Masquage dynamique des données

Présentation

Grâce au masquage des données (DDM) dans Amazon Redshift, vous pouvez protéger les données sensibles dans votre entrepôt des données. Vous pouvez modifier la façon dont Amazon Redshift montre les données sensibles à l’utilisateur au moment de la requête, sans les transformer dans la base de données. Vous contrôlez l’accès aux données par le biais de politiques de masquage qui appliquent des règles de masquage personnalisées à un utilisateur ou à un rôle donné. Vous pouvez ainsi répondre à l’évolution des exigences de confidentialité sans modifier les données sous-jacentes ni modifier les requêtes SQL.

Les politiques de masquage dynamique des données cachent, masquent ou pseudonymisent les données qui correspondent à un format donné. Lorsqu’elle est attachée à une table, l’expression de masquage est appliquée à une ou plusieurs de ses colonnes. Vous pouvez modifier davantage les politiques de masquage pour ne les appliquer qu’à certains utilisateurs ou à des rôles définis par l’utilisateur que vous pouvez créer avec Contrôle d’accès basé sur les rôles (RBAC). En outre, vous pouvez appliquer le DDM au niveau de la cellule en utilisant des colonnes conditionnelles lors de la création de votre politique de masquage. Pour plus d’informations sur le masquage conditionnel, consultez Masquage conditionnel des données dynamiques.

Vous pouvez appliquer plusieurs politiques de masquage avec différents niveaux de masquage à la même colonne d’une table et les attribuer à différents rôles. Pour éviter les conflits lorsque vous avez des rôles différents et que des politiques différentes s’appliquent à une colonne, vous pouvez définir des priorités pour chaque application. Vous pouvez ainsi contrôler les données auxquelles un utilisateur ou un rôle donné peut accéder. Les politiques DDM peuvent supprimer partiellement ou complètement des données, ou les hacher à l’aide de fonctions définies par l’utilisateur écrites en SQL, Python ou avec AWS Lambda. En masquant les données à l’aide de hachages, vous pouvez appliquer des jointures à ces données sans accéder à des informations potentiellement sensibles.

nd-to-end Exemple E

L' end-to-end exemple suivant montre comment créer et associer des politiques de masquage à une colonne. Ces règles permettent aux utilisateurs d’accéder à une colonne et de voir différentes valeurs, en fonction du degré de masquage des politiques associées à leurs rôles. Vous devez être un super-utilisateur ou avoir le rôle sys:secadmin requis pour exécuter cet exemple.

Création d’une politique de masquage

D’abord, créez une table et remplissez-la avec les valeurs des cartes de crédit.

--create the table         
CREATE TABLE credit_cards (
  customer_id INT,
  credit_card TEXT
);

--populate the table with sample values
INSERT INTO credit_cards
VALUES
  (100, '4532993817514842'),
  (100, '4716002041425888'),
  (102, '5243112427642649'),
  (102, '6011720771834675'),
  (102, '6011378662059710'),
  (103, '373611968625635')
;

--run GRANT to grant permission to use the SELECT statement on the table
GRANT SELECT ON credit_cards TO PUBLIC;

--create two users
CREATE USER regular_user WITH PASSWORD '1234Test!';

CREATE USER analytics_user WITH PASSWORD '1234Test!';

--create the analytics_role role and grant it to analytics_user
--regular_user does not have a role
CREATE ROLE analytics_role;

GRANT ROLE analytics_role TO analytics_user;

Créez ensuite une politique de masquage à appliquer au rôle d’analyse.

--create a masking policy that fully masks the credit card number
CREATE MASKING POLICY mask_credit_card_full
WITH (credit_card VARCHAR(256))
USING ('000000XXXX0000'::TEXT);

--create a user-defined function that partially obfuscates credit card data
CREATE FUNCTION REDACT_CREDIT_CARD (credit_card TEXT)
RETURNS TEXT IMMUTABLE
AS $$
    import re
    regexp = re.compile("^([0-9]{6})[0-9]{5,6}([0-9]{4})")
 
    match = regexp.search(credit_card)
    if match != None:
        first = match.group(1)
        last = match.group(2)
    else:
        first = "000000"
        last = "0000"
    
    return "{}XXXXX{}".format(first, last)
$$ LANGUAGE plpythonu;

--create a masking policy that applies the REDACT_CREDIT_CARD function
CREATE MASKING POLICY mask_credit_card_partial
WITH (credit_card VARCHAR(256))
USING (REDACT_CREDIT_CARD(credit_card));

--confirm the masking policies using the associated system views
SELECT * FROM svv_masking_policy;

SELECT * FROM svv_attached_masking_policy;   

Attachement d’une politique de masquage

Attachez les politiques de masquage à la table des cartes de crédit.

--attach mask_credit_card_full to the credit card table as the default policy
--all users will see this masking policy unless a higher priority masking policy is attached to them or their role
ATTACH MASKING POLICY mask_credit_card_full
ON credit_cards(credit_card)
TO PUBLIC;

