Partage via

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 de sécurité utilise les enclaves basées sur la virtualisation (VBS) (également connues sous le nom d'enclaves Virtual Secure Mode ou VSM) – une technologie logicielle qui repose sur l'hyperviseur Windows et ne nécessite aucun matériel particulier. L’attestation d’une enclave VBS implique de vérifier que le code à l’intérieur de l’enclave est valide et si l’ordinateur hébergeant SQL Server est fiable. L’attestation réalise cet objectif en introduisant un tiers qui peut 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 concernant 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.

Remarque

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, elles n'offrent aucune protection contre les attaques utilisant des comptes système privilégiés provenant de l'hôte. Par exemple, une image 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 Service Guardian hôte, au moins un ordinateur exécutant SQL Server et un ordinateur exécutant une application cliente ou des outils, comme 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 au Service Guardian hôte et à un ordinateur SQL Server, ils pourraient configurer le service d’attestation pour permettre à un ordinateur malveillant d’exécuter SQL Server, ce qui leur permettrait 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 si c’est le cas, il doit s’agir d’un domaine différent de celui utilisé par le serveur SGH.

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 l’ordinateur SQL Server doivent pouvoir communiquer avec SGH sur 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 SGH.

Modes d’attestation

Quand un ordinateur exécutant SQL Server tente d’attester avec le Service Guardian hôte, il commence par demander au Service Guardian hôte comment il doit attester. SGH prend en charge deux modes d’attestation avec SQL Server :

Mode d’attestation Explication
Module de plateforme sécurisée (TPM) 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. Elle nécessite que TPM version 2.0 soit installé sur les ordinateurs exécutant SQL Server. 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 au Service Guardian hôte. 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 recommandons d’utiliser l’attestation TPM pour les garanties supplémentaires qu’elle 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 puisse faire confiance à une instance légitime de VBS, vous devez utiliser l’attestation de module TPM qui établit une racine matérielle de l’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 une machine 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 hyperviseur. Un administrateur 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.

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

De même, l’attestation de clé d’hôte reste valable 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 néanmoins 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 comme un tout. 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.

Prérequis

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é)
RAM 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 Configuration requise pour l’installation de SQL Server et à la Configuration matérielle requise pour Hyper-V.

Ces conditions requises incluent :

  • SQL Server 2019 (15.x) ou ultérieur
  • 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 SGH 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 SGH, inscrit les ordinateurs SQL Server auprès de SGH et partage l’URL d’attestation SGH avec les administrateurs de l’ordinateur SQL Server et les administrateurs de l’application cliente.
  • Administrateur de l’ordinateur SQL Server : installe les composants du client d’attestation, active VBS sur les ordinateurs SQL Server, fournit à l’administrateur SGH les informations nécessaires à l’inscription des ordinateurs SQL Server auprès de SGH, configure l’URL d’attestation sur les ordinateurs et vérifie que les ordinateurs SQL Server peuvent attester correctement avec SGH.
  • Administrateur de la base de données : configure les enclaves sécurisées dans les 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 aux environnements de développement/test

Si vous utilisez Always Encrypted avec 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 renforcée de l’ordinateur exécutant SQL Server, vous pouvez faire une ou plusieurs des concessions suivantes pour un déploiement simplifié :

  • Utilisez Always Encrypted avec enclaves sécurisées sans attestation : consultez Planifier pour Always Encrypted avec enclaves sécurisées dans SQL Server sans attestation.
  • Ou encore :
    • Déployez un seul nœud de Service Guardian hôte. Même si le Service Guardian hôte installe un cluster de basculement, vous n’avez pas besoin d’ajouter des nœuds supplémentaires 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 le Service Guardian hôte et/ou SQL Server pour économiser les 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 permet de conserver les clés principales de colonne sur le même ordinateur que SQL Server : ne le faites donc pas dans un environnement de production.

Étapes suivantes