Explicação da segurança em nível de coluna

Este tópico fornece uma visão geral da segurança em nível de coluna e descreve os recursos e o suporte que são comuns ao mascaramento dinâmico de dados e à tokenização externa.

Para saber mais sobre o uso de uma política de mascaramento com uma tag, consulte Políticas de mascaramento baseadas em tags.

O que é a segurança em nível de coluna?

A segurança em nível de coluna no Snowflake permite a aplicação de uma política de mascaramento a uma coluna de uma tabela ou exibição. Atualmente, a segurança em nível de coluna inclui dois recursos:

  1. Mascaramento de dados dinâmico

  2. Tokenização externa

O mascaramento dinâmico de dados é um recurso de segurança em nível de coluna que usa políticas de mascaramento para ocultar seletivamente dados de texto sem formatação na tabela e exibir colunas no momento da consulta.

A tokenização externa permite que as contas tokenizem os dados antes de carregá-los no Snowflake e destokenizem os dados no tempo de execução da consulta. A tokenização é o processo de remoção de dados confidenciais, substituindo-os por um token indecifrável. A tokenização externa usa políticas de mascaramento com funções externas.

O que são políticas de mascaramento?

O Snowflake utiliza políticas de mascaramento como um objeto em nível de esquema para proteger dados confidenciais contra o acesso não autorizado, enquanto permite que usuários autorizados acessem dados confidenciais no tempo de execução da consulta. Isso significa que os dados confidenciais no Snowflake não são modificados em uma tabela existente (ou seja, não há mascaramento estático). Ao contrário, quando os usuários executam uma consulta na qual se aplica uma política de mascaramento, as condições da política de mascaramento determinam se usuários não autorizados veem dados mascarados, parcialmente mascarados, ocultados ou tokenizados. Políticas de mascaramento como um objeto em nível de esquema também proporcionam flexibilidade na escolha de uma abordagem de gerenciamento centralizada, descentralizada ou híbrida. Para obter mais informações, consulte Gerenciamento da segurança em nível de coluna (neste tópico).

As políticas de mascaramento podem incluir condições e funções para transformar os dados no tempo de execução da consulta quando essas condições forem atendidas. A abordagem orientada por políticas oferece suporte à segregação de tarefas para permitir que as equipes de segurança definam políticas que possam limitar a exposição de dados confidenciais, mesmo para o proprietário de um objeto (ou seja, a função com o privilégio OWNERSHIP para o objeto, como uma tabela ou exibição) que normalmente tem pleno acesso aos dados subjacentes.

O administrador da política de mascaramento pode aplicar políticas de mascaramento a tabelas e exibições.

Por exemplo, os administradores de políticas de mascaramento podem implementar uma política de mascaramento de forma que analistas (ou seja, usuários com a função personalizada ANALYST) só possam visualizar os últimos quatro dígitos de um número de telefone e nenhum dígito do número da previdência social, enquanto representantes de atendimento ao cliente (ou seja, usuários com a função personalizada SUPPORT) podem visualizar todo o número de telefone e o número da previdência social para casos de uso de verificação do cliente.

Resultados da política de mascaramento para funções autorizadas e não autorizadas.

Uma política de mascaramento consiste em um único tipo de dados, uma ou mais condições e uma ou mais funções de mascaramento.

Embora o Snowflake ofereça exibições seguras para restringir o acesso a dados confidenciais, elas apresentam desafios de gerenciamento devido ao grande número de exibições e painéis de business intelligence (BI) derivados de cada exibição. As políticas de mascaramento resolvem este desafio de gerenciamento, evitando uma explosão de exibições e painéis para gerenciar.

As políticas de mascaramento aceitam a segregação de tarefas (SoD) através da separação de funções dos administradores de políticas dos proprietários de objetos. Exibições seguras não têm SoD, o que é uma profunda limitação à sua utilidade. Esta separação de funções leva às seguintes configurações padrão:

  • Os proprietários de objetos (ou seja, a função que tem o privilégio OWNERSHIP sobre o objeto) não têm o privilégio de remover políticas de mascaramento.

  • Os proprietários de objetos não podem visualizar os dados de coluna aos quais se aplica uma política de mascaramento.

Para obter mais informações sobre o gerenciamento de funções e privilégios, consulte Gerenciamento da segurança em nível de coluna (neste tópico) e Privilégios de controle de acesso.

Como funciona uma política de mascaramento?

As políticas de mascaramento para mascaramento dinâmico de dados e tokenização externa adotam a mesma estrutura e formato, com uma notável exceção: as políticas de mascaramento para tokenização externa requerem o uso de Como escrever funções externas no corpo da política de mascaramento.

A razão para esta exceção é que a tokenização externa exige que um provedor de tokenização terceiro tokenize os dados antes de carregá-los no Snowflake. No tempo de execução da consulta, o Snowflake usa a função externa para fazer uma chamada REST API ao provedor de tokenização, que então avalia uma política de tokenização (que é criada fora do Snowflake) para retornar dados tokenizados ou destokenizados com base nas condições da política de mascaramento. Observe que deve haver um mapeamento de funções no Snowflake e no provedor de tokenização para garantir que os dados corretos possam ser retornados de uma determinada consulta.

O Snowflake aceita a criação de políticas de mascaramento usando CREATE MASKING POLICY. Por exemplo:

-- Dynamic Data Masking

CREATE MASKING POLICY employee_ssn_mask AS (val string) RETURNS string ->
  CASE
    WHEN CURRENT_ROLE() IN ('PAYROLL') THEN val
    ELSE '******'
  END;

-- External Tokenization

  CREATE MASKING POLICY employee_ssn_detokenize AS (val string) RETURNS string ->
  CASE
    WHEN CURRENT_ROLE() IN ('PAYROLL') THEN ssn_unprotect(VAL)
    ELSE val -- sees tokenized data
  END;
Copy

Onde:

employee_ssn_mask

O nome da política de mascaramento dinâmico de dados.

employee_ssn_detokenize

O nome da política de tokenização externa.

AS (val string) RETURNS string

Especifica os tipos de dados de entrada e saída. Os tipos de dados devem corresponder.

->

Separa a assinatura da política de seu corpo.

case ... end;

Especifica as condições do corpo da política de mascaramento (ou seja, expressão SQL).

Nestes dois exemplos, se o operador de consulta estiver usando a função PAYROLL personalizada na sessão atual, verá o valor não mascarado/destokenizado. Caso contrário, verá um valor fixo mascarado/tokenizado.

ssn_unprotect

A função externa a operar nos dados tokenizados.

Dica

Se você quiser atualizar uma política de mascaramento existente e precisar ver a definição atual da política, chame a função GET_DDL ou execute o comando DESCRIBE MASKING POLICY.

A definição da política de mascaramento pode então ser atualizada com o comando ALTER MASKING POLICY. Este comando não requer a remoção de uma política de mascaramento de uma coluna, se a política estiver definida. Portanto, uma coluna que esteja protegida por uma política permanece protegida enquanto a definição da política estiver sendo atualizada.

Para obter mais detalhes sobre o uso de políticas de mascaramento, consulte:

Uso de colunas condicionais

O mascaramento condicional usa uma política de mascaramento para proteger seletivamente os dados da coluna em uma tabela ou exibição com base nos valores em uma ou mais colunas diferentes.

Usar uma coluna diferente para determinar se os dados em uma determinada coluna devem ser protegidos oferece aos administradores de políticas (ou seja, usuários com a função POLICY_ADMIN personalizada) mais liberdade para criar condições de políticas.

