Políticas de mascaramento baseadas em tags¶

Privilégio¶

Existem diferentes requisitos de privilégio, dependendo se você optar por definir a política de mascaramento baseada em tags em um banco de dados, esquema ou tabela.

Com o mascaramento baseado em tags em um banco de dados ou esquema, a função atual ou uma função na hierarquia de funções atual deve herdar os privilégios mostrados em uma das duas opções a seguir.

Opção 1:

A função deve ter tanto o APPLY MASKING POLICY global e os privilégios globais APPLY TAG. Por exemplo, conceda esses privilégios à função personalizada data_engineer:

USE ROLE ACCOUNTADMIN;

GRANT APPLY MASKING POLICY ON ACCOUNT TO ROLE data_engineer;

GRANT APPLY TAG ON ACCOUNT TO ROLE data_engineer;

Copy

Este é a abordagem mais centralizada para proteger colunas com uma política de mascaramento baseada em tags em um esquema ou banco de dados.

Opção 2:

Um proprietário de esquema (ou seja, uma função com o privilégio OWNERSHIP no esquema) pode ter o privilégio global APPLY MASKING POLICY e o privilégio APPLY na tag. Por exemplo, se a tag tiver o nome governance.tags.schema_mask e a função personalizada que possui o esquema for schema_owner:

USE ROLE ACCOUNTADMIN;

GRANT APPLY MASKING POLICY ON ACCOUNT TO ROLE schema_owner;

GRANT APPLY ON TAG governance.tags.schema_mask TO ROLE schema_owner;

Copy

Essa abordagem fornece mais flexibilidade ao delegar proteção de coluna aos proprietários do esquema.

Com o mascaramento baseado em tags em tabelas e exibições, uma função com o privilégio global APPLY MASKING POLICY pode atribuir e substituir uma política de mascaramento em uma tag.

Por exemplo, conceda o privilégio global APPLY MASKING POLICY à função personalizada tag_admin:

USE ROLE SECURITYADMIN;

GRANT APPLY MASKING POLICY ON ACCOUNT TO ROLE tag_admin;

Copy

Atribuição de um política de mascaramento a uma tag¶

A atribuição de uma política de mascaramento baseada em tags em um esquema ou banco de dados segue o mesmo procedimento que definir uma política de mascaramento baseada em tags em uma tabela:

1. Crie uma tag usando o comando CREATE TAG.

2. Crie uma política de mascaramento usando o comando CREATE MASKING POLICY.

   Você pode opcionalmente usar as funções do sistema SYSTEM$GET_TAG_ON_CURRENT_COLUMN e SYSTEM$GET_TAG_ON_CURRENT_TABLE nas condições da política de mascaramento.

3. Defina a política de mascaramento na tag usando um comando ALTER TAG.

4. Defina a tag no objeto com base em como você deseja proteger seus dados usando um dos seguintes comandos:

   • ALTER DATABASE

   • ALTER SCHEMA

   • ALTER TABLE

Além das notas de uso de ALTER TAG, observe o seguinte:

• Uma tag pode ter apenas uma política de mascaramento por tipo de dados. Por exemplo, uma única política para o tipo de dados STRING, uma única política para o tipo de dados NUMBER e assim por diante.

• Se uma política de mascaramento já proteger uma coluna e uma tag com uma política de mascaramento for definida na mesma coluna, a política de mascaramento diretamente atribuída à coluna tem precedência sobre a política de mascaramento atribuída à tag.

• Uma tag não pode ser descartada se for atribuída a uma política de mascaramento.

• Uma política de mascaramento não pode ser descartada se for atribuída a uma tag.

Para obter mais informações sobre o gerenciamento de políticas de mascaramento e tags, consulte:

• Gerenciamento da segurança em nível de coluna

• Gerenciamento de tags

Substituição de uma política de mascaramento em uma tag¶

Depois de definir uma política de mascaramento em uma tag, existem dois caminhos diferentes para substituir a política de mascaramento na tag por uma política de mascaramento diferente. A instrução ALTER TAG deve especificar o nome da política de mascaramento, conforme mostrado nas opções a seguir.

Opção 1:

Remova a política de uma tag em uma instrução e, em seguida, defina uma nova política na tag em uma instrução diferente:

ALTER TAG security UNSET MASKING POLICY ssn_mask;

ALTER TAG security SET MASKING POLICY ssn_mask_2;

Copy

Opção 2:

Use a palavra-chave FORCE para substituir a política em uma única instrução:

