Stratégies de confidentialité des données

MySQL | PostgreSQL | SQL Server

La confidentialité des données protège les données telles que les informations personnelles des personnes qui ne devraient pas y avoir accès. Cette page décrit plusieurs approches de la confidentialité des données que vous pouvez utiliser pour protéger vos informations personnelles dans Cloud SQL.

Vous pouvez utiliser Cloud SQL pour stocker vos informations personnelles de manière sécurisée. Vous voulez vous assurer que ces informations sont traitées avec la protection de la confidentialité la plus élevée afin qu'elles ne soient pas accessibles par inadvertance. Par exemple, si vous stockez des informations de carte de crédit ou des données de santé dans vos bases de données, vous pouvez utiliser Cloud SQL pour masquer les informations personnelles d'utilisateurs non privilégiés.

Utilisez les stratégies suivantes pour sécuriser vos informations personnelles dans Cloud SQL :

• Sécurité au niveau des colonnes
• Approche basée sur les vues
• Sécurité au niveau des lignes
• Masquer et anonymiser des données
• Chiffrer des données

Sécurité au niveau des colonnes

La sécurité au niveau des colonnes vous permet de limiter les utilisateurs autorisés à voir le contenu dans des colonnes spécifiques de tables de base de données. Les droits au niveau des colonnes s'appliquent aux instructions INSERT, UPDATE, SELECT et REFERENCES.

Prenons l'exemple d'un site Web de vente au détail sur lequel vous souhaitez gérer les informations personnelles de deux utilisateurs, Jackson et Alice.

--User: "admin"

CREATE SCHEMA secure_schema;

CREATE TABLE secure_schema.user_details(id bigint, name text, age smallint, email_id text, password text);

--For this example, passwords are stored in plain text for demonstration
--purposes only. In production, never store passwords in plain text.

INSERT INTO secure_schema.user_details VALUES(1,'jack',34,'[e-mail]','testpass');
INSERT INTO secure_schema.user_details VALUES(2,'alice',37,'[e-mail]','testpass');

GRANT USAGE ON SCHEMA secure_schema TO analyst_ro;

--Grant read permissions on specific columns only.

GRANT SELECT (id, name, age) ON secure_schema.user_details TO analyst_ro;

--User: "analyst_ro"

SELECT * FROM secure_schema.user_details;
ERROR:  permission denied for table user_details

SELECT name, age, password FROM secure_schema.user_details;
ERROR:  permission denied for table user_details

SELECT id, name,age FROM secure_schema.user_details;
 id | name  | age
----+-------+----
  1 | jack  |  34
  2 | alice |  37

Si vous incluez les colonnes restreintes dans l'instruction SELECT ou si vous saisissez SELECT *, un message d'erreur s'affiche. Cloud SQL sécurise les informations personnelles pour Jackson et Alice dans ces colonnes.

Vous pouvez également utiliser une seule instruction GRANT pour combiner différents droits.

GRANT SELECT (id,name,age), UPDATE (name) ON secure_schema.user_details TO analyst_ro;

Approche basée sur les vues

Vous pouvez également assurer la sécurité au niveau des colonnes en créant une vue sur une table, en excluant ou en masquant les colonnes que vous souhaitez rendre invisible aux autres utilisateurs, et en fournissant l'accès à la vue plutôt qu'à la table.

L'exemple suivant montre comment utiliser une approche basée sur les vues pour le site Web de vente au détail afin de sécuriser les informations personnelles de Jackson et Alice :

--User: "admin"

CREATE SCHEMA analyst_ro;
CREATE VIEW analyst_ro.user_details AS SELECT id, name, age FROM secure_schema.user_details;
GRANT USAGE ON SCHEMA analyst_ro TO analyst_ro;
GRANT SELECT ON analyst_ro.user_details TO analyst_ro;

--User: "analyst_ro"

SELECT id,name,age FROM user_details;
 id | name  | age
----+-------+----
  1 | jack  |  34
  2 | alice |  37

SELECT * FROM user_details;
 id | name  | age
----+-------+----
  1 | jack  |  34
  2 | alice |  37

Dans cet exemple, un schéma distinct est créé pour que la vue garde le même nom que la table. Avec l'approche basée sur les vues, vous pouvez utiliser SELECT *.

Vous pouvez également créer une vue et masquer les colonnes de la table de base de données afin que les utilisateurs non privilégiés ne puissent pas voir les informations personnelles masquées.

CREATE VIEW analyst_ro.user_details AS SELECT id, name, age, '[e-mail]' as email_id,'*****'::text as password FROM secure_schema.user_details;

