Uso do mascaramento de dados dinâmico com caminhos do tipo de dados SUPER

O Amazon Redshift dá suporte à anexação de políticas de mascaramento de dados dinâmicas a caminhos das colunas do tipo SUPER. Para obter mais informações sobre tipos de dados SUPER, consulte Dados semiestruturados no Amazon Redshift.

Ao anexar políticas de mascaramento a caminhos de colunas do tipo SUPER, considere o seguinte.

• Ao anexar uma política de mascaramento a um caminho em uma coluna, essa coluna deve ser definida como o tipo de dados SUPER. Você só pode aplicar políticas de mascaramento a valores escalares no caminho SUPER. Você não pode aplicar políticas de mascaramento a estruturas ou matrizes complexas.

• Você pode aplicar políticas de mascaramento diferentes a vários valores escalares em uma única coluna SUPER, desde que os caminhos SUPER não entrem em conflito. Por exemplo, os caminhos SUPER a.b e a.b.c estão em conflito porque estão no mesmo caminho, com a.b sendo o pai de a.b.c. Os caminhos SUPER a.b.c e a.b.d não entram em conflito.

• O Amazon Redshift não consegue verificar se os caminhos anexados por uma política de mascaramento existem nos dados e são do tipo esperado até que a política seja aplicada no runtime da consulta do usuário. Por exemplo, quando você anexar uma política de mascaramento que mascara valores TEXT a um caminho SUPER contendo um valor INT, o Amazon Redshift tentará converter o tipo do valor no caminho.

  Nessas situações, o comportamento do Amazon Redshift no runtime depende das definições de configuração para consulta de objetos SUPER. Por padrão, o Amazon Redshift está em modo relaxado e vai resolver caminhos não encontrados e conversões inválidas como NULL para o caminho SUPER indicado. Para obter mais informações sobre definições de configuração relacionadas a SUPER, consulte Configurações SUPER.

• SUPER é um tipo sem esquema, o que significa que o Amazon Redshift não consegue confirmar a existência do valor em um determinado caminho SUPER. Se você anexar uma política de mascaramento a um caminho SUPER não existente e o Amazon Redshift estiver em modo flexível, o Amazon Redshift vai resolver o caminho para um valor NULL. É recomendável considerar o formato esperado de objetos SUPER e a probabilidade de terem atributos inesperados durante a anexação das políticas de mascaramento aos caminhos de colunas SUPER. Se você acha que possa haver um esquema inesperado na coluna SUPER, considere anexar diretamente as políticas de mascaramento à coluna SUPER. Você pode usar as funções de informações do tipo SUPER para verificar atributos e tipos e usar OBJECT_TRANSFORM para mascarar os valores. Para obter mais informações sobre funções de informações do tipo SUPER, consulte Funções de informação de tipo SUPER.

Exemplos

Anexação das políticas de mascaramento a caminhos SUPER

O exemplo a seguir anexa várias políticas de mascaramento a vários caminhos do tipo SUPER em uma coluna.

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

Estes são alguns exemplos de anexos da política de mascaramento inválidos aos caminhos 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

Este é um exemplo de anexação de uma política de mascaramento a um caminho SUPER não existente. Por padrão, o Amazon Redshift vai resolver o caminho para 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
}