Note que o uso da palavra-chave FORCE substitui a política quando uma política do mesmo tipo de dados já estiver definida na tag.

ALTER TAG security SET MASKING POLICY ssn_mask_2 FORCE;

Copy

A opção que você selecionar na seção Privilégio e a ordem das operações na seção Atribuição de um política de mascaramento a uma tag pode afetar o gerenciamento de tags se você precisar substituir ou cancelar a definição de uma tag em um banco de dados ou esquema.

Se um proprietário de esquema definir uma tag em um esquema e, em seguida, uma função diferente definir uma política de mascaramento na mesma tag, o proprietário do esquema não poderá cancelar a definição da tag do esquema, a menos que o proprietário do esquema receba o privilégio global APPLY MASKING POLICY. O Snowflake falha a operação ALTER SCHEMA … UNSET TAG para o proprietário do esquema. Esse cenário garante que os dados da coluna protegidos por uma política de mascaramento baseada em tags permaneçam protegidos. Para evitar esse cenário, use a opção 1 na seção Privilégio.

Importante

Tenha cuidado ao substituir uma política de mascaramento em uma tag.

Dependendo do momento da substituição e da consulta na coluna, optar por substituir a política em duas instruções separadas poderia levar a um vazamento de dados porque os dados da coluna estão desprotegidos no intervalo de tempo entre as operações UNSET e SET.

No entanto, se as condições da política forem diferentes na política de substituição, especificar a palavra-chave FORCE pode levar a uma falta de acesso porque (anteriormente) os usuários poderiam acessar os dados e a substituição não permite mais o acesso.

Antes de substituir uma política, consulte seus administradores de dados internos para coordenar a melhor abordagem para proteger os dados com políticas de mascaramento e substituir as políticas de mascaramento baseadas em tag conforme necessário.

Atualização de um valor de tag¶

Se um proprietário de esquema (ou seja, sch_role) definir uma tag em um esquema e, em seguida, uma função diferente definir uma política de mascaramento na mesma tag (ou seja, masking_admin_role), o proprietário do esquema não poderá alterar o valor da tag. O Snowflake falha a operação ALTER SCHEMA … SET TAG para o proprietário do esquema.

Para alterar o valor da tag:

1. Usando o masking_admin_role, desmarque a política de mascaramento da tag.

2. Usando o sch_role, modifique o valor da tag.

3. Reatribua a política de mascaramento à tag usando masking_admin_role.

Banco de dados e esquema pai¶

Você não pode executar as operações DROP e REPLACE no banco de dados e esquema quando:

• A tag e a política de mascaramento estão no mesmo esquema.

• A tabela ou exibição está em um esquema diferente.

• A coluna protegida na tabela ou exibição existe em um esquema diferente do esquema que contém a política de mascaramento e a tag.

Estes quatro comandos se referem a DROP e substituem as operações no banco de dados e esquema:

• DROP DATABASE

• DROP SCHEMA

• CREATE OR REPLACE DATABASE

• CREATE OR REPLACE SCHEMA

Argumentos condicionais¶

Uma política de mascaramento condicional pode ser atribuída a uma tag. Após atribuir a tag a uma coluna, os argumentos condicionais são mapeados para uma coluna na tabela por nome se o tipo de dados do argumento coincidir com o tipo de dados da coluna.

Uma consulta falhará se uma política de mascaramento condicional for atribuída a uma coluna nos seguintes casos:

• A tabela não tem uma coluna com o mesmo nome que um argumento condicional da política.

• A tabela tem uma coluna que corresponde ao nome do argumento condicional da política, mas o tipo de dados não coincide.

Para obter mais informações sobre esses erros, consulte Solução de problemas de políticas de mascaramento baseadas em tags (neste tópico).

Linhagem de tags¶

A tag com a política de mascaramento pode ser atribuída a todos os objetos da tabela base, ou a tag pode ser atribuída a uma coluna em uma tabela base. colunas. Quando a política de mascaramento baseada em tags é atribuída a uma tabela base, as colunas são protegidas pela política desde que o tipo de dados da coluna corresponda ao tipo de dados na assinatura da política de mascaramento.

Como a política de mascaramento protege as colunas da tabela base, as colunas de exibição derivadas das colunas da tabela base subjacente também são protegidas, com base nas atuais limitações, considerações e comportamentos relacionados a políticas de mascaramento com tabelas e exibições.

Data Sharing¶

