“il nostro compito non è quello di rallentare l’innovazione. È fare in modo che tutti noi possiamo muoverci ancora più velocemente”. Così Amy Herzog, da poco nominata Chief Information Security Officer (CISO) di Amazon Web Services, nell’introduzione del keynote inaugurale di AWS re:Inforce 2025, che si è tenuto a Philadelphia e a cui abbiamo preso parte. Una frase-manifesto, che ha definito il tono di un intervento che ha articolato con precisione il nuovo ruolo della cybersecurity: da barriera difensiva a leva di accelerazione AI-first.
Identità e accesso: il cuore matematico del controllo
Herzog ha aperto con un dato piuttosto impressionante: “IAM gestisce 1,2 miliardi di chiamate API al secondo. È un numero che fa girare la testa, ma riflette la scala della fiducia che ci viene richiesta ogni istante”. Un dato non solo quantitativo, ma qualitativo: racconta la pervasività dei sistemi IAM nel disegnare, proteggere e controllare ogni flusso digitale nel cloud.
AWS Identity and Access Management (IAM) è uno dei servizi più strategici della piattaforma: definisce chi può fare cosa, su quali risorse, in quali condizioni. Ogni azione — dal caricamento di un oggetto S3 alla rotazione di una chiave KMS, dall’esecuzione di una Lambda function al lancio di un container — passa per una valutazione di policy IAM.
La complessità di questa valutazione nasce dal fatto che i permessi possono derivare da policy esplicite assegnate all’identità, da ruoli assunti temporaneamente, da policy di trust tra servizi, condizioni basate su IP, orario, tag e deleghe cross-account.
Per questo motivo, IAM è diventato un linguaggio formale, con sintassi e semantica rigorosa. E come ogni linguaggio, richiede strumenti di analisi che vadano oltre la semplice gestione e attribuzione dei privilegi da console: da Access Analyzer a Policy Simulator, fino a Internal Access Findings, di cui è stato l’annuncio della general availability, che applica il ragionamento automatico per determinare se un’entità può effettivamente accedere a una risorsa — al di là della singola policy visibile, consentendo una vista unificata e automatica su chi ha accesso a risorse critiche. Il valore aggiunto? L’analisi continua e basata su ragionamento automatico delle policy, capace di aggregare permessi derivanti da ruoli, sessioni temporanee, tag, condizioni dinamiche. “Non si può parlare di innovazione, intelligenza artificiale o modernizzazione se non si parte da una base solida. E quella base è sapere, in ogni momento, chi può fare cosa”.
IAM deve essere osservabile, testabile, prevedibile. La sua accuratezza è ciò che distingue una piattaforma sicura da una vulnerabile.
Fine delle credenziali persistenti
Il secondo asse strategico ha riguardato l’eliminazione delle credenziali a lunga durata. “Ogni secondo in più in cui una credenziale è valida è un secondo in più in cui può essere rubata. Dobbiamo superare l’era delle chiavi che vivono per sempre”. Herzog ha descritto un attacco concreto in cui credenziali statiche compromesse sono state usate per ri-crittografare oggetti S3, bloccando l’accesso ai dati originali.
AWS propone una migrazione strutturale verso l’utilizzo esclusivo di credenziali temporanee. Queste vengono generate tramite AWS Security Token Service – STS, sono federate da Identity Provider esterni (come Active Directory, Okta, Azure AD) e durano solo pochi minuti. Possono essere condizionate con regole dinamiche e protette da MFA.
L’architettura suggerita è quella a “zero standing privileges”: nessun utente o workload mantiene privilegi permanenti. I permessi sono assegnati in modo dinamico e Just-in-Time, validi solo per una singola operazione. Questo modello si applica tanto alle pipeline CI/CD (es. GitHub Actions che assumono ruoli IAM) quanto agli utenti umani, che accedono tramite portali federati.
I benefici: tutto è tracciato tramite CloudTrail; gli accessi sono limitati nel tempo e nel contesto e anche in caso di leakage, l’impatto è minimo.
Il passaggio alle credenziali temporanee implica tuttavia anche una transizione culturale nello sviluppo: abbandonare file di configurazione statici, chiavi salvate in chiaro, accessi non controllati. È il fondamento per una sicurezza davvero cloud-native.
E se servono privilegi elevati? “Usate ruoli temporanei, concedeteli solo quando servono e sempre con MFA (Multi-Factor Authentication). È la cosa più efficace che potete fare per proteggere il vostro account. Punto”, conclude assertivamente Herzog.
Crittografia ovunque e controllo sovrano
Herzog ha ribadito la posizione AWS sulla sovranità digitale: “Non dovreste dover scegliere tra innovazione e controllo. AWS è nato per offrirvi entrambi”. Il concetto di sovranità non si limita alla collocazione geografica dei dati, ma include il controllo su chi vi accede, sulla loro cifratura, sulla resistenza ai guasti e sulla conformità a normative locali.
La crittografia multilivello è oggi pervasiva: ogni pacchetto che attraversa la rete AWS può essere cifrato fino a tre volte, senza intervento del cliente. Questo avviene attraverso una combinazione di TLS, crittografia dei link fisici tra data center, e wrapping con header AWS proprietari all’interno dei VPC. L’obiettivo è costruire una catena di fiducia che resista anche al fallimento di uno degli strati di sicurezza.
Storicamente, la cifratura era un’attività onerosa in termini di risorse computazionali e di gestione. Oggi, su AWS, è automatizzata e praticamente gratuita. Ogni servizio — da S3 a RDS, da EBS a Kinesis — supporta la cifratura automatica dei dati a riposo con chiavi gestite (SSE-KMS) o fornite dal cliente (SSE-C).
Con l’annuncio della possibilità di esportare certificati e chiavi private da ACM, AWS consente ora di usare i certificati TLS anche in ambienti ibridi e multi-cloud. “Ora potete usare i nostri certificati ovunque, dentro e fuori AWS. E non dovrete più rinnovarli a mano”. Questa novità apre scenari significativi per chi gestisce architetture distribuite, consentendo una gestione centralizzata dei certificati anche in ambienti on-premise o edge.
Il risultato complessivo è una postura di sicurezza che unisce praticità e rigore crittografico: i dati sono cifrati in transito, a riposo e durante l’elaborazione, senza sacrificare performance o scalabilità. È una delle basi architetturali che rende possibile l’adozione sicura dell’intelligenza artificiale, della blockchain, e dei servizi cross-border.
Difesa in profondità: dalla rete alle applicazioni
Con i sistemi Blackfoot e Madpod, AWS riesce a bloccare 2,4 trilioni di richieste malevole in sei mesi. “Ogni tre minuti analizziamo gli IP bloccati: il 12,5% cambia. Il valore del threat intel ha vita brevissima, serve agire in tempo reale”.
Blackfoot è un sistema interno di network address translation e tracciamento, posizionato al confine di ogni VPC AWS. Esso elabora oltre 13 trilioni di flussi orari e associa gli indirizzi IP pubblici a quelli interni, fungendo da sistema di osservabilità a livello di infrastruttura. Il suo ruolo è duplice: mappare il traffico per identificarne le origini e abilitare regole di blocco dinamico e automatizzato.
Madpod, invece, è una rete di honeypot ad alta interazione: istanze EC2 che simulano vulnerabilità note o comportamenti esposti, progettate per attirare attori malevoli. Ogni Madpod finge di essere un servizio reale e registra i tentativi di exploit o scansione. I dati raccolti alimentano un drop table condiviso che, combinato con la visibilità di Blackfoot, consente ad AWS di bloccare l’attività malevola prima che raggiunga l’ambiente cliente.
Nel layer applicativo, il nuovo Network Security Director analizza la topologia della rete e segnala criticità, mentre la nuova console WAF semplifica onboarding e gestione di protezioni su API e app web. “Non dovreste dover scegliere tra protezione completa e facilità d’uso”. Herzog ha sottolineato come la nuova interfaccia WAF sia pensata per semplificare il deployment su vasta scala e migliorare l’accessibilità di una protezione granulare, specie in ambienti con molteplici API pubbliche.
Monitoraggio comportamentale e detection sequenziale
Herzog ha usato una metafora per parlare dei limiti del monitoraggio tradizionale: “Il problema della sicurezza è che spesso cerchiamo dove è facile vedere, non dove è più pericoloso. È l’effetto lampione”. Strumenti come GuardDuty Extended Threat Detection permettono ora di correlare eventi distribuiti e costruire “sequenze” di attacco.
“Ogni giorno ispezioniamo 360 trilioni di eventi. Non vi serve più cercare un ago in un pagliaio: ve lo mostriamo noi”. Le nuove funzioni di Security Hub aggregano i dati, generano priorità e suggeriscono remediation in un flusso operativo continuo.
Security Hub si presenta ora come una soluzione unificata per la sicurezza cloud, in grado di raccogliere, normalizzare e correlare segnali da tutti i servizi AWS (e da numerosi partner esterni). L’obiettivo non è solo la visibilità, ma la prioritizzazione e l’automazione della risposta.
Il nuovo pannello di sintesi mostra tendenze di esposizioni, minacce attive e risorse vulnerabili, con possibilità di indagare singoli incidenti e analizzarne il percorso d’attacco. Ogni finding include descrizione, asset coinvolti, percorso di rete, configurazioni associate e suggerimenti di remediation.
Il flusso operativo può infine confluire direttamente in sistemi di ticketing come Jira, abilitando il passaggio da rilevamento a risoluzione senza frizioni. Grazie a Security Hub, il lavoro dei team SOC si sposta dal triage continuo all’intervento mirato, con maggiore velocità ed efficacia.
Comcast: tre stelle polari per una sicurezza AI-ready
Noopur Davis, CISO globale di Comcast, è salita sul palco per descrivere la strategia di sicurezza di un colosso con oltre 2.000 professionisti cyber e miliardi di interazioni digitali giornaliere. “In meno di due anni, il 20% delle nostre analisi di sicurezza riguarda software AI creato internamente. È una trasformazione straordinaria”.
Comcast, grande cliente AWS, è uno dei principali provider di connettività al mondo, serve decine di milioni di clienti residenziali e business con servizi che spaziano dalla banda larga al mobile, dalla TV on demand all’intrattenimento via streaming (Peacock), fino a infrastrutture per IoT e smart home. Questo ecosistema composito e altamente interconnesso rende la superficie di attacco estremamente ampia e complessa da gestire.
La velocità con cui l’intelligenza artificiale è stata adottata internamente ha spinto Comcast a ridefinire il proprio framework di sicurezza: dall’analisi del rischio alla governance, dallo sviluppo sicuro alla risposta agli incidenti. Per guidare questa evoluzione, l’azienda ha individuato tre “North Star”, fuor di metafora tre principi guida operativi e strategici:
Secure by Design: la sicurezza viene inserita nel ciclo di vita del software fin dalla fase di ideazione. I team DevSecOps sono co-responsabili della protezione dei modelli AI, e i dati utilizzati per l’addestramento vengono anonimizzati e tracciati con policy centralizzate. Ogni modello passa attraverso test di robustezza e audit di bias prima di essere messo in produzione.
Data-driven Security: l’approccio è predittivo, non solo reattivo. Comcast integra segnali provenienti da telemetria interna, threat intelligence esterna, e logging AI-specifico per generare alert contestualizzati e dashboard che aiutano i CISO a visualizzare i rischi emergenti. Le metriche di rischio sono generate in tempo reale e guidano scelte automatizzate sulle policy di enforcement.
Zero Trust: ogni componente — utente, servizio, modello AI — è autenticato e autorizzato con granularità. Le comunicazioni interne sono cifrate end-to-end e il contesto viene costantemente rivalutato. L’accesso ai modelli AI generativi, ad esempio, avviene solo tramite broker intermedi che applicano regole di policy e logging dettagliato.
Davis ha inoltre sottolineato come la Generative AI sia una leva concreta in ambito GRC (Governance, Risk, Compliance): “Compiliamo questionari, analizziamo attestazioni SOC2, monitoriamo controlli in tempo reale. E lo facciamo con bot AI, ogni giorno”. Il risultato è una drastica riduzione dei tempi di audit, una maggiore copertura dei controlli e una capacità predittiva più avanzata nel rilevare violazioni prima che si materializzino.
Modernizzazione: sicurezza nativa, continua, automatizzata
AWS promuove una visione della modernizzazione come potenziamento della postura di sicurezza. “Il miglior patch è quello che non dovete fare. E con S3, Lambda, KMS, non lo fate più voi”. Il caso RedShield è emblematico: attacchi da 1,3 Tbps mitigati grazie a modernizzazione dell’infrastruttura e architettura distribuita.
Modernizzare non significa solo migrare workload nel cloud, ma ripensarli secondo paradigmi cloud-native. Significa adottare servizi gestiti che aggiornano automaticamente la propria superficie di attacco, eliminano la necessità di patching manuale e integrano la sicurezza fin dalla progettazione.
I runtime serverless come Lambda, i database gestiti come Aurora e DynamoDB, gli orchestratori come Step Functions permettono di costruire applicazioni resilienti, monitorabili e intrinsecamente più sicure. Questo perché si riduce il numero di componenti da gestire direttamente, si automatizzano i controlli di sicurezza e si sfrutta l’infrastruttura condivisa AWS che viene continuamente migliorata.
Strumenti come CodeArtifact, ECR scanning, Amazon Inspector e Q Developer CLI integrano la sicurezza nelle pipeline. Il patching diventa continuo, il ciclo DevSecOps scalabile. Le policy possono essere scritte come codice, testate come unit test, e rilasciate insieme all’applicazione stessa.
Modernizzazione significa inoltre cultura: visibilità continua, gestione centralizzata dei permessi, auditing real-time, monitoraggio dell’integrità del codice e del comportamento runtime. Come ha sottolineato Herzog: “Passare al cloud è l’inizio. Modernizzare è il vero cambio di gioco”.
L’AI come leva, non come minaccia
AWS utilizza internamente la GenAI per velocizzare processi critici: analisi log, triage incident, patch generativi, testing automatico. “Nel 2025, puntiamo a +5% di efficienza grazie alle correzioni automatiche generate da AI. Ed è solo l’inizio”.
L’approccio AWS alla GenAI è pragmatico e infrastrutturale: i modelli non sono soltanto strumenti di analisi predittiva, ma veri e propri attori nei flussi operativi di sicurezza. Bot specializzati vengono addestrati a comprendere log, individuare anomalie, suggerire misure correttive e, quando autorizzati, applicarle automaticamente.
In particolare, nei Security Operations Center (SOC) interni, la GenAI è impiegata per prioritizzare incidenti sulla base del contesto aziendale, intetizzare catene causali di attacco da centinaia di eventi, proporre playbook personalizzati per la risposta automatizzata, validare configurazioni prima del rilascio di nuove policy e ottimizzare l’efficienza del patch management su larga scala.
Herzog ha anche menzionato l’uso della GenAI nella governance: “Stiamo riducendo drasticamente il tempo necessario per completare audit, assessment GRC e revisioni di controllo, grazie a modelli linguistici che interpretano i requisiti e li correlano ai log e alle evidenze tecniche”.
L’intelligenza artificiale, in questo scenario, non sostituisce gli esperti di sicurezza, ma ne potenzia la portata, trasformandoli in supervisori di ecosistemi intelligenti. La GenAI diventa così un moltiplicatore di velocità, precisione e resilienza.
La sicurezza è l’infrastruttura dell’innovazione
“Quando avete una base sicura, i vostri team non rallentano. Accelerano. Possono innovare sapendo che i guardrail sono già in funzione. È questo il significato profondo di «secure by design»” ribadice Herzog, che conclude con un messaggio potente: “La sicurezza è ciò che vi porta alla destinazione, più velocemente, in modo più sicuro, con maggiore impatto”.
