Amazon SCS-C02: Sicurezza dei container e serverless — 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.

ECS Exec e Ispezione Runtime Senza SSH

ECS Exec fornisce una shell interattiva in un container in esecuzione — inclusi i task Fargate — senza esporre SSH, bastion host o IP pubblici. Funziona sfruttando l’agente SSM che AWS inietta nell’ambiente di esecuzione sidecar del task. Poiché non ci sono demoni SSH, materiale crittografico o percorsi di rete in ingresso da proteggere, il sovraccarico operativo è minimo e ogni sessione è verificabile tramite CloudTrail e (opzionalmente) registrata su S3 o CloudWatch Logs.

Perché ECS Exec funzioni, devono essere soddisfatti tre requisiti:

• Permessi del ruolo del task: il ruolo del task (non il ruolo di esecuzione) necessita di ssmmessages:CreateControlChannel, ssmmessages:CreateDataChannel, ssmmessages:OpenControlChannel e ssmmessages:OpenDataChannel. Il ruolo di esecuzione si occupa solo di prelevare le immagini e scrivere i log; il traffico SSM a runtime passa attraverso il ruolo del task perché quella è l’identità assunta dal processo del container.

• Configurazione del servizio o del task: il servizio deve essere creato o aggiornato con --enable-execute-command. Questo flag imposta enableExecuteCommand sui nuovi task; i task esistenti devono essere sostituiti.

• Supporto dell’immagine del container: il container necessita di una shell (/bin/sh o /bin/bash) presente nell’immagine.

Un tipico flusso di ispezione è simile a questo:

aws ecs update-service --cluster prod --service api \
  --enable-execute-command --force-new-deployment

aws ecs execute-command --cluster prod \
  --task 5f8c...c2 --container api \
  --interactive --command "/bin/sh"

Da quella shell, un ingegnere può copiare i log su S3, avviare un heap dump o leggere /proc per analisi forensi. L’alternativa — tentare di raggiungere il container tramite SSH o riavviare il task per abilitare un agente di debug — o fallisce su Fargate o distrugge le prove che si stavano cercando di raccogliere.

Bloccare l’Accesso a IMDS dai Container su EC2

Un malinteso comune è che le impostazioni hop-limit di IMDSv2 sull’istanza EC2 proteggano i container su quella stessa istanza. Non è così, almeno non di default nelle modalità di rete bridge o host: i container condividono il namespace di rete dell’host o un bridge NAT e possono raggiungere 169.254.169.254 e recuperare le credenziali del profilo dell’istanza, che sono tipicamente molto più privilegiate del ruolo del task. Questo vanifica completamente il principio del privilegio minimo.

La soluzione, quando la migrazione a Fargate non è possibile, si compone di due parti:

• Usare la modalità di rete awsvpc per i task. Ogni task ottiene la propria ENI e il proprio namespace di rete. Il traffico IMDS non raggiunge più in modo trasparente l’endpoint link-local dell’host.

• Impostare ECS_AWSVPC_BLOCK_IMDS=true in /etc/ecs/ecs.config sull’istanza del container. Questo indica all’agente ECS di installare una regola iptables che scarta i pacchetti provenienti dai task awsvpc e destinati a 169.254.169.254.

echo 'ECS_AWSVPC_BLOCK_IMDS=true' >> /etc/ecs/ecs.config
systemctl restart ecs

Combina questo approccio con un profilo dell’istanza minimale (essenzialmente solo ciò di cui l’agente ECS ha bisogno: AmazonEC2ContainerServiceforEC2Role) e ruoli IAM per-task per i permessi dell’applicazione. Impostare l’hop limit di IMDS dell’istanza a 1 con IMDSv2 obbligatorio è un’utile misura di difesa in profondità, ma non è un sostituto — i container in modalità bridge possono ancora raggiungere IMDS a hop 1 perché la richiesta ha origine dall’host.

Monitoraggio Runtime di GuardDuty, Protezione EKS e Log del Control Plane

GuardDuty offre un rilevamento a più livelli per i container:

