Verwendung dynamischer Datenmaskierung mit Pfaden des Datentyps SUPER

Amazon Redshift unterstützt das Anfügen dynamischer Datenmaskierungsrichtlinien an Pfade von Spalten des Typs SUPER. Weitere Informationen zum SUPER-Datentyp finden Sie unter Erfassen und Abfragen von halbstrukturierten Daten in Amazon Redshift.

Beachten Sie beim Anfügen von Maskierungsrichtlinien an Pfade von Spalten des Typs SUPER Folgendes.

• Beim Anfügen einer Maskierungsrichtlinie an einen Pfad in einer Spalte muss diese Spalte mit dem Datentyp SUPER definiert werden. Sie können Maskierungsrichtlinien nur auf Skalarwerte im SUPER-Pfad anwenden. Sie können Maskierungsrichtlinien nicht auf komplexe Strukturen oder Arrays anwenden.

• Sie können unterschiedliche Maskierungsrichtlinien auf mehrere Skalarwerte in einer einzelnen SUPER-Spalte anwenden, sofern die SUPER-Pfade nicht miteinander in Konflikt stehen. Beispielsweise stehen die SUPER-Pfade a.b in a.b.c Konflikt, weil sie sich auf demselben Pfad befinden, wobei a.b das übergeordnete Element von a.b.c ist. Die SUPER-Pfade a.b.c und a.b.d stehen nicht im Konflikt.

• Amazon Redshift kann erst überprüfen, ob die Pfade, denen eine Maskierungsrichtlinie angefügt wird, in den Daten existieren und den erwarteten Typ haben, wenn die Richtlinie zur Laufzeit der Benutzerabfrage angewendet wird. Wenn Sie beispielsweise eine Maskierungsrichtlinie anfügen, die TEXT-Werte mit einem SUPER-Pfad maskiert, der einen INT-Wert enthält, versucht Amazon Redshift, den Typ des Werts in dem Pfad umzuwandeln.

  In solchen Situationen hängt das Verhalten von Amazon Redshift zur Laufzeit von Ihren Konfigurationseinstellungen für die Abfrage von SUPER-Objekten ab. Standardmäßig befindet sich Amazon Redshift im Lax-Modus und löst fehlende Pfade und ungültige Umwandlungen wie beim angegebenen NULL für den SUPER-Pfad auf. Weitere Informationen zu den Konfigurationseinstellungen im Zusammenhang mit SUPER finden Sie unter SUPER-Konfigurationen.

• SUPER ist ein Typ ohne Schema, was bedeutet, dass Amazon Redshift die Existenz des Werts in einem bestimmten SUPER-Pfad nicht bestätigen kann. Wenn Sie eine Maskierungsrichtlinie an einen SUPER-Pfad anfügen, der nicht existiert, und Amazon Redshift sich im Lax-Modus befindet, löst Amazon Redshift den Pfad zu einem NULL-Wert auf. Wir empfehlen, das erwartete Format von SUPER-Objekten und die Wahrscheinlichkeit, dass sie unerwartete Attribute aufweisen, zu berücksichtigen, wenn Sie Maskierungsrichtlinien an Pfade von SUPER-Spalten anfügen. Wenn Sie vermuten, dass Ihre SUPER-Spalte ein unerwartetes Schema enthält, sollten Sie erwägen, Ihre Maskierungsrichtlinien direkt an die SUPER-Spalte anzufügen. Sie können die Informationsfunktionen vom Typ SUPER verwenden, um Attribute und Typen zu überprüfen und um mit OBJECT_TRANSFORM die Werte zu maskieren. Weitere Informationen zu SUPER-Informationsfunktionen finden Sie unter Funktionen für SUPER-Typinformationen.

Beispiele

Anfügen von Maskierungsrichtlinien an SUPER-Pfade

Im folgenden Beispiel werden mehrere Maskierungsrichtlinien an mehrere SUPER-Pfade in einer Spalte angefügt.

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."
}

Im Folgenden finden Sie einige Beispiele für ungültige Maskierungsrichtlinien-Anhänge an SUPER-Pfade.

-- 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

Im Folgenden finden Sie ein Beispiel für das Anfügen einer Maskierungsrichtlinie an einen SUPER-Pfad, der nicht existiert. Standardmäßig löst Amazon Redshift den Pfad zu NULL auf.

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
}