Planifier des enclaves sécurisées dans Azure SQL Database

S’applique à Azure SQL Database

Dans Azure SQL Database, Always Encrypted avec enclaves sécurisées peut utiliser des enclaves Intel SGX (Intel Software Guard Extensions) ou des enclaves VBS (Sécurité basée sur la virtualisation).

Enclaves Intel SGX

Intel SGX est une technologie d’environnement d’exécution de confiance basée sur le matériel. Elle est disponible dans les bases de données et les pools élastiques qui utilisent le modèle d’achat vCore et la configuration matérielle de la série DC. Pour rendre une enclave Intel SGX disponible pour votre base de données ou pool élastique, vous devez sélectionner la configuration matérielle de la série DC lors de la création de la base de données ou du pool élastique. Une autre alternative est de mettre à jour votre base de données existante pour qu’elle utilise le matériel de la série DC.

Remarque

Intel SGX n’est pas disponible dans le matériel autre que la série DC. Par exemple, Intel SGX n’est pas disponible pour le matériel de la série Standard (Gen5) et n’est pas disponible pour les bases de données utilisant le modèle DTU.

Les enclaves Intel SGX combinées à l’attestation fournie par Microsoft Azure Attestation offrent une protection plus forte contre les attaques des acteurs disposant de l’accès administrateur au niveau du système d’exploitation, en comparaison des enclaves VBS. Cependant, avant de configurer le matériel de la série DC pour votre base de données, veillez à bien connaître les propriétés et les limitations de ses performances :

  • Contrairement à d’autres configurations matérielles du modèle d’achat vCore, la série DC utilise des cœurs de processeur physiques et non pas des cœurs logiques. Les limites de ressources des bases de données de la série DC diffèrent des limites de ressources de la configuration matérielle de la série Standard (Gen 5).
  • Le nombre maximal de cœurs de processeur que vous pouvez définir pour une base de données de la série DC est de 40.
  • La série DC ne fonctionne pas en mode serverless.

Vérifiez aussi la disponibilité régionale actuelle de la série DC et qu’elle est bien disponible dans vos régions préférées. Pour plus d’informations, consultez Série DC.

Les enclaves SGX sont recommandées pour les charges de travail qui nécessitent la protection la plus forte en matière de confidentialité des données et qui peuvent se satisfaire des limitations actuelles de la série DC.

Enclaves VBS

Les enclaves VBS (également appelées enclaves VSM, pour Virtual Secure Mode) sont une technologie logicielle qui s’appuie sur l’hyperviseur Windows et qui ne nécessite pas de matériel spécial. Par conséquent, les enclaves VBS sont disponibles dans toutes les offres Microsoft Azure SQL Database, notamment Azure SQL Elastic Pools, ce qui vous offre la possibilité d’utiliser Always Encrypted avec des enclaves sécurisées ayant une taille de calcul, un niveau de service, un modèle d’achat, une configuration matérielle et une région qui répondent le mieux aux besoins de votre charge de travail.

Notes

Les enclaves VBS sont disponibles dans toutes les régions de Microsoft Azure SQL Database sauf: Jio Inde Centre.

Les enclaves VBS sont la solution recommandée pour les clients qui recherchent une protection des données vis-à-vis des utilisateurs à privilèges élevés dans l’organisation du client, y compris les administrateurs de base de données (DBA). Sans avoir les clés de chiffrement protégeant les données, un administrateur de base de données ne peut pas accéder aux données en texte clair.

Les enclaves VBS peuvent également aider à empêcher certaines menaces au niveau du système d’exploitation, comme l’exfiltration de données sensibles à partir de vidages de mémoire au sein d’une machine virtuelle hébergeant votre base de données. Les données en texte clair traitées dans une enclave n’apparaissent pas dans les vidages de mémoire, à condition que le code à l’intérieur de l’enclave et ses propriétés n’aient pas été modifiés de façon malveillante. Cependant, les enclaves VBS dans Azure SQL Database ne peuvent pas répondre à des attaques plus sophistiquées, comme le remplacement des fichiers binaires de l’enclave par du code malveillant, en raison de l’absence actuelle d’attestation de l’enclave. De plus, indépendamment de l’attestation, les enclaves VBS n’offrent aucune protection contre les attaques utilisant des comptes système privilégiés provenant de l’hôte. Il est important de noter que Microsoft a implémenté plusieurs couches de contrôles de sécurité pour détecter et empêcher de telles attaques dans le cloud Azure, y compris l'accès juste-à-temps, l'authentification multifacteur et la surveillance de la sécurité. Néanmoins, les clients qui ont besoin d'une forte isolation de sécurité peuvent préférer les enclaves Intel SGX avec la configuration matérielle de la série DC aux enclaves de sécurité basée sur la virtualisation.

Planifier l’attestation d’enclave dans Azure SQL Database

La configuration de l’attestation en utilisant Microsoft Azure Attestation est nécessaire lors de l’utilisation d’enclaves Intel SGX dans des bases de données de la série DC.

Important

L’attestation n’est actuellement pas prise en charge pour les enclaves VBS. Le reste de cette section s’applique seulement aux enclaves Intel SGX dans les bases de données de la série DC.

Pour utiliser Microsoft Azure Attestation pour l’attestation d’enclaves Intel SGX dans Azure SQL Database, vous devez créer un fournisseur d’attestation et le configurer avec la stratégie d’attestation fournie par Microsoft. Consultez Configurer l’attestation pour Always Encrypted à l’aide d’Azure Attestation.

Rôles et responsabilités lors de la configuration d’enclaves Intel SGX et de l’attestation

La configuration de votre environnement pour prendre en charge les enclaves Intel SGX et l’attestation pour Always Encrypted dans Azure SQL Database implique la configuration de différents composants : un fournisseur d’attestation, une base de données et des 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 d’attestation : crée un fournisseur d’attestation dans Microsoft Azure Attestation, crée la stratégie d’attestation, accorde l’accès au serveur logique Azure SQL au fournisseur d’attestation et partage l’URL d’attestation qui pointe vers la stratégie pour les administrateurs d’application.
  • Administrateur de base de données (DBA) : active les enclaves SGX dans les bases de données en sélectionnant le matériel de la série DC et fournit à l’administrateur d’attestation l’identité du serveur logique Azure SQL qui doit accéder au fournisseur d’attestation.
  • Administrateur d’application : configure les applications avec l’URL d’attestation obtenue auprès de l’administrateur d’attestation.

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 particulier, si l’objectif du déploiement d’Always Encrypted au sein de votre organisation est de réduire la surface d’attaque en veillant à ce que les administrateurs de base de données ne puissent pas accéder à des données sensibles, les administrateurs de base de données ne devraient pas contrôler les stratégies d’attestation.

Étapes suivantes

Voir aussi