Amazon SCS-C02: Governance, configurazione e automazione — Guida allo studio

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Fa parte della AWS Security Specialty SCS-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Service Control Policies e Guardrail a Livello di Organizzazione

Le Service Control Policies costituiscono il perimetro più esterno di ciò che qualsiasi principal può fare in una AWS Organization. Una SCP non è una policy IAM: non concede nulla, definisce solo le autorizzazioni massime disponibili per gli account sotto una OU o per l’intera organizzazione. Un Allow in una policy IAM, in una policy di risorsa o in un permissions boundary è completamente inefficace se una SCP nega l’azione. Questa asimmetria è esattamente il motivo per cui le SCP sono lo strumento corretto per i guardrail a livello di organizzazione: restrizioni sulle Region, servizi vietati, protezione dei ruoli IAM gestiti centralmente e imposizione della crittografia alla creazione delle risorse.

Una SCP canonica che nega la creazione di tabelle DynamoDB e bucket S3 non crittografati ha questo aspetto:

Version: "2012-10-17"
Statement:
  - Sid: DenyUnencryptedS3
    Effect: Deny
    Action: s3:CreateBucket
    Resource: "*"
    Condition:
      StringNotEquals:
        s3:x-amz-server-side-encryption-aws-kms-key-id: !Ref CmkArn
  - Sid: DenyUnencryptedDdb
    Effect: Deny
    Action: dynamodb:CreateTable
    Resource: "*"
    Condition:
      "Null":
        dynamodb:SSESpecificationEnabled: "true"

Una trappola comune è tentare di imporre “nessuno nell’organizzazione può usare us-east-2” o “nessuno può disabilitare CloudTrail” tramite policy IAM collegate a ciascun account. Anche con un permissions boundary e un allineamento delle policy di identità, un amministratore locale può crearsi una via di fuga. Solo una SCP applicata alla root o a una OU è affidabile, perché vincola persino l’utente root degli account membri (con la stretta eccezione di una manciata di azioni non limitabili).

Le SCP dovrebbero anche proteggere i ruoli di break-glass e di amministrazione delegata: aggiungere un Deny esplicito su qualsiasi azione che abbia come target un ruolo come OrganizationAccountAccessRole o SecurityAudit, a meno che l’ aws:PrincipalArn del chiamante non corrisponda a un elenco approvato.

AWS Config, Conformance Pack e Applicazione Multi-Account

AWS Config fornisce il livello di valutazione continua che integra le SCP (che prevengono) con il rilevamento (che osserva e segnala le deviazioni). Un conformance pack è un pacchetto di regole Config — sia regole gestite come s3-bucket-server-side-encryption-enabled sia regole personalizzate basate su Lambda o Guard — confezionato come un singolo artefatto YAML distribuibile con azioni di remediation opzionali.

Per distribuire una baseline standard a livello di organizzazione, si combinano due meccanismi:

CloudFormation StackSets dall’account di gestione con autorizzazioni gestite dal servizio e AutoDeployment: Enabled, in modo che qualsiasi nuovo account che si unisca all’organizzazione riceva automaticamente uno stack che attiva il registratore e il canale di consegna di Config. Questo risolve il problema di bootstrap: un conformance pack non può valutare un account in cui Config non è abilitato.
Conformance pack distribuiti dall’account amministratore delegato (ad esempio security-01) utilizzando PutOrganizationConformancePack. Questo propaga un set di regole coerente a ogni account attuale e futuro, senza bisogno di intervenire manualmente su ciascun account.

Il pattern amministratore delegato + aggregatore è importante: permette al team di sicurezza di vedere la conformità di tutti gli account in un unico posto, pur consentendo ai team applicativi di aggiungere le proprie regole localmente. Distribuire le stesse regole direttamente dall’account di gestione funzionerebbe, ma violerebbe il principio del privilegio minimo e impedirebbe gli audit sulla separazione dei compiti.

CloudFormation Guard, StackSets e Service Catalog

