Rafforzamento dell'ambiente prod

Rafforzamento dell'ambiente protettivo

1) Obiettivo e cornice

Il rafforzamento (hardening) dell'ambiente è una serie di pratiche di sistema che riducono la possibilità di incidenti e danni. Focus: perimetro API, dati client/pagamenti, CI/CD, piattaforma contenitori, accessibilità, controllo delle modifiche, osservabilità e conformità.

• Sicurezza by Design & Default: privilegi minimi necessari, default sicuro.
• Zero Trust non fidarsi né della rete né delle identità senza la verifica.
• Defence-in-Depth - Protezione su più livelli (rete, servizio, applicazione e dati).
• L'immutabilità degli artefatti è «build once, run many».
• Tracce E2E e audibilità: chi, quando, cosa ha cambiato - e perché.

2) Modello di minacce e risorse critiche

Beni: conti e token di pagamento, PI/passaporti, RNG/bilanci di gioco, chiavi di crittografia, segreti di integrazioni, pipline di deposito, immagini di contenitori.
Vettori: vulnerabilità delle dipendenze, perdite di token, configurazione del cloud/K8s non corretta, SSRF/RCE in API, supply chain (compromissione di CI/CD/repository), accesso privilegiato, DDoS/bot.
Script: prelievo di fondi da parte di un soggetto non autorizzato, sostituzione di coefficienti/bilanci, fuso di base, acquisizione di pipline, modifiche manuali in vendita.

3) Architettura di rete e isolamento

Segmentazione: VPC/VNet separati per prod/stage/dave. All'interno della prod - Sottorete per edge (LB/WAF), API, database, analisi, servizi admine.
Il criterio «esplicitamente consentito» è deny-all tra le sottotete, aprendo solo le porte/direzioni desiderate.
Tra i servizi, la rotazione dei certificati è automatizzata.

yaml apiVersion: networking. k8s. io/v1 kind: NetworkPolicy metadata:
name: default-deny namespace: prod spec:
podSelector: {}
policyTypes: ["Ingress","Egress"]
apiVersion: networking. k8s. io/v1 kind: NetworkPolicy metadata:
name: allow-api-to-db namespace: prod spec:
podSelector:
matchLabels: {app: db}
ingress:
- from:
- podSelector: {matchLabels: {app: api}}
ports: [{protocol: TCP, port: 5432}]

4) Identità e accesso (PAM/JIT)

SSO + MFA per tutte le accessibilità umane.
RBAC&ABAC: ruoli a livello di cloud, cluster, spazio dei nomi e applicazione.
PAM: jump/base, accesso JIT (tempo limitato), sessione recording.
Break-glass - Insegne sigillate con chiave hardware, rilascio giornalizzato.
Scansioni regolari di chi ha accesso a tutto questo, ogni 30 giorni.

5) Segreti e chiavi

Archivio segreti (Vault/KMS/Secret Manager), escludiamo i segreti da Git.
KMS/HSM per chiavi master; KEK/DEK, rotazione automatica.
Criteri TTL: token a vita corta (OIDC/JWT), apprendisti temporanei per CI.
Crittografia a riposo (AES-256/GCM), in volo (TLS 1. 2+/mTLS), le colonne PII/schede sono una chiave separata.

6) Supply chain и CI/CD hardening

Isolamento runner'ov per prod (self-hosted in una rete privata).
Firma manufatti (Sigstore/cosign), convalida la firma del deposito.
SBOM (CycloneDX/SPDX), SCA/VA su ogni commit e prima del lancio.
Criteri no tag latest, solo tag immutabili.
4 occhi: codice review obbligatorio e change approval.
Infrastructure as Code: Terraform/Helm с policy-as-code (OPA/Conftest).

rego package iac. guardrails

deny[msg] {
input. resource. type == "storage_bucket"
input. resource. acl == "public-read"
msg:= sprintf("Public bucket forbidden: %s", [input. resource. name])
}

7) Contenitori e Kubernets

Base di aspetto minima (distroless), rootless, read-only FS, drop CAP.
Controllo addizionale: divieto di prived, hostPath, hostNetwork.
Pod Security Standards: baseline/restricted для prod ns.
ImagePolicyWebhook - Omettere solo le immagini firmate.
Regole runtime (Falco/eBPF): alert per syscalls anomali.
Protezione dei nodi da «vicini rumorosi».

8) perimetro API: WAF, Rate Limits, Bot/DDoS

API Gateway: autenticazione (OAuth2/JWT/HMAC), normalizzazione, mTLS, schema validation.
WAF: regole di base + casta per metriche aziendali.
Rate limits: globale/IP/chiave client; token e burst.

nginx limit_req_zone $binary_remote_addr zone=api:20m rate=10r/s;

server {
location /api/ {
limit_req zone=api burst=30 nodelay;
proxy_pass http://api_backend;
}
}

Bot management: segnali comportamentali, device fingerprint, challenge.
DDoS: CDN/edge-screobbing, autoscaling, dark-launch per i fiocchi caldi.

9) Criteri di configurazione e default sicuri