Observe a diferença entre os dois exemplos representativos de políticas:

Política de mascaramento:

Esta política pode ser usada para o mascaramento dinâmicos de dados.

CREATE MASKING POLICY email_mask AS
(val string) RETURNS string ->
  CASE
    WHEN CURRENT_ROLE() IN ('PAYROLL') THEN val
    ELSE '******'
  END;
Copy

Esta política especifica apenas um argumento, val, que representa qualquer coluna que contenha dados de cadeia de caracteres. Esta política pode ser criada uma vez e aplicada a qualquer coluna que contenha dados de cadeia de caracteres. Somente usuários cuja função CURRENT_ROLE seja a função PAYROLL personalizada podem ver os dados da coluna. Caso contrário, o Snowflake retorna um valor mascarado fixo no resultado da consulta.

Para obter mais informações, consulte CREATE MASKING POLICY.

Política de mascaramento condicional:

Observe os argumentos, (email varchar, visibility string), neste exemplo.

CREATE MASKING POLICY email_visibility AS
(email varchar, visibility string) RETURNS varchar ->
  CASE
    WHEN CURRENT_ROLE() = 'ADMIN' THEN email
    WHEN VISIBILITY = 'PUBLIC' THEN email
    ELSE '***MASKED***'
  END;
Copy

Esta política especifica dois argumentos, email e visibility, e esses argumentos são nomes de colunas. A primeira coluna sempre especifica a coluna a ser mascarada. A segunda é uma coluna condicional para avaliar se a primeira coluna deve ser mascarada. Podem ser especificadas várias colunas condicionais. Nesta política, os usuários cuja CURRENT_ROLE seja a função ADMIN personalizada podem visualizar o endereço de e-mail. Se o endereço de e-mail também tiver um valor de coluna de visibilidade de Public, então o endereço de e-mail será visível no resultado da consulta. Caso contrário, o Snowflake retornará um resultado de consulta com um valor mascarado fixo para a coluna de e-mail.

Esta política pode ser usada em várias tabelas e exibições desde que a estrutura da coluna na tabela ou exibição corresponda às colunas especificadas na política. Para obter mais informações, consulte CREATE MASKING POLICY.

Como o mesmo tipo de objeto é usado para cada exemplo representativo, o comportamento geral das políticas deve ser semelhante, incluindo, entre outros:

  • Avaliação no tempo de execução da consulta.

  • Utilidade (por exemplo, proteção de dados confidenciais, uso de Funções de contexto).

  • Estrutura de privilégios.

  • Uso com diferentes abordagens de gerenciamento para permitir a segregação de tarefas (SoD).

Limitações:

Além das limitações de política de mascaramento existentes, as políticas de mascaramento condicionais têm as seguintes limitações:

Considerações:

Além das considerações de políticas de mascaramento normais existentes, avalie os pontos a seguir antes de usar políticas de mascaramento condicionais:

  • Certifique-se de que todas as colunas especificadas na instrução CREATE MASKING POLICY residam na mesma tabela ou exibição.

  • Minimize o número de argumentos de coluna na definição da política. O Snowflake deve avaliar cada coluna no tempo de execução da consulta. A especificação de menos colunas leva a um desempenho geral mais rápido.

  • Rastreie o uso de colunas condicionais em uma política de mascaramento chamando a função da tabela Information Schema POLICY_REFERENCES.

Para obter mais detalhes sobre a definição de políticas de mascaramento com colunas condicionais, consulte Aplicação de uma política de mascaramento condicional em uma coluna (neste tópico).

Políticas de mascaramento no tempo de execução da consulta

No tempo de execução, o Snowflake regrava a consulta para aplicar a expressão da política de mascaramento às colunas especificadas na política. A política de mascaramento é aplicada à coluna independentemente de onde em uma expressão SQL a coluna é referenciada, inclusive:

  • Projeções.

  • Predicados JOIN.

  • Predicados de cláusula WHERE.

  • Cláusulas ORDER BY e GROUP BY.

Importante

Uma política de mascaramento é deliberadamente aplicada onde quer que a coluna relevante seja referenciada por uma construção SQL para evitar a desanonimização dos dados através de consultas criativas para incluir dados de colunas mascaradas.

Portanto, se a execução de uma consulta resultar em dados mascarados em uma ou mais colunas, a saída da consulta pode não fornecer o valor previsto porque os dados mascarados impedem a avaliação de todos os dados de saída da consulta no contexto desejado.

Políticas de mascaramento com objetos aninhados:

O Snowflake aceita políticas de mascaramento aninhadas, como uma política de mascaramento em uma tabela e uma política de mascaramento em uma exibição para a mesma tabela. No tempo de execução da consulta, o Snowflake avalia todas as políticas de mascaramento que são relevantes para uma determinada consulta na sequência a seguir:

  1. A política de mascaramento aplicável à tabela é sempre executada em primeiro lugar.

  2. A política para a exibição é executada após a avaliação da política para a tabela.

  3. Se existirem exibições aninhadas (por exemplo, table_1 » view_1 » view_2 » … view_n), as políticas serão aplicadas em ordem sequencial, da esquerda para a direita.

Este padrão continua por todas as políticas de mascaramento que houver em relação aos dados da consulta. O diagrama a seguir ilustra a relação entre um executor de consultas, tabelas, exibições e políticas.

Políticas de mascaramento com tabelas e exibições.

Consultas do usuário:

O exemplo a seguir mostra uma consulta submetida pelo usuário seguida pela regravação da consulta no tempo de execução pelo Snowflake, na qual a política de mascaramento (ou seja, sql_expression) se aplica somente à coluna email.

SELECT email, city
FROM customers
WHERE city = 'San Mateo';

SELECT <SQL_expression>(email), city
FROM customers
WHERE city = 'San Mateo';
Copy

Consulta com uma coluna protegida no predicado de cláusula WHERE (antipadrão):

Os exemplos a seguir mostram uma consulta enviada pelo usuário seguida da regravação pelo Snowflake da consulta no tempo de execução na qual a política de mascaramento (ou seja, sql_expression) se aplica somente a um lado de uma comparação (por exemplo, a coluna de e-mail, mas não a cadeia de caracteres com a qual a coluna de e-mail é comparada). Os resultados da consulta não são o que o usuário pretendia. Mascarar apenas um lado de uma comparação é um antipadrão comum.

SELECT email
FROM customers
WHERE email = 'user@example.com';

SELECT <SQL_expression>(email)
FROM customers
WHERE <SQL_expression>(email) = 'user@example.com';
Copy

Consulta com uma coluna protegida no predicado JOIN (antipadrão):

SELECT b.email, d.city
FROM
  sf_tuts.public.emp_basic AS b
  JOIN sf_tuts.public.emp_details AS d ON b.email = d.email;

SELECT
  <SQL_expression>(b.email),
  d.city
FROM
  sf_tuts.public.emp_basic AS b
  JOIN sf_tuts.public.emp_details AS d ON <SQL_expression>(b.email) = <SQL_expression>(d.email);
Copy

Considerações sobre o tempo de execução da consulta

O Snowflake recomenda considerar os seguintes fatores ao tentar prever o efeito da aplicação de uma política de mascaramento a uma coluna e se o operador da consulta vê dados mascarados:

A sessão atual:

Condições da política de mascaramento usando CURRENT_ROLE.

