Planifier l’attestation du Service Guardian hôte

  • Article

S’applique à : SQL Server 2019 (15.x) et versions ultérieures - Windows uniquement

L’attestation est un flux de travail qui permet à une application cliente de vérifier qu’elle parle à une enclave fiable au sein du processus SQL Server lors de l’utilisation d’Always Encrypted avec enclaves sécurisées.

Dans SQL Server, Always Encrypted avec enclaves sécurisées utilise des enclaves de sécurité basée sur la virtualisation (VBS) (également appelées enclaves virtual secure ou VSM) - une technologie basée sur un logiciel qui s’appuie sur l’hyperviseur Windows et ne nécessite aucun matériel spécial. L’attestation d’une enclave VBS implique de vérifier que le code à l’intérieur de l’enclave est valide et que l’ordinateur hébergeant SQL Server est fiable. L’attestation atteint cet objectif en introduisant un tiers capable de valider l’identité (et éventuellement la configuration) de l’ordinateur SQL Server. Avant que SQL Server puisse utiliser une enclave pour exécuter une requête, il doit fournir des informations au service d’attestation sur son environnement d’exploitation pour obtenir un certificat d’intégrité. Ce certificat d’intégrité est ensuite envoyé au client, qui peut vérifier son authenticité de façon indépendante auprès du service d’attestation. Le client sait, une fois qu’il a approuvé le certificat d’intégrité, qu’il communique avec une enclave de confiance pour la sécurité basée sur la virtualisation. Il émet alors la requête qui va utiliser cette enclave.

L’attestation est essentielle pour détecter certaines attaques par des administrateurs de système d’exploitation malveillants, par exemple, des attaques impliquant une falsification de la bibliothèque SQL Server s’exécutant à l’intérieur de l’enclave. Si vous ne vous inquiétez pas de ces attaques (par exemple, vous utilisez Always Encrypted avec enclaves sécurisées dans un environnement hors production), consultez Planifier Always Encrypted avec enclaves sécurisées dans SQL Server sans attestation.

Le rôle Service Guardian hôte (SGH) accordé dans Windows Server 2019 (et versions plus récentes) fournit des fonctionnalités d’attestation à distance pour Always Encrypted avec des enclaves de sécurité basée sur la virtualisation. Cet article vous guide tout au long des décisions de prédéploiement et des exigences pour utiliser Always Encrypted avec des enclaves VBS et l’attestation du Service Guardian hôte.

Note

Lorsque SQL Server est déployé dans une machine virtuelle, les enclaves VBS aident à protéger vos données contre les attaques à l’intérieur de la machine virtuelle. Toutefois, ils ne fournissent aucune protection contre les attaques à l’aide de comptes système privilégiés provenant de l’hôte. Par exemple, un vidage de mémoire de la machine virtuelle générée sur l’ordinateur hôte peut contenir la mémoire de l’enclave.

Présentation de l'architecture

Le Service Guardian hôte est un service web en cluster qui s’exécute sur Windows Server 2019 (et versions plus récentes). Dans un déploiement classique, il y aura 1 à 3 serveurs SGH, au moins un ordinateur exécutant SQL Server et un ordinateur exécutant une application cliente ou des outils, tels que SQL Server Management Studio. Comme SGH est chargé de déterminer quels ordinateurs exécutant SQL Server sont dignes de confiance, il exige une isolation à la fois physique et logique vis-à-vis de l’instance SQL Server qu’il protège. Si les mêmes administrateurs ont accès à SGH et à un ordinateur SQL Server, ils peuvent configurer le service d’attestation pour permettre à un ordinateur malveillant d’exécuter SQL Server, ce qui leur permet de compromettre l’enclave VBS.

Domaine SGH

Le programme d’installation du Service Guardian hôte va créer automatiquement un nouveau domaine Active Directory pour les serveurs Service Guardian hôte, les ressources du cluster de basculement et les comptes d’administrateur.

L’ordinateur exécutant SQL Server n’a pas besoin d’être dans un domaine, mais s’il s’agit d’un domaine différent de celui que le serveur SGH utilise.

Haute disponibilité