Feature flags/kill-switches per disattivare rapidamente le funzioni di rischio.
Config-as-Code con convalida degli schemi, canary/blue-green per le configurazioni.
Time-to-Revoke come KPI quando si richiamano configuri/chiavi.

10) Dati e privacy

Classificazione: PII/finanza/logi operativi/telemetria.
Minimizzazione: memorizza solo ciò che desideri, anonimato/alias.
Backups: account/progetto separato, crittografia, prove DR regolari.
Le regole di output sono same-method, velocity-limits, risk-screen, 4-occhi.
Legale Hold/Retenschn: grafici di storage, smaltimento gestito.

11) Osservazione, alert e risposta

Quadriadi (senza segreti), metriche (SLO/SLA), roulotte (W3C).
Segnali di sicurezza: successo/inattività degli ingressi, aumento dei privilegi, cambiamenti dei segreti, deviazione del traffico.
SIEM + SOAR - Correlazione e playbook semiautomatici.
Playbook di incidenti: DDoS, fuga di segreti, compromissione runner'a, rilascio rollback, congelamento dei pagamenti.
MTTD/MTTR come metriche principali di rapidità.

12) Gestione delle modifiche e del rilascio

Change Advisory Board (leggero) per modifiche high-risk.
Pre-prod gates: test, sicurezza, perf, migrazione del database.
Canary/Blue-Green/Shadow deploi, rollback automatico SLO.
Disabilita le modifiche dirette alla vendita: modifiche solo tramite pipline.

13) Vulnerabilità e patch

Patch policy critico - ASAP; high - entro n giorni.
Nuova scansione dopo la fix; Pesatura CVE per esposizione.
Chaos-security: esercizi periodici «table-top» e attacchi di comando rosso nelle finestre selezionate.

14) Conformità e verifica

Frame di controllo: PCI DSS (pagamenti), SOC2, ISO 27001.
Artefatti: matrice di controllo, registri delle modifiche, report delle scene, risultati dei test DR, access review.
Preparazione continua: «evidence as code» - i manufatti vengono raccolti automaticamente da pipline e sistemi.

15) Economia e affidabilità

Garrails in base al costo: quote, budget, alert, spegnimento automatico delle risorse inutilizzate.
Capacità: pianificazione orientata a SLO, test di carico, giorni di caos.
Priorità di ripristino: RTO/RPO sui servizi, mappa delle dipendenze.

16) Anti-pattern

I segreti v.eng in Git, «admine» condivisi per tutti, «SSH diretto in prode», fissaggi manuali in contenitori, «latest» tag, un cluster condiviso per tutto, baguette pubbliche, CI-runner con outbound-internet in rete prod, login con PII, nessun kill-switch per «hot» I fischi.

17) Lista degli assegni di partenza rapida (90 giorni)

0-30 giorni

Abilita MFA/SSO, invecchiando la disponibilità; deny-all criteri di rete Secrets Manager/KMS; Divieto di privacy in K8s; Abilitare WAF/Rate-limit; alert di base di ingresso/escalation.

31-60 giorni

Firma immagine + ImagePolicy; SBOM + SCA в CI; canary/rollback; Correlazioni SIEM playbook IR; JIT/PAM; backup con test DR.

61-90 giorni

OPA-GUARDRAILS eBPF/Falco; bot management; periodic access-review; chaos-security esercizio; Controllo di configurazioni e cost-garrails.

18) Metriche di maturità

Disponibili:% di apprendistato con MFA, età media dei token, tempo di ritiro.
Pipline:% di immagini firmate/SBOM, rivestimento SAST/DAST.
Piattaforma: pod'ov con read-only FS, PSS-restritted, rivestimento NetworkPolicy.
Perimetro:% API con regole rate-limit/WAF, risposta media al DDoS.
IR: MTTD/MTTR, frequenza «table-top», percentuale di prove DR di successo.
La corrispondenza è la quota di controllo con le prove automatiche.

19) Applicazione: modelli di criteri

AWS SCP (proibizione dei bustini pubblici)

json
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "DenyPublicS3",
"Effect": "Deny",
"Action": ["s3:PutBucketAcl","s3:PutBucketPolicy"],
"Resource": "",
"Condition": {"StringEquals": {"s3:x-amz-acl": "public-read"}}
}]
}

Kubernetes PodSecurity (namespace-label)

yaml apiVersion: v1 kind: Namespace metadata:
name: prod labels:
pod-security. kubernetes. io/enforce: restricted pod-security. kubernetes. io/audit: restricted

OPA per contenitori (disabilitazione)

rego package k8s. admission deny[msg] {
input. request. object. spec. containers[_].securityContext. privileged == true msg:= "Privileged containers are not allowed in prod"
}

20) Conclusione

Il rafforzamento dell'ambiente protettivo è un processo continuo. Priorità per la massima riduzione dei rischi: disponibilità e segreti, isolamento in rete, firma di manufatti e controllo del pipline, protezione del perimetro API, osservabilità e disciplina dei cambiamenti. Il resto aumenta in modo iterativo, fissando le metriche di maturità e l'economia di controllo.