Sélectionner vos préférences de cookies

Nous utilisons des cookies essentiels et des outils similaires qui sont nécessaires au fonctionnement de notre site et à la fourniture de nos services. Nous utilisons des cookies de performance pour collecter des statistiques anonymes afin de comprendre comment les clients utilisent notre site et d’apporter des améliorations. Les cookies essentiels ne peuvent pas être désactivés, mais vous pouvez cliquer sur « Personnaliser » ou « Refuser » pour refuser les cookies de performance.

Si vous êtes d’accord, AWS et les tiers approuvés utiliseront également des cookies pour fournir des fonctionnalités utiles au site, mémoriser vos préférences et afficher du contenu pertinent, y compris des publicités pertinentes. Pour accepter ou refuser tous les cookies non essentiels, cliquez sur « Accepter » ou « Refuser ». Pour effectuer des choix plus détaillés, cliquez sur « Personnaliser ».

Utilisation du masquage dynamique des données avec des chemins de type de données SUPER

Mode de mise au point
Utilisation du masquage dynamique des données avec des chemins de type de données SUPER - Amazon Redshift

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.

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.

Amazon Redshift permet d’attacher des politiques de masquage dynamique des données aux chemins des colonnes de type SUPER. Pour plus d’informations sur le type de données SUPER, consultez Données semi-structurées dans Amazon Redshift.

Lorsque vous associez des politiques de masquage aux chemins de colonnes de type SUPER, tenez compte des points suivants.

  • Lorsque vous associez une politique de masquage à un chemin dans une colonne, cette colonne doit être définie comme type de données SUPER. Vous ne pouvez appliquer des politiques de masquage qu’aux valeurs scalaires du chemin SUPER. Vous ne pouvez pas appliquer de politiques de masquage à des structures ou à des tableaux complexes.

  • Vous pouvez appliquer différentes politiques de masquage à plusieurs valeurs scalaires sur une seule colonne SUPER, à condition que les chemins SUPER ne soient pas en conflit. Par exemple, les chemins SUPER a.b et a.b.c entrent en conflit parce qu’ils se trouvent sur le même chemin, a.b étant le parent de a.b.c. Les chemins SUPER a.b.c et a.b.d ne sont pas en conflit.

  • Amazon Redshift ne peut pas vérifier que les chemins auxquels s’attache une politique de masquage existent dans les données et sont du type attendu, tant que la politique n’est pas appliquée à l’exécution de la requête utilisateur. Par exemple, lorsque vous attachez une politique de masquage qui masque les valeurs TEXT à un chemin SUPER contenant une valeur INT, Amazon Redshift essaie de convertir le type de valeur sur le chemin.

    Dans de telles situations, le comportement d’Amazon Redshift au moment de l’exécution dépend de vos paramètres de configuration pour interroger les objets SUPER. Par défaut, Amazon Redshift est en mode laxiste et résoudra les chemins manquants et les conversions non valides comme NULL pour le chemin SUPER indiqué. Pour plus d’informations sur les paramètres de configuration concernant SUPER, consultez Configurations SUPER.

  • SUPER est un type sans schéma, ce qui signifie qu’Amazon Redshift ne peut pas confirmer l’existence de la valeur sur un chemin SUPER donné. Si vous attachez une politique de masquage à un chemin SUPER qui n’existe pas et qu’Amazon Redshift est en mode laxiste, Amazon Redshift résoudra le chemin à une valeur NULL. Nous vous recommandons de tenir compte du format attendu des objets SUPER et de la probabilité qu’ils présentent des attributs inattendus lorsque vous attachez des politiques de masquage aux chemins des colonnes SUPER. Si vous pensez qu’il existe un schéma inattendu dans votre colonne SUPER, pensez à attacher vos politiques de masquage directement à la colonne SUPER. Vous pouvez utiliser les fonctions d’information de type SUPER pour vérifier les attributs et les types, et utiliser OBJECT_TRANSFORM pour masquer les valeurs. Pour plus d’informations sur les fonctions d’information de type SUPER, consultez Fonctions d’informations sur le type SUPER.

Exemples

Association de politiques de masquage aux chemins SUPER

L’exemple suivant attache plusieurs politiques de masquage à plusieurs chemins de type SUPER dans une colonne.