La fonctionnalité Service Guardian hôte installe et configure automatiquement un cluster de basculement. Dans un environnement de production, il est recommandé d’utiliser trois serveurs Service Guardian hôte pour la haute disponibilité. Pour plus d’informations sur la façon dont le quorum du cluster est déterminé et sur les configurations alternatives, notamment des clusters à deux nœuds avec un témoin externe, reportez-vous à la documentation du cluster de basculement.

Un stockage partagé n’est pas nécessaire entre les nœuds SGH. Une copie de la base de données d’attestation est stockée sur chaque serveur Service Guardian hôte et est automatiquement répliquée sur le réseau par le service de cluster.

Connectivité réseau

Le client SQL et SQL Server doivent être en mesure de communiquer avec HGS via HTTP. Configurez SGH avec un certificat TLS pour chiffrer toutes les communications entre le client SQL et SGH, ainsi qu’entre l’ordinateur SQL Server et SGH. Cette configuration vous protège contre les attaques de l’intercepteur et garantit que vous communiquez avec le bon serveur SGH.

Les serveurs SGH nécessitent une connectivité entre chaque nœud du cluster pour garantir que la base de données du service d’attestation reste synchronisée. Il est recommandé de connecter les nœuds SGH sur un réseau pour la communication de cluster et d’utiliser un réseau distinct pour que d’autres clients communiquent avec HGS.

Modes d’attestation

Lorsqu’un ordinateur exécutant SQL Server tente d’attester avec HGS, il demande d’abord à SGH comment il doit attester. HGS prend en charge deux modes d’attestation à utiliser avec SQL Server :

Mode d’attestation Explication
Module de plateforme sécurisée L’attestation de module TPM fournit l’assurance la plus forte quant à l’identité et à l’intégrité de l’ordinateur qui atteste avec le Service Guardian hôte. Les ordinateurs exécutant SQL Server doivent être installés avec TPM version 2.0. Chaque puce TPM contient une identité unique et immuable (une paire de clés de type EK - Endorsement Key) qui peut être utilisée pour identifier un ordinateur particulier. Les modules TPM mesurent également le processus de démarrage de l’ordinateur, en stockant les hachages des mesures sensibles pour la sécurité dans les registres de contrôle de plateforme qui peuvent être lus mais pas modifiés par le système d’exploitation. Ces mesures sont utilisées lors de l’attestation pour fournir une preuve de chiffrement qu’un ordinateur est bien dans la configuration de sécurité où il prétend être.
Clé hôte L’attestation de clé hôte est une forme d’attestation plus simple qui vérifie seulement l’identité d’un ordinateur en utilisant une paire de clés asymétriques. La clé privée est stockée sur l’ordinateur exécutant SQL Server et la clé publique est fournie à SGH. La configuration de sécurité de l’ordinateur n’est pas mesurée. Aucune puce TPM 2.0 n’est nécessaire sur l’ordinateur exécutant SQL Server. Il est important de protéger la clé privée installée sur l’ordinateur SQL Server, car toute personne disposant de cette clé peut emprunter l’identité d’un ordinateur SQL Server légitime et de l’enclave de sécurité basée sur la virtualisation s’exécutant dans SQL Server.

En général, nous faisons les recommandations suivantes :

  • Pour les serveurs de production physiques, nous vous recommandons d’utiliser l’attestation TPM pour obtenir les garanties supplémentaires qu’il fournit.
  • Dans le cas de serveurs de production virtuels, nous recommandons d’utiliser l’attestation de clé d’hôte dans la mesure où la plupart des machines virtuelles ne disposent ni de modules TPM virtuels ni du démarrage sécurisé. Si vous utilisez une machine virtuelle bénéficiant d’une sécurité renforcée comme une machine virtuelle locale dotée d’une protection maximale, vous pouvez opter pour le mode TPM. Dans tous les déploiements virtualisés, le processus d’attestation analyse uniquement votre environnement de machine virtuelle (et non la plateforme de virtualisation sous-jacente).
  • Dans les scénarios dev/test, nous recommandons d’utiliser l’attestation de clé d’hôte, car elle est plus facile à configurer.

Modèle d’approbation

Dans le modèle d’approbation d’enclave VBS, les requêtes et les données chiffrées sont évaluées dans une enclave logicielle pour la protéger du système d’exploitation hôte. L’accès à cette enclave est protégé par l’hyperviseur, de la même façon que deux machines virtuelles exécutées sur le même ordinateur ne peuvent pas accéder à la mémoire l’une de l’autre.