A função de execução:

Condições da política de mascaramento usando INVOKER_ROLE.

Hierarquia das funções:

Condições da política de mascaramento usando IS_ROLE_IN_SESSION ou IS_GRANTED_TO_INVOKER_ROLE.

Data Sharing:

Se os dados são compartilhados usando o Secure Data Sharing. Para obter mais detalhes, consulte Data Sharing (neste tópico).

Replicação:

Consulte Replicação (neste tópico).

Subconsultas:

Uma política de mascaramento pode fazer referência a uma subconsulta na definição da política; no entanto, há limites para o suporte a subconsultas no Snowflake. Para obter mais informações, consulte Como trabalhar com subconsultas.

UDFs em uma política de mascaramento:

Certifique-se de que o tipo de dados da coluna, UDF, e a política de mascaramento coincidam. Para obter mais informações, consulte Funções definidas pelo usuário em uma política de mascaramento (neste tópico).

Serviço de otimização de pesquisa:

O serviço de otimização de pesquisa pode melhorar o desempenho da consulta em uma tabela que utiliza uma política de mascaramento ou de acesso a linhas.

Para obter mais detalhes, consulte Suporte para tabelas com políticas de mascaramento e políticas de acesso a linhas no serviço de otimização de pesquisa.

Os três primeiros itens são explicados com mais detalhes em Tópicos avançados de segurança em nível de coluna. O compartilhamento de dados só se aplica ao mascaramento dinâmico de dados porque funções externas não podem ser chamadas no contexto de um compartilhamento.

Em última análise, o caso de uso específico determina se o mascaramento dinâmico de dados ou a tokenização externa é o mais adequado.

Escolha de mascaramento dinâmico de dados ou tokenização externa

Para escolher o recurso correto que melhor atenda às necessidades de sua organização, avalie os principais casos de uso de seus dados, juntamente com considerações e limitações relevantes. As duas seções a seguir resumem os benefícios e limitações dos dois recursos.

Benefícios

A tabela a seguir compara os benefícios do mascaramento dinâmico de dados e da tokenização externa.

Fator

Mascaramento dinâmico de dados

Tokenização externa

Notas

Preservar o valor analítico após a desidentificação.

Como a tokenização fornece um valor único para um determinado conjunto de caracteres, é possível agrupar os registros por um valor tokenizado sem revelar as informações confidenciais.

Por exemplo, prontuários médicos de grupo por código de diagnóstico com o código de diagnóstico do paciente tokenizado. Os analistas de dados podem então consultar uma exibição do código de diagnóstico para obter uma contagem do número de pacientes com um código de diagnóstico único.

Pré-carregamento de dados tokenizados.

Usuários não autorizados nunca veem o valor real dos dados. Requer um provedor de tokenização terceiro.

Pré-carregamento de dados não mascarados.

Só precisa da funcionalidade integrada do Snowflake, sem necessidade de terceiros.

Data Sharing.

Para obter mais detalhes, consulte Data Sharing (neste tópico).

Facilidade de uso e gerenciamento de alterações.

Grave uma política uma vez e faça com que ela seja aplicada a milhares de colunas em bancos de dados e esquemas.

Administração de dados e SoD.

Um responsável por segurança ou privacidade, e não o proprietário do objeto, decide quais colunas proteger.

Políticas de mascaramento são fáceis de gerenciar e aceitam modelos de administração centralizados e descentralizados.

Autorização e governança de dados.

Acesso contextual a dados por função ou direitos personalizados.

Compatível com a governança de dados implementada pelos responsáveis pela segurança ou privacidade; pode proibir usuários privilegiados com as funções ACCOUNTADMIN ou SECURITYADMIN do sistema de visualizar dados desnecessariamente.

Replicação de banco de dados e replicação de objeto de conta.

Consulte: Replicação (neste tópico).

Limitações

A tabela a seguir descreve as limitações atuais da segurança em nível de coluna. Uma marca de verificação (ou seja, ✔) indica uma limitação ou ausência de suporte para o recurso.

Limitação

Mascaramento dinâmico de dados

Tokenização externa

Notas

Exibições materializadas (MV).

Para um resumo completo, consulte Exibições materializadas (neste tópico).

DROP MASKING POLICY

Antes de descartar uma política, remova a política da coluna da tabela ou exibição usando ALTER TABLE … ALTER COLUMN ou ALTER VIEW.

DROP DATABASE e DROP SCHEMA

Descartar um banco de dados ou esquema exige que a política de mascaramento e seus mapeamentos estejam autocontidos dentro do banco de dados ou esquema.

Por exemplo, database_1 contém policy_1 e policy_1 só é usada em database_1.

Tabelas externas.

Uma tabela externa não pode ser referenciada como uma tabela de pesquisa (ou seja, em uma subconsulta) para determinar se os valores das colunas devem ser mascarados. Para obter mais informações, consulte Tabelas externas (neste tópico)

Diferentes tipos de dados na entrada e na saída de uma definição de política.

Uma definição de política de mascaramento deve ter o mesmo tipo de dados para a entrada e para a saída. Em outras palavras, como exemplo representativo, não é possível definir o tipo de dados da entrada como um carimbo de data/hora e retornar uma cadeia de caracteres.

Gerenciamento de alterações da política de mascaramento.

Opcionalmente, você pode armazenar e acompanhar as alterações de políticas de mascaramento em um sistema de controle de versões de sua escolha.

Concessões futuras.

Não há suporte para futuras concessões de privilégios em políticas de mascaramento.

Como alternativa, conceda o privilégio APPLY MASKING POLICY a uma função personalizada para permitir que essa função aplique políticas de mascaramento em colunas de tabela ou exibição.

Considerações

  • Tenha cuidado ao inserir valores de uma coluna de origem que tenha uma política de mascaramento na coluna de origem em uma coluna de destino sem uma política de mascaramento na coluna de destino. Como uma política de máscara está definida na coluna de origem, uma função que visualize dados de coluna não mascarado pode inserir dados não mascarados em outra coluna, onde qualquer função com privilégios suficientes na tabela ou exibição poderá ver o valor.

  • Se uma função que vê dados mascarados na coluna de origem insere esses valores em uma coluna de destino, os valores inseridos permanecem mascarados. Se uma política de mascaramento não for definida na coluna de destino, então os usuários com privilégios suficientes na tabela ou exibição podem ver uma combinação de valores mascarados e não mascarados na coluna de destino. Portanto, como uma melhor prática:

    • Tenha cuidado ao aplicar políticas de mascaramento a colunas.

    • Verifique consultas que usam colunas com políticas de mascaramento antes de disponibilizar as tabelas e exibições aos usuários.

    • Determine tabelas e exibições adicionais (ou seja, colunas de destino) onde os dados na coluna de origem podem aparecer.

    • Para obter mais informações, consulte Obtenção de colunas com política de mascaramento (neste tópico).

  • Tenha cuidado ao criar o script de configuração para um Snowflake Native App quando a política de mascaramento existir em um esquema com versão. Para obter detalhes, consulte considerações sobre esquema com versão.

Uso de segurança em nível de coluna em tabelas e exibições

O Snowflake tem suporte para políticas de mascaramento com tabelas e exibições. Abaixo está uma descrição de como as políticas de mascaramento afetam tabelas e exibições no Snowflake.

Dica

Chame a função POLICY_CONTEXT para simular uma consulta em uma coluna que esteja protegida por uma política de mascaramento, uma tabela ou exibição protegida por uma política de acesso a linhas, ou ambos os tipos de políticas.

