Isolamento nel cloud pubblico di Azure

Azure consente di eseguire applicazioni e macchine virtuali in un'infrastruttura fisica condivisa. Uno dei motivi economici principali per l'esecuzione di applicazioni in un ambiente cloud è la possibilità di distribuire il costo delle risorse condivise tra più clienti. Questa pratica di multi-tenancy aumenta l'efficienza grazie al multiplexing delle risorse tra i diversi clienti a costi ridotti, ma introduce purtroppo i rischi correlati alla condivisione di server fisici e altre risorse dell'infrastruttura per l'esecuzione di applicazioni sensibili del cliente insieme a VM che possono appartenere a un utente qualsiasi, potenzialmente malintenzionato.

Questo articolo illustra l'isolamento dagli utenti malintenzionati e non offerto da Azure e funge da guida per la progettazione di soluzioni cloud offrendo diverse opzioni di isolamento per gli architetti.

Isolamento a livello di tenant

Uno dei vantaggi principali del cloud computing è il concetto di un'infrastruttura comune condivisa tra numerosi clienti contemporaneamente, determinando economie di scala. Questo concetto è denominato "multi-tenancy". Microsoft lavora costantemente per garantire che l'architettura multi-tenant dei servizi cloud di Microsoft Azure supporti gli standard di sicurezza, riservatezza, privacy, integrità e disponibilità.

Nell'area di lavoro abilitata per il cloud, un tenant può essere definito come un client o un'organizzazione che possiede e gestisce un'istanza specifica di tale servizio cloud. Con la piattaforma delle identità fornita da Microsoft Azure, un tenant è semplicemente un'istanza dedicata di Microsoft Entra ID che l'organizzazione riceve e di cui diventa proprietaria quando effettua l'iscrizione a un servizio cloud Microsoft.

Ogni directory di Microsoft Entra è distinta e separata da altre directory di Microsoft Entra. Proprio come un edificio di uffici è un asset sicuro specifico dell'organizzazione che vi ha sede, una directory di Microsoft Entra è stata progettata come asset sicuro usato solo dall'organizzazione proprietaria. L'architettura di Microsoft Entra isola le informazioni relative all'identità e i dati dei clienti evitando che si combinino con altri. Questo significa che gli utenti e gli amministratori di una directory di Microsoft Entra non possono accedere accidentalmente o malintenzionatamente ai dati presenti in un'altra directory.

Tenancy di Azure

Il concetto di tenancy di Azure (sottoscrizione di Azure) fa riferimento a una relazione "cliente/fatturazione" e a un tenant univoco in Microsoft Entra ID. L'isolamento a livello di tenant in Microsoft Azure viene ottenuto usando Microsoft Entra ID e il controllo degli accessi in base al ruolo di Azure offerto. Ogni sottoscrizione di Azure è associata a una directory di Microsoft Entra.

Gli utenti, i gruppi e le applicazioni da tale directory possono gestire le risorse nella sottoscrizione di Azure. È possibile assegnare questi diritti di accesso tramite il portale di Azure, gli strumenti da riga di comando di Azure o le API Gestione di Azure. Un tenant di Microsoft Entra viene isolato in modo logico usando limiti di sicurezza in modo che nessun cliente possa accedere a co-tenant e comprometterli, malintenzionatamente o accidentalmente. Microsoft Entra ID viene eseguito in server "bare metal" isolati in un segmento di rete separato, in cui il filtro dei pacchetti a livello di host e Windows Firewall bloccano connessioni e traffico indesiderati.

• L'accesso ai dati in Microsoft Entra ID richiede l'autenticazione utente tramite un servizio token di sicurezza. Le informazioni relative a esistenza, stato abilitato e ruolo dell'utente vengono usate dal sistema di autorizzazione per determinare se l'accesso richiesto al tenant di destinazione è autorizzato per l'utente corrente in questa sessione.

• I tenant sono contenitori separati che non hanno alcuna relazione tra loro.

• Non è possibile l'accesso da un tenant all'altro, a meno che l'amministratore non lo conceda tramite la federazione o il provisioning degli account utente da altri tenant.

• L'accesso fisico ai server che comprendono il servizio Microsoft Entra e l'accesso diretto ai sistemi back-end di Microsoft Entra ID sono limitati.

• Gli utenti di Microsoft Entra non hanno accesso ad asset fisici o posizioni, pertanto non è possibile ignorare i controlli logici del controllo degli accessi in base al ruolo di Azure indicati di seguito.

Per esigenze di diagnostica e manutenzione, è necessario e viene usato un modello operativo che impiega un sistema di elevazione dei privilegi just-in-time. Privileged Identity Management (PIM) di Microsoft Entra introduce il concetto di amministratore idoneo. Gli amministratori idonei devono essere utenti che necessitano di accesso con privilegi ora e in seguito, ma non ogni giorno. Il ruolo è inattivo fino a quando l'utente che necessita dell'accesso non completa un processo di attivazione e diventa amministratore attivo per un periodo di tempo predeterminato.