CREATE TABLE employees ( col_person SUPER ); INSERT INTO employees VALUES ( json_parse(' { "name": { "first": "John", "last": "Doe" }, "age": 25, "ssn": "111-22-3333", "company": "Company Inc." } ') ), ( json_parse(' { "name": { "first": "Jane", "last": "Appleseed" }, "age": 34, "ssn": "444-55-7777", "company": "Organization Org." } ') ) ; GRANT ALL ON ALL TABLES IN SCHEMA "public" TO PUBLIC; -- Create the masking policies. -- This policy converts the given name to all uppercase letters. CREATE MASKING POLICY mask_first_name WITH(first_name TEXT) USING ( UPPER(first_name) ); -- This policy replaces the given name with the fixed string 'XXXX'. CREATE MASKING POLICY mask_last_name WITH(last_name TEXT) USING ( 'XXXX'::TEXT ); -- This policy rounds down the given age to the nearest 10. CREATE MASKING POLICY mask_age WITH(age INT) USING ( (FLOOR(age::FLOAT / 10) * 10)::INT ); -- This policy converts the first five digits of the given SSN to 'XXX-XX'. CREATE MASKING POLICY mask_ssn WITH(ssn TEXT) USING ( 'XXX-XX-'::TEXT || SUBSTRING(ssn::TEXT FROM 8 FOR 4) ); -- Attach the masking policies to the employees table. ATTACH MASKING POLICY mask_first_name ON employees(col_person.name.first) TO PUBLIC; ATTACH MASKING POLICY mask_last_name ON employees(col_person.name.last) TO PUBLIC; ATTACH MASKING POLICY mask_age ON employees(col_person.age) TO PUBLIC; ATTACH MASKING POLICY mask_ssn ON employees(col_person.ssn) TO PUBLIC; -- Verify that your masking policies are attached. SELECT policy_name, TABLE_NAME, priority, input_columns, output_columns FROM svv_attached_masking_policy; policy_name | table_name | priority | input_columns | output_columns -----------------+------------+----------+-----------------------------------+----------------------------------- mask_age | employees | 0 | ["col_person.\"age\""] | ["col_person.\"age\""] mask_first_name | employees | 0 | ["col_person.\"name\".\"first\""] | ["col_person.\"name\".\"first\""] mask_last_name | employees | 0 | ["col_person.\"name\".\"last\""] | ["col_person.\"name\".\"last\""] mask_ssn | employees | 0 | ["col_person.\"ssn\""] | ["col_person.\"ssn\""] (4 rows) -- Observe the masking policies taking effect. SELECT col_person FROM employees ORDER BY col_person.age; -- This result is formatted for ease of reading. col_person -------------------------------- { "name": { "first": "JOHN", "last": "XXXX" }, "age": 20, "ssn": "XXX-XX-3333", "company": "Company Inc." } { "name": { "first": "JANE", "last": "XXXX" }, "age": 30, "ssn": "XXX-XX-7777", "company": "Organization Org." }

Voici quelques exemples d’attachements non valides de politique de masquage à des chemins SUPER.

-- This attachment fails because there is already a policy -- with equal priority attached to employees.name.last, which is -- on the same SUPER path as employees.name. ATTACH MASKING POLICY mask_ssn ON employees(col_person.name) TO PUBLIC; ERROR: DDM policy "mask_last_name" is already attached on relation "employees" column "col_person."name"."last"" with same priority -- Create a masking policy that masks DATETIME objects. CREATE MASKING POLICY mask_date WITH(INPUT DATETIME) USING ( INPUT ); -- This attachment fails because SUPER type columns can't contain DATETIME objects. ATTACH MASKING POLICY mask_date ON employees(col_person.company) TO PUBLIC; ERROR: cannot attach masking policy for output of type "timestamp without time zone" to column "col_person."company"" of type "super

Voici un exemple d’attachement d’une politique de masquage à un chemin SUPER qui n’existe pas. Par défaut, Amazon Redshift résoudra le chemin à la valeur NULL.

ATTACH MASKING POLICY mask_first_name ON employees(col_person.not_exists) TO PUBLIC; SELECT col_person FROM employees LIMIT 1; -- This result is formatted for ease of reading. col_person ----------------------------------- { "name": { "first": "JOHN", "last": "XXXX" }, "age": 20, "ssn": "XXX-XX-3333", "company": "Company Inc.", "not_exists": null }

Sur cette page

ConfidentialitéConditions d'utilisation du sitePréférences de cookies
© 2025, Amazon Web Services, Inc. ou ses affiliés. Tous droits réservés.