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.
Utilisation du masquage dynamique des données avec des chemins de types de SUPER données
Amazon Redshift permet d'associer des politiques de masquage dynamique des données aux chemins de SUPER type colonnes. Pour plus d'informations sur le type de SUPER données, consultezDonnées semi-structurées dans Amazon Redshift.
Lorsque vous associez des politiques de masquage à des chemins de SUPER type colonnes, tenez compte des points suivants.
-
Lorsque vous associez une politique de masquage à un chemin d'une colonne, cette colonne doit être définie comme le type de SUPER données. Vous ne pouvez appliquer des politiques de masquage qu'aux valeurs scalaires du SUPER chemin. 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 même SUPER colonne, à condition que les SUPER chemins ne soient pas en conflit. Par exemple, les SUPER chemins
a.b
et lesa.b.c
conflits parce qu'ils sont sur le même chemin, avec lea.b
fait d'être le parent dea.b.c
. Les SUPER cheminsa.b.c
et les cheminsa.b.d
ne s'affrontent pas. -
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 associez une politique de masquage qui masque des TEXT valeurs à un SUPER chemin contenant une INT valeur, 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 l'interrogation SUPER des objets. 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 indiqué. SUPER Pour plus d'informations sur SUPER les paramètres de configuration associés, consultezSUPERconfigurations. -
SUPERest un type sans schéma, ce qui signifie qu'Amazon Redshift ne peut pas confirmer l'existence de la valeur sur un chemin donné. SUPER Si vous associez une politique de masquage à un SUPER chemin qui n'existe pas et qu'Amazon Redshift est en mode laxiste, Amazon Redshift résoudra le chemin en une valeur.
NULL
Nous vous recommandons de tenir compte du format attendu des SUPER objets et de la probabilité qu'ils présentent des attributs inattendus lorsque vous associez des politiques de masquage aux chemins de SUPER colonnes. Si vous pensez que votre SUPER colonne contient un schéma inattendu, pensez à associer vos politiques de masquage directement à la SUPER colonne. Vous pouvez utiliser les fonctions d'information sur les SUPER types pour vérifier les attributs et les types, ainsiOBJECT_TRANSFORM
que pour masquer les valeurs. Pour plus d'informations sur les fonctions d'informations de SUPER type, consultezSUPERfonctions d'information de type.
Exemples
Associer des politiques de masquage aux tracés SUPER
L'exemple suivant attache plusieurs politiques de masquage à plusieurs chemins SUPER de type 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 de politiques de masquage non valides associées à des SUPER chemins.
-- 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 SUPER chemin 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 }