SELECT * FROM user_details;
 id | name  | age |     email_id         | password
----+-------+-----+----------------------+---------
  1 | jack  |  34 | [e-mail] | *****
  2 | alice |  37 | [e-mail] | *****

Sécurité au niveau des lignes

La sécurité au niveau des colonnes et l'approche basée sur les vues vous permettent de masquer des informations personnelles dans les colonnes de tables de base de données pour des utilisateurs spécifiques. Cependant, vous pouvez parfois avoir besoin de filtrer ces données et d'accorder l'accès à des lignes spécifiques d'une table. Ce tableau contient les informations personnelles auxquelles seuls certains utilisateurs ont accès, en fonction des conditions éligibles. C'est ce qu'on appelle la sécurité au niveau des lignes.

La sécurité au niveau des lignes est utile pour les applications mutualisées dans lesquelles les utilisateurs disposent de droits d'accès en lecture et en écriture uniquement à leurs propres informations personnelles. Dans Cloud SQL, les tables peuvent comporter des règles de sécurité au niveau des lignes qui limitent, par utilisateur, les lignes que les utilisateurs peuvent afficher en créant des requêtes, ou les lignes que les utilisateurs peuvent insérer, mettre à jour ou supprimer en exécutant des commandes de modification de données.

Pour l'exemple du site Web de vente au détail, vous pouvez mettre en œuvre la sécurité au niveau des lignes pour Jackson et Alice afin qu'ils puissent afficher leurs propres informations personnelles, mais ils ne peuvent pas les modifier ni les supprimer.

--User: "admin"
--Create and enable a policy for row-level security

CREATE POLICY user_details_rls_pol ON secure_schema.user_details FOR ALL TO PUBLIC USING (name=current_user);
ALTER TABLE secure_schema.user_details ENABLE ROW LEVEL SECURITY;

SELECT * FROM secure_schema.user_details;
 id | name  | age |     email_id      | password
----+-------+-----+-------------------+---------
  1 | jack  |  34 | [e-mail]  | testpass
  2 | alice |  37 | [e-mail] | testpass

--User: "jack"

SELECT * FROM secure_schema.user_details;
 id | name | age |    email_id      | password
----+------+-----+------------------+---------
  1 | jack |  34 | [e-mail] | testpass

--User: "alice"

SELECT * FROM secure_schema.user_details;
 id | name  | age |    email_id       | password
----+-------+-----+-------------------+---------
  2 | alice |  37 | [e-mail] | testpass

Les utilisateurs affectés à des rôles avec l'attribut BYPASSRLS peuvent contourner la sécurité au niveau des lignes lorsqu'ils accèdent à une table. Les propriétaires de table peuvent également contourner la sécurité au niveau des lignes. Si vous souhaitez soumettre un propriétaire de table à une sécurité au niveau des lignes, utilisez la commande ALTER TABLE ... FORCE ROW LEVEL SECURITY.

Il peut arriver que vous ne souhaitiez pas appliquer une sécurité au niveau des lignes aux lignes d'une table de base de données. Par exemple, si vous utilisez pg_dump pour effectuer une sauvegarde de la table, vous ne souhaitez pas que les lignes soient omises de la sauvegarde. Pour éviter cela, définissez le paramètre de configuration row_security sur OFF pour l'utilisateur qui effectue la sauvegarde. Si des lignes sont filtrées en fonction de la sécurité au niveau des lignes, un message d'erreur s'affiche.

Masquer et anonymiser des données

En plus de masquer des données à l'aide d'une approche basée sur les vues, vous pouvez également masquer des données à l'aide de l'extension postgresql_anonymizer. Cette extension masque ou remplace les informations personnelles ou les données commerciales sensibles dans une base de données PostgreSQL.

L'utilisation de l'extension par rapport à une approche basée sur les vues offre les avantages suivants :

• Vous disposez de différentes fonctions de masquage telles que la substitution, la randomisation, la simulation, la pseudonymisation, le brassage partiel, le brassage, l'ajout de bruit et la généralisation.

• Vous pouvez générer des données masquées significatives que vous pouvez ensuite utiliser pour les tests fonctionnels et le traitement des données.

• Vous pouvez utiliser le langage de définition de données (LDD) PostgreSQL pour déclarer des règles de masquage et spécifier la stratégie d'anonymisation dans la définition de table.

Installer et configurer l'extension postgresql_anonymizer

Pour utiliser cette extension sur une instance Cloud SQL, procédez comme suit :