As políticas de mascaramento baseadas em tags definidas em um esquema compartilhado ou banco de dados compartilhado na conta do provedor são aplicadas na conta do consumidor. Esse cenário garante que os dados protegidos compartilhados permaneçam protegidos, mesmo que um consumidor crie um novo banco de dados a partir do compartilhamento.

Além disso, observe o seguinte:

• A linhagem da tag é preservada na conta do consumidor.

  Quando o provedor define uma política de mascaramento baseada em tags em seu banco de dados e compartilha esse banco de dados, o Snowflake faz referência ao banco de dados compartilhado do provedor na conta do consumidor nos termos do banco de dados que contém a tag.

• O Snowflake não respeita a linhagem de tags com objetos compartilhados quando as tags e as políticas de mascaramento baseadas em tags se originam na conta do consumidor.

  As tags e as políticas de mascaramento baseadas em tags da conta do consumidor não são impostas a nenhum objeto compartilhado.

Snowsight¶

Você pode monitorar e atribuir políticas de mascaramento baseadas em tags no Snowsight. Para obter mais detalhes, consulte:

• Monitoramento de tags com Snowsight

• Monitoramento de políticas de mascaramento com Snowsight

Descoberta de tags e políticas¶

A função de tabela POLICY_REFERENCES de Information Schema e a exibição POLICY_REFERENCES de Account Usage podem ajudar a determinar se uma política de mascaramento e uma tag se referem uma à outra; para isso, observe as seguintes colunas:

• TAG_DATABASE

• TAG_SCHEMA

• TAG_NAME

• POLICY_STATUS

A coluna POLICY_STATUS pode ter quatro valores possíveis:

ACTIVE

Especifica que a coluna (isto é, REF_COLUMN_NAME) só é associada a uma única política por uma tag.

MULTIPLE_MASKING_POLICY_ASSIGNED_TO_THE_COLUMN

Especifica que múltiplas políticas de mascaramento são atribuídas à mesma coluna.

COLUMN_IS_MISSING_FOR_SECONDARY_ARG

Especifica que a política (isto é, POLICY_NAME) é uma política de mascaramento condicional e a tabela (isto é, REF_ENTITY_NAME) não tem uma coluna com o mesmo nome.

COLUMN_DATATYPE_MISMATCH_FOR_SECONDARY_ARG

Especifica que a política é uma política de mascaramento condicional e a tabela tem uma coluna com o mesmo nome, mas um tipo de dados diferente do tipo de dados na assinatura da política de mascaramento.

Para obter mais detalhes sobre mensagens de erro relacionadas com os valores possíveis na coluna POLICY_STATUS, consulte Solução de problemas de políticas de mascaramento baseadas em tags (neste tópico).

Etapas de proteção e validação de dados¶

De forma geral, o Snowflake recomenda a seguinte abordagem ao utilizar políticas de mascaramento baseadas em tags:

1. Crie quaisquer tags que sejam necessárias para políticas de mascaramento baseadas em tags.

2. Crie uma única política de mascaramento para cada tipo de dados com base nas colunas de tabela que você pretende proteger com as políticas de mascaramento baseadas em tags.

3. Atribua as políticas de mascaramento à tag.

4. Atribua a tag com as políticas de mascaramento à coluna da tabela diretamente, ou à tabela.

5. Verifique no Information Schema se a política baseada em tags está atribuída às colunas.

6. Consulte os dados para verificar se a política de mascaramento baseada em tags protege os dados como pretendido.

Etapas de pré-requisitos¶

1. Identifique as tags existentes e seus valores de cadeia de caracteres em sua conta Snowflake.

   • Consulte a exibição TAG REFERENCES de Account Usage para obter todas as tags e seus valores de cadeia de caracteres atribuídos.

   • Opcionalmente:

     • Consulte a exibição TAGS de Account Usage (ou seja, o catálogo de tags) para obter uma lista de tags e garantir que não ocorram nomes duplicados de tags mais tarde ao usar políticas de mascaramento baseadas em tags.

     • Compare as saídas das consultas TAG_REFERENCES e TAGS para determinar se há alguma tag não atribuída que possa ser usada posteriormente.

     • Crie quaisquer tags que serão necessárias mais tarde usando o comando CREATE TAG. Caso contrário, crie tags conforme necessário.

