Isolamento nel cloud pubblico di Azure

Azure consente di eseguire applicazioni e macchine virtuali (VM) nell'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 descrive in che modo Azure fornisce l'isolamento per utenti malintenzionati e non dannosi e funge da guida per progettare soluzioni cloud offrendo diverse opzioni di isolamento agli 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 di gestione delle identità fornita da Microsoft Azure, un tenant è semplicemente un'istanza dedicata dell'ID Microsoft Entra che l'organizzazione riceve e possiede quando si iscrive a un servizio cloud Microsoft.

Ogni directory di Microsoft Entra è distinta e separata da altre directory di Microsoft Entra. Proprio come un edificio aziendale è un asset sicuro specifico solo per l'organizzazione, una directory di Microsoft Entra è stata progettata anche per essere un asset sicuro per l'uso solo da parte dell'organizzazione. L'architettura di Microsoft Entra isola i dati dei clienti e le informazioni sull'identità dal co-mingling. Ciò significa che gli utenti e gli amministratori di una directory di Microsoft Entra non possono accedere accidentalmente o dannosamente ai dati in un'altra directory.

Tenancy di Azure

Il tenancy di Azure (sottoscrizione di Azure) si riferisce 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 l'ID Microsoft Entra e il controllo degli accessi in base al ruolo di Azure offerto da esso. 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 è isolato logicamente usando i limiti di sicurezza in modo che nessun cliente possa accedere o compromettere i co-tenant, in modo dannoso o accidentale. Microsoft Entra ID viene eseguito su server "bare metal" isolati in un segmento di rete separato, in cui il filtro dei pacchetti a livello di host e Windows Firewall blocca le connessioni e il 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 discreti e non esiste alcuna relazione tra questi contenitori.

• 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 e 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. Microsoft Entra Privileged Identity Management (PIM) introduce il concetto di amministratore idoneo. Gli amministratori idonei devono essere utenti che necessitano di accesso con privilegi ora e poi, 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.

L'ID Microsoft Entra ospita ogni tenant nel proprio contenitore protetto, con criteri e autorizzazioni per e all'interno del contenitore di proprietà e gestito esclusivamente dal tenant.

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 esiste alcuna relazione tra i contenitori diversi da quello definito dal servizio directory, che a sua volta viene determinato dall'amministratore del 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 ha accesso completo a tutte le risorse, compreso il diritto di delegare l'accesso ad altri utenti.

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

• 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 loro l'accesso all'Rete virtuale di Azure o alla subnet a cui si connette la macchina virtuale.

I ruoli predefiniti di Azure elencano 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 ospitati. 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 identità come servizio tramite la federazione usando Active Directory Federation Services, la sincronizzazione e la replica con directory locali.

• L'autenticazione a più fattori Microsoft Entra richiede agli utenti di verificare gli accessi usando un'app per dispositivi mobili, una telefonata o un SMS. Può essere usato con Microsoft Entra ID per proteggere le risorse locali con il server Multi-Factor Authentication e anche con applicazioni e directory personalizzate tramite 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.

• Azure Active Directory B2C offre un servizio di gestione delle identità globale a disponibilità elevata per le applicazioni rivolte agli utenti, con scalabilità fino 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 dei 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 hanno accesso predefinito ai dati nel cloud. L'accesso viene loro concesso sotto supervisione e solo quando necessario. L'accesso viene controllato e registrato con attenzione e revocato quando non è più necessario.
• Microsoft può ricorrere ad altre società per la fornitura di servizi limitati per suo conto. I subappaltatori possono accedere ai dati dei clienti solo per fornire i servizi per i quali sono stati assunti e non possono usarli per altri scopi. Inoltre, sono vincolati contrattualmente a mantenere la riservatezza delle informazioni dei nostri 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 un'unità disco usata per l'archiviazione subisce un errore hardware, viene cancellata o distrutta in modo sicuro prima che Microsoft lo restituisca al produttore per la sostituzione o il ripristino. I dati nell'unità vengono sovrascritti per garantire che i dati 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 delle macchine virtuali con piano Isolato 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 viene ritirata o è disponibile una nuova generazione hardware.

Le dimensioni delle macchine virtuali isolate sono più adatte per i 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 una dimensione isolata garantisce che la macchina virtuale sia l'unica in esecuzione in tale istanza del server specifica.

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 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_M128ms

Nota

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 invia promemoria per 12 mesi prima della data ufficiale di deprecazione delle dimensioni e fornisce un'offerta isolata aggiornata per la tua considerazione. Le dimensioni seguenti hanno annunciato il ritiro.

Dimensione	Data ritiro 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: Le dimensioni verranno ritirati o solo la funzionalità di "isolamento"?

R: Qualsiasi dimensione pubblicata come isolata ma senza "i" nel nome, la funzionalità di isolamento delle dimensioni della macchina virtuale viene 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, in cui solo l'isolamento è deprecato 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 di sostituzione consigliate. La selezione delle dimensioni di sostituzione richiede ai clienti di ridimensionare le macchine virtuali.

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

R: No

D: Quando vengono ritirati 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. Questa modifica influisce sull'utente corrente?