• EKS Protection analizza i log di audit di EKS per rilevare attività sospette sull’API di Kubernetes — accessi anonimi, creazione di pod privilegiati, exec in pod di sistema.

• Runtime Monitoring distribuisce un sensore basato su eBPF (come add-on gestito per EKS, o un agente gestito da SSM per ECS/Fargate) che osserva l’attività di processi, file e rete all’interno dei container. Fa emergere rilevamenti come reverse shell, binari di cryptomining ed esfiltrazione di credenziali dall’interno di un Pod o di un task.

EKS Protection è inutile se i log di audit del control plane di EKS non vengono effettivamente inviati a CloudWatch Logs. Abilita almeno i tipi di log audit e authenticator sul cluster:

aws eks update-cluster-config --name prod \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

Senza di essi, GuardDuty non ha un data plane da ispezionare per i rilevamenti di EKS Protection — una trappola che si presenta di frequente perché gli operatori abilitano la funzionalità di GuardDuty ma lasciano disattivata la configurazione di logging del cluster, per poi chiedersi perché non compaiano rilevamenti relativi a Kubernetes.

Scansione delle Immagini con la Scansione Avanzata di ECR

La Scansione Avanzata (Enhanced Scanning) di ECR è basata su Amazon Inspector e fornisce una scansione continua delle immagini dei container per CVE del sistema operativo e dei pacchetti di linguaggi (Python, Node, Java, Go, Ruby). La scansione di base è una tantum al momento del push e copre solo i pacchetti del sistema operativo; quella avanzata è continua e include le dipendenze dell’applicazione, dove risiede la maggior parte delle vulnerabilità moderne.

I rilevamenti confluiscono automaticamente in Security Hub quando entrambi i servizi sono abilitati, fornendo una visione unificata (single pane of glass) per la conformità e consentendo di scrivere regole EventBridge che causano il fallimento delle build CI/CD. Un tipico modello di applicazione:

Problema Pratico: Scenario d’Uso

Scenario: NovaTech Corp gestisce microservizi rivolti ai clienti su un’infrastruttura di calcolo mista: diversi cluster ECS su EC2, un cluster EKS per l’elaborazione dei dati e funzioni Lambda serverless per la gestione degli eventi. Le immagini sono archiviate in ECR, le operazioni utilizzano SSM per l’accesso agli host e GuardDuty/CloudWatch sono abilitati, ma la visibilità non è uniforme tra i container e i componenti del control plane.

Sfida: Un container in produzione ha mostrato connessioni in uscita sospette e un ingegnere ha scoperto che un pod poteva raggiungere il servizio di metadati dell’istanza EC2, rischiando l’esfiltrazione di credenziali; le vulnerabilità delle immagini e una registrazione insufficiente del control plane potrebbero nascondere la causa principale.

Approccio Raccomandato:

1. Abilitare ECS Exec per i task e richiedere AWS Systems Manager Session Manager per l’ispezione degli host e del runtime dei container (ECS Exec + SSM), eliminando la necessità di SSH e garantendo che l’attività della sessione sia registrata su CloudTrail e CloudWatch Logs.
2. Imporre l’uso di IMDSv2 sulle istanze EC2 (Instance Metadata Service HttpTokens=required, hop limit=1) e applicare regole di rete a livello di host per bloccare l’indirizzo 169.254.169.254 dai namespace di rete dei container, in modo che i container non possano interrogare i metadati dell’istanza.
3. Attivare il monitoraggio a runtime di Amazon GuardDuty e la Malware Protection per container e Lambda, inoltrando i risultati (findings) a Security Hub ed EventBridge per playbook di contenimento automatizzati.
4. Rafforzare la sicurezza di EKS abilitando i log del control plane (audit, authenticator, controllerManager, scheduler) verso CloudWatch Logs, adottare IAM Roles for Service Accounts (IRSA) e imporre controlli di ammissione (Pod Security o OPA Gatekeeper) per limitare le funzionalità rischiose.
5. Attivare la scansione avanzata delle immagini di Amazon ECR (Inspector/scansione ECR) con la funzione scan-on-push e integrare i risultati nella CI per bloccare/mettere in quarantena le immagini tramite EventBridge + Lambda per l’applicazione delle policy.
6. Centralizzare la telemetria: inviare i log di CloudTrail, i risultati di GuardDuty, i log del control plane di EKS e i risultati delle scansioni ECR a una pipeline centralizzata basata su S3/Lambda/Security Hub e alimentare le regole di AWS Config per una conformità continua.