Hierarquia de funções ativa e tabelas de mapeamento

As condições da política podem avaliar as funções primárias e secundárias ativas do usuário em uma sessão diretamente, procurar as funções ativas em uma tabela de mapeamento, ou fazer ambos dependendo de como o administrador da política quer escrever a política. Se a política contiver uma pesquisa de tabela de mapeamento, crie uma tabela de mapeamento centralizada e armazene-a no mesmo banco de dados que a tabela protegida. Isto é especialmente importante se a política chamar a função IS_DATABASE_ROLE_IN_SESSION. Para obter mais detalhes, consulte a função notas de uso.

Para esses casos de uso, a Snowflake recomenda gravar as condições de política para chamar a função IS_ROLE_IN_SESSION ou IS_DATABASE_ROLE_IN_SESSION dependendo se você deseja especificar uma função de conta ou de banco de dados. Para exemplos, consulte:

Para obter exemplos adicionais usando funções de contexto e políticas de mascaramento, consulte Tópicos avançados de segurança em nível de coluna.

Aplicação de políticas de mascaramento a colunas

Quando uma coluna não é protegida por uma política de mascaramento, há duas opções para aplicar uma política de mascaramento a uma coluna em uma tabela ou exibição:

  1. Com uma nova tabela ou exibição, aplique a política a uma coluna de tabela com uma instrução CREATE TABLE ou uma coluna de exibição com uma instrução CREATE VIEW.

  2. Com uma tabela ou exibição existente, aplique a política a uma coluna de tabela com uma instrução ALTER TABLE … ALTER COLUMN ou uma coluna de exibição com uma instrução ALTER VIEW.

Para uma nova tabela ou exibição, execute as seguintes instruções:

-- table
CREATE OR REPLACE TABLE user_info (ssn string masking policy ssn_mask);

-- view
CREATE OR REPLACE VIEW user_info_v (ssn masking policy ssn_mask_v) AS SELECT * FROM user_info;
Copy

Para uma tabela ou exibição existente, execute as seguintes instruções:

-- table
ALTER TABLE IF EXISTS user_info MODIFY COLUMN ssn_number SET MASKING POLICY ssn_mask;

-- view
ALTER VIEW user_info_v MODIFY COLUMN ssn_number SET MASKING POLICY ssn_mask_v;
Copy

Para obter mais informações sobre sintaxe e uso, consulte ALTER TABLE … ALTER COLUMN e ALTER VIEW.

Se a política de mascaramento usar um UDF, consulte Funções definidas pelo usuário em uma política de mascaramento (neste tópico).

Aplicação de uma política de mascaramento condicional em uma coluna

Depois de criar uma política de mascaramento usando colunas condicionais, há duas opções para definir uma política de mascaramento condicional em uma coluna quando a coluna ainda não está protegida por uma política de mascaramento:

  1. Para uma nova tabela ou exibição, aplique a política a uma coluna de tabela ou exibição com a instrução CREATE correspondente.

    Para obter mais informações sobre sintaxe e uso, consulte:

    Para uma nova tabela ou exibição, execute as seguintes instruções:

    -- table
    CREATE OR REPLACE TABLE user_info (email string masking policy email_visibility) USING (email, visibility);
    
    --view
    CREATE OR REPLACE VIEW user_info_v (email masking policy email_visibility) USING (email, visibility) AS SELECT * FROM user_info;
    
    Copy
  2. Para uma tabela ou exibição existente, defina a política em uma coluna de tabela ou exibição com a instrução ALTER correspondente.

    Para obter mais informações sobre sintaxe e uso, consulte:

    Para uma tabela ou exibição existente, execute as seguintes instruções:

    -- table
    ALTER TABLE IF EXISTS user_info MODIFY COLUMN email
    SET MASKING POLICY email_visibility USING (EMAIL, VISIBILITY);
    
    -- VIEW
    ALTER VIEW user_info_v MODIFY COLUMN email
    SET MASKING POLICY email_visibility USING (email, visibility);
    
    Copy

Substituição de uma política de mascaramento em uma coluna

Uma vez estabelecida uma política de mascaramento em uma coluna, existem dois caminhos diferentes para substituir a política de mascaramento na coluna por uma política de mascaramento diferente sem a necessidade de substituir toda a tabela ou exibição.

Estes exemplos utilizam comandos ALTER TABLE. A mesma abordagem se aplica às exibições com o comando ALTER VIEW:

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

    ALTER TABLE t1 MODIFY COLUMN c1 UNSET MASKING POLICY;
    
    ALTER TABLE t1 MODIFY COLUMN c1 SET MASKING POLICY p2;
    
    Copy
  • Use a palavra-chave FORCE para substituir a política em uma única instrução:

    ALTER TABLE t1 MODIFY COLUMN c1 SET MASKING POLICY p2 FORCE;
    
    Copy

    Nota:

    • A utilização da palavra-chave FORCE exige o tipo de dados da política na instrução ALTER TABLE (isto é, STRING) para corresponder ao tipo de dados da política de mascaramento atualmente definida na coluna (isto é, STRING).

    • A palavra-chave FORCE pode ser combinada com a cláusula USING para definir uma política de mascaramento condicional na coluna:

      ALTER TABLE t1 MODIFY COLUMN c1 SET MASKING POLICY policy1 USING (c1, c3, c4) FORCE;
      
      Copy

Importante

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

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 conforme necessário.

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.

Este comportamento também se aplica às colunas utilizadas como colunas condicionais em uma política de mascaramento.

Para obter mais informações, consulte CREATE MASKING POLICY e CREATE ROW ACCESS POLICY.

Simulação de como uma política irá funcionar

Chame a função POLICY_CONTEXT para simular uma consulta em uma coluna que esteja protegida por uma política de mascaramento, uma tabela ou exibição protegida por uma política de acesso a linhas, ou ambos os tipos de políticas.

Exibições materializadas

O Snowflake permite definir uma política de mascaramento em uma coluna de exibição materializada. No tempo de execução da consulta, o plano da consulta executa qualquer política de mascaramento que esteja presente antes de criar a regravação da exibição materializada. Uma vez ocorrida a regravação da exibição materializada, as políticas de mascaramento não podem ser definidas em nenhuma coluna de exibição materializada.

Há duas opções para definir uma política de mascaramento em uma coluna de exibição materializada:

  1. Para uma nova exibição materializada, execute uma instrução CREATE MATERIALIZED VIEW.

  2. Para uma exibição materializada existente, execute uma instrução ALTER VIEW … MODIFY COLUMN na exibição materializada.

Para uma nova exibição materializada, execute a seguinte instrução:

CREATE OR REPLACE MATERIALIZED VIEW user_info_mv
  (ssn_number masking policy ssn_mask)
AS SELECT ssn_number FROM user_info;
Copy

Para uma exibição materializada existente, consulte o exemplo de exibição na seção Aplicação de políticas de mascaramento a colunas (neste tópico).

