Uso do mascaramento dinâmico de dados¶
Este tópico fornece instruções sobre como configurar e usar o mascaramento dinâmico de dados no Snowflake.
Para saber mais sobre o uso de uma política de mascaramento com uma tag, consulte Políticas de mascaramento baseadas em tags.
Uso do mascaramento dinâmico de dados¶
A seguir são listadas as etapas de alto nível para configurar e usar o mascaramento dinâmico de dados no Snowflake:
Conceder privilégios de gerenciamento de políticas de mascaramento a uma função personalizada para um responsável por segurança ou privacidade.
Conceder a função personalizada aos usuários apropriados.
O responsável pela segurança ou privacidade cria e define políticas de mascaramento e as aplica a colunas com dados confidenciais.
Executar consultas no Snowflake. Observe o seguinte:
O Snowflake regrava dinamicamente a consulta aplicando a expressão SQL da política de mascaramento à coluna.
A regravação da coluna ocorre em todos os lugares onde a coluna especificada na política de mascaramento aparece na consulta (por exemplo, projeções, predicado de junção, predicado de cláusula where, order by e group by).
Os usuários veem os dados mascarados com base nas condições do contexto de execução definidas nas políticas de mascaramento. Para obter mais informações sobre o contexto de execução nas políticas de mascaramento dinâmico de dados, consulte Tópicos avançados de segurança em nível de coluna.
Etapa 1: Conceder privilégios de política de mascaramento para função personalizada¶
Um responsável por segurança ou privacidade deve servir como administrador da política de mascaramento (ou seja, função personalizada: MASKING_ADMIN
) e ter os privilégios de definir, gerenciar e aplicar políticas de mascaramento às colunas.
O Snowflake fornece os seguintes privilégios para conceder a um responsável por segurança ou privacidade para políticas de mascaramento de segurança em nível de coluna:
Privilégio |
Descrição |
---|---|
CREATE MASKING POLICY |
Este privilégio em nível de esquema controla quem pode criar políticas de mascaramento. |
APPLY MASKING POLICY |
Este privilégio em nível de conta controla quem pode definir ou remover políticas de mascaramento nas colunas e é concedido à função ACCOUNTADMIN por padrão. . Este privilégio só permite aplicar uma política de mascaramento a uma coluna e não fornece qualquer privilégio de tabela adicional descrito em Privilégios de controle de acesso. |
APPLY ON MASKING POLICY |
Opcional. Este privilégio em nível de política pode ser usado por um proprietário de política para descentralizar as operações definidas ou removidas de uma dada política de mascaramento em colunas para os proprietários do objeto (ou seja, a função que tem o privilégio OWNERSHIP sobre o objeto). . O Snowflake suporta o controle de acesso discricionário onde os proprietários de objetos também são considerados administradores de dados. . Se o administrador de políticas confia que os proprietários dos objetos sejam considerados administradores de dados para colunas protegidas, então o administrador de políticas pode usar este privilégio para descentralizar a aplicação de operações de definição e remoção de políticas. |
O exemplo seguinte cria a função MASKING_ADMIN
e concede privilégios de política de mascaramento a essa função.
Crie uma função personalizada de administrador de políticas de mascaramento:
use role useradmin; CREATE ROLE masking_admin;
Conceda privilégios à função masking_admin
:
use role securityadmin; GRANT CREATE MASKING POLICY on SCHEMA <db_name.schema_name> to ROLE masking_admin; GRANT APPLY MASKING POLICY on ACCOUNT to ROLE masking_admin;
Permita que a função table_owner
defina ou remova a política de mascaramento ssn_mask
(opcional):
GRANT APPLY ON MASKING POLICY ssn_mask to ROLE table_owner;
Onde:
db_name.schema_name
Especifica o identificador do esquema para o qual o privilégio deve ser concedido.
Para obter mais informações, consulte:
Etapa 2: Conceder a função personalizada a um usuário¶
Conceda a função personalizada MASKING_ADMIN
a um usuário que serve como responsável por segurança ou privacidade.
GRANT ROLE masking_admin TO USER jsmith;
Etapa 3: Criar uma política de mascaramento¶
Usando a função MASKING_ADMIN, crie uma política de mascaramento e aplique-a a uma coluna.
Neste exemplo representativo, os usuários com a função ANALYST veem o valor não mascarado. Usuários sem a função ANALYST 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;
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.
Etapa 4: Aplicar uma política de mascaramento a uma coluna de exibição ou tabela¶
Estes exemplos consideram que uma política de mascaramento não é aplicada à coluna de tabela quando a tabela é criada e à coluna de exibição quando a exibição é criada. Opcionalmente, você pode aplicar uma política de mascaramento a uma coluna da tabela quando criar a tabela com uma instrução CREATE TABLE ou uma coluna de exibição com uma instrução CREATE VIEW.
Execute as seguintes instruções para aplicar a política a uma coluna de tabela ou a uma coluna de exibição.
-- apply masking policy to a table column
ALTER TABLE IF EXISTS user_info MODIFY COLUMN email SET MASKING POLICY email_mask;
-- apply the masking policy to a view column
ALTER VIEW user_info_v MODIFY COLUMN email SET MASKING POLICY email_mask;
Etapa 5: Consultar dados no Snowflake¶
Execute duas consultas diferentes no Snowflake, uma consulta com a função ANALYST e outra consulta com uma função diferente, para verificar se os usuários sem a função ANALYST veem uma máscara completa.
-- using the ANALYST role
USE ROLE analyst;
SELECT email FROM user_info; -- should see plain text value
-- using the PUBLIC role
USE ROLE PUBLIC;
SELECT email FROM user_info; -- should see full data mask
Exemplos adicionais de políticas de mascaramento¶
A seguir estão exemplos adicionais e representativos que podem ser usados no corpo da política de mascaramento dinâmico de dados.
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 uma <JavaScript UDF em JSON (VARIANT):
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.
Próximos tópicos: