Account di archiviazione Azure

Un Azure Storage Account è la risorsa fondamentale che consente di accedere ai servizi di archiviazione principali di Azure: Blob Storage (archiviazione di oggetti), Azure Files (condivisioni file gestite), Queue Storage (code di messaggi), Table Storage (archivio NoSQL chiave-valore) e Azure Data Lake Storage Gen2 (namespace gerarchico per l'analisi). Un singolo storage account può ospitare contemporaneamente tutti questi servizi e fornisce un namespace univoco in Azure: il nome dell'account diventa parte dell'URL di ogni oggetto che contiene.

Azure offre diversi tipi di storage account: Standard general-purpose v2 (GPv2) — il tipo consigliato per la maggior parte degli scenari; supporta tutti i servizi di archiviazione e le opzioni di ridondanza con prestazioni standard. Premium block blobs — archiviazione basata su SSD per gli scenari che richiedono una latenza molto bassa per le operazioni di Blob Storage. Premium file shares — condivisioni Azure Files basate su SSD per carichi di lavoro con IOPS elevati, come database o directory home. Premium page blobs — archiviazione SSD per i dischi del sistema operativo e dei dati delle VM Azure (Managed Disks la utilizzano internamente). Per la maggior parte dei casi d'uso, inizi con un account Standard GPv2.

Azure Storage replica automaticamente i dati per proteggerli dai guasti hardware. Le quattro opzioni di ridondanza sono: LRS (Locally Redundant Storage) — tre copie sincrone all'interno di un singolo datacenter. ZRS (Zone-Redundant Storage) — tre copie sincrone distribuite tra tre zone di disponibilità nella stessa area. GRS (Geo-Redundant Storage) — LRS nell'area primaria e replica asincrona in un'area secondaria (LRS). GZRS (Geo-Zone-Redundant Storage) — ZRS nell'area primaria e replica asincrona in un'area secondaria. Una maggiore ridondanza comporta una durabilità e un costo più elevati.

Scelga il livello di ridondanza in base ai requisiti di RTO, RPO e budget: LRS — è l'opzione più economica, offre una durabilità di 11 nove, ma non protegge dai guasti del datacenter. La utilizzi per gli ambienti di sviluppo/test o per dati che può ricreare. ZRS — protegge dai guasti del datacenter ed è adatto ai dati di produzione in una singola area. GRS/GZRS — protegge dall'interruzione di un'intera area Azure; i dati vengono replicati asincronamente nell'area abbinata. Per i dati aziendali critici che devono sopravvivere a un'emergenza regionale, GRS o GZRS è la scelta appropriata, nonostante il costo aggiuntivo.

Azure Storage offre due livelli di prestazioni: Standard — basato su unità disco rigido (HDD), adatto alla maggior parte dei carichi di lavoro con un costo per GB inferiore. Premium — basato su unità a stato solido (SSD), progettato per gli scenari sensibili alla latenza che richiedono operazioni di I/O nell'ordine dei millisecondi a una cifra. Lo storage Standard viene fatturato per ogni GB archiviato; il livello Premium è più costoso per GB, ma offre prestazioni costanti e prevedibili. Per risorse web, backup, log e archiviazione a lungo termine, Standard è appropriato. Per VM con database a elevato utilizzo di I/O o condivisioni file utilizzate da utenti desktop, Premium è la scelta migliore.

I nomi degli storage account devono essere univoci a livello globale in Azure (perché formano parte di un nome DNS pubblico come mystorageacct.blob.core.windows.net). I nomi devono contenere da 3 a 24 caratteri e solo lettere minuscole e numeri: non sono consentiti trattini, caratteri di sottolineatura o lettere maiuscole. Poiché i nomi devono essere univoci a livello globale, le parole comuni e i nomi di marchi sono già utilizzati. È buona pratica combinare un prefisso aziendale, l'ambiente (prod/dev) e lo scopo (store/media), quindi aggiungere un suffisso casuale se necessario: ad esempio contosoprodmedia7x2.

Ogni storage account dispone di due chiavi di accesso a 512 bit che concedono l'accesso amministrativo completo a tutto ciò che contiene l'account. Queste chiavi devono essere trattate come password e archiviate in Azure Key Vault, anziché nel codice o nei file di configurazione. Azure genera due chiavi per consentire la rotazione delle chiavi senza interruzioni: aggiorni le applicazioni affinché utilizzino Key 2, quindi rigeneri Key 1, aggiorni le applicazioni affinché utilizzino Key 1 e infine rigeneri Key 2. Per un controllo degli accessi più granulare, utilizzi Shared Access Signatures (SAS) o Azure RBAC invece di condividere le chiavi master.

Azure RBAC (Role-Based Access Control) è il metodo consigliato per autorizzare l'accesso ai dati di archiviazione senza condividere le chiavi. Assegni il ruolo Storage Blob Data Reader per consentire l'accesso in sola lettura a Blob Storage, oppure Storage Blob Data Contributor per consentire la lettura e la scrittura. Questi ruoli vengono assegnati a utenti, gruppi o identità gestite di Entra ID, quindi l'accesso è associato a un'identità autenticata anziché a un segreto condiviso. L'autorizzazione RBAC per lo storage è disponibile per i servizi Blob, Queue e Table (non per File, che utilizza i protocolli SMB/NFS con i propri controlli di accesso).

Per impostazione predefinita, gli storage account accettano connessioni da qualsiasi rete. Per la sicurezza degli ambienti di produzione, limiti l'accesso utilizzando il Firewall dello Storage Account: consenta solo intervalli di indirizzi IP pubblici o subnet di reti virtuali specifici. Per il massimo livello di sicurezza, disabiliti completamente l'accesso a Internet pubblico e utilizzi un Private Endpoint: un indirizzo IP privato all'interno della VNet che instrada il traffico verso lo storage account attraverso la rete privata di Azure, senza mai esporlo su Internet pubblico. I Private Endpoint sono l'approccio consigliato per gli storage account che contengono dati sensibili o soggetti a normative.

Azure Storage offre funzionalità integrate di protezione dei dati per difendersi dalle eliminazioni accidentali: Blob soft delete — i blob eliminati e le relative versioni vengono conservati per un periodo configurabile (da 1 a 365 giorni) e possono essere recuperati senza ripristinarli da un backup. Blob versioning — ogni sovrascrittura crea una nuova versione, consentendo di ripristinare qualsiasi versione precedente di un blob. Container soft delete — i container eliminati accidentalmente possono essere recuperati. Queste funzionalità sono disabilitate per impostazione predefinita e devono essere abilitate per gli storage account di produzione che contengono dati importanti non sottoposti a backup altrove.

Azure Monitor raccoglie automaticamente le metriche per ogni storage account: capacità totale utilizzata, numero di transazioni, byte in ingresso e in uscita e latenza end-to-end. Può visualizzarle nel pannello Insights del portale Azure per il Suo storage account, che offre grafici predefiniti per capacità, disponibilità e prestazioni. Per un controllo dettagliato degli accessi, abiliti i Storage Diagnostic Logs per registrare ogni operazione di lettura, scrittura ed eliminazione in una destinazione di log: sono utili per le indagini di sicurezza e la reportistica di conformità.

Verifichi la Sua comprensione dei concetti di Microsoft Azure Fundamentals (AZ-900) trattati in questa lezione.

In questa lezione ha imparato che: uno storage account è la risorsa radice per tutti i servizi di archiviazione di Azure ed è identificato da un nome univoco a livello globale, le opzioni di ridondanza — LRS, ZRS, GRS e GZRS — offrono livelli crescenti di durabilità a costi crescenti e l'accesso deve essere controllato tramite RBAC e Private Endpoint anziché condividendo le chiavi di accesso master. Ora approfondiremo Blob Storage, l'archivio di oggetti di Azure per i dati non strutturati.