Pour qu’un client approuve qu’il parle à une instance légitime de VBS, vous devez utiliser l’attestation basée sur TPM qui établit une racine matérielle d’approbation sur l’ordinateur SQL Server.

Les mesures de module TPM capturées lors du processus de démarrage incluent la clé d’identité unique de l’instance de VBS, ce qui garantit que le certificat d’intégrité est valide seulement sur cet ordinateur. En outre, quand un module TPM est disponible sur un ordinateur exécutant VBS, la partie privée de la clé d’identité VBS est protégée par le module TPM, empêchant toute tentative d’emprunt d’identité de cette instance de VBS.

Le démarrage sécurisé est obligatoire avec l’attestation TPM pour vérifier que l’interface UEFI a chargé un chargeur de démarrage légitime signé par Microsoft et qu’aucun rootkit n’a intercepté le processus de démarrage de l’hyperviseur. De plus, un appareil IOMMU est nécessaire par défaut pour garantir qu’aucun appareil matériel disposant d’un accès direct à la mémoire ne peut inspecter ni modifier la mémoire de l’enclave.

Ces protections supposent que l’ordinateur exécutant SQL Server est un ordinateur physique. Si vous virtualisez l’ordinateur exécutant SQL Server, vous ne pouvez plus garantir que la mémoire de la machine virtuelle est protégée contre l’inspection par l’hyperviseur ou l’administrateur d’hyperviseur. Un administrateur d’hyperviseur peut, par exemple, vider la mémoire de la machine virtuelle et accéder à la version en texte clair de la requête et des données dans l’enclave. De façon similaire, même si la machine virtuelle dispose d’un module TPM virtuel, elle peut mesurer seulement l’état et l’intégrité du système d’exploitation et de l’environnement de démarrage de la machine virtuelle. Elle ne peut pas mesurer l’état de l’hyperviseur contrôlant la machine virtuelle.

Toutefois, même quand SQL Server est virtualisé, l’enclave est toujours protégée contre les attaques provenant du système d’exploitation de machine virtuelle. Si vous faites confiance à votre hyperviseur ou fournisseur de cloud et que vous vous inquiétez principalement des attaques d’administrateur de base de données et d’administration du système d’exploitation sur des données sensibles, un serveur SQL Server virtualisé peut répondre à vos besoins.

De même, l’attestation de clé d’hôte est toujours précieuse dans les situations où un module TPM 2.0 n’est pas installé sur l’ordinateur exécutant SQL Server ou dans des scénarios de développement/test où la sécurité n’est pas primordiale. Vous pouvez toujours utiliser la plupart des fonctionnalités de sécurité mentionnées, notamment le démarrage sécurisé et un module TPM 1.2, pour mieux protéger VBS et le système d’exploitation dans son ensemble. Cependant, étant donné qu’il n’existe aucun moyen pour le Service Guardian hôte de vérifier que ces paramètres sont activés sur l’ordinateur avec l’attestation de clé hôte, le client n’est pas sûr que l’hôte utilise toutes les protections disponibles.

Prerequisites

Prérequis pour le serveur SGH

Le ou les ordinateurs qui exécutent le rôle Service Guardian hôte doivent remplir les conditions suivantes :

Composant Condition requise
Système d’exploitation Windows Server 2019 (ou version plus récente) Standard ou Datacenter
UC 2 cœurs (minimum), 4 cœurs (recommandé)
Mémoire vive 8 Go (minimum)
Cartes réseau 2 cartes réseau avec adresses IP statiques recommandées (1 pour le trafic du cluster, 1 pour SGH)

Le Service Guardian hôte est un rôle très lié au processeur, en raison du nombre d’actions qui nécessitent un chiffrement et un déchiffrement. L’utilisation de processeurs modernes avec des fonctionnalités d’accélération du chiffrement améliore les performances du Service Guardian hôte. Les exigences de stockage pour les données d’attestation sont peu importantes : elles sont comprises dans une plage de 10 Ko à 1 Mo pour chaque ordinateur effectuant les attestations.

Ne joignez pas le ou les ordinateurs SGH à un domaine avant de commencer.

Prérequis de l’ordinateur SQL Server