La prevenzione dovrebbe spostarsi a sinistra (“shift left”). CloudFormation Guard (cfn-guard) è un motore di policy-as-code che analizza i template CloudFormation (o qualsiasi file JSON/YAML) e li valuta rispetto a regole dichiarative prima della distribuzione. Una regola Guard ha questo aspetto:

rule s3_encrypted {
  Resources.*[ Type == "AWS::S3::Bucket" ] {
    Properties.BucketEncryption exists
    Properties.BucketEncryption.ServerSideEncryptionConfiguration[*] {
      ServerSideEncryptionByDefault.SSEAlgorithm == "aws:kms"
    }
  }
}

Integrare questo in una fase di CI/CD — tipicamente come uno step in un container Docker che esegue cfn-guard validate -r rules.guard -d template.yaml — fa fallire la pipeline prima che venga creata qualsiasi risorsa non conforme. In caso di violazione, la pipeline pubblica un messaggio su un topic SNS a cui il team di sicurezza è iscritto, dando loro visibilità senza diventare un collo di bottiglia per l’approvazione manuale. Affidarsi esclusivamente alla revisione degli StackSet o dei change set di CloudFormation per notificare il team di sicurezza è una trappola: nessuno dei due servizi emette risultati di conformità per singola risorsa, e nel momento in cui uno stack è stato creato, la risorsa esiste già nell’account.

Service Catalog completa Guard per l’ultimo miglio (“last mile”). Invece di lasciare che gli sviluppatori scrivano codice CloudFormation arbitrario, il team della piattaforma pubblica prodotti approvati (baseline di VPC, pattern RDS, cluster EKS) come portfolio di Service Catalog condivisi tra gli account tramite AWS RAM. Gli sviluppatori li avviano con parametri vincolati e un ruolo IAM di “launch constraint” esegue il provisioning delle risorse con autorizzazioni elevate che lo sviluppatore non possiede personalmente. Questo fornisce un modello di distribuzione self-service e verificabile, in cui il template sottostante ha già superato i controlli di Guard.

Gli StackSets stessi necessitano di una configurazione corretta (“plumbing”): utilizzare il modello di autorizzazione SERVICE_MANAGED quando si distribuisce dall’account di gestione dell’organizzazione, abilitare l’accesso attendibile per CloudFormation in Organizations e configurare attentamente i ruoli di esecuzione. La coppia AdministrationRoleARN/ExecutionRoleName (in modalità autogestita) o i ruoli collegati al servizio (in modalità gestita dal servizio) devono avere l’autorizzazione iam:PassRole verso il ruolo di servizio di CloudFormation che crea effettivamente le risorse. Dimenticare di associare un ruolo di servizio di CloudFormation e affidarsi invece alle credenziali dell’utente che esegue la distribuzione porta a errori intermittenti di AccessDenied su iam:PassRole — una causa comune di fallimento delle operazioni degli StackSet. Il pattern corretto è un ruolo di servizio dedicato per ogni stack, con solo le autorizzazioni necessarie per creare i tipi di risorsa dichiarati.

Pipeline di remediation automatizzata

Quando Config rileva una non conformità, la remediation deve essere automatica per tutto ciò che può essere auto-riparato in sicurezza. Il flusso degli eventi è:

Config pubblica un evento Compliance Change sul bus di eventi predefinito.
Una regola di EventBridge filtra i risultati NON_COMPLIANT relativi a regole specifiche e indirizza l’evento a un documento di Systems Manager Automation (per correzioni semplici e idempotenti come l’abilitazione della crittografia S3), a una funzione Lambda (per correzioni a livello di API) o a una state machine di Step Functions (per flussi di lavoro multi-step che richiedono approvazioni, tentativi o orchestrazione tra servizi).

Ad esempio, se la regola s3-bucket-public-read-prohibited si attiva, un runbook di SSM Automation AWS-DisableS3BucketPublicReadWrite esegue la remediation. Per flussi più complessi, come una policy di una chiave KMS che devia dalla configurazione desiderata e deve essere riconciliata notificando il team proprietario, Step Functions coordina le operazioni: legge la policy corrente, la confronta con la versione “golden”, chiama kms:PutKeyPolicy e infine pubblica un messaggio su SNS. Memorizzare la logica di remediation in Step Functions anziché in una singola Lambda offre osservabilità su ogni passaggio e una semantica di retry pulita.