2. Identifique as políticas existentes e suas definições em sua conta Snowflake.

   • Execute o comando SHOW MASKING POLICIES para obter uma lista das políticas de mascaramento existentes.

   • Decida se essas políticas, em sua forma atual, podem ser atribuídas a tags. Se necessário, execute o comando DESCRIBE MASKING POLICY para obter a definição de políticas. Caso contrário, planeje criar novas políticas para atribuir a tags.

3. Determine como proteger os dados da coluna com a política de mascaramento em termos de se as condições da política devem avaliar o valor da cadeia de caracteres da tag que está definido na coluna da tabela.

Premissas comuns com os exemplos¶

Os exemplos têm as seguintes premissas:

• Os pré-requisitos foram concluídos.

• A função personalizada tag_admin tem os seguintes privilégios:

  • O privilégio de nível de esquema CREATE TAG.

  • O privilégio global APPLY TAG.

  Para obter mais informações, consulte privilégios de tags.

• A função personalizada masking_admin tem os seguintes privilégios:

  • O privilégio de nível de esquema CREATE MASKING POLICY.

  • O privilégio USAGE no banco de dados governance e o esquema governance.masking_policies.

  • O privilégio global APPLY MASKING POLICY para atribuir políticas de mascaramento a tags (consulte Privilégio neste tópico).

  • O privilégio global APPLY TAG para atribuir a tag (com as políticas de mascaramento) a objetos.

  Para obter mais detalhes, consulte privilégios de tag.

• A função personalizada row_access_admin tem os seguintes privilégios:

  • O privilégio de nível de esquema CREATE ROW ACCESS POLICY.

  • O privilégio USAGE no banco de dados governance e o esquema governance.row_access_policies.

  • O privilégio global APPLY ROW ACCESS POLICY.

  Para obter mais informações, consulte privilégios da política de acesso a linhas.

• A função personalizada accounting_admin tem os seguintes privilégios:

  • O privilégio USAGE no banco de dados finance e o esquema finance.accounting.

  • O privilégio SELECT nas tabelas do esquema finance.accounting.

• A função personalizada analyst tem os seguintes privilégios:

  • O privilégio USAGE no banco de dados finance e no esquema finance.accounting.

  • O privilégio SELECT na tabela finance.accounting.name_number.

• As funções personalizadas descritas acima são concedidas aos usuários apropriados.

  Para obter mais detalhes, consulte Configuração do controle de acesso.

Exemplo 1: proteção de dados da coluna com base na política de mascaramento diretamente atribuída à tag¶

Este exemplo atribui duas políticas de mascaramento a uma tag e depois atribui a mesma tag a uma tabela. O resultado é que as políticas de mascaramento protegem todas as colunas da tabela cujos tipos de dados correspondem aos tipos de dados das políticas.

Os passos seguintes criam uma política de mascaramento baseada em tags para mascarar dados contábeis. Por exemplo, considere a tabela chamada finance.accounting.name_number, que tem duas colunas, ACCOUNT_NAME e ACCOUNT_NUMBER. Os tipos de dados nestas colunas são STRING e NUMBER, respectivamente.

---------------+----------------+
  ACCOUNT_NAME | ACCOUNT_NUMBER |
---------------+----------------+
  ACME         | 1000           |
---------------+----------------+

Crie uma política de mascaramento baseada em tags para proteger as colunas ACCOUNT_NAME e ACCOUNT_NUMBER como a seguir:

1. Crie uma tag chamada accounting no esquema chamado governance.tags.

   USE ROLE tag_admin;
   USE SCHEMA governance.tags;
   CREATE OR REPLACE TAG accounting;
   

   Copy

2. Crie diferentes políticas de mascaramento para proteger as colunas ACCOUNT_NAME e ACCOUNT_NUMBER. Em cada uma dessas políticas, somente a função personalizada ACCOUNTING_ADMIN pode visualizar os dados brutos.

   Política de nome de conta:

   USE ROLE masking_admin;
   USE SCHEMA governance.masking_policies;
   
   CREATE OR REPLACE MASKING POLICY account_name_mask
   AS (val string) RETURNS string ->
     CASE
       WHEN CURRENT_ROLE() IN ('ACCOUNTING_ADMIN') THEN val
       ELSE '***MASKED***'
     END;
   

   Copy

   Política de número de conta:

   CREATE OR REPLACE MASKING POLICY account_number_mask
   AS (val number) RETURNS number ->
     CASE
       WHEN CURRENT_ROLE() IN ('ACCOUNTING_ADMIN') THEN val
       ELSE -1
     END;
   

   Copy