Além disso, considere as duas limitações a seguir com relação a políticas de mascaramento e exibições materializadas:

  1. Uma política de mascaramento não pode ser definida em uma coluna da tabela se uma exibição materializada já tiver sido criada a partir da tabela subjacente. O Snowflake retorna a seguinte mensagem de erro quando esta tentativa é feita:

    SQL execution error: One or more materialized views exist on the table. number of mvs=<number>, table name=<table_name>.
    
    Copy
  2. Se uma política de mascaramento for definida para uma coluna de tabela e uma exibição materializada for criada a partir dessa tabela, a exibição materializada terá apenas colunas que não são protegidas por uma política de mascaramento. O Snowflake também retorna a seguinte mensagem de erro se houver uma tentativa de incluir uma ou mais colunas protegidas por uma política de mascaramento:

    Unsupported feature 'CREATE ON MASKING POLICY COLUMN'.
    
    Copy

Obtenção de colunas com uma política de mascaramento

Para obter uma lista de colunas com políticas de mascaramento, execute a seguinte instrução. Para obter mais informações, consulte POLICY_REFERENCES.

SELECT * from table(
  INFORMATION_SCHEMA.POLICY_REFERENCES(
    policy_name=>'<policy_name>'
  )
);
Copy

Execute uma instrução DESCRIBE TABLE ou DESCRIBE VIEW para ver a política de mascaramento na coluna de uma tabela ou exibição.

Políticas de mascaramento e marcação de objetos

Para obter mais detalhes, consulte Políticas de mascaramento baseadas em tags.

Note que uma política de mascaramento diretamente atribuída a uma coluna tem precedência sobre uma política de mascaramento baseada em tags.

Funções de hashing, criptografia e codificação em políticas de mascaramento

Funções de hashing e criptografia/soma de verificação podem ser usadas em políticas de mascaramento para mascarar dados confidenciais.

Para obter mais informações, consulte Tópicos avançados de segurança em nível de coluna.

Tabelas externas

Não é possível atribuir uma política de mascaramento à coluna VALUE da tabela externa ao criar a tabela externa com uma instrução CREATE EXTERNAL TABLE porque esta coluna é criada automaticamente por padrão.

Você pode atribuir a política de mascaramento à coluna VALUE da tabela externa executando uma instrução ALTER TABLE … ALTER COLUMN na tabela externa. O tipo de dados da política de mascaramento que protege a coluna VALUE deve ser VARIANT.

ALTER TABLE t1 MODIFY COLUMN VALUE SET MASKING POLICY p1;
Copy

Você pode atribuir uma política de mascaramento a uma coluna virtual em uma tabela externa da seguinte forma:

  • Defina a propriedade da política de mascaramento EXEMPT_OTHER_POLICIES como TRUE na política de mascaramento que protege a coluna VALUE na tabela externa.

    Se esta propriedade ainda não estiver definida, execute uma instrução CREATE OR REPLACE na política de mascaramento que protege a coluna VALUE e especifique a propriedade EXEMPT_OTHER_POLICIES. A coluna virtual herda a política que protege a coluna VALUE e esta propriedade permite que a política na coluna virtual substitua a política herdada. Para obter mais detalhes, consulte CREATE MASKING POLICY.

  • Atribua uma política de mascaramento diferente à coluna virtual usando um comando ALTER TABLE. Esta política pode ser menos rigorosa que a política da coluna VALUE porque a coluna virtual é menos sensível. A coluna virtual contém uma quantidade menor de dados que a coluna VALUE; a coluna VALUE contém todos os dados de cada linha da tabela externa.

    O tipo de dados na política que protege a coluna virtual depende do tipo de dados da coluna virtual.

Com relação às colunas condicionais em uma política de mascaramento, uma coluna virtual pode ser listada como um argumento de coluna condicional para determinar se o argumento da primeira coluna deve ser mascarado ou tokenizado. Entretanto, uma coluna virtual não pode ser especificada como a primeira coluna a ser mascarada ou tokenizada.

Para obter mais informações, consulte CREATE MASKING POLICY.

Importante

O Snowflake não aceita o uso de uma tabela externa como tabela de pesquisa (ou seja, em uma subconsulta) em uma política de mascaramento. Ao clonar um banco de dados, o Snowflake clona a política de mascaramento, mas não a tabela externa. Portanto, a política no banco de dados clonado refere-se a uma tabela que não está presente no banco de dados clonado.

Se os dados na tabela externa forem necessários para a política, considere mover os dados da tabela externa para um esquema dedicado dentro do banco de dados no qual a política de mascaramento existe antes de completar uma operação de clonagem. Atualize a política de mascaramento para referenciar o nome de tabela totalmente qualificado para garantir que a política se refira a uma tabela no banco de dados clonado.

Fluxos

As políticas de mascaramento em colunas de uma tabela são transferidas para um fluxo na mesma tabela.

O resultado é que usuários não autorizados veem os dados mascarados; fluxos criados por usuários autorizados veem os dados como definidos pela política de mascaramento.

Objetos clonados

A abordagem a seguir ajuda a proteger os dados dos usuários com o privilégio SELECT na tabela ou exibição ao acessar um objeto clonado.

  • A clonagem de um objeto individual de política não é permitida.

  • A clonagem de um esquema resulta na clonagem de todas as políticas dentro do esquema.

  • Uma tabela clonada é mapeada para as mesmas políticas que a tabela de origem. Em outras palavras, se uma política for definida em uma tabela base ou suas colunas, a política será anexada à tabela clonada ou a suas colunas.

    • Quando uma tabela é clonada no contexto da clonagem de seu esquema principal, se a tabela de origem tiver uma referência a uma política no mesmo esquema principal (ou seja, uma referência local), a tabela clonada terá uma referência à política clonada.

    • Se a tabela de origem se referir a uma política em um esquema diferente (ou seja, uma referência estrangeira), então a tabela clonada manterá a referência estrangeira.

Para obter mais informações, consulte CREATE <objeto> … CLONE.

Instruções CREATE TABLE … AS SELECT (CTAS)

Executar uma instrução CREATE TABLE … AS SELECT (CTAS) aplica qualquer política de mascaramento nas colunas incluídas na instrução antes de os dados serem preenchidos na nova tabela (ou seja, os dados da coluna aplicável são mascarados na nova tabela). Este fluxo é seguido porque uma tabela criada usando uma instrução CTAS pode ter um conjunto de colunas diferente dos objetos de origem, e o Snowflake não pode aplicar implicitamente políticas de mascaramento às novas colunas da tabela.

Se houver necessidade de copiar dados não mascarados, use uma função autorizada para dados protegidos para executar a instrução CTAS. Após criar a nova tabela, transfira a propriedade da nova tabela para outra função e peça ao administrador da política de mascaramento que aplique as políticas de mascaramento às colunas da nova tabela.

Para obter mais informações, consulte CREATE TABLE.

Consultas que usam funções agregadas e colunas mascaradas

É possível usar Funções de agregação em colunas com dados mascarados.

Um caso de uso representativo é quando um analista de dados quer obter a COUNT para uma coluna de números de previdência social sem precisar ver os dados reais. Entretanto, se o analista de dados executar uma consulta usando SELECT em uma coluna de tabela mascarada, a consulta retorna um valor mascarado fixo. Os usuários com a função PAYROLL personalizada na sessão atual veem os dados não mascarados e todos os outros veem os dados mascarados.

Para alcançar este resultado:

  1. O proprietário da tabela cria uma exibição na coluna que contém a função agregada.

    CREATE VIEW ssn_count AS SELECT DISTINCT(ssn) FROM table1;
    
    Copy
  2. Conceda privilégios totais à função ANALYST para a exibição. Não conceda quaisquer privilégios ao analista para a tabela.

  3. Aplique uma política de mascaramento à coluna da tabela. Observe que a política de tabela é sempre aplicada antes da política de exibição, se houver uma política em uma coluna de exibição.

    CASE
      WHEN CURRENT_ROLE() IN ('PAYROLL') THEN val
      ELSE '***MASKED***'
    END;
    
    Copy
  4. Execute uma consulta na coluna de exibição.

    USE ROLE analyst;
    SELECT COUNT(DISTINCT ssn) FROM v1;
    
    Copy