1. Modifiez l'instance, puis définissez cloudsql.enable_anon flag sur on. Pour en savoir plus sur la définition des options et pour découvrir les options compatibles avec cette extension, consultez la page Configurer des options de base de données.

2. Créez l'extension dans la base de données en exécutant la commande suivante :

   --Connect to the PostgreSQL database
   
   CREATE EXTENSION IF NOT EXISTS anon CASCADE;
   SELECT anon.init();
   

Une fois que vous avez installé et configuré l'extension, utilisez-la sur l'instance pour mettre en œuvre des stratégies d'anonymisation par masquage dynamique, masquage statique pi vidage anonyme.

Masquage dynamique

Utilisez le masquage dynamique pour définir des règles de masquage pour des utilisateurs spécifiques. Ces utilisateurs ne peuvent pas voir les informations personnelles. À la place, ils voient des données masquées. Tous les autres utilisateurs voient les données non masquées. Cette méthode est utile dans les environnements de production lorsque vous ne souhaitez pas modifier les informations personnelles, mais que vous les masquez uniquement pour certains utilisateurs.

Pour l'exemple du site Web de vente au détail, vous pouvez mettre en œuvre le masquage dynamique afin que l'administrateur puisse afficher les adresses e-mail et les mots de passe non masqués pour Jackson et Alice, mais que l'analyste ne puisse afficher que les données masquées.

--Activate the dynamic masking engine

SELECT anon.start_dynamic_masking();

--Declare the masking user and masking rules
--analyst_ro is the masked user with select privileges on the
--user_details table

SECURITY LABEL FOR anon ON ROLE analyst_ro IS 'MASKED';

SECURITY LABEL FOR anon ON COLUMN secure_schema.user_details.email_id IS 'MASKED WITH FUNCTION anon.fake_email()';
SECURITY LABEL FOR anon ON COLUMN secure_schema.user_details.password  IS 'MASKED WITH FUNCTION anon.hash(password)';

--User: "admin" (can see all unmasked data)

SELECT * FROM secure_schema.user_details;
 id | name  | age |    email_id       | password
----+-------+-----+------------  -----+---------
  1 | jack  |  34 | [e-mail]  | testpass
  2 | alice |  37 | [e-mail] | testpass

--User:"analyst_ro" (note that the "email_id" and "password" columns are
--replaced with masked data,)
--Data in the password column is truncated for better formatting.

SELECT * FROM secure_schema.user_details;
 id | name  | age |       email_id         | password
----+-------+-----+-----------------  -----+----------------
  1 | jack  |  34 | [e-mail] | 13d249f2cb4127b
  2 | alice |  37 | [e-mail]   | 13d249f2cb4127b

Masquage statique

Utilisez le masquage statique pour supprimer les informations personnelles d'une table, en fonction des critères définis dans les règles de masquage, et remplacez ces informations par des données masquées. Les utilisateurs ne peuvent pas récupérer les données non masquées. Cette méthode est utile dans les environnements de test lorsque vous souhaitez modifier les informations personnelles et que vous ne souhaitez pas que les utilisateurs puissent consulter ces informations.

Remarque : Étant donné que le masquage statique remplace les données non masquées par des données masquées dans une table, en fonction de la taille de la table, ce processus peut prendre beaucoup de temps.

Pour l'exemple du site Web de vente au détail, vous pouvez mettre en œuvre un masquage statique afin qu'aucun utilisateur ne puisse consulter les adresses e-mail et les mots de passe non masqués pour Jack et Alice. À la place, ils ne voient que les données masquées.

--User: "admin"

SELECT * FROM secure_schema.user_details;
 id | name  | age |    email_id       | password
----+-------+-----+--------------  ---+---------
  1 | jack  |  34 | [e-mail]  | testpass
  2 | alice |  37 | [e-mail] | testpass

--Apply earlier defined masking rules to the table permanently.
--Now all users see masked data only.

SELECT anon.anonymize_table('secure_schema.user_details');
 anonymize_table
-----------------
 t

--User: "analyst_ro"
--Data in the password column is truncated for better formatting.

select * from secure_schema.user_details;
 id | name  | age |           email_id              |  password
----+-------+-----+-------------------------  ------+---------------
  1 | jack  |  34 | [e-mail] | 13d249f2cb412c
  2 | alice |  37 | [e-mail]         | 13d249f2cb4127

Vidage anonyme

Utilisez des vidages anonymes pour exporter les données masquées dans un fichier SQL. Pour l'exemple de site Web de vente au détail, vous pouvez créer un fichier de vidage pour les données masquées contenues dans la table user_details.

