Pianificare l'attestazione di Host Guardian Service

Si applica a: SQL Server 2019 (15.x) e versioni successive in Windows

L'attestazione è una procedura che consente a un'applicazione client di verificare che stia comunicando con un'enclave attendibile all'interno del processo di SQL Server quando usa Always Encrypted con enclave sicure.

In SQL Server, Always Encrypted con enclave sicure usa le enclave con sicurezza basata su virtualizzazione (VBS), note anche come modalità protetta virtuale o enclave VSM, ovvero una tecnologia basata sull'hypervisor Windows che non richiede hardware speciale. L'attestazione di un'enclave VBS comporta la verifica della validità del codice all'interno dell'enclave e quella dell'attendibilità del computer che ospita SQL Server. L'attestazione raggiunge questo obiettivo introducendo un soggetto terzo che può convalidare l'identità (e, facoltativamente, la configurazione) del computer che esegue SQL Server. Prima che SQL Server possa usare un'enclave per eseguire una query, deve fornire al servizio di attestazione informazioni sull'ambiente operativo per ottenere un certificato di integrità. Questo certificato di integrità viene quindi inviato al client, che può verificarne in modo indipendente l'autenticità con il servizio di attestazione. Quando il client considera attendibile il certificato di integrità, sa di interagire con un'enclave VBS attendibile e invierà la query che userà quell'enclave.

L'attestazione è fondamentale per rilevare alcuni attacchi da parte di amministratori del sistema operativo malintenzionati, ad esempio attacchi che comportano manomissioni del catalogo di SQL Server in esecuzione all'interno dell'enclave. Se tali attacchi non costituiscono una preoccupazione (ad esempio, se si usa Always Encrypted con enclave sicure in un ambiente non di produzione), vedere Pianificare Always Encrypted con enclave sicure in SQL Server senza attestazione.

Il ruolo del Servizio di protezione host (HGS) in Windows Server 2019 o versione successiva fornisce funzionalità di attestazione remota per Always Encrypted con enclave VBS. Questo articolo ti guida nelle decisioni da prendere prima della distribuzione e nei requisiti necessari per usare Always Encrypted con enclave VBS e l'attestazione HGS.

Nota

Quando SQL Server viene implementato in una VM, le enclave VBS consentono di proteggere i dati dagli attacchi all'interno della VM. Tuttavia, non forniscono alcuna protezione dagli attacchi che usano account di sistema con privilegi provenienti dall'host. Ad esempio, un backup della memoria della VM generata nel computer host può contenere la memoria dell'enclave.

Panoramica dell'architettura

Il servizio Sorveglianza host (HGS) è un servizio Web in cluster eseguito in Windows Server 2019 o versioni successive. In una distribuzione tipica, saranno presenti da 1 a 3 server HGS, almeno un computer che esegue SQL Server e un computer che esegue un'applicazione client o strumenti come SQL Server Management Studio. Poiché HGS deve determinare quali dei computer che eseguono SQL Server sono attendibili, richiede l'isolamento sia fisico che logico dall'istanza di SQL Server protetta. Se gli stessi amministratori hanno accesso a HGS e a un computer con SQL Server, potrebbero configurare il servizio di attestazione per consentire a un computer dannoso di eseguire SQL Server e compromettere in questo modo l'enclave VBS.

Dominio HGS

Il programma di installazione di HGS creerà automaticamente un nuovo dominio di Active Directory per i server HGS, le risorse cluster di failover e gli account amministratore.

Non è necessario che il computer che esegue SQL Server sia in un dominio, ma, se così fosse, deve trattarsi di un dominio diverso da quello usato dal server HGS.

Disponibilità elevata

La funzionalità HGS installa e configura automaticamente un cluster di failover. In un ambiente di produzione è consigliabile usare tre server HGS per la disponibilità elevata. Per dettagli su come viene stabilito il quorum del cluster e sulle configurazioni alternative, inclusi i cluster a due nodi con un testimone esterno, fare riferimento alla documentazione del cluster di failover.

L'archiviazione condivisa non è necessaria tra i nodi HGS. Una copia del database di attestazione viene archiviata in ogni server HGS e viene replicata automaticamente in rete dal servizio cluster.

Connettività di rete