--attach mask_credit_card_partial to the analytics role
--users with the analytics role can see partial credit card information
ATTACH MASKING POLICY mask_credit_card_partial
ON credit_cards(credit_card)
TO ROLE analytics_role
PRIORITY 10;

--confirm the masking policies are applied to the table and role in the associated system view
SELECT * FROM svv_attached_masking_policy;

--confirm the full masking policy is in place for normal users by selecting from the credit card table as regular_user
SET SESSION AUTHORIZATION regular_user;

SELECT * FROM credit_cards;

--confirm the partial masking policy is in place for users with the analytics role by selecting from the credit card table as analytics_user
SET SESSION AUTHORIZATION analytics_user;

SELECT * FROM credit_cards;

Modification d’une politique de masquage

La section suivante montre comment modifier une politique de masquage dynamique des données.

--reset session authorization to the default
RESET SESSION AUTHORIZATION;

--alter the mask_credit_card_full policy
ALTER MASKING POLICY mask_credit_card_full
USING ('00000000000000'::TEXT);	
	
--confirm the full masking policy is in place after altering the policy, and that results are altered from '000000XXXX0000' to '00000000000000'
SELECT * FROM credit_cards;

Détachement et suppression d’une politique de masquage

La section suivante explique comment détacher et supprimer les politiques de masquage en supprimant toutes les politiques de masquage dynamique des données de la table.

--reset session authorization to the default
RESET SESSION AUTHORIZATION;

--detach both masking policies from the credit_cards table
DETACH MASKING POLICY mask_credit_card_full 
ON credit_cards(credit_card) 
FROM PUBLIC;

DETACH MASKING POLICY mask_credit_card_partial 
ON credit_cards(credit_card) 
FROM ROLE analytics_role;

--drop both masking policies
DROP MASKING POLICY mask_credit_card_full;

DROP MASKING POLICY mask_credit_card_partial; 

Considérations relatives à l’utilisation du masquage dynamique des données

Considérez ce qui suit quand vous utilisez le masquage dynamique des données :

• Lorsqu’ils interrogent des objets créés à partir de tables, tels que des vues, les utilisateurs voient les résultats en fonction de leurs propres politiques de masquage, et non celles de l’utilisateur qui a créé les objets. Par exemple, un utilisateur ayant le rôle d’analyste interrogeant une vue créée par un secadmin obtiendrait des résultats avec des politiques de masquage associées au rôle d’analyste.

• Pour éviter que la commande EXPLAIN n’expose potentiellement des filtres de politique de masquage sensibles, seuls les utilisateurs disposant de l’autorisation SYS_EXPLAIN_DDM peuvent voir les politiques de masquage appliquées dans les sorties EXPLAIN. Les utilisateurs ne disposent pas de l’autorisation SYS_EXPLAIN_DDM par défaut.

  La syntaxe suivante permet de donner une autorisation à un utilisateur ou à un rôle.

  GRANT EXPLAIN MASKING TO { username | ROLE rolename }

  Pour plus d’informations sur la commande EXPLAIN, consultez EXPLAIN.

• Les utilisateurs ayant des rôles différents peuvent voir des résultats différents en fonction des conditions de filtre ou des conditions de jointure utilisées. Par exemple, l’exécution d’une commande SELECT sur une table à l’aide d’une valeur de colonne spécifique échouera si l’utilisateur exécutant la commande applique une politique de masquage qui masque cette colonne.

• Les politiques DDM doivent être appliquées avant toute opération de prédicat ou toute projection. Les politiques de masquage peuvent inclure les éléments suivants :

  • Opérations constantes à faible coût, telles que la conversion d’une valeur en valeur nulle

  • Opérations à coût modéré telles que le hachage HMAC

  • Opérations coûteuses telles que les appels à des fonctions Lambda externes définies par l’utilisateur

  À ce titre, nous vous recommandons d’utiliser des expressions de masquage simples lorsque cela est possible.

• Vous pouvez utiliser des politiques DDM pour des rôles dotés de politiques de sécurité au niveau des lignes, mais notez que les politiques RLS sont appliquées avant le DDM. Une expression de masquage dynamique des données ne pourra pas lire une ligne protégée par RLS. Pour plus d’informations sur RLS, consultez Sécurité au niveau des lignes.

• Lorsque vous utilisez la commande COPY pour copier des tables parquet vers des tables cible protégées, vous devez spécifier explicitement les colonnes dans l’instruction COPY. Pour plus d’informations sur le mappage de colonnes avec COPY, consultez Options de mappage de colonnes.

• Il n’est pas possible d’attacher les politiques de DDM aux relations suivantes :

  • Tables et catalogues du système

  • Tables externes

  • Tables d’unités de partage des données

  • Vues matérialisées

  • Relations entre bases de données

  • Tables temporaires

  • Requêtes corrélées