3. Atribua ambas as políticas de mascaramento à tag accounting. Observe que ambas as políticas podem ser atribuídas à tag em uma única instrução.

   ALTER TAG governance.tags.accounting SET
     MASKING POLICY account_name_mask,
     MASKING POLICY account_number_mask;
   

   Copy

4. Atribua a tag accounting à tabela finance.accounting.name_number.

   ALTER TABLE finance.accounting.name_number
     SET TAG governance.tags.accounting = 'tag-based policies';
   

   Copy

5. Verifique se as colunas ACCOUNT_NAME e ACCOUNT_NUMBER da tabela estão protegidas pela política de mascaramento baseada em tags chamando a função de tabela POLICY_REFERENCES do Information Schema.

   Para cada coluna protegida, a linha no resultado da consulta deve especificar os valores apropriados para o nome da coluna, nome da política e nome da tag:

   USE ROLE masking_admin;
   SELECT *
   FROM TABLE (governance.INFORMATION_SCHEMA.POLICY_REFERENCES(
     REF_ENTITY_DOMAIN => 'TABLE',
     REF_ENTITY_NAME => 'governance.accounting.name_number' )
   );
   

   Copy

   Retorna (note as colunas atualizadas):

   -------------+------------------+---------------------+----------------+-------------------+-----------------+-----------------+-------------------+-----------------+----------------------+--------------+------------+------------+---------------+
     POLICY_DB  | POLICY_SCHEMA    | POLICY_NAME         | POLICY_KIND    | REF_DATABASE_NAME | REF_SCHEMA_NAME | REF_ENTITY_NAME | REF_ENTITY_DOMAIN | REF_COLUMN_NAME | REF_ARG_COLUMN_NAMES | TAG_DATABASE | TAG_SCHEMA | TAG_NAME   | POLICY_STATUS |
   -------------+------------------+---------------------+----------------+-------------------+-----------------+-----------------+-------------------+-----------------+----------------------+--------------+------------+------------+---------------+
     GOVERNANCE | MASKING_POLICIES | ACCOUNT_NAME_MASK   | MASKING_POLICY | FINANCE           | ACCOUNTING      | NAME_NUMBER     | TABLE             | ACCOUNT_NAME    | NULL                 | GOVERNANCE   | TAGS       | ACCOUNTING | ACTIVE        |
     GOVERNANCE | MASKING_POLICIES | ACCOUNT_NUMBER_MASK | MASKING_POLICY | FINANCE           | ACCOUNTING      | NAME_NUMBER     | TABLE             | ACCOUNT_NUMBER  | NULL                 | GOVERNANCE   | TAGS       | ACCOUNTING | ACTIVE        |
   -------------+------------------+---------------------+----------------+-------------------+-----------------+-----------------+-------------------+-----------------+----------------------+--------------+------------+------------+---------------+
   

6. Consulte as colunas da tabela com funções autorizadas e não autorizadas para garantir que o Snowflake retorne o resultado de consulta correto.

   Autorizado:

   USE ROLE accounting_admin;
   SELECT * FROM finance.accounting.name_number;
   

   Copy

   Retorna:

   ---------------+----------------+
     ACCOUNT_NAME | ACCOUNT_NUMBER |
   ---------------+----------------+
     ACME         | 1000           |
   ---------------+----------------+
   

   Não autorizado:

   USE ROLE analyst;
   SELECT * FROM finance.accounting.name_number;
   

   Copy

   Retorna:

   ---------------+----------------+
     ACCOUNT_NAME | ACCOUNT_NUMBER |
   ---------------+----------------+
     ***MASKED*** | -1             |
   ---------------+----------------+
   

Exemplo 2: proteção de dados da coluna com base no valor da cadeia de caracteres da tag da coluna¶

Este exemplo usa uma política de mascaramento baseada em tags para determinar se os dados devem ser mascarados com base no valor da cadeia de caracteres da tag atribuída a uma coluna. A política de mascaramento avalia dinamicamente o valor da cadeia de caracteres da tag chamando a função SYSTEM$GET_TAG_ON_CURRENT_COLUMN para as condições da política de mascaramento e gravando as condições da política de mascaramento para corresponder ao valor da cadeia de caracteres da tag.

Os passos seguintes criam uma política de mascaramento baseada em tags para mascarar dados contábeis. Para brevidade, as colunas da tabela têm dois tipos de dados, STRING e NUMBER, respectivamente. Por exemplo, uma tabela chamada finance.accounting.name_number:

