Masquage dynamique des données - Amazon Redshift
Présentationnd-to-end Exemple EConsidérations relatives à l’utilisation du masquage dynamique des données

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Masquage dynamique des données

Présentation

Grâce au masquage dynamique des données (DDM) dans Amazon Redshift, vous pouvez protéger les données sensibles de votre entrepôt de 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é. Ainsi, vous pouvez répondre à l'évolution des exigences de confidentialité sans modifier les données sous-jacentes ni modifier SQL les requêtes.

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 l'appliquer 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. DDMles politiques peuvent partiellement ou complètement supprimer 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 EXPLAIN commande n'expose potentiellement les filtres de politique de masquage sensibles, seuls les utilisateurs disposant de l'DDMautorisation SYS _ EXPLAIN _ peuvent voir les politiques de masquage appliquées dans EXPLAIN les sorties. Les utilisateurs n'ont pas l'DDMautorisation SYS EXPLAIN _ _ par défaut.

    Voici la syntaxe permettant d'accorder l'autorisation à un rôle.

    GRANT EXPLAIN MASKING TO ROLE rolename

    Pour plus d'informations sur la EXPLAIN commande, consultezEXPLAIN.

  • 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 SELECT commande 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.

  • DDMles politiques doivent être appliquées avant toute opération de prédicat ou 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 HMAC hachage

    • 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 DDM politiques pour les rôles dotés de politiques de sécurité au niveau des lignes, mais notez que RLS les politiques sont appliquées auparavant. DDM Une expression de masquage de données dynamique ne pourra pas lire une ligne protégée parRLS. Pour plus d'informations surRLS, voirSécurité au niveau des lignes.

  • Lorsque vous utilisez la COPY commande pour copier du parquet vers des tables cibles protégées, vous devez spécifier explicitement les colonnes dans l'COPYinstruction. Pour plus d'informations sur le mappage de colonnes avecCOPY, consultezOptions de mappage de colonnes.

  • DDMles politiques ne peuvent pas être associées 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

  • DDMles politiques peuvent contenir des tables de recherche. Des tables de recherche peuvent être présentes dans la USING clause. 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 associer une politique de masquage qui génère une chaîne de 12 caractères à 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 dont la taille INTM est égale à M < N. Par exemple, une politique d'entrée 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 FLOAT colonne.

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

  • Vous ne pouvez pas interroger les relations associées à des DDM politiques si les valeurs de l'une des options de configuration suivantes ne correspondent 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 est attachée une DDM politique et que vous voyez le message « la relation DDM protégée ne prend pas en charge la configuration au niveau de la session si la distinction majuscules/minuscules 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 DDM politiques, nous vous recommandons de modifier les paramètres des options de configuration par défaut pour les utilisateurs ordinaires afin qu'ils correspondent aux paramètres des options de configuration de la session au moment de la création de la politique. Les superutilisateurs et les utilisateurs disposant du ALTER USER privilège peuvent le faire en utilisant les paramètres de groupe de paramètres ou la ALTER USER commande. 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 plus d'informations sur la ALTER USER commande, consultezALTER USER.

  • Les vues et les vues tardives associées à des DDM politiques ne peuvent pas être remplacées par les utilisateurs ordinaires à l'CREATE VIEWaide de cette commande. Pour remplacer les vues ou par LBVs des DDM politiques, détachez d'abord les DDM politiques qui leur sont associées, remplacez les vues ouLBVs, puis attachez à nouveau les politiques. Les superutilisateurs et les utilisateurs sys:secadmin autorisés peuvent utiliser CREATE VIEW des vues ou LBVs des DDM politiques sans détacher les politiques.

  • Les vues associées à des DDM politiques ne peuvent pas faire référence aux tables et aux vues du système. Les vues à liaison tardive peuvent faire référence à des tables et à des vues système.

  • Les vues contraignantes tardives associées à des DDM politiques ne peuvent pas faire référence à des données imbriquées dans des lacs de données, tels que des documents. JSON

  • Les vues à liaison tardive ne peuvent pas être associées à des DDM politiques si cette vue à liaison tardive est référencée par une vue.

  • DDMles politiques associées aux vues contraignantes tardives 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.

  • Vous pouvez utiliser des variables de contexte de session personnalisées lors de la création DDM de politiques. L'exemple suivant définit les variables de contexte de session pour une DDM politique.

    -- Set a customized context variable.
SELECT set_config('app.city', 'XXXX', FALSE);

-- Create a MASKING policy using current_setting() to get the value of a customized context variable.
CREATE MASKING POLICY city_mask
WITH (city VARCHAR(30))
USING (current_setting('app.city')::VARCHAR(30));

-- Attach the policy on the target table to one or more roles.
ATTACH MASKING POLICY city_mask 
ON tickit_users_redshift(city) 
TO ROLE analyst, ROLE dbadmin;

    Pour plus de détails sur la façon de définir et de récupérer des variables de contexte de session personnalisées SETSET_CONFIG, reportez-vous àSHOW,CURRENT_SETTING, etRESET. Pour plus d'informations sur la modification de la configuration du serveur en général, rendez-vous surModification de la configuration du serveur.

    Important

    Lorsque vous utilisez des variables de contexte de session dans des DDM politiques, la stratégie de sécurité dépend de l'utilisateur ou du rôle qui invoque la stratégie. Veillez à éviter les failles de sécurité lorsque vous utilisez des variables de contexte de session dans DDM les politiques.