Amazon SAP-C02: Sicurezza, identità e conformità — Guida allo studio

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Fa parte della AWS Solutions Architect Professional SAP-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Gestione di identità e accessi: controllo basato su principi e federazione

La gestione delle identità dovrebbe essere progettata attorno a credenziali di breve durata con privilegi minimi (least-privilege) e una netta separazione tra la fiducia sull’identità (identity trust) e la concessione di permessi. Utilizzare i ruoli IAM per tutti gli accessi di tipo compute e cross-account, evitare le chiavi di accesso utente IAM di lunga durata e sfruttare STS per le credenziali temporanee. Per la federazione aziendale SAML o OIDC, configurare un identity provider centralizzato e abilitare l’accesso basato su attributi (attribute-based access) utilizzando i session tag, in modo che i permessi seguano utenti e gruppi senza la necessità di gestire gli utenti per ogni singolo account. IAM Identity Center (IAM Identity Center) fornisce set di permessi (permission sets) a livello di organizzazione, provisioning SCIM per il push dei gruppi in AWS e si integra con l’applicazione della MFA dall’IdP per soddisfare i requisiti di autenticazione forte (strong-auth). Integrare i controlli di identità con i permission boundaries e le policy gestite (managed policies) per limitare l’escalation dei privilegi (privilege escalation) ed eseguire IAM Access Analyzer per rilevare l’accesso non intenzionale alle risorse. Le Service Control Policies (SCP) in AWS Organizations offrono dei guardrail negando intere categorie di azioni attraverso le OU, ma non concedono permessi: le trust policy e le permission policy rimangono necessarie. Le trappole comuni includono azioni o principal con wildcard troppo ampie, fare affidamento sull’account root, la mancanza di ID esterni (external ID) per l’accesso di terze parti e il role chaining che estende la portata effettiva della sessione. I compromessi riguardano l’overhead operativo rispetto a una granularità più stretta: ruoli molto granulari richiedono più gestione ma riducono significativamente il raggio d’impatto (blast radius).

Chiavi, segreti e crittografia: ciclo di vita e pattern cross-account

La crittografia è fondamentale per i controlli sia at-rest che in-transit; le decisioni dovrebbero bilanciare la proprietà della chiave (key ownership), il controllo operativo e le prestazioni. Utilizzare le CMK gestite dal cliente (customer-managed CMK) di AWS KMS quando si necessita di policy della chiave granulari, concessioni cross-account, auditabilità o rotazione automatica. Per la comodità della gestione da parte del servizio, le chiavi gestite da AWS (AWS-managed keys) riducono l’overhead operativo ma limitano il controllo sulle policy. L’envelope encryption mitiga l’impatto sulle prestazioni per payload di grandi dimensioni utilizzando una data key per la crittografia massiva e KMS per il wrapping della chiave. L’uso cross-account o cross-Region richiede policy della chiave e Grant espliciti; evitare di concedere solo permessi IAM senza la corrispondente policy della chiave. Secrets Manager offre flussi di lavoro per la rotazione e integrazione nativa con RDS e altri servizi, mentre SSM Parameter Store (SecureString) è un’opzione a costo inferiore per esigenze più contenute; entrambi dovrebbero utilizzare endpoint VPC per evitare l’uscita verso la rete pubblica (public egress). Le trappole comuni per gli architetti includono la concessione di

undefined

o di ampi diritti di

undefined

nelle policy della chiave, dimenticare di consentire ai ruoli di esecuzione di Lambda sia i permessi IAM che quelli KMS, e trascurare la replica multi-Region per le chiavi utilizzate da carichi di lavoro distribuiti a livello globale. I compromessi costo-prestazioni includono il costo per richiesta di KMS e una leggera latenza aggiuntiva rispetto ai benefici di sicurezza derivanti dal controllo sulle chiavi gestite dal cliente.

Rilevamento, monitoraggio e auditing: telemetria, controlli di rilevamento e automazione