---------------+----------------+
  ACCOUNT_NAME | ACCOUNT_NUMBER |
---------------+----------------+
  ACME         | 1000           |
---------------+----------------+

Crie uma política de mascaramento baseada em tags para proteger as colunas ACCOUNT_NAME e ACCOUNT_NUMBER como a seguir:

1. Crie uma tag chamada accounting_col_string no esquema chamado governance.tags.

   USE ROLE tag_admin;
   USE SCHEMA governance.tags;
   CREATE TAG accounting_col_string;
   

   Copy

2. Crie diferentes políticas de mascaramento para proteger as colunas ACCOUNT_NAME e ACCOUNT_NUMBER. Em cada uma destas políticas, os dados brutos são visíveis somente quando o valor atual da cadeia de caracteres da tag na coluna é definido como 'visible'.

   Política de nome de conta:

   USE ROLE masking_admin;
   USE SCHEMA governance.masking_policies;
   
   CREATE MASKING POLICY account_name_mask_tag_string
   AS (val string) RETURNS string ->
     CASE
       WHEN SYSTEM$GET_TAG_ON_CURRENT_COLUMN('tags.accounting_col_string') = 'visible' THEN val
       ELSE '***MASKED***'
     END;
   

   Copy

   Política de número de conta:

   CREATE MASKING POLICY account_number_mask_tag_string
   AS (val number) RETURNS number ->
     CASE
       WHEN SYSTEM$GET_TAG_ON_CURRENT_COLUMN('tags.accounting_col_string') = 'visible' THEN val
       ELSE -1
     END;
   

   Copy

   Nota

   Essas políticas utilizam o formato de nome de objeto schema_name.tag_name no argumento da função porque tanto o esquema tags como o esquema masking_policies existem no banco de dados governance. Alternativamente, você também pode usar o nome totalmente qualificado para a tag no argumento da função.

   O Snowflake retorna um erro no tempo de execução da consulta em uma coluna protegida por uma política de mascaramento baseada em tags se o argumento da função do sistema nas condições da política contiver um nome de tag que não seja suficientemente qualificado. Por exemplo, o argumento usa o nome da tag como apenas accounting_col_string, sem especificar o nome do esquema ou o nome do banco de dados.

   Para obter mais informações, consulte Resolução de nomes de objetos.

3. Atribua ambas as políticas de mascaramento à tag accounting_col_string. Observe que ambas as políticas podem ser atribuídas à tag em uma única instrução.

   ALTER TAG accounting_col_string SET
     MASKING POLICY account_name_mask_tag_string,
     MASKING POLICY account_number_mask_tag_string;
   

   Copy

4. Atribua a tag accounting_col_string a cada coluna da tabela. Neste exemplo, o valor da cadeia de caracteres da tag na coluna ACCOUNT_NAME é 'visible'; entretanto, o valor da cadeia de caracteres da tag na coluna ACCOUNT_NUMBER é definido como 'protect'.

   ALTER TABLE finance.accounting.name_number MODIFY COLUMN
     account_name SET TAG governance.tags.accounting_col_string = 'visible',
     account_number SET TAG governance.tags.accounting_col_string = 'protect';
   

   Copy

5. Verifique se as colunas ACCOUNT_NAME e ACCOUNT_NUMBER da tabela estão protegidas pela política de mascaramento baseada em tags chamando a função de tabela POLICY_REFERENCES do Information Schema.

   Para cada coluna protegida, a linha no resultado da consulta deve especificar os valores apropriados para o nome da coluna, nome da política e nome da tag.

   SELECT *
   FROM TABLE(
    governance.INFORMATION_SCHEMA.POLICY_REFERENCES(
      REF_ENTITY_DOMAIN => 'TABLE',
      REF_ENTITY_NAME => 'finance.accounting.name_number'
      )
   );
   

   Copy

   Retorna (note as colunas atualizadas):

   ------------+----------------+--------------------------------+----------------+-------------------+-----------------+-----------------+-------------------+-----------------+----------------------+--------------+------------+-----------------------+---------------+
    POLICY_DB  | POLICY_SCHEMA  | POLICY_NAME                    |  POLICY_KIND   | REF_DATABASE_NAME | REF_SCHEMA_NAME | REF_ENTITY_NAME | REF_ENTITY_DOMAIN | REF_COLUMN_NAME | REF_ARG_COLUMN_NAMES | TAG_DATABASE | TAG_SCHEMA | TAG_NAME              | POLICY_STATUS |
   ------------+----------------+--------------------------------+----------------+-------------------+-----------------+-----------------+-------------------+-----------------+----------------------+--------------+------------+-----------------------+---------------+
    GOVERNANCE | MASKING_POLICY | ACCOUNT_NAME_MASK_TAG_STRING   | MASKING_POLICY | FINANCE           | ACCOUNTING      | NAME_NUMBER     | TABLE             | ACCOUNT_NAME    | NULL                 | GOVERNANCE   | TAGS       | ACCOUNTING_COL_STRING | ACTIVE        |
    GOVERNANCE | MASKING_POLICY | ACCOUNT_NUMBER_MASK_TAG_STRING | MASKING_POLICY | FINANCE           | ACCOUNTING      | NAME_NUMBER     | TABLE             | ACCOUNT_NUMBER  | NULL                 | GOVERNANCE   | TAGS       | ACCOUNTING_COL_STRING | ACTIVE        |
   ------------+----------------+--------------------------------+----------------+-------------------+-----------------+-----------------+-------------------+-----------------+----------------------+--------------+------------+-----------------------+---------------+
   