Motivazione: Questa sequenza elimina l’accesso basato su SSH, previene il furto di credenziali dai metadati, fornisce rilevamento a runtime e risposta automatizzata, impone l’igiene delle immagini e offre visibilità sul control plane, allineandosi con le best practice di AWS del principio del privilegio minimo (least privilege), della difesa in profondità (defense in depth) e dell’osservabilità centralizzata.

# CodeBuild buildspec fragment
post_build:
  commands:
    - aws ecr describe-image-scan-findings \
        --repository-name api --image-id imageTag=$TAG \
        --query 'imageScanFindings.findingSeverityCounts' > findings.json
      CRIT=$(jq '.CRITICAL // 0' findings.json)
      if [ "$CRIT" -gt 0 ]; then echo "Critical CVEs present"; exit 1; fi

L’integrazione nella pipeline è ciò che trasforma la scansione da un semplice esercizio su una dashboard a un controllo reale.

Lambda: Authorizer, Segreti e Ruoli di Esecuzione

La sicurezza a livello di funzione Lambda ha tre piani che vengono spesso confusi:

• Policy della risorsa (policy della funzione): controlla quali principal (API Gateway, EventBridge, altri account) possono invocare la funzione. I Lambda Authorizer su API Gateway sono il punto di controllo dell’identità per le chiamate HTTP: restituiscono una policy IAM che API Gateway mette in cache e applica prima di invocare la funzione di backend.

• Ruolo di esecuzione: l’identità che il codice della funzione assume a runtime. La sua policy di attendibilità (trust policy) deve includere lambda.amazonaws.com e deve concedere le autorizzazioni logs:CreateLogGroup, logs:CreateLogStream e logs:PutLogEvents per il funzionamento di CloudWatch Logs. Se i log mancano, la soluzione è quasi sempre il ruolo di esecuzione, non la console Lambda, che si limita a visualizzare i log che CloudWatch ha ricevuto. Affidarsi solo ai “log della console” è una trappola diagnostica: nessuna autorizzazione nel ruolo di esecuzione significa nessuno stream di log, e la console non mostra nulla.

• Recupero dei segreti: non inserire mai le credenziali in chiaro nelle variabili d’ambiente. Archiviarle in Secrets Manager o in SSM Parameter Store come SecureString e recuperarle al cold start:

import boto3, os, json
_ssm = boto3.client("ssm")
_cached = None

def get_db_password():
    global _cached
    if _cached is None:
        r = _ssm.get_parameter(Name=os.environ["DB_PWD_PARAM"], WithDecryption=True)
        _cached = r["Parameter"]["Value"]
    return _cached

Il ruolo di esecuzione necessita delle autorizzazioni ssm:GetParameter e kms:Decrypt sulla CMK. Mettere in cache a livello di modulo in modo che le invocazioni “warm” evitino la chiamata API; utilizzare l’estensione Lambda di Secrets Manager per una cache automatica che gestisce la rotazione nelle funzioni a throughput più elevato.

Crittografia e Protezione dei Repository ECR

