Políticas de mascaramento baseadas em tags

Este tópico fornece conceitos sobre políticas de mascaramento baseadas em tags e exemplos relacionados para proteção de dados de coluna.

Neste tópico:

Visão geral

Uma política de mascaramento baseada em tags combina recursos de marcação de objetos e política de mascaramento para permitir que uma política de mascaramento seja definida em uma tag usando um comando ALTER TAG. Quando o tipo de dados na assinatura da política de mascaramento e o tipo de dados da coluna correspondem, a coluna marcada é automaticamente protegida pelas condições da política de mascaramento. Isto simplifica os esforços de proteção de dados porque os dados da coluna que devem ser protegidos não precisam mais de uma política de mascaramento aplicada manualmente à coluna para proteger os dados. Você pode definir uma política de mascaramento baseada em tag em um banco de dados, esquema ou tabela.

A tag pode oferecer suporte a uma política de mascaramento para cada tipo de dado para que o Snowflake oferece suporte. Para simplificar os esforços de proteção de dados da coluna inicial, crie uma política de mascaramento genérica para cada tipo de dado (por exemplo, STRING, NUMBER, TIMESTAMP_LTZ) que permita às funções autorizadas ver os dados brutos e às funções não autorizadas ver um valor mascarado fixo.

As condições da política de mascaramento podem ser escritas para proteger os dados da coluna com base na política atribuída à tag ou para proteger os dados da coluna com base no valor da cadeia de caracteres da tag atribuída à coluna, dependendo das decisões do administrador da política, do administrador da tag e do administrador de dados.

Como escolher um banco de dados, esquema ou tabela para atribuir a política

Engenheiros de dados e administradores de dados podem optar por atribuir a política de mascaramento baseada em tags a um banco de dados, esquema, tabela ou coluna.

Banco de dados e esquema

Ao definir uma política de mascaramento baseada em tags em um banco de dados ou esquema, você aproveita a linhagem de tag para proteger tabelas e exibir colunas no esquema ou banco de dados. Definir uma política de mascaramento baseada em tags no banco de dados ou esquema protege as colunas nesse banco de dados ou esquema quando o tipo de dados da coluna corresponder ao tipo de dados da política de mascaramento definida na tag.

O principal benefício de definir a política de mascaramento baseada em tags no banco de dados ou esquema é que as colunas em todas as tabelas e exibições recém-adicionadas são automaticamente protegidas quando o tipo de dados da coluna corresponde ao tipo de dados da política de mascaramento. Essa abordagem simplifica o gerenciamento da proteção de dados porque não é mais necessário definir tags em todas as tabelas. O resultado é que a política protege novos dados no Snowflake até que um responsável pela proteção de dados decida atribuir uma política de mascaramento diretamente à coluna ou uma política de acesso a linhas à tabela ou exibição.

Tabelas

Quando você define uma política de mascaramento baseada em tags em uma tabela, a tag é definida em todas as colunas da tabela. A política de mascaramento protege os dados da coluna quando o tipo de dados da coluna corresponde ao tipo de dados da política de mascaramento.

Uma coluna pode ser protegida por uma política de mascaramento diretamente atribuída à coluna e por uma política de mascaramento baseada em tags. Se uma coluna faz referência a essas duas políticas de mascaramento, a política de mascaramento que é diretamente atribuída à coluna tem precedência sobre a política de mascaramento baseada em tags.

Para exemplos de políticas de mascaramento baseadas em tags, consulte a seção Uso de políticas de mascaramento baseadas em tags (neste tópico).

Benefícios

Facilidade de uso

Atribuir uma ou mais políticas de mascaramento a uma tag é simples. Os administradores de políticas podem adicionar ou substituir políticas sem interromper os fluxos de trabalho existentes.

Escalável

Políticas baseadas em tags permitem aos administradores de políticas escrever uma política uma vez, atribuir uma política a uma tag uma vez, e, dependendo do nível no qual a tag é definida, ter a política aplicada a muitos objetos. Isto resulta na vasta redução da atribuição manual de uma única política a uma única coluna toda vez que uma nova coluna é criada ou substituída.