--Launch pg_dump_anon with the masked user to apply earlier defined --masking rules

pg_dump_anon -h HOSTIP -p 5432 -d DATABASE_NAME -U analyst_ro --table=secure_schema.user_details --file=user_details_anonysms.sql

Chiffrer des données

Bien que vous puissiez masquer les informations personnelles, celles-ci sont stockées dans la base de données sous forme de texte brut. Un administrateur peut afficher ces informations.

Utilisez l'extension pgcrypto pour chiffrer les informations personnelles avant de les stocker. Ainsi, seuls les utilisateurs disposant d'une clé de chiffrement valide peuvent déchiffrer les informations et les afficher en texte brut.

L'extension pgcrypto dispose d'un certain nombre de fonctions de hachage et de chiffrement.

Hachage

Un hachage est une fonction de chiffrement unidirectionnelle qui vous permet uniquement de chiffrer les informations personnelles. Cette méthode est utile pour stocker les mots de passe hachés et faire correspondre les mots de passe saisis par l'utilisateur avec les mots de passe hachés. Les mots de passe hachés ne sont jamais déchiffrés en texte brut.

Pour l'exemple de site Web de vente au détail, vous pouvez utiliser l'extension pgcrypto pour hacher le mot de passe de Jack avant de le stocker dans la table user_details.

--Hash passwords before storing them in the user_details table.

TRUNCATE TABLE secure_schema.user_details;
INSERT INTO secure_schema.user_details VALUES(1,'jack',34,'[e-mail]',crypt('testpassword', gen_salt('bf')));

--Match the hashed data with user entered password

SELECT id, name FROM secure_schema.user_details WHERE email_id = '[e-mail]' AND password = crypt('testpassword', password);
 id | name
----+-----
  1 | jack

Chiffrer

Utilisez une fonction de chiffrement pour chiffrer les informations personnelles à l'aide d'une clé. Les utilisateurs ont ensuite besoin de cette clé pour déchiffrer les informations en texte brut. Ces informations sont utiles pour stocker des informations de carte de crédit et des coordonnées bancaires lorsque les applications souhaitent récupérer les informations personnelles dans un format lisible.

Dans l'exemple du site Web de commerce de détail, le mot de passe et l'adresse e-mail de Jack sont chiffrés. Les utilisateurs disposant de la clé de chiffrement peuvent déchiffrer ces informations et les afficher en texte brut. Un message d'erreur s'affiche pour tous les autres utilisateurs.

--"user_acc_key" is the encryption key

TRUNCATE TABLE secure_schema.user_details;
INSERT INTO secure_schema.user_details VALUES(1,'jack',34,pgp_sym_encrypt('[e-mail]','user_acc_key'),pgp_sym_encrypt('testpassword','user_acc_key'));

--User: "admin" (queries without an encryption key)
--Data in the email_id and password columns are truncated for better
--formatting.

SELECT * FROM secure_schema.user_details;
 id | name  | age |    email_id     | password
----+-------+-----+-----------------+-------------------
  1 | jack |  34 | \xc30d0407030209 | \xc30d040703028962

--User: "app_user" (queries with a valid encryption key)

SELECT name,pgp_sym_decrypt(email_id::bytea,'user_acc_key'),pgp_sym_decrypt(password::bytea,'user_acc_key') FROM secure_schema.user_details;
 name | pgp_sym_decrypt   | pgp_sym_decrypt
------+-------------------+----------------
 jack | [e-mail]  | testpassword

--If a user uses the wrong encryption key, then the following error message appears:

SELECT name,pgp_sym_decrypt(email_id::bytea,'user_bad_key'),
pgp_sym_decrypt(password::bytea,'user_bad_key') FROM secure_schema.user_details;
ERROR:  Wrong key or corrupt data

Remarque : Avec l'extension pgcrypto, le traitement et le déchiffrement se déroulent au sein de la base de données. Toutefois, vous souhaiterez peut-être contrôler la logique de chiffrement et de déchiffrement au sein d'une application. Pour ce faire, utilisez le chiffrement côté client afin de chiffrer les informations personnelles avant de les écrire dans Cloud SQL. Vous pouvez chiffrer ces informations de sorte que seules les applications puissent les déchiffrer.

Étapes suivantes

Découvrez les contrôles supplémentaires suivants que vous pouvez utiliser pour protéger les informations personnelles contre les accès injustifiés :

• Authentification IAM

• Réseaux autorisés

• Certificats SSL/TLS

• Rôles et autorisations

• Maintenance en libre-service