Microsoft Entra ID ospita ogni tenant nel proprio contenitore protetto, con criteri e autorizzazioni per il contenitore e gli elementi al suo interno gestiti esclusivamente dal tenant che ne è anche proprietario.

Il concetto dei contenitori di tenant è profondamente radicato nel servizio directory a tutti i livelli, dai portali fino all'archivio permanente.

Anche quando i metadati di più tenant di Microsoft Entra vengono archiviati nello stesso disco fisico, non esistono relazioni tra i contenitori tranne quelle definite dal servizio directory, che a sua volta è determinato dall'amministratore tenant.

Controllo degli accessi in base al ruolo di Azure

Il controllo degli accessi in base al ruolo di Azure consente di condividere vari componenti disponibili all'interno di una sottoscrizione di Azure fornendo una gestione degli accessi con granularità fine per Azure. Il controllo degli accessi in base al ruolo di Azure consente di separare i compiti all'interno dell'organizzazione e di concedere l'accesso in base alle attività che i singoli utenti devono svolgere. Invece di concedere a tutti autorizzazioni senza restrizioni per la sottoscrizione o le risorse di Azure, è possibile consentire solo determinate azioni.

Il Controllo degli accessi in base al ruolo di Azure include di tre ruoli di base che si applicano a tutti i tipi di risorsa:

• Proprietario: dispone dell'accesso completo a tutte le risorse, incluso il diritto di delegare l'accesso ad altri.

• Collaboratore: può creare e gestire tutti i tipi di risorse di Azure, ma non può concedere l'accesso ad altri.

• Lettore: può visualizzare le risorse di Azure esistenti.

Il resto dei ruoli di Azure in Azure consente la gestione di risorse di Azure specifiche. Ad esempio, il ruolo Collaboratore Macchina virtuale consente all'utente di creare e gestire macchine virtuali. Non concede l'accesso alla rete virtuale di Azure o alla subnet a cui si connette la macchina virtuale.

Ruoli predefiniti di Azure: elenca i ruoli disponibili in Azure. Specifica le operazioni e l'ambito che ogni ruolo predefinito concede agli utenti. Per definire ruoli personalizzati per un maggiore controllo, vedere come creare ruoli personalizzati nel Controllo degli accessi in base al ruolo di Azure.

Alcune altre funzionalità per Microsoft Entra ID includono:

• Microsoft Entra ID consente l'accesso Single Sign-On alle applicazioni SaaS, indipendentemente dalla posizione in cui sono ospitate. Alcune applicazioni sono federate con Microsoft Entra ID e altre usano l'accesso SSO con password. Le applicazioni federate possono anche supportare il provisioning utenti e l'insieme di credenziali delle password.

