Az - Storage Accounts & Blobs
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Gli Azure Storage Accounts sono servizi fondamentali in Microsoft Azure che forniscono storage cloud scalabile, sicuro e altamente disponibile per vari tipi di dati, inclusi blob (oggetti binari di grandi dimensioni), file, code e tabelle. Servono come contenitori che raggruppano questi diversi servizi di storage sotto un unico namespace per una gestione più semplice.
Opzioni di configurazione principali:
Ogni storage account deve avere un nome unico in tutti gli Azure.
Ogni storage account è distribuito in una regione o in una zona estesa di Azure.
È possibile selezionare la versione premium dello storage account per migliori prestazioni.
È possibile scegliere tra 4 tipi di ridondanza per proteggere contro guasti di rack, disco e datacenter.
Opzioni di configurazione della sicurezza:
Richiedere il trasferimento sicuro per le operazioni REST API: Richiedere TLS in qualsiasi comunicazione con lo storage.
Consente di abilitare l'accesso anonimo su contenitori individuali: Se non lo si fa, non sarà possibile abilitare l'accesso anonimo in futuro.
Abilitare l'accesso con chiave dello storage account: Se non lo si fa, l'accesso con chiavi condivise sarà vietato.
Versione minima TLS.
Ambito consentito per le operazioni di copia: Consenti da qualsiasi storage account, da qualsiasi storage account dello stesso tenant Entra o da storage account con endpoint privati nella stessa rete virtuale.
Opzioni di Blob Storage:
Consenti la replica cross-tenant.
Livello di accesso: Hot (dati accessibili frequentemente), Cool e Cold (dati raramente accessibili).
Opzioni di rete:
Accesso di rete:
Consenti da tutte le reti.
Consenti da reti virtuali e indirizzi IP selezionati.
Disabilita l'accesso pubblico e utilizza l'accesso privato.
Endpoint privati: Consente una connessione privata allo storage account da una rete virtuale.
Opzioni di protezione dei dati:
Ripristino point-in-time per contenitori: Consente di ripristinare i contenitori a uno stato precedente.
Richiede che la versioning, il change feed e la cancellazione soft dei blob siano abilitati.
Abilitare la cancellazione soft per i blob: Abilita un periodo di retention in giorni per i blob eliminati (anche sovrascritti).
Abilitare la cancellazione soft per i contenitori: Abilita un periodo di retention in giorni per i contenitori eliminati.
Abilitare la cancellazione soft per le condivisioni di file: Abilita un periodo di retention in giorni per le condivisioni di file eliminate.
Abilitare la versioning per i blob: Mantieni le versioni precedenti dei tuoi blob.
Abilitare il change feed dei blob: Tieni traccia dei log di creazione, modifica e cancellazione dei blob.
Abilitare il supporto per l'immutabilità a livello di versione: Consente di impostare una politica di retention basata sul tempo a livello di account che si applicherà a tutte le versioni dei blob.
Il supporto per l'immutabilità a livello di versione e il ripristino point-in-time per i contenitori non possono essere abilitati simultaneamente.
Opzioni di configurazione della crittografia:
Tipo di crittografia: È possibile utilizzare chiavi gestite da Microsoft (MMK) o chiavi gestite dal cliente (CMK).
Abilitare la crittografia dell'infrastruttura: Consente di crittografare i dati due volte "per maggiore sicurezza".
Blob storage |
|
Data Lake Storage |
|
Azure Files |
|
Queue storage |
|
Table storage |
|
Se "Consenti accesso pubblico ai blob" è abilitato (disabilitato per impostazione predefinita), quando si crea un contenitore è possibile:
Dare accesso pubblico per leggere i blob (è necessario conoscere il nome).
Elencare i blob del contenitore e leggerli.
Renderlo completamente privato.
Se trovi qualche storage a cui puoi connetterti, puoi utilizzare lo strumento Microsoft Azure Storage Explorer per farlo.
È possibile utilizzare i principi di Entra ID con ruoli RBAC per accedere agli storage account ed è il modo raccomandato.
Gli storage account hanno chiavi di accesso che possono essere utilizzate per accedervi. Questo fornisce accesso completo allo storage account.
È possibile generare Chiavi Condivise firmate con le chiavi di accesso per autorizzare l'accesso a determinate risorse tramite un URL firmato.
Nota che la parte CanonicalizedResource
rappresenta la risorsa dei servizi di storage (URI). E se qualche parte nell'URL è codificata, dovrebbe essere codificata anche all'interno del CanonicalizedResource
.
Questo è utilizzato per impostazione predefinita da az
cli per autenticare le richieste. Per farlo utilizzare le credenziali del principale Entra ID, indica il parametro --auth-mode login
.
È possibile generare una chiave condivisa per i servizi blob, queue e file firmando le seguenti informazioni:
È possibile generare una chiave condivisa per i servizi di tabella firmando le seguenti informazioni:
È possibile generare una chiave condivisa leggera per i servizi blob, coda e file firmando le seguenti informazioni:
È possibile generare una chiave condivisa leggera per i servizi di tabella firmando le seguenti informazioni:
Poi, per utilizzare la chiave, può essere fatto nell'intestazione di autorizzazione seguendo la sintassi:
Le Shared Access Signatures (SAS) sono URL sicuri e limitati nel tempo che concedono permessi specifici per accedere alle risorse in un account di Azure Storage senza esporre le chiavi di accesso dell'account. Mentre le chiavi di accesso forniscono accesso amministrativo completo a tutte le risorse, le SAS consentono un controllo granulare specificando i permessi (come lettura o scrittura) e definendo un tempo di scadenza.
User delegation SAS: Questa viene creata da un principale Entra ID che firmerà la SAS e delega i permessi dall'utente alla SAS. Può essere utilizzata solo con blob e data lake storage (docs). È possibile revocare tutte le SAS delegate generate dall'utente.
Anche se è possibile generare una SAS di delega con "più" permessi di quelli che l'utente ha. Tuttavia, se il principale non li possiede, non funzionerà (no privesc).
Service SAS: Questa è firmata utilizzando una delle chiavi di accesso dell'account di storage. Può essere utilizzata per concedere accesso a risorse specifiche in un singolo servizio di storage. Se la chiave viene rinnovata, la SAS smetterà di funzionare.
Account SAS: È anch'essa firmata con una delle chiavi di accesso dell'account di storage. Concede accesso a risorse attraverso i servizi di un account di storage (Blob, Queue, Table, File) e può includere operazioni a livello di servizio.
Un URL SAS firmato da una chiave di accesso appare così:
https://<container_name>.blob.core.windows.net/newcontainer?sp=r&st=2021-09-26T18:15:21Z&se=2021-10-27T02:14:21Z&spr=https&sv=2021-07-08&sr=c&sig=7S%2BZySOgy4aA3Dk0V1cJyTSIf1cW%2Fu3WFkhHV32%2B4PE%3D
Un URL SAS firmato come user delegation appare così:
https://<container_name>.blob.core.windows.net/testing-container?sp=r&st=2024-11-22T15:07:40Z&se=2024-11-22T23:07:40Z&skoid=d77c71a1-96e7-483d-bd51-bd753aa66e62&sktid=fdd066e1-ee37-49bc-b08f-d0e152119b04&skt=2024-11-22T15:07:40Z&ske=2024-11-22T23:07:40Z&sks=b&skv=2022-11-02&spr=https&sv=2022-11-02&sr=c&sig=7s5dJyeE6klUNRulUj9TNL0tMj2K7mtxyRc97xbYDqs%3D
Nota alcuni parametri http:
Il parametro se
indica la data di scadenza della SAS
Il parametro sp
indica i permessi della SAS
Il sig
è la firma che convalida la SAS
Quando si genera una SAS è necessario indicare i permessi che dovrebbe concedere. A seconda dell'oggetto su cui viene generata la SAS, potrebbero essere inclusi permessi diversi. Ad esempio:
(a)dd, (c)reate, (d)elete, (e)xecute, (f)ilter_by_tags, (i)set_immutability_policy, (l)ist, (m)ove, (r)ead, (t)ag, (w)rite, (x)delete_previous_version, (y)permanent_delete
Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)