Abrangente

Os administradores de políticas podem criar uma política para cada tipo de dado e atribuir todas essas políticas a uma única tag. Uma vez que a tag é aplicada no nível da tabela, todas as colunas da tabela são protegidas, desde que o tipo de dados da coluna corresponda ao tipo de dados especificado na política.

Proteção de objetos futuros

A atribuição de uma política de mascaramento baseada em tags a uma tabela aplica automaticamente a política de mascaramento a qualquer nova coluna da tabela. Este comportamento é análogo a concessões futuras.

Flexibilidade

As políticas de mascaramento baseadas em tags oferecem uma alternativa para especificar a política de mascaramento em uma instrução CREATE TABLE, o que ajuda a simplificar o gerenciamento do DDL da tabela. Os administradores podem escolher atribuir a política de mascaramento na criação da tabela ou atribuindo a política à tag, o que usa a linhagem de tags.

Considerações

  • Para uma política de mascaramento baseada em tags em que a tag é armazenada em um esquema diferente da política de mascaramento e da tabela, a clonagem do esquema contendo a política de mascaramento e tabela resulta na tabela clonada sendo protegida pela política de mascaramento no esquema de origem, não no esquema clonado.

    No entanto, para uma política de mascaramento baseada em tags em que a tag, a política de mascaramento e a tabela existem no esquema, a clonagem do esquema resulta na proteção da tabela pela política de mascaramento no esquema clonado, não no esquema de origem.

    Se a tabela for clonada ou movida para um esquema ou banco de dados diferente e tiver sido originalmente protegida por uma política de mascaramento baseada em tags definida no esquema ou banco de dados, a tabela não será protegida pela política de mascaramento baseada em tags definida no esquema ou banco de dados de origem. A tabela é protegida pela política de mascaramento baseada em tags definida no esquema ou banco de dados de destino, se houver uma política de mascaramento baseada em tags definida no esquema ou banco de dados de destino.

  • Com relação a políticas de mascaramento baseadas em replicação e tags, consulte considerações sobre a replicação de políticas.

  • Para obter mais detalhes sobre Secure Data Sharing e este recurso, consulte:

Limitações

Todas as limitações a políticas de mascaramento existentes aplicam-se a políticas de mascaramento baseadas em tags.

Observe as seguintes limitações adicionais ao usar políticas de mascaramento baseadas em tags:

Tipos de dados

Uma tag pode oferecer suporte a uma política de mascaramento para cada tipo de dados. Por exemplo, se uma tag já tem uma política de mascaramento para o tipo de dados NUMBER, você não pode atribuir outra política de mascaramento com o tipo de dados NUMBER à mesma tag.

Tags de sistema

Uma política de mascaramento não pode ser atribuída a uma tag do sistema.

Descarte de objetos

Nem a política de mascaramento nem a tag podem ser descartadas se a política de mascaramento for atribuída a uma tag. Da mesma forma, o esquema pai e o banco de dados contendo a tag e a política de mascaramento não podem ser descartados se a política for atribuída a uma tag. Para obter mais informações, consulte Atribuição de um política de mascaramento a uma tag (neste tópico).

Exibições materializadas

Uma exibição materializada não pode ser criada se a tabela subjacente estiver protegida por uma política de mascaramento baseada em tags. Para detalhes adicionais, consulte políticas de mascaramentos e exibições materializadas.

Se existir uma exibição materializada e uma política de mascaramento baseada em tags for adicionada à tabela subjacente mais tarde, a exibição materializada não poderá ser consultada e estará invalidada. Para continuar usando a exibição materializada, remova a política de mascaramento baseada em tags, recrie ou retome e depois consulte a exibição materializada.

Políticas de acesso a linhas

