Condividi tramite


Resilienza tra aree per SQL TDE con il modulo di protezione hardware gestito di Azure Key Vault

Istanza gestita di SQL di Azure
Azure Key Vault

Idee per soluzioni

In questo articolo viene descritta un'idea di soluzione. Il cloud architect può usare queste linee guida per visualizzare i componenti principali di un'implementazione tipica di questa architettura. Usare questo articolo come punto di partenza per il design di una soluzione ben progettata che sia in linea con i requisiti specifici del carico di lavoro.

Questa soluzione descrive un modello di distribuzione sicuro e resiliente per Istanza gestita di SQL di Azure. Illustra come viene usato il modulo di protezione hardware gestito di Azure Key Vault per archiviare le chiavi di protezione TDE (Transparent Data Encryption) gestite dal cliente.

Architettura

Diagramma che mostra l'architettura di Istanza gestita di SQL sicura e resiliente.

Il diagramma include due sezioni chiave, l'area primaria e l'area secondaria. L'area primaria include una sottosezione che include Istanza gestita di SQL, zone di disponibilità e una subnet con un gruppo di sicurezza di rete.The primary region has a subsection that includes SQL Managed Instance, availability zones, and a subnet with a network security group (NSG). L'area primaria ha un'altra sottosezione che include una subnet con un gruppo di sicurezza di rete, un endpoint privato per l'area primaria del Managed HSM, un altro endpoint privato, un bilanciatore di carico e un pool di Managed HSM. Ogni sottosezione ha una rete virtuale e gruppi di risorse. Anche una zona DNS privata per mHSM si trova nell'area primaria. L'area secondaria replica le risorse dell'area primaria. Una freccia etichettata 'piano di gestione' punta da Istanza Gestita di SQL a Traffic Manager nella sezione risorse globali esterne. Una freccia etichettata "replica dei dati tra regioni" punta dalla sottosezione Istanza gestita di SQL nella regione primaria alla stessa sottosezione nella regione secondaria. Una freccia etichettata "replica tra regioni" indica dalla sottosezione del pool di HSM gestiti nella regione primaria alla stessa sottosezione nella regione secondaria. In ogni area, una freccia con l'etichetta "data plane" punta dall'istanza gestita di SQL all'endpoint privato e quindi a Traffic Manager. In ogni area, una freccia etichettata piano di controllo punta da istanza gestita di SQL a Gestione del traffico. In ogni area, una freccia punta da Traffic Manager al pool di HSM gestiti, indicando che Traffic Manager reindirizza all'mHSM più vicino.

Scaricare un file di Visio di questa architettura.

Flusso di lavoro

Il flusso di lavoro seguente corrisponde al diagramma precedente:

  1. Istanza gestita di SQL è configurata con i gruppi di disponibilità nell'area secondaria non abbinata per replicare i dati per il ripristino di emergenza.

  2. Managed HSM è configurato con un pool multi-regionale. Questo pool replica automaticamente il materiale della chiave e le relative autorizzazioni nel vault nell'area secondaria non associata.

  3. Il traffico del piano dati da SQL Managed Instance passa attraverso l'endpoint privato di Managed HSM.

  4. Il Managed HSM utilizza Azure Traffic Manager per instradare il traffico verso il vault operativo più vicino.

  5. Se l'istanza gestita deve controllare le autorizzazioni per una chiave, invia una richiesta del piano di gestione sulla rete backbone di Azure.

