Sicurezza di Azure per app native del cloud
Suggerimento
Questo contenuto è un estratto dell'eBook, Progettazione di applicazioni .NET native del cloud per Azure, disponibile in .NET Docs o come PDF scaricabile gratuitamente che può essere letto offline.
Le applicazioni native del cloud possono essere sia più semplici che più difficili da proteggere rispetto alle applicazioni tradizionali. Il lato negativo è che è necessario proteggere applicazioni più piccole e dedicare più energia per creare l'infrastruttura di sicurezza. La natura eterogenea dei linguaggi di programmazione e degli stili nella maggior parte delle distribuzioni di servizi significa anche prestare maggiore attenzione ai bollettini sulla sicurezza di molti provider diversi.
Il lato positivo è che i servizi più piccoli, ognuno con il proprio archivio dati, limitano l'ambito di un attacco. Se un utente malintenzionato compromette un sistema, è probabilmente più difficile per l'utente malintenzionato fare il salto a un altro sistema rispetto a quello in un'applicazione monolitica. I limiti dei processi sono limiti forti. Inoltre, se un backup del database viene esposto, il danno è più limitato, in quanto tale database contiene solo un subset di dati e probabilmente non contiene dati personali.
Modellazione delle minacce
Indipendentemente dal fatto che i vantaggi superino gli svantaggi delle applicazioni native del cloud, è necessario seguire la stessa mentalità olistica per la sicurezza. La sicurezza e il pensiero sicuro devono far parte di ogni fase dello sviluppo e delle operazioni. Quando si pianifica un'applicazione, è possibile porre domande come:
- Quale sarebbe l'impatto di questi dati persi?
- In che modo è possibile limitare i danni derivanti dall'inserimento di dati errati in questo servizio?
- Chi deve avere accesso a questi dati?
- Esistono criteri di controllo per il processo di sviluppo e rilascio?
Tutte queste domande fanno parte di un processo denominato modellazione delle minacce. Questo processo tenta di rispondere alle domande su quali sono le minacce per il sistema, qual è la probabilità della presenza di tali minacce e quali sono i potenziali danni derivanti.
Dopo aver stabilito l'elenco delle minacce, è necessario decidere se vale la pena attenuarle. A volte la pianificazione relativa a una minaccia è talmente improbabile e costosa che non vale la pena spendere energia su di essa. Ad esempio, un soggetto a livello di stato potrebbe inserire modifiche nella progettazione di un processo usato da milioni di dispositivi. Invece di eseguire un determinato frammento di codice nell’anello 3, il codice viene eseguito nell'anello 0. Questo processo consente un exploit che può ignorare l'hypervisor ed eseguire il codice di attacco sulle macchine bare metal, consentendo attacchi a tutte le macchine virtuali in esecuzione su tale hardware.
I processori modificati sono difficili da rilevare senza un microscopio e una conoscenza avanzata della progettazione su silicio del processore. Questo scenario è improbabile e dispendioso da attenuare, quindi probabilmente nessuna modellazione delle minacce consiglierebbe di creare protezione dagli exploit per tale soluzione.
Pe minacce più probabili, ad esempio controlli di accesso interrotti che consentono Id un incremento degli attacchi (sostituendo Id=2 con Id=3 nell'URL) o SQL injection, è più interessante creare protezioni. Le mitigazioni per queste minacce sono abbastanza ragionevoli da costruire ed evitano problemi di sicurezza imbarazzanti che macchierebbero la reputazione dell'azienda.
Principio del privilegio minimo
Una delle idee fondanti della sicurezza informatica è il principio dei privilegi minimi (POLP). È in realtà un'idea fondamentale nella maggior parte delle forme di sicurezza, sia digitali che fisiche. In breve, il principio è che qualsiasi utente o processo deve avere il minor numero di diritti possibile per eseguire l'attività.
Pensa, ad esempio, ai cassieri di una banca: l'accesso alla cassaforte è un'attività non comune. Quindi, il cassiere medio non può aprire la cassaforte. Per ottenere l'accesso, è necessario inoltrare la richiesta tramite un responsabile bancario, che esegue controlli di sicurezza aggiuntivi.
In un sistema informatico, un esempio fantastico è il diritto di un utente a connettersi a un database. In molti casi, è presente un singolo account utente usato per compilare la struttura del database ed eseguire l'applicazione. Ad eccezione dei casi estremi, l'account che esegue l'applicazione non richiede la possibilità di aggiornare le informazioni dello schema. Dovrebbero essere presenti diversi account che forniscono diversi livelli di privilegio. L'applicazione deve usare solo il livello di autorizzazione che concede l'accesso in lettura e scrittura ai dati nelle tabelle. Questo tipo di protezione eliminerebbe gli attacchi che mirerebbero a eliminare le tabelle di database o a introdurre trigger dannosi.
Quasi ogni parte della creazione di un'applicazione nativa del cloud può trarre vantaggio dal ricordare il principio dei privilegi minimi. È possibile trovarlo in fase di configurazione di firewall, gruppi di sicurezza di rete, ruoli e ambiti nel controllo degli accessi in base al ruolo.
Test di penetrazione
Man mano che le applicazioni diventano più complesse, il numero di vettori di attacco aumenta a una velocità allarmante. La modellazione delle minacce è difettosa perché tende a essere eseguita dagli stessi utenti che creano il sistema. Allo stesso modo in cui molti sviluppatori hanno problemi a immaginare le interazioni utente e quindi creare interfacce utente inutilizzabili, la maggior parte degli sviluppatori ha difficoltà a vedere ogni vettore di attacco. È anche possibile che gli sviluppatori che creano il sistema non siano ben esperti nelle metodologie di attacco e quindi si lascino sfuggire elementi cruciali.
Il test di penetrazione o "pen testing" comporta l'inserimento di soggetti esterni che tentano di attaccare il sistema. Questi utenti malintenzionati possono essere una società di consulenza esterna o altri sviluppatori con una buona conoscenza della sicurezza di un'altra parte dell'azienda. A essi viene data carta bianca per tentare di sovvertire il sistema. Spesso, troveranno ampi problemi di sicurezza a cui devono essere applicate patch. A volte il vettore di attacco sarà totalmente imprevisto, ad esempio se sfrutta un attacco di phishing contro il CEO.
Azure stesso è costantemente sotto attacco da parte di un team di hacker all'interno di Microsoft. Nel corso degli anni, il team è stato il primo a trovare decine di vettori di attacco potenzialmente irreversibili e li ha chiusi prima che possano essere stati sfruttati esternamente. Più il bersaglio è allettante, più è probabile che i soggetti esterni tenteranno di sfruttarlo, e nel mondo ci sono alcuni obiettivi più allettanti di Azure.
Monitoraggio
Se un utente malintenzionato tenta di penetrare un'applicazione, dovrebbe essere presente un avviso. Spesso, gli attacchi possono essere individuati esaminando i log dai servizi. Gli attacchi lasciano segni rivelatori che possono essere individuati prima che l’attacco vada a buon fine. Ad esempio, un utente malintenzionato che tenta di indovinare una password effettuerà molte richieste a un sistema di accesso. Il monitoraggio intorno al sistema di accesso può rilevare modelli strani non allineati con il modello di accesso tipico. Questo monitoraggio può essere trasformato in un avviso che può, a sua volta, avvisare un addetto alle operazioni, che potrà attivare una serie di contromisure. Un sistema di monitoraggio altamente maturo potrebbe anche intervenire proattivamente in base a queste deviazioni, aggiungendo regole per bloccare le richieste o limitare le risposte.
Protezione della compilazione
Un luogo in cui la sicurezza è spesso trascurata è intorno al processo di compilazione. Non devono essere protetti solo i controlli di sicurezza dell'esecuzione della compilazione, come l'analisi di codice non sicuro o credenziali archiviate, ma anche la compilazione stessa. Se il server di compilazione è compromesso, fornisce un vettore fantastico per introdurre codice arbitrario nel prodotto.
Supponiamo che un utente malintenzionato stia cercando di rubare le password delle persone che accedono a un'applicazione Web. L’utente potrebbe introdurre un passaggio di compilazione che modifica il codice estratto per eseguire il mirroring di qualsiasi richiesta di accesso a un altro server. La volta successiva che il codice passa attraverso la compilazione, viene aggiornato automaticamente. L'analisi delle vulnerabilità del codice sorgente non rileva questa vulnerabilità durante l'esecuzione prima della compilazione. Allo stesso modo, nessuno la intercetta in una revisione del codice perché i passaggi di compilazione si trovano nel server di compilazione. Il codice sfruttato passerà all'ambiente di produzione in cui può raccogliere le password. Probabilmente non esiste alcun log di controllo delle modifiche del processo di compilazione, o almeno nessuno monitora il controllo.
Questo scenario è un esempio perfetto di una destinazione apparentemente a basso valore che può essere usata per irrompere nel sistema. Una volta che un utente malintenzionato viola il perimetro del sistema, può iniziare a lavorare per trovare modi per elevare le autorizzazioni al punto da poter causare danni reali ovunque preferisca.
Compilazione di codice sicuro
.NET Framework è già un framework abbastanza sicuro. Evita alcune delle insidie del codice non gestito, ad esempio l'interruzione delle estremità delle matrici. Il lavoro viene svolto attivamente per correggere i problemi di sicurezza man mano che vengono individuati. Esiste anche un programma di ricompense sui bug che paga i ricercatori per trovare problemi nel framework e segnalarli invece di sfruttarli.
Esistono molti modi per rendere più sicuro il codice .NET. Le linee guida seguenti, ad esempio l’articolo Linee guida per la generazione di codice sicuro per .NET, sono un passaggio ragionevole da eseguire per assicurarsi che il codice sia protetto sin dall’inizio. La top 10 di OWASP è un'altra guida preziosa per la creazione di codice sicuro.
Il processo di compilazione è un buon luogo in cui usare gli strumenti di analisi per rilevare i problemi nel codice sorgente prima di produrlo. La maggior parte dei progetti ha dipendenze da altri pacchetti. Uno strumento in grado di analizzare i pacchetti obsoleti intercetta problemi in una compilazione notturna. Anche quando si creano immagini Docker, è utile verificare e assicurarsi che l'immagine di base non abbia vulnerabilità note. Un'altra cosa da controllare è che nessuno abbia accidentalmente archiviato le credenziali.
Sicurezza incorporata
Azure è progettato per bilanciare l'usabilità e la sicurezza per la maggior parte degli utenti. Diversi utenti avranno requisiti di sicurezza diversi, quindi devono ottimizzare il loro approccio alla sicurezza cloud. Microsoft pubblica una grande quantità di informazioni sulla sicurezza nel Centro protezione. Questa risorsa deve essere la prima tappa per i professionisti interessati a comprendere il funzionamento delle tecnologie di mitigazione degli attacchi predefinite.
All'interno del portale di Azure, Azure Advisor è un sistema che analizza costantemente l’ambiente e fornisce elementi consigliati. Alcune di questi elementi consigliati sono progettati per far risparmiare denaro agli utenti, ma altri sono progettati per identificare configurazioni potenzialmente non sicure, ad esempio quella di avere un contenitore di archiviazione aperto al mondo e non protetto da una rete virtuale.
Infrastruttura di rete di Azure
In un ambiente di distribuzione locale, una grande quantità di energia è dedicata alla configurazione della rete. La configurazione di router, commutatori e simili è un lavoro complesso. Le reti consentono a determinate risorse di comunicare con altre risorse e impedire l'accesso in alcuni casi. Una regola di rete frequente consiste nel limitare l'accesso all'ambiente di produzione dall'ambiente di sviluppo in caso di esecuzione di una parte di codice semi-sviluppata ed elimina una swath di dati.
Per impostazione predefinita, la maggior parte delle risorse di Azure PaaS ha solo la configurazione di rete più semplice e permissiva. Ad esempio, chiunque su Internet può accedere a un servizio app. Le nuove istanze di SQL Server sono in genere limitate, in modo che le parti esterne non possano accedervi, ma gli intervalli di indirizzi IP usati da Azure stesso sono consentiti. Pertanto, mentre SQL Server è protetto da minacce esterne, un utente malintenzionato deve configurare solo una testa di ponte di Azure da cui può avviare attacchi contro tutte le istanze di SQL in Azure.
Fortunatamente, la maggior parte delle risorse di Azure può essere inserita in una rete virtuale di Azure che consente un controllo di accesso con granularità fine. Analogamente al modo in cui le reti locali stabiliscono reti private protette dal mondo più ampio, le reti virtuali sono isole di indirizzi IP privati che si trovano all'interno della rete di Azure.
Figura 9-1. Rete virtuale in Azure.
Allo stesso modo in cui le reti locali hanno un firewall che regola l'accesso alla rete, è possibile stabilire un firewall simile al limite della rete virtuale. Per impostazione predefinita, tutte le risorse in una rete virtuale possono comunque comunicare con Internet. Si tratta solo di connessioni in ingresso che richiedono una qualche forma di eccezione esplicita del firewall.
Con la rete stabilita, le risorse interne come gli account di archiviazione possono essere configurate per consentire l'accesso solo da parte delle risorse presenti anche nella rete virtuale. Questo firewall offre un livello di sicurezza aggiuntivo: in caso di perdita delle chiavi per l'account di archiviazione, gli utenti malintenzionati non sarebbero in grado di connettersi a esso per sfruttare le chiavi perse. Questo scenario è un altro esempio di principio dei privilegi minimi.
I nodi in un cluster Azure Kubernetes possono partecipare a una rete virtuale esattamente come altre risorse più native di Azure. Questa funzionalità è denominata Azure Container Networking Interface. In effetti, alloca una subnet all'interno della rete virtuale in cui vengono allocate le macchine virtuali e le immagini del contenitore.
Continuando il percorso per illustrare il principio dei privilegi minimi, non tutte le risorse all'interno di una rete virtuale devono comunicare con ogni altra risorsa. Ad esempio, in un'applicazione che fornisce un'API Web su un account di archiviazione e un database SQL, è improbabile che il database e l'account di archiviazione debbano comunicare tra loro. Qualsiasi condivisione di dati tra di essi passa attraverso l'applicazione Web. Pertanto, un gruppo di sicurezza di rete (NSG) potrebbe essere usato per negare il traffico tra i due servizi.
Un criterio di negazione della comunicazione tra le risorse può essere fastidioso da implementare, soprattutto in caso di precedenti di uso di Azure senza restrizioni al traffico. In altri cloud, il concetto di gruppi di sicurezza di rete è molto più diffuso. Ad esempio, il criterio predefinito in AWS è che le risorse non possono comunicare tra loro fino a quando non sono abilitate dalle regole in un gruppo di sicurezza di rete. Anche se più lento a sviluppare ciò, un ambiente più restrittivo offre un'impostazione predefinita più sicura. L'uso di procedure DevOps appropriate, in particolare l'uso di Azure Resource Manager o Terraform per gestire le autorizzazioni, può semplificare il controllo delle regole.
Le reti virtuali possono essere utili anche quando si configura la comunicazione tra risorse locali e cloud. Una rete privata virtuale può essere usata per collegare facilmente le due reti tra loro. Questo approccio consente di eseguire una rete virtuale senza alcun tipo di gateway per scenari in cui tutti gli utenti sono in loco. Esistono diverse tecnologie che possono essere usate per stabilire questa rete. La più semplice consiste nell'usare una VPN da sito a sito che può essere stabilita tra molti router e Azure. Il traffico viene crittografato e sottoposto a tunneling su Internet allo stesso costo per byte di qualsiasi altro traffico. Per gli scenari in cui è preferibile una maggiore larghezza di banda o più sicurezza, Azure offre un servizio denominato ExpressRoute che usa un circuito privato tra una rete locale e Azure. È più costoso e difficile stabilire, ma anche più sicuro.
Controllo degli accessi in base al ruolo per limitare l'accesso alle risorse di Azure
Il controllo degli accessi in base al ruolo è un sistema che fornisce un'identità alle applicazioni in esecuzione in Azure. Le applicazioni possono accedere alle risorse usando questa identità al posto dell’uso o in aggiunta all’uso di chiavi o password.
Entità di sicurezza
Il primo componente nel controllo degli accessi in base al ruolo è un'entità di sicurezza. Un’entità di sicurezza può essere un utente, un gruppo, un'entità servizio o un'identità gestita.
Figura 9-2. Tipi diversi di entità di sicurezza.
- Utente: qualsiasi utente che ha un account in Azure Active Directory è un utente.
- Gruppo: raccolta di utenti di Azure Active Directory. Come membro di un gruppo, un utente assume i ruoli di tale gruppo oltre al proprio.
- Entità servizio: identità di sicurezza con cui vengono eseguiti servizi o applicazioni.
- Identità gestita: identità di Azure Active Directory gestita da Azure. Le identità gestite vengono usate in genere durante lo sviluppo di applicazioni cloud che gestiscono le credenziali per l'autenticazione nei servizi di Azure.
L'entità di sicurezza può essere applicata alla maggior parte delle risorse. Questo aspetto significa che è possibile assegnare un'entità di sicurezza a un contenitore in esecuzione in Azure Kubernetes, consentendogli di accedere ai segreti archiviati in Key Vault. Una funzione di Azure potrebbe accettare un'autorizzazione che consente di comunicare con un'istanza di Active Directory per convalidare un token JWT per un utente chiamante. Dopo aver abilitato i servizi con un'entità servizio, le relative autorizzazioni possono essere gestite in modo granulare usando ruoli e ambiti.
Ruoli
Un entità di sicurezza può assumere molti ruoli o, usando un'analogia più sartoriale, indossare molti cappelli. Ogni ruolo definisce una serie di autorizzazioni, ad esempio "Leggere i messaggi dall'endpoint bus di servizio di Azure". Il set di autorizzazioni effettivo di un'entità di sicurezza è la combinazione di tutte le autorizzazioni assegnate a tutti i ruoli di un'entità di sicurezza. Azure ha un numero elevato di ruoli predefiniti e gli utenti possono definire i propri ruoli.
Figura 9-3. Definizioni di ruoli Controllo degli accessi in base al ruolo.
In Azure sono disponibili anche diversi ruoli di alto livello, ad esempio Proprietario, Collaboratore, Lettore e Amministrazione dell’account utente. Con il ruolo Proprietario, un'entità di sicurezza può accedere a tutte le risorse e assegnare autorizzazioni ad altri utenti. Un collaboratore ha lo stesso livello di accesso a tutte le risorse, ma non può assegnare autorizzazioni. Un lettore può solo visualizzare le risorse di Azure esistenti e un amministratore dell’account utente può gestire l'accesso alle risorse di Azure.
I ruoli predefiniti più granulari, ad esempio Collaboratore zona DNS, hanno diritti limitati a un singolo servizio. Le entità di sicurezza possono assumere un numero qualsiasi di ruoli.
Ambiti
I ruoli possono essere applicati a un set limitato di risorse all'interno di Azure. Ad esempio, applicando l'ambito all'esempio precedente di lettura da una coda di bus di servizio, è possibile limitare l'autorizzazione a una singola coda: "Leggere i messaggi dall'endpoint bus di servizio di Azure blah.servicebus.windows.net/queue1".
L'ambito può essere limitato a una singola risorsa oppure può essere applicato a un intero gruppo di risorse, a una sottoscrizione o anche a un gruppo di gestione.
Quando si verifica se un'entità di sicurezza dispone di determinate autorizzazioni, viene presa in considerazione la combinazione di ruolo e ambito. Questa combinazione fornisce un potente meccanismo di autorizzazione.
Nega
In precedenza, solo le regole "consenti" erano consentite per il controllo degli accessi in base al ruolo. Questo comportamento rendeva alcuni ambiti complicati da compilare. Ad esempio, consentire a un'entità di sicurezza l'accesso a tutti gli account di archiviazione ad eccezione di uno comportava dover concedere un'autorizzazione esplicita a un elenco potenzialmente infinito di account di archiviazione. Ogni volta che veniva creato un nuovo account di archiviazione, era necessario aggiungerlo a questo elenco di account. Ciò ha aggiunto un sovraccarico di gestione che certamente non era auspicabile.
Le regole di negazione hanno la precedenza sulle regole di autorizzazione. Ora, lo stesso ambito "consenti a tutti, tranne uno" può essere rappresentato con due regole "consenti a tutti" e "nega a questo specifico". Le regole di negazione non solo semplificano la gestione, ma consentono risorse che sono più sicure negando l'accesso a tutti.
Controllo dell'accesso
Come si può immaginare, avere un numero elevato di ruoli e ambiti può rendere difficile capire l'autorizzazione effettiva di un'entità servizio. Inoltre, l’accumulo di regole di negazione non fa che aumentare la complessità. Fortunatamente, è disponibile un calcolatore delle autorizzazioni che può mostrare le autorizzazioni valide per qualsiasi entità servizio. In genere si trova nella scheda IAM del portale, come illustrato nella figura 9-3.
Figura 9-4. Calcolatore delle autorizzazioni per un servizio app.
Protezione dei segreti
Password e certificati sono un vettore di attacco comune per gli utenti malintenzionati. L'hardware di cracking delle password può eseguire un attacco di forza bruta e cercare di indovinare miliardi di password al secondo. È quindi importante che le password usate per accedere alle risorse siano complesse, con un'ampia varietà di caratteri. Queste password sono esattamente il tipo di password che è quasi impossibile da ricordare. Fortunatamente, le password in Azure non devono essere effettivamente note da nessun essere umano.
Molti esperti di sicurezza suggeriscono che l'uso di un gestore delle password per mantenere le proprie password sia l'approccio migliore. Anche se centralizza le password in un'unica posizione, consente anche di usare password estremamente complesse e di garantire che siano univoche per ogni account. Lo stesso sistema esiste in Azure: un archivio centrale per i segreti.
Azure Key Vault
Azure Key Vault offre una posizione centralizzata per archiviare le password per elementi quali database, chiavi API e certificati. Una volta immesso un segreto nel Vault, questo non viene più visualizzato e i comandi per estrarlo e visualizzarlo sono intenzionalmente complicati. Le informazioni contenute nell'ambiente sicuro sono protette usando la crittografia software o i moduli di sicurezza hardware convalidati FIPS 140-2 livello 2.
L'accesso all'insieme di credenziali delle chiavi viene fornito tramite controllo degli accessi in base al ruolo; ciò significa che un utente qualsiasi non può accedere alle informazioni nell’insieme di credenziali delle chiavi. Supponiamo che un'applicazione Web voglia accedere alla stringa di connessione del database archiviata in Azure Key Vault. Per ottenere l'accesso, le applicazioni devono essere eseguite usando un'entità servizio. Con questo ruolo assunto, possono leggere i segreti dal safe. Esistono diverse impostazioni di sicurezza che possono limitare ulteriormente l'accesso che un'applicazione ha all'insieme di credenziali, in modo che non possa aggiornare i segreti ma solo leggerli.
L'accesso all'insieme di credenziali delle chiavi può essere monitorato per garantire che solo le applicazioni previste accedano all'insieme di credenziali. I log possono essere integrati di nuovo in Monitoraggio di Azure, abilitando la possibilità di configurare avvisi quando si verificano condizioni impreviste.
Kubernetes
All'interno di Kubernetes è disponibile un servizio simile per la gestione di piccole parti di informazioni segrete. I segreti Kubernetes possono essere impostati tramite il tipico kubectl eseguibile.
La creazione di un segreto è semplice come trovare la versione base64 dei valori da archiviare:
echo -n 'admin' | base64
YWRtaW4=
echo -n '1f2d1e2e67df' | base64
MWYyZDFlMmU2N2Rm
Quindi, aggiungerlo a un file di segreti denominato secret.yml, in modo analogo all'esempio seguente:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
Infine, questo file può essere caricato in Kubernetes eseguendo il comando seguente:
kubectl apply -f ./secret.yaml
Questi segreti possono quindi essere montati in volumi o esposti ai processi contenitore tramite variabili di ambiente. L'approccio dell'app a dodici fattori per la creazione di applicazioni suggerisce l'uso del minimo comune denominatore per trasmettere le impostazioni a un'applicazione. Le variabili di ambiente sono il minimo comune denominatore, perché sono supportate indipendentemente dal sistema operativo o dall'applicazione.
Un'alternativa all'uso dei segreti Kubernetes predefiniti consiste nell'accedere ai segreti in Azure Key Vault da Kubernetes. Il modo più semplice per eseguire questa operazione consiste nell'assegnare un ruolo Controllo degli accessi in base al ruolo al contenitore che cerca di caricare i segreti. L'applicazione può quindi usare le API di Azure Key Vault per accedere ai segreti. Tuttavia, questo approccio richiede modifiche al codice e non segue il modello di utilizzo delle variabili di ambiente. È invece possibile inserire valori in un contenitore. Questo approccio è in realtà più sicuro rispetto all'uso diretto dei segreti Kubernetes, perché consente l’accesso agli utenti nel cluster.
Crittografia in transito e inattiva
Mantenere i dati al sicuro è importante sia sul disco che durante il transito tra diversi servizi. Il modo più efficace per impedire la perdita di dati consiste nel crittografare in un formato che non può essere letto facilmente da altri utenti. Azure supporta un'ampia gamma di opzioni di crittografia.
In transito
Esistono diversi modi per crittografare il traffico nella rete in Azure. L'accesso ai servizi di Azure viene in genere eseguito sulle connessioni che usano Transport Layer Security (TLS). Ad esempio, tutte le connessioni alle API di Azure richiedono connessioni TLS. Allo stesso modo, le connessioni agli endpoint nelle risorse di archiviazione di Azure possono essere limitate per funzionare solo tramite connessioni crittografate TLS.
TLS è un protocollo complesso e sapere semplicemente che la connessione sta usando TLS non è sufficiente per garantire la sicurezza. Ad esempio, TLS 1.0 è cronicamente non sicuro e TLS 1.1 non è di molto migliore. Anche all'interno delle versioni di TLS sono disponibili varie impostazioni che consentono di semplificare la decrittografia delle connessioni. L'azione migliore consiste nel verificare se la connessione al server usa protocolli aggiornati e ben configurati.
Questo controllo può essere eseguito da un servizio esterno, ad esempio il test del server SSL dei lab SSL. Un test eseguito su un tipico endpoint di Azure, in questo caso un endpoint del bus di servizio, restituisce un punteggio quasi perfetto di A.
Anche i servizi come i database SQL di Azure usano la crittografia TLS per mantenere nascosti i dati. La parte interessante sulla crittografia dei dati in transito con TLS è che non è possibile, anche per Microsoft, rimanere in ascolto sulla connessione tra computer che eseguono TLS. Ciò dovrebbe rappresentare una sicurezza per le aziende preoccupate per il fatto che i dati possano essere a rischio con Microsoft o un soggetto di stato con più risorse rispetto all'utente malintenzionato standard.
Figura 9-5. Report lab SSL che mostra un punteggio A per un endpoint bus di servizio.
Anche se questo livello di crittografia non sarà sempre sufficiente, dovrebbe ispirare la fiducia nel fatto che le connessioni TLS di Azure siano abbastanza sicure. Azure continuerà a evolvere i propri standard di sicurezza man mano che la crittografia migliora. È bello sapere che ci sia qualcuno che osserva gli standard di sicurezza e aggiorna Azure man mano che vi siano miglioramenti.
Inattivi
In qualsiasi applicazione, i dati si trovano sul disco in diverse posizioni. Il codice dell'applicazione stesso viene caricato da un meccanismo di archiviazione. La maggior parte delle applicazioni usa anche alcuni tipi di database, ad esempio SQL Server, Cosmos DB, o anche Archiviazione tabelle, estremamente conveniente. Questi database usano tutti l'archiviazione fortemente crittografata per garantire che nessuno ad eccezione delle applicazioni con autorizzazioni appropriate possa leggere i dati. Neanche gli operatori di sistema possono leggere i dati crittografati. Quindi, i clienti possono avere la sicurezza che le informazioni segrete rimangano segrete.
Storage
La base di gran parte di Azure è il motore di Archiviazione di Azure. I dischi delle macchine virtuali vengono montati sopra Archiviazione di Azure. servizio Azure Kubernetes in esecuzione su macchine virtuali ospitate in Archiviazione di Azure. Anche le tecnologie serverless, ad esempio app Funzioni di Azure e Istanze di contenitore di Azure, vengono eseguite sul disco che fa parte di Archiviazione di Azure.
Se Archiviazione di Azure è ben crittografato, fornisce una base per la maggior parte di tutti gli altri elementi da crittografare. Archiviazione di Azure viene crittografato con AES a 256 bit conforme a FIPS 140-2. Si tratta di una tecnologia di crittografia oggetto di un ampio esame accademico negli ultimi 20 anni. Attualmente, non esiste un attacco pratico noto che consentirebbe a un utente che non conosca la chiave di leggere i dati crittografati da AES.
Per impostazione predefinita, le chiavi usate per crittografare Archiviazione di Azure vengono gestite da Microsoft. Esistono protezioni estese per garantire l'accesso dannoso a queste chiavi. Tuttavia, gli utenti con requisiti di crittografia specifici possono anche fornire chiavi di archiviazione proprie gestite in Azure Key Vault. Queste chiavi possono essere revocate in qualsiasi momento, rendendo effettivamente inaccessibile il contenuto dell'account di archiviazione.
Le macchine virtuali usano l'archiviazione crittografata, ma è possibile fornire un altro livello di crittografia usando tecnologie come BitLocker in Windows o DM-Crypt in Linux. Queste tecnologie indicano che, anche se l'immagine del disco fosse uscita dallo spazio di archiviazione, sarebbe rimasta quasi impossibile da leggere.
Azure SQL
I database ospitati in AZURE SQL usano una tecnologia denominata Transparent Data Encryption (TDE) per garantire che i dati rimangano crittografati. È abilitata per impostazione predefinita in tutti i database SQL appena creati, ma deve essere abilitata manualmente per i database legacy. TDE esegue crittografia e decrittografia in tempo reale, non solo del database, ma anche dei backup e dei log delle transazioni.
I parametri di crittografia vengono archiviati nel database master e, all'avvio, vengono letti in memoria per le operazioni rimanenti. Ciò significa che il database master deve rimanere non crittografato. La chiave effettiva viene gestita da Microsoft. Tuttavia, gli utenti con requisiti di sicurezza esatti possono fornire la propria chiave in Key Vault nello stesso modo in cui viene fatto per Archiviazione di Azure. Key Vault fornisce servizi come la rotazione e la revoca delle chiavi.
La parte "Transparent" di TDS deriva dal fatto che non sono presenti modifiche client necessarie per usare un database crittografato. Sebbene questo approccio fornisca una buona sicurezza, la perdita della password del database è sufficiente per consentire agli utenti di decrittografare i dati. Esiste un altro approccio che crittografa singole colonne o tabelle in un database. Always Encrypted garantisce che in nessun momento i dati crittografati vengano visualizzati in testo normale all'interno del database.
Per configurare questo livello di crittografia è necessario eseguire una procedura guidata in SQL Server Management Studio per selezionare il tipo di crittografia e lo spazio in Key Vault in cui archiviare le chiavi associate.
Figura 9-6. Selezione di colonne in una tabella da crittografare tramite Always Encrypted.
Le applicazioni client che leggono informazioni da queste colonne crittografate devono avere una particolare necessità di leggere i dati crittografati. Le stringhe di connessione devono essere aggiornate con Column Encryption Setting=Enabled e le credenziali client devono essere recuperate dal Key Vault. Il client SQL Server deve quindi essere inizializzato con le chiavi di crittografia della colonna. Al termine delle operazioni, le azioni rimanenti usano le interfacce standard per SQL Client. Ovvero, gli strumenti come Dapper ed Entity Framework, basati su SQL Client, continueranno a funzionare senza modifiche. Always Encrypted potrebbe non essere ancora disponibile per ogni driver di SQL Server in ogni lingua.
La combinazione di TDE e Always Encrypted, entrambe utilizzabili con chiavi specifiche del client, garantisce che siano supportati anche i requisiti di crittografia più precisi.
Cosmos DB
Cosmos DB è il database più recente fornito da Microsoft in Azure. È stato costruito da zero pensando a sicurezza e crittografa. La crittografia AES a 256 bit è standard per tutti i database Cosmos DB e non può essere disabilitata. Insieme al requisito TLS 1.2 per la comunicazione, viene crittografata l'intera soluzione di archiviazione.
Figura 9-7. Flusso di crittografia dei dati in Cosmos DB.
Anche se Cosmos DB non si occupa della fornitura di chiavi di crittografia dei clienti, il team ha eseguito un lavoro significativo per assicurarsi che rimanga conforme a PCI-DSS senza questo elemento. Cosmos DB non supporta inoltre alcun tipo di crittografia a colonna singola simile a Always Encrypted di Azure SQL.
Mantenere la sicurezza
Azure offre tutti gli strumenti necessari per rilasciare un prodotto altamente sicuro. Tuttavia, una catena è forte come il suo anello più debole. Se le applicazioni distribuite su Azure non vengono sviluppate con una mentalità di sicurezza appropriata e con controlli di sicurezza validi, diventano l’anello debole nella catena. Esistono molti ottimi strumenti di analisi statica, librerie di crittografia e procedure di sicurezza che è possibile usare per garantire che il software installato in Azure sia sicuro come Azure stesso. Tra gli esempi vi sono strumenti di analisi statica, librerie di crittografia e procedure di sicurezza.