IAM Access Analyzer e validazione delle policy

IAM Access Analyzer risponde a due domande distinte. In primo luogo, gli analizzatori di accesso esterno identificano le risorse (S3, KMS, ruoli IAM, Lambda, SQS, Secrets Manager) le cui policy concedono l’accesso a principal esterni a una “zona di fiducia” (zone of trust) definita, che può essere l’account o l’organizzazione. Abilita l’analizzatore a livello di organizzazione dall’account amministratore delegato in modo che i risultati vengano aggregati centralmente.

In secondo luogo, la validazione delle policy (policy validation) e la generazione delle policy (policy generation) di Access Analyzer vengono eseguite durante la fase di authoring. Il comando aws accessanalyzer validate-policy restituisce avvisi di sicurezza, errori e suggerimenti (ad esempio, segnalando un Resource: "*" eccessivamente ampio combinato con azioni sensibili). Integra questo controllo nella stessa fase di CI/CD di cfn-guard in modo che le policy IAM incorporate in CloudFormation vengano verificate prima del deployment. Access Analyzer può anche generare una policy basata sul principio del privilegio minimo (least-privilege) a partire dalla cronologia di CloudTrail, sostituendo una policy con wildcard con le azioni esatte che un ruolo ha effettivamente utilizzato. Questa è la risposta meccanica alla necessità di “applicare il privilegio minimo per l’accesso ai dati”, insieme a una policy di chiave KMS con ambito limitato che permette kms:Decrypt solo quando il servizio chiamante è S3, DynamoDB, Lambda o EKS tramite le condizioni kms:ViaService.

Problema pratico: scenario d’uso

Scenario: Meridian Financial gestisce un’AWS Organization multi-account che include account di produzione, staging, sandbox e un account di sicurezza centralizzato. Distribuiscono i carichi di lavoro con un mix di template CloudFormation e template creati dagli sviluppatori nella sandbox; la proprietà è federata tra i vari team, i quali devono rispettare la governance interna per la crittografia dei dati e l’accesso con privilegi minimi.

Sfida: Gli sviluppatori nella sandbox hanno creato accidentalmente bucket S3 pubblici e policy IAM eccessivamente permissive che si sono propagate ad altri account. Il team di sicurezza non dispone di un’applicazione delle regole e di una validazione dei template coerenti e automatizzate in tutta l’Organization.

Approccio consigliato:

Creare Service Control Policies (SCPs) a livello di Organization per negare l’accesso pubblico a S3, imporre la crittografia dei bucket e limitare le azioni IAM privilegiate alla radice dell’Organization, fornendo così dei guardrail preventivi.
Dall’account di sicurezza centrale, distribuire un aggregatore AWS Config e dei Conformance Pack utilizzando CloudFormation StackSets in ogni account e regione per valutare continuamente l’accesso pubblico a S3, i pattern di associazione delle policy IAM e la conformità della crittografia.
Integrare le regole di CloudFormation Guard (cfn-guard) nella pipeline CI/CD (CodePipeline/CodeBuild) e richiedere l’uso di prodotti Service Catalog per l’infrastruttura approvata, in modo che i template vengano validati e si possano provisionare solo stack conformi.
Abilitare la remediation automatizzata di AWS Config con documenti di SSM Automation o runbook Lambda per i risultati ad alta priorità (blocco automatico dell’accesso pubblico a S3, remediation di policy IAM eccessivamente permissive) e attivare flussi di lavoro aggiuntivi tramite EventBridge.
Eseguire IAM Access Analyzer e la validazione delle policy a livello centrale, inserire i risultati in Security Hub e automatizzare la creazione di ticket o l’esecuzione di playbook di remediation per le policy cross-account o eccessivamente permissive scoperte.

Logica: Questo approccio combina guardrail preventivi a livello di organizzazione (SCP), rilevamento continuo (Config/Conformance Pack), validazione anticipata dei template (“shift-left”) (cfn-guard/Service Catalog) e remediation automatizzata con IAM Access Analyzer per applicare il principio del privilegio minimo e ottenere una governance multi-account coerente, secondo le best practice di AWS.

