Visão geral Exemplo completo Considerações ao usar o mascaramento dinâmico de dados

Mascaramento dinâmico de dados

Visão geral

Usando o mascaramento dinâmico de dados (DDM) no Amazon Redshift, é possível proteger dados confidenciais no seu data warehouse. Você pode manipular a forma como o Amazon Redshift mostra dados confidenciais para o usuário no momento da consulta, sem transformá-los no banco de dados. Você controla o acesso aos dados por meio de políticas de mascaramento que aplicam regras de ofuscação personalizadas para determinado usuário ou perfil. Dessa forma, você pode responder às mudanças nos requisitos de privacidade sem alterar os dados subjacentes ou editar consultas SQL.

As políticas de mascaramento dinâmico de dados ocultam, ofuscam ou pseudonimizam dados que correspondem a determinado formato. Quando anexada a uma tabela, a expressão de mascaramento é aplicada a uma ou mais de suas colunas. Você pode modificar ainda mais as políticas de mascaramento para aplicá-las somente a determinados usuários, ou a perfis definidos por usuários que podem ser criados com Regras de controle de acesso com base em função (RBAC). Além disso, você pode aplicar o DDM em células usando colunas condicionais ao criar sua política de mascaramento. Para obter mais informações sobre o mascaramento condicional, consulte Mascaramento dinâmico de dados condicional.

Você pode aplicar várias políticas de mascaramento com níveis variados de ofuscação à mesma coluna em uma tabela e atribuí-las a diferentes perfis. Para evitar conflitos quando você tem perfis diferentes com políticas diferentes aplicadas a uma coluna, você pode definir prioridades para cada aplicação. Dessa forma, você pode controlar quais dados determinado usuário ou perfil pode acessar. As políticas de DDM podem redigir dados parcial ou completamente, ou aplicar hash neles usando funções definidas por usuários escritas em SQL, em Python ou com o AWS Lambda. Ao mascarar dados usando hashes, você pode aplicar uniões nesses dados sem acessar informações potencialmente confidenciais.

Exemplo completo

Veja a seguir um exemplo completo que mostra como criar e anexar políticas de mascaramento a uma coluna. Essas políticas permitem que os usuários acessem uma coluna e vejam valores diferentes, dependendo do grau de ofuscação nas políticas associadas aos seus perfis. Você deve ser um superusuário ou ter o perfil sys:secadmin para executar este exemplo.

Criar uma política de mascaramento

Primeiro, crie uma tabela e preencha-a com valores de cartões de crédito.


--create the table         
CREATE TABLE credit_cards (
  customer_id INT,
  credit_card TEXT
);

--populate the table with sample values
INSERT INTO credit_cards
VALUES
  (100, '4532993817514842'),
  (100, '4716002041425888'),
  (102, '5243112427642649'),
  (102, '6011720771834675'),
  (102, '6011378662059710'),
  (103, '373611968625635')
;

--run GRANT to grant permission to use the SELECT statement on the table
GRANT SELECT ON credit_cards TO PUBLIC;

--create two users
CREATE USER regular_user WITH PASSWORD '1234Test!';

CREATE USER analytics_user WITH PASSWORD '1234Test!';

--create the analytics_role role and grant it to analytics_user
--regular_user does not have a role
CREATE ROLE analytics_role;

GRANT ROLE analytics_role TO analytics_user;

Depois, crie uma política de mascaramento para aplicar ao perfil de análise.


--create a masking policy that fully masks the credit card number
CREATE MASKING POLICY mask_credit_card_full
WITH (credit_card VARCHAR(256))
USING ('000000XXXX0000'::TEXT);

--create a user-defined function that partially obfuscates credit card data
CREATE FUNCTION REDACT_CREDIT_CARD (credit_card TEXT)
RETURNS TEXT IMMUTABLE
AS $$
    import re
    regexp = re.compile("^([0-9]{6})[0-9]{5,6}([0-9]{4})")
 
    match = regexp.search(credit_card)
    if match != None:
        first = match.group(1)
        last = match.group(2)
    else:
        first = "000000"
        last = "0000"
    
    return "{}XXXXX{}".format(first, last)
$$ LANGUAGE plpythonu;

--create a masking policy that applies the REDACT_CREDIT_CARD function
CREATE MASKING POLICY mask_credit_card_partial
WITH (credit_card VARCHAR(256))
USING (REDACT_CREDIT_CARD(credit_card));

--confirm the masking policies using the associated system views
SELECT * FROM svv_masking_policy;

SELECT * FROM svv_attached_masking_policy;

Anexar uma política de mascaramento

Anexe as políticas de mascaramento à tabela de cartões de crédito.


--attach mask_credit_card_full to the credit card table as the default policy
--all users will see this masking policy unless a higher priority masking policy is attached to them or their role
ATTACH MASKING POLICY mask_credit_card_full
ON credit_cards(credit_card)
TO PUBLIC;

