Ce document décrit l'utilisation de la protection des données sensibles pour limiter le risque d'exposition des données sensibles stockées dans les bases de données Google Cloud aux utilisateurs, tout en leur permettant d'interroger des données significatives.
Des données sensibles peuvent exister dans votre entreprise. Les données collectées, traitées et partagées peuvent contenir des informations telles que des informations personnelles (personally identifiable information, PII) soumises à des règles ou réglementations internes et externes. En plus des contrôles de sécurité appropriés pour restreindre l'accès aux données sensibles, vous pouvez également utiliser ces techniques pour protéger les données en cours d'utilisation. L'anonymisation permet de trouver un équilibre entre l'utilité et la confidentialité des données en utilisant des techniques telles que le masquage des données, le binning et la tokenisation.
La tokenisation remplace les données sensibles par des valeurs de substitution appelées jetons, qui représentent la valeur sensible d'origine (brute) lorsque les données sont interrogées ou affichées. Ce processus est parfois appelé pseudonymisation ou remplacement de substitution. Le concept de tokenisation est largement utilisé dans des secteurs tels que la finance et la santé, pour réduire le risque d'utilisation des données, réduire la portée de la conformité et limiter l'exposition des données sensibles aux personnes ou aux systèmes qui n'en ont pas besoin.
Avec la protection des données sensibles, vous pouvez classer et anonymiser des données sensibles par lots et en temps réel. La classification consiste à identifier les informations sensibles et à déterminer leur type. Ce document explique comment utiliser ces techniques d'anonymisation et comment utiliser un proxy pour effectuer ces tâches.
Le schéma suivant illustre le scénario décrit dans ce document.
- Les données sont stockées au repos dans Cloud Storage. Par exemple, les données reçues d'un partenaire.
- Les données sont ingérées par le biais d'un processus d'extraction, de transformation et de chargement (ETL) dans une base de données SQL.
- Les données de cette base de données sont interrogées par les utilisateurs pour effectuer une analyse.
Dans ce scénario, les résultats renvoyés par la requête sont des données brutes. Les données sensibles sont donc affichées et exposent potentiellement des informations personnelles à l'utilisateur qui exécute la requête. Vous devez concevoir votre application de manière à auditer et empêcher les requêtes non autorisées portant sur des données sensibles.
Architecture du proxy DLP
Une façon de protéger les informations personnelles consiste à transmettre toutes les requêtes et les résultats via un service qui analyse, inspecte, puis consigne les résultats ou anonymise les résultats à l'aide de la protection des données sensibles avant de renvoyer les données demandées à l'utilisateur. Dans ce document, ce service est appelé proxy DLP.
L'application du proxy DLP accepte une requête SQL en entrée, l'exécute sur la base de données, puis applique la protection des données sensibles aux résultats, avant de les renvoyer à l'utilisateur demandant les données.
Le schéma suivant illustre l'architecture de l'application de proxy DLP.
La protection des données sensibles permet de configurer en détail les types de données à inspecter et de les transformer en fonction des résultats d'inspection ou de la structure des données (par exemple, les noms de champs). Pour simplifier la création et la gestion de la configuration, utilisez des modèles de protection des données sensibles. L'application du proxy DLP fait référence à la fois aux modèles d'inspection et d'anonymisation.
Vous pouvez utiliser des modèles pour créer et conserver des informations de configuration avec la protection des données sensibles. Les modèles sont utiles pour dissocier les informations de configuration : d'un côté les éléments que vous inspectez, et d'un autre côté la méthode utilisée dans la mise en œuvre des requêtes pour l'anonymisation de ces éléments. Pour en savoir plus sur les modèles, consultez les modèles de protection des données sensibles.
Cloud Audit Logging est un service de journalisation intégré de Google Cloud utilisé dans cette architecture. Pour commencer, Cloud Audit Logging fournit un journal d'audit des appels passés à l'API Cloud Data Loss Prevention (qui fait partie de la protection des données sensibles). Les entrées du journal d'audit incluent des informations sur l'auteur de l'appel d'API, le projet Google Cloud sur lequel il a été exécuté et des détails sur la requête, y compris si un modèle a été utilisé dans la requête. Ensuite, si vous utilisez le fichier de configuration de l'application pour activer l'audit, Cloud Audit Logging enregistre un résumé des résultats de l'inspection.
Cloud Key Management Service (Cloud KMS) est un service de gestion de clés hébergé dans le cloud de Google Cloud qui vous permet de gérer les clés cryptographiques de vos services cloud.
Les méthodes de protection des données sensibles pour la tokenisation et le changement de date utilisent la cryptographie pour générer les valeurs de remplacement. Ces méthodes de chiffrement utilisent une clé pour chiffrer les valeurs de manière cohérente afin de préserver l'intégrité du référentiel ou, pour les méthodes réversibles, de détokeniser. Vous pouvez fournir cette clé directement à la protection des données sensibles lorsque l'appel est effectué ou vous pouvez l'encapsuler à l'aide de Cloud KMS. L'encapsulation de votre clé dans Cloud KMS fournit une autre couche de contrôle d'accès et d'audit. C'est donc la méthode recommandée pour les déploiements de production.
Dans une configuration de production, vous devez utiliser le principe du moindre privilège pour attribuer des autorisations. Le schéma suivant illustre un exemple de ce principe.
Le schéma précédent montre comment, dans une configuration de production classique, trois personnes ont des rôles et un accès différents aux données brutes :
- Infrastructure admin (Administrateur d'infrastructure) : installe et configure le proxy afin qu'il ait accès à l'environnement de calcul sur lequel le proxy de protection des données sensibles est installé.
Data analyst (Analyste de données) : accède au client qui se connecte au proxy DLP.
Administrateur de sécurité: classe les données, crée les modèles de protection des données sensibles et configure Cloud KMS.
Pour en savoir plus sur l'utilisation de Cloud KMS pour chiffrer et déchiffrer des données, consultez la page Chiffrer et déchiffrer des données.
Pour le proxy DLP utilisé dans ce document, toutes ces informations sont configurées dans un modèle d'anonymisation de protection des données sensibles.
Protéger les informations personnelles avec l'audit, le masquage et la tokenisation
Dans ce scénario, vous pouvez mettre en œuvre deux stratégies pour limiter le risque d'exposition des informations personnelles.
Données brutes stockées dans la base de données
Si votre application stocke des données brutes dans une base de données, vous pouvez utiliser le proxy DLP pour traiter les résultats renvoyés à l'utilisateur en inspectant et en générant automatiquement un audit des résultats sensibles. Vous pouvez également masquer les résultats de la requête en temps réel, comme illustré dans le schéma suivant.
Cette configuration nécessite que vous utilisiez un client SQL qui se connecte au proxy DLP. Si vous activez l'audit sur votre application, un journal est créé dans Cloud Audit Logging avec un résumé des résultats de l'inspection. Ce récapitulatif indique le type d'informations sensibles renvoyées dans la requête.
Données stockées de manière anonyme
Si vous ne souhaitez pas stocker les données brutes, vous pouvez stocker les données de votre application de manière anonyme ou masquée en effectuant les transformations d'anonymisation pendant le processus ETL à destination de la base de données, comme illustré dans le schéma suivant.
Le schéma précédent illustre le flux de base, où les données sont inspectées et masquées avant d'être ingérées dans la base de données. Lorsqu'un utilisateur interroge ces données, même s'il dispose d'un accès brut à la base de données, il ne peut voir que la version masquée.
Si vous autorisez l'utilisateur à consulter des données non masquées, vous devez utiliser un client capable de se connecter à une instance du proxy DLP et autorisé à démasquer les données, comme illustré dans le schéma suivant.
Le schéma ci-dessus montre comment utiliser un client pour se connecter au proxy DLP afin de permettre au client d'afficher des données non masquées.
Étape suivante
- Consultez la page sur la Prendre le contrôle de vos données : comment la tokenisation rend les données utilisables sans remettre en cause la confidentialité.
Consultez la documentation technique sur la protection des données sensibles suivante:
Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.