Pianificare l'attestazione del servizio Sorveglianza host

  • Articolo

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

L'attestazione è un flusso di lavoro che consente a un'applicazione client di verificare che stia parlando con un'enclave attendibile all'interno del processo di SQL Server quando si 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 introduce a questo scopo una terza parte che può convalidare l'identità (e, facoltativamente, la configurazione) del computer computer con 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 comunicare con un'enclave VBS attendibile ed eseguirà la query che userà tale 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 Servizio Sorveglianza host (HGS) in Windows Server 2019 o versioni successive fornisce funzionalità di attestazione remota per Always Encrypted con enclave VBS. Questo articolo illustra le decisioni relative alla pre-distribuzione e i requisiti per usare Always Encrypted con enclave di sicurezza basata sulla virtualizzazione 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 nessuna 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 informazioni dettagliate su come viene determinato il quorum del cluster e sulle configurazioni alternative, inclusi i cluster a due nodi con una risorsa di controllo esterna, vedere la 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 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, è consigliabile usare l'attestazione con tasto host perché la maggior parte delle macchine virtuali non ha TPM virtuali o l'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 attendibilità dell'enclave di sicurezza basata sulla virtualizzazione, le query e i dati crittografati vengono valutati in un'enclave basata su software per proteggerli 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.

Per consentire a un client di considerare attendibile la comunicazione con un'istanza legittima di sicurezza basata su virtualizzazione, è necessario usare l'attestazione basata su TPM che stabilisce una radice di attendibilità hardware nel computer con SQL Server.

Le misurazioni TPM acquisite durante il processo di avvio includono la chiave di identità univoca dell'istanza della sicurezza basata sulla virtualizzazione, assicurando che il certificato di integrità sia valido solo in quel determinato 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 si considera attendibile l'hypervisor o il provider di servizi cloud e la preoccupazione principale deriva dell'amministratore del database e dagli attacchi dell'amministratore del sistema operativo ai dati sensibili, un SQL Server virtualizzato può essere la soluzione ideale.

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. È comunque possibile usare molte delle funzionalità di sicurezza descritte, tra cui l'avvio protetto e un modulo TPM 1.2, per proteggere meglio la sicurezza basata su virtualizzazione 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 (min), 4 core (scelta consigliata)
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 aggiungere i computer HGS a un dominio prima di iniziare la procedura.

Prerequisiti del computer con SQL Server

I computer che eseguono SQL Server devono soddisfare sia i requisiti per l'installazione di SQL Server che 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 versioni successive, abilitare il supporto della sicurezza basata sulla virtualizzazione per la macchina virtuale come descritto nella documentazione di VMware.
      • Anche altri hypervisor e cloud pubblici possono supportare le funzionalità di virtualizzazione annidata che abilitano Always Encrypted con enclave di sicurezza basata sulla virtualizzazione. 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:
    • Distribuire un solo 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. Poiché questo approccio lascia le chiavi master della colonna nello stesso computer di SQL Server, evitare di adottarlo in un ambiente di produzione.

Passaggi successivi