Funções definidas pelo usuário em uma política de mascaramento

Um UDF pode ser passado para as condições da política de mascaramento.

É importante assegurar que o tipo de dados para a coluna da tabela ou exibição, o UDF e a política de mascaramento coincidam. Se os tipos de dados forem diferentes, tais como ter uma coluna de tabela e um UDF com tipo de dados VARIANT e a política de mascaramento (com esse UDF nas condições da política) retornar o tipo de dados VARCHAR, o Snowflake retornará um erro ao fazer uma consulta na coluna da tabela quando essa política de mascaramento estiver definida na coluna da tabela.

Para um exemplo representativo de correspondência do tipo de dados para uma coluna de tabela, UDF e política de mascaramento, consulte o exemplo Uso de UDFs JavaScript em JSON (variante) em CREATE MASKING POLICY.

Data Sharing

Uso:
  • Se o provedor atribuir uma política a uma tabela ou exibição compartilhada e as condições da política chamarem a função CURRENT_ROLE ou CURRENT_USER, ou as condições da política chamarem a função UDF segura, o Snowflake retorna um valor NULL para a função ou o UDF na conta do consumidor.

    A razão é que o proprietário dos dados que estão sendo compartilhados não costuma controlar os usuários ou as funções na conta na qual a tabela ou exibição está sendo compartilhada. Como alternativa, use a função CURRENT_ACCOUNT nas condições da política.

    Como alternativa, como provedor, escreva as condições da política para chamar a função IS_DATABASE_ROLE_IN_SESSION e compartilhar a função do banco de dados. Como consumidor, conceda a função de banco de dados compartilhada a uma função de conta. Para obter mais detalhes, consulte Compartilhamento de dados protegidos por uma política.

Limitações:
  • Um provedor de compartilhamento de dados não pode criar uma política em uma conta de leitor.

  • Os consumidores que compartilham dados não podem aplicar uma política a uma tabela ou exibição compartilhada. Como alternativa, importe o banco de dados compartilhado e crie exibições locais a partir da tabela ou exibição compartilhada.

  • Os consumidores que compartilham dados não podem consultar uma tabela ou exibição compartilhada que faz referência a dois fornecedores provedores. Por exemplo:

    • rap1 é uma política de acesso a linhas que protege a tabela chamada t1, onde t1 está na ação chamada share1 de um provedor.

    • As condições da política rap1 referem-se a uma tabela de mapeamento chamada t2, em que t2 vem de share2 e de um provedor diferente.

    • A consulta do consumidor em t1 falha.

    • O provedor de t1 pode consultar t1.

  • Funções externas:

    O Snowflake retorna um erro se:

    • A política atribuída a uma tabela ou exibição compartilhada é atualizada para chamar uma função externa.

    • A política chama uma função externa e você tenta atribuir a política a uma tabela ou exibição compartilhada.

Nota

Para tokenização externa, Secure Data Sharing não é aplicável porque as funções externas não podem ser invocadas no contexto de um compartilhamento.

Replicação

As políticas de mascaramento e suas atribuições podem ser replicadas usando replicação de banco de dados e grupos de replicação.

Para replicação de banco de dados, a operação de replicação falha se uma das seguintes condições for verdadeira:

  • O banco de dados primário está em uma conta Enterprise (ou superior) e contém uma política, mas uma ou mais das contas aprovadas para replicação estão em edições anteriores.

  • Uma tabela ou exibição contida no banco de dados primário tem uma referência pendente a uma política de mascaramento em outro banco de dados.

O comportamento de referência pendente para a replicação de banco de dados pode ser evitado ao replicar múltiplos bancos de dados em um grupo de replicação.

Nota

Se ações de failover ou failback forem usadas, a conta Snowflake deve ser Business Critical Edition ou superior.

Para obter mais informações, consulte Introdução à replicação e failover em várias contas.

Perfil de consulta

Quando usado em uma coluna com uma política de mascaramento, a saída do comando EXPLAIN inclui os dados mascarados, não o corpo da política de mascaramento.

O exemplo a seguir gera o plano EXPLAIN para uma consulta em uma tabela de números de identificação de funcionários e números de previdência social. O comando gera o exemplo no formato JSON.

A coluna que contém os números da previdência social tem uma política de mascaramento.

EXPLAIN USING JSON SELECT * FROM mydb.public.ssn_record;
Copy
{
  "GlobalStats": {
    "partitionsTotal": 0,
    "partitionsAssigned": 0,
    "bytesAssigned": 0
  },
  "Operations": [
    [
      {
        "id": 0,
        "operation": "Result",
        "expressions": [
          "1",
          "'**MASKED**'"
        ]
      },
      {
        "id": 1,
        "parent": 0,
        "operation": "Generator",
        "expressions": [
          "1"
        ]
      }
    ]
  ]
}
Copy

Descarregamento de dados

O uso do comando COPY INTO <local> em uma coluna que tem uma política de mascaramento faz com que a política de mascaramento seja aplicada aos dados. Portanto, usuários não autorizados veem os dados mascarados após executar o comando.

Snowflake Native App Framework

Para obter detalhes sobre o uso de políticas de mascaramento com Snowflake Native App, consulte:

Gerenciamento da segurança em nível de coluna

Esta seção fornece informações úteis para determinar sua abordagem geral de gerenciamento de políticas de mascaramento, descreve os privilégios necessários para gerenciar a segurança em nível de coluna e lista os comandos DDL aceitos.

Escolha de uma abordagem centralizada, híbrida ou descentralizada

Para gerenciar políticas de mascaramento dinâmico de dados e tokenização externa de forma eficaz, é útil considerar se sua abordagem de mascaramento de dados em colunas deve seguir uma abordagem de segurança centralizada, uma abordagem descentralizada ou um híbrido de cada abordagem.

A tabela a seguir resume algumas das considerações para cada abordagem.

Ação da política

Gerenciamento centralizado

Gerenciamento híbrido

Gerenciamento descentralizado

Criar políticas

Responsável pela segurança

Responsável pela segurança

Equipes individuais

Aplicar políticas às colunas

Responsável pela segurança

Equipes individuais

Equipes individuais

Como melhor prática, o Snowflake recomenda que sua organização reúna todas as partes interessadas relevantes para determinar a melhor abordagem de gerenciamento para implementar a segurança em nível de coluna em seu ambiente.

Privilégios da política de mascaramento

Esta seção descreve os privilégios da política de mascaramento da segurança em nível de coluna e como eles se aplicam a uma abordagem de gerenciamento centralizada, descentralizada ou híbrida.

O Snowflake oferece os seguintes privilégios para as políticas de mascaramento de segurança em nível de coluna.

Observe que operar em qualquer objeto de um esquema também requer o privilégio USAGE no banco de dados e esquema principais.

Privilégio

Uso

CREATE

Permite a criação de uma nova política de mascaramento em um esquema.

APPLY

Permite executar as operações de remover e definir para uma política de mascaramento em uma coluna.

Observe que a concessão do privilégio global APPLY MASKING POLICY (isto é, APPLY MASKING POLICY em ACCOUNT) permite executar a operação DESCRIBE em tabelas e exibições.

