Controllo degli accessi S3: policy dei bucket e ACL

S3 offre diversi meccanismi sovrapposti di controllo degli accessi: policy IAM (basate sull'identità, controllano ciò che i principal possono fare), policy dei bucket (policy JSON basate sulle risorse e applicate al bucket), Access Control Lists (ACL) (concessioni legacy a livello di oggetto o bucket) e S3 Block Public Access (override a livello di account o bucket che blocca qualsiasi accesso pubblico indipendentemente dalle altre policy). Per la maggior parte dei casi d'uso attuali, l'approccio consigliato consiste nell'utilizzare le policy dei bucket insieme a Block Public Access; gli ACL sono considerati legacy.

Una bucket policy è un documento JSON associato direttamente al bucket S3. Specifica quali principal (utenti IAM, ruoli, account AWS, servizi o il pubblico) possono eseguire quali azioni su quali risorse (il bucket e/o specifici prefissi di chiavi). Le bucket policy supportano l'accesso tra account senza dover utilizzare ruoli IAM: è possibile concedere direttamente, nella bucket policy, a un ruolo IAM di un altro account AWS l'accesso in lettura a oggetti specifici del bucket. Ogni bucket può avere una sola policy e la dimensione massima è di 20 KB.

Per distribuire contenuti pubblici (ad esempio risorse di un sito web statico o dataset pubblici), è possibile rendere gli oggetti leggibili pubblicamente tramite una bucket policy. Per prima cosa, disabiliti Block Public Access a livello di bucket, quindi aggiunga una dichiarazione nella bucket policy con Principal: '*' e Action: s3:GetObject. Sono necessari entrambi: la disabilitazione dell'impostazione Block Public Access e l'Allow nella bucket policy; abilitarne solo uno non è sufficiente. Limiti sempre Resource a un prefisso specifico anziché all'intero bucket, a meno che non desideri intenzionalmente rendere pubblici tutti gli oggetti.

S3 Block Public Access è una rete di sicurezza con quattro impostazioni che prevalgono sulle bucket policy e sulle ACL: BlockPublicAcls (rifiuta le richieste di impostazione di ACL pubbliche), IgnorePublicAcls (ignora le ACL pubbliche esistenti), BlockPublicPolicy (rifiuta le bucket policy che concedono l'accesso pubblico) e RestrictPublicBuckets (limita l'accesso in base alla policy pubblica). Tutte e quattro le impostazioni sono abilitate per impostazione predefinita. È inoltre possibile abilitare Block Public Access a livello di account, bloccandolo per tutti i bucket indipendentemente dalle impostazioni dei singoli bucket: una soluzione ideale per prevenire l'esposizione accidentale al pubblico.

Le ACL S3 sono il meccanismo di controllo degli accessi originale, precedente a IAM. Un'ACL concede autorizzazioni predefinite (READ, WRITE, FULL_CONTROL) ad account AWS o gruppi predefiniti (tutti gli utenti, utenti AWS autenticati, distribuzione dei log). Le ACL possono essere applicate a livello di bucket o di singolo oggetto. AWS ora raccomanda di disabilitare le ACL (l'impostazione S3 'Bucket Owner Enforced' fa sì che il proprietario del bucket possieda tutti gli oggetti, disabilitando le ACL) e di utilizzare invece bucket policy e IAM. Le ACL vengono ancora trattate nell'esame SAA-C03 come concetto legacy.

Quando distribuisce contenuti S3 tramite CloudFront, desidera mantenere privato il bucket consentendo a CloudFront di recuperare gli oggetti. Utilizzi Origin Access Control (OAC), il sostituto moderno di Origin Access Identity (OAI). OAC crea un'identità CloudFront a cui concede l'autorizzazione s3:GetObject nella bucket policy, mantenendo abilitato Block Public Access. In questo modo, gli utenti devono passare da CloudFront (per caching, WAF e HTTPS) e non possono accedere direttamente al bucket: un comune modello di architettura sicura nell'esame SAA-C03.