I controlli di rilevamento (detective controls) sono importanti quanto quelli preventivi; la strumentazione (instrumentation) dovrebbe essere centralizzata, immutabile e ricercabile. Abilitare AWS CloudTrail in modalità multi-Region e multi-account con la validazione dei file di log e inviare i log a un account S3 centralizzato con accesso controllato e policy di lifecycle. Inviare i log di CloudTrail, i VPC Flow Logs e i log DNS a una pipeline di analisi centralizzata — come CloudWatch Logs, Kinesis Data Firehose e un SIEM — per la conservazione (retention) e la generazione di allarmi (alerting). GuardDuty fornisce rilevamento gestito delle minacce (managed threat detection) per i comportamenti dell’account e dei carichi di lavoro; designare un amministratore delegato per aggregare i risultati (findings) attraverso l’Organization e automatizzare la risposta tramite EventBridge per attivare playbook Lambda o Systems Manager Automation. Security Hub aggrega standard e risultati (findings) (CIS, PCI, regole personalizzate) e può orchestrare la remediation prioritizzata. AWS Config e le Config Rules abilitano controlli di conformità continui e il rilevamento delle deviazioni (drift detection), con remediation tramite SSM Automation. Le trappole tipiche includono CloudTrail in una singola regione, conservazione insufficiente o log non immutabili, allarmi rumorosi (noisy alerts) senza un’adeguata messa a punto (tuning) e la mancanza di amministratori delegati per scalare il rilevamento. I compromessi dipendono dai costi di conservazione (retention) rispetto alle esigenze forensi e di conformità: una conservazione più lunga aiuta le indagini ma aumenta i costi di S3 e di interrogazione (querying).

Difesa a livello di applicazione, WAF, Shield e governance multi-account

La protezione delle applicazioni esposte su Internet richiede controlli a più livelli e una gestione centralizzata delle policy. Posizionare AWS WAF a livello di edge (CloudFront) e/o sugli ALB regionali per filtrare le minacce di tipo OWASP, il traffico dei bot e per implementare il rate limiting. Per la gestione delle regole in un ambiente multi-account, utilizzare AWS Firewall Manager con un account di sicurezza delegato per distribuire gruppi di regole WAFv2, sottoscrizioni a Shield Advanced e policy di sicurezza centralizzate tra le varie OU. Shield Advanced offre mitigazione DDoS e protezione dei costi per eventi su larga scala, ma è costoso; valutare l’SLA e l’esposizione agli attacchi DDoS della propria applicazione rispetto al prezzo della sottoscrizione. Utilizzare Web ACL centralizzate, gruppi di regole gestite (managed rule groups) e aggiornamenti granulari degli IP set per ridurre il carico operativo ed evitare protezioni incoerenti. Le trappole architetturali includono l’affidarsi esclusivamente ai security group a livello di rete, non centralizzare la distribuzione delle regole (causando un disallineamento o “drift”) o posizionare WAF solo a livello regionale quando è necessaria una protezione CDN globale. I compromessi in termini di prestazioni includono la potenziale latenza aggiuntiva per l’ispezione e la complessità delle regole personalizzate, a fronte della resilienza ottenuta bloccando il traffico malevolo prima che raggiunga i server di origine. Assicurare l’attivazione di log e metriche per WAF e la sua integrazione con Security Hub/GuardDuty per una risposta agli incidenti coesa.

Problema Pratico: Scenario d’Uso

Scenario: OmniApps Ltd. possiede una AWS Organization con un account di gestione, un account di rete centralizzato che ospita un Transit Gateway e diversi account di workload in eu-west-1 e us-east-1. Gestiscono stack applicativi privati in VPC con ALB in sottoreti private, esposti tramite CloudFront, e necessitano di controlli di identità e sicurezza centralizzati.

Sfida: OmniApps deve centralizzare l’accesso con MFA basato su SAML aziendale, applicare guardrail di sicurezza a livello di organizzazione, gestire le regole WAF e la protezione DDoS tra i vari account, e mantenere segreti e chiavi accessibili solo tramite percorsi di rete privati.

Approccio Raccomandato:

Abilitare IAM Identity Center nell’account di gestione e connetterlo all’IdP SAML aziendale imponendo l’MFA; configurare il provisioning SCIM e creare permission set per l’accesso cross-account secondo il principio del privilegio minimo (least-privilege).
Implementare Service Control Policies in Organizations per negare azioni non gestite dell’utente root e richiedere l’uso di CloudTrail/Config; designare un account di sicurezza come amministratore delegato per Security Hub, GuardDuty e Firewall Manager.
Utilizzare AWS Firewall Manager dall’account di sicurezza per distribuire Web ACL di AWS WAFv2 e AWS Managed Rules sulle distribuzioni CloudFront e sugli ALB in tutti gli account; valutare la sottoscrizione a Shield Advanced per ogni applicazione critica.
Centralizzare i log di CloudTrail in un account di logging sicuro, crittografati con una CMK multi-regione nell’account di sicurezza, concedere i permessi di decrittografia tramite una policy esplicita della chiave KMS e Grants ai processori di log, e abilitare VPC endpoint per KMS e Secrets Manager per l’accesso privato.

Logica: L’identità centralizzata e l’amministrazione della sicurezza delegata riducono l’attrito amministrativo e il raggio d’impatto (blast radius), mentre Firewall Manager e il logging centralizzato forniscono un’applicazione coerente delle policy e capacità forensi in linea con le best practice di architettura professionale.

← Networking e connettività ibrida · Tutti i domini · Compute e Auto Scaling →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →