Domain Knowledge Base - Cloud Infrastructure
Come funziona il dominio, prima di scrivere una riga di codice? Scegli un documento dall'albero a sinistra: ogni pagina spiega una parte del modello.
Regole di Business - Cloud Infrastructure
Questo documento elenca le regole di business fondamentali del dominio Cloud Infrastructure, identificate con codice univoco BR-NNN. Ogni regola è technology-independent (vale su AWS, Azure, GCP o cloud privato) e descrive un vincolo invariante sul comportamento del sistema infrastrutturale.
---
BR-001 - Tutta l'infrastruttura è descritta come codice versionato
Codice: BR-001
Nome: Nessuna risorsa cloud provisionata fuori da Infrastructure as Code
Descrizione: Ogni risorsa cloud (rete, compute, storage, IAM) deve essere definita in un IaCModule versionato e applicata tramite il flusso di provisioning. Le modifiche manuali in console ("click-ops") sono vietate perché generano drift non tracciabile.
Motivazione: Riproducibilità, audit, rollback e prevenzione del drift tra stato desiderato e stato reale.
Priorità: ALTA
Attori: Platform Engineer, Provisioning Engine
Violazione: il DriftDetected event apre un task di reconciliation; la risorsa fuori-codice viene reimportata o distrutta.
Tracciabilità: HashiCorp Terraform docs; AWS Well-Architected OPS; provision-infrastructure.md.
---
BR-002 - Provisioning idempotente
Codice: BR-002
Nome: Applicare lo stesso piano più volte produce lo stesso stato
Descrizione: Un apply del Provisioning Engine sullo stesso IaCModule con lo stesso input deve convergere allo stesso InfrastructureState senza creare risorse duplicate. Un retry dopo un timeout di rete non deve raddoppiare le risorse.
Motivazione: Sicurezza al retry in presenza di guasti di rete; convergenza deterministica.
Priorità: ALTA
Attori: Provisioning Engine
Tracciabilità: Idempotenza (glossary); 12factor.net; provision-infrastructure.md.
---
BR-003 - Ridondanza multi-zona obbligatoria per i workload di produzione
Codice: BR-003
Nome: Ogni workload di produzione è distribuito su almeno due Availability Zone
Descrizione: Un Workload con tier production deve avere repliche distribuite su ≥2 AvailabilityZone della stessa Region. Un singolo punto di guasto zonale non deve causare indisponibilità totale del servizio.
Motivazione: Alta disponibilità; tolleranza al guasto di una zona.
Priorità: ALTA
Attori: Platform Engineer, Load Balancer
Violazione: blocco del deploy se la policy rileva un workload production single-AZ.
Tracciabilità: AWS Well-Architected REL; failover-recovery.md.
---
BR-004 - Privilegio minimo su ogni identità
Codice: BR-004
Nome: Ogni IAMPolicy concede solo i permessi strettamente necessari
Descrizione: Nessuna identità (utente, ruolo, service account) può avere permessi più ampi di quelli richiesti dalla sua funzione. Sono vietati i permessi wildcard (:) sulle risorse di produzione.
Motivazione: Ridurre la superficie d'attacco; contenere il raggio d'azione di una credenziale compromessa (zero trust).
Priorità: CRITICA
Attori: Security Engineer, Identity Provider
Violazione: la pipeline di policy-scan rifiuta il merge; audit di sicurezza.
Tracciabilità: NIST SP 800-207 (Zero Trust); CIS Benchmarks; OWASP Cloud-Native Top 10.
---
BR-005 - I segreti non risiedono mai nel codice o nelle immagini
Codice: BR-005
Nome: Ogni segreto è custodito in un Secrets Manager e iniettato a runtime
Descrizione: Credenziali, chiavi API, certificati e password non devono mai comparire in repository IaC, immagini container, variabili d'ambiente in chiaro nei manifest o log. Devono essere recuperati a runtime da un secrets manager con accesso auditato.
Motivazione: Prevenire la disclosure di credenziali; consentire rotazione senza redeploy.
Priorità: CRITICA
Attori: Security Engineer, Provisioning Engine
Violazione: lo scan di supply-chain blocca il commit; rotazione immediata del segreto esposto.
Tracciabilità: CIS Benchmarks; AWS Well-Architected SEC; best-practices.md.
---
BR-006 - Cifratura in transito e a riposo per default
Codice: BR-006 Nome: Tutti i dati sono cifrati in transito (TLS 1.2+) e a riposo Descrizione: La comunicazione tra componenti avviene su TLS 1.2 minimo (1.3 preferibile); i volumi di storage e i backup sono cifrati a riposo con chiavi gestite. Nessun endpoint accetta traffico in chiaro su reti non fidate. Motivazione: Riservatezza e integrità dei dati; conformità. Priorità: CRITICA Attori: Security Engineer, Load Balancer Tracciabilità: RFC 8446 (TLS 1.3); NIST SP 800-145; AWS Well-Architected SEC.
---
BR-007 - Backup verificati e RTO/RPO definiti
Codice: BR-007
Nome: Ogni workload stateful ha un piano di disaster recovery con RTO/RPO dichiarati
Descrizione: Ogni Workload che persiste dati deve avere backup periodici, un RecoveryPointObjective (massima perdita dati tollerata) e un RecoveryTimeObjective (massimo tempo di ripristino) documentati. Le procedure di restore devono essere testate periodicamente, non solo configurate.
Motivazione: Garantire la recuperabilità reale; un backup mai testato non è un backup.
Priorità: ALTA
Attori: Platform Engineer, SRE
Tracciabilità: AWS Well-Architected REL; failover-recovery.md; BR-003.
---
BR-008 - Risorse di backend isolate in subnet private
Codice: BR-008
Nome: Database e servizi interni non sono raggiungibili dall'internet pubblico
Descrizione: Ogni risorsa che non deve essere esposta pubblicamente (database, cache, servizi interni) risiede in una PrivateSubnet senza IP pubblico. L'accesso esterno avviene solo tramite LoadBalancer/Ingress controllati o bastion/VPN.
Motivazione: Ridurre la superficie esposta; difesa in profondità.
Priorità: ALTA
Attori: Network Engineer, Platform Engineer
Tracciabilità: Virtual Private Cloud (glossary); NIST SP 800-207; best-practices.md.
---
BR-009 - Governance continua dei costi
Codice: BR-009
Nome: Ogni risorsa ha un owner e tag di costo; gli sprechi vengono recuperati
Descrizione: Ogni risorsa provisionata deve avere tag di attribuzione (owner, ambiente, centro di costo). Risorse orfane, sovradimensionate o inutilizzate devono essere identificate e dismesse o ridimensionate. Il budget cloud è monitorato con alert di soglia.
Motivazione: Evitare spreco economico; responsabilizzare i team sui consumi.
Priorità: MEDIA
Attori: FinOps Analyst, Platform Engineer
Tracciabilità: AWS Well-Architected COST; cost-governance.md.