Salta al contenuto principale

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.