6. Consulte as colunas da tabela para garantir que o Snowflake retorne o resultado da consulta correto, que deve mascarar apenas o valor na coluna ACCOUNT_NUMBER.

   USE ROLE accounting_admin;
   SELECT * FROM finance.accounting.name_number;
   

   Copy

   Retorna:

   ---------------+----------------+
     ACCOUNT_NAME | ACCOUNT_NUMBER |
   ---------------+----------------+
     ACME         | -1             |
   ---------------+----------------+
   

Exemplo 3: proteção de uma tabela com base no valor da cadeia de caracteres da tag da tabela¶

Este exemplo usa uma política de acesso a linhas para proteger uma tabela baseada em um valor de cadeia de caracteres da tag atribuído à tabela e uma política de mascaramento baseada em tags para proteger as colunas na tabela. Para simplificar, este exemplo usa uma tag, atribui as políticas de mascaramento à tag, e atribui a tag à tabela. As colunas na tabela terão automaticamente a mesma tag e seu valor de cadeia de caracteres por causa da linhagem de tags.

A política de acesso a linhas avalia dinamicamente o valor da cadeia de caracteres da tag atribuído à tabela chamando a função SYSTEM$GET_TAG_ON_CURRENT_TABLE nas condições da política de acesso a linhas. Como no exemplo anterior, as condições da política de mascaramento chamam a função SYSTEM$GET_TAG_ON_CURRENT_COLUMN para avaliar o valor da cadeia de caracteres da tag nas colunas da tabela.

A tabela finance.accounting.name_number tem duas colunas, que têm os tipos de dados STRING e NUMBER:

---------------+----------------+
  ACCOUNT_NAME | ACCOUNT_NUMBER |
---------------+----------------+
  ACME         | 1000           |
---------------+----------------+

Proteja a tabela e suas colunas com uma política de acesso a linhas e uma política de mascaramento baseada em tags como segue:

1. Crie uma política de acesso a linhas que chame a função SYSTEM$GET_TAG_ON_CURRENT_TABLE nas condições da política:

   USE ROLE row_access_admin;
   USE SCHEMA governance.row_access_policies;
   
   CREATE ROW ACCESS POLICY rap_tag_value
   AS (account_number number)
   RETURNS BOOLEAN ->
   SYSTEM$GET_TAG_ON_CURRENT_TABLE('tags.accounting_row_string') = 'visible'
   AND
   'accounting_admin' = CURRENT_ROLE();
   

   Copy

   A política especifica que o Snowflake retorne linhas no resultado da consulta somente quando a tag accounting_row_string é atribuída à tabela com um valor de cadeia de caracteres 'visible' e a função que executa a consulta na tabela ou suas colunas é a função personalizada accounting_admin.

   O Snowflake não retorna linhas no resultado da consulta se qualquer um dos itens a seguir for verdadeiro:

   • A tag accounting_row_string não está definida na tabela.

   • A tag accounting_row_string está definida na tabela, mas com um valor de cadeia de caracteres diferente.

   • A função que executa uma consulta na tabela ou em suas colunas não é a função personalizada accounting_admin.