AWS Config: Regole di Organizzazione, Aggregatori e Amministrazione Delegata

AWS Config è il fondamento del controllo detective della conformità su AWS. Registra continuamente le configurazioni delle risorse e le valuta rispetto a regole, che possono essere gestite da AWS (ad esempio, restricted-ssh, vpc-flow-logs-enabled, encrypted-volumes) o personalizzate (supportate da Lambda o Guard). Su scala enterprise, tre decisioni architetturali contano più delle regole stesse: come vengono distribuite le regole, come vengono aggregati i risultati e chi è responsabile degli strumenti.

Per implementazioni multi-account e multi-regione sotto AWS Organizations, il pattern corretto è designare un account amministratore delegato (tipicamente l’account di sicurezza o di audit, non l’account di gestione) tramite aws organizations register-delegated-administrator --service-principal=config-multiaccountsetup.amazonaws.com. Da quell’account, si utilizza PutOrganizationConfigRule o PutOrganizationConformancePack per distribuire le regole a ogni account membro e regione. Saltare l’amministrazione delegata costringe ad abilitare Config manualmente in ogni account o a eseguire tutto dall’account di gestione: quest’ultima opzione viola la separazione dei compiti, mentre la prima non è scalabile oltre una manciata di account.

Le regole di organizzazione distribuiscono una singola definizione di regola; gli aggregatori raccolgono le valutazioni risultanti. Si crea un aggregatore nell’account amministratore delegato con una OrganizationAggregationSource che copre tutti gli account e le regioni. La dashboard dell’aggregatore risponde quindi a domande come “quali VPC in 200 account non hanno i Flow Logs?” senza doversi destreggiare tra ruoli cross-account. Si noti che gli aggregatori sono di sola lettura: espongono lo stato di conformità ma non eseguono la remediation autonomamente.

Pacchetti di Conformità per l’Applicazione di Baseline

Un pacchetto di conformità (conformance pack) raggruppa le regole di Config e le relative azioni di remediation in un unico template YAML. AWS fornisce pacchetti mappati su framework come PCI DSS, HIPAA, NIST 800-53 e CIS. La distribuzione di un pacchetto di conformità di organizzazione dall’amministratore delegato si rivolge a OU specifiche — ad esempio, applicando un pacchetto più restrittivo alla OU Prod rispetto alla OU Sandbox. Questo è il modo più efficiente per applicare una baseline coerente su centinaia di account, perché una singola chiamata API propaga l’insieme di regole e i relativi collegamenti per la remediation ovunque e in una sola volta.

Resources:
  EncryptedVolumesRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: encrypted-volumes
      Source:
        Owner: AWS
        SourceIdentifier: ENCRYPTED_VOLUMES
  EncryptedVolumesRemediation:
    Type: AWS::Config::RemediationConfiguration
    Properties:
      ConfigRuleName: encrypted-volumes
      TargetType: SSM_DOCUMENT
      TargetId: AWSConfigRemediation-EncryptS3BucketVolume
      Automatic: true
      MaximumAutomaticAttempts: 3
      RetryAttemptSeconds: 60

Pattern di Remediation Automatica

Esistono due percorsi di remediation canonici, e la scelta tra di essi dipende dai requisiti di latenza e complessità.

Il percorso di remediation nativa di Config utilizza AWS::Config::RemediationConfiguration per invocare un runbook di SSM Automation ogni volta che una regola riporta lo stato NON_COMPLIANT. AWS fornisce runbook predefiniti come AWS-EnableVPCFlowLogs, AWSConfigRemediation-RemoveUnrestrictedSourceIngressRules e AWSConfigRemediation-EncryptSNSTopic. Questo percorso è dichiarativo, si integra in modo pulito con i pacchetti di conformità ed è ideale quando un ritardo di diversi minuti è accettabile.