Esistono due modi per concedere a un altro account AWS l'accesso al bucket S3. Opzione 1 — Bucket policy: aggiunga una dichiarazione con l'ARN dell'account esterno come Principal e le azioni S3 desiderate. Gli utenti e i ruoli IAM dell'account esterno devono comunque disporre delle autorizzazioni IAM per chiamare S3, oltre al fatto che la bucket policy deve concedere loro l'Allow. Opzione 2 — Ruolo IAM con trust policy: crei nel proprio account un ruolo considerato attendibile dall'account esterno; le identità dell'account esterno assumono il ruolo e ottengono le autorizzazioni sul bucket. La bucket policy è più semplice negli scenari di sola lettura; i ruoli sono preferibili per l'accesso operativo.

Cross-Origin Resource Sharing (CORS) consente a un'applicazione web ospitata su un dominio di effettuare richieste fetch JavaScript a un bucket S3 situato su un dominio diverso. Senza una configurazione CORS, i browser bloccano queste richieste per motivi di sicurezza. Aggiunga al bucket una configurazione CORS che specifichi le origini, i metodi HTTP e le intestazioni consentiti. CORS è comunemente necessario quando una SPA React ospitata su example.com recupera immagini o file direttamente dall'URL di un bucket S3.

Un pre-signed URL concede l'accesso a tempo limitato a un oggetto S3 privato (per GET o PUT) senza modificare le autorizzazioni del bucket o dell'oggetto. L'URL incorpora le credenziali e una scadenza: chiunque disponga dell'URL può accedere all'oggetto fino alla scadenza. Utilizzi i pre-signed URL per consentire agli utenti autenticati dell'app di scaricare file privati, permettere ai client di caricare direttamente su S3 senza passare dal backend oppure condividere temporaneamente dei report. La scadenza può variare da 1 secondo a 7 giorni (quando si utilizzano credenziali temporanee STS, il massimo è 12 ore).

Utilizzi le condizioni delle bucket policy per aggiungere una sicurezza basata sul contesto. Modelli comuni: aws:SourceIp limita l'accesso a intervalli IP specifici (ad esempio endpoint VPC o reti aziendali); aws:SecureTransport: true impone HTTPS negando le richieste HTTP (una best practice per tutti i bucket che archiviano dati sensibili); s3:x-amz-server-side-encryption garantisce che gli oggetti vengano caricati con la crittografia lato server; e aws:PrincipalOrgID limita l'accesso ai principal all'interno della propria Organizzazione AWS, impedendo l'esfiltrazione dei dati verso account esterni.

Per impostazione predefinita, le istanze EC2 in una subnet privata accedono a S3 tramite Internet (attraverso un NAT gateway), sostenendo costi NAT ed esponendo il traffico a Internet pubblico. Gli S3 Gateway Endpoint forniscono connettività privata a S3 dall'interno di una VPC senza un NAT gateway e senza costi aggiuntivi. Aggiunga il Gateway Endpoint alla tabella di routing: il traffico verso S3 viene instradato automaticamente attraverso la rete privata di AWS. È inoltre possibile aggiungere condizioni alla bucket policy usando aws:SourceVpce per limitare l'accesso alle sole richieste che passano dall'endpoint.

Verifichi la propria comprensione dei concetti di AWS Solutions Architect (SAA-C03) presentati in questa lezione.

In questa lezione ha imparato che: le bucket policy sono documenti JSON basati sulle risorse che controllano l'accesso tra account e l'accesso dei servizi a S3, S3 Block Public Access è un meccanismo di sicurezza che impedisce l'esposizione accidentale al pubblico e pre-signed URL, endpoint VPC e configurazioni CORS rispondono in modo sicuro a specifici modelli di accesso. Nella prossima lezione tratteremo il versioning S3, MFA Delete e la replica.