Sia il client SQL che SQL Server devono riuscire a comunicare con HGS su HTTP. Configurare HGS con un certificato TLS per crittografare tutte le comunicazioni tra il client SQL e HGS, nonché tra SQL Server e HGS. Questa configurazione offre protezione dagli attacchi man-in-the-middle e garantisce la comunicazione con il server HGS corretto.

I server HGS richiedono la connettività tra ogni nodo del cluster per garantire che il database del servizio di attestazione rimanga sincronizzato. Si tratta di una procedura consigliata per il cluster di failover per connettere i nodi HGS in una rete per la comunicazione del cluster e usare una rete separata per consentire ad altri client di comunicare con HGS.

Modalità di attestazione

Quando un computer che esegue SQL Server prova a eseguire l'attestazione con HGS, chiederà prima di tutto a HGS come eseguire l'attestazione. HGS supporta due modalità di attestazione per l'uso con SQL Server::

Modalità di attestazione Spiegazione
TPM L'attestazione TPM (Trusted Platform Module) offre la massima garanzia sull'identità e sull'integrità del computer che esegue l'attestazione con HGS. Richiede che nei computer che eseguono SQL Server sia installato TPM versione 2.0. Ogni chip TPM contiene un'identità univoca e non modificabile (chiave di verifica dell'autenticità) che può essere usata per identificare un determinato computer. I moduli TPM misurano anche il processo di avvio del computer, archiviando hash di misurazioni basate sulla sicurezza nei registri PCR che possono essere letti, ma non modificati dal sistema operativo. Queste misurazioni vengono usate durante l'attestazione per fornire la prova crittografica che la configurazione di sicurezza di un computer corrisponda effettivamente a quella dichiarata.
Chiave dell'host L'attestazione chiave host è una forma più semplice di attestazione che verifica solo l'identità di un computer usando una coppia di chiavi asimmetriche. La chiave privata viene archiviata nel computer che esegue SQL Server e la chiave pubblica viene fornita a HGS. La configurazione di sicurezza del computer non viene misurata e non è necessario un chip TPM 2.0 nel computer che esegue SQL Server. È importante proteggere la chiave privata installata nel computer con SQL Server perché chiunque ottenga questa chiave può rappresentare un computer con SQL Server legittimo e l'enclave VBS in esecuzione all'interno di SQL Server.

In generale, tenere presenti le indicazioni seguenti:

  • Per i server di produzione fisici, è consigliabile usare l'attestazione TPM per le garanzie aggiuntive fornite.
  • Per i server di produzione virtuali, consigliamo l'attestazione della chiave host, poiché la maggior parte delle macchine virtuali non dispone di un TPM virtuale né dell'Avvio protetto. Se si usa una macchina virtuale con sicurezza avanzata, come una macchina virtuale schermata locale, è possibile scegliere di usare la modalità TPM. In tutte le distribuzioni virtualizzate, il processo di attestazione analizza solo l'ambiente della VM e non la piattaforma di virtualizzazione sottostante.
  • Per gli scenari di sviluppo/test, è consigliabile usare l'attestazione con tasto host perché è più facile da configurare.

Modello di attendibilità

Nel modello di trust dell'enclave VBS, le query e i dati crittografati vengono elaborati in un'enclave basata su software per proteggerla dal sistema operativo host. L'accesso a questo enclave è protetto dall'hypervisor nello stesso modo in cui due macchine virtuali in esecuzione nello stesso computer non possono accedere l'una alla memoria dell'altra.

Affinché un client abbia la certezza di comunicare con un'istanza legittima di VBS, è necessario usare l'attestazione basata su TPM, che stabilisce una radice di attendibilità hardware sul computer che esegue SQL Server.

Le misurazioni TPM acquisite durante il processo di avvio includono la chiave di identità univoca dell'istanza VBS, garantendo che il certificato di integrità sia valido solo su quello specifico computer. Inoltre, quando un modulo TPM è disponibile in un computer che esegue la sicurezza basata sulla virtualizzazione, la parte privata della chiave di identità della sicurezza basata sulla virtualizzazione è protetta dal modulo TPM, che impedisce a chiunque di provare a rappresentare tale istanza della sicurezza basata sulla virtualizzazione.

