Ciascuno dei tre grandi provider ha, al di sopra del singolo bucket, un interruttore che prevale su qualsiasi configurazione impostata a un livello inferiore. Il Suo pomeriggio ha due compiti: individuare ciò che è già aperto e poi attivare questi interruttori, in modo che la prossima policy incauta non produca alcun effetto. Li svolga in quest'ordine, perché gli interruttori interromperanno tutto ciò che dipende dall'essere pubblico.
Che cosa significa "pubblico" su ciascuna piattaforma
Le definizioni differiscono e l'audit deve cercarle tutte.
| Piattaforma | Che cosa lo rende pubblico | Guardrail che lo sovrascrive |
|---|---|---|
| AWS S3 | ACL che concedono accesso ai gruppi AllUsers o AuthenticatedUsers, oppure una bucket policy non dimostrabilmente non pubblica | Block Public Access, a livello di account o di organizzazione |
| Azure Blob | L'account consente l'accesso anonimo e il livello del container è impostato su Container o Blob | AllowBlobPublicAccess impostato su False sullo storage account |
| Google Cloud Storage | allUsers o allAuthenticatedUsers in una policy IAM del bucket o in una ACL dell'oggetto | Public access prevention, per singolo bucket o tramite il vincolo storage.publicAccessPrevention |
S3 considera pubblica una bucket policy finché non si dimostra il contrario. La policy è non pubblica solo se concede l'accesso a valori fissi, senza wildcard né variabili di policy, come un principal specifico o un insieme di blocchi CIDR tramite aws:SourceIp. Un principal con wildcard, quindi, non supera il test.
Su Azure devono verificarsi entrambe le condizioni. Se l'account non consente l'accesso anonimo, l'impostazione del container è irrilevante. Se lo consente, un container resta comunque privato finché qualcuno non ne imposta il livello su Container o Blob.
Passo 1: individuare ciò che è aperto
S3. La guida AWS indica IAM Access Analyzer for S3 per la revisione dei bucket pubblici, quindi parta da lì. Verifichi poi le quattro impostazioni di Block Public Access su ciascun account: BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy e RestrictPublicBuckets. Si noti che GetBucketAcl restituisce i permessi effettivi. Un bucket con una ACL pubblica e IgnorePublicAcls attivo mostrerà una ACL che nasconde quella reale.
Azure. Il portale fornisce innanzitutto il conteggio delle richieste anonime. Nello storage account apra Monitoring, quindi Metrics. Usi il namespace Blob, la metrica Transactions, l'aggregazione Sum e aggiunga un filtro con Authentication uguale ad Anonymous.
Per vedere quali container sono coinvolti, crei un diagnostic setting che invii i log a un workspace Log Analytics. Esegua poi questa query, che copre gli ultimi sette giorni:
StorageBlobLogs
| where TimeGenerated > ago(7d) and AuthenticationType == "Anonymous"
| project TimeGenerated, AccountName, AuthenticationType, UriLa colonna Uri indica i container e i blob che vengono letti. Metriche e log mostrano solo chi legge in modo anonimo, non che cosa sia esposto: un container aperto che nessuno ha richiesto resta quindi invisibile. Verifichi anche i livelli di accesso dei container.
Google Cloud. Ispezioni le policy IAM dei bucket alla ricerca di ruoli assegnati a allUsers o allAuthenticatedUsers. Cloud Asset Inventory mostra le policy di tutti i bucket in un progetto, una cartella o un'organizzazione, evitando di procedere bucket per bucket. Le ACL degli oggetti richiedono un controllo separato e le managed folder hanno proprie policy IAM. Attivi gli usage log per vedere quali workload accedono a dati pubblici. Cloud Audit Logs non traccia l'accesso agli oggetti pubblici, quindi in questo caso non è utile.
Passo 2: attivare i guardrail
S3. AWS raccomanda di abilitare tutte e quattro le impostazioni a livello di account. Raccomanda inoltre di abilitarle tutte e quattro anche su ogni bucket, per soddisfare il controllo S3.8 di Security Hub. Per più account, utilizzi una policy a livello di organizzazione. Tale policy è del tipo tutto o niente, senza scelta per singola impostazione, e prevale sulle impostazioni a livello di account negli account membri selezionati. S3 applica la combinazione più restrittiva tra i vari livelli, quindi un bucket non può indebolire ciò che l'account impone.
Applichi BlockPublicPolicy in particolare a livello di account. In caso contrario, chiunque possa modificare una bucket policy può inserirne una che disattiva l'impostazione a livello di bucket. Le modifiche a livello di account si applicano a tutte le Region, ma potrebbero non propagarsi ovunque nello stesso momento. Le impostazioni degli access point si definiscono solo alla creazione, quindi li verifichi separatamente.
Azure. Imposti AllowBlobPublicAccess su False su ogni storage account. Questo prevale su qualsiasi impostazione dei container, quindi non è necessario intervenire sui container stessi. Richiede la versione 2019-04-01 o successiva dell'Azure Storage resource provider. L'utente deve disporre di Microsoft.Storage/storageAccounts/write, incluso nei ruoli Owner, Contributor e Storage Account Contributor. Mantenga ristrette queste assegnazioni.
Google Cloud. Imponga la public access prevention sui bucket, oppure imposti il vincolo di organization policy storage.publicAccessPrevention a livello di progetto, cartella o organizzazione. Google consiglia di applicarlo al livello più alto possibile. Lo stato di un bucket è enforced oppure inherited. Un bucket con l'impostazione enforced resta enforced anche se in seguito si disattiva il vincolo a un livello superiore.
Che cosa si interromperà e che cosa no
Pianifichi i malfunzionamenti, perché è proprio questo lo scopo dell'esercizio.
- S3: le impostazioni non modificano le policy o le ACL esistenti. Rimuovendo un'impostazione, tutto ciò che ha una policy o una ACL pubblica torna a essere pubblico, quindi ripulisca anche i permessi sottostanti. Riveda inoltre le policy basate sull'identità e le resource policy, come le key policy di KMS, che Block Public Access non copre.
- Azure: le letture anonime iniziano a fallire. Il codice di errore dipende dalla versione del servizio: 401 per le versioni 2019-12-12 e successive, altrimenti 409 quando l'account non consente l'accesso anonimo e 404 quando lo consente.
- Google Cloud: le richieste che usano
allUsersfalliscono con HTTP 401 o 403. I binding esistenti restano al loro posto ma vengono sovrascritti. I tentativi di aggiungerne di nuovi falliscono con412 Precondition Failed. Gli URL firmati non sono interessati. L'applicazione può richiedere fino a 10 minuti e gli oggetti in cache possono restare pubblici per la durata diCache-Control, che per impostazione predefinita è di 3600 secondi.
I contenuti realmente pubblici, come un sito web statico, richiedono un'eccezione. Azure consiglia di spostarli in uno storage account separato riservato all'accesso anonimo. Su Google Cloud, disattivi la prevention sullo specifico progetto che contiene il bucket. In S3, personalizzi le singole impostazioni per i bucket che ne hanno bisogno.
Da dove iniziare
- Elenchi ogni account AWS, sottoscrizione Azure e progetto Google Cloud che contiene storage, compresi quelli di cui nessuno ricorda la creazione.
- Esegua la discovery descritta sopra: Access Analyzer for S3, la metrica e la query di log Azure sulle richieste anonime e Cloud Asset Inventory per le policy IAM dei bucket.
- Per ogni riscontro pubblico, stabilisca se sia intenzionale. Sposti i contenuti pubblici legittimi in account o progetti dedicati.
- Abiliti i controlli a livello di account o di organizzazione: tutte e quattro le impostazioni S3,
AllowBlobPublicAccessimpostato su False e il vincolostorage.publicAccessPrevention. - Riesegua le query dopo qualche giorno per confermare che le richieste anonime siano scese a zero e imposti un alert sulla metrica Azure delle richieste anonime.
- Se desidera una verifica esterna di ciò che resta raggiungibile, il nostro servizio di penetration testing copre l'esposizione cloud e il nostro team di consulenza può rivedere la struttura dei Suoi account.