Les ordinateurs exécutant SQL Server doivent répondre à la fois à la configuration requise pour installer SQL Server et la configuration matérielle requise pour Hyper-V.

Ces conditions requises incluent :

  • SQL Server 2019 (15.x) ou version ultérieure
  • Windows 10 1809 (ou version ultérieure) – Édition Entreprise, Windows 11 (ou version ultérieure) – Édition Entreprise, Windows Server 2019 (ou version ultérieure) – Édition Datacenter Les autres éditions de Windows 10/11 et de Windows Server ne prennent pas en charge l’attestation SGH.
  • Prise en charge du processeur pour les technologies de virtualisation :
    • Intel VT-x avec Extended Page Tables.
    • AMD-V avec Rapid Virtualization Indexing.
    • Si vous exécutez SQL Server dans une machine virtuelle :
  • Si vous envisagez d’utiliser l’attestation de module TPM, vous aurez besoin d’une puce TPM 2.0 révision 1.16 prêt à être utilisée sur le serveur. À ce stade, l’attestation de Service Guardian hôte ne fonctionne pas avec les puces TPM 2.0 révision 1.38. De plus, le module TPM doit avoir un certificat de paire de clés de type EK (Endorsement Key) valide.

Rôles et responsabilités lors de la configuration de l’attestation avec SGH

La configuration de l’attestation avec HGS implique la configuration de composants de différents types : SGH, ordinateurs SQL Server, instances SQL Server et applications qui déclenchent l’attestation d’enclave. La configuration des composants de chacun de ces types est effectuée par les utilisateurs qui disposent de l’un des rôles suivants :

  • Administrateur SGH : déploie HGS, inscrit des ordinateurs SQL Server auprès de SGH et partage l’URL d’attestation SGH avec les administrateurs d’ordinateurs SQL Server et les administrateurs d’applications clientes.
  • Administrateur d’ordinateur SQL Server : installe les composants clients d’attestation, active VBS sur les ordinateurs SQL Server, fournit à l’administrateur SGH les informations requises pour inscrire les ordinateurs SQL Server auprès de SGH, configure l’URL d’attestation sur les ordinateurs SQL Server et vérifie que les ordinateurs SQL Server peuvent attester avec HGS.
  • DBA : configure des enclaves sécurisées dans des instances SQL Server.
  • Administrateur d’application : configure l’application avec l’URL d’attestation obtenue auprès de l’administrateur SGH.

Dans les environnements de production (qui gèrent des données sensibles réelles), il est important que, lors de la configuration de l’attestation, votre organisation adhère à la séparation des rôles, selon laquelle chaque rôle est assumé par une personne différente. En effet, si l’objectif de déploiement d’Always Encrypted au sein de votre organisation est de réduire la surface d’attaque en veillant à ce que les administrateurs d’ordinateurs SQL Server et les administrateurs de bases de données ne puissent pas accéder à des données sensibles, les administrateurs en question ne doivent pas contrôler les serveurs SGH.

Considérations relatives à l’environnement de développement ou de test

Si vous utilisez Always Encrypted avec des enclaves VBS dans un environnement de développement ou de test et que vous n’avez pas besoin d’une haute disponibilité ou d’une protection forte de l’ordinateur exécutant SQL Server, vous pouvez effectuer l’une ou l’ensemble des concessions suivantes pour un déploiement simplifié :

  • Utilisez Always Encrypted avec enclaves sécurisées sans attestation : consultez Planifier Always Encrypted avec enclaves sécurisées dans SQL Server sans attestation.
  • Alternativement:
    • Déployez un seul nœud de Service Guardian hôte. Même si HGS installe un cluster de basculement, vous n’avez pas besoin d’ajouter d’autres nœuds si la haute disponibilité n’est pas un problème.
    • Utilisez le mode de clé hôte au lieu du mode TPM pour une expérience d’installation plus simple.
    • Virtualisez HGS et/ou SQL Server pour enregistrer des ressources physiques.
    • Exécutez SSMS ou d’autres outils pour configurer Always Encrypted avec enclaves sécurisées sur le même ordinateur que SQL Server. Cela laisse les clés principales de colonne sur le même ordinateur que SQL Server. Par conséquent, ne faites pas cela dans un environnement de production.

Étapes suivantes