Amazon SAA-C03: Sicurezza, IAM, KMS e Governance — Guida allo studio

By Laurynas Brazys · 17 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Fa parte della AWS SAA-C03 — Guida di studio completa. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Fondamenti dell’Identità: Utenti, Root, Gruppi e Ruoli

Identity and Access Management è il piano di controllo (control plane) attraverso cui passa ogni workload, e il suo principio guida è quello del privilegio minimo (least privilege): concedere solo ciò che è necessario, solo per il tempo necessario, e preferire identità che producono credenziali a breve termine rispetto a quelle che detengono segreti statici.

L’utente root è il proprietario dell’account, detiene permessi illimitati e non può essere limitato da policy IAM o SCP. Questo lo rende la credenziale più sensibile dell’intero ambiente, e dovrebbe essere trattata come una credenziale di emergenza (break-glass). Su un nuovo account: abilitare un dispositivo MFA hardware o virtuale per l’utente root, impostare una password lunga e unica, rimuovere eventuali access key storiche dell’utente root e registrare contatti alternativi per la fatturazione, le operazioni e la sicurezza in modo da rendere possibile il ripristino. Dopo la configurazione iniziale — creazione di un’identità IAM amministrativa, configurazione della fatturazione e impostazione dell’alias dell’account — l’utente root non viene più utilizzato, se non per il ristretto insieme di attività per cui AWS lo richiede esplicitamente (chiusura dell’account, modifica del nome dell’account, ripristino di permessi IAM cancellati, abilitazione di MFA Delete e una manciata di operazioni su S3/CloudFront che richiedono una firma root). Utilizzare l’utente root per le operazioni quotidiane è sbagliato perché non può essere limitato da policy, è difficile da attribuire in CloudTrail quando condiviso, e una singola compromissione garantisce un controllo irrevocabile.

L’accesso quotidiano da parte di persone avviene tramite identità IAM limitate da policy di privilegio minimo. Associare le policy gestite ai gruppi, non ai singoli utenti: un gruppo Administrators con la policy AdministratorAccess associata, e gli utenti nominativi inseriti al suo interno, produce un unico punto di modifica ed evita l’anti-pattern di copiare policy identiche su ogni utente. Limitare l’ambito delle risorse con ARN espliciti anziché con *.

I ruoli (role) hanno uno scopo completamente diverso. Vengono assunti da principal — servizi, istanze EC2, funzioni Lambda, utenti federati, chiamate cross-account — e producono credenziali STS temporanee che vengono rinnovate automaticamente. Poiché tali credenziali non possono trapelare in un commit Git e scadono in minuti o ore anziché persistere fino a una rotazione manuale, i ruoli sono l’identità predefinita per qualsiasi entità non umana.

Due Policy per ogni Ruolo: Permessi e Fiducia (Trust)

Ogni ruolo è governato da due documenti indipendenti, e dimenticarne uno è un classico errore.

La policy di permessi (basata sull’identità) dichiara cosa può fare il ruolo una volta assunto. La policy di fiducia (basata sulla risorsa, associata al ruolo stesso) dichiara chi può assumerlo. Associare AmazonS3ReadOnlyAccess a un ruolo non serve a nulla se nessun principal è autorizzato a chiamare sts:AssumeRole su di esso e, viceversa, una policy di fiducia permissiva senza una policy di permessi produce un ruolo che può essere assunto ma non può eseguire alcuna operazione utile.

Un ruolo di esecuzione Lambda (execution role) mostra il pattern del service-principal — è il servizio stesso, non il proprietario dell’account, ad essere il chiamante:

AssumeRolePolicyDocument:              # trust policy
  Version: "2012-10-17"
  Statement:
    - Effect: Allow
      Principal: { Service: lambda.amazonaws.com }
      Action: sts:AssumeRole
Policies:                              # permissions
  - PolicyName: ReadOrders
    PolicyDocument:
      Statement:
        - Effect: Allow
          Action: dynamodb:GetItem
          Resource: arn:aws:dynamodb:*:*:table/Orders

Identità per i Workload: Instance Profile, Task Role, IRSA, Roles Anywhere