2. Atribua a política de acesso a linhas à tabela:

   ALTER TABLE finance.accounting.name_number
     ADD ROW ACCESS POLICY rap_tag_value ON (account_number);
   

   Copy

   Observe que neste ponto do procedimento, uma consulta na tabela não pode retornar quaisquer linhas no resultado da consulta para qualquer função no Snowflake porque a tag accounting_row_string não está atribuída à tabela. Portanto, o resultado esperado de uma consulta na tabela precisa ser:

   USE ROLE accounting_admin;
   SELECT * FROM finance.accounting.name_number;
   

   Copy

   Retorna:

   ---------------+----------------+
     ACCOUNT_NAME | ACCOUNT_NUMBER |
   ---------------+----------------+
                  |                |
   ---------------+----------------+
   

   Ao optar por atribuir a política de acesso a linhas à tabela antes de atribuir a política de mascaramento baseada em tags à tabela, todos os dados da tabela são protegidos o mais cedo possível.

3. Crie uma tag chamada accounting_row_string no esquema chamado governance.tags.

   USE ROLE tag_admin;
   USE SCHEMA governance.tags;
   CREATE TAG accounting_row_string;
   

   Copy

4. Crie diferentes políticas de mascaramento para proteger as colunas ACCOUNT_NAME e ACCOUNT_NUMBER. Em cada uma destas políticas, os dados brutos são visíveis somente quando o valor atual da cadeia de caracteres da tag na coluna é definido como 'visible'.

   Política de nome de conta:

   USE ROLE masking_admin;
   USE SCHEMA governance.masking_policies;
   
   CREATE MASKING POLICY account_name_mask AS (val string) RETURNS string ->
     CASE
       WHEN SYSTEM$GET_TAG_ON_CURRENT_COLUMN('tags.accounting_row_string') = 'visible' THEN val
       ELSE '***MASKED***'
     END;
   

   Copy

   Política de número de conta:

   CREATE MASKING POLICY account_number_mask AS (val number) RETURNS number ->
     CASE
       WHEN SYSTEM$GET_TAG_ON_CURRENT_COLUMN('tags.accounting_row_string') = 'visible' THEN val
       ELSE -1
     END;
   

   Copy

5. Atribua ambas as políticas de mascaramento à tag accounting_row_string. Observe que ambas as políticas podem ser atribuídas à tag em uma única instrução.

   ALTER TAG governance.tags.accounting_row_string SET
     MASKING POLICY account_name_mask,
     MASKING POLICY account_number_mask;
   

   Copy

6. Atribua a tag accounting_row_string à tabela com o valor da cadeia de caracteres da tag 'visible':

   ALTER TABLE finance.accounting.name_number
     SET TAG governance.tags.accounting_row_string = 'visible';
   

   Copy

   Agora que a tag está atribuída à tabela com um valor de cadeia de caracteres de visible, somente a função personalizada accounting_admin pode visualizar os dados da tabela; uma consulta feita por um usuário com qualquer outra função não pode resultar em retorno de linhas, como mostrado anteriormente neste exemplo. Em outras palavras, as condições da política de acesso a linhas agora são avaliadas como verdadeiras.

   Da mesma forma, as colunas da tabela também têm o valor de cadeia de caracteres da tag de visible porque as colunas herdam a tag e seu valor de cadeia de caracteres através da linhagem da tag. O resultado é que quando um usuário com a função personalizada accounting_admin consulta a tabela, o Snowflake retorna dados não mascarados:

   USE ROLE accounting_admin;
   SELECT * FROM finance.accounting.name_number;
   

   Copy

   Retorna:

   ---------------+----------------+
     ACCOUNT_NAME | ACCOUNT_NUMBER |
   ---------------+----------------+
     ACME         | 1000           |
   ---------------+----------------+
   

7. Para mascarar dados em uma das colunas, atualize diretamente o valor da cadeia de caracteres da tag para a coluna. Por exemplo, para mascarar os dados na coluna ACCOUNT_NUMBER:

   ALTER TABLE finance.accounting.name_number MODIFY COLUMN
     account_number SET TAG governance.tags.accounting_row_string = 'protect';
   

   Copy

   Agora, quando um usuário com a função personalizada accounting_admin consulta a tabela ou a coluna ACCOUNT_NUMBER, o Snowflake retorna dados mascarados:

   USE ROLE accounting_admin;
   SELECT * FROM finance.accounting.name_number;
   

   Copy

   Retorna:

   ---------------+----------------+
     ACCOUNT_NAME | ACCOUNT_NUMBER |
   ---------------+----------------+
     ACME         | -1             |
   ---------------+----------------+