Tópicos avançados de segurança em nível de coluna¶

Uso de CURRENT_ROLE e IS_ROLE_IN_SESSION¶

Uma condição de política de mascaramento usando CURRENT_ROLE visa a sessão atual e não é afetada pelo contexto de execução da instrução SQL.

Se a ativação e a hierarquia de funções for necessária nas condições da política, use IS_ROLE_IN_SESSION.

Considere o seguinte corpo de política de mascaramento:

CREATE OR REPLACE MASKING POLICY mask_string AS
(val string) RETURNS string ->
CASE
  WHEN CURRENT_ROLE() IN ('ANALYST') THEN val
  ELSE '********'
END;

Copy

Para determinar se um usuário específico tem autorização para ver os dados em uma coluna onde esta política de mascaramento é definida nessa coluna, complete as seguintes etapas:

1. Avalie as condições da política de mascaramento.

2. Determine se a função especificada está na hierarquia CURRENT_ROLE.

3. Realize uma consulta de teste para verificar.

USE ROLE analyst;

SELECT * FROM mydb.mysch.mytable;

Uso de INVOKER_ROLE¶

Uma condição de política de mascaramento usando INVOKER_ROLE visa o contexto de execução da instrução SQL.

A tabela a seguir resume o contexto de execução e o valor que INVOKER_ROLE retorna em uma condição de política de mascaramento:

Considere o seguinte corpo de política de mascaramento que é aplicado a uma única exibição em uma tabela:

CREATE OR REPLACE MASKING POLICY mask_string AS
(val string) RETURNS string ->
CASE
  WHEN INVOKER_ROLE() IN ('ANALYST') THEN val
  ELSE '********'
END;

Copy

Para determinar se um usuário específico que executa uma consulta na coluna tem autorização para ver os dados, complete as seguintes etapas:

1. Avalie as condições da política de mascaramento.

2. Determine se a função especificada é proprietária da exibição.

3. Realize uma consulta de teste para verificar.

SHOW GRANTS OF ROLE analyst;

USE ROLE analyst;

SELECT * FROM mydb.mysch.myview;

Uso de IS_GRANTED_TO_INVOKER_ROLE¶

A função IS_GRANTED_TO_INVOKER_ROLE pode ser passada para um corpo de política de mascaramento como parte de uma condição. Quando a função é avaliada como TRUE, a função no argumento da função está na hierarquia INVOKER_ROLE.

Considere o seguinte corpo de política de mascaramento que é aplicado a uma coluna de exibição de números de previdência social (SSNs):

CREATE OR REPLACE MASKING POLICY mask_string AS
(val string) RETURNS string ->
CASE
  WHEN IS_GRANTED_TO_INVOKER_ROLE('PAYROLL') THEN val
  WHEN IS_GRANTED_TO_INVOKER_ROLE('ANALYST') THEN REGEXP_REPLACE(val, '[0-9]', '*', 7)
  ELSE '*******'
END;

Para determinar se um usuário específico que executa uma consulta na coluna de exibição tem autorização para ver os dados, complete as seguintes etapas:

1. Avalie as condições da política de mascaramento.

2. Determine se a função especificada está na hierarquia de funções do invocador. Por exemplo, se a política for definida em uma exibição, a função especificada deverá estar na hierarquia de funções do proprietário da exibição para retornar TRUE. Para obter mais detalhes, consulte notas de uso.

3. Realize uma consulta de teste para verificar.

USE ROLE payroll;

SELECT * FROM mydb.mysch.myview;

USE ROLE analyst;

SELECT * FROM mydb.mysch.myview;

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.

Antes de implementar qualquer uma destas funções em uma política de mascaramento, é importante considerar se seu caso de uso com estas funções envolve operações JOIN. Sob certas implementações de políticas de mascaramento, operações criativas JOIN que envolvem tabelas e exibições podem levar à engenharia reversa do valor mascarado ao seu verdadeiro valor com base na seguinte limitação:

• É possível que ocorram colisões porque pode não haver uma representação 1:1 do valor real (ou seja, entrada) e o valor com hash, criptografia ou soma de verificação baseado no número total de valores (ou seja, a saída, o intervalo de valores) a transformar.

Uma representação 1:1 é mais provável de ocorrer até que o número total de valores de entrada atinja a raiz quadrada dos valores de saída a transformar.

Por exemplo, se os valores de saída do hash forem 144, então é razoável esperar que os primeiros 12 valores (ou seja, 144^(1/2) – a raiz quadrada de 144) sejam únicos e que possam ocorrer colisões para os 132 valores restantes. Como esta limitação e sua consequência são possíveis, é aconselhável nunca utilizar funções com hashing, criptografia ou soma de verificação em políticas de mascaramento cujos valores podem ser utilizados em operações JOIN.