Protéger vos données
Maintenant que votre réseau et la gestion des identités et des accès sont configurés et sécurisés, intéressons-nous à la manière de protéger vos données, qu’elles soient au repos, en mouvement ou en cours de consultation par des utilisateurs et administrateurs.
Chiffrement des données
Azure SQL Database force les connexions chiffrées, en laissant la possibilité de spécifier également la version minimale requise du protocole TLS (Transport Layer Security) entrant (>1.0, >1.1 ou >1.2). Nous vous recommandons de forcer le chiffrement sur le client afin d’éviter la négociation du serveur et de ne pas faire confiance au certificat de serveur comme meilleure pratique.
Chiffrement transparent des données
La technologie TDE (Transparent Data Encryption) fournit le chiffrement pour les données au repos ; elle est activée par défaut pour toutes les nouvelles bases de données dans Azure SQL Database. Vous pouvez le configurer pour toutes les options de déploiement avec un commutateur dans le Portail Azure, comme illustré ici :
Au niveau du serveur, vous pouvez également choisir d’utiliser une clé gérée par le service ou le service Bring Your Own Key (BYOK) à l’aide de l’option Clé gérée par le client. Le paramétrage par défaut est de laisser le service Azure gérer votre clé. Azure génère automatiquement une clé pour chiffrer vos bases de données et gère les rotations des clés. Vous avez appris à l’effectuer avec le Portail Azure, mais vous pouvez également utiliser Azure PowerShell, Azure CLI, Transact-SQL (T-SQL) ou des API REST.
Clés gérées par le client avec TDE
Vous pouvez également utiliser BYOK et tirer parti d’un coffre de clés Azure. Les avantages de l’utilisation de clés gérées par le client sont les suivants :
- Contrôle complet et précis de l’utilisation et de la gestion du protecteur TDE
- Transparence de l’utilisation du protecteur TDE
- Possibilité d’implémenter la séparation des tâches dans la gestion des clés et des données au sein de l’organisation
- L’administrateur de coffre de clés peut révoquer les autorisations d’accès à la clé pour rendre la base de données chiffrée inaccessible
- Gestion centralisée des clés dans Azure Key Vault (AKV)
- Vous bénéficiez d’une confiance accrue de vos clients finaux, car Azure Key Vault (AKV) est conçu de telle sorte que Microsoft ne peut pas voir ni extraire les clés de chiffrement
Vous pouvez également tirer parti de l’utilisation d’une identité managée affectée par l’utilisateur (UMI) avec des clés gérées par le client pour TDE, ce qui :
- Permet de pré-autoriser l’accès au coffre de clés pour les serveurs logiques Azure SQL en créant une identité managée affectée par l’utilisateur et en lui octroyant l’accès au coffre de clés, avant même la création du serveur ou de la base de données.
- Permet de créer un serveur logique Azure SQL avec Transparent Data Encryption (TDE) et la clé gérée par le client (CMK) activés.
- Permet d’attribuer la même identité managée affectée par l’utilisateur à plusieurs serveurs, ce qui élimine le besoin d’activer individuellement l’identité managée affectée par le système pour chaque serveur logique Azure SQL et lui permet d’accéder au coffre de clés.
- Fournit la possibilité d’appliquer la CMK au moment de la création du serveur avec une stratégie Azure intégrée disponible.
La rotation automatique des clés a été introduite pour les clés gérées par le client à l’aide de TDE. Une fois appliquée, le serveur recherche continuellement dans le coffre de clés des versions de la clé utilisée en tant que protecteur TDE. En cas de détection d’une nouvelle version de la clé, le protecteur TDE sur le serveur fait l’objet d’une rotation automatique vers la dernière version de la clé dans les 60 minutes qui suivent.
Always Encrypted
Vous pouvez aussi tirer parti du chiffrement au niveau des colonnes, qui est pris en charge tant dans Azure SQL que dans SQL Server. Ce processus implique d’utiliser le chiffrement côté client de données sensibles qui utilise des clés qui ne sont jamais données au système de base de données. Par ailleurs, le pilote du client chiffre les paramètres de requête, et déchiffre les résultats chiffrés en toute transparence. Les données chiffrées sont actuellement prises en charge pour la comparaison d’égalité, notamment les opérateurs JOIN, GROUP BY et DISTINCT par un chiffrement déterministe.
Always Encrypted avec enclaves sécurisées étend les capacités de calcul confidentiel d’Always Encrypted en activant le chiffrement sur place et des requêtes confidentielles enrichies. La fonctionnalité Always Encrypted avec enclaves sécurisées est maintenant disponible pour Azure SQL Database, mais n’est pas encore prise en charge pour Azure SQL Managed Instance.
Masquage dynamique des données
Parfois, vous aurez besoin de masquer ou modifier certaines données afin que les utilisateurs non privilégiés ne puissent pas les voir, mais qu’ils puissent quand même exécuter des requêtes incluant ces données. Cette fonctionnalité est prise en charge de la même façon que dans SQL Server. Toutefois, il existe des fonctionnalités et des vues supplémentaires dans le portail Azure, qui vous permettent d’afficher des recommandations concernant les champs à masquer.
Prenons l’exemple où les données comprennent des informations sensibles, comme des noms et des adresses e-mail. Vous pouvez appliquer un masque à ces colonnes dans le portail Azure en sélectionnant le menu Dynamic Data Masking sous Sécurité dans le volet de configuration de votre base de données SQL, ou en utilisant les commandes T-SQL suivantes :
ALTER TABLE Data.Membership ALTER COLUMN FirstName
ADD MASKED WITH (FUNCTION = 'partial(1, "xxxxx", 1)')
ALTER TABLE Data.Membership ALTER COLUMN Email
ADD MASKED WITH (FUNCTION = 'email()')
ALTER TABLE Data.Membership ALTER COLUMN DiscountCode
ADD MASKED WITH (FUNCTION = 'random(1, 100)')
GRANT UNMASK to DataOfficers
À partir des commandes précédentes, vous pouvez voir qu’il existe plusieurs façons d’appliquer un masque par le biais de fonctions.
Par exemple, certains utilisateurs, s’ils sont affectés à un rôle comme DataOfficers (il s’agit d’un exemple, pas d’un rôle officiel), peuvent avoir besoin d’afficher les données masquées. Vous pouvez leur accorder des privilèges UNMASK à l’aide de la commande T-SQL suivante :
GRANT UNMASK TO DataOfficers
En fonction de la personne qui interroge, les résultats sont les suivants :
Avec l’introduction d’autorisations de masquage des données dynamiques granulaires, vous pouvez accorder ou révoquer l’autorisation UNMASK au niveau de la base de données, du schéma, de la table ou de la colonne pour un utilisateur de la base de données, une identité Microsoft Entra, un groupe Microsoft Entra ou un rôle de base de données.
Tâches pour la protection des données
Pour mettre en place et configurer la protection des données, voici ce que vous devez faire :
- Vérifiez que vos applications forcent le chiffrement de connexion, et utilisez la version TLS la plus élevée compatible avec votre application, vos clients et vos pilotes.
- Évaluez et activez TDE. Il s’agit du paramètre par défaut pour les nouvelles bases de données, mais si vous migrez, vous devrez peut-être l’activer.
- Tirez parti de Dynamic Data Masking.
- Pour une protection avancée, vous pouvez configurer la fonctionnalité Always Encrypted avec enclaves sécurisées.