Amazon MLS-C01: Sicurezza, privacy e conformità — Guida allo studio
Fa parte della AWS Machine Learning Specialty MLS-C01 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.
Crittografia dei dati e dei modelli: controlli stratificati e trappole comuni
La crittografia dei dati a riposo (at rest) e in transito (in transit) è la prima linea di difesa per le pipeline di ML. Per gli oggetti in S3, preferire la crittografia lato server con KMS (SSE-KMS) quando sono necessarie auditabilità e un controllo granulare delle chiavi; SSE-S3 è accettabile per i bucket in cui non è richiesta la registrazione di ogni richiesta a KMS. Anche gli artefatti dei modelli SageMaker, i volumi EBS collegati alle istanze di training e hosting e i volumi EFS/FSx devono essere crittografati. SageMaker può essere configurato per utilizzare CMK gestite dal cliente per la crittografia degli artefatti dei modelli e dei volumi. Per dataset di grandi dimensioni o per la condivisione tra account diversi (cross-account), utilizzare la crittografia a involucro (generando chiavi dati con KMS e utilizzando l’AWS Encryption SDK o librerie lato client) per evitare chiamate ripetute a KMS. La protezione in transito richiede TLS per tutti gli endpoint di S3 e dei servizi; quando si utilizza una rete privata, anche PrivateLink e gli endpoint VPC utilizzano TLS sul canale di comunicazione. Una trappola frequente è dimenticare di aggiornare le policy della chiave CMK: è necessario concedere al principal del servizio SageMaker e ai propri ruoli di esecuzione le autorizzazioni di decrittografia/generazione (IAM da solo non è sufficiente). Criteri decisionali: scegliere le CMK gestite da AWS quando si desidera un basso carico operativo; scegliere le CMK gestite dal cliente quando si richiedono policy di rotazione delle chiavi, controllo cross-account o amministratori delle chiavi separati. Considerare le prestazioni e i costi: la crittografia a involucro riduce l’utilizzo delle API di KMS per i carichi di lavoro ad alto throughput.
Gestione delle chiavi, progettazione delle CMK e controlli operativi
La progettazione di una strategia KMS per i carichi di lavoro di ML bilancia sicurezza, confini di accesso e operatività. Utilizzare CMK gestite dal cliente quando sono necessari controlli di policy granulari, grant, uso cross-account e tracce di audit in CloudTrail per le operazioni GenerateDataKey/Decrypt. Per chiavi supportate da HSM e requisiti FIPS, considerare un KMS Custom Key Store basato su CloudHSM. Le policy della chiave sono autoritative; integrarle con le policy IAM e utilizzare le condizioni kms:ViaService per limitare l’uso a specifici servizi AWS (ad esempio, consentire la decrittografia solo se chiamata tramite sagemaker.amazonaws.com o s3.amazonaws.com). Utilizzare i grant di KMS per permessi a breve termine per delegare la crittografia/decrittografia a ruoli effimeri utilizzati dai processi di training. Abilitare la rotazione automatica delle chiavi per le CMK simmetriche, dove appropriato, e creare chiavi multi-regione per la replica geo-ridondata dei modelli. Tra le trappole comuni vi sono l’affidarsi esclusivamente alle policy IAM (senza aggiornare la policy della chiave CMK) e dimenticare di includere i principal dei servizi (come sagemaker.amazonaws.com o elasticblockstore.amazonaws.com) in modo che i servizi gestiti possano utilizzare le CMK. I criteri decisionali dovrebbero bilanciare la separazione amministrativa (utilizzare CMK distinte per unità di business o classe di sensibilità) con le quote di KMS e la complessità operativa; applicare il principio del privilegio minimo e controllare gli eventi GenerateDataKey in CloudTrail.
Networking privato ed endpoint VPC per SageMaker e S3
Per mantenere dati e immagini al di fuori della rete Internet pubblica, collocare SageMaker Studio, le istanze di notebook e i processi di training/hosting all’interno di VPC e utilizzare endpoint VPC. Gli endpoint gateway di S3 consentono un accesso diretto e privato agli oggetti dei bucket dalle proprie subnet; associare policy di endpoint restrittive per limitare l’accesso a bucket e prefissi specifici. Le API di SageMaker, le chiamate di runtime e ECR richiedono endpoint di interfaccia (PrivateLink): creare gli endpoint com.amazonaws.<region>.sagemaker, com.amazonaws.<region>.sagemaker-runtime, com.amazonaws.<region>.ecr.api, com.amazonaws.<region>.ecr.dkr e com.amazonaws.<region>.sts, a seconda dei casi. Un dettaglio operativo critico è la semantica del pull da ECR: sono necessari sia gli endpoint di interfaccia di ECR sia un endpoint S3 (e un endpoint STS) per l’autenticazione e il recupero dei blob. La mancanza degli endpoint STS o S3 è una causa comune di fallimenti in modalità privata. Quando si fornisce la VpcConfig per il training/hosting, SageMaker crea delle ENI nelle proprie subnet in modo che le risorse di calcolo possano accedere a risorse private; ricordare che disabilitare i gateway NAT e le subnet pubbliche blocca l’egresso verso Internet, imponendo un ambiente isolato. Criteri decisionali: per un’elevata sicurezza, bloccare le policy degli endpoint, disabilitare l’accesso a Internet per il traffico di Studio e dei notebook e instradare la registrazione (CloudWatch Logs e CloudTrail) attraverso canali abilitati per gli endpoint.
IAM, accesso a immagini private, audit logging e controlli sull’esfiltrazione
I ruoli IAM basati sul principio del privilegio minimo sono fondamentali: il ruolo di esecuzione di SageMaker deve disporre solo delle autorizzazioni S3, ECR, KMS e CloudWatch necessarie per il processo, spesso limitate agli ARN delle risorse e vincolate con condizioni come aws:SourceArn/aws:SourceAccount/aws:SourceVpc. Per le immagini container private, ospitarle in repository ECR privati con policy di repository che limitano i pull a specifici principal IAM o account dell’organizzazione; contrassegnare le immagini come immutabili e abilitare la scansione delle immagini. L’audit logging è completo: abilitare gli eventi di gestione di CloudTrail e gli eventi dati di S3 per GetObject/PutObject sui bucket sensibili, inoltrare i log a un bucket di logging dedicato, crittografato e cross-account, e abilitare CloudWatch Logs e VPC Flow Logs per rilevare egress anomali. Utilizzare Amazon Macie per scoprire PII in S3 e GuardDuty per rilevare pattern di accesso ai dati insoliti. Per prevenire l’esfiltrazione di dati, combinare policy dei bucket S3 che negano (Deny) le richieste non provenienti da endpoint VPC o CIDR VPC approvati, controlli di rete come Security Group/NACL e AWS Network Firewall per il filtraggio dell’egress, e permission boundary/SCP di IAM per ridurre il raggio d’impatto (blast radius). Tra le trappole comuni vi sono il presumere che VpcConfig da solo impedisca tutto l’egress in uscita (è necessario controllare NAT/Internet Gateway e gli endpoint) e dimenticare di concedere l’autorizzazione KMS decrypt ai principal di runtime effettivi che necessitano degli artefatti del modello.
Problema Pratico: Scenario d’Uso
Scenario: MetroDelivery gestisce modelli XGBoost per singola città, archiviati come artefatti in S3, e addestra i modelli in SageMaker Studio. Richiedono che l’addestramento e l’inferenza non transitino mai sulla rete internet pubblica, che gli artefatti dei modelli siano crittografati con chiavi controllate dal cliente e che le immagini dei container siano ospitate privatamente.
Sfida: Garantire la crittografia end-to-end e il networking privato per l’addestramento e l’hosting, limitare il pull delle immagini ai ruoli approvati e rilevare/prevenire lo spostamento non autorizzato di dati.
Approccio Raccomandato:
- Creare una CMK simmetrica gestita dal cliente in KMS, impostare una policy della chiave che conceda agli amministratori di MetroDelivery, a
sagemaker.amazonaws.come ai ruoli di esecuzione di SageMaker le autorizzazioniDecrypt/GenerateDataKey, e abilitare la rotazione automatica. - Crittografare i bucket S3 con SSE-KMS utilizzando quella CMK; usare le policy dei bucket S3 per bloccare l’accesso pubblico e richiedere le condizioni
aws:SourceVpcoaws:ViaAWSServiceperPutObject/GetObject. - Configurare il VPC: distribuire sottoreti private senza NAT, creare un Gateway VPC Endpoint per S3 con una policy dell’endpoint limitata al prefisso del bucket dei modelli, e distribuire Interface Endpoint per
sagemaker,sagemaker-runtime,ecr.api,ecr.dkr,stsecloudwatchlogs. - Ospitare le immagini in ECR privato con una policy di repository che limiti i principal al ruolo di esecuzione di SageMaker; abilitare l’immutabilità e la scansione delle immagini. Abilitare CloudTrail (eventi di gestione + dati S3), Macie per la scoperta di dati sensibili e GuardDuty per attività anomale; inviare i log a un bucket di audit cross-account crittografato.
Logica: L’uso di una CMK gestita dal cliente fornisce controllo e auditabilità per gli artefatti dei modelli; gli endpoint VPC e le policy restrittive di endpoint/repository mantengono il traffico sulla rete AWS e impediscono l’egress pubblico; la combinazione di servizi di logging e classificazione dei dati rileva e scoraggia l’esfiltrazione, mentre l’approccio IAM del privilegio minimo limita il raggio d’attacco.
← Deployment · Tutti i domini · MLOps →
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 →