• L'accesso ai dati in Archiviazione di Azure è controllato dall'autenticazione. Ogni account di archiviazione ha una chiave primaria (chiave dell'account di archiviazione) e una chiave privata secondaria (firma di accesso condiviso).

• Microsoft Entra ID fornisce l'identità come servizio tramite federazione usando Active Directory Federation Services, la sincronizzazione e la replica con directory locali.

• L'autenticazione a più fattori di Microsoft Entra richiede agli utenti di verificare gli accessi usando un'app per dispositivi mobili, una telefonata o un SMS. Può essere usata con Microsoft Entra AD per la protezione di risorse locali con il server Multi-Factor Authentication e anche con applicazioni e directory personalizzate che usano l'SDK.

• Microsoft Entra Domain Services consente di aggiungere macchine virtuali di Azure a un dominio di Active Directory senza distribuire controller di dominio. È possibile accedere a queste macchine virtuali con le credenziali di Active Directory aziendali e amministrare le macchine virtuali aggiunte a un dominio usando Criteri di gruppo per applicare le baseline della sicurezza in tutte le macchine virtuali di Azure.

• Microsoft Entra External ID offre un servizio di gestione delle identità globale a disponibilità elevata per le applicazioni rivolte agli utenti che si adattano a centinaia di milioni di identità. Il servizio può essere integrato tra piattaforme mobili e Web. Gli utenti possono accedere a tutte le applicazioni attraverso esperienze personalizzabili usando gli account dei propri social network esistenti o creando credenziali.

Isolamento da amministratori Microsoft ed eliminazione di dati

Microsoft adotta misure sicure per proteggere i dati da accessi e usi impropri da parte di persone non autorizzate. Questi processi operativi e controlli sono supportati dalle condizioni di Microsoft Online Services, che offrono impegni contrattuali che regolano l'accesso ai dati.

• I tecnici Microsoft non dispongono dell'accesso predefinito ai dati nel cloud. L'accesso viene loro concesso sotto supervisione e solo quando necessario. Viene anche attentamente controllato e registrato e revocato quando non è più necessario.
• Microsoft può ricorrere ad altre società per la fornitura di servizi limitati per suo conto. Le società esterne possono accedere ai dati dei clienti solo per fornire i servizi dei quali sono state incaricate e non sono autorizzate a usare i dati per altri scopi. Sono anche vincolate per contratto a tutelare la riservatezza delle informazioni dei clienti.

I servizi aziendali con certificazioni sottoposte a auditing, ad esempio ISO/IEC 27001, vengono verificati regolarmente da Microsoft e da società di auditing accreditate tramite controlli a campione per attestare che l'accesso avvenga solo per scopi commerciali legittimi. Il cliente può accedere ai propri dati in qualsiasi momento e per qualunque motivo.

Se si eliminano dati, Microsoft Azure elimina i dati, comprese le eventuali copie memorizzate nella cache o di backup. Per i servizi nell'ambito, l'eliminazione verrà eseguita entro 90 giorni dal termine del periodo di conservazione. I servizi nell'ambito sono definiti nella sezione Condizioni per l'elaborazione dei dati delle condizioni di Microsoft Online Services.

Se in un'unità disco usata per l'archiviazione si verifica un errore hardware, l'unità verrà cancellata o distrutta in modo sicuro prima che Microsoft la restituisca al produttore per la sostituzione o la riparazione. I dati presenti nell'unità verranno sovrascritti per garantire che non possano essere recuperati in alcun modo.

Isolamento del calcolo

Microsoft Azure offre numerosi servizi di calcolo basati sul cloud che includono un'ampia gamma di istanze e servizi di calcolo con scalabilità automatica per soddisfare le esigenze dell'applicazione o dell'organizzazione. Tali istanze e servizi di calcolo offrono l'isolamento a più livelli per proteggere i dati senza sacrificare la flessibilità di configurazione richiesta dai clienti.

Dimensioni delle macchine virtuali con piano Isolato

Calcolo di Azure offre dimensioni di macchine virtuali isolate per uno specifico tipo di hardware e dedicate a un singolo cliente. Le dimensioni isolate sono attive e operano su una generazione hardware specifica e verranno deprecate quando la generazione dell'hardware verrà ritirata o sarà disponibile una nuova generazione hardware.

Le dimensioni delle macchine virtuali isolate sono più adatte ai carichi di lavoro che richiedono un livello elevato di isolamento dai carichi di lavoro di altri clienti. Questo è talvolta necessario per soddisfare i requisiti normativi e di conformità. L'utilizzo di dimensioni con piano Isolato garantisce che la macchina virtuale sia l'unica in esecuzione nell'istanza specifica del server.

Inoltre, poiché le macchine virtuali con dimensioni isolate sono di grandi dimensioni, i clienti possono scegliere di suddividere le risorse di queste macchine virtuali usando il supporto tecnico di Azure per le macchine virtuali nidificate.

Le offerte di macchine virtuali con piano Isolato correnti includono:

• Standard_E80ids_v4
• Standard_E80is_v4
• Standard_E104i_v5
• Standard_E104is_v5
• Standard_E104id_v5
• Standard_E104ids_v5
• M192is_v2 Standard
• M192ims_v2 Standard
• M192ids_v2 Standard
• M192idms_v2 Standard
• Standard_F72s_v2
• Standard_M832ids_16_v3
• Standard_M832is_16_v3
• Standard_M896ixds_24_v3
• Standard_M896ixds_32_v3
• Standard_M1792ixds_32_v3

Note

Le dimensioni delle macchine virtuali isolate hanno una durata limitata a causa della deprecazione hardware.

Deprecazione delle dimensioni delle macchine virtuali isolate

Le dimensioni di VM di tipo Isolato hanno una durata limitata dell'hardware. Azure emetterà promemoria 12 mesi prima della data di deprecazione ufficiale delle dimensioni e fornirà un'offerta isolata aggiornata da valutare. Per le dimensioni seguenti è stato annunciato il ritiro.

Dimensione	Data del ritiro dell'isolamento
Standard_DS15_v2	sabato 15 maggio 2021
Standard_D15_v2	sabato 15 maggio 2021
Standard_G5	15 febbraio 2022
Standard_GS5	15 febbraio 2022
Standard_E64i_v3	15 febbraio 2022
Standard_E64is_v3	15 febbraio 2022
M192is_v2 Standard	31 marzo 2027
M192ims_v2 Standard	31 marzo 2027
M192ids_v2 Standard	31 marzo 2027
M192idms_v2 Standard	31 marzo 2027

Domande frequenti

D: Verranno ritirate solo le dimensioni o verrà ritirata solo la relativa funzionalità di "isolamento"?

R: Verranno ritirate le dimensioni pubblicate come isolate ma senza "i" nel nome, la funzionalità di isolamento delle dimensioni delle macchine virtuali verrà ritirata a meno che non venga comunicato diversamente. Le dimensioni con "i" nel nome verranno deprecate.

D: Si verifica un tempo di inattività quando la macchina virtuale si trova in un hardware non isolato?

R: Per le dimensioni delle macchine virtuali, dove verrà deprecato solo l'isolamento ma non le dimensioni, non è necessaria alcuna azione e non ci saranno tempi di inattività. Al contrario, se è necessario l'isolamento, l'annuncio include le dimensioni sostitutive consigliate. La selezione delle dimensioni sostitutive richiede ai clienti di ridimensionare le relative macchine virtuali.

D: Esiste un delta dei costi per il passaggio a una macchina virtuale non isolata?

R: No

D: Quando vengono ritirate le altre dimensioni isolate?

R: Forniamo promemoria 12 mesi prima della deprecazione ufficiale delle dimensioni isolate. L'annuncio più recente include il ritiro delle funzionalità di isolamento di Standard_G5, Standard_GS5, Standard_E64i_v3 e Standard_E64i_v3.

D: Io sono un cliente di Azure Service Fabric che si basa sui livelli di durabilità Silver o Gold. Quali sono gli effetti di questa modifica?

R: No. Le garanzie fornite dai Livelli di durabilità di Service Fabric continuerà a funzionare anche dopo questa modifica. Se è necessario l'isolamento hardware fisico per altri motivi, potrebbe essere comunque necessario eseguire una delle azioni descritte in precedenza.

D: Quali sono i passaggi fondamentali per il ritiro dell'isolamento di D15_v2 o DS15_v2?

R:

Dati	Azione
15 maggio 20201	Annuncio di ritiro dell'isolamento per D/DS15_v2
sabato 15 maggio 2021	Rimozione della garanzia di isolamento per D/DS15_v2

¹ Il cliente esistente che usa queste dimensioni riceverà un messaggio e-mail di annuncio con istruzioni dettagliate sui passaggi successivi.

D: Quali sono i passaggi fondamentali per il ritiro dell'isolamento di G5, Gs5, E64i_v3 e E64is_v3?

R:

Dati	Azione
15febbraio 20211	Annuncio del ritiro dell'isolamento per G5/GS5/E64i_v3/E64is_v3
28 febbraio 2022	Garanzia dell'isolamento per G5/GS5/E64i_v3/E64is_v3 rimossa

¹ Il cliente esistente che usa queste dimensioni riceverà un messaggio e-mail di annuncio con istruzioni dettagliate sui passaggi successivi.

Passaggi successivi

I clienti possono anche scegliere di suddividere ulteriormente le risorse di tali macchine virtuali con piano Isolato usando il supporto di Azure per le macchine virtuali annidate.

Host dedicati

Oltre agli host isolati descritti nella sezione precedente, Azure offre anche host dedicati. Gli host dedicati in Azure rappresentano un servizio che fornisce server fisici in grado di ospitare una o più macchine virtuali sono dedicati a una singola sottoscrizione di Azure. Gli host dedicati forniscono isolamento hardware a livello di server fisico. Nei tuoi host non verranno posizionate altre VM. Gli host dedicati vengono distribuiti negli stessi data center e condividono la stessa rete e la stessa infrastruttura di archiviazione sottostante di altri host non isolati. Per altre informazioni, vedere la panoramica dettagliata degli host dedicati di Azure.

Isolamento Hyper-V e del sistema operativo radice tra macchine virtuali radice e macchine virtuali guest

La piattaforma di calcolo di Azure si basa sulla virtualizzazione dei computer, ovvero tutto il codice del cliente viene eseguito in una macchina virtuale Hyper-V. In ogni nodo o endpoint di rete di Azure è presente un Hypervisor che viene eseguito direttamente sull'hardware e suddivide il nodo in un numero variabile di macchine virtuali guest.

Ogni nodo ha anche un'apposita VM radice che esegue il sistema operativo host. Una delimitazione critica è l'isolamento della VM radice dalle VM guest e delle VM guest l'una dall'altra, gestita dall'hypervisor e dal sistema operativo radice. L'associazione di hypervisor e sistema operativo radice sfrutta decenni di esperienza di Microsoft nella sicurezza dei sistemi operativi e l'esperienza più recente con Microsoft Hyper-V per offrire l'isolamento avanzato delle macchine virtuali guest.

La piattaforma Azure usa un ambiente virtualizzato. Le istanze utente funzionano come macchine virtuali autonome prive di accesso a un server host fisico.

L'hypervisor di Azure funge da micro-kernel e passa tutte le richieste di accesso all'hardware dalle macchine virtuali guest all'host per elaborarle usando un'interfaccia di memoria condivisa denominata VMBus. Questo impedisce agli utenti di ottenere l'accesso in lettura/scrittura/esecuzione non elaborato al sistema e riduce il rischio di condividere le risorse di sistema.

Algoritmo di posizionamento delle macchine virtuali avanzato e protezione da attacchi side-channel

Gli attacchi tra VM prevedono due passaggi: posizionamento di una VM controllata da un antagonista nello stesso host delle VM bersaglio e quindi violazione del limite di isolamento per sottrarre informazioni sensibili alla vittima oppure comprometterne le prestazioni per guadagno o vandalismo. Microsoft Azure fornisce protezione in entrambi i passaggi usando un algoritmo avanzato di selezione host per le VM e la protezione da tutti gli attacchi side channel noti, incluse le VM "noisy neighbor".

Controller di infrastruttura di Azure

Il controller di infrastruttura di Azure è responsabile dell'allocazione delle risorse dell'infrastruttura nei carichi di lavoro dei tenant e gestisce le comunicazioni unidirezionali dall'host alle macchine virtuali. L'algoritmo di selezione host per le VM del controller di infrastruttura di Azure è estremamente sofisticato e quasi impossibile da prevedere a livello di host fisico.

L'hypervisor di Azure impone la separazione di memoria e processi tra le macchine virtuali e instrada in modo sicuro il traffico di rete ai tenant del sistema operativo guest. Si elimina così la possibilità di un attacco side channel a livello di VM.

In Azure, la macchina virtuale radice è particolare: esegue un sistema operativo con protezione avanzata denominato "sistema operativo radice" che ospita un agente dell'infrastruttura. Gli agenti di Fabric vengono usati a loro volta per gestire gli agenti guest all'interno di sistemi operativi guest nelle macchine virtuali dei clienti. Gestiscono anche i nodi di archiviazione.

L'insieme costituito da hypervisor di Azure, sistema operativo radice/agente dell'infrastruttura e VM del cliente/agenti guest comprende un nodo di calcolo. Gli agenti dell'infrastruttura sono gestiti da un controller di infrastruttura (FC) esterno ai nodi di calcolo e di archiviazione: i cluster di calcolo e di archiviazione vengono gestiti da controller di infrastruttura separati. Se un cliente aggiorna il file di configurazione dell'applicazione mentre questa è in esecuzione, il controller di infrastruttura comunica con l'agente dell'infrastruttura, il quale contatta gli agenti guest che a loro volta segnalano la modifica della configurazione all'applicazione. In caso di errore hardware, il controller di infrastruttura troverà automaticamente hardware disponibile nel quale riavvierà la macchina virtuale.

La comunicazione tra un controller di infrastruttura e un agente è unidirezionale. L'agente implementa un servizio protetto da SSL che risponda solo alle richieste del controller. Non può stabilire connessioni con il controller o altri nodi interni con privilegi. Il controller di infrastruttura considera tutte le risposte come se fossero non attendibili.

L'isolamento si estende dalla VM radice alle VM guest e tra le VM guest. Anche i nodi di calcolo sono isolati dai nodi di archiviazione per aumentare la protezione.

L'hypervisor e il sistema operativo host forniscono filtri dei pacchetti di rete per assicurare che le macchine virtuali non attendibili non possano generare traffico falsificato o ricevere il traffico non indirizzato a loro, indirizzare il traffico a endpoint protetti dell'infrastruttura o inviare/ricevere traffico broadcast inappropriato.

Regole aggiuntive configurate dall'agente controller di infrastruttura per isolare la VM

Per impostazione predefinita, tutto il traffico viene bloccato quando viene creata una macchina virtuale e quindi l'agente controller di infrastruttura configura il filtro dei pacchetti per aggiungere regole ed eccezioni che consentono il traffico autorizzato.

Sono previste due categorie di regole:

• Regole dell'infrastruttura o di configurazione della macchina: per impostazione predefinita, tutta la comunicazione è bloccata. Alcune eccezioni consentono a una macchina virtuale di inviare e ricevere il traffico DHCP e DNS. Le macchine virtuali possono anche inviare il traffico a Internet "pubblico" e ad altre macchine virtuali nella stessa rete virtuale di Azure e nel server di attivazione del sistema operativo. L'elenco di destinazioni in uscita consentite delle macchine virtuali non include subnet di router di Azure, la gestione di Azure e altre proprietà Microsoft.
• File di configurazione dei ruoli: definisce gli elenchi di controllo di accesso (ACL) in ingresso in base al modello di servizio del tenant.

Isolamento VLAN

In ogni cluster sono presenti tre VLAN:

• VLAN principale: crea l'interconnessione tra i nodi non attendibili del cliente
• VLAN del controller di infrastruttura: contiene controller di infrastruttura attendibili e sistemi di supporto
• VLAN dei dispositivi: contiene dispositivi di rete attendibili e altri dispositivi dell'infrastruttura

La comunicazione è consentita dalla VLAN del controller di infrastruttura alla VLAN principale, ma non dalla VLAN principale alla VLAN del controller di infrastruttura. La comunicazione è anche bloccata dalla VLAN principale alla VLAN dei dispositivi. Questo assicura che anche se un nodo che esegue il codice del cliente è compromesso, non potrà attaccare nodi sulla VLAN dei dispositivi o sulla VLAN del controller di infrastruttura.

Isolamento dell'archiviazione

Isolamento logico tra calcolo e archiviazione

Nell'ambito della sua progettazione fondamentale, Microsoft Azure separa il calcolo basato sulle VM dall'archiviazione. Questa separazione consente la scalabilità indipendente di calcolo e archiviazione, semplificando l'uso di multi-tenancy e isolamento.

Il servizio Archiviazione di Azure viene quindi eseguito in hardware separato senza alcuna connettività di rete ai servizi di calcolo di Azure, ad eccezione di quella logica. Questo significa che quando viene creato un disco virtuale, lo spazio sul disco non viene allocato per l'intera capacità. Viene invece creata una tabella che associa gli indirizzi nel disco virtuale ad aree del disco fisico. Questa tabella è inizialmente vuota. La prima volta che un cliente scrive dati nel disco virtuale, viene allocato spazio sul disco fisico e il relativo puntatore viene inserito nella tabella.

Isolamento tramite il controllo di accesso per l'archiviazione

Il controllo di accesso nell'archiviazione di Azure dispone di un modello semplice di controllo degli accessi. Ogni sottoscrizione di Azure può creare uno o più account di archiviazione. Ogni account di archiviazione ha un'unica chiave privata usata per controllare l'accesso a tutti i dati presenti nell'account di archiviazione.

L'accesso ai dati dell'archiviazione di Azure, incluse le tabelle, può essere controllato in un token SAS (firma di accesso condiviso) che concede l'accesso con ambito. La firma di accesso condiviso viene creata tramite un modello di query (URL) firmato con la chiave dell'account di archiviazione. L'URL firmato può essere assegnato, ovvero delegato, a un altro processo che può quindi compilare i dettagli della query ed effettuare la richiesta del servizio di archiviazione. Una firma di accesso condiviso consente di concedere l'accesso con scadenza ai client senza rivelare la chiave privata dell'account di archiviazione.

La firma di accesso condiviso consente di concedere a un client autorizzazioni limitate per oggetti nell'account di archiviazione per un periodo di tempo specificato e con un set di autorizzazioni. È possibile concedere queste autorizzazioni limitate senza dover condividere le chiavi di accesso all'account.

Isolamento dell'archiviazione a livello IP

È possibile stabilire firewall e definire un intervallo di indirizzi IP per i client attendibili. Con un intervallo di indirizzi IP, solo i client con indirizzo IP compreso nell'intervallo definito possono connettersi ad Archiviazione di Azure.

I dati di archiviazione IP possono essere protetti da utenti non autorizzati tramite un meccanismo di rete usato per allocare un tunnel di traffico dedicato per l'archiviazione IP.

Crittografia

Azure offre i tipi di crittografia seguenti per proteggere i dati:

• Crittografia in transito
• Crittografia di dati inattivi

Crittografia in transito

La crittografia in transito è un meccanismo di protezione dei dati durante la trasmissione tra le reti. Con Archiviazione di Azure è possibile proteggere i dati con:

• Crittografia a livello di trasporto, ad esempio HTTPS quando si trasferiscono dati all'interno o all'esterno dell'archiviazione di Azure.
• Crittografia di rete, ad esempio la crittografia SMB 3.0 per le condivisioni file di Azure.
• Crittografia lato client, per crittografare i dati prima che siano trasferiti nella risorsa di archiviazione e decrittografarli dopo il trasferimento dalla risorsa di archiviazione.

Crittografia di dati inattivi

Per molte organizzazioni, la crittografia dei dati inattivi è un passaggio obbligatorio per assicurare la privacy dei dati, la conformità e la sovranità dei dati. Esistono tre funzionalità di Azure che consentono di crittografare dati inattivi:

• Crittografia del servizio di archiviazione consente di richiedere che il servizio di archiviazione crittografi automaticamente i dati durante la scrittura nell'archiviazione di Azure.
• Crittografia lato client offre anche la funzionalità di crittografia dei dati inattivi.
• Crittografia dischi di Azure per macchine virtuali Linux e Crittografia dischi di Azure per macchine virtuali Windows.

Per altre informazioni, vedere Panoramica delle opzioni di crittografia del disco gestito.

Crittografia dischi di Azure

Crittografia dischi di Azure per macchine virtuali Linux e Crittografia dischi di Azure per macchine virtuali Windows permettono di soddisfare i requisiti di conformità e sicurezza dell'organizzazione crittografando i dischi delle macchine virtuali (inclusi i dischi dati e di avvio) con chiavi e criteri controllati in Azure Key Vault.

La soluzione Crittografia dischi per Windows è basata su Crittografia unità BitLocker di Microsoft e la soluzione Linux è basata su dm-crypt.

La soluzione supporta gli scenari seguenti per le macchine virtuali IaaS, se abilitati in Microsoft Azure:

• Integrazione dell'insieme di credenziali delle chiavi di Azure.
• Macchine virtuali di livello Standard: serie A, D, DS, G, GS e così via per VM IaaS
• Abilitazione della crittografia nelle macchine virtuali IaaS Windows e Linux
• Disabilitazione della crittografia nel sistema operativo e nelle unità dati per le VM IaaS Windows
• Disabilitazione della crittografia nelle unità dati per le macchine virtuali IaaS Linux
• Abilitazione della crittografia in macchine virtuali IaaS in esecuzione nel sistema operativo client Windows
• Abilitazione della crittografia su volumi con percorsi di montaggio
• Abilitazione della crittografia nelle macchine virtuali Linux configurate con striping del disco (RAID) tramite mdadm
• Abilitazione della crittografia nelle macchine virtuali Linux usando LVM (Logical Volume Manager) per i dischi di dati
• Abilitazione della crittografia nelle macchine virtuali Windows configurate usando spazi di archiviazione
• Sono supportate tutte le aree geografiche pubbliche di Azure

La soluzione non supporta gli scenari, le funzionalità e la tecnologia seguenti in questa versione:

• VM IaaS del piano Basic
• Disabilitazione della crittografia in un'unità del sistema operativo per le VM IaaS Linux
• Macchine virtuali IaaS create usando il metodo di creazione classico per le macchine virtuali
• Integrazione con il servizio di gestione delle chiavi locale.
• File di Azure (file system condiviso), file system di rete (NFS, Network File System), volumi dinamici e macchine virtuali Windows configurate con sistemi RAID basati su software

Isolamento del database SQL

Il database SQL è un servizio di database relazionale sul cloud Microsoft basato sul motore Microsoft SQL Server, leader di mercato, e in grado di gestire carichi di lavoro di importanza strategica. Il database SQL di Azure offre isolamento prevedibile dei dati a livello di account, in base all'area geografica e alla rete, con esigenze di amministrazione quasi nulle.

Modello di applicazione di database SQL

Il database Microsoft SQL è un servizio di database relazionale basato su cloud basato sulle tecnologie SQL Server. Fornisce un servizio di database a disponibilità elevata, scalabile e multi-tenant ospitato da Microsoft nel cloud.

Dal punto di vista dell'applicazione, il database SQL fornisce la gerarchia seguente. Ogni livello ha una relazione di contenimento uno-a-molti per questi livelli.

Account e sottoscrizione sono concetti della piattaforma Microsoft Azure per associare fatturazione e gestione.

I server e i database SQL logici sono concetti specifici del database SQL gestiti usando il database SQL, forniti dalle interfacce OData e TSQL o tramite il portale di Azure.

I server nel database SQL non sono istanze di macchine virtuali o fisiche, ma raccolte di database, con criteri di sicurezza e gestione condivisi, archiviate nel cosiddetto database "master logico".

I database master logici includono:

• Account di accesso SQL usati per connettersi al server
• Regole del firewall

Le informazioni sulla fatturazione e l'utilizzo per i database dello stesso server non si trovano necessariamente nella stessa istanza fisica del cluster, mentre le applicazioni devono fornire il nome del database di destinazione durante la connessione.

Dal punto di vista del cliente, un server viene creato in un'area geografica, mentre la creazione effettiva del server viene eseguita in uno dei cluster disponibili nell'area.

Isolamento tramite la topologia della rete

Quando viene creato un server e il relativo nome DNS viene registrato, questo nome punta all'indirizzo denominato "VIP del gateway" nel data center specifico in cui si trova il server.

Dietro l'indirizzo VIP (indirizzo IP virtuale) è presente una raccolta di servizi di gateway senza stato. In generale, i gateway vengono coinvolti quando è necessario coordinare più origini dati, ovvero database master, database utente e così via. I servizi gateway implementano gli elementi seguenti:

• Inoltro dei dati tramite connessione TDS. Comprende l'identificazione del database utente nel cluster back-end, l'implementazione della sequenza di accesso e quindi l'inoltro dei pacchetti TDS al back-end e viceversa.
• Gestione di database. Comprende l'implementazione di una raccolta di flussi di lavoro per eseguire operazioni di database CREATE/ALTER/DROP. Le operazioni di database possono essere richiamate analizzando pacchetti TDS o API OData esplicite.
• Operazioni CREATE/ALTER/DROP per account di accesso/utenti
• Operazioni di gestione server tramite API OData

Il livello dietro il gateway è denominato "back-end". Qui vengono archiviati tutti i dati in una modalità a disponibilità elevata. Ogni dato appartiene a una partizione o unità di failover, ognuna con almeno tre repliche. Le repliche vengono archiviate e replicate dal motore di SQL Server e gestite da un sistema di failover, noto anche come "infrastruttura".

In genere, il sistema back-end non comunica in uscita con altri sistemi come misura di sicurezza. Questo tipo di comunicazione è riservata ai sistemi nel livello front-end (gateway). Le macchine di livello gateway hanno privilegi limitati per le macchine back-end per ridurre al minimo la superficie di attacco come meccanismo di difesa avanzata.

Isolamento in base all'accesso e alla funzione della macchina

Il database SQL è composto da servizi in esecuzione in funzioni della macchina diverse. Il database SQL è suddiviso in ambienti di database cloud "back-end" e "front-end" (gateway/gestione), con il principio generale del traffico diretto solo al back-end e non all'esterno. L'ambiente front-end può comunicare con l'esterno di altri servizi e, in generale, dispone solo di autorizzazioni limitate nel back-end (sufficienti per chiamare i punti di ingresso da richiamare).

Isolamento della rete

La distribuzione di Azure offre più livelli di isolamento della rete. Il diagramma seguente mostra i vari livelli di isolamento della rete che Azure offre ai clienti. Questi livelli sono costituiti sia da funzionalità native della piattaforma Azure, sia da funzionalità definite dal cliente. Per il traffico in ingresso da Internet, Azure DDoS fornisce l'isolamento da attacchi su larga scala contro Azure. Il livello di isolamento successivo è costituito da indirizzi IP pubblici (endpoint) definiti dall'utente, usati per determinare il traffico che può passare alla rete virtuale attraverso il servizio cloud. L'isolamento nativo della rete virtuale di Azure assicura l'isolamento completo da tutte le altre reti e il flusso di traffico solo tramite percorsi e metodi configurati dall'utente. Questi percorsi e metodi costituiscono il livello successivo, in cui è possibile usare NSG, UDR e appliance virtuali di rete per creare limiti di isolamento e proteggere le distribuzioni delle applicazioni nella rete protetta.

Isolamento del traffico: Una rete virtuale è il limite di isolamento del traffico sulla piattaforma di Azure. Le macchine virtuali (VM) in una rete virtuale non possono comunicare direttamente con le VM in una rete virtuale diversa, anche se entrambe le reti virtuali vengono create dallo stesso cliente. L'isolamento è una proprietà essenziale che assicura che le macchine virtuali e le comunicazioni dei clienti rimangano private entro una rete virtuale.

La subnet offre un livello aggiuntivo di isolamento nella rete virtuale in base all'intervallo di indirizzi IP. È possibile suddividere la rete virtuale in più subnet per una maggiore organizzazione e sicurezza. Le VM e le istanze del ruolo PaaS distribuite nelle subnet (nella stessa o in diverse) in una rete virtuale possono comunicare tra loro senza nessuna configurazione aggiuntiva. È anche possibile configurare un gruppo di sicurezza di rete (NSG) per consentire o negare il traffico di rete verso un'istanza di macchina virtuale in base alle regole configurate nell'elenco di controllo di accesso (ACL) del gruppo di sicurezza di rete. I gruppi di sicurezza di rete possono essere associati a subnet o singole istanze di macchine virtuali in una subnet. Quando un gruppo di sicurezza di rete viene associato a una subnet, le regole ACL si applicano a tutte le istanze di macchine virtuali nella subnet.

Passaggi successivi

• Informazioni su Opzioni di isolamento della rete per le macchine nelle reti virtuali di Microsoft Azure. Comprendono il tipico scenario front-end e back-end in cui le macchine di una particolare rete back-end o subnet possono consentire solo ad alcuni client o altri computer di connettersi a un endpoint specifico in base a un elenco di indirizzi IP consentiti.

• Informazioni sull'isolamento delle macchine virtuali in Azure. Calcolo di Azure offre dimensioni di macchine virtuali isolate per uno specifico tipo di hardware e dedicate a un singolo cliente.