Il percorso guidato da EventBridge è necessario quando la latenza è importante o quando è richiesta un’orchestrazione personalizzata. Config emette un evento Config Rules Compliance Change a ogni transizione di stato. Una regola di EventBridge filtra su detail.newEvaluationResult.complianceType = NON_COMPLIANT e ha come target una funzione Lambda (o una Step Function, o direttamente un runbook di SSM). Poiché EventBridge si attiva entro pochi secondi dalla valutazione, diventano fattibili finestre di remediation inferiori al minuto.

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["restricted-ssh"],
    "newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] }
  }
}

L’handler Lambda chiama quindi RevokeSecurityGroupIngress sull’SG non conforme. Qualunque percorso si scelga, l’automazione deve assumere un ruolo IAM con i permessi minimi per modificare la risorsa target. Una modalità di fallimento frequente è una regola di Config il cui stato di conformità alterna indefinitamente tra NON_COMPLIANT e COMPLIANT perché il runbook di remediation riceve un errore AccessDenied — Config registra l’invocazione ma procede silenziosamente. Ispezionare sempre la cronologia di esecuzione di SSM Automation e concedere al ruolo del runbook i permessi di modifica specifici di cui ha bisogno (ad esempio, ec2:CreateFlowLogs, iam:PassRole per il ruolo di consegna dei flow-log e logs:CreateLogGroup).

Systems Manager Automation e Patch Manager

I runbook di SSM Automation sono il cavallo di battaglia per la remediation imperativa. Sono documenti YAML/JSON versionati che descrivono i passaggi — chiamate API, approvazioni, ramificazioni — eseguiti da un ruolo IAM specificato dall’utente. Oltre alla remediation attivata da Config, eseguono attività di manutenzione pianificate: ruotare le chiavi di accesso, taggare i volumi EBS non collegati o terminare le istanze arrestate dopo 30 giorni.

Patch Manager è un sottosistema di SSM che mantiene i sistemi operativi conformi a una patch baseline (un insieme di patch approvate, classificazioni e filtri di gravità). Le istanze sono raggruppate in patch group tramite il tag Patch Group; una finestra di manutenzione pianifica l’esecuzione del documento AWS-RunPatchBaseline su di esse. Lo stato di conformità ritorna a Config e Security Hub, chiudendo il cerchio tra lo stato a livello di sistema operativo e il reporting a livello di organizzazione.

Service Catalog, CloudFormation StackSets e Guardrail preventivi

Il rilevamento e la remediation sono reattivi. Per prevenire la non conformità, utilizzare controlli preventivi:

Service Catalog pubblica template CloudFormation curati e parametrizzati come prodotti. Gli sviluppatori avviano pattern approvati (una VPC con hardening, un cluster RDS crittografato) senza necessitare di permessi IAM per i servizi sottostanti, il che impone la separazione dei compiti (separation of duties) tra il team della piattaforma e i consumatori.
CloudFormation StackSets distribuisce stack identici tra account e Regioni. Con permessi gestiti dal servizio (service-managed) e il targeting per OU, una singola operazione installa registratori di Config, ruoli IAM o rilevatori di GuardDuty in ogni account dell’organizzazione, inclusi quelli appena creati, tramite la distribuzione automatica.
Le Service Control Policies (SCP) sono l’unico meccanismo in grado di negare esplicitamente una chiamata API al confine dell’organizzazione. Config e SSM non possono impedire una chiamata RunInstances priva di crittografia; possono solo rilevarla e correggerla in un secondo momento. Tentare di imporre divieti assoluti (“mai bucket S3 pubblici”) unicamente con le regole di Config lascia una finestra temporale tra la creazione della risorsa e la remediation. Abbinare una regola di rilevamento di Config a un SCP, come il diniego di s3:PutBucketPublicAccessBlock, per colmare questa lacuna.

Disaster Recovery: Backup, Template e Controllo di Versione

Rispettare gli obiettivi di RPO/RTO richiede che sia i dati sia le definizioni dell’infrastruttura siano recuperabili. AWS Backup centralizza le policy di backup per EBS, RDS, DynamoDB, EFS e FSx; le policy di backup a livello di organizzazione applicano i piani a tutti gli account membri, e le copie cross-Region e cross-account proteggono dalla perdita di una Regione e dalla compromissione di un account. L’RPO è definito dalla frequenza dei backup; l’RTO dipende dai meccanismi di ripristino (un ripristino PITR di DynamoDB richiede minuti; un ripristino di uno snapshot RDS tra Regioni può richiedere un’ora).