Amazon ECR crittografa tutte le immagini a riposo (at rest) per impostazione predefinita utilizzando AES-256 con una chiave gestita da AWS, ma i carichi di lavoro regolamentati richiedono tipicamente una chiave KMS gestita dal cliente (customer-managed key) in modo che la rotazione della chiave, le policy della chiave e la verificabilità tramite CloudTrail siano sotto il controllo del cliente. La crittografia KMS viene configurata solo al momento della creazione del repository; un repository ECR esistente non può essere convertito da AES-256 a KMS in un secondo momento. La migrazione richiede quindi la creazione di un nuovo repository crittografato con KMS, la replica o il re-push delle immagini, l’aggiornamento dei consumer a valle e l’eliminazione del vecchio repository. I consumer cross-account che effettuano il pull da un repository crittografato con KMS devono avere l’autorizzazione kms:Decrypt sulla CMK, oltre ai permessi di lettura di ECR, altrimenti il pull fallirà con un errore di accesso a KMS anche se la policy del repository consente l’accesso al principal.

{
  "encryptionConfiguration": {
    "encryptionType": "KMS",
    "kmsKey": "arn:aws:kms:us-east-1:111122223333:key/abcd-...-ef01"
  },
  "imageScanningConfiguration": { "scanOnPush": true },
  "imageTagMutability": "IMMUTABLE"
}

I tag immutabili (immutable tags) prevengono attacchi di tipo tag-hijack in cui un tag convalidato come v1.2.3 viene sovrascritto silenziosamente da un’immagine dannosa dopo la scansione.

Scansione delle immagini: Basic, Enhanced e Inspector

ECR offre due modalità di scansione. La scansione di base (Basic scanning) utilizza il database open-source di CVE Clair, viene eseguita solo al momento del push (o su invocazione manuale) e restituisce i risultati nella console di ECR. È gratuita, ma non esegue nuove scansioni continue, non copre contemporaneamente i pacchetti del sistema operativo e quelli dei linguaggi di programmazione, e non ha un’integrazione nativa con Security Hub. La scansione avanzata (Enhanced scanning) è basata su Amazon Inspector e copre sia i pacchetti del sistema operativo sia i pacchetti dei linguaggi applicativi (Python, Java, Node.js, Go, Ruby, .NET). Inspector monitora continuamente le immagini caricate (pushed) confrontandole con le informazioni aggiornate sulle vulnerabilità, quindi una CVE scoperta una settimana dopo il push dell’immagine produce comunque un risultato (finding) senza necessità di una nuova build.