Para exemplos de sintaxe, consulte Privilégios da política de mascaramento.

OWNERSHIP

Concede controle total sobre a política de mascaramento. Requerido para alterar a maioria das propriedades de uma política de mascaramento. Somente uma única função pode ter este privilégio sobre um objeto específico de cada vez.

Nota

A operação em uma política de mascaramento também requer o privilégio USAGE no banco de dados pai e no esquema.

Os exemplos a seguir mostram como a concessão de privilégios se aplica a diferentes abordagens de gerenciamento. Após conceder o privilégio APPLY a uma função, a política de mascaramento pode ser definida em uma coluna de tabela usando uma instrução ALTER TABLE … ALTER COLUMN ou definida em uma coluna de exibição usando uma instrução ALTER VIEW (por um membro da função com o privilégio APPLY para a política de mascaramento).

Gerenciamento centralizado

Em uma abordagem de gerenciamento centralizado, apenas a função personalizada do responsável pela segurança (por exemplo, security_officer) cria e aplica políticas de mascaramento a colunas em tabelas ou exibições. Essa abordagem pode fornecer a maior consistência em termos de gerenciamento de políticas de mascaramento e mascaramento de dados confidenciais.

-- create a security_officer custom role

USE ROLE ACCOUNTADMIN;
CREATE ROLE security_officer;

-- grant CREATE AND APPLY masking policy privileges to the SECURITY_OFFICER custom role.

GRANT CREATE MASKING POLICY ON SCHEMA mydb.mysch TO ROLE security_officer;

GRANT APPLY MASKING POLICY ON ACCOUNT TO ROLE security_officer;
Copy

Onde:

  • schema_name

    Especifica o identificador do esquema; deve ser único para o banco de dados no qual o esquema é criado.

    Além disso, o identificador deve começar com um caractere alfabético e não pode conter espaços ou caracteres especiais, a menos que toda a cadeia identificadora esteja entre aspas duplas (por exemplo, “Meu objeto”). Os identificadores delimitados por aspas duplas também diferenciam letras maiúsculas de minúsculas.

    Para obter mais detalhes, consulte Requisitos para identificadores.

Gerenciamento híbrido

Em uma abordagem de gerenciamento híbrido, a função personalizada do responsável pela segurança (por exemplo, security_officer) cria políticas de mascaramento, e equipes individuais (por exemplo, finanças, folha de pagamento, recursos humanos) aplicam as políticas de mascaramento a colunas em tabelas ou exibições de propriedade das equipes. Essa abordagem pode levar à criação e manutenção de políticas consistentes, mas requer que as equipes individuais tenham a maior responsabilidade de mascarar dados confidenciais.

USE ROLE ACCOUNTADMIN;
CREATE ROLE security_officer;
GRANT CREATE MASKING POLICY ON SCHEMA mydb.mysch TO ROLE security_officer;
Copy

A função personalizada SECURITY_OFFICER concede o privilégio APPLY à equipe de recursos humanos (ou seja, usuários com a função personalizada HUMAN_RESOURCES) para mascarar números de previdência social (por exemplo, política de mascaramento: ssn_mask) em colunas para objetos de propriedade da função personalizada HUMAN_RESOURCES.

USE ROLE security_officer;
GRANT APPLY ON MASKING POLICY ssn_mask TO ROLE human_resources;
Copy

Onde:

  • grant apply on masking policy policy_name to role role_name;

    Usado por um proprietário de política para descentralizar as operações de remoção e definição de uma determinada política de mascaramento em colunas para os proprietários dos objetos.

    Esse privilégio tem suporte para o controle de acesso discricionário onde os proprietários de objetos também são considerados administradores de dados.

Abordagem descentralizada

Em uma abordagem de gerenciamento descentralizado, equipes individuais criam e aplicam políticas de mascaramento a colunas em tabelas ou exibições. Essa abordagem pode levar a um gerenciamento de políticas inconsistente, com a possibilidade de os dados confidenciais não serem mascarados adequadamente, uma vez que equipes individuais assumem toda a responsabilidade pelo gerenciamento de políticas de mascaramento e pelo mascaramento de dados confidenciais.

Neste exemplo representativo, a equipe de suporte (ou seja, usuários com a função personalizada SUPPORT) e a equipe financeira (ou seja, usuários com a função personalizada FINANCE) podem criar políticas de mascaramento. Observe que estas funções personalizadas podem não incluir a função personalizada SECURITY_OFFICER.

USE ROLE ACCOUNTADMIN;
GRANT CREATE MASKING POLICY ON SCHEMA mydb.mysch TO ROLE support;
GRANT CREATE MASKING POLICY ON SCHEMA <DB_NAME.SCHEMA_NAME> TO ROLE FINANCE;
Copy

A equipe de suporte concede o privilégio APPLY à equipe de recursos humanos (ou seja, usuários com a função personalizada HUMAN_RESOURCES) para mascarar números de previdência social (por exemplo, política de mascaramento: ssn_mask) em colunas para objetos de propriedade da função personalizada HUMAN_RESOURCES.

USE ROLE support;
GRANT APPLY ON MASKING POLICY ssn_mask TO ROLE human_resources;
Copy

A equipe financeira concede o privilégio APPLY à equipe de auditoria interna (ou seja, usuários com a função personalizada AUDIT_INTERNAL) para mascarar dados de fluxo de caixa (por exemplo, política de máscara: cash_flow_mask) em colunas para objetos de propriedade da função personalizada AUDIT_INTERNAL.

USE ROLE finance;
GRANT APPLY ON MASKING POLICY cash_flow_mask TO ROLE audit_internal;
Copy

Para obter mais informações sobre privilégios de políticas de mascaramento, consulte:

DDL da política de mascaramento

O Snowflake fornece o seguinte conjunto de comandos para gerenciar as políticas de mascaramento da segurança em nível de coluna.

A tabela a seguir resume a relação entre as operações do DDL da política de mascaramento de segurança em nível da coluna e seus privilégios necessários.

Observe que operar em qualquer objeto de um esquema também requer o privilégio USAGE no banco de dados e esquema principais.

Operação

Privilégio

Criar uma política de mascaramento

Uma função com o privilégio CREATE MASKING POLICY no SCHEMA.

Alterar uma política de mascaramento

O proprietário da política de mascaramento (ou seja, a função com o privilégio OWNERSHIP na política de mascaramento).

Descartar uma política de mascaramento

O proprietário da política de mascaramento (ou seja, a função com o privilégio OWNERSHIP na política de mascaramento).

Mostrar políticas de mascaramento

Um dos seguintes: . Uma função com o privilégio global APPLY MASKING POLICY, ou . O proprietário da política de mascaramento (ou seja, a função com o privilégio OWNERSHIP na política de mascaramento) ou . Uma função com o privilégio APPLY para a política de mascaramento.

Descrição da política de mascaramento

Um dos seguintes: . Uma função com o privilégio global APPLY MASKING POLICY, ou . O proprietário da política de mascaramento (ou seja, a função com o privilégio OWNERSHIP na política de mascaramento) ou . Uma função com o privilégio APPLY para a política de mascaramento.

Listar colunas com uma política de mascaramento

Um dos seguintes: . A função com o privilégio APPLY MASKING POLICY, ou . A função com o privilégio APPLY para MASKING POLICY em uma dada política de mascaramento e tem OWNERSHIP para o objeto de destino.

