

 O Amazon Redshift não permitirá mais a criação de UDFs do Python a partir do Patch 198. As UDFs do Python existentes continuarão a funcionar normalmente até 30 de junho de 2026. Para ter mais informações, consulte a [publicação de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). 

# Hierarquia de políticas de mascaramento dinâmico de dados
<a name="t_ddm-hierarchy"></a>

Ao anexar várias políticas de mascaramento, considere o seguinte:
+ É possível anexar várias políticas de mascaramento a uma única coluna.
+ Quando várias políticas de mascaramento são aplicáveis a uma consulta, a política de maior prioridade anexada a cada coluna respectiva se aplica. Considere o seguinte exemplo. 

  ```
  ATTACH MASKING POLICY partial_hash
  ON credit_cards(address, credit_card)
  TO ROLE analytics_role 
  PRIORITY 20;
  
  ATTACH MASKING POLICY full_hash
  ON credit_cards(credit_card, ssn)
  TO ROLE auditor_role 
  PRIORITY 30;
  
  SELECT address, credit_card, ssn
  FROM credit_cards;
  ```

  Ao executar a instrução SELECT, um usuário com os perfis de analista e auditor vê a coluna de endereços com a política de mascaramento `partial_hash` aplicada. Ele vê as colunas de cartão de crédito e SSN com a política de mascaramento `full_hash` aplicada, porque a política `full_hash` tem a prioridade mais alta na coluna do cartão de crédito.
+  Se você não especificar uma prioridade ao anexar uma política de mascaramento, a prioridade padrão será 0. 
+ Você não pode anexar duas políticas com a mesma prioridade à mesma coluna. 
+ Você não pode anexar duas políticas à mesma combinação de usuário e coluna ou função e coluna.
+ Quando várias políticas de mascaramento são aplicáveis ao longo do mesmo caminho SUPER enquanto anexadas ao mesmo usuário ou função, somente o anexo de prioridade mais alta entra em vigor. Considere os seguintes exemplos: 

  O primeiro exemplo mostra duas políticas de mascaramento anexadas no mesmo caminho, com a política de prioridade mais alta entrando em vigor. 

  ```
  ATTACH MASKING POLICY hide_name
  ON employees(col_person.name)
  TO PUBLIC
  PRIORITY 20;
  
  ATTACH MASKING POLICY hide_last_name
  ON employees(col_person.name.last)
  TO PUBLIC
  PRIORITY 30;
  
  --Only the hide_last_name policy takes effect.
  SELECT employees.col_person.name FROM employees;
  ```

  O segundo exemplo mostra duas políticas de mascaramento anexadas a caminhos diferentes no mesmo objeto SUPER, sem conflito entre as políticas. Ambos os anexos serão aplicados simultaneamente.

  ```
  ATTACH MASKING POLICY hide_first_name
  ON employees(col_person.name.first)
  TO PUBLIC
  PRIORITY 20;
  
  ATTACH MASKING POLICY hide_last_name
  ON employees(col_person.name.last)
  TO PUBLIC
  PRIORITY 20;
  
  --Both col_person.name.first and col_person.name.last are masked.
  SELECT employees.col_person.name FROM employees;
  ```

Para confirmar qual política de mascaramento se aplica a uma determinada combinação de usuário e coluna ou função, os usuários com a função [https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html) podem consultar o par de coluna/perfil ou coluna/usuário na exibição do sistema [SVV\$1ATTACHED\$1MASKING\$1POLICY](r_SVV_ATTACHED_MASKING_POLICY.md). Para obter mais informações, consulte [Visualizações do sistema de mascaramento dinâmico de dados](r_ddm-svv.md).