R: No. Le garanzie fornite dai livelli di durabilità di Service Fabric continueranno 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 le attività cardine per D15_v2 o DS15_v2 ritiro dell'isolamento?

R:

Date	Azione
15 maggio 20201	Annuncio di ritiro dell'isolamento D/DS15_v2
sabato 15 maggio 2021	Rimozione dell'isolamento D/DS15_v2

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

D: Quali sono le attività cardine per G5, Gs5, E64i_v3 e E64is_v3 ritiro dell'isolamento?

R:

Date	Azione
15 febbraio 20211	Annuncio di ritiro dell'isolamento G5/GS5/E64i_v3/E64is_v3
28 febbraio 2022	L'isolamento G5/GS5/E64i_v3/E64is_v3 rimosso

¹ Il cliente esistente che usa queste dimensioni riceverà un messaggio di posta elettronica 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 sono un servizio che fornisce server fisici che possono ospitare una o più macchine virtuali e che sono dedicati a una singola sottoscrizione di Azure. Gli host dedicati forniscono l'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 VM radice e VM 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 di Azure (o endpoint di rete) è presente un hypervisor che viene eseguito direttamente sull'hardware e divide un nodo in un numero variabile di Macchine virtuali guest (VM).

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 che non hanno accesso a un server host fisico.

L'hypervisor di Azure agisce come un micro kernel e passa tutte le richieste di accesso hardware dalle macchine virtuali guest all'host per l'elaborazione usando un'interfaccia di memoria condivisa denominata bus di macchina virtuale. 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 avanzato di selezione host per le VM 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 FA vengono usati a loro volta per gestire gli agenti guest (GA) all'interno dei 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 di configurazione macchina virtuale o di infrastruttura: per impostazione predefinita, vengono bloccate tutte le comunicazioni. 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 delle macchine virtuali delle destinazioni in uscita consentite non include subnet del router di Azure, 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. Ciò significa che quando viene creato un disco virtuale, lo spazio su 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 i dati sul disco virtuale, lo spazio sul disco fisico viene allocato e un puntatore alla tabella.

Isolamento tramite il controllo di accesso per l'archiviazione

Il controllo di accesso in Archiviazione di Azure ha un modello semplice. Ogni sottoscrizione di Azure può creare uno o più account di archiviazione. Ogni account di archiviazione ha una singola chiave privata usata per controllare l'accesso a tutti i dati in tale account di archiviazione.

L'accesso ai dati di Archiviazione di Azure, incluse le tabelle, può essere controllato in un token di 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 dedicato o dedicato del traffico all'archiviazione IP.

Crittografia

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

• Crittografia dei dati 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 di 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 vengano trasferiti nell'archiviazione e decrittografare i dati 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. Sono disponibili tre funzionalità di Azure che forniscono la crittografia dei dati "inattivi":

• Crittografia del servizio di archiviazione consente di richiedere che il servizio di archiviazione crittografi automaticamente i dati durante la scrittura in Archiviazione di Azure.
• Client-side Encryption offre anche la funzionalità di crittografia dei dati inattivi.
• Crittografia dischi di Azure per macchine virtuali Linux e Crittografia dischi di Azure per le macchine virtuali Windows.

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

Azure Disk Encryption

Crittografia dischi di Azure per macchine virtuali Linux e Crittografia dischi di Azure per le macchine virtuali Windows consente di soddisfare i requisiti di sicurezza e conformità dell'organizzazione crittografando i dischi delle macchine virtuali (inclusi i dischi di avvio e dati) con chiavi e criteri che si controllano 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 nella 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 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 database SQL

Microsoft database SQL è un servizio di database relazionale basato sul cloud basato sulle tecnologie DI 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, database SQL fornisce la gerarchia seguente: ogni livello ha un contenimento uno-a-molti dei livelli sottostanti.

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

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

I server in database SQL non sono istanze fisiche o vm, ma sono raccolte di database, condivisione di criteri di gestione e sicurezza, archiviati nel cosiddetto database "master logico".

I database master logici includono:

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

Non è garantito che le informazioni relative alla fatturazione e all'utilizzo per i database dello stesso server si trovano nella stessa istanza fisica del cluster. Al contrario, 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 con interfaccia grafica mentre la creazione effettiva del server avviene in uno dei cluster nell'area.

Isolamento tramite la topologia della rete

Quando viene creato un server e il relativo nome DNS viene registrato, il nome DNS punta all'indirizzo "VIP gateway" nel data center specifico in cui è stato inserito 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 il coordinamento tra più origini dati (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 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 del server tramite l'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 ad altri sistemi come precauzione 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

database SQL è costituito da servizi in esecuzione in diverse funzioni del computer. database SQL è suddiviso in ambienti di database cloud "back-end" e "front-end" (gateway/gestione), con il principio generale del traffico che passa 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 (sufficiente per chiamare i punti di ingresso necessari per 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 nella piattaforma 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 di isolamento aggiuntivo nella rete virtuale in base a un 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 sulle opzioni di isolamento della rete per i computer in Windows Azure Rete virtuale s. Ciò include lo scenario front-end e back-end classico in cui i computer in una determinata rete back-end o sottorete possono consentire solo a determinati client o altri computer di connettersi a un determinato endpoint in base a un elenco di indirizzi IP consentiti.

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