Il ripristino dell’infrastruttura si basa su template CloudFormation archiviati in CodeCommit (o un altro provider Git) come unica fonte di verità (single source of truth). La ridistribuzione di uno StackSet da template sotto controllo di versione ricostruisce VPC, IAM e stack applicativi in una Regione di ripristino in pochi minuti. Mantenere i template solo nella console, senza un repository, rende l’RTO imprevedibile perché non esiste un artefatto riproducibile.

Analisi delle Trappole

Tre malintesi portano costantemente a risposte errate. Primo, trattare Config come un controllo preventivo: esso valuta dopo che CloudTrail ha registrato la modifica, quindi i divieti effettivi richiedono gli SCP. Secondo, configurare la remediation senza un ruolo IAM con uno scope adeguato: il documento SSM esiste e la regola di Config si attiva, ma il runbook fallisce silenziosamente per errori di permesso. Terzo, eseguire servizi a livello di organizzazione dall’account di gestione invece di registrare un amministratore delegato, il che forza l’abilitazione manuale per ogni account e impedisce agli aggregatori a livello di organizzazione di funzionare correttamente.

Problema Pratico: Scenario d’Uso

Scenario: Meridian Financial gestisce un ambiente AWS multi-account con account separati per produzione, sviluppo e sicurezza sotto AWS Organizations. Il team di sicurezza deve dimostrare la conformità continua ai controlli interni e alle normative, gestendo centinaia di istanze EC2, bucket S3 e funzioni Lambda in più regioni.

Sfida: Un audit recente ha rilevato istanze EC2 senza patch, bucket S3 pubblici e un’applicazione incoerente delle baseline tra gli account; la remediation è manuale e lenta, e i controlli preventivi non sono applicati in modo uniforme.

Approccio Raccomandato:

Designare l’account di Sicurezza come amministratore delegato di AWS Config e distribuire un AWS Config Aggregator tramite CloudFormation StackSets per raccogliere i dati di configurazione e conformità da tutti gli account e le regioni.
Distribuire Conformance Pack di AWS Config a livello di organizzazione dall’account di sicurezza (usando StackSets) per codificare i controlli di baseline (accesso pubblico S3, crittografia, tagging) in modo che le stesse regole si applichino in modo coerente.
Associare azioni di remediation automatiche di AWS Config alle regole ad alto rischio che invocano documenti di AWS Systems Manager Automation (registrati come runbook di remediation) in modo che le violazioni attivino automaticamente la remediation tramite SSM Automation o Run Command.
Utilizzare AWS Systems Manager Patch Manager con le Patch Baseline di SSM e State Manager per definire gruppi di patch e automatizzare l’applicazione delle patch del sistema operativo tra gli account; inviare i risultati di conformità delle patch al Config Aggregator.
Pubblicare template CloudFormation approvati in AWS Service Catalog e usare CloudFormation StackSets per distribuire o aggiornare stack conformi; imporre guardrail preventivi con le Service Control Policies di AWS Organizations per bloccare la creazione di risorse non consentite (ad esempio, disabilitando la creazione di bucket S3 pubblici).
Configurare Amazon EventBridge (CloudWatch Events) e SNS per notificare il team di sicurezza in caso di non conformità e per attivare ulteriori flussi di lavoro di SSM Automation per incidenti complessi.

Logica: Centralizzare il rilevamento con Config Aggregator e i conformance pack, automatizzare la remediation tramite SSM e imporre guardrail preventivi tramite Service Catalog/StackSets e SCP fornisce controlli coerenti e verificabili e una remediation rapida, in linea con le best practice di AWS per la sicurezza, la conformità e il principio del privilegio minimo (least privilege).

← Sicurezza perimetrale e delle applicazioni · Tutti i domini · Vulnerabilità →

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

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

Supera l'esame →

Sfoglia Amazon →