L'avvio protetto è necessario con l'attestazione TPM per garantire che UEFI abbia caricato un bootloader legittimo firmato da Microsoft e che nessun rootkit abbia intercettato il processo di avvio dell'hypervisor. Per impostazione predefinita, è anche necessario un dispositivo IOMMU per garantire che nessun dispositivo hardware con accesso diretto alla memoria possa ispezionare o modificare la memoria dell'enclave.

Tutte queste protezioni presuppongono che il computer che esegue SQL Server sia un computer fisico. Se si virtualizza il computer che esegue SQL Server, non è più possibile garantire che la memoria della VM sia sicura nell'ispezione da parte dell'hypervisor o dell'amministratore dell'hypervisor. Un amministratore dell'hypervisor potrebbe, ad esempio, eseguire il backup della memoria della VM e ottenere l'accesso alla versione in testo non crittografato della query e dei dati nell'enclave. Analogamente, anche se la macchina virtuale ha un modulo TPM virtuale, può solo misurare lo stato e l'integrità del sistema operativo e dell'ambiente di avvio della macchina virtuale. Non può misurare lo stato dell'hypervisor che controlla la VM.

Tuttavia, anche quando SQL Server è virtualizzato, l'enclave continua a essere protetta da attacchi provenienti dal sistema operativo della VM. Se ritieni affidabile il tuo hypervisor o provider cloud e sei principalmente preoccupato per gli attacchi ai dati sensibili da parte degli amministratori del database e del sistema operativo, un SQL Server virtualizzato può soddisfare i tuoi requisiti.

Analogamente, l'attestazione con tasto host resta utile nelle situazioni in cui non è installato un modulo TPM 2.0 nel computer che esegue SQL Server o in scenari di sviluppo/test in cui la sicurezza non è fondamentale. È ancora possibile usare molte delle funzioni di sicurezza menzionate, tra cui Secure Boot e un modulo TPM 1.2, per proteggere meglio VBS e il sistema operativo nel suo complesso. Poiché tuttavia HGS non può verificare che nel computer queste impostazioni siano effettivamente abilitate con l'attestazione chiave host, il client non ha la certezza che l'host stia realmente usando tutte le protezioni disponibili.

Prerequisiti

Prerequisiti del server HGS

I computer che eseguono il ruolo Servizio Sorveglianza host devono soddisfare i requisiti seguenti:

Componente Requisito
Sistema operativo Windows Server 2019 o versioni successive, edizioni Standard o Datacenter
CPU 2 core (minimo), 4 core (consigliato)
RAM 8 GB (min)
Schede di interfaccia di rete Si consigliano 2 schede di interfaccia di rete con indirizzi IP statici (1 per il traffico del cluster, 1 per il servizio HGS)

HGS è un ruolo associato alla CPU a causa del numero di azioni che richiedono la crittografia e la decrittografia. L'uso di processori moderni con funzionalità di accelerazione della crittografia migliorerà le prestazioni di HGS. I requisiti di archiviazione per i dati di attestazione sono minimi, da 10 KB a 1 MB per ogni singolo computer che esegue l'attestazione.

Non unire i computer HGS a un dominio prima di iniziare.

Prerequisiti del computer con SQL Server

I computer che eseguono SQL Server devono soddisfare sia i requisiti per l'installazione di SQL Server sia i requisiti hardware di Hyper-V.