Uma determinada coluna de tabela ou exibição pode ser especificada em uma assinatura de política de mascaramento ou em uma assinatura de política de acesso a linhas. Em outras palavras, a mesma coluna não pode ser especificada tanto em uma assinatura de política de mascaramento quanto em uma assinatura de política de acesso a linhas ao mesmo tempo.

Colunas condicionais

Uma coluna mascarada não pode ser usada como coluna condicional em uma política de mascaramento.

Tabelas de mapeamento

Uma tabela contendo uma coluna protegida por uma política de mascaramento baseada em tags não pode ser usada como uma tabela de mapeamento.

Gerenciamento de políticas de mascaramento baseadas em tags

Os privilégios existentes para políticas de mascaramento e tags, juntamente com os comandos para gerenciar políticas de mascaramento e tags, aplicam-se às 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:

Dica

Para evitar conflitos com tags e políticas de mascaramento ao definir uma política de mascaramento baseada em tags em um esquema ou banco de dados, antes de atribuir a política de mascaramento baseada em tags:

  • Consulte a exibição TAG_REFERENCES do Account Usage para verificar as tags existentes definidas em uma tabela ou coluna em uma tabela.

  • Consulte a exibição POLICY_REFERENCES do Account Usage para determinar se uma política de mascaramento baseada em tags está definida em uma tabela ou coluna. Para obter mais detalhes, consulte Descoberta de tags e políticas.

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:

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:

Uso de políticas de mascaramento baseadas em tags

As subseções abaixo fornecem as seguintes informações:

  • Um procedimento comum a ser usado com políticas de mascaramento baseadas em tags para proteção e validação de dados.

  • Pré-requisitos a serem cumpridos antes da implementação de políticas de mascaramento baseadas em tags.

  • Uma lista de premissas comuns para os exemplos.

  • Exemplos representativos do uso de políticas de mascaramento baseadas em tags, incluindo o uso das seguintes funções do sistema:

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.

Importante

Note que você não pode atribuir uma política de acesso a linhas à tag.

Em vez disso, atribua a política de acesso a linhas diretamente à tabela usando um comando ALTER TABLE.

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

Solução de problemas de políticas de mascaramento baseadas em tags

A tabela a seguir lista algumas mensagens de erro que o Snowflake pode retornar ao usar políticas de mascaramento baseadas em tags:

Comportamento

Mensagem de erro

Ação de solução de problemas

Não é possível consultar uma coluna: excesso de políticas.

SQL execution error: Column <col_name> is mapped to multiple masking policies by tags.Please contact your local administrator to fix the issue.

Uma determinada coluna pode ser protegida por apenas uma política de mascaramento.

Chame a função POLICY_REFERENCES para identificar as políticas de mascaramento definidas para a coluna. Modifique as tags removendo a política de mascaramento da tag de modo que a coluna fique protegida por uma única política.

Não é possível consultar uma coluna: não há coluna condicional.

SQL execution error: Column <col_name> is mapped to a masking policy where the table doesnt have acolumn for a secondary argument name of the policy.Please contact your local administrator to fix the issue.

Uma política de mascaramento que utilize argumentos condicionais deve ter todas as colunas especificadas na mesma tabela ou exibição. Execute uma das seguintes ações para proteger os dados da coluna:

  • Atribua uma política diferente à coluna diretamente.

  • Modifique a tag atribuindo uma política de mascaramento diferente à tag.

Os dados da coluna não são mascarados devido à diferença entre o tipo de dados da coluna e da política.

SQL execution error: Column <col_name> is mapped to a masking policy where the table has a column with different data-type for a secondary argument name. Please contact your local administrator to fix the issue.

Para mascarar os dados da coluna, o tipo de dados para a coluna e o tipo de dados na assinatura da política de mascaramento devem corresponder. Execute uma das seguintes ações para proteger os dados da coluna:

  • Atribua uma política diferente à coluna diretamente.

  • Atribua uma política de mascaramento à tag, certificando-se de que o tipo de dados para a política e o tipo de dados para a coluna correspondem.