--attach mask_credit_card_partial to the analytics role
--users with the analytics role can see partial credit card information
ATTACH MASKING POLICY mask_credit_card_partial
ON credit_cards(credit_card)
TO ROLE analytics_role
PRIORITY 10;

--confirm the masking policies are applied to the table and role in the associated system view
SELECT * FROM svv_attached_masking_policy;

--confirm the full masking policy is in place for normal users by selecting from the credit card table as regular_user
SET SESSION AUTHORIZATION regular_user;

SELECT * FROM credit_cards;

--confirm the partial masking policy is in place for users with the analytics role by selecting from the credit card table as analytics_user
SET SESSION AUTHORIZATION analytics_user;

SELECT * FROM credit_cards;

Alterar uma política de mascaramento

A seção a seguir mostra como alterar uma política de mascaramento dinâmico de dados.


--reset session authorization to the default
RESET SESSION AUTHORIZATION;

--alter the mask_credit_card_full policy
ALTER MASKING POLICY mask_credit_card_full
USING ('00000000000000'::TEXT);	
	
--confirm the full masking policy is in place after altering the policy, and that results are altered from '000000XXXX0000' to '00000000000000'
SELECT * FROM credit_cards;

Desanexar e descartar uma política de mascaramento

A seção a seguir mostra como desanexar e descartar políticas de mascaramento removendo todas as políticas de mascaramento dinâmico de dados da tabela.


--reset session authorization to the default
RESET SESSION AUTHORIZATION;

--detach both masking policies from the credit_cards table
DETACH MASKING POLICY mask_credit_card_full 
ON credit_cards(credit_card) 
FROM PUBLIC;

DETACH MASKING POLICY mask_credit_card_partial 
ON credit_cards(credit_card) 
FROM ROLE analytics_role;

--drop both masking policies
DROP MASKING POLICY mask_credit_card_full;

DROP MASKING POLICY mask_credit_card_partial;

Considerações ao usar o mascaramento dinâmico de dados

Ao usar o mascaramento dinâmico de dados, considere o seguinte:

Ao consultar objetos criados com base em tabelas, como visualizações, os usuários verão os resultados com base em suas próprias políticas de mascaramento, não nas políticas do usuário que criou os objetos. Por exemplo, um usuário com o perfil de analista consultando uma visualização criada por um secadmin verá resultados com as políticas de mascaramento associadas ao perfil de analista.
Para evitar que o comando EXPLAIN exponha filtros confidenciais de políticas de mascaramento, somente usuários com a permissão SYS_EXPLAIN_DDM podem ver as políticas de mascaramento aplicadas nas saídas do EXPLAIN. Os usuários não têm a permissão SYS_EXPLAIN_DDM por padrão.

