CREATE MASKING POLICY¶
Cria uma nova política de mascaramento no esquema atual/especificado ou substitui uma política de mascaramento existente.
Após criar uma política de mascaramento, aplique a política de mascaramento a uma coluna em uma tabela usando um comando ALTER TABLE … ALTER COLUMN ou uma visualização usando um comando ALTER VIEW.
- Consulte também:
Escolha de uma abordagem centralizada, híbrida ou descentralizada, Tópicos avançados de segurança em nível de coluna
Sintaxe¶
CREATE [ OR REPLACE ] MASKING POLICY [ IF NOT EXISTS ] <name> AS
( <arg_name_to_mask> <arg_type_to_mask> [ , <arg_1> <arg_type_1> ... ] )
RETURNS <arg_type_to_mask> -> <expression_on_arg_name>
[ COMMENT = '<string_literal>' ];
Parâmetros¶
name
Identificador da política de mascaramento; deve ser único para seu esquema.
O valor do 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 de caracteres do identificador esteja entre aspas duplas (por exemplo,
"My object"
). Os identificadores delimitados por aspas duplas também diferenciam letras maiúsculas de minúsculas.Para obter mais detalhes, consulte Requisitos para identificadores.
AS ( arg_name_to_mask arg_type_to_mask [ , arg_1 arg_type_1 ... ] )
A assinatura da política de mascaramento; especifica as colunas de entrada e os tipos de dados a serem avaliados no tempo de execução da consulta.
Para obter mais detalhes, consulte Tipos de dados.
arg_name_to_mask arg_type_to_mask
A primeira coluna e seu tipo de dados sempre indicam os valores do tipo de dados da coluna a serem mascarados ou tokenizados nas condições da política subsequente.
Note que você não pode especificar uma coluna virtual como primeiro argumento da coluna em uma política de mascaramento condicional.
[ , arg_1 arg_type_1 ... ]
Especifica as colunas condicionais e seus tipos de dados a serem avaliados para determinar se as condições da política devem mascarar ou tokenizar os dados na primeira coluna em cada linha do resultado da consulta.
Se estas colunas e tipos de dados adicionais não forem especificados, o Snowflake avalia a política como uma política normal de mascaramento.
RETURNS arg_type_to_mask
O tipo de dados de retorno deve corresponder ao tipo de dados de entrada da primeira coluna especificada como coluna de entrada.
expression_on_arg_name
Expressão SQL que transforma os dados.
A expressão pode incluir Funções de expressão condicional para representar lógica condicional, funções internas ou UDFs para transformar os dados.
Se uma UDF ou função externa for usada no corpo de política de mascaramento, o proprietário da política deve ter USAGE na UDF ou função externa. O privilégio USAGE na UDF ou função externa não é necessário para a função usada para consultar uma coluna que tenha uma política de mascaramento aplicada a ela.
Se uma UDF ou função externa for usada no corpo de política de mascaramento condicional, o proprietário da política deve ter OWNERSHIP na UDF ou função externa. Os usuários que consultam uma coluna com uma política de mascaramento condicional aplicada a ela não precisam ter USAGE na UDF ou função externa.
COMMENT = 'string_literal'
Adiciona um comentário ou substitui um comentário existente para a política de mascaramento.
Requisitos de controle de acesso¶
Uma função usada para executar este comando SQL deve ter os seguintes privilégios no mínimo:
Privilégio |
Objeto |
Notas |
---|---|---|
CREATE MASKING POLICY |
Esquema |
Observe que operar em qualquer objeto de um esquema também requer o privilégio USAGE no banco de dados e esquema principais.
Para instruções sobre como criar uma função personalizada com um conjunto específico de privilégios, consulte Criação de funções personalizadas.
Para informações gerais sobre concessões de funções e privilégios para executar ações de SQL em objetos protegíveis, consulte Controle de acesso no Snowflake.
Para detalhes adicionais sobre a política de mascaramento DDL e privilégios, consulte Gerenciamento da segurança em nível de coluna.
Notas de uso¶
Se você quiser substituir 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.
Para políticas de mascaramento com uma subconsulta no corpo da política de mascaramento, use EXISTS na ramificação WHEN da função CASE. Para um exemplo representativo, consulte o exemplo da tabela de direitos personalizados na seção Política de mascaramento normal (neste tópico).
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.
Para obter mais informações, consulte CREATE ROW ACCESS POLICY.
Um provedor de compartilhamento de dados não pode criar uma política de mascaramento em uma conta de leitor.
Se utilizar uma UDF em uma política de mascaramento, certifique-se de que o tipo de dados da coluna, a UDF e a política de mascaramento sejam correspondentes. Para obter mais informações, consulte Funções definidas pelo usuário em uma política de mascaramento.
Em relação aos metadados:
Atenção
Os clientes devem garantir que nenhum dado pessoal (exceto para um objeto do usuário), dados sensíveis, dados controlados por exportação ou outros dados regulamentados sejam inseridos como metadados ao usar o serviço Snowflake. Para obter mais informações, consulte Campos de metadados no Snowflake.
Instruções CREATE OR REPLACE <object> são atômicas. Ou seja, quando o objeto é substituído, a exclusão do objeto antigo e a criação do novo objeto são processadas em uma única transação.
Exemplos¶
Política de mascaramento normal¶
Você pode usar Funções de expressão condicional, Funções de contexto e UDFs para criar a expressão SQL.
A seguir, você encontra exemplos representativos do corpo de política para mostrar como criar condições de política de mascaramento usando diferentes instruções, funções e tipos de dados de SQL.
Estes exemplos utilizam principalmente a função de contexto CURRENT_ROLE. Se a ativação e a hierarquia de funções for necessária nas condições da política, use IS_ROLE_IN_SESSION.
Máscara completa:
A função
analyst
pode ver o valor em texto simples. Usuários sem a funçãoanalyst
veem uma máscara completa.CREATE OR REPLACE MASKING POLICY email_mask AS (val string) returns string -> CASE WHEN current_role() IN ('ANALYST') THEN VAL ELSE '*********' END;
Permitir que uma conta de produção consulte valores sem máscara e todas as outras contas (como de desenvolvimento, teste) vejam valores com máscara.
case when current_account() in ('<prod_account_identifier>') then val else '*********' end;
Retornar NULL para usuários não autorizados:
case when current_role() IN ('ANALYST') then val else NULL end;
Retornar um valor estático mascarado para usuários não autorizados:
CASE WHEN current_role() IN ('ANALYST') THEN val ELSE '********' END;
Retornar um valor de hash usando SHA2 , SHA2_HEX para usuários não autorizados. O uso de uma função de hash em uma política de mascaramento pode resultar em colisões; portanto, tenha cuidado com esta abordagem. Para obter mais informações, consulte Tópicos avançados de segurança em nível de coluna.
CASE WHEN current_role() IN ('ANALYST') THEN val ELSE sha2(val) -- return hash of the column value END;
Aplicar uma máscara parcial ou máscara completa:
CASE WHEN current_role() IN ('ANALYST') THEN val WHEN current_role() IN ('SUPPORT') THEN regexp_replace(val,'.+\@','*****@') -- leave email domain unmasked ELSE '********' END;
Usando carimbos de data/hora.
case WHEN current_role() in ('SUPPORT') THEN val else date_from_parts(0001, 01, 01)::timestamp_ntz -- returns 0001-01-01 00:00:00.000 end;Importante
Atualmente, o Snowflake não oferece suporte a diferentes tipos de dados de entrada e saída em uma política de mascaramento, como a definição da política de mascaramento para apontar para um carimbo de data/hora e retornar uma cadeia de caracteres (por exemplo,
***MASKED***
); os tipos de dados de entrada e saída devem ser correspondentes.Uma alternativa é converter o valor real do carimbo de data/hora em um valor de carimbo de data/hora inventado. Para obter mais informações, consulte DATE_FROM_PARTS e CAST , ::.
Usando uma UDF:
CASE WHEN current_role() IN ('ANALYST') THEN val ELSE mask_udf(val) -- custom masking function END;
Em dados das variantes:
CASE WHEN current_role() IN ('ANALYST') THEN val ELSE OBJECT_INSERT(val, 'USER_IPADDRESS', '****', true) END;
Usando uma tabela de direitos personalizados. Observe o uso de EXISTS na cláusula WHEN. Use sempre EXISTS ao incluir uma subconsulta no corpo de política de mascaramento. Para obter mais informações sobre as subconsultas que o Snowflake suporta, consulte Como trabalhar com subconsultas.
CASE WHEN EXISTS (SELECT role FROM <db>.<schema>.entitlement WHERE mask_method='unmask' AND role = current_role()) THEN val ELSE '********' END;
Usando DECRYPT em dados previamente criptografados com ENCRYPT ou ENCRYPT_RAW, com uma frase secreta nos dados criptografados:
case when current_role() in ('ANALYST') then DECRYPT(val, $passphrase) else val -- shows encrypted value end;
Usando Como escrever UDFs de JavaScript em JSON (Variante):
Neste exemplo, uma UDF JavaScript esconde os dados de localização em uma cadeia de caracteres JSON. É importante definir o tipo de dados como VARIANT na UDF e a política de mascaramento. Se o tipo de dados na coluna da tabela, UDF e a assinatura da política de mascaramento não forem correspondentes, o Snowflake retorna uma mensagem de erro porque não consegue resolver o SQL.
-- Flatten the JSON data create or replace table <table_name> (v variant) as select value::variant from @<table_name>, table(flatten(input => parse_json($1):stationLocation)); -- JavaScript UDF to mask latitude, longitude, and location data CREATE OR REPLACE FUNCTION full_location_masking(v variant) RETURNS variant LANGUAGE JAVASCRIPT AS $$ if ("latitude" in V) { V["latitude"] = "**latitudeMask**"; } if ("longitude" in V) { V["longitude"] = "**longitudeMask**"; } if ("location" in V) { V["location"] = "**locationMask**"; } return V; $$; -- Grant UDF usage to ACCOUNTADMIN grant ownership on function FULL_LOCATION_MASKING(variant) to role accountadmin; -- Create a masking policy using JavaScript UDF create or replace masking policy json_location_mask as (val variant) returns variant -> CASE WHEN current_role() IN ('ANALYST') THEN val else full_location_masking(val) -- else object_insert(val, 'latitude', '**locationMask**', true) -- limited to one value at a time END;
Usando o tipo de dados GEOGRAPHY:
Neste exemplo, uma política de mascaramento usa a função TO_GEOGRAPHY para converter todos os dados GEOGRAPHY em uma coluna para um ponto fixo, a longitude e a latitude para Snowflake em San Mateo, Califórnia, para usuários cuja CURRENT_ROLE não seja
ANALYST
.create masking policy mask_geo_point as (val geography) returns geography -> case when current_role() IN ('ANALYST') then val else to_geography('POINT(-122.35 37.55)') end;Definir a política de mascaramento em uma coluna com o tipo de dados GEOGRAPHY e defina o valor GEOGRAPHY_OUTPUT_FORMAT para a sessão como
GeoJSON
:alter table mydb.myschema.geography modify column b set masking policy mask_geo_point; alter session set geography_output_format = 'GeoJSON'; use role public; select * from mydb.myschema.geography;O Snowflake retorna o seguinte:
---+--------------------+ A | B | ---+--------------------+ 1 | { | | "coordinates": [ | | -122.35, | | 37.55 | | ], | | "type": "Point" | | } | 2 | { | | "coordinates": [ | | -122.35, | | 37.55 | | ], | | "type": "Point" | | } | ---+--------------------+Os valores do resultado da consulta na coluna B dependem do valor do parâmetro GEOGRAPHY_OUTPUT_FORMAT para a sessão. Por exemplo, se o valor do parâmetro for definido como
WKT
, o Snowflake retorna o seguinte:alter session set geography_output_format = 'WKT'; select * from mydb.myschema.geography; ---+----------------------+ A | B | ---+----------------------+ 1 | POINT(-122.35 37.55) | 2 | POINT(-122.35 37.55) | ---+----------------------+
Para exemplos que utilizam outras funções de contexto e hierarquia de funções, consulte Tópicos avançados de segurança em nível de coluna.
Política de mascaramento condicional¶
O exemplo seguinte retorna dados não mascarados para usuários cuja CURRENT_ROLE é a função personalizada de admin
ou cujo valor na coluna de visibilidade é Public
. Todas as outras condições resultam em um valor fixo mascarado.
-- Conditional Masking 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;
O exemplo seguinte retorna dados não tokenizados para usuários cuja CURRENT_ROLE é a função personalizada de admin
ou cujo valor em uma outra coluna é Public
. Todas as outras condições resultam em um valor tokenizado.
-- Conditional Tokenization create masking policy de_email_visibility as (email varchar, visibility string) returns varchar -> case when current_role() = 'ADMIN' and visibility = 'Public' then de_email(email) else email -- sees tokenized data end;