Livre blanc sur la sécurité d’Azure Synapse Analytics : Protection des données

Notes

Cet article fait partie de la série d’articles du livre blanc sur la sécurité d’Azure Synapse Analytics. Pour une vue d’ensemble de la série, consultez le livre blanc sur la sécurité d’Azure Synapse Analytics.

Découverte et classification des données

Les organisations doivent protéger leurs données conformément aux recommandations émises à l’échelle régionale, locale et de l’entreprise pour atténuer les risques de violation de données. L’une des difficultés auxquelles les organisations sont confrontées est la suivante : Comment protéger les données si vous ne savez pas où elles se trouvent ? Autre difficulté : Quel est le niveau de protection nécessaire ?, car certains jeux de données nécessitent davantage de protection que d’autres.

Imaginez une organisation avec des centaines ou des milliers de fichiers stockés dans son lac de données ainsi que des centaines ou des milliers de tables dans ses bases de données. Elle pourrait tirer parti d’un processus qui analyse automatiquement chaque ligne et colonne du système de fichiers ou de la table, et qui classifie les colonnes en tant que données potentiellement sensibles. Ce processus est appelé découverte des données.

Une fois le processus de découverte des données effectué, il fournit des recommandations de classification en fonction d’un ensemble prédéfini de modèles, de mots clés et de règles. Quelqu’un peut ensuite passer en revue les recommandations et appliquer des étiquettes de classification de sensibilité aux colonnes appropriées. Ce processus est appelé classification.

Azure Synapse propose deux options pour la découverte et la classification des données :

  • Découverte des données et classification, qui est intégrée à Azure Synapse et au pool SQL dédié (anciennement SQL DW).
  • Microsoft Purview, qui est une solution unifiée de gouvernance des données permettant de gérer et de gouverner les données locales, multicloud et SaaS (software as a service). Elle peut automatiser la découverte des données, l’identification de la traçabilité et la classification des données. La production d’un mappage unifié des ressources de données et de leurs relations permet de rendre les données plus facilement détectables.

Notes

Le service de découverte et de classification des données Microsoft Purview est en préversion publique pour Azure Synapse, le pool SQL dédié (anciennement SQL DW) et le pool SQL serverless. Toutefois, la traçabilité des données n’est pas prise en charge pour le moment pour Azure Synapse, le pool SQL dédié (anciennement SQL DW) et le pool SQL serverless. Le pool Apache Spark prend uniquement en charge le suivi de la traçabilité.

Chiffrement des données

Les données sont chiffrées au repos et en transit.

Données au repos

Par défaut, le service Stockage Azure chiffre automatiquement toutes les données à l’aide du chiffrement Advanced Encryption Standard 256 bits (AES 256). Il s’agit de l’un des chiffrements par blocs les plus puissants disponibles. De plus, il est conforme à la norme FIPS 140-2. La plateforme gère la clé de chiffrement et forme la première couche de chiffrement des données. Ce chiffrement s’applique à la fois aux bases de données utilisateur et système, notamment la base de données MASTER.

L’activation du chiffrement TDE (Transparent Data Encryption) permet d’ajouter une deuxième couche de chiffrement des données pour les pools SQL dédiés. Il effectue le chiffrement et le déchiffrement des E/S en temps réel des fichiers de base de données, des fichiers journaux de transactions et des sauvegardes au repos sans nécessiter de changements dans l’application. Par défaut, il utilise le chiffrement AES 256.

Par défaut, TDE protège la clé de chiffrement de base de données (DEK) avec un certificat de serveur intégré (managé par le service). Il existe une option permettant d’utiliser le service BYOK (Bring Your Own Key) pour stocker votre clé de manière sécurisée dans Azure Key Vault.

Le pool SQL serverless et le pool Apache Spark dans Azure Synapse sont des moteurs analytiques qui fonctionnent directement sur Azure Data Lake Gen2 (ADLS Gen2) ou Stockage Blob Azure. Ces runtimes analytiques n’ont pas de stockage permanent et s’appuient sur les technologies de chiffrement du service Stockage Azure pour la protection des données. Par défaut, le service Stockage Azure chiffre toutes les données à l’aide du chiffrement côté serveur (SSE). Il est activé pour tous les types de stockage (notamment ADLS Gen2) et ne peut pas être désactivé. SSE chiffre et déchiffre les données de manière transparente à l’aide d’AES 256.

Il existe deux options de chiffrement SSE :

  • Clés gérées par Microsoft : Microsoft gère tous les aspects de la clé de chiffrement, notamment le stockage, la propriété et les rotations des clés. Il s’agit d’une opération totalement transparente pour les clients.
  • Clés gérées par le client : dans ce cas, la clé symétrique utilisée pour chiffrer les données dans le service Stockage Azure est chiffrée à l’aide d’une clé fournie par le client. Elle prend en charge les clés RSA et RSA-HSM (modules de sécurité matériels) de tailles 2 048, 3 072 et 4 096. Les clés peuvent être stockées de manière sécurisée dans Azure Key Vault ou le HSM managé d’Azure Key Vault. Elle fournit un contrôle d’accès précis de la clé et de sa gestion, notamment en ce qui concerne le stockage, la sauvegarde et les rotations. Pour plus d’informations, consultez Clés gérées par le client pour le chiffrement Stockage Azure.

Bien que SSE forme la première couche de chiffrement, les clients prudents peuvent doubler le chiffrement en activant une deuxième couche basée sur le chiffrement AES 256 bits au niveau de la couche d’infrastructure du service Stockage Azure. Appelée chiffrement d’infrastructure, cette couche de chiffrement utilise une clé gérée par la plateforme avec une clé distincte du chiffrement SSE. Ainsi, les données du compte de stockage sont chiffrées deux fois : une fois au niveau du service et une fois au niveau de l’infrastructure avec deux algorithmes de chiffrement différents et des clés distinctes.

Données en transit

Azure Synapse, le pool SQL dédié (anciennement SQL DW) et le pool SQL serverless utilisent le protocole TDS (Tabular Data Stream) pour communiquer entre le point de terminaison du pool SQL et une machine cliente. TDS dépend du protocole TLS (Transport Layer Security) pour le chiffrement du canal, ce qui permet de sécuriser et de chiffrer tous les paquets de données entre le point de terminaison et la machine cliente. Il utilise un certificat de serveur signé émanant de l’autorité de certification et utilisé pour le chiffrement TLS, managé par Microsoft. Azure Synapse prend en charge le chiffrement des données en transit avec TLS v1.2, à l’aide du chiffrement AES 256.

Azure Synapse tire parti du protocole TLS pour garantir le chiffrement des données en mouvement. Les pools dédiés SQL prennent en charge les versions TLS 1.0, TLS 1.1 et TLS 1.2 pour le chiffrement, dans lequel les pilotes fournis par Microsoft utilisent TLS 1.2 par défaut. Le pool SQL serverless et le pool Apache Spark utilisent TLS 1.2 pour toutes les connexions sortantes.

Étapes suivantes

Dans le prochain article de cette série de livres blancs, vous découvrirez le contrôle d’accès.