A sintaxe a seguir concede a permissão a um perfil.
```
GRANT EXPLAIN MASKING TO ROLE rolename
```
Para obter mais informações sobre o comando EXPLAIN, consulte EXPLAIN.
Usuários com perfis diferentes podem ver resultados diferentes com base nas condições do filtro ou nas condições de união usadas. Por exemplo, a execução de um comando SELECT em uma tabela usando um valor de coluna específico falhará se o usuário que executa o comando tiver uma política de mascaramento aplicada que ofusque essa coluna.
As políticas de DDM devem ser aplicadas antes de qualquer operação ou projeção de predicados. As políticas de mascaramento podem incluir o seguinte:
- Operações constantes de baixo custo, como converter um valor em nulo
- Operações de custo moderado, como hashing HMAC
- Operações de alto custo, como chamadas para funções externas do Lambda definidas por usuários
Assim, recomendamos o uso de expressões de mascaramento simples sempre que possível.
Você pode usar políticas de DDM para perfis com políticas de segurança por linha, mas observe que as políticas de RLS são aplicadas antes do DDM. Uma expressão de mascaramento de dados dinâmica não conseguirá ler uma linha protegida por RLS. Para obter mais informações sobre RLS, consulte Segurança por linha.
Ao usar o comando COPY para copiar de parquet para tabelas de destino protegidas, você deve especificar explicitamente as colunas na instrução COPY. Para obter mais informações sobre como mapear colunas com COPY, consulte Opções de mapeamento da coluna.
As políticas DDM não podem ser anexadas às seguintes relações:
- Tabelas e catálogos do sistema
- Tabelas externas
- Tabelas de compartilhamento de dados
- Visualizações materializadas
- Relações entre bancos de dados
- Tabelas temporárias
- Consultas correlacionadas
As políticas DDM podem conter tabelas de pesquisa. As tabelas de pesquisa podem estar presentes na cláusula USING. Os seguintes tipos de relação não podem ser usados como tabelas de pesquisa:
- Tabelas e catálogos do sistema
- Tabelas externas
- Tabelas de compartilhamento de dados
- Exibições, visões materializadas e exibições de vinculação tardia
- Relações entre bancos de dados
- Tabelas temporárias
- Consultas correlacionadas
Veja a seguir um exemplo de como anexar uma política de mascaramento a uma tabela de pesquisa.
```
--Create a masking policy referencing a lookup table
CREATE MASKING POLICY lookup_mask_credit_card WITH (credit_card TEXT) USING (
  CASE
    WHEN
      credit_card IN (SELECT credit_card_lookup FROM credit_cards_lookup)      
    THEN '000000XXXX0000'
    ELSE REDACT_CREDIT_CARD(credit_card)
    END
  ); 
  
--Provides access to the lookup table via a policy attached to a role
GRANT SELECT ON TABLE credit_cards_lookup TO MASKING POLICY lookup_mask_credit_card;
```
Você não pode anexar uma política de mascaramento que produza uma saída incompatível com o tipo e o tamanho da coluna de destino. Por exemplo, você não pode anexar uma política de mascaramento que gera uma string de 12 caracteres em uma coluna VARCHAR(10). O Amazon Redshift é compatível com as exceções a seguir:
- Uma política de mascaramento com o tipo de entrada INTN pode ser anexada a uma política com tamanho INTM, desde que M < N. Por exemplo, uma política de entrada BIGINT (INT8) pode ser anexada a uma coluna smallint (INT4).
- Uma política de mascaramento com o tipo de entrada NUMERIC ou DECIMAL sempre pode ser anexada a uma coluna FLOAT.
As políticas de DDM não podem ser usadas com o compartilhamento de dados. Se o produtor de dados da unidade de compartilhamento de dados anexar uma política de DDM a uma tabela na unidade de compartilhamento de dados, a tabela se tornará inacessível aos usuários do consumidor de dados que estão tentando consultar a tabela. Tabelas com políticas de DDM anexadas não podem ser adicionadas a uma unidade de compartilhamento de dados.
Você não poderá consultar relações que tenham políticas de DDM anexadas se os valores para qualquer uma das opções de configuração a seguir não corresponderem ao valor padrão da sessão:
- enable_case_sensitive_super_attribute
- enable_case_sensitive_identifier
- downcase_delimited_identifier
Considere redefinir as opções de configuração da sessão se você tentar consultar uma relação com uma política DDM anexada e vir a mensagem “DDM protected relation does not support session level config on case sensitivity being different from its default value”.
Quando o cluster provisionado ou namespace sem servidor tem alguma política de mascaramento dinâmico de dados, os seguintes comandos são bloqueados para usuários comuns:
```
ALTER <current_user> SET enable_case_sensitive_super_attribute/enable_case_sensitive_identifier/downcase_delimited_identifier
```
Ao criar políticas de DDM, recomendamos que você altere as definições de opções da configuração padrão para usuários comuns a fim de que correspondam às definições de opções da configuração da sessão no momento em que a política foi criada. Superusuários e usuários com o privilégio ALTER USER podem fazer isso usando as configurações do grupo de parâmetros ou o comando ALTER USER. Para obter informações sobre grupos de parâmetros, consulte Amazon Redshift parameter groups no Guia de gerenciamento do Amazon Redshift. Para obter mais informações sobre o comando ALTER USER, consulte ALTER USER.
As exibições e as exibições de vinculação tardia com políticas DDM não podem ser substituídas por usuários regulares usando o comando CREATE VIEW. Para substituir exibições ou LBVs por políticas DDM, primeiro desanexe todas as políticas DDM anexadas, substitua as exibições ou LBVs e reanexe as políticas. Os superusuários e usuários com a permissão sys:secadmin podem usar CREATE VIEW em exibições ou LBVs com políticas DDM sem desanexar as políticas.
As exibições com políticas DDM anexadas não podem referenciar tabelas e exibições de sistema. Exibições de vinculação tardia podem referenciar tabelas e exibições de sistema.
As exibições de vinculação tardia com políticas DDM anexadas não podem referenciar dados aninhados em data lakes, como documentos JSON.
As exibições de vinculação tardia não poderão ter políticas DDM anexadas se essa exibição de vinculação tardia for referenciada por qualquer exibição.
As políticas DDM anexadas às exibições de vinculação tardia são anexadas pelo nome da coluna. No momento da consulta, o Amazon Redshift valida se todas as políticas de mascaramento anexadas à exibição de vinculação tardia foram aplicadas com êxito e se o tipo de coluna de saída da exibição de vinculação tardia corresponde aos tipos nas políticas de mascaramento anexadas. Se a validação falhar, o Amazon Redshift retornará um erro para a consulta.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Segurança de metadados

Gerenciar políticas de mascaramento dinâmico de dados