Ogni credenziale che risiede in un template, in una variabile d’ambiente o su un laptop è una futura violazione della sicurezza. Il pattern canonico di AWS sostituisce le access key statiche con credenziali a breve termine, rinnovate automaticamente, fornite tramite i ruoli.

Per EC2, il meccanismo di fornitura è l’instance profile — un contenitore leggero che lega un ruolo IAM a un’istanza in modo che l’Instance Metadata Service (IMDSv2) possa distribuire credenziali temporanee all’SDK. La catena di provider di credenziali predefinita le trova senza alcuna configurazione, quindi boto3.client('s3') funziona direttamente e il codice dell’applicazione non vede mai una credenziale. È necessario imporre l’uso di IMDSv2 (HttpTokens: required) per contrastare l’esfiltrazione di credenziali basata su SSRF. Le credenziali vengono rinnovate circa ogni sei ore, e la revoca si ottiene con una semplice modifica del ruolo.

AppRole:
  Type: AWS::IAM::Role
  Properties:
    AssumeRolePolicyDocument:
      Statement:
        - Effect: Allow
          Principal: { Service: ec2.amazonaws.com }
          Action: sts:AssumeRole
    Policies:
      - PolicyName: S3DocAccess
        PolicyDocument:
          Statement:
            - Effect: Allow
              Action: [s3:GetObject, s3:PutObject]
              Resource: arn:aws:s3:::docs-bucket/*
AppInstanceProfile:
  Type: AWS::IAM::InstanceProfile
  Properties:
    Roles: [!Ref AppRole]

Per ECS l’analogo è il task role; per Lambda è l’execution role; per i pod EKS è IRSA (IAM Roles for Service Accounts) o EKS Pod Identity. In ogni caso, è AWS stesso a mediare le credenziali rispetto a un ruolo e il workload non vede mai un segreto a lunga durata.

Incorporare (baking) le access key in una AMI, in uno script user-data o in un file .env è sbagliato per tre motivi concreti: le chiavi non vengono mai rinnovate automaticamente, non possono essere limitate al contesto della sessione come un VPC endpoint di origine, e se l’istanza viene compromessa o una AMI viene condivisa inavvertitamente, la credenziale trapela in modo permanente.

Per i workload al di fuori di AWS — server on-premise, altri cloud, CI runner — che necessitano di credenziali AWS temporanee senza chiavi incorporate, IAM Roles Anywhere utilizza certificati X.509 provenienti da una CA privata (AWS Private CA o una propria) come ancora di fiducia (trust anchor). Il workload presenta il suo certificato client e riceve credenziali STS a breve termine:

aws_signing_helper credential-process \
  --certificate /etc/pki/client.pem \
  --private-key /etc/pki/client.key \
  --trust-anchor-arn arn:aws:rolesanywhere:...:trust-anchor/... \
  --profile-arn arn:aws:rolesanywhere:...:profile/... \
  --role-arn arn:aws:iam::111122223333:role/OnPremWorkload

Questo risolve lo stesso anti-pattern che gli instance role e Secrets Manager risolvono all’interno di AWS.

Accesso Umano su Larga Scala: Identity Center, SAML, Directory Service

Il provisioning di utenti IAM per ogni singolo account, su qualsiasi scala, è ingestibile. AWS IAM Identity Center (successore di AWS SSO) è la porta d’accesso consigliata per la forza lavoro (workforce): una singola directory che si federa in ogni account di un’Organization ed emette sessioni temporanee basate su ruoli tramite i permission set — ruoli IAM pre-configurati (templated) mappati a gruppi dell’IdP. Gli utenti si autenticano una sola volta nel portale di Identity Center, per poi assumere i permission set in qualsiasi account a cui sono stati assegnati.

Identity Center si integra con IdP esterni (Okta, Entra ID/Azure AD, Google Workspace, ADFS) tramite SAML 2.0 e SCIM per flussi automatizzati di joiner/mover/leaver, e con Active Directory on-premise tramite AWS Directory Service AD Connector (un proxy) o AWS Managed Microsoft AD (una replica completa in AWS). Per le app mobili o web che devono chiamare AWS da parte di utenti non autenticati o autenticati da terze parti, Amazon Cognito scambia l’identità esterna con credenziali STS temporanee, evitando ancora una volta le chiavi a lunga durata incorporate.

Accesso Cross-Account

L’accesso cross-account si realizza tramite ruoli, non con utenti condivisi, ed entrambe le parti devono essere d’accordo. L’account di destinazione (B) crea un ruolo la cui policy di trust nomina l’Account A (o un principal specifico al suo interno), e il chiamante nell’Account A deve anche avere il permesso sts:AssumeRole che punta all’ARN di quel ruolo. Nessuna delle due parti da sola è sufficiente. Questo produce credenziali a breve termine e una chiara traccia di audit in CloudTrail in entrambi gli account.

Quando un’entità terza (un fornitore SaaS) è il principal che assume il ruolo, aggiungere una condizione ExternalId per sconfiggere il problema del “confused deputy” e considerare di richiedere l’MFA:

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::222222222222:root" },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": { "sts:ExternalId": "a1b2c3-unique-token" },
    "Bool": { "aws:MultiFactorAuthPresent": "true" }
  }
}

Per le invocazioni cross-account da servizio a servizio, il lavoro viene svolto dalle policy di risorsa. Per consentire a un topic SNS nell’Account A di invocare una Lambda nell’Account B:

aws lambda add-permission \
  --function-name ProcessNotification \
  --statement-id AllowSNSInvoke \
  --action lambda:InvokeFunction \
  --principal sns.amazonaws.com \
  --source-arn arn:aws:sns:us-east-1:111111111111:my-topic

Il --principal sns.amazonaws.com è il service principal (SNS stesso invoca la Lambda), e --source-arn limita la fiducia a un topic specifico per prevenire il problema del “confused deputy”.

Per la condivisione S3 all’interno di un’Organization, l’approccio ingenuo — elencare ogni ARN di account nella policy del bucket — non è scalabile e si rompe ogni volta che viene aggiunto un nuovo account. Il pattern corretto è aws:PrincipalOrgID:

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports-bucket/*",
  "Condition": {
    "StringEquals": { "aws:PrincipalOrgID": "o-abcd1234ef" }
  }
}

Qualsiasi principal in qualsiasi account di quell’organizzazione è autorizzato; chiunque altro viene negato. Si noti che Principal: "*" senza la condizione renderebbe il bucket pubblico — è la chiave di condizione che limita l’ambito. Anche il lato dell’identità è importante: gli utenti negli account membri necessitano anche del permesso s3:GetObject concesso dalla propria policy IAM (a meno che non siano l’utente root dell’account), perché l’accesso cross-account richiede che entrambe le parti autorizzino la chiamata.

Specificamente per S3, dal 2023 l’impostazione predefinita di Object Ownership Proprietario del bucket applicato disabilita completamente le ACL, rendendo le policy di bucket l’unico meccanismo di autorizzazione per il bucket. Quando gli oggetti sono stati caricati in precedenza da altri account, le ACL storiche degli oggetti o la canned ACL bucket-owner-full-control potrebbero essere ancora in gioco.

Organizations e Service Control Policies

AWS Organizations aggrega gli account in un albero di OU con un account di gestione (management account) alla radice. Le Service Control Policies sono dei guardrail applicati alla radice, a una OU o a un singolo account. Si applicano a ogni utente e ruolo IAM nell’account — incluso l’utente root dell’account — ma non all’account di gestione stesso, motivo per cui i carichi di lavoro non dovrebbero mai essere eseguiti lì.

Il modello mentale critico: le SCP non concedono mai permessi. Definiscono l’insieme massimo di azioni permesse in un account. Un’azione è consentita solo se è concessa da una policy di identità o di risorsa e non è bloccata da nessuna SCP nel percorso dell’account. Se uno sviluppatore ha AdministratorAccess ma una SCP nega ec2:RunInstances al di fuori di ap-southeast-2, il lancio in us-east-1 fallirà. Al contrario, una SCP che permette s3:* non fa nulla da sola — l’utente ha comunque bisogno di una policy IAM che conceda s3:*. Le SCP filtrano ciò che IAM ha già permesso; sono dei massimali, non dei permessi di base.

Gli usi tipici delle SCP includono il blocco di region, il divieto di disabilitare CloudTrail o GuardDuty, il divieto di eliminare chiavi KMS al di fuori di un ruolo “break-glass” e l’imposizione della crittografia. Per forzare la crittografia dei volumi EBS al momento del lancio, si combinano due meccanismi: abilitare la crittografia EBS di default nella region (un’impostazione a livello di account per region, in modo che gli utenti non debbano modificare gli script), più una SCP come guardrail verificabile:

{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Resource": "arn:aws:ec2:*:*:volume/*",
  "Condition": { "Bool": { "ec2:Encrypted": "false" } }
}

Poiché le SCP si applicano all’intero account, non possono essere aggirate da un amministratore compromesso in un account membro. Le Tag policies impongono la standardizzazione delle chiavi e del “case” dei tag (CostCenter, non costcenter) in modo che l’allocazione dei costi e l’ABAC funzionino in modo affidabile. Organizations supporta anche l’amministrazione delegata: invece di eseguire i servizi di sicurezza dall’account di gestione, si delega un account membro (ad esempio “security” o “audit”) come amministratore per GuardDuty, Security Hub, IAM Access Analyzer o Config, preservando la separazione dei compiti.

KMS: Chiavi, policy delle chiavi e modelli di proprietà

KMS distingue il materiale della chiave in base alla proprietà e al controllo:

Una CMK è governata da una policy della chiave — una policy basata sulla risorsa collegata alla chiave. A differenza di quasi ogni altra risorsa AWS, le policy IAM da sole non possono concedere l’accesso a una chiave KMS a meno che la policy della chiave non deleghi prima a IAM:

{
  "Sid": "EnableIAMPolicies",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
  "Action": "kms:*",
  "Resource": "*"
}

Senza questa dichiarazione (statement), nessuna policy IAM rende la chiave utilizzabile. Sia la policy della chiave sia la policy IAM del chiamante devono consentire l’operazione: questo è l’errore di crittografia più frequente in assoluto. Concedere kms:Decrypt in una policy IAM è necessario ma non sufficiente; se la policy della chiave non delega a IAM o non nomina il principal, la decrittografia fallisce con AccessDenied anche per un amministratore.

Per i servizi che utilizzano KMS per tuo conto (EBS, S3, RDS, Lambda), il ruolo chiamante necessita tipicamente di kms:GenerateDataKey, kms:Decrypt e spesso kms:CreateGrant. Per un gruppo di nodi gestito di EKS che crittografa volumi EBS con una CMK, il ruolo collegato al servizio (service-linked role) di Auto Scaling deve comparire nella policy della chiave con kms:CreateGrant, altrimenti l’avvio delle istanze fallisce silenziosamente.

La rotazione delle CMK gestite dal cliente richiede un’abilitazione esplicita: molti professionisti presumono erroneamente che tutte le chiavi KMS ruotino automaticamente:

aws kms enable-key-rotation --key-id alias/my-cmk
aws kms get-key-rotation-status --key-id alias/my-cmk

La rotazione preserva lo stesso ID e alias della chiave; il materiale di supporto (backing material) cambia, ma il testo cifrato precedente rimane decifrabile perché KMS conserva il vecchio materiale per decifrare i testi cifrati esistenti, mentre le nuove scritture utilizzano materiale nuovo. Il materiale importato non ruota mai automaticamente. KMS impone una finestra di eliminazione in sospeso obbligatoria da 7 a 30 giorni; abbina questa funzionalità a una regola EventBridge che corrisponda a ScheduleKeyDeletion o DisableKey in CloudTrail e indirizzala a un topic SNS per un modello di allerta serverless e senza polling:

{
  "source": ["aws.kms"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": { "eventName": ["ScheduleKeyDeletion", "DisableKey"] }
}

Gli External Key Store estendono il modello quando le normative richiedono che il materiale della chiave risieda fisicamente in un HSM controllato dal cliente. KMS inoltra le operazioni crittografiche a un proxy XKS che comunica con l’HSM on-premise; se l’HSM è offline, la decrittografia fallisce: la disponibilità diventa responsabilità del cliente.

Le chiavi multi-regione (MRK) condividono lo stesso ID e materiale della chiave tra più Regioni, quindi un testo cifrato prodotto in us-east-1 può essere decifrato direttamente in eu-west-1. Questo è il pattern corretto per le tabelle globali di DynamoDB, la replica tra regioni (Cross-Region Replication) di S3 con SSE-KMS e scenari di DR in cui una Regione di standby deve leggere backup crittografati. Le chiavi standard a singola Regione richiederebbero una decrittografia seguita da una nuova crittografia al momento della replica.

Condivisione di risorse crittografate tra account

La condivisione di AMI e snapshot EBS crittografati è una delle modalità di fallimento più comuni tra account perché richiede quattro azioni coordinate: (1) usare una CMK gestita dal cliente — le chiavi gestite da AWS non possono essere condivise; (2) aggiungere l’account di destinazione come principal nella policy della chiave con kms:Decrypt, kms:DescribeKey, kms:CreateGrant e kms:ReEncrypt*; (3) modificare i permessi di avvio/condivisione dell’AMI o dello snapshot per includere tale account; e (4) assicurarsi che anche il principal IAM nell’account di destinazione disponga di tali azioni KMS. L’operazione di condivisione sembra avere successo se si salta il passaggio 2, ma l’account ricevente non può decifrare. Presumere che la sola condivisione dell’AMI sia sufficiente è la trappola classica.

Modalità di crittografia lato server (Server-Side Encryption) di S3

Quando un requisito specifica rotazione annuale automatica, verificabilità su CloudTrail e minimizzazione dei costi della chiave, la risposta è SSE-KMS con la chiave aws/s3 gestita da AWS: ruota annualmente senza costi e ogni chiamata GenerateDataKey/Decrypt viene registrata. SSE-S3 è più economico ma non lascia traccia dell’utilizzo della chiave. Una CMK gestita dal cliente aggiunge un costo di $1/mese e ruota solo se si abilita la rotazione.

Confondere SSE-S3 e SSE-KMS è la classica trappola quando si trattano dati sensibili (PHI). SSE-S3 crittografa i dati ma non offre una policy della chiave, nessuna visibilità su CloudTrail e nessun modo per un team di conformità di amministrare la chiave; pertanto, non soddisfa alcun requisito che menzioni “amministrare”, “controllare”, “verificare” o “revocare l’accesso” alla chiave. Al contrario, scegliere SSE-KMS quando il requisito è solo “crittografare a riposo con gestione minima” è una complicazione eccessiva (over-engineering).

L’abilitazione di SSE-KMS non impedisce di per sé letture non autorizzate. Se la policy del bucket consente s3:GetObject e la policy della chiave concede kms:Decrypt allo stesso principal, l’oggetto è leggibile. La crittografia a riposo (at rest) protegge dalla compromissione dei supporti fisici e aggiunge un secondo controllo di autorizzazione tramite la policy della chiave; non sostituisce policy del bucket, policy IAM, policy degli endpoint VPC e condizioni aws:PrincipalOrgID definite con un ambito corretto.

Applicare la crittografia e il TLS su S3

Rendere un bucket “crittografato di default” non è sufficiente: i client possono omettere o sovrascrivere l’header di crittografia. È necessario sovrapporre due meccanismi di protezione (guardrail): la crittografia di default del bucket (che compila l’header se il client lo omette) e una bucket policy basata su “deny” che rifiuti le chiamate PutObject senza l’header richiesto, più una dichiarazione (statement) che neghi l’accesso non-TLS:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnEncryptedObjectUploads",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::phi-bucket/*",
      "Condition": {
        "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
      }
    },
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::phi-bucket", "arn:aws:s3:::phi-bucket/*"],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    }
  ]
}

La condizione aws:SecureTransport forza l’uso di HTTPS, soddisfacendo il requisito di “crittografia in transito” (encrypted in transit). Combinato con SSE-KMS utilizzando una CMK di proprietà del team di compliance, questo è il pattern canonico per l’archiviazione di dati PHI.

Crittografia in transito (in transit) vs. a riposo (at rest)

La crittografia a riposo (EBS crittografato con KMS, storage RDS, oggetti S3) e la crittografia in transito (TLS sul canale di comunicazione) sono controlli indipendenti che affrontano minacce diverse: il furto di dischi contro l’intercettazione di rete. Abilitare KMS su un’istanza RDS protegge lo storage sottostante; non fa nulla per una sessione client-database, che di default potrebbe non essere crittografata. Per RDS MySQL, la protezione in transito richiede di scaricare il bundle CA di RDS, impostare require_secure_transport=ON nel parameter group e connettere i client con --ssl-ca=rds-combined-ca-bundle.pem. Considerare sufficiente la “crittografia a riposo” è un errore frequente riscontrato negli audit.

Secrets Manager e Parameter Store

Le password statiche dei database in file di configurazione, variabili d’ambiente o parametri di CloudFormation sono il principale vettore di fuga di credenziali. AWS Secrets Manager archivia i segreti crittografati con KMS, li espone tramite la chiamata GetSecretValue controllata da IAM e, aspetto fondamentale, li ruota automaticamente tramite una funzione Lambda di rotazione. Per RDS, Aurora, Redshift e DocumentDB, AWS fornisce una Lambda di rotazione gestita che si connette al database, genera una nuova password, aggiorna atomicamente sia il segreto che l’utente del DB e supporta strategie a utente singolo o multi-utente. Per altri sistemi, è necessario creare una Lambda che implementi il ciclo di vita in quattro fasi: createSecret, setSecret, testSecret, finishSecret.

import boto3, json
secret = json.loads(
    boto3.client('secretsmanager')
         .get_secret_value(SecretId='prod/aurora/app')['SecretString'])
conn = pymysql.connect(host=secret['host'],
                       user=secret['username'],
                       password=secret['password'])

Le applicazioni mettono in cache il valore per un breve periodo (usando la libreria di caching dell’AWS SDK) e si riconnettono in caso di fallimento dell’autenticazione. La rotazione è invisibile e non è necessario alcun deployment per cambiare una password.

SSM Parameter Store SecureString è l’alternativa quando la rotazione non è richiesta e il costo è il fattore dominante:

Chi recupera un parametro SecureString necessita sia del permesso ssm:GetParameter sia di kms:Decrypt sulla chiave. Dimenticare il permesso per KMS è una delle errate configurazioni più comuni: la policy IAM sembra corretta, ma la chiamata API fallisce in fase di decrittografia.

Su EC2, ECS, EKS e Lambda, il codice dovrebbe assumere un ruolo IAM e chiamare GetSecretValue o GetParameter; nessuna credenziale a lunga durata deve essere presente su disco. Incorporare le access key di un utente IAM direttamente nel codice dell’applicazione, anche se crittografate, viola il principio del privilegio minimo (least privilege) e complica la rotazione.

Strumenti di Audit e Analisi Forense

CloudTrail registra ogni chiamata API AWS: chi, cosa, quando, da dove. Un organization trail, abilitato dall’account di gestione, cattura gli eventi di tutti gli account in un unico bucket S3, idealmente in un account di sicurezza blindato (locked-down) con S3 Object Lock e MFA Delete. Questo fornisce una timeline forense immutabile: quale principal ha cancellato un volume, quale ruolo ha modificato un security group, quale access key ha chiamato ec2:RunInstances alle 03:17 UTC. Va integrato con i log e gli allarmi di CloudWatch (login dell’utente root, modifiche alle policy IAM) e con AWS Config per lo stato delle risorse point-in-time e i conformance pack. Impedire la manomissione con una SCP che neghi le azioni cloudtrail:StopLogging e cloudtrail:DeleteTrail.

MFA Delete su un bucket S3 obbliga l’utente root a presentare un token MFA per eliminare permanentemente la versione di un oggetto o per disabilitare il versioning. Può essere abilitato solo dall’utente root tramite la CLI e fornisce una forte protezione contro ransomware e cancellazioni da parte di insider.

Amazon Macie utilizza il machine learning (ML) gestito per scoprire dati PII, PHI, credenziali e dati finanziari in S3, producendo risultati (finding) classificati per gravità. È uno strumento di scoperta, non uno strumento di crittografia.

Rilevamento delle minacce: GuardDuty, Security Hub, Detective

Amazon GuardDuty analizza continuamente i VPC Flow Logs, i log DNS e gli eventi di gestione e dati di CloudTrail, con piani di protezione dedicati per i log di audit di EKS, gli eventi dati di S3, le scansioni malware di EBS, l’attività di rete di Lambda e gli eventi di login di RDS. La funzionalità RDS Protection di GuardDuty fa emergere tentativi di autenticazione anomali o di tipo brute-force contro Aurora e RDS, un comportamento che un security group non può intercettare perché la connessione è legittima a livello L4. I risultati (finding) confluiscono nelle dashboard di EventBridge, Security Hub e Detective.

I security group operano solo a livello L3-L4. Un gruppo che permette 0.0.0.0/0 sulla porta 443 sta facendo il suo lavoro quando inoltra un payload di SQL injection: è proprio questo che WAF è progettato per fermare. La difesa in profondità (defense in depth) significa usare security group più WAF più Shield più GuardDuty, dove ciascuno copre un livello che gli altri non possono vedere.

DDoS: Shield Standard e Advanced

AWS Shield Standard è automatico e gratuito, difende ogni account da attacchi comuni di livello L3/L4 (SYN flood, attacchi di reflection). Funziona in modo silenzioso senza visibilità, senza mitigazioni personalizzate e senza un percorso di intervento umano.

AWS Shield Advanced (3.000 $/mese per organizzazione più il trasferimento dati) è richiesto ogni volta che lo scenario menziona coinvolgimento proattivo, risposta dedicata, protezione dei costi contro il dimensionamento indotto da DDoS, o visibilità quasi in tempo reale degli attacchi. Copre CloudFront, Global Accelerator, ALB, CLB, Route 53 e gli IP Elastici, e fornisce accesso 24/7 allo Shield Response Team (SRT) — pre-autorizzato tramite un ruolo IAM — per scrivere regole WAF per tuo conto durante un attacco attivo. Quando un’architettura dietro un ALB e Route 53 necessita di rilevamento gestito e risposta umana, Shield Standard da solo è insufficiente; questa è la trappola ricorrente. Advanced garantisce anche la protezione dei costi per il dimensionamento innescato dagli attacchi. Quando viene menzionato “MINIMO sforzo di implementazione” e l’architettura include già Global Accelerator o un ALB, la risposta è tipicamente abilitare Shield Advanced e collegare i gruppi di regole WAF gestiti da AWS, non creare Lambda@Edge personalizzate o migrare la CDN.

Protezione a Livello Applicativo: AWS WAF

AWS WAF si collega a CloudFront, Application Load Balancer, API Gateway, AppSync, App Runner e ai pool di utenti di Cognito. Non protegge direttamente i Network Load Balancer (posizionare CloudFront davanti). Ispeziona il traffico L7 e applica regole per SQL injection, XSS, vincoli di dimensione, geo-blocking, reputazione IP e rate limiting. Le AWS Managed Rules forniscono gruppi di regole predefinite come AWSManagedRulesCommonRuleSet e AWSManagedRulesSQLiRuleSet senza dover scrivere espressioni regolari.

Le regole basate sulla frequenza (rate-based) sono la difesa principale contro gli attacchi di tipo HTTP flood e credential stuffing — contano le richieste in una finestra di cinque minuti per indirizzo IP di origine (o per header inoltrato) e bloccano automaticamente i trasgressori:

Rules:
  - Name: RateLimitPerIP
    Priority: 1
    Statement:
      RateBasedStatement:
        Limit: 2000        # per 5-min window per IP
        AggregateKeyType: IP
    Action: { Block: {} }
    VisibilityConfig:
      CloudWatchMetricsEnabled: true
      MetricName: RateLimitPerIP
      SampledRequestsEnabled: true

WAF non è un servizio DDoS — quello è il ruolo di Shield. WAF integra le policy delle risorse (policy dei bucket S3 che negano il traffico non-TLS, policy degli endpoint VPC che limitano i bucket raggiungibili) e i controlli di rete (security group, NACL) — una configurazione errata a un singolo livello non deve esporre i dati.

Isolamento di Rete: Security Group, NACL, Network Firewall

All’interno di un VPC, la difesa è stratificata:

• I Security group sono stateful, si applicano alle ENI, consentono solo regole di tipo ‘allow’ e valutano tutte le regole insieme. Il traffico di ritorno è permesso automaticamente, quindi non è necessario aprire esplicitamente le porte effimere.
• Le Network ACL (NACL) sono stateless, si applicano alle subnet, supportano sia ‘allow’ che ‘deny’ e vengono valutate in ordine numerico. Poiché sono stateless, se si permette il traffico in entrata sulla porta 443, si deve anche permettere il traffico in uscita sulle porte effimere 1024–65535 per le risposte. Dimenticarsene causa la perdita di tutte le risposte in modi difficili da diagnosticare. I security group non hanno questo problema.
• AWS Network Firewall fornisce ispezione approfondita dei pacchetti (deep packet inspection), regole IPS compatibili con Suricata e filtraggio del traffico in uscita basato su dominio, posizionandosi tra le subnet e gli IGW/TGW per un’ispezione centralizzata.

Presumere che i soli security group siano sufficienti ignora le minacce a livello di subnet e i controlli del raggio d’impatto (blast-radius); presumere che le sole NACL siano sufficienti ignora la loro natura stateless e la loro granularità grossolana.

Catalogo delle Trappole

Policy di attendibilità (trust policy) dimenticata. La policy dei permessi di un ruolo concede capacità; solo la trust policy concede la possibilità di essere assunto (assumability). Entrambe devono essere configurate correttamente affinché l’accesso cross-account o tra servizi funzioni — il chiamante riceve AccessDenied su sts:AssumeRole indipendentemente da quanto sia permissiva la policy di identità.

Policy IAM senza una key policy corrispondente. kms:Decrypt in IAM è necessario ma non sufficiente. La key policy deve o nominare il principal o delegare a IAM con Principal: {"AWS": "arn:aws:iam::ACCOUNT:root"}. La condivisione di AMI/snapshot crittografati fallisce quando viene eseguita solo la condivisione dell’AMI e la key policy non viene aggiornata.

SCP trattate come concessioni di permessi. Le SCP limitano, non concedono mai permessi. Una SCP con Allow s3:* non fa nulla senza una policy di identità corrispondente. Al contrario, una policy di identità permissiva è limitata da qualsiasi SCP con Deny nel percorso dell’account.

Presumere la rotazione automatica delle chiavi KMS. Le CMK gestite dal cliente non ruotano finché la rotazione non viene abilitata; il materiale importato non ruota mai automaticamente.

SSE-S3 scelto per dati soggetti a controlli di conformità. SSE-S3 non ha una key policy, nessuna visibilità in CloudTrail e nessun percorso di revoca — non soddisfa alcun requisito che menzioni “amministrare”, “controllare”, “verificare” (audit) o “revocare” la chiave.

Crittografia a riposo (at rest) considerata sufficiente. A riposo e in transito sono concetti indipendenti. Un’istanza RDS con KMS necessita comunque di require_secure_transport=ON e della validazione della CA del client.

Policy del bucket che nomina gli account individualmente. Non è scalabile e si rompe in caso di modifiche all’organizzazione. Usare aws:PrincipalOrgID.

Chiavi di accesso hardcoded ovunque. Nei dati utente (user data), file .env, parametri di CloudFormation, Git — è sempre sbagliato. Usare instance profile, ruoli di task, ruoli di esecuzione, IRSA/Pod Identity o Roles Anywhere.

Utente root per il lavoro quotidiano o con policy collegate. L’utente root non può essere limitato da IAM o SCP; aggiungere una policy all’utente root è privo di senso. Qualsiasi risposta che lo faccia è palesemente sbagliata.

Utenti IAM per l’accesso cross-account. Gli utenti IAM non possono essere ‘assunti’ cross-account; creare un ruolo nell’account di destinazione e permettere al principal dell’account di origine di assumerlo.

NLB dietro WAF. WAF non si collega agli NLB. Posizionare CloudFront davanti all’NLB se è necessario un filtraggio L7.

NACL senza regola per il traffico effimero in uscita. Le NACL stateless necessitano di regole esplicite per il percorso di ritorno. La mancanza della regola per le porte 1024–65535 in uscita interrompe silenziosamente tutte le risposte al traffico in entrata sulla porta 443.

Shield Standard per un coinvolgimento gestito. Standard è passivo e senza accesso all’SRT; solo Advanced soddisfa i requisiti di “coinvolgimento proattivo gestito” o “protezione dei costi”.

← Integrazione di Applicazioni · Tutti i domini · Gestione →

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

Sfoglia Amazon →