I requisiti includono:

  • SQL Server 2019 (15.x) o versioni successive
  • Windows 10, versione 1809 o successive - edizione Enterprise, Windows 11 o versioni successive - edizione Enterprise, Windows Server 2019 o versioni successive - edizione Datacenter. Le altre edizioni di Windows 10/11 e Windows Server non supportano l'attestazione con HGS.
  • Supporto della CPU per le tecnologie di virtualizzazione:
    • Intel VT-x con Extended Page Tables.
    • AMD-V con Rapid Virtualization Indexing.
    • Se si esegue SQL Server in una VM:
      • In Azure, usare una dimensione VM di seconda generazione (scelta consigliata) o una dimensione VM di prima generazione con la virtualizzazione annidata abilitata. Consultare la documentazione sulle dimensioni delle singole VM per determinare le dimensioni di VM di prima generazione che supportano la virtualizzazione annidata.
      • In Hyper-V 2016 o versioni successive (all'esterno di Azure), accertarsi che la VM sia di seconda generazione (scelta consigliata) o di prima generazione con la virtualizzazione annidata. Per ulteriori informazioni, vedere È necessario creare una macchina virtuale di generazione 1 o 2 in Hyper-V? e Configurare una virtualizzazione annidata.
      • In VMware vSphere 6.7 o versione successiva abilitare il supporto della sicurezza basato su virtualizzazione per la macchina virtuale. Consultare la tua documentazione VMware per istruzioni sull'abilitazione di VBS (sicurezza basata sulla virtualizzazione) e della virtualizzazione annidata per la versione specifica di vSphere.
      • Anche altri hypervisor e cloud pubblici possono supportare funzionalità di virtualizzazione annidata che consentono anche Always Encrypted con VBS Enclaves. Vedere la documentazione della soluzione di virtualizzazione per informazioni sulla compatibilità e istruzioni per la configurazione.
  • Se si prevede di usare l'attestazione TPM, è necessario un chip TPM 2.0 rev 1.16 pronto per l'uso nel server. Per il momento, l'attestazione HGS non funziona con i chip TPM 2.0 rev 1.38. Il modulo TPM deve anche avere un certificato valido della chiave di verifica dell'autenticità.

Ruoli e responsabilità per la configurazione dell'attestazione con HGS

La configurazione dell'attestazione con HGS prevede la configurazione di componenti di tipi diversi: HGS, computer con SQL Server, istanze di SQL Server e applicazioni che attivano l'attestazione dell'enclave. La configurazione dei componenti di ogni tipo viene eseguita dagli utenti presupponendo uno dei ruoli distinti seguenti:

  • Amministratore di HGS: implementa HGS, registra i computer con SQL Server in HGS e condivide l'URL di attestazione di HGS con amministratori del computer con SQL Server e amministratori di applicazioni client.
  • Amministratore del computer con SQL Server: installa i componenti client di attestazione, abilita VBS nei computer con SQL Server, fornisce all'amministratore di HGS le informazioni necessarie per registrare i computer con SQL Server in HGS, configura l'URL di attestazione nei computer con SQL Server e verifica che l'attestazione dei computer con SQL Server in HGS funzioni correttamente.
  • DBA: configura le enclave sicure nelle istanze di SQL Server.
  • Amministratore delle applicazioni: configura l'applicazione con l'URL di attestazione ottenuto dall'amministratore di HGS.

Negli ambienti di produzione (che gestiscono dati sensibili reali), è importante che l'organizzazione rispetti la separazione dei ruoli durante la configurazione dell'attestazione, assicurandosi che ogni ruolo distinto venga assunto da persone diverse. In particolare, se l'obiettivo dell'implementazione di Always Encrypted nell'organizzazione è quello di ridurre la superficie di attacco garantendo che gli amministratori di computer con SQL Server e i DBA non possano accedere ai dati sensibili, gli amministratori del server SQL e i DBA non devono controllare i server HGS.

Considerazioni sull'ambiente di sviluppo o test

Se si usa Always Encrypted con le enclave VBS in un ambiente di sviluppo o di test e non è necessaria la disponibilità elevata o la protezione avanzata del computer che esegue SQL Server, è possibile applicare alcune o tutte le concessioni seguenti per una distribuzione semplificata:

  • Usare Always Encrypted con enclave sicure senza attestazione: vedere Pianificare Always Encrypted con enclave sicure in SQL Server senza attestazione.
  • In alternativa:
    • Distribuisci solo un nodo di HGS. Anche se HGS installa un cluster di failover, non è necessario aggiungere altri nodi se la disponibilità elevata non è un problema.
    • Usare la modalità chiave host invece della modalità TPM per semplificare la configurazione.
    • Virtualizzare HGS e/o SQL Server per salvare le risorse fisiche.
    • Eseguire SSMS o altri strumenti per la configurazione di Always Encrypted con enclave sicure nello stesso computer di SQL Server. Questo lascia le chiavi master di colonna sullo stesso computer di SQL Server, quindi non farlo in un ambiente di produzione.

Contenuti correlati

  • Last updated on