La scansione avanzata è abilitata a livello di registry (per Regione), con filtri di inclusione per repository che utilizzano pattern con wildcard come prod-* o team-a/*. Questo è il controllo corretto per il requisito comune di “scansionare la maggior parte dei repository ma escludere quelli di sandbox/sperimentazione” — si definiscono filtri positivi che elencano cosa deve essere scansionato, anziché esclusioni negative su singoli repository.

aws ecr put-registry-scanning-configuration \
  --scan-type ENHANCED \
  --rules '[{
    "scanFrequency": "CONTINUOUS_SCAN",
    "repositoryFilters":[{"filter":"prod-*","filterType":"WILDCARD"}]
  },{
    "scanFrequency": "SCAN_ON_PUSH",
    "repositoryFilters":[{"filter":"dev-*","filterType":"WILDCARD"}]
  }]'

Integrazione di Inspector e Aggregazione con Security Hub

Amazon Inspector deve essere abilitato in ogni account e Regione in cui è richiesta la scansione. In una configurazione con AWS Organizations, l’account degli strumenti di sicurezza viene designato come amministratore delegato per Inspector, il che gli consente di abilitare la scansione, impostare l’iscrizione automatica (auto-enroll) per i nuovi account membri e visualizzare i risultati aggregati. Dimenticare di delegare — o di attivare l’auto-enroll — è una modalità di fallimento subdola: i nuovi account che si uniscono all’organizzazione inviano silenziosamente container a ECR che non vengono mai scansionati, infrangendo le garanzie di copertura senza generare alcun errore evidente.

I risultati (findings) di Inspector confluiscono automaticamente in AWS Security Hub quando entrambi i servizi sono abilitati e l’integrazione di Inspector in Security Hub è attiva. Security Hub quindi normalizza i risultati nel formato AWS Security Finding Format (ASFF), li correla con i risultati di GuardDuty, Macie e Config e — se combinato con un amministratore delegato di Security Hub e l’aggregazione cross-Region — presenta un’unica interfaccia di gestione (single pane of glass). Le regole di EventBridge sui risultati di Security Hub possono instradare le CVE critiche a Lambda per la creazione automatizzata di ticket, etichettare l’immagine problematica con un’etichetta quarantine=true, o bloccare il deployment tramite un gate nella pipeline.

Scansione Centralizzata e CI/CD Cross-Account

Il pattern raccomandato per i carichi di lavoro container multi-account pone al centro un account di registry centrale con hardening:

• Account centrale: ospita repository ECR crittografati con KMS, con scansione avanzata, tag immutabili e firma delle immagini (tramite Notation/Sigstore integrato con AWS Signer).
• Account di build: eseguono job di CodeBuild/CodePipeline che effettuano la build, il push su ECR centrale, attendono i risultati di Inspector e applicano un gate basato su soglie di gravità.
• Account di workload (dev/stage/prod): effettuano il pull delle immagini dal registry centrale tramite permessi cross-account.

L’accesso in lettura cross-account richiede due livelli: una policy IAM nell’account consumer che concede ecr:GetDownloadUrlForLayer, ecr:BatchGetImage e ecr:GetAuthorizationToken, più una policy del repository sul repo ECR nell’account centrale che autorizza lo specifico account o ruolo consumer.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowProdPull",
    "Effect": "Allow",
    "Principal": {"AWS":"arn:aws:iam::444455556666:role/EcsTaskExecutionRole"},
    "Action": ["ecr:BatchGetImage","ecr:GetDownloadUrlForLayer"]
  }]
}

Poiché le policy dei repository ECR sono basate sulla risorsa (resource-based), l’intersezione tra la policy di identità e quella di risorsa determina l’accesso — omettere uno dei due livelli produce un’eccezione AccessDeniedException. Quando è coinvolto KMS, anche la policy della chiave KMS deve concedere kms:Decrypt al principal cross-account.

Logging e Osservabilità del Control Plane di EKS

Per EKS, il control plane gestito non è direttamente accessibile, quindi gli eventi Kubernetes rilevanti per la sicurezza sono esposti solo quando il logging del control plane è abilitato esplicitamente. Sono disponibili cinque tipi di log: api, audit, authenticator, controllerManager e scheduler. Il log di audit è l’artefatto di sicurezza di maggior valore — registra ogni chiamata API al cluster con l’identità del chiamante risolta tramite l’authenticator IAM — e il log authenticator registra le decisioni di mappatura da IAM a RBAC di Kubernetes. Tutti i tipi vengono trasmessi in streaming a CloudWatch Logs in un gruppo di log /aws/eks/<cluster>/cluster, da cui possono essere sottoscritti a Kinesis Data Firehose, inoltrati a S3 o inviati a un SIEM.

aws eks update-cluster-config --name prod-cluster \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator",
  "controllerManager","scheduler"],"enabled":true}]}'

Complementa i log del control plane con GuardDuty EKS Protection (rilevamento delle minacce a runtime sui nodi) e utilizza IRSA (IAM Roles for Service Accounts) invece dei profili di istanza dei nodi, in modo che i log di audit attribuiscano l’attività delle API AWS a pod specifici.

Trappole Comuni

Affidarsi solo alla scansione al push: La scansione di base al push rileva le vulnerabilità note al momento del push, ma non interviene sulle CVE divulgate in seguito per le immagini già presenti nel registro. Framework di audit come PCI DSS e FedRAMP richiedono una valutazione continua delle vulnerabilità, che impone una scansione avanzata con frequenza CONTINUOUS_SCAN e l’aggregazione tramite Security Hub. Un’istantanea eseguita una sola volta al push non supera il controllo.

Omettere KMS su ECR quando è richiesta la crittografia at-rest: La crittografia predefinita AES-256 è una crittografia effettiva, ma i regimi di conformità che richiedono chiavi gestite dal cliente (customer-managed keys), registri di rotazione delle chiavi e tracce di audit kms:Decrypt per principal non possono essere soddisfatti con chiavi di proprietà di AWS. Poiché il tipo di crittografia è immutabile per ogni repository, questo aspetto deve essere gestito al momento della creazione: l’approccio “lo attiveremo più tardi” è impossibile senza ricreare il repository.

Dimenticare l’amministratore delegato di Inspector o l’iscrizione automatica: Senza un amministratore delegato per Inspector, ogni proprietario di account deve abilitare autonomamente la scansione e inoltrare i risultati, il che è operativamente impraticabile e produce lacune nella copertura. Senza l’abilitazione automatica per i nuovi account membri, ogni nuovo account creato tramite Control Tower o Organizations inizia con Inspector disabilitato, quindi le sue immagini ECR non vengono scansionate, anche se Security Hub nell’account centrale non mostra alcun risultato: un falso negativo silenzioso anziché un errore evidente.

Problema Pratico: Scenario d’Uso

Scenario: Meridian Financial gestisce un ambiente AWS multi-account con cluster EKS di produzione, servizi ECS e più registri ECR distribuiti tra gli ambienti di prod, dev e un account di sicurezza dedicato. I loro team di ingegneri effettuano il push delle immagini dei container tramite pipeline CI/CD in ECR e le distribuiscono su EKS/ECS, mentre il team di sicurezza mantiene un account centralizzato per il monitoraggio e la conformità.

Sfida: Una recente implementazione ha distribuito un container con una vulnerabilità di gravità elevata che non è stata rilevata prima della messa in produzione; gli investigatori hanno trovato log del control plane di EKS limitati e risultati di scansione frammentati tra gli account, rallentando la risoluzione del problema.

Approccio Raccomandato:

1. Abilitare le protezioni a livello di repository ECR: imporre l’immutabilità dei tag delle immagini, applicare policy di repository che limitano il push/pull a ruoli IAM specifici e crittografare i repository at-rest con una chiave gestita dal cliente (CMK) AWS KMS dedicata.
2. Attivare la scansione delle immagini al push (base) e abilitare la scansione avanzata delle immagini di Amazon Inspector per ECR per produrre i risultati delle vulnerabilità; integrare Inspector con AWS Security Hub per l’aggregazione centralizzata delle gravità tra gli account.
3. Implementare la scansione centralizzata cross-account: configurare la replica ECR o concedere a un ruolo CodeBuild/CodePipeline dell’account di sicurezza le autorizzazioni di pull cross-account, in modo che l’account di sicurezza esegua la scansione di ogni immagine con Inspector e qualsiasi strumento SCA/DAST aggiuntivo, archiviando gli artefatti in un bucket S3 centralizzato e crittografato con la CMK dell’account di sicurezza.
4. Imporre il gating nella CI/CD: aggiungere una fase di scansione nella pipeline (CodeBuild/CodePipeline o GitHub Actions con STS assume-role) che interroga i risultati di Inspector/Security Hub e blocca automaticamente o richiede l’approvazione per le immagini con risultati di gravità alta/critica.
5. Migliorare l’osservabilità di EKS: abilitare i log del control plane di EKS (API, Audit, Authenticator, ControllerManager, Scheduler) verso CloudWatch Logs in un account di logging centralizzato, abilitare CloudTrail per gli eventi API di EKS e utilizzare Container Insights e GuardDuty per il monitoraggio a runtime.

Motivazione: Questo approccio applica una difesa in profondità (defense-in-depth): crittografare e proteggere i registri, automatizzare la scansione avanzata con Inspector, centralizzare i risultati in Security Hub per un’applicazione coerente delle policy, implementare il gating delle distribuzioni nella CI/CD e abilitare i log del control plane di EKS per un rilevamento e un’analisi forense rapidi, allineandosi con le best practice di AWS sul principio del privilegio minimo (least-privilege) e sul monitoraggio centralizzato.

← Vulnerabilità · Tutti i domini · Risposta agli incidenti e analisi forense →

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

Sfoglia Amazon →