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

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.

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.

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.

• Você pode aplicar a política de mascaramento a uma ou mais colunas de tabela/exibição com o tipo de dados correspondente. Por exemplo, você pode definir uma vez uma política para um endereço de e-mail e aplicá-la a milhares de colunas de e-mail em bancos de dados e esquemas.

• As condições da política de mascaramento podem ser expressas usando-se Funções de expressão condicional e Funções de contexto ou consultando-se uma tabela de direitos personalizados. Você pode usar as funções de contexto INVOKER_ROLE e INVOKER_SHARE com exibições e compartilhamentos, respectivamente.

• As funções de mascaramento podem ser qualquer uma das funções internas (por exemplo, REGEXP_REPLACE, SHA2 , SHA2_HEX), Visão geral das funções definidas pelo usuário ou Como escrever funções externas (para a destokenização por meio de um provedor externo).

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.

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

Benefícios¶

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

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.

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.

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:

• Seção Exemplos na função IS_ROLE_IN_SESSION.

• IS_DATABASE_ROLE_IN_SESSION

• Compartilhamento de dados protegidos por uma política

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:

   • CREATE TABLE

   • CREATE VIEW

   • CREATE MATERIALIZED VIEW

   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:

   • ALTER TABLE

   • ALTER TABLE … ALTER COLUMN

   • ALTER VIEW

   • ALTER MATERIALIZED VIEW

   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

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.

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.

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;

{
  "GlobalStats": {
    "partitionsTotal": 0,
    "partitionsAssigned": 0,
    "bytesAssigned": 0
  },
  "Operations": [
    [
      {
        "id": 0,
        "operation": "Result",
        "expressions": [
          "1",
          "'**MASKED**'"
        ]
      },
      {
        "id": 1,
        "parent": 0,
        "operation": "Generator",
        "expressions": [
          "1"
        ]
      }
    ]
  ]
}

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:

• Restrições ao compartilhamento de conteúdo de dados que contém políticas.

• Definição de políticas em exibições de proxy.

• Funções de contexto bloqueadas.

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.

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.

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:

• Uso do mascaramento dinâmico de dados

• Uso de tokenização externa

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.

• CREATE MASKING POLICY

• ALTER MASKING POLICY (consulte também: ALTER TABLE, ALTER TABLE … ALTER COLUMN e ALTER VIEW)

• DROP MASKING POLICY

• SHOW MASKING POLICIES

• DESCRIBE MASKING POLICY

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.

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.

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.

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