Uso de UDFs em uma política de mascaramento

Se estiver criando uma nova política de mascaramento ou alterando uma política existente, a função do administrador de políticas deve ter uso no UDF, todos os UDFs escalares na expressão da política devem ter o mesmo tipo de dados e o UDF deve existir.

No tempo de execução da consulta, o Snowflake verifica se o UDF existe; caso contrário, a expressão SQL não será resolvida e a consulta falhará.

Monitoramento de políticas de mascaramento com SQL

Você pode monitorar o uso da política de mascaramento por meio de duas exibições diferentes do Account Usage e de uma tabela do Information Schema.

Pode ser útil pensar em duas abordagens gerais para determinar como monitorar o uso de política de mascaramento.

Como descobrir as políticas de mascaramento

Você pode usar a exibição MASKING_POLICIES no esquema Account Usage do banco de dados SNOWFLAKE compartilhado. Essa exibição é um catálogo de todas as políticas de mascaramento em sua conta Snowflake. Por exemplo:

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.MASKING_POLICIES
ORDER BY POLICY_NAME;
Copy

Identificar atribuições

O Snowflake oferece suporte a diferentes opções para identificar atribuições de política de mascaramento, dependendo se a consulta precisa ser direcionada à conta ou a um banco de dados específico.

  • Consulta em nível de conta:

    Use a exibição POLICY_REFERENCES do Account Usage para determinar todas as colunas que têm uma política de mascaramento. Por exemplo:

    SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.POLICY_REFERENCES
    ORDER BY POLICY_NAME, REF_COLUMN_NAME;
    
    Copy
  • Consulta em nível de banco de dados:

    Todo banco de dados do Snowflake inclui um Snowflake Information Schema. Use a função de tabela do Information Schema POLICY_REFERENCES para determinar todas as políticas de mascaramento em colunas de uma determinada tabela:

    SELECT *
    FROM TABLE(
      my_db.INFORMATION_SCHEMA.POLICY_REFERENCES(
        'my_table',
        'table'
      )
    );
    
    Copy

    Você também pode usar essa função para consultar pelo nome da política de mascaramento para encontrar os objetos associados a uma determinada política de mascaramento.

Monitoramento de políticas de mascaramento com Snowsight

Você pode usar a área Snowsight Monitoring » Governance para monitorar e gerar relatórios sobre o uso de políticas e tags com tabelas, exibições e colunas. Há duas interfaces diferentes: Dashboard e Tagged Objects.

Ao usar a interface Dashboard e Tagged Objects, observe os detalhes a seguir.

  • As interfaces Dashboard e Tagged Objects exigem um warehouse em execução.

  • Snowsight atualiza o Dashboard a cada 12 horas.

  • A latência das informações Tagged Objects pode ser de até duas horas e retorna até 1.000 objetos.

Acesso à área de governança no Snowsight

Para acessar a área Governance, sua conta Snowflake deve ser Enterprise Edition ou superior. Além disso, você deve executar um dos seguintes procedimentos:

  • Use a função ACCOUNTADMIN.

  • Use uma função de conta receba diretamente as funções de banco de dados GOVERNANCE_VIEWER e OBJECT_VIEWER.

    Você deve usar uma função de conta com essas concessões de função de banco de dados. Atualmente, Snowsight não avalia hierarquias de funções e funções de banco de dados definidas pelo usuário com acesso a tabelas, exibições, políticas de acesso a dados e tags.

    Para determinar se a função da sua conta tem essas duas funções de banco de dados, use um comando SHOW GRANTS:

    SHOW GRANTS LIKE '%VIEWER%' TO ROLE data_engineer;
    
    Copy
    |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
    | created_on                    | privilege | granted_on    | name                        | granted_to | grantee_name    | grant_option | granted_by |
    |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
    | 2024-01-24 17:12:26.984 +0000 | USAGE     | DATABASE_ROLE | SNOWFLAKE.GOVERNANCE_VIEWER | ROLE       | DATA_ENGINEER   | false        |            |
    | 2024-01-24 17:12:47.967 +0000 | USAGE     | DATABASE_ROLE | SNOWFLAKE.OBJECT_VIEWER     | ROLE       | DATA_ENGINEER   | false        |            |
    |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
    

    Se a função da sua conta não receber uma ou ambas as funções de banco de dados, use o comando GRANT DATABASE ROLE e execute o comando SHOW GRANTS novamente para confirmar as concessões:

    USE ROLE ACCOUNTADMIN;
    GRANT DATABASE ROLE SNOWFLAKE.GOVERNANCE_VIEWER TO ROLE data_engineer;
    GRANT DATABASE ROLE SNOWFLAKE.OBJECT_VIEWER TO ROLE data_engineer;
    SHOW GRANTS LIKE '%VIEWER%' TO ROLE data_engineer;
    
    Copy

    Para obter detalhes sobre essas funções de banco de dados, consulte Funções de banco de dados SNOWFLAKE.

Painel

Como administrador de dados, você pode usar a interface do Dashboard para monitorar o uso de tags e políticas das seguintes maneiras.

  • Cobertura: especifica a contagem e a porcentagem com base no fato de uma tabela, exibição ou coluna ter uma política ou tag.

  • Prevalência: lista e conta as políticas e tags usadas com mais frequência.

A cobertura e a prevalência fornecem um instantâneo de quão bem os dados estão protegidos e marcados com tag.

Quando você seleciona um número de contagem, porcentagem, nome de política ou nome de tag, a interface Tagged Objects é aberta. A interface Tagged Objects atualiza os filtros automaticamente com base em sua seleção em Dashboard.

As informações de monitoramento são uma alternativa ou um complemento à execução de operações complexas e de consulta intensa em várias exibições do Account Usage.

Essas exibições podem incluir, sem limitação, as exibições COLUMNS, POLICY_REFERENCES, TABLES, TAG_REFERENCES e VIEWS.

Objetos marcados

Como administrador de dados, você pode usar essa tabela para associar rapidamente a cobertura e a prevalência no Dashboard a uma lista de tabelas, exibições ou colunas específicas. Você também pode filtrar os resultados da tabela manualmente da seguinte forma.

  • Escolha Tables ou Columns.

  • Para as tags, você pode filtrar com tags, sem tags ou por uma tag específica.

  • Para políticas, você pode filtrar com políticas, sem políticas ou por uma política específica.

Quando você seleciona uma linha na tabela, a guia Table Details ou Columns em Data » Databases é aberta. Você pode editar as atribuições de tags e políticas conforme necessário.

Dica

Você pode usar a Snowsight para solucionar problemas de atribuições de políticas de mascaramento. Na guia Columns, a coluna MASKING POLICY mostra Policy Error quando há um conflito com a atribuição da política de mascaramento na coluna. Você pode selecionar Policy Error para obter mais informações.

Além disso, a guia Data Preview não exibe uma pré-visualização dos dados quando há um erro com uma atribuição de política de mascaramento em uma coluna. Em vez disso, a guia Data Preview retorna a mensagem de erro SQL. Esta mensagem corresponde a um dos valores de erro na coluna POLICY_STATUS da exibição POLICY_REFERENCES do Account Usage e da função de tabela POLICY_REFERENCES do Information Schema.

Para corrigir o erro, use a mensagem de erro SQL e a mensagem Policy Error para modificar a atribuição da tag ou da política.

Para obter detalhes adicionais, consulte Descoberta de tags e políticas