Identity and Access Management e least privilege
AWS Identity and Access Management (IAM) è il servizio con cui controlli chi può fare cosa su Amazon Bedrock, Amazon SageMaker e sugli altri servizi AI. Il principio guida è il least privilege: concedi solo i permessi strettamente necessari a un compito, niente di più. In pratica non assegni un accesso da amministratore a un data scientist che deve soltanto invocare un modello; gli dai una policy che consente le sole azioni richieste sulle sole risorse richieste.
Preferisci sempre gli IAM role alle access key statiche. Un role fornisce credenziali temporanee che ruotano automaticamente: è così che, ad esempio, un job di training in SageMaker legge un bucket Amazon S3 senza incorporare segreti nel codice. L’utente root va protetto con MFA e non usato per le operazioni quotidiane. IAM policy, group e role sono la prima linea di difesa: la maggior parte degli incidenti nasce da permessi troppo ampi, non da un cifrario debole.
Protezione dei dati: encryption e isolamento
I dati vanno protetti a riposo (at rest) e in transito (in transit). L’encryption in transit si ottiene con TLS/HTTPS su tutte le chiamate API ai servizi AI, così i dati non viaggiano mai in chiaro. L’encryption at rest si appoggia a AWS Key Management Service (KMS): i volumi di SageMaker, i bucket S3 con i dataset e gli artifact dei modelli si cifrano con chiavi KMS. Puoi scegliere una AWS managed key (gestita dal servizio) oppure una customer managed key, che ti dà controllo su rotazione, policy e revoca.
Per ridurre l’esposizione di rete usi VPC e private endpoint (AWS PrivateLink), così il traffico verso Bedrock o SageMaker resta dentro la rete AWS senza passare per l’Internet pubblico. Amazon Macie aiuta a scoprire dati sensibili (PII) nei bucket S3, mentre AWS CloudTrail registra le chiamate API per l’audit. Nota che con Amazon Bedrock i tuoi prompt e i tuoi dati non vengono usati per addestrare i foundation model di base.
Il modello di responsabilità condivisa applicato all’AI
Lo shared responsibility model divide la sicurezza tra AWS e cliente. AWS è responsabile della sicurezza “of the cloud”: hardware, infrastruttura fisica e software dei servizi gestiti. Il cliente è responsabile della sicurezza “in the cloud”: i propri dati, la configurazione IAM, la scelta e la gestione dell’encryption, il controllo degli accessi.
La linea di demarcazione si sposta con il tipo di servizio. Con un servizio completamente gestito come Amazon Bedrock, AWS gestisce patch, runtime del modello e infrastruttura; a te restano dati, permessi, filtri sugli output e governance dei prompt. Se invece gestisci istanze o container per addestrare modelli custom, ti carichi di più responsabilità, come gli aggiornamenti del sistema operativo e la configurazione di rete. L’errore concettuale da evitare: pensare che “gestito” significhi che AWS protegge anche i tuoi dati e i tuoi permessi. Quella parte resta sempre tua, ed è per questo che il passing score di 700/1000 premia chi sa dove passa il confine.
Trappole tipiche d’esame
- Serve dare a un utente accesso completo per fare prima → least privilege: concedi solo le azioni necessarie; un accesso ampio “per comodità” è la risposta sbagliata anche quando funziona.
- Chi protegge i dati caricati in un servizio AI gestito → il cliente: AWS protegge l’infrastruttura, ma dati, IAM ed encryption restano responsabilità tua nello shared responsibility model.
- Cifrare i dati at rest mantenendo il controllo delle chiavi → AWS KMS con customer managed key: se lo scenario chiede controllo su rotazione e revoca, scegli la customer managed key, non la chiave gestita dal servizio.
- Evitare che il traffico verso il modello passi dall’Internet pubblico → VPC + private endpoint (PrivateLink): la risposta non è “cifrare di più”, ma isolare la rete.
- Un servizio che deve accedere ad altre risorse → IAM role, non access key: le key statiche nel codice sono il distrattore classico; il role fornisce credenziali temporanee che ruotano.
- Trovare PII in un bucket S3 → Amazon Macie: è il servizio dedicato alla scoperta di dati sensibili; Amazon GuardDuty invece rileva minacce e non classifica i dati.