• Les politiques de DDM peuvent contenir des tables de recherche. Des tables de recherche peuvent être présentes dans la clause USING. Les types de relations suivants ne peuvent pas être utilisés comme tables de recherche :

  • Tables et catalogues du système

  • Tables externes

  • Tables d’unités de partage des données

  • Vues, vues matérialisées et vues à liaison tardive

  • Relations entre bases de données

  • Tables temporaires

  • Requêtes corrélées

  Vous trouverez ci-dessous un exemple d’association d’une politique de masquage à une table de recherche.

  --Create a masking policy referencing a lookup table
  CREATE MASKING POLICY lookup_mask_credit_card WITH (credit_card TEXT) USING (
    CASE
      WHEN
        credit_card IN (SELECT credit_card_lookup FROM credit_cards_lookup)      
      THEN '000000XXXX0000'
      ELSE REDACT_CREDIT_CARD(credit_card)
      END
    ); 
    
  --Provides access to the lookup table via a policy attached to a role
  GRANT SELECT ON TABLE credit_cards_lookup TO MASKING POLICY lookup_mask_credit_card;

• Vous ne pouvez pas attacher de politique de masquage qui produirait une sortie incompatible avec le type et la taille de la colonne cible. Par exemple, vous ne pouvez pas attacher une politique de masquage qui génère une chaîne de 12 caractères dans une colonne VARCHAR(10). Amazon Redshift prend en charge les exceptions suivantes :

  • Une politique de masquage avec le type d’entrée INTN peut être attachée à une politique de taille INTM tant que M < N. Par exemple, une politique de saisie BIGINT (INT8) peut être attachée à une colonne smallint (INT4).

  • Une politique de masquage avec le type d’entrée NUMERIC ou DECIMAL peut toujours être attachée à une colonne FLOAT.

• Les politiques DDM ne peuvent pas être utilisées avec le partage de données. Si le producteur de données de l’unité de partage des données associe une politique DDM à une table de l’unité de partage des données, la table devient inaccessible aux utilisateurs du consommateur de données qui tentent d’interroger la table. Les tables auxquelles sont associées des politiques DDM ne peuvent pas être ajoutées à une unité de partage des données.

• Vous ne pouvez pas interroger les relations auxquelles des politiques DDM sont attachées si la valeur de l’une de vos options de configuration suivantes ne correspond pas à la valeur par défaut de la session :

  • enable_case_sensitive_super_attribute

  • enable_case_sensitive_identifier

  • downcase_delimited_identifier

  Envisagez de réinitialiser les options de configuration de votre session si vous tentez d’interroger une relation à laquelle une politique DDM est attachée et que vous voyez le message « La relation protégée DDM ne prend pas en charge la configuration au niveau de la session si la sensibilité à la casse est différente de sa valeur par défaut ».

• Lorsque votre cluster ou votre espace de noms sans serveur mis en service est soumis à des politiques de masquage dynamique des données, les commandes suivantes sont bloquées pour les utilisateurs standard :

  ALTER <current_user> SET enable_case_sensitive_super_attribute/enable_case_sensitive_identifier/downcase_delimited_identifier

  Lorsque vous créez des politiques DDM, nous vous recommandons de modifier les paramètres des options de configuration par défaut pour les utilisateurs standard afin qu’ils correspondent aux paramètres des options de configuration de la session au moment où la politique a été créée. Les super-utilisateurs et les utilisateurs dotés du privilège ALTER USER peuvent faire cela en utilisant les paramètres de groupe de paramètres ou la commande ALTER USER. Pour en savoir plus sur les groupes de paramètres, consultez Groupes de paramètres Amazon Redshift dans le Guide de gestion Amazon Redshift. Pour en savoir plus sur la commande ALTER USER, consultez ALTER USER.

• Les vues et les vues à liaison tardive (LBV) associées à des politiques de DDM ne peuvent pas être remplacées par des utilisateurs ordinaires utilisant la commande CREATE VIEW. Pour remplacer les vues ou les LBV par des politiques de DDM, commencez par détacher toutes les politiques de DDM qui leur sont associées, remplacez les vues ou les LBV, puis attachez les politiques à nouveau. Les super-utilisateurs et les utilisateurs disposant de l’autorisation sys:secadmin peuvent utiliser CREATE VIEW sur les vues ou les LBV ayant des politiques de DDM sans détacher les politiques.

• Les vues attachées à des politiques de DDM ne peuvent pas référencer les tables et les vues système. Les vues à liaison tardive peuvent faire référence à des tables et à des vues système.

• Les vues à liaison tardive attachées à des politiques de DDM ne peuvent pas faire référence à des données imbriquées dans des lacs de données, comme des documents JSON.

• Une vue à liaison tardive ne peut pas être attachée à des politiques de DDM si elle est référencée par n’importe quelle vue.

• Les politiques de DDM attachées aux vues à liaison tardive sont jointes par nom de colonne. Au moment de la requête, Amazon Redshift valide que toutes les politiques de masquage attachées à la vue à liaison tardive ont été appliquées correctement, et que le type de colonne de sortie de la vue à liaison tardive correspond aux types des politiques de masquage attachées. Si la validation échoue, Amazon Redshift renvoie une erreur pour la requête.