Componenti

  • SQL Istanza Gestita è un'offerta PaaS quasi completamente compatibile con il motore di database più recente di SQL Server Enterprise Edition. Offre un'implementazione di rete virtuale nativa che migliora la sicurezza e offre un modello aziendale vantaggioso per i clienti di SQL Server esistenti. È possibile usare Istanza gestita di SQL per eseguire la migrazione delle applicazioni locali al cloud con modifiche minime alle applicazioni e ai database.

    Istanza gestita di SQL offre anche funzionalità PaaS complete, tra cui l'applicazione automatica di patch e gli aggiornamenti delle versioni, i backup automatizzati e la disponibilità elevata. Queste funzionalità riducono significativamente il sovraccarico di gestione e il costo totale di proprietà. In questa architettura, *SQL Managed Instance* è il database che usa le chiavi di protezione per TDE.

  • La Managed HSM è un servizio cloud completamente gestito che offre alta disponibilità, single tenancy e conformità agli standard del settore. Il modulo di protezione hardware gestito è progettato per proteggere le chiavi crittografiche per le applicazioni cloud. Utilizza HSM convalidati secondo gli standard federali di elaborazione delle informazioni 140-2 di Livello 3. In Azure, l'HSM gestito è una delle diverse soluzioni di gestione delle chiavi. In questa architettura il modulo di protezione hardware gestito archivia in modo sicuro le chiavi di protezione TDE e offre resilienza tra aree.

  • Un endpoint privato di Azure funge da interfaccia di rete che connette in modo sicuro i servizi PaaS, ad esempio Archiviazione di Azure, il database SQL di Azure e Azure Key Vault a una rete virtuale tramite un indirizzo IP privato. Questa funzionalità elimina la necessità di esposizione a Internet pubblico, migliorando la sicurezza mantenendo il traffico all'interno della rete backbone di Azure. Usa anche la rete virtuale del cliente per una maggiore protezione. In questa architettura, un endpoint privato di Azure garantisce che il traffico tra i servizi passi attraverso una rete virtuale privata.

  • DNS privato di Azure offre una risoluzione dei nomi senza problemi per gli endpoint privati, che consente alle risorse all'interno di una rete virtuale di accedere privatamente ai servizi di Azure. Consente loro di usare nomi di dominio completi anziché indirizzi IP pubblici, che migliorano la sicurezza e l'accessibilità. Quando viene creato un endpoint privato, un record DNS (Domain Name System) corrispondente viene registrato automaticamente nella zona DNS privata collegata. Una zona DNS privata garantisce che il traffico verso il servizio rimanga all'interno della rete backbone di Azure. Questo approccio migliora la sicurezza, le prestazioni e la conformità evitando l'esposizione a Internet pubblico. Se si verifica un'interruzione del servizio a livello di area, DNS privato di Azure offre resilienza nativa nella risoluzione dei nomi a livello regionale per HSM gestito. In questa architettura i servizi usano DNS privato di Azure per comunicare tra loro tramite gli indirizzi di rete privata.

Dettagli dello scenario

In questa soluzione, un cliente mira a soddisfare soglie SLO (Service Level Objective) rigide per il proprio sistema mission-critical garantendo al tempo stesso la piena funzionalità dei servizi elencati. Per raggiungere questo obiettivo, usano Istanza gestita di SQL con una chiave di protezione TDE gestita dal cliente. La chiave viene archiviata in una cassaforte che supporta le regioni scelte e soddisfa tutti i requisiti di conformità e sicurezza. L'accesso agli endpoint privati viene applicato anche per la protezione avanzata.

Casi d'uso potenziali

  • Un cliente usa due aree abbinate o non abbinate. L'istanza gestita di SQL primaria si trova in un'area e i gruppi di failover sono configurati per la connessione con Istanza gestita di SQL nell'area secondaria.

  • Un cliente utilizza un'istanza HSM gestito in una regione primaria, con una replica tra regioni in una regione secondaria. Quando una replica tra aree è abilitata, viene creata un'istanza di Gestione traffico. L'istanza di Traffic Manager gestisce l'instradamento del traffico verso il vault locale se entrambi i vault sono operativi o verso il vault operativo se un vault non è disponibile.

  • Un cliente utilizza due zone DNS personalizzate per supportare un endpoint privato per un'istanza di Managed HSM in ciascuna regione.

  • Un TDE abilitato dal cliente nei database utente utilizza un modello di chiave gestita dal cliente e archivia una chiave di protezione nel HSM gestito.

  • Un cliente usa questa progettazione per offrire la massima resilienza possibile.

Contributori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autori principali:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi