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/).
# Segurança do banco de dados
Você gerencia a segurança do banco de dados controlando quais usuários têm acesso a quais objetos do banco de dados. É possível atribuir funções ou grupos aos usuários, e as permissões que você concede a usuários, funções ou grupos determinam quais objetos do banco de dados eles podem acessar.
**Topics**
+ [Visão geral da segurança do Amazon Redshift](c_security-overview.md)
+ [Permissões de usuário padrão do banco de dados](r_Privileges.md)
+ [superuser](r_superusers.md)
+ [Usuários](r_Users.md)
+ [Grupos](r_Groups.md)
+ [Esquemas](r_Schemas_and_tables.md)
+ [Regras de controle de acesso com base em função (RBAC)](t_Roles.md)
+ [Segurança por linha](t_rls.md)
+ [Segurança de metadados](t_metadata_security.md)
+ [Mascaramento dinâmico de dados](t_ddm.md)
+ [Permissões em escopo](t_scoped-permissions.md)
O acesso a objetos de banco de dados depende das permissões que você concede a usuários ou grupos. As seguintes diretrizes resumem como a segurança de banco de dados funciona:
+ Por padrão, as permissões são concedidas somente ao proprietário do objeto.
+ Os usuários do banco de dados Amazon Redshift são usuários nomeados que podem se conectar a um banco de dados. Um usuário recebe permissões de duas maneiras: explicitamente, com essas permissões atribuídas diretamente à conta, ou implicitamente, sendo um membro de um grupo que recebe permissões.
+ Os grupos são coleções de usuários que podem receber permissões coletivamente tendo em vista uma manutenção de segurança mais simplificada.
+ Esquemas são coleções de tabelas de bancos de dados e outros objetos de banco de dados. Os esquemas são semelhantes a diretórios de sistema de arquivos, exceto pelo fato de que esquemas não podem ser aninhados. Os usuários podem receber acesso a um único esquema ou a vários.
Além disso, o Amazon Redshift emprega os seguintes recursos para oferecer um controle mais preciso sobre quais usuários têm acesso a quais objetos do banco de dados:
+ O controle de acesso baseado em perfil (RBAC) permite atribuir permissões a perfis que podem ser aplicados aos usuários, permitindo que você controle as permissões para grandes grupos de usuários. Ao contrário dos grupos, perfis podem herdar permissões de outros perfis.
A segurança por linha (RLS) permite definir políticas que restringem o acesso às linhas de sua escolha, depois aplicar essas políticas a usuários ou grupos.
O mascaramento dinâmico de dados (DDM) protege ainda mais seus dados ao transformá-los no runtime de consulta para que você possa permitir que os usuários acessem os dados sem expor detalhes confidenciais.
Para obter exemplos de implementação de segurança, consulte [Exemplo para controlar acesso de usuário e grupo](t_user_group_examples.md).
Para obter mais informações sobre como proteger seus dados, consulte “[Segurança no Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/iam-redshift-user-mgmt.html)” no *Guia de gerenciamento de clusters do Amazon Redshift*.
# Visão geral da segurança do Amazon Redshift
A segurança do banco de dados do Amazon Redshift é diferente de outros tipos de segurança do Amazon Redshift. Além da segurança do banco de dados, que é descrita nesta seção, o Amazon Redshift fornece estes recursos para gerenciar a segurança:
+ **Credenciais de login**: o acesso ao Console de Gerenciamento da AWS do Amazon Redshift é controlado pelos privilégios da sua conta da AWS. Para obter mais informações, consulte [Credenciais de login](https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html).
+ **Gerenciamento de acesso** — Para controlar o acesso a recursos específicos do Amazon Redshift, defina contas do AWS Identity and Access Management (IAM). (Para obter mais informações, consulte [Controlar o acesso aos recursos do Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/iam-redshift-user-mgmt.html).
+ **Grupos de segurança do cluster** — Para conceder acesso de entrada de outros usuários a um cluster do Amazon Redshift, você define um grupo de segurança de cluster e o associa a um cluster. Para obter mais informações, consulte [Grupos de segurança do cluster do Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-security-groups.html).
+ **VPC** — Para proteger o acesso ao seu cluster usando um ambiente de rede virtual, você pode iniciar seu cluster em uma Amazon Virtual Private Cloud (VPC). Para obter mais informações, consulte [Gerenciar clusters na Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-clusters-vpc.html).
+ **Criptografia de cluster**: para criptografar os dados em todas as tabelas criadas pelo usuário, você pode ativar a criptografia de cluster ao iniciar o cluster. Para obter mais informações, consulte [Clusters do Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html).
+ **Conexões SSL** — Para criptografar a conexão entre o cliente SQL e o cluster, você pode usar a criptografia Secure Sockets Layer (SSL). Para obter mais informações, consulte [Conectar-se ao cluster usando SSL](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-ssl-support.html).
+ **Criptografia dos dados de carga** — para criptografar seus arquivos de dados de carga de tabela ao carregá-los no Amazon S3, você pode usar criptografia do lado do servidor ou criptografia do lado do cliente. Quando você carrega dados criptografados do lado do servidor, o Amazon S3 lida com a descriptografia de forma transparente. Quando você carrega a partir de dados criptografados do lado do cliente, o comando Amazon Redshift COPY descriptografa os dados conforme carrega a tabela. Para obter mais informações, consulte [Carregamento de dados criptografados para Amazon S3](t_uploading-encrypted-data.md).
+ **Dados em trânsito**: para proteger seus dados em trânsito na nuvem da AWS, o Amazon Redshift usa SSL acelerado por hardware para se comunicar com o Amazon S3 ou Amazon DynamoDB para operações de COPY, UNLOAD, backup e restauração.
+ **Controle de acesso em nível de coluna**: para ter controle de acesso em nível de coluna para dados no Amazon Redshift, use as declarações de concessão e revogação em nível de coluna sem ter que implementar controle de acesso baseado em exibições ou usar outro sistema.
+ **Controle de segurança por linha**: para ter controle de segurança por linha para dados no Amazon Redshift, crie e anexe políticas a perfis ou usuários que restrinjam o acesso às linhas definidas na política.
# Permissões de usuário padrão do banco de dados
Ao criar um objeto de banco de dados, você é o proprietário. Por padrão, somente um superusuário ou o proprietário de um objeto pode consultar, modificar ou conceder permissões em relação ao objeto. Para que os usuários utilizem um objeto, você deve conceder as permissões necessárias ao o usuário ou ao grupo que contém o usuário. Os superusuários do banco de dados têm as mesmas permissões de proprietários do banco de dados.
O Amazon Redshift oferece suporte às seguintes permissões: SELECT, INSERT, UPDATE, DELETE, REFERENCES, CREATE, TEMPORARY e USAGE. As permissões diferentes são associadas a tipos de objeto diferentes. Para obter informações sobre permissões do objeto de banco de dados compatíveis com o Amazon Redshift, consulte o comando [GRANT](r_GRANT.md).
Somente o proprietário tem permissão para modificar ou destruir um objeto.
Por padrão, todos os usuários têm permissões CREATE e USAGE no esquema PUBLIC de um banco de dados. Para impedir que usuários criem objetos no esquema PUBLIC de um banco de dados, use o comando REVOKE para remover essa permissão.
Para revogar uma permissão que tenha sido concedida anteriormente, use o comando [REVOKE](r_REVOKE.md). As permissões do proprietário do objeto, como DROP, GRANT e REVOKE, são implícitas e não podem ser concedidas ou revogadas. Os proprietários de objeto podem revogar as próprias permissões fundamentais, por exemplo, para tornar uma tabela somente leitura para eles e para os outros. Os superusuários têm todas as permissões, independentemente de comandos GRANT e REVOKE.
# Superusuários
Os superusuários do banco de dados têm as mesmas permissões dos proprietários de todos os bancos de dados.
O usuário *administrador*, que é o usuário que você criou ao iniciar o cluster, é um superusuário.
Você deve ser um superusuário para criar outro.
As tabelas e visualizações do sistema do Amazon Redshift são visíveis apenas para superusuários ou para todos os usuários. Somente superusuários podem consultar tabelas e exibições do sistema designadas como “visíveis para superusuários”. Para mais informações, consulte [Visualizações de monitoramento de SYS](serverless_views-monitoring.md).
Os superusuários podem visualizar todas as tabelas do catálogo. Para mais informações, consulte [Tabelas de catálogo do sistema](c_intro_catalog_views.md).
Um superusuário de banco de dados ignora todas as verificações de permissão. Os superusuários têm todas as permissões, independentemente de comandos GRANT e REVOKE. Tenha cuidado ao usar um perfil de superusuário. Recomendamos que faça a maior parte do seu trabalho com uma função que não a de superusuário. É possível criar um perfil de administrador com permissões mais restritivas. Para obter mais informações sobre como criar funções, consulte [Regras de controle de acesso com base em função (RBAC)](t_Roles.md).
Para criar um novo superusuário do banco de dados, faça login no banco de dados como superusuário e emita um comando CREATE USER ou um comando ALTER USER com a permissão CREATEUSER.
```
CREATE USER adminuser CREATEUSER PASSWORD '1234Admin';
ALTER USER adminuser CREATEUSER;
```
Para criar, alterar ou soltar um superusuário, use os mesmos comandos para gerenciar usuários. Para obter mais informações, consulte [Criar, alterar e excluir usuários](r_Users-creatingaltering-and-deleting-users.md).
# Usuários
Você pode criar e gerenciar usuários de banco de dados usando os comandos de SQL do Amazon Redshift CREATE USER e ALTER USER. Ou você pode configurar seu cliente SQL com drivers JDBC ou ODBC personalizados do Amazon Redshift. Eles gerenciam o processo de criação de usuários de banco de dados e senhas temporárias como parte do processo de logon do banco de dados.
Os drivers autenticam os usuários de banco de dados com base na autenticação do AWS Identity and Access Management (IAM). Se você já gerencia identidades de usuário fora da AWS, pode usar um provedor de identidades (IdP) compatível com SAML 2.0 para gerenciar o acesso aos recursos do Amazon Redshift. Use uma função do IAM para configurar o IdP e a AWS para permitir que os usuários federados gerem credenciais de banco de dados temporárias e façam logon nos bancos de dados do Amazon Redshift. Para obter mais informações, consulte [Uso da autenticação do IAM para gerar credenciais do usuário do banco de dados](https://docs.aws.amazon.com/redshift/latest/mgmt/generating-user-credentials.html).
Os usuários do Amazon Redshift podem ser criados e descartados somente por um superusuário do banco de dados. Os usuários são autenticados quando fazem login no Amazon Redshift. Eles podem possuir bancos de dados e objetos de banco de dados (por exemplo, tabelas). Eles também podem conceder permissões nesses objetos a usuários, grupos e esquemas para controlar quem tem acesso a qual objeto. Os usuários com direitos CREATE DATABASE podem criar bancos de dados e conceder permissões a esses bancos de dados. Os superusuários têm permissões de propriedade em todos os bancos de dados.
# Criar, alterar e excluir usuários
Os usuários do banco de dados são globais em um cluster de data warehouse (e não em cada banco de dados individual).
+ Para criar um usuário, utilize o comando [CREATE USER](r_CREATE_USER.md).
+ Para criar um superusuário, utilize o comando [CREATE USER](r_CREATE_USER.md) com a opção CREATEUSER.
+ Para remover um usuário existente, use o comando [DROP USER](r_DROP_USER.md).
+ Para alterar um usuário, por exemplo, alterar uma senha, use o comando [ALTER USER](r_ALTER_USER.md).
+ Para exibir uma lista de usuários, consulte a tabela do catálogo PG\$1USER.
```
select * from pg_user;
usename | usesysid | usecreatedb | usesuper | usecatupd | passwd | valuntil | useconfig
------------+----------+-------------+----------+-----------+----------+----------+-----------
rdsdb | 1 | t | t | t | ******** | |
masteruser | 100 | t | t | f | ******** | |
dwuser | 101 | f | f | f | ******** | |
simpleuser | 102 | f | f | f | ******** | |
poweruser | 103 | f | t | f | ******** | |
dbuser | 104 | t | f | f | ******** | |
(6 rows)
```
# Grupos
Grupos são coleções de usuários que recebem todas as permissões associadas ao grupo. Você pode usar grupos para atribuir permissões. Por exemplo, você pode criar grupos diferentes para vendas, administração e suporte e dar aos usuários em cada grupo o acesso apropriado aos dados necessários para o trabalho. Você pode conceder ou revogar permissões no nível do grupo, e essas alterações serão aplicadas a todos os membros do grupo, exceto superusuários.
Para exibir todos os grupos de usuários, consulte a lista de catálogo do sistema PG\$1GROUP:
```
select * from pg_group;
```
Por exemplo, para listar todos os usuários do banco de dados por grupo, execute o SQL a seguir.
```
SELECT u.usesysid
,g.groname
,u.usename
FROM pg_user u
LEFT JOIN pg_group g ON u.usesysid = ANY (g.grolist)
```
# Criar, alterar e excluir grupos
Somente um superusuário pode criar, alterar ou descartar grupos.
Você pode realizar as seguintes ações:
+ Para criar um grupo, use o comando [CREATE GROUP](r_CREATE_GROUP.md).
+ Para adicionar ou remover usuários de um grupo existente, use o comando [ALTER GROUP](r_ALTER_GROUP.md).
+ Para excluir um grupo, use o comando [DROP GROUP](r_DROP_GROUP.md). Esse comando descarta somente o grupo, e não os usuários membros.
# Exemplo para controlar acesso de usuário e grupo
Esse exemplo cria usuários e grupos de usuários e, depois, concede a eles várias permissões para um banco de dados do Amazon Redshift que se conecta a um cliente de aplicação web. Este exemplo pressupõe três grupos de usuários: usuários regulares de uma aplicação Web, usuários avançados de uma aplicação Web e desenvolvedores Web.
Para obter informações sobre como remover um usuário de um grupo, consulte [ALTER GROUP](r_ALTER_GROUP.md).
1. Crie os grupos aos quais os usuários serão atribuídos. O seguinte conjunto de comandos criam três grupos de usuários diferentes:
```
create group webappusers;
create group webpowerusers;
create group webdevusers;
```
1. Crie diversos usuários de banco de dados com permissões diferentes e os adicione aos grupos.
1. Crie dois usuários e os adicione ao grupo WEBAPPUSERS:
```
create user webappuser1 password 'webAppuser1pass'
in group webappusers;
create user webappuser2 password 'webAppuser2pass'
in group webappusers;
```
1. Crie um usuário de desenvolvedor da web e adicione-o ao grupo WEBDEVUSERS:
```
create user webdevuser1 password 'webDevuser2pass'
in group webdevusers;
```
1. Crie um superusuário. Esse usuário terá direitos administrativos para criar outros usuários:
```
create user webappadmin password 'webAppadminpass1'
createuser;
```
1. Crie um esquema a ser associado às tabelas de bancos de dados usadas pela aplicação Web e conceda acesso a este esquema aos diversos grupos de usuários:
1. Crie o esquema WEBAPP:
```
create schema webapp;
```
1. Conceda permissões USAGE ao grupo WEBAPPUSERS:
```
grant usage on schema webapp to group webappusers;
```
1. Conceda permissões USAGE ao grupo WEBPOWERUSERS:
```
grant usage on schema webapp to group webpowerusers;
```
1. Conceda permissões ALL ao grupo WEBDEVUSERS:
```
grant all on schema webapp to group webdevusers;
```
Agora os usuários e os grupos básicos estão configurados. Você já pode alterar os usuários e os grupos.
1. Por exemplo, o comando a seguir altera o parâmetro search\$1path do WEBAPPUSER1.
```
alter user webappuser1 set search_path to webapp, public;
```
SEARCH\$1PATH especifica a ordem de pesquisa do esquema de objetos de banco de dados, como tabelas e funções, quando o objeto é referenciado por um nome simples sem esquema especificado.
1. Você também poderá adicionar usuários a um grupo depois ter criado o grupo, como adicionar WEBAPPUSER2 ao grupo WEBPOWERUSERS:
```
alter group webpowerusers add user webappuser2;
```
# Esquemas
Um banco de dados contém um ou mais esquemas nomeados. Cada esquema em um banco de dados contém tabelas e outros tipos de objetos nomeados. Por padrão, um banco de dados tem um único esquema, chamado PUBLIC. Você pode usar esquemas para agrupar objetos de banco de dados sob um mesmo nome. Os esquemas são semelhantes a diretórios de sistema de arquivos, exceto pelo fato de que esquemas não podem ser aninhados.
É possível usar nomes de objeto de banco de dados idênticos em esquemas diferentes no mesmo banco de dados sem conflito. Por exemplo, MY\$1SCHEMA e YOUR\$1SCHEMA podem conter uma tabela chamada MYTABLE. Os usuários com as permissões necessáriss podem acessar objetos em vários esquemas em um banco de dados.
Por padrão, um objeto é criado dentro do primeiro esquema no caminho de pesquisa do banco de dados. Para obter informações, consulte [Caminho de pesquisa](#c_Search_path) posteriormente nesta seção.
Os esquemas podem ajudar em problemas de organização e simultaneidade em um ambiente de vários usuários das seguintes maneiras:
+ Para permitir que muitos desenvolvedores trabalhem no mesmo banco de dados sem interferência entre si.
+ Para organizar objetos de banco de dados em grupos lógicos para torná-los mais gerenciáveis.
+ Para permitir que as aplicações tenham a possibilidade de colocar objetos em esquemas separados, de maneira que os nomes não colidam com nomes de objetos usados por outros aplicativos.
## Caminho de pesquisa
O caminho de pesquisa é definido no parâmetro search\$1path com uma lista de nomes de esquema separados por vírgulas. O caminho de pesquisa especifica a ordem na qual os esquemas são pesquisados quando um objeto, como uma tabela ou uma função, é referenciado por um nome simples que não inclui um qualificador de esquema.
Se for criado sem especificar um esquema de destino, o objeto será adicionado ao primeiro esquema listado no caminho de pesquisa. Quando houver objetos com nomes idênticos em esquemas diferentes, um nome de objeto que não especificar um esquema irá se referir ao primeiro esquema no caminho de pesquisa que contenha um objeto com esse nome.
Para alterar o esquema padrão da sessão atual, use o comando [SET](r_SET.md).
Para obter mais informações, consulte a descrição [search\$1path](r_search_path.md) na Referência de configuração.
# Criar, alterar e excluir esquemas
Qualquer usuário pode criar esquemas e alterar ou descartar esquemas próprios.
Você pode realizar as seguintes ações:
+ Para criar um esquema, use o comando [CREATE SCHEMA](r_CREATE_SCHEMA.md).
+ Para alterar o proprietário de um esquema, use o comando [ALTER SCHEMA](r_ALTER_SCHEMA.md).
+ Para excluir um esquema e os objetos, use o comando [DROP SCHEMA](r_DROP_SCHEMA.md).
+ Para criar uma tabela dentro de um esquema, crie a tabela com o formato *nome\$1do\$1esquema.nome\$1da\$1tabela.*
Para exibir uma lista de todos os esquemas, consulte a tabela de catálogo do sistema PG\$1NAMESPACE:
```
select * from pg_namespace;
```
Para exibir uma lista de tabelas que pertençam a um esquema, consulte a tabela de catálogo do sistema PG\$1TABLE\$1DEF. Por exemplo, a consulta a seguir retorna uma lista de tabelas no esquema PG\$1CATALOG.
```
select distinct(tablename) from pg_table_def
where schemaname = 'pg_catalog';
```
# Permissões baseadas em esquemas
As permissões baseadas em esquema são determinadas pelo proprietário do esquema:
+ Por padrão, todos os usuários têm permissões CREATE e USAGE no esquema PUBLIC de um banco de dados. Para impedir que usuários criem objetos no esquema PUBLIC de um banco de dados, use o comando [REVOKE](r_REVOKE.md) para remover essa permissão.
+ A menos que recebam a permissão USAGE pelo proprietário do objeto, os usuários não podem acessar objetos em esquemas que não possuam.
+ Se tiverem concedido a permissão CREATE a um esquema criado por outro usuário, os usuários poderão criar objetos nesse esquema.
# Regras de controle de acesso com base em função (RBAC)
Com o uso do controle de acesso baseado em função (RBAC) para gerenciar permissões de banco de dados no Amazon Redshift, você pode simplificar o gerenciamento de permissões de segurança no Amazon Redshift. Você pode proteger o acesso a dados confidenciais controlando o que os usuários podem fazer tanto em um nível amplo quanto mais preciso. Você também pode controlar o acesso do usuário a tarefas que normalmente são restritas a superusuários. Ao atribuir permissões diferentes a funções diferentes e atribuí-las a usuários diferentes, você pode ter um controle mais granular do acesso do usuário.
Os usuários com uma função atribuída podem executar somente as tarefas especificadas pela função atribuída com a qual estão autorizados. Por exemplo, um usuário com a função atribuída que tem as permissões CREATE TABLE e DROP TABLE só está autorizado a executar essas tarefas. Você pode controlar o acesso de usuários, concedendo diferentes níveis de permissões de segurança a diferentes usuários para acessar os dados necessários para o trabalho.
O RBAC aplica o princípio de permissões mínimas aos usuários com base em seus requisitos de função, independentemente dos tipos de objetos envolvidos. A concessão e revogação de permissões é realizada no nível da função, sem a necessidade de atualizar permissões em objetos de banco de dados individuais.
Com o RBAC, você pode criar funções com permissões para executar comandos que costumavam exigir permissões de superusuário. Os usuários podem executar esses comandos, desde que sejam autorizados com uma função que inclua essas permissões. Da mesma forma, você também pode criar funções para limitar o acesso a determinados comandos e atribuir a função a superusuários ou usuários que foram autorizados com a função.
Para saber como o RBAC funciona no Amazon Redshift, assista ao vídeo a seguir.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/IhHQ7mZ-tp4)
# Hierarquia de funções
*Funções* são coleções de permissões que você pode atribuir a um usuário ou outra função. Você pode atribuir permissões de sistema ou banco de dados a uma função. Um usuário herda permissões de uma função atribuída.
No RBAC, os usuários podem ter funções aninhadas. Você pode conceder funções a usuários e funções. Ao conceder um perfil a um usuário, você autoriza o usuário com todas as permissões que esse perfil inclui. Ao conceder uma função r1 a um usuário, você autoriza o usuário com permissões de r1. O usuário agora tem permissões de r1 e também todas as permissões existentes que ele já possui.
Ao conceder uma função (r1) a uma outra função (r2), você autoriza r2 com todas as permissões de r1. Além disso, ao conceder r2 a outra função (r3), as permissões de r3 são a combinação das permissões de r1 e r2. A hierarquia de funções tem permissões de herdar de r2 de r1. O Amazon Redshift propaga permissões com cada autorização de função. Conceder r1 para r2 e, em seguida, r2 para r3, autoriza r3 com todas as permissões das três funções. Assim, ao conceder r3 a um usuário, o usuário tem todas as permissões das três funções.
O Amazon Redshift não permite a criação de um ciclo de autorização de função. Um ciclo de autorização de função ocorre quando uma função aninhada é atribuída de volta a uma função anteriormente na hierarquia de funções, como r3 sendo atribuído de volta a r1. Para obter mais informações sobre como criar e gerenciar atribuições de perfis, consulte [Gerenciamento de funções no RBAC](r_roles-managing.md).
# Atribuição de função
Superusuários e usuários regulares com as permissões CREATE ROLE podem usar a instrução CREATE ROLE para criar funções. Superusuários e administradores de função podem usar a instrução GRANT ROLE para conceder uma função a outras pessoas. Eles podem usar a instrução REVOKE ROLE para revogar uma função de outras pessoas e a instrução DROP ROLE para descartar funções. Os administradores de perfis incluem proprietários de perfis e usuários que receberam o perfil com a permissão ADMIN OPTION.
Somente superusuários ou administradores de função podem conceder e revogar funções. Você pode conceder ou revogar uma ou mais funções para ou de uma ou mais funções ou usuários. Use a opção WITH ADMIN OPTION na instrução GRANT ROLE para fornecer as opções de administração para todas as funções concedidas a todos os beneficiários.
O Amazon Redshift oferece suporte a diferentes combinações de atribuições de função, como conceder várias funções ou ter vários beneficiários. WITH ADMIN OPTION só se aplica a usuários, e não a funções. Da mesma forma, use a opção WITH ADMIN OPTION na instrução REVOKE ROLE para remover a função e a autorização administrativa do beneficiário. Quando usado com ADMIN OPTION, somente a autorização administrativa é revogada da função.
O exemplo a seguir revoga a autorização administrativa da função `sample_role2` de `user2`.
```
REVOKE ADMIN OPTION FOR sample_role2 FROM user2;
```
Para obter mais informações sobre como criar e gerenciar atribuições de perfis, consulte [Gerenciamento de funções no RBAC](r_roles-managing.md).
# Funções definidas pelo sistema do Amazon Redshift
O Amazon Redshift fornece algumas funções definidas pelo sistema que são definidas com permissões específicas. Funções específicas do sistema começam com um prefixo `sys:`. Somente usuários com acesso apropriado podem alterar funções definidas pelo sistema ou criar funções personalizadas definidas pelo sistema. Não é possível usar o prefixo `sys:` para uma função definida pelo sistema personalizada.
A tabela a seguir resume as funções e suas permissões.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/r_roles-default.html)
## Usuários e perfis definidos pelo sistema para compartilhamento de dados
O Amazon Redshift cria perfis e usuários para uso interno que correspondem a unidades de compartilhamento de dados e os respectivos consumidores. O nome de cada perfil e usuário internos tem o prefixo de namespace reservado `ds:`. Eles têm o seguinte formato:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/r_roles-default.html)
É criado um perfil de compartilhamento de dados para cada unidade de compartilhamento de dados. Ele contém todas as permissões atualmente concedidas à unidade de compartilhamento de dados. É criado um usuário de compartilhamento de dados para cada consumidor de uma unidade de compartilhamento de dados. Ele recebe permissão para um único perfil de compartilhamento de dados. Um consumidor adicionado a várias unidades de compartilhamento de dados terá um usuário criado para cada unidade de compartilhamento de dados.
Esses usuários e perfis são necessários para que o compartilhamento de dados funcione corretamente. Eles não podem ser modificados nem eliminados e não podem ser acessados nem usados para nenhuma tarefa realizada pelos clientes. É possível ignorá-los com segurança. Para ter mais informações, consulte [Compartilhar dados entre clusters no Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/datashare-overview.html).
**nota**
Não é possível usar o prefixo `ds:` para criar usuários ou perfis definidos pelo usuário.
# Permissões do sistema para RBAC
A seguir, uma lista de permissões do sistema que podem ser concedidas ou revogadas de uma função.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/r_roles-system-privileges.html)
# Permissões de objetos do banco de dados
Além das permissões do sistema, o Amazon Redshift inclui permissões de objeto de banco de dados que definem as opções. Isso inclui opções como capacidade de leitura de dados em tabelas e exibições, gravação de dados, criação de tabelas e descarte de tabelas. Para obter mais informações, consulte [GRANT](r_GRANT.md).
Usando o RBAC, você pode atribuir permissões de objeto de banco de dados a funções, de forma semelhante a como você faz com as permissões do sistema. Em seguida, você pode atribuir funções a usuários, autorizar usuários com permissões do sistema e autorizar usuários com permissões do banco de dados.
# ALTER DEFAULT PRIVILEGES para o RBAC
Use a instrução ALTER DEFAULT PRIVILEGES para definir o conjunto padrão de permissões de acesso a serem aplicadas a objetos criados no futuro pelo usuário especificado. Por padrão, os usuários podem alterar somente suas próprias permissões de acesso padrão. Com o RBAC, você pode definir as permissões de acesso padrão para funções. Para obter mais informações, consulte o comando [ALTER DEFAULT PRIVILEGES](r_ALTER_DEFAULT_PRIVILEGES.md).
O RBAC permite que você atribua permissões de objeto de banco de dados a funções, de forma semelhante a permissões do sistema. Em seguida, você pode atribuir funções a usuários, autorizar usuários com permissões do sistema e/ou do banco de dados.
# Considerações sobre o uso de funções no RBAC
Ao trabalhar com funções do RBAC, considere o seguinte:
+ O Amazon Redshift não permite ciclos de autorizações de funções. Você não pode conceder r1 a r2 e, em seguida, conceder r2 a r1.
+ O RBAC funciona tanto para objetos nativos do Amazon Redshift quanto para tabelas do Amazon Redshift Spectrum.
+ Como administrador do Amazon Redshift, você pode ativar o RBAC atualizando seu cluster para o patch de manutenção mais recente para começar.
+ Somente superusuários e usuários com a permissão do sistema CREATE ROLE podem criar funções.
+ Somente superusuários ou administradores de função podem modificar e descartar funções.
+ Um nome de função não pode ser o mesmo que um nome de usuário.
+ Um nome de função não pode conter caracteres inválidos, como “:/\$1n.”
+ Um nome de função não pode ser uma palavra reservada, como PUBLIC.
+ O nome da função não pode começar com o prefixo reservado para funções padrão, `sys:`.
+ Você não pode descartar uma função que tenha o parâmetro RESTRICT quando ela estiver concedida a outra função. A configuração padrão é RESTRICT. O Amazon Redshift emite um erro quando você tenta eliminar uma função que tenha herdado outra função.
+ Usuários que não têm permissões de administrador em uma função não podem conceder ou revogar uma função.
+ O controle de acesso por perfil (RBAC) não é totalmente compatível com tabelas e visualizações do sistema. As permissões do RBAC para tabelas e visualizações do sistema não persistem por meio de atualizações, reversões para versões anteriores ou redimensionamentos. Recomendamos usar [Funções definidas pelo sistema do Amazon RedshiftUsuários e perfis definidos pelo sistema para compartilhamento de dados](r_roles-default.md) para gerenciar a tabela do sistema e visualizar as permissões. Para ter mais informações sobre tabelas do sistema, acesse [Referência de visualizações e tabelas do sistema](cm_chap_system-tables.md).
# Gerenciamento de funções no RBAC
Para executar as seguintes ações, use os seguintes comandos:
+ Para criar uma função, use o comando [CREATE ROLE](r_CREATE_ROLE.md).
+ Para renomear uma função ou alterar o proprietário da função, use o comando [ALTER ROLE](r_ALTER_ROLE.md).
+ Para excluir uma função, use o comando [DROP ROLE](r_DROP_ROLE.md).
+ Para conceder uma função a um usuário, use o comando [GRANT](r_GRANT.md).
+ Para revogar uma função de um usuário, use o comando [REVOKE](r_REVOKE.md).
+ Para conceder permissões do sistema a uma função, use o comando [GRANT](r_GRANT.md).
+ Para revogar permissões do sistema de uma função, use o comando [REVOKE](r_REVOKE.md).
Para exibir uma lista de funções no cluster ou no grupo de trabalho, consulte[SVV\$1ROLES](r_SVV_ROLES.md).
# Tutorial: Criar funções e consultar com o RBAC
Com o RBAC, você pode criar funções com permissões para executar comandos que costumavam exigir permissões de superusuário. Os usuários podem executar esses comandos, desde que sejam autorizados com uma função que inclua essas permissões.
Neste tutorial, você usa o controle de acesso por função (RBAC) para gerenciar permissões em um banco de dados que você cria. Em seguida, você se conecta ao banco de dados e o consulta usando duas funções diferentes para testar a funcionalidade de RBAC.
As duas funções que você cria e usa para consultar o banco de dados são `sales_ro` e `sales_rw`. Você cria a função `sales_ro` e consulta os dados como um usuário com a função `sales_ro`. O usuário `sales_ro` pode usar o comando SELECT, mas não pode usar o comando UPDATE. Em seguida, você cria a função `sales_rw` e consulta os dados como um usuário com a função `sales_rw`. O usuário `sales_rw` pode usar o comando SELECT e o comando UPDATE.
Além disso, você também pode criar funções para limitar o acesso a determinados comandos e atribuir a função a superusuários ou usuários.
**Tarefas**
+ [Pré-requisitos](#tutorial-rbac-prereqs)
+ [Etapa 1: Criar um usuário administrador](#tutorial-rbac-step1)
+ [Etapa 2: Configurar esquemas](#tutorial-rbac-step2)
+ [Etapa 3: Criar um usuário somente leitura](#tutorial-rbac-step3)
+ [Etapa 4: Consultar os dados como usuário somente leitura](#tutorial-rbac-step4)
+ [Etapa 5: Criar um usuário de leitura e gravação](#tutorial-rbac-step5)
+ [Etapa t: Consultar os dados como o usuário com a função somente leitura herdada](#tutorial-rbac-step6)
+ [Etapa 7: Conceder permissões de atualização e inserção à função de leitura e gravação](#tutorial-rbac-step7)
+ [Etapa 8: Consultar os dados como o usuário de leitura e gravação](#tutorial-rbac-step8)
+ [Etapa 9: Analisar e limpar tabelas em um banco de dados como o usuário administrador](#tutorial-rbac-step9)
+ [Etapa 10: Truncar tabelas como o usuário de leitura e gravação](#tutorial-rbac-step10)
+ [Funções do sistema para RBAC (opcional)](#tutorial-rbac-system-functions)
+ [Visualizações do sistema para RBAC (opcional)](#tutorial-rbac-system-views)
+ [Usar a segurança por linha com o RBAC (opcional)](#tutorial-rbac-rls)
## Pré-requisitos
+ Crie um cluster ou grupo de trabalho sem servidor do Amazon Redshift carregado com o banco de dados TICKIT de exemplo. Para criar um grupo de trabalho de tecnologia sem servidor, consulte [Criar um data warehouse com o Amazon Redshift sem servidor](https://docs.aws.amazon.com/redshift/latest/gsg/new-user-serverless.html). Para criar um cluster, consulte [Criar um cluster de amostra do Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-launch-sample-cluster.html). Para obter mais informações sobre os bancos de dados de amostra TICKIT, consulte [Banco de dados de exemplo](c_sampledb.md).
+ Tenha acesso a um usuário com permissões de superusuário ou administrador de função. Somente superusuários ou administradores de função podem conceder ou revogar funções. Para obter mais informações sobre as permissões necessárias para RBAC, consulte [Permissões do sistema para RBAC](r_roles-system-privileges.md).
+ Revise as [Considerações sobre o uso de funções no RBAC](r_role-usage-notes.md).
## Etapa 1: Criar um usuário administrador
Para configurar este tutorial, você cria uma função de administrador de banco de dados e a anexa a um usuário administrador de banco de dados nesta etapa. Você deve criar o administrador do banco de dados como superusuário ou administrador de função.
Execute todas as consultas no [Editor de Consultas v2](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-using.html) do Amazon Redshift.
1. Para criar a função de administrador db\$1admin, use o exemplo a seguir.
```
CREATE ROLE db_admin;
```
1. Para criar um usuário do banco de dados chamado dbadmin, use o exemplo a seguir.
```
CREATE USER dbadmin PASSWORD 'Test12345';
```
1. Para conceder a função definida pelo sistema chamada sys:dba à função db\$1admin, use o exemplo a seguir. Quando a função sys:dba é concedida, o usuário dbadmin pode criar esquemas e tabelas. Para obter mais informações, consulte [Funções definidas pelo sistema do Amazon RedshiftUsuários e perfis definidos pelo sistema para compartilhamento de dados](r_roles-default.md).
## Etapa 2: Configurar esquemas
Nesta etapa, você se conecta ao seu banco de dados como administrador do banco de dados. Em seguida, você cria dois esquemas e adiciona dados a eles.
1. Conecte-se ao banco de dados dev como o usuário dbadmin utilizando o editor de consultas v2. Para ter mais informações sobre como se conectar a um banco de dados, consulte [Trabalhar com o editor de consultas v2](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-using.html).
1. Para criar esquemas de bancos de dados de vendas e marketing, use o exemplo a seguir.
```
CREATE SCHEMA sales;
CREATE SCHEMA marketing;
```
1. Para criar e inserir valores em tabelas em um esquema de vendas, use o exemplo a seguir.
```
CREATE TABLE sales.cat(
catid smallint,
catgroup varchar(10),
catname varchar(10),
catdesc varchar(50)
);
INSERT INTO sales.cat(SELECT * FROM category);
CREATE TABLE sales.dates(
dateid smallint,
caldate date,
day char(3),
week smallint,
month char(5),
qtr char(5),
year smallint,
holiday boolean
);
INSERT INTO sales.dates(SELECT * FROM date);
CREATE TABLE sales.events(
eventid integer,
venueid smallint,
catid smallint,
dateid smallint,
eventname varchar(200),
starttime timestamp
);
INSERT INTO sales.events(SELECT * FROM event);
CREATE TABLE sales.sale(
salesid integer,
listid integer,
sellerid integer,
buyerid integer,
eventid integer,
dateid smallint,
qtysold smallint,
pricepaid decimal(8,2),
commission decimal(8,2),
saletime timestamp
);
INSERT INTO sales.sale(SELECT * FROM sales);
```
1. Para criar e inserir valores em tabelas em um esquema de marketing, use o exemplo a seguir.
```
CREATE TABLE marketing.cat(
catid smallint,
catgroup varchar(10),
catname varchar(10),
catdesc varchar(50)
);
INSERT INTO marketing.cat(SELECT * FROM category);
CREATE TABLE marketing.dates(
dateid smallint,
caldate date,
day char(3),
week smallint,
month char(5),
qtr char(5),
year smallint,
holiday boolean
);
INSERT INTO marketing.dates(SELECT * FROM date);
CREATE TABLE marketing.events(
eventid integer,
venueid smallint,
catid smallint,
dateid smallint,
eventname varchar(200),
starttime timestamp
);
INSERT INTO marketing.events(SELECT * FROM event);
CREATE TABLE marketing.sale(
marketingid integer,
listid integer,
sellerid integer,
buyerid integer,
eventid integer,
dateid smallint,
qtysold smallint,
pricepaid decimal(8,2),
commission decimal(8,2),
saletime timestamp
);
INSERT INTO marketing.sale(SELECT * FROM marketing);
```
## Etapa 3: Criar um usuário somente leitura
Nesta etapa, você cria uma função somente leitura e um salesanalyst para a função somente leitura. O analista de vendas só precisa de acesso somente leitura às tabelas no esquema de vendas para realizar a tarefa atribuída de encontrar os eventos que geraram as comissões mais altas.
1. Conecte-se ao banco de dados como o usuário dbadmin.
1. Para criar a função sales\$1ro, use o exemplo a seguir.
```
CREATE ROLE sales_ro;
```
1. Para criar a função salesanalyst, use o exemplo a seguir.
```
CREATE USER salesanalyst PASSWORD 'Test12345';
```
1. Para conceder acesso de uso e seleção à função sales\$1ro aos objetos do esquema de vendas, use o exemplo a seguir.
```
GRANT USAGE ON SCHEMA sales TO ROLE sales_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA sales TO ROLE sales_ro;
```
1. Para conceder ao usuário salesanalyst a função sales\$1ro, use o exemplo a seguir.
```
GRANT ROLE sales_ro TO salesanalyst;
```
## Etapa 4: Consultar os dados como usuário somente leitura
Nesta etapa, o usuário salesanalyst consulta os dados do esquema de vendas. Em seguida, o usuário salesanalyst tenta atualizar uma tabela e ler tabelas no esquema de marketing.
1. Conecte-se ao banco de dados como o usuário salesanalyst.
1. Para encontrar as dez vendas com as comissões mais altas, use o exemplo a seguir.
```
SET SEARCH_PATH TO sales;
SELECT DISTINCT events.dateid, sale.commission, cat.catname
FROM sale, events, dates, cat
WHERE events.dateid=dates.dateid AND events.dateid=sale.dateid AND events.catid = cat.catid
ORDER BY 2 DESC LIMIT 10;
+--------+------------+----------+
| dateid | commission | catname |
+--------+------------+----------+
| 1880 | 1893.6 | Pop |
| 1880 | 1893.6 | Opera |
| 1880 | 1893.6 | Plays |
| 1880 | 1893.6 | Musicals |
| 1861 | 1500 | Plays |
| 2003 | 1500 | Pop |
| 1861 | 1500 | Opera |
| 2003 | 1500 | Plays |
| 1861 | 1500 | Musicals |
| 1861 | 1500 | Pop |
+--------+------------+----------+
```
1. Para selecionar dez eventos na tabela de eventos no esquema de vendas, use o exemplo a seguir.
```
SELECT * FROM sales.events LIMIT 10;
+---------+---------+-------+--------+--------------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+--------------------+---------------------+
| 4836 | 73 | 9 | 1871 | Soulfest | 2008-02-14 19:30:00 |
| 5739 | 41 | 9 | 1871 | Fab Faux | 2008-02-14 19:30:00 |
| 627 | 229 | 6 | 1872 | High Society | 2008-02-15 14:00:00 |
| 2563 | 246 | 7 | 1872 | Hamlet | 2008-02-15 20:00:00 |
| 7703 | 78 | 9 | 1872 | Feist | 2008-02-15 14:00:00 |
| 7903 | 90 | 9 | 1872 | Little Big Town | 2008-02-15 19:30:00 |
| 7925 | 101 | 9 | 1872 | Spoon | 2008-02-15 19:00:00 |
| 8113 | 17 | 9 | 1872 | Santana | 2008-02-15 15:00:00 |
| 463 | 303 | 8 | 1873 | Tristan und Isolde | 2008-02-16 19:00:00 |
| 613 | 236 | 6 | 1873 | Pal Joey | 2008-02-16 15:00:00 |
+---------+---------+-------+--------+--------------------+---------------------+
```
1. Para tentar atualizar eventname para eventid 1, execute o exemplo a seguir. Este exemplo gerará um erro de permissão negada porque o usuário salesanalyst só tem permissões SELECT na tabela de eventos no esquema de vendas. Para atualizar a tabela de eventos, você deve conceder permissões UPDATE à função sales\$1ro. Para obter mais informações sobre como conceder permissões para atualizar uma tabela, consulte o parâmetro UPDATE para [GRANT](r_GRANT.md). Para obter mais informações sobre o comando UPDATE, consulte [UPDATE](r_UPDATE.md).
```
UPDATE sales.events
SET eventname = 'Comment event'
WHERE eventid = 1;
ERROR: permission denied for relation events
```
1. Para tentar selecionar todos os eventos na tabela no esquema de marketing, use o exemplo a seguir. Este exemplo gerará um erro de permissão negada porque o usuário salesanalyst só tem permissões SELECT para a tabela de eventos no esquema de vendas. Para selecionar dados da tabela de eventos no esquema de marketing, você deve conceder à função sales\$1ro as permissões SELECT na tabela de eventos do esquema de marketing.
```
SELECT * FROM marketing.events;
ERROR: permission denied for schema marketing
```
## Etapa 5: Criar um usuário de leitura e gravação
Nesta etapa, o engenheiro de vendas responsável por criar o pipeline de extração, transformação e carregamento (ETL) para processamento de dados no esquema de vendas receberá acesso somente leitura, mas posteriormente receberá acesso de leitura e gravação para realizar suas tarefas.
1. Conecte-se ao banco de dados como o usuário dbadmin.
1. Para criar a função sales\$1rw no esquema de vendas, use o exemplo a seguir.
```
CREATE ROLE sales_rw;
```
1. Para criar o usuário salesengineer, use o exemplo a seguir.
```
CREATE USER salesengineer PASSWORD 'Test12345';
```
1. Para conceder acesso de uso e seleção à função sales\$1rw aos objetos do esquema de vendas atribuindo a função sales\$1ro a ela, use o exemplo a seguir. Para obter mais informações sobre como as funções herdam permissões no Amazon Redshift, consulte [Hierarquia de funções](t_role_hierarchy.md).
```
GRANT ROLE sales_ro TO ROLE sales_rw;
```
1. Para atribuir a função sales\$1rw ao usuário salesengineer, use o exemplo a seguir.
```
GRANT ROLE sales_rw TO salesengineer;
```
## Etapa t: Consultar os dados como o usuário com a função somente leitura herdada
Nesta etapa, o usuário salesengineer tenta atualizar a tabela de eventos antes de receber permissões de leitura.
1. Conecte-se ao banco de dados como o usuário salesengineer.
1. O usuário salesengineer pode ler com êxito os dados da tabela de eventos do esquema de vendas. Para selecionar o evento com eventid 1 na tabela de eventos no esquema de vendas, use o exemplo a seguir.
```
SELECT * FROM sales.events where eventid=1;
+---------+---------+-------+--------+-----------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+-----------------+---------------------+
| 1 | 305 | 8 | 1851 | Gotterdammerung | 2008-01-25 14:30:00 |
+---------+---------+-------+--------+-----------------+---------------------+
```
1. Para tentar selecionar todos os eventos na tabela no esquema de marketing, use o exemplo a seguir. Como o usuário salesengineer não tem permissões para tabelas no esquema de marketing, essa consulta gerará um erro de permissão negada. Para selecionar dados da tabela de eventos no esquema de marketing, você deve conceder à função sales\$1rw as permissões SELECT na tabela de eventos do esquema de marketing.
```
SELECT * FROM marketing.events;
ERROR: permission denied for schema marketing
```
1. Para tentar atualizar eventname para eventid 1, execute o exemplo a seguir. Este exemplo gerará um erro de permissão negada porque o usuário salesengineer só tem permissões de seleção na tabela de eventos no esquema de vendas. Para atualizar a tabela de eventos, você deve conceder permissões de UPDATE à função sales\$1rw.
```
UPDATE sales.events
SET eventname = 'Comment event'
WHERE eventid = 1;
ERROR: permission denied for relation events
```
## Etapa 7: Conceder permissões de atualização e inserção à função de leitura e gravação
Nesta etapa, você concede permissões de atualização e inserção à função sales\$1rw.
1. Conecte-se ao banco de dados como o usuário dbadmin.
1. Para conceder as permissões UPDATE, INSERT e DELETE à função sales\$1rw, use o exemplo a seguir.
```
GRANT UPDATE, INSERT, ON ALL TABLES IN SCHEMA sales TO role sales_rw;
```
## Etapa 8: Consultar os dados como o usuário de leitura e gravação
Nesta etapa, o usuário salesengineer atualiza com êxito a tabela depois que sua função recebe as permissões de inserção e atualização. Em seguida, ele tenta analisar e limpar a tabela de eventos, mas não consegue fazer isso.
1. Conecte-se ao banco de dados como o usuário salesengineer.
1. Para atualizar eventname para eventid 1, execute o exemplo a seguir.
```
UPDATE sales.events
SET eventname = 'Comment event'
WHERE eventid = 1;
```
1. Para visualizar a alteração feita na consulta anterior, use o exemplo a seguir para selecionar o evento com eventid 1 na tabela de eventos no esquema de vendas.
```
SELECT * FROM sales.events WHERE eventid=1;
+---------+---------+-------+--------+---------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+---------------+---------------------+
| 1 | 305 | 8 | 1851 | Comment event | 2008-01-25 14:30:00 |
+---------+---------+-------+--------+---------------+---------------------+
```
1. Para analisar a tabela de eventos atualizada no esquema de vendas, use o exemplo a seguir. Este exemplo gerará um erro de permissão negada porque o usuário salesengineer não tem as permissões necessárias e não é o proprietário da tabela de eventos no esquema de vendas. Para analisar a tabela de eventos, você deve conceder permissões ANALYZE à função sales\$1rw usando o comando GRANT. Para obter mais informações sobre o comando ANALYZE, consulte [ANALYZE](r_ANALYZE.md).
```
ANALYZE sales.events;
ERROR: skipping "events" --- only table or database owner can analyze
```
1. Para limpar a tabela de eventos atualizada, use o exemplo a seguir. Este exemplo gerará um erro de permissão negada porque o usuário salesengineer não tem as permissões necessárias e não é o proprietário da tabela de eventos no esquema de vendas. Para limpar a tabela de eventos, você deve conceder permissões VACUUM à função sales\$1rw usando o comando GRANT. Para obter mais informações sobre o comando VACUUM, consulte [VACUUM](r_VACUUM_command.md).
```
VACUUM sales.events;
ERROR: skipping "events" --- only table or database owner can vacuum it
```
## Etapa 9: Analisar e limpar tabelas em um banco de dados como o usuário administrador
Nesta etapa, o usuário dbadmin analisa e limpa todas as tabelas. O usuário tem permissões de administrador nesse banco de dados, então ele pode executar esses comandos.
1. Conecte-se ao banco de dados como o usuário dbadmin.
1. Para analisar a tabela de eventos no esquema de vendas, use o exemplo a seguir.
```
ANALYZE sales.events;
```
1. Para limpar a tabela de eventos no esquema de vendas, use o exemplo a seguir.
```
VACUUM sales.events;
```
1. Para analisar a tabela de eventos no esquema de marketing, use o exemplo a seguir.
```
ANALYZE marketing.events;
```
1. Para limpar a tabela de eventos no esquema de marketing, use o exemplo a seguir.
```
VACUUM marketing.events;
```
## Etapa 10: Truncar tabelas como o usuário de leitura e gravação
Nesta etapa, o usuário salesengineer tenta truncar a tabela de eventos no esquema de vendas, mas só consegue quando o usuário dbadmin concede permissões para truncar.
1. Conecte-se ao banco de dados como o usuário salesengineer.
1. Para tentar excluir todas as linhas na tabela de eventos no esquema de vendas, use o exemplo a seguir. Este exemplo gerará um erro porque o usuário salesengineer não tem as permissões necessárias e não é o proprietário da tabela de eventos no esquema de vendas. Para truncar a tabela de eventos, você deve conceder permissões TRUNCATE à função sales\$1rw usando o comando GRANT. Para obter mais informações sobre o comando TRUNCATE, consulte [TRUNCATE](r_TRUNCATE.md).
```
TRUNCATE sales.events;
ERROR: must be owner of relation events
```
1. Conecte-se ao banco de dados como o usuário dbadmin.
1. Para conceder à função sales\$1rw privilégios para truncar a tabela, use o exemplo a seguir.
```
GRANT TRUNCATE TABLE TO role sales_rw;
```
1. Conecte-se ao banco de dados como o usuário salesengineer utilizando o editor de consultas v2.
1. Para ler os dez primeiros eventos na tabela de eventos no esquema de vendas, use o exemplo a seguir.
```
SELECT * FROM sales.events ORDER BY eventid LIMIT 10;
+---------+---------+-------+--------+-----------------------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+-----------------------------+---------------------+
| 1 | 305 | 8 | 1851 | Comment event | 2008-01-25 14:30:00 |
| 2 | 306 | 8 | 2114 | Boris Godunov | 2008-10-15 20:00:00 |
| 3 | 302 | 8 | 1935 | Salome | 2008-04-19 14:30:00 |
| 4 | 309 | 8 | 2090 | La Cenerentola (Cinderella) | 2008-09-21 14:30:00 |
| 5 | 302 | 8 | 1982 | Il Trovatore | 2008-06-05 19:00:00 |
| 6 | 308 | 8 | 2109 | L Elisir d Amore | 2008-10-10 19:30:00 |
| 7 | 309 | 8 | 1891 | Doctor Atomic | 2008-03-06 14:00:00 |
| 8 | 302 | 8 | 1832 | The Magic Flute | 2008-01-06 20:00:00 |
| 9 | 308 | 8 | 2087 | The Fly | 2008-09-18 19:30:00 |
| 10 | 305 | 8 | 2079 | Rigoletto | 2008-09-10 15:00:00 |
+---------+---------+-------+--------+-----------------------------+---------------------+
```
1. Para truncar a tabela de eventos no esquema de vendas, use o exemplo a seguir.
```
TRUNCATE sales.events;
```
1. Para ler os dados da tabela de eventos atualizada no esquema de vendas, use o exemplo a seguir.
```
SELECT * FROM sales.events ORDER BY eventid LIMIT 10;
+---------+---------+-------+--------+-----------------------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+-----------------------------+---------------------+
```
### Criar funções somente leitura e leitura e gravação para o esquema de marketing (opcional)
Nesta etapa, você cria funções somente leitura e leitura e gravação para o esquema de marketing.
1. Conecte-se ao banco de dados como o usuário dbadmin.
1. Para criar funções somente leitura e leitura e gravação para o esquema de marketing, use o exemplo a seguir.
```
CREATE ROLE marketing_ro;
CREATE ROLE marketing_rw;
GRANT USAGE ON SCHEMA marketing TO ROLE marketing_ro, ROLE marketing_rw;
GRANT SELECT ON ALL TABLES IN SCHEMA marketing TO ROLE marketing_ro;
GRANT ROLE marketing_ro TO ROLE marketing_rw;
GRANT INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA marketing TO ROLE marketing_rw;
CREATE USER marketinganalyst PASSWORD 'Test12345';
CREATE USER marketingengineer PASSWORD 'Test12345';
GRANT ROLE marketing_ro TO marketinganalyst;
GRANT ROLE marketing_rw TO marketingengineer;
```
## Funções do sistema para RBAC (opcional)
O Amazon Redshift tem duas funções para fornecer informações do sistema sobre associação de usuários e funções em grupos ou funções adicionais: role\$1is\$1member\$1of e user\$1is\$1member\$1of. Essas funções estão disponíveis para superusuários e usuários regulares. Os superusuários podem verificar a associação de todas as funções. Os usuários regulares só podem verificar a associação de funções às quais tenham acesso.
Como usar a função role\$1is\$1member\$1of
1. Conecte-se ao banco de dados como o usuário salesengineer.
1. Para verificar se a função sales\$1rw é membro da função sales\$1ro, use o exemplo a seguir.
```
SELECT role_is_member_of('sales_rw', 'sales_ro');
+-------------------+
| role_is_member_of |
+-------------------+
| true |
+-------------------+
```
1. Para verificar se a função sales\$1ro é membro da função sales\$1rw, use o exemplo a seguir.
```
SELECT role_is_member_of('sales_ro', 'sales_rw');
+-------------------+
| role_is_member_of |
+-------------------+
| false |
+-------------------+
```
Como usar a função user\$1is\$1member\$1of
1. Conecte-se ao banco de dados como o usuário salesengineer.
1. O exemplo a seguir tenta verificar a associação do usuário salesanalyst. Essa consulta gera um erro porque o usuário salesengineer não tem acesso ao usuário salesanalyst. Para executar esse comando com êxito, conecte-se ao banco de dados como o usuário salesanalyst e use o exemplo.
```
SELECT user_is_member_of('salesanalyst', 'sales_ro');
ERROR
```
1. Conecte-se ao banco de dados como superusuário.
1. Para verificar a associação do usuário salesanalyst quando conectado como superusuário, use o exemplo a seguir.
```
SELECT user_is_member_of('salesanalyst', 'sales_ro');
+-------------------+
| user_is_member_of |
+-------------------+
| true |
+-------------------+
```
1. Conecte-se ao banco de dados como o usuário dbadmin.
1. Para verificar a associação do usuário salesengineer quando conectado como superusuário, use o exemplo a seguir.
```
SELECT user_is_member_of('salesengineer', 'sales_ro');
+-------------------+
| user_is_member_of |
+-------------------+
| true |
+-------------------+
SELECT user_is_member_of('salesengineer', 'marketing_ro');
+-------------------+
| user_is_member_of |
+-------------------+
| false |
+-------------------+
SELECT user_is_member_of('marketinganalyst', 'sales_ro');
+-------------------+
| user_is_member_of |
+-------------------+
| false |
+-------------------+
```
## Visualizações do sistema para RBAC (opcional)
Para visualizar as funções, a atribuição de funções aos usuários, a hierarquia de funções e os privilégios dos objetos de banco de dados por meio de funções, use as visualizações do sistema para o Amazon Redshift. Essas visualizações estão disponíveis para superusuários e usuários regulares. Os superusuários podem verificar todos os detalhes da função. Os usuários regulares só podem verificar detalhes das funções às quais tenham acesso.
1. Para visualizar uma lista de usuários aos quais se concedem funções no cluster explicitamente, use o exemplo a seguir.
```
SELECT * FROM svv_user_grants;
```
1. Para visualizar uma lista de funções às quais se concedem funções no cluster explicitamente, use o exemplo a seguir.
```
SELECT * FROM svv_role_grants;
```
Para obter a lista completa de visualizações do sistema, consulte [Visualizações SVV de metadados](svv_views.md).
## Usar a segurança por linha com o RBAC (opcional)
Para ter controle de acesso detalhado sobre seus dados confidenciais, use a segurança por linha (RLS). Para obter mais informações sobre RLS, consulte [Segurança por linha](t_rls.md).
Nesta seção, você cria uma política de RLS que concede ao usuário `salesengineer` permissões para visualizar somente as linhas na tabela `cat` que tenham o valor `catdesc` da Major League Baseball. Em seguida, você consulta o banco de dados como o usuário `salesengineer`.
1. Conecte-se ao banco de dados como o usuário `salesengineer`.
1. Para visualizar as primeiras cinco entradas na tabela `cat`, use o exemplo a seguir.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+---------------------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+---------------------------------+
| 1 | Sports | MLB | Major League Baseball |
| 2 | Sports | NHL | National Hockey League |
| 3 | Sports | NFL | National Football League |
| 4 | Sports | NBA | National Basketball Association |
| 5 | Sports | MLS | Major League Soccer |
+-------+----------+---------+---------------------------------+
```
1. Conecte-se ao banco de dados como o usuário `dbadmin`.
1. Para criar uma política de RLS para a coluna `catdesc` na tabela `cat`, use o exemplo a seguir.
```
CREATE RLS POLICY policy_mlb_engineer
WITH (catdesc VARCHAR(50))
USING (catdesc = 'Major League Baseball');
```
1. Para anexar a política de RLS à função `sales_rw`, use o exemplo a seguir.
```
ATTACH RLS POLICY policy_mlb_engineer ON sales.cat TO ROLE sales_rw;
```
1. Para alterar a tabela a fim de ativar a RLS, use o exemplo a seguir.
```
ALTER TABLE sales.cat ROW LEVEL SECURITY ON;
```
1. Conecte-se ao banco de dados como o usuário `salesengineer`.
1. Para tentar visualizar as primeiras cinco entradas na tabela `cat`, use o exemplo a seguir. Observe que as entradas só aparecem quando a coluna `catdesc` é `Major League Baseball`.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+-----------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+-----------------------+
| 1 | Sports | MLB | Major League Baseball |
+-------+----------+---------+-----------------------+
```
1. Conecte-se ao banco de dados como o usuário `salesanalyst`.
1. Para tentar visualizar as primeiras cinco entradas na tabela `cat`, use o exemplo a seguir. Observe que nenhuma entrada aparece porque a política padrão de negar tudo é aplicada.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+-----------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+-----------------------+
```
1. Conecte-se ao banco de dados como o usuário `dbadmin`.
1. Para conceder a permissão IGNORE RLS à função `sales_ro`, use o exemplo a seguir. Isso concede ao usuário `salesanalyst` as permissões para ignorar as políticas de RLS, pois ele é membro da função `sales_ro`.
```
GRANT IGNORE RLS TO ROLE sales_ro;
```
1. Conecte-se ao banco de dados como o usuário `salesanalyst`.
1. Para visualizar as primeiras cinco entradas na tabela `cat`, use o exemplo a seguir.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+---------------------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+---------------------------------+
| 1 | Sports | MLB | Major League Baseball |
| 2 | Sports | NHL | National Hockey League |
| 3 | Sports | NFL | National Football League |
| 4 | Sports | NBA | National Basketball Association |
| 5 | Sports | MLS | Major League Soccer |
+-------+----------+---------+---------------------------------+
```
1. Conecte-se ao banco de dados como o usuário `dbadmin`.
1. Para revogar a permissão IGNORE RLS da função `sales_ro`, use o exemplo a seguir.
```
REVOKE IGNORE RLS FROM ROLE sales_ro;
```
1. Conecte-se ao banco de dados como o usuário `salesanalyst`.
1. Para tentar visualizar as primeiras cinco entradas na tabela `cat`, use o exemplo a seguir. Observe que nenhuma entrada aparece porque a política padrão de negar tudo é aplicada.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+-----------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+-----------------------+
```
1. Conecte-se ao banco de dados como o usuário `dbadmin`.
1. Para desanexar a política de RLS da tabela `cat`, use o exemplo a seguir.
```
DETACH RLS POLICY policy_mlb_engineer ON cat FROM ROLE sales_rw;
```
1. Conecte-se ao banco de dados como o usuário `salesanalyst`.
1. Para tentar visualizar as primeiras cinco entradas na tabela `cat`, use o exemplo a seguir. Observe que nenhuma entrada aparece porque a política padrão de negar tudo é aplicada.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+---------------------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+---------------------------------+
| 1 | Sports | MLB | Major League Baseball |
| 2 | Sports | NHL | National Hockey League |
| 3 | Sports | NFL | National Football League |
| 4 | Sports | NBA | National Basketball Association |
| 5 | Sports | MLS | Major League Soccer |
+-------+----------+---------+---------------------------------+
```
1. Conecte-se ao banco de dados como o usuário `dbadmin`.
1. Para descartar a política de RLS, use o exemplo a seguir.
```
DROP RLS POLICY policy_mlb_engineer;
```
1. Para remover a RLS, use o exemplo a seguir.
```
ALTER TABLE cat ROW LEVEL SECURITY OFF;
```
## Tópicos relacionados
Para obter mais informações sobre RBAC, consulte a seguinte documentação:
+ [Hierarquia de funções](t_role_hierarchy.md)
+ [Atribuição de função](t_role_assignment.md)
+ [Permissões de objetos do banco de dados](r_roles-database-privileges.md)
+ [ALTER DEFAULT PRIVILEGES para o RBAC](r_roles-alter-default-privileges.md)
# Segurança por linha
Usando a segurança no nível da linha (RLS) no Amazon Redshift, é possível ter controle de acesso granular sobre seus dados confidenciais. É possível decidir quais usuários ou funções podem acessar registros específicos de dados em esquemas ou tabelas com base nas políticas de segurança definidas no nível dos objetos do banco de dados. Além da segurança no nível da coluna, na qual é possível conceder permissões aos usuários para um subconjunto de colunas, use as políticas de RLS para restringir ainda mais o acesso a linhas específicas das colunas visíveis. Para obter mais informações sobre regras de segurança no nível de coluna, consulte [Observações de uso para controle de acesso no nível da coluna](r_GRANT-usage-notes.md#r_GRANT-usage-notes-clp).
Quando você impuser políticas de RLS em tabelas, poderá restringir os conjuntos de resultados retornados quando os usuários executarem consultas.
Ao criar políticas de RLS, é possível especificar expressões que determinam se o Amazon Redshift retornará quaisquer linhas existentes em uma tabela de uma consulta. Ao criar políticas de RLS para limitar o acesso, você não precisa adicionar ou externalizar condições adicionais em suas consultas.
Ao criar políticas de RLS, recomendamos que você crie políticas simples e evite declarações complexas nas políticas. Ao definir políticas de RLS, não use junções de tabela excessivas na definição de política que sejam baseadas em políticas.
Quando uma política se refere a uma tabela de pesquisa, o Amazon Redshift verifica a tabela adicional, além da tabela na qual a política existe. Haverá diferenças de performance entre a mesma consulta para um usuário com uma política de RLS anexada e um usuário sem nenhuma política anexada.
# Utilização de políticas de RLS em instruções SQL
Ao usar políticas de RLS em instruções SQL, o Amazon Redshift aplica as seguintes regras:
+ O Amazon Redshift aplica políticas de RLS às instruções SELECT, UPDATE e DELETE por padrão.
+ Para SELECT e UNLOAD, o Amazon Redshift filtra linhas de acordo com sua política definida.
+ Para UPDATE, o Amazon Redshift atualiza somente as linhas que estão visíveis para você. Se uma política restringir um subconjunto das linhas em uma tabela, não será possível atualizá-las.
+ Para DELETE, é possível excluir somente as linhas que estão visíveis para você. Se uma política restringir um subconjunto das linhas em uma tabela, não será possível excluí-las. Para TRUNCATE, ainda será possível truncar a tabela.
+ Para CREATE TABLE LIKE, as tabelas criadas com as opções LIKE não herdarão as configurações de permissão da tabela de origem. Da mesma forma, a tabela de destino não herdará as políticas de RLS da tabela de origem.
# Combinar várias políticas por usuário
O RLS no Amazon Redshift é compatível com a anexação de várias políticas por usuário e objeto. Quando há várias políticas definidas para um usuário, o Amazon Redshift aplica todas as políticas com a sintaxe AND ou OR dependendo da definição RLS CONJUNCTION TYPE da tabela. Para obter mais informações sobre o tipo de conjunção, consulte [ALTER TABLE](r_ALTER_TABLE.md).
Várias políticas em uma tabela podem ser associadas a você. Várias políticas estão diretamente anexadas a você ou você pertence a várias funções, e as funções têm políticas diferentes anexadas a elas.
Quando as várias políticas precisam restringir o acesso a linhas em uma determinada relação, você pode definir RLS CONJUNCTION TYPE da relação como AND. Considere o seguinte exemplo. Alice só consegue ver um evento Sports que tenham um "catname" NBA de acordo com a política especificada.
```
-- Create an analyst role and grant it to a user named Alice.
CREATE ROLE analyst;
CREATE USER alice WITH PASSWORD 'Name_is_alice_1';
GRANT ROLE analyst TO alice;
-- Create an RLS policy that only lets the user see sports.
CREATE RLS POLICY policy_sports
WITH (catgroup VARCHAR(10))
USING (catgroup = 'Sports');
-- Create an RLS policy that only lets the user see NBA.
CREATE RLS POLICY policy_nba
WITH (catname VARCHAR(10))
USING (catname = 'NBA');
-- Attach both to the analyst role.
ATTACH RLS POLICY policy_sports ON category TO ROLE analyst;
ATTACH RLS POLICY policy_nba ON category TO ROLE analyst;
-- Activate RLS on the category table with AND CONJUNCTION TYPE.
ALTER TABLE category ROW LEVEL SECURITY ON CONJUNCTION TYPE AND;
-- Change session to Alice.
SET SESSION AUTHORIZATION alice;
-- Select all from the category table.
SELECT catgroup, catname
FROM category;
catgroup | catname
---------+---------
Sports | NBA
(1 row)
```
Quando as várias políticas precisam permitir a usuários ver mais linhas em uma determinada relação, o usuário pode definir RLS CONJUNCTION TYPE da relação como OR. Considere o seguinte exemplo. Alice só consegue ver "Shows" e "Esportes" de acordo com a política especificada.
```
-- Create an analyst role and grant it to a user named Alice.
CREATE ROLE analyst;
CREATE USER alice WITH PASSWORD 'Name_is_alice_1';
GRANT ROLE analyst TO alice;
-- Create an RLS policy that only lets the user see concerts.
CREATE RLS POLICY policy_concerts
WITH (catgroup VARCHAR(10))
USING (catgroup = 'Concerts');
-- Create an RLS policy that only lets the user see sports.
CREATE RLS POLICY policy_sports
WITH (catgroup VARCHAR(10))
USING (catgroup = 'Sports');
-- Attach both to the analyst role.
ATTACH RLS POLICY policy_concerts ON category TO ROLE analyst;
ATTACH RLS POLICY policy_sports ON category TO ROLE analyst;
-- Activate RLS on the category table with OR CONJUNCTION TYPE.
ALTER TABLE category ROW LEVEL SECURITY ON CONJUNCTION TYPE OR;
-- Change session to Alice.
SET SESSION AUTHORIZATION alice;
-- Select all from the category table.
SELECT catgroup, count(*)
FROM category
GROUP BY catgroup ORDER BY catgroup;
catgroup | count
---------+-------
Concerts | 3
Sports | 5
(2 rows)
```
# Propriedade e gerenciamento da política de RLS
Como superusuário, administrador de segurança ou usuário que tem a função sys:secadmin, você pode criar, modificar, anexar e desanexar políticas de RLS. As políticas de RLS podem ser anexadas a tabelas, visualizações, visualizações de vinculação tardia (LBVs) e visões materializadas (MVs). No nível do objeto, é possível ativar ou desativar a segurança no nível da linha sem modificar a definição do esquema para tabelas.
Para começar a usar a segurança no nível da linha, a seguir estão as instruções SQL que é possível usar:
+ Use a instrução ALTER TABLE para ativar ou desativar a RLS em uma tabela, visualização ou visualização de vinculação tardia. Para obter mais informações, consulte [ALTER TABLE](r_ALTER_TABLE.md).
+ Use a instrução ALTER MATERIALIZED VIEW para ativar ou desativar a RLS em uma visão materializada (MV). Para obter mais informações, consulte [ALTER MATERIALIZED VIEW](r_ALTER_MATERIALIZED_VIEW.md).
+ Use a instrução CREATE RLS POLICY para criar uma política de segurança para uma ou mais tabelas e especificar um ou mais usuários ou funções na política.
Para obter mais informações, consulte [CREATE RLS POLICY](r_CREATE_RLS_POLICY.md).
+ Use a instrução ALTER RLS POLICY para alterar a política, como alterar a definição da política. Você pode usar a mesma política para várias tabelas ou visões.
Para obter mais informações, consulte [ALTER RLS POLICY](r_ALTER_RLS_POLICY.md).
+ Use a instrução ATTACH RLS POLICY para anexar uma política a uma ou mais relações, a um ou mais usuários ou a funções.
Para obter mais informações, consulte [ATTACH RLS POLICY](r_ATTACH_RLS_POLICY.md).
+ Use a declaração DETACH RLS POLICY para desanexar uma política de uma ou mais relações, de um ou mais usuários ou de perfis.
Para obter mais informações, consulte [https://s3.amazonaws.com/redshift-downloads/drivers/jdbc/2.1.0.7/redshift-jdbc42-2.1.0.7.zip Na região da China (Pequim), use o seguinte link: https://s3---cn-north-1.amazonaws.com.rproxy.goskope.com.cn/redshift-downloads-cn/drivers/jdbc/2.1.0.7/redshift-jdbc42-2.1.0.7.zip](r_DETACH_RLS_POLICY.md).
+ Use a instrução DROP RLS POLICY para descartar uma política.
Para obter mais informações, consulte [DROP RLS POLICY](r_DROP_RLS_POLICY.md).
+ Use as instruções GRANT e REVOKE para conceder e revogar explicitamente permissões SELECT para políticas de RLS que fazem referência a tabelas de pesquisa. Para obter mais informações, consulte [GRANT](r_GRANT.md) e [REVOKE](r_REVOKE.md).
Para monitorar as políticas criadas, sys:secadmin pode visualizar [SVV\$1RLS\$1POLICY](r_SVV_RLS_POLICY.md) e [SVV\$1RLS\$1ATTACHED\$1POLICY](r_SVV_RLS_ATTACHED_POLICY.md).
Para listar relações protegidas por RLS, sys:secadmin pode visualizar [SVV\$1RLS\$1RELATION](r_SVV_RLS_RELATION.md).
Para monitorar a aplicação de políticas de RLS em consultas que fazem referência a relações protegidas por RLS, um superusuário sys:operator ou qualquer usuário com a permissão do sistema ACCESS SYSTEM TABLE pode visualizar [SVV\$1RLS\$1APPLIED\$1POLICY](r_SVV_RLS_APPLIED_POLICY.md). Observe que sys:secadmin não recebe essas permissões por padrão.
Para permitir que os usuários tenham acesso total a uma relação protegida por RLS, você pode conceder a permissão IGNORE RLS. Superusuários ou sys:secadmin recebem automaticamente IGNORE RLS. Para obter mais informações, consulte [GRANT](r_GRANT.md).
Para explicar os filtros de política de RLS de uma consulta no plano EXPLAIN para solucionar problemas de consultas relacionadas à RLS, é possível conceder a permissão EXPLAIN RLS a qualquer usuário. Para obter mais informações, consulte [GRANT](r_GRANT.md) e [EXPLAIN](r_EXPLAIN.md).
# Objetos e princípios dependentes de políticas
Para fornecer segurança a aplicações e evitar que objetos da política se tornem obsoletos ou inválidos, o Amazon Redshift não permite descartar ou alterar objetos referenciados por políticas de RLS.
Veja a seguir uma lista das dependências de objeto de esquema que o Amazon Redshift monitora para políticas de RLS.
+ Ao monitorar a dependência do objeto de esquema para a tabela de destino, o Amazon Redshift segue estas regras:
+ O Amazon Redshift separa a política de uma relação, usuário, função ou público quando você descarta uma tabela de destino.
+ Quando você renomeia um nome de tabela de destino, não há impacto nas políticas anexadas.
+ Não é possível descartar as colunas da tabela de políticas referenciada dentro da definição de política, a menos que você descarte ou desanexe a política. Isso também se aplica quando a opção CASCADE é especificada. É possível descartar outras colunas na tabela de destino.
+ Não é possível renomear as colunas referenciadas da tabela de destino. Para renomear as colunas referidas, desanexe a política primeiro. Isso também se aplica quando a opção CASCADE é especificada.
+ Não é possível alterar o tipo da coluna referenciada, mesmo quando você especifica a opção CASCADE.
+ Ao monitorar a dependência do objeto de esquema para a tabela de consulta, o Amazon Redshift segue estas regras:
+ Não é possível descartar uma tabela de pesquisa. Para descartar uma tabela de pesquisa, primeiro descarte a política na qual a tabela de pesquisa é referenciada.
+ Não é possível renomear uma tabela de pesquisa. Para renomear uma tabela de pesquisa, primeiro descarte a política na qual a tabela de pesquisa é referenciada. Isso também se aplica quando a opção CASCADE é especificada.
+ Não é possível descartar as colunas da tabela de pesquisa usadas na definição de política. Para descartar colunas de uma tabela de pesquisa usadas na definição da política, primeiro descarte a política na qual a tabela de pesquisa é referenciada. Isso também se aplica quando a opção CASCADE é especificada na instrução ALTER TABLE DROP COLUMN. É possível descartar outras colunas na tabela de consultas.
+ Não é possível renomear as colunas referidas da tabela de pesquisa. Para renomear colunas referenciadas, primeiro descarte a política na qual a tabela de pesquisa é referenciada. Isso também se aplica quando a opção CASCADE é especificada.
+ Não é possível alterar o tipo da coluna de referência.
+ Ao descartar um usuário ou uma função, o Amazon Redshift desanexa todas as políticas anexadas ao usuário ou à função automaticamente.
+ Quando você usa a opção CASCADE na instrução DROP SCHEMA, o Amazon Redshift também descarta as relações no esquema. Ele também descarta as relações em quaisquer outros esquemas que sejam dependentes das relações no esquema descartado. Para uma relação que seja uma tabela de pesquisa em uma política, o Amazon Redshift falhará no DROP SCHEMA DDL. Para todas as relações abandonadas pela instrução DROP SCHEMA, o Amazon Redshift desanexa todas as políticas anexadas a essas relações.
+ Só é possível descartar uma função de pesquisa (uma função que é referenciada dentro de uma definição de política) quando você também descarta a política. Isso também se aplica quando a opção CASCADE é especificada.
+ Quando uma política é anexada a uma tabela, o Amazon Redshift verifica se essa tabela é uma tabela de pesquisa em uma política diferente. Se esse for o caso, o Amazon Redshift não permitirá anexar uma política a essa tabela.
+ Ao criar uma política de RLS, o Amazon Redshift verifica se essa tabela é uma tabela de destino para qualquer outra política de RLS. Se esse for o caso, o Amazon Redshift não permitirá criar uma política nessa tabela.
## Exemplo
O exemplo a seguir ilustra como a dependência de esquema é monitorada.
```
-- The CREATE and ATTACH policy statements for `policy_events` references some
-- target and lookup tables.
-- Target tables are tickit_event_redshift and target_schema.target_event_table.
-- Lookup table is tickit_sales_redshift.
-- Policy `policy_events` has following dependencies:
-- table tickit_sales_redshift column eventid, qtysold
-- table tickit_event_redshift column eventid
-- table target_event_table column eventid
-- schema public and target_schema
CREATE RLS POLICY policy_events
WITH (eventid INTEGER)
USING (
eventid IN (SELECT eventid FROM tickit_sales_redshift WHERE qtysold <3)
);
ATTACH RLS POLICY policy_events ON tickit_event_redshift TO ROLE analyst;
ATTACH RLS POLICY policy_events ON target_schema.target_event_table TO ROLE consumer;
```
# Considerações e limitações ao usar políticas de RLS
## Considerações
Veja as seguintes considerações para trabalhar com políticas de RLS:
+ O Amazon Redshift aplica políticas de RLS às instruções SELECT, UPDATE e DELETE.
+ O Amazon Redshift não aplica políticas de RLS a instruções INSERT, COPY e ALTER TABLE APPEND.
+ As políticas de RLS podem ser anexadas a tabelas, visualizações, visualizações de vinculação tardia (LBVs) e visões materializadas (MVs).
+ A segurança no nível da linha trabalha com a segurança no nível da coluna para proteger seus dados.
+ Quando o RLS é ativado para a relação de origem, o Amazon Redshift oferece suporte à instrução ALTER TABLE APPEND para superusuários, usuários que receberam explicitamente a permissão de sistema IGNORE RLS ou o perfil sys:secadmin. Nesse caso, é possível executar a instrução ALTER TABLE APPEND para acrescentar linhas a uma tabela de destino movendo dados de uma tabela de origem existente. O Amazon Redshift move todas as tuplas da relação de origem para a relação de destino. O status RLS da relação de destino não afeta a instrução ALTER TABLE APPEND.
+ Para facilitar a migração de outros sistemas de data warehouse, é possível definir e recuperar variáveis de contexto de sessão personalizadas para uma conexão especificando o nome e o valor da variável.
O exemplo a seguir define variáveis de contexto de sessão para uma política de segurança no nível da linha (RLS).
```
-- Set a customized context variable.
SELECT set_config(‘app.category’, ‘Concerts’, FALSE);
-- Create a RLS policy using current_setting() to get the value of a customized context variable.
CREATE RLS POLICY policy_categories
WITH (catgroup VARCHAR(10))
USING (catgroup = current_setting('app.category', FALSE));
-- Set correct roles and attach the policy on the target table to one or more roles.
ATTACH RLS POLICY policy_categories ON tickit_category_redshift TO ROLE analyst, ROLE dbadmin;
```
Para obter detalhes sobre como definir e recuperar variáveis de contexto de sessão personalizadas, acesse [SET](r_SET.md), [SET\$1CONFIG](r_SET_CONFIG.md), [SHOW](r_SHOW.md), [CURRENT\$1SETTING](r_CURRENT_SETTING.md) e [RESET](r_RESET.md). Para obter mais informações sobre como modificar a configuração do servidor em geral, acesse [Modificar a configuração do servidor](cm_chap_ConfigurationRef.md#t_Modifying_the_default_settings).
**Importante**
Quando são usadas variáveis de contexto de sessão em políticas de RLS, a política de segurança depende do usuário ou da função que invoca a política. Tenha cuidado para evitar vulnerabilidades de segurança ao usar variáveis de contexto de sessão em políticas de RLS.
+ Alterar o usuário da sessão usando SET SESSION AUTHORIZATION entre DECLARE e FETCH, ou entre instruções FETCH subsequentes, não atualizará o plano já preparado com base nas políticas do usuário no momento de DECLARE. Evite alterar o usuário da sessão quando os cursores são usados com tabelas protegidas por RLS.
+ Quando os objetos de base dentro de um objeto de visualização são protegidos por RLS, as políticas anexadas ao usuário que executa a consulta são aplicadas nos respectivos objetos de base. Isso é diferente das verificações de permissão por objeto, onde as permissões do proprietário da visualização são comparadas com os objetos de base da visualização. Você pode visualizar as relações protegidas por RLS de uma consulta na saída do plano EXPLAIN.
+ Quando uma função definida pelo usuário (UDF) é mencionada em uma política de RLS de uma relação anexada a um usuário, o usuário deve ter a permissão EXECUTE sobre a UDF para consultar a relação.
+ A segurança no nível da linha pode limitar a otimização de consultas. É recomendável avaliar cuidadosamente o desempenho da consulta antes de implantar exibições protegidas por RLS em conjuntos de dados grandes.
+ As políticas de segurança no nível da linha aplicadas às exibições de vinculação tardia podem ser inseridas em tabelas federadas. Essas políticas RLS podem estar visíveis em logs do mecanismo de processamento externos.
## Limitações
Veja a seguir as limitações ao trabalhar com políticas de RLS:
+ Não é possível anexar políticas de RLS a tabelas externas e a vários outros tipos de relação. Para obter mais informações, consulte [ATTACH RLS POLICY](r_ATTACH_RLS_POLICY.md).
+ O Amazon Redshift é compatível com a instruções SELECT para determinadas políticas de RLS com pesquisas que têm junções complexas, mas não são compatíveis com instruções UPDATE ou DELETE. Nos casos com instruções UPDATE ou DELETE, o Amazon Redshift retorna o seguinte erro:
```
ERROR: One of the RLS policies on target relation is not supported in UPDATE/DELETE.
```
+ Sempre que uma função definida pelo usuário (UDF) é mencionada em uma política de RLS de uma relação anexada a um usuário, o usuário deve ter a permissão EXECUTE sobre a UDF para consultar a relação.
+ Subconsultas correlacionadas não são compatíveis. O Amazon Redshift retorna o erro a seguir:
```
ERROR: RLS policy could not be rewritten.
```
+ O Amazon Redshift não oferece suporte ao compartilhamento de dados com RLS. Se uma relação não tiver o RLS desativado para unidades de compartilhamento de dados, a consulta falhará no cluster de consumidores com o seguinte erro:
```
RLS-protected relation "rls_protected_table" cannot be accessed via datasharing query.
```
É possível desativar o RLS para unidades de compartilhamento de dados usando o comando ALTER TABLE com o parâmetro ROW LEVEL SECURITY OFF FOR DATASHARES. Consulte mais informações sobre como usar ALTER TABLE para habilitar ou desabilitar o RLS em [ALTER TABLE](r_ALTER_TABLE.md).
+ Em consultas entre bancos de dados, o Amazon Redshift bloqueia as leituras de relações protegidas por RLS. Usuários com a permissão IGNORE RLS podem acessar a relação protegida usando consultas entre bancos de dados. Quando um usuário sem a permissão IGNORE RLS acessa uma relação protegida por RLS por meio de uma consulta entre bancos de dados, o seguinte erro é exibido:
```
RLS-protected relation "rls_protected_table" cannot be accessed via cross-database query.
```
+ ALTER RLS POLICY só comporta a modificação de uma política de RLS por meio da cláusula USING ( using\$1predicate\$1exp ). Não é possível modificar uma política de RLS com uma cláusula WITH ao executar ALTER RLS POLICY.
+ Você não poderá consultar relações que tenham a segurança por linha ativada se os valores de qualquer uma das opções de configuração abaixo 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 a segurança por linha ativada e vir a mensagem “RLS 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 segurança por linha, os seguintes comandos são bloqueados para usuários comuns:
```
ALTER SET enable_case_sensitive_super_attribute/enable_case_sensitive_identifier/downcase_delimited_identifier
```
Ao criar políticas de RLS, 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](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html) no *Guia de gerenciamento do Amazon Redshift*. Para obter mais informações sobre o comando ALTER USER, consulte [ALTER USER](r_ALTER_USER.md).
+ As exibições e as exibições de vinculação tardia com políticas de segurança no nível da linha não podem ser substituídas por usuários regulares usando o comando [CREATE VIEW](r_CREATE_VIEW.md). Para substituir exibições ou LBVs por políticas RLS, primeiro desanexe todas as políticas RLS anexadas, substitua as exibições ou LBVs e reanexe as políticas. Os superusuários e usuários com o `sys:secadmin permission` podem usar CREATE VIEW em exibições ou LBVs com políticas RLS sem desanexar as políticas.
+ As exibições com políticas de segurança no nível da linha não podem referenciar tabelas e exibições de sistema.
+ Uma exibição de vinculação tardia referenciada por uma exibição normal não pode ser protegida por RLS.
+ As relações protegidas por RLS e os dados aninhados de data lakes não podem ser acessados na mesma consulta.
# Práticas recomendadas para desempenho de RLS
Veja a seguir as práticas recomendadas para garantir um melhor desempenho do Amazon Redshift em tabelas protegidas por RLS.
## Segurança dos operadores e funções
Ao consultar tabelas protegidas por RLS, o uso de determinados operadores ou funções pode levar à degradação do desempenho. O Amazon Redshift classifica operadores e funções como seguros ou não seguros para consultar tabelas protegidas por RLS. Uma função ou operador é classificado como seguro para RLS quando não tem efeitos colaterais observáveis, dependendo das entradas. Em particular, uma função ou operador seguro para RLS não pode ser um dos seguintes:
+ Produz um valor de entrada, ou qualquer valor que seja dependente do valor de entrada, com ou sem uma mensagem de erro.
+ Falha ou retorna erros que são dependentes do valor de entrada.
Os operadores não seguros para RLS incluem:
+ Operadores aritméticos: \$1, -, /, \$1, %.
+ Operadores de texto: LIKE e SIMILAR TO.
+ Operadores Cast.
+ UDFs.
Use a seguinte instrução SELECT para verificar a segurança dos operadores e das funções.
```
SELECT proname, proc_is_rls_safe(oid) FROM pg_proc;
```
O Amazon Redshift impõe restrições na ordem de avaliação dos predicados do usuário que contêm operadores e funções não seguros para RLS ao planejar consultas em tabelas protegidas por RLS. Consultas que fazem referência a operadores ou funções não seguras para RLS podem causar degradação do desempenho ao consultar tabelas protegidas por RLS. O desempenho pode degradar significativamente quando o Amazon Redshift não pode enviar predicados não seguros para RLS para varreduras de tabela base para aproveitar as chaves de classificação. Para obter um melhor desempenho, evite consultas usando predicados não seguros para RLS que tiram proveito de uma chave de classificação. Para verificar se o Amazon Redshift é capaz de enviar operadores e funções, é possível usar instruções EXPLAIN em combinação com a permissão de sistema EXPLAIN RLS.
## Armazenamento em cache dos resultados
Para reduzir o tempo de execução da consulta e melhorar a performance do sistema, o Amazon Redshift armazena em cache os resultados de certos tipos de consultas na memória no nó líder.
O Amazon Redshift usa resultados armazenados em cache para uma nova consulta que verifica tabelas protegidas por RLS quando todas as condições para tabelas desprotegidas são verdadeiras e quando todas as seguintes opções são verdadeiras:
+ As tabelas ou as exibições na política não foram modificadas.
+ A política não usa uma função que precisa ser avaliada cada vez que ela é executada, por exemplo GETDATE ou CURRENT\$1USER.
Para melhorar a performance, evite usar predicados de política que não satisfaçam as condições anteriores.
Para obter mais informações sobre o armazenamento em cache de resultados no Amazon Redshift, consulte [Armazenamento em cache dos resultados](c_challenges_achieving_high_performance_queries.md#result-caching).
## Políticas complexas
Para obter um melhor desempenho, evite usar políticas complexas com subconsultas que unem várias tabelas.
# Exemplo completo de segurança em nível de linha
Este é um exemplo de ponta a ponta para ilustrar como um superusuário cria alguns usuários e funções. Em seguida, um usuário com a função secadmin cria, anexa, desanexa e descarta políticas de RLS. Este exemplo usa o exemplo do banco de dados tickit. Para obter mais informações, consulte [Carregar dados do Amazon S3 para o Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-create-sample-db.html) no *Guia de conceitos básicos do Amazon Redshift*.
```
-- Create users and roles referenced in the policy statements.
CREATE ROLE analyst;
CREATE ROLE consumer;
CREATE ROLE dbadmin;
CREATE ROLE auditor;
CREATE USER bob WITH PASSWORD 'Name_is_bob_1';
CREATE USER alice WITH PASSWORD 'Name_is_alice_1';
CREATE USER joe WITH PASSWORD 'Name_is_joe_1';
CREATE USER molly WITH PASSWORD 'Name_is_molly_1';
CREATE USER bruce WITH PASSWORD 'Name_is_bruce_1';
GRANT ROLE sys:secadmin TO bob;
GRANT ROLE analyst TO alice;
GRANT ROLE consumer TO joe;
GRANT ROLE dbadmin TO molly;
GRANT ROLE auditor TO bruce;
GRANT ALL ON TABLE tickit_category_redshift TO PUBLIC;
GRANT ALL ON TABLE tickit_sales_redshift TO PUBLIC;
GRANT ALL ON TABLE tickit_event_redshift TO PUBLIC;
-- Create table and schema referenced in the policy statements.
CREATE SCHEMA target_schema;
GRANT ALL ON SCHEMA target_schema TO PUBLIC;
CREATE TABLE target_schema.target_event_table (LIKE tickit_event_redshift);
GRANT ALL ON TABLE target_schema.target_event_table TO PUBLIC;
-- Change session to analyst alice.
SET SESSION AUTHORIZATION alice;
-- Check the tuples visible to analyst alice.
-- Should contain all 3 categories.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
CREATE RLS POLICY policy_concerts
WITH (catgroup VARCHAR(10))
USING (catgroup = 'Concerts');
SELECT poldb, polname, polalias, polatts, polqual, polenabled, polmodifiedby FROM svv_rls_policy WHERE poldb = CURRENT_DATABASE();
ATTACH RLS POLICY policy_concerts ON tickit_category_redshift TO ROLE analyst, ROLE dbadmin;
ALTER TABLE tickit_category_redshift ROW LEVEL SECURITY ON;
SELECT * FROM svv_rls_attached_policy;
-- Change session to analyst alice.
SET SESSION AUTHORIZATION alice;
-- Check that tuples with only `Concert` category will be visible to analyst alice.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to consumer joe.
SET SESSION AUTHORIZATION joe;
-- Although the policy is attached to a different role, no tuples will be
-- visible to consumer joe because the default deny all policy is applied.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to dbadmin molly.
SET SESSION AUTHORIZATION molly;
-- Check that tuples with only `Concert` category will be visible to dbadmin molly.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Check that EXPLAIN output contains RLS SecureScan to prevent disclosure of
-- sensitive information such as RLS filters.
EXPLAIN SELECT catgroup, count(*) FROM tickit_category_redshift GROUP BY catgroup ORDER BY catgroup;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
-- Grant IGNORE RLS permission so that RLS policies do not get applicable to role dbadmin.
GRANT IGNORE RLS TO ROLE dbadmin;
-- Grant EXPLAIN RLS permission so that anyone in role auditor can view complete EXPLAIN output.
GRANT EXPLAIN RLS TO ROLE auditor;
-- Change session to dbadmin molly.
SET SESSION AUTHORIZATION molly;
-- Check that all tuples are visible to dbadmin molly because `IGNORE RLS` is granted to role dbadmin.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to auditor bruce.
SET SESSION AUTHORIZATION bruce;
-- Check explain plan is visible to auditor bruce because `EXPLAIN RLS` is granted to role auditor.
EXPLAIN SELECT catgroup, count(*) FROM tickit_category_redshift GROUP BY catgroup ORDER BY catgroup;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
DETACH RLS POLICY policy_concerts ON tickit_category_redshift FROM ROLE analyst, ROLE dbadmin;
-- Change session to analyst alice.
SET SESSION AUTHORIZATION alice;
-- Check that no tuples are visible to analyst alice.
-- Although the policy is detached, no tuples will be visible to analyst alice
-- because of default deny all policy is applied if the table has RLS on.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
CREATE RLS POLICY policy_events
WITH (eventid INTEGER) AS ev
USING (
ev.eventid IN (SELECT eventid FROM tickit_sales_redshift WHERE qtysold <3)
);
ATTACH RLS POLICY policy_events ON tickit_event_redshift TO ROLE analyst;
ATTACH RLS POLICY policy_events ON target_schema.target_event_table TO ROLE consumer;
RESET SESSION AUTHORIZATION;
-- Can not cannot alter type of dependent column.
ALTER TABLE target_schema.target_event_table ALTER COLUMN eventid TYPE float;
ALTER TABLE tickit_event_redshift ALTER COLUMN eventid TYPE float;
ALTER TABLE tickit_sales_redshift ALTER COLUMN eventid TYPE float;
ALTER TABLE tickit_sales_redshift ALTER COLUMN qtysold TYPE float;
-- Can not cannot rename dependent column.
ALTER TABLE target_schema.target_event_table RENAME COLUMN eventid TO renamed_eventid;
ALTER TABLE tickit_event_redshift RENAME COLUMN eventid TO renamed_eventid;
ALTER TABLE tickit_sales_redshift RENAME COLUMN eventid TO renamed_eventid;
ALTER TABLE tickit_sales_redshift RENAME COLUMN qtysold TO renamed_qtysold;
-- Can not drop dependent column.
ALTER TABLE target_schema.target_event_table DROP COLUMN eventid CASCADE;
ALTER TABLE tickit_event_redshift DROP COLUMN eventid CASCADE;
ALTER TABLE tickit_sales_redshift DROP COLUMN eventid CASCADE;
ALTER TABLE tickit_sales_redshift DROP COLUMN qtysold CASCADE;
-- Can not drop lookup table.
DROP TABLE tickit_sales_redshift CASCADE;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
DROP RLS POLICY policy_concerts;
DROP RLS POLICY IF EXISTS policy_events;
ALTER TABLE tickit_category_redshift ROW LEVEL SECURITY OFF;
RESET SESSION AUTHORIZATION;
-- Drop users and roles.
DROP USER bob;
DROP USER alice;
DROP USER joe;
DROP USER molly;
DROP USER bruce;
DROP ROLE analyst;
DROP ROLE consumer;
DROP ROLE auditor FORCE;
DROP ROLE dbadmin FORCE;
```
# Segurança de metadados
Assim como a segurança no nível da linha do Amazon Redshift, a segurança de metadados oferece um controle mais granular sobre os metadados. Se a segurança de metadados estiver habilitada para o cluster provisionado ou o grupo de trabalho de tecnologia sem servidor, os usuários poderão ver metadados dos objetos aos quais têm acesso de exibição. A segurança de metadados permite a você separar a visibilidade com base nas necessidades. Por exemplo, você pode usar um único data warehouse para centralizar todo o armazenamento de dados. No entanto, se você armazenar dados de vários setores, o gerenciamento da segurança poderá se tornar problemático. Com a segurança de metadados habilitada, você pode configurar a visibilidade. Os usuários de um setor podem ter mais visibilidade sobre os objetos, ao mesmo tempo em que você restringe o acesso de exibição a usuários de outro setor. A segurança de metadados dá suporte a todos os tipos de objeto, como esquemas, tabelas, exibições, visões materializadas, procedimentos armazenados, funções definidas pelo usuário e modelos de machine learning.
Os usuários podem ver metadados de objetos sob as seguintes circunstâncias:
+ Se o acesso ao objeto for concedido ao usuário.
+ Se o acesso ao objeto for concedido a um grupo ou a uma função da qual o usuário faz parte.
+ O objeto é público.
+ O usuário é o proprietário do objeto do banco de dados.
Para habilitar a segurança de metadados, use o comando [ALTER SYSTEM](https://docs.aws.amazon.com/redshift/latest/dg/r_ALTER_SYSTEM.html). Esta é a sintaxe de como usar o comando ALTER SYSTEM com segurança de metadados.
```
ALTER SYSTEM SET metadata_security=[true|t|on|false|f|off];
```
Quando você habilita a segurança de metadados, todos os usuários que tenham as permissões necessárias conseguem ver os metadados relevantes de objetos aos quais têm acesso. Se você quiser que apenas determinados usuários consigam ver a segurança dos metadados, conceda a permissão `ACCESS CATALOG` a uma função e, em seguida, atribua a função ao usuário. Para obter mais informações sobre como usar funções para controlar melhor a segurança, consulte [Role-based access control](https://docs.aws.amazon.com/redshift/latest/dg/t_Roles.html).
O exemplo a seguir demonstra como conceder a permissão `ACCESS CATALOG` a uma função e, em seguida, atribuir a função a um usuário. Para obter mais informações sobre como conceder permissões, consulte o comando [GRANT](https://docs.aws.amazon.com/redshift/latest/dg/r_GRANT.html).
```
CREATE ROLE sample_metadata_viewer;
GRANT ACCESS CATALOG TO ROLE sample_metadata_viewer;
GRANT ROLE sample_metadata_viewer to salesadmin;
```
Se você preferir usar funções já definidas, as [funções definidas pelo sistema](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html) `operator`, `secadmin`, `dba` e `superuser` terão todas as permissões necessárias para exibir metadados de objeto. Por padrão, os superusuários conseguem ver o catálogo completo.
```
GRANT ROLE operator to sample_user;
```
Se estiver usando funções para controlar a segurança de metadados, você terá acesso a todas as exibições e funções do sistema que acompanham o controle de acesso baseado em funções. Por exemplo, é possível consultar a visualização [SVV\$1ROLES](https://docs.aws.amazon.com/redshift/latest/dg/r_SVV_ROLES.html) para ver todos os perfis. Para saber se um usuário é membro de uma função ou de um grupo, use a função [USER\$1IS\$1MEMBER\$1OF](https://docs.aws.amazon.com/redshift/latest/dg/r_USER_IS_MEMBER_OF.html). Para obter uma lista completa de exibições SVV, consulte você [ SVV metadata views](https://docs.aws.amazon.com/redshift/latest/dg/svv_views.html). Para obter uma lista das funções de informações do sistema, consulte [ System information functions](https://docs.aws.amazon.com/redshift/latest/dg/r_System_information_functions.html).
# Mascaramento dinâmico de dados
**nota**
O Amazon Redshift mascara automaticamente determinadas colunas das tabelas do sistema ao registrar informações sobre consultas feitas às visualizações do catálogo de dados para evitar a exposição de metadados confidenciais. Para obter mais informações, consulte [Registros em log seguros](https://docs.aws.amazon.com/redshift/latest/mgmt/db-auditing-secure-logging.html) no *Guia de gerenciamento do Amazon Redshift*.
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)](t_Roles.md). 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](t_ddm-conditional.md).
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.
# Comandos SQL para gerenciar políticas de mascaramento dinâmico de dados
Você pode realizar as seguintes ações para criar, anexar, desanexar e excluir políticas de mascaramento dinâmico de dados (DDM):
+ Para criar uma política de DDM, use o comando [CREATE MASKING POLICY](r_CREATE_MASKING_POLICY.md).
Veja a seguir um exemplo de criação de uma política de mascaramento usando uma função de hash SHA-2.
```
CREATE MASKING POLICY hash_credit
WITH (credit_card varchar(256))
USING (sha2(credit_card + 'testSalt', 256));
```
+ Para alterar uma política de DDM existente, use o comando [ALTER MASKING POLICY](r_ALTER_MASKING_POLICY.md).
Veja a seguir um exemplo de como alterar uma política de mascaramento existente.
```
ALTER MASKING POLICY hash_credit
USING (sha2(credit_card + 'otherTestSalt', 256));
```
+ Para anexar uma política de DDM em uma tabela a um ou mais usuários ou perfis, use o comando [ATTACH MASKING POLICY](r_ATTACH_MASKING_POLICY.md).
Veja a seguir um exemplo de como anexar uma política de mascaramento a um par de coluna/perfil.
```
ATTACH MASKING POLICY hash_credit
ON credit_cards (credit_card)
TO ROLE science_role
PRIORITY 30;
```
A cláusula PRIORITY determina qual política de mascaramento se aplica a uma sessão de usuário quando várias políticas estão anexadas à mesma coluna. Por exemplo, se o usuário no exemplo anterior tiver outra política de mascaramento anexada à mesma coluna de cartões de crédito com uma prioridade de 20, a política de science\$1role se aplicará, pois tem prioridade mais alta (30).
+ Para desanexar uma política de DDM em uma tabela de um ou mais usuários ou perfis, use o comando [DETACH MASKING POLICY](r_DETACH_MASKING_POLICY.md).
Veja a seguir um exemplo de como desanexar uma política de mascaramento de um par de coluna/perfil.
```
DETACH MASKING POLICY hash_credit
ON credit_cards(credit_card)
FROM ROLE science_role;
```
+ Para descartar uma política de DDM de todos os bancos de dados, use o comando [DROP MASKING POLICY](r_DROP_MASKING_POLICY.md).
Veja a seguir um exemplo de como descartar uma política de mascaramento de todos os bancos de dados.
```
DROP MASKING POLICY hash_credit;
```
# Hierarquia de políticas de mascaramento dinâmico de dados
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).
# Uso do mascaramento de dados dinâmico com caminhos do tipo de dados SUPER
O Amazon Redshift dá suporte à anexação de políticas de mascaramento de dados dinâmicas a caminhos das colunas do tipo SUPER. Para obter mais informações sobre tipos de dados SUPER, consulte [Dados semiestruturados no Amazon Redshift](super-overview.md).
Ao anexar políticas de mascaramento a caminhos de colunas do tipo SUPER, considere o seguinte.
+ Ao anexar uma política de mascaramento a um caminho em uma coluna, essa coluna deve ser definida como o tipo de dados SUPER. Você só pode aplicar políticas de mascaramento a valores *escalares* no caminho SUPER. Você não pode aplicar políticas de mascaramento a estruturas ou matrizes complexas.
+ Você pode aplicar políticas de mascaramento diferentes a vários valores escalares em uma única coluna SUPER, desde que os caminhos SUPER não entrem em conflito. Por exemplo, os caminhos SUPER `a.b` e `a.b.c` estão em conflito porque estão no mesmo caminho, com `a.b` sendo o pai de `a.b.c`. Os caminhos SUPER `a.b.c` e `a.b.d` não entram em conflito.
+ O Amazon Redshift não consegue verificar se os caminhos anexados por uma política de mascaramento existem nos dados e são do tipo esperado até que a política seja aplicada no runtime da consulta do usuário. Por exemplo, quando você anexar uma política de mascaramento que mascara valores TEXT a um caminho SUPER contendo um valor INT, o Amazon Redshift tentará converter o tipo do valor no caminho.
Nessas situações, o comportamento do Amazon Redshift no runtime depende das definições de configuração para consulta de objetos SUPER. Por padrão, o Amazon Redshift está em modo relaxado e vai resolver caminhos não encontrados e conversões inválidas como `NULL` para o caminho SUPER indicado. Para obter mais informações sobre definições de configuração relacionadas a SUPER, consulte [Configurações SUPER](super-configurations.md).
+ SUPER é um tipo sem esquema, o que significa que o Amazon Redshift não consegue confirmar a existência do valor em um determinado caminho SUPER. Se você anexar uma política de mascaramento a um caminho SUPER não existente e o Amazon Redshift estiver em modo flexível, o Amazon Redshift vai resolver o caminho para um valor `NULL`. É recomendável considerar o formato esperado de objetos SUPER e a probabilidade de terem atributos inesperados durante a anexação das políticas de mascaramento aos caminhos de colunas SUPER. Se você acha que possa haver um esquema inesperado na coluna SUPER, considere anexar diretamente as políticas de mascaramento à coluna SUPER. Você pode usar as funções de informações do tipo SUPER para verificar atributos e tipos e usar `OBJECT_TRANSFORM` para mascarar os valores. Para obter mais informações sobre funções de informações do tipo SUPER, consulte [Funções de informação de tipo SUPER](c_Type_Info_Functions.md).
## Exemplos
**Anexação das políticas de mascaramento a caminhos SUPER**
O exemplo a seguir anexa várias políticas de mascaramento a vários caminhos do tipo SUPER em uma coluna.
```
CREATE TABLE employees (
col_person SUPER
);
INSERT INTO employees
VALUES
(
json_parse('
{
"name": {
"first": "John",
"last": "Doe"
},
"age": 25,
"ssn": "111-22-3333",
"company": "Company Inc."
}
')
),
(
json_parse('
{
"name": {
"first": "Jane",
"last": "Appleseed"
},
"age": 34,
"ssn": "444-55-7777",
"company": "Organization Org."
}
')
)
;
GRANT ALL ON ALL TABLES IN SCHEMA "public" TO PUBLIC;
-- Create the masking policies.
-- This policy converts the given name to all uppercase letters.
CREATE MASKING POLICY mask_first_name
WITH(first_name TEXT)
USING ( UPPER(first_name) );
-- This policy replaces the given name with the fixed string 'XXXX'.
CREATE MASKING POLICY mask_last_name
WITH(last_name TEXT)
USING ( 'XXXX'::TEXT );
-- This policy rounds down the given age to the nearest 10.
CREATE MASKING POLICY mask_age
WITH(age INT)
USING ( (FLOOR(age::FLOAT / 10) * 10)::INT );
-- This policy converts the first five digits of the given SSN to 'XXX-XX'.
CREATE MASKING POLICY mask_ssn
WITH(ssn TEXT)
USING ( 'XXX-XX-'::TEXT || SUBSTRING(ssn::TEXT FROM 8 FOR 4) );
-- Attach the masking policies to the employees table.
ATTACH MASKING POLICY mask_first_name
ON employees(col_person.name.first)
TO PUBLIC;
ATTACH MASKING POLICY mask_last_name
ON employees(col_person.name.last)
TO PUBLIC;
ATTACH MASKING POLICY mask_age
ON employees(col_person.age)
TO PUBLIC;
ATTACH MASKING POLICY mask_ssn
ON employees(col_person.ssn)
TO PUBLIC;
-- Verify that your masking policies are attached.
SELECT
policy_name,
TABLE_NAME,
priority,
input_columns,
output_columns
FROM
svv_attached_masking_policy;
policy_name | table_name | priority | input_columns | output_columns
-----------------+------------+----------+-----------------------------------+-----------------------------------
mask_age | employees | 0 | ["col_person.\"age\""] | ["col_person.\"age\""]
mask_first_name | employees | 0 | ["col_person.\"name\".\"first\""] | ["col_person.\"name\".\"first\""]
mask_last_name | employees | 0 | ["col_person.\"name\".\"last\""] | ["col_person.\"name\".\"last\""]
mask_ssn | employees | 0 | ["col_person.\"ssn\""] | ["col_person.\"ssn\""]
(4 rows)
-- Observe the masking policies taking effect.
SELECT col_person FROM employees ORDER BY col_person.age;
-- This result is formatted for ease of reading.
col_person
--------------------------------
{
"name": {
"first": "JOHN",
"last": "XXXX"
},
"age": 20,
"ssn": "XXX-XX-3333",
"company": "Company Inc."
}
{
"name": {
"first": "JANE",
"last": "XXXX"
},
"age": 30,
"ssn": "XXX-XX-7777",
"company": "Organization Org."
}
```
Estes são alguns exemplos de anexos da política de mascaramento inválidos aos caminhos SUPER.
```
-- This attachment fails because there is already a policy
-- with equal priority attached to employees.name.last, which is
-- on the same SUPER path as employees.name.
ATTACH MASKING POLICY mask_ssn
ON employees(col_person.name)
TO PUBLIC;
ERROR: DDM policy "mask_last_name" is already attached on relation "employees" column "col_person."name"."last"" with same priority
-- Create a masking policy that masks DATETIME objects.
CREATE MASKING POLICY mask_date
WITH(INPUT DATETIME)
USING ( INPUT );
-- This attachment fails because SUPER type columns can't contain DATETIME objects.
ATTACH MASKING POLICY mask_date
ON employees(col_person.company)
TO PUBLIC;
ERROR: cannot attach masking policy for output of type "timestamp without time zone" to column "col_person."company"" of type "super
```
Este é um exemplo de anexação de uma política de mascaramento a um caminho SUPER não existente. Por padrão, o Amazon Redshift vai resolver o caminho para `NULL`.
```
ATTACH MASKING POLICY mask_first_name
ON employees(col_person.not_exists)
TO PUBLIC;
SELECT col_person FROM employees LIMIT 1;
-- This result is formatted for ease of reading.
col_person
-----------------------------------
{
"name": {
"first": "JOHN",
"last": "XXXX"
},
"age": 20,
"ssn": "XXX-XX-3333",
"company": "Company Inc.",
"not_exists": null
}
```
# Mascaramento dinâmico de dados condicional
Você pode mascarar dados no nível de célula criando políticas de mascaramento com expressões condicionais na expressão de mascaramento. Por exemplo, você pode criar uma política de mascaramento que aplica máscaras diferentes a um valor, dependendo do valor de outra coluna nessa linha.
Veja a seguir um exemplo de como usar o mascaramento condicional de dados para criar e anexar uma política de mascaramento que edita parcialmente os números de cartão de crédito envolvidos em fraudes e oculta completamente todos os outros números de cartão de crédito. Você deve ser um superusuário ou ter o perfil [https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html) para executar este exemplo.
```
--Create an analyst role.
CREATE ROLE analyst;
--Create a credit card table. The table contains an is_fraud boolean column,
--which is TRUE if the credit card number in that row was involved in a fraudulent transaction.
CREATE TABLE credit_cards (id INT, is_fraud BOOLEAN, credit_card_number VARCHAR(16));
--Create a function that partially redacts credit card numbers.
CREATE FUNCTION REDACT_CREDIT_CARD (credit_card VARCHAR(16))
RETURNS VARCHAR(16) 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 partially redacts credit card numbers if the is_fraud value for that row is TRUE,
--and otherwise blanks out the credit card number completely.
CREATE MASKING POLICY card_number_conditional_mask
WITH (fraudulent BOOLEAN, pan varchar(16))
USING (CASE WHEN fraudulent THEN REDACT_CREDIT_CARD(pan)
ELSE Null
END);
--Attach the masking policy to the credit_cards/analyst table/role pair.
ATTACH MASKING POLICY card_number_conditional_mask ON credit_cards (credit_card_number)
USING (is_fraud, credit_card_number)
TO ROLE analyst PRIORITY 100;
```
# Visualizações do sistema de mascaramento dinâmico de dados
Superusuários, usuários com a função `sys:operator` e usuários com a permissão ACCESS SYSTEM TABLE podem acessar as visualizações de sistema relacionadas a DDM a seguir.
+ [SVV\$1MASKING\$1POLICY](r_SVV_MASKING_POLICY.md)
Use SVV\$1MASKING\$1POLICY para visualizar todas as políticas de mascaramento criadas no cluster ou grupo de trabalho.
+ [SVV\$1ATTACHED\$1MASKING\$1POLICY](r_SVV_ATTACHED_MASKING_POLICY.md)
Use SVV\$1ATTACHED\$1MASKING\$1POLICY para visualizar todas as relações e usuários ou funções com políticas anexadas no banco de dados atualmente conectado.
+ [SYS\$1APPLIED\$1MASKING\$1POLICY\$1LOG](SYS_APPLIED_MASKING_POLICY_LOG.md)
Use SYS\$1APPLIED\$1MASKING\$1POLICY\$1LOG para monitorar a aplicação de políticas de mascaramento em consultas que fazem referência a relações protegidas por DDM.
Veja a seguir alguns exemplos das informações que você pode encontrar usando as visualizações do sistema.
```
--Select all policies associated with specific users, as opposed to roles
SELECT policy_name,
schema_name,
table_name,
grantee
FROM svv_attached_masking_policy
WHERE grantee_type = 'user';
--Select all policies attached to a specific user
SELECT policy_name,
schema_name,
table_name,
grantee
FROM svv_attached_masking_policy
WHERE grantee = 'target_grantee_name'
--Select all policies attached to a given table
SELECT policy_name,
schema_name,
table_name,
grantee
FROM svv_attached_masking_policy
WHERE table_name = 'target_table_name'
AND schema_name = 'target_schema_name';
--Select the highest priority policy attachment for a given role
SELECT samp.policy_name,
samp.priority,
samp.grantee,
smp.policy_expression
FROM svv_masking_policy AS smp
JOIN svv_attached_masking_policy AS samp
ON samp.policy_name = smp.policy_name
WHERE
samp.grantee_type = 'role' AND
samp.policy_name = mask_get_policy_for_role_on_column(
'target_schema_name',
'target_table_name',
'target_column_name',
'target_role_name')
ORDER BY samp.priority desc
LIMIT 1;
--See which policy a specific user will see on a specific column in a given relation
SELECT samp.policy_name,
samp.priority,
samp.grantee,
smp.policy_expression
FROM svv_masking_policy AS smp
JOIN svv_attached_masking_policy AS samp
ON samp.policy_name = smp.policy_name
WHERE
samp.grantee_type = 'role' AND
samp.policy_name = mask_get_policy_for_user_on_column(
'target_schema_name',
'target_table_name',
'target_column_name',
'target_user_name')
ORDER BY samp.priority desc;
--Select all policies attached to a given relation.
SELECT policy_name,
schema_name,
relation_name,
database_name
FROM sys_applied_masking_policy_log
WHERE relation_name = 'relation_name'
AND schema_name = 'schema_name';
```
# 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\$1EXPLAIN\$1DDM podem ver as políticas de mascaramento aplicadas nas saídas do EXPLAIN. Os usuários não têm a permissão SYS\$1EXPLAIN\$1DDM 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](r_EXPLAIN.md).
+ 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](t_rls.md).
+ Ao usar o comando [COPY](r_COPY.md) 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](copy-parameters-column-mapping.md).
+ 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
+ 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.
+ Não é possível usar políticas de DDM 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. A tentativa de adicionar a relação com uma unidade de compartilhamento de dados falhará no cluster ou namespace do lado do produtor com o seguinte erro:
```
or a relation dependent on it is protected by a masking policy and cannot be added to a datashare
```
Se você anexar uma política de mascaramento a uma relação no lado do produtor e ela já estiver incluída em uma unidade de compartilhamento de dados, a tentativa de consultar a relação no lado do consumidor falhará com o seguinte erro:
```
cross-cluster query of the masked relation is not supported.
```
É possível desativar o DDM para unidades de compartilhamento de dados usando o comando ALTER TABLE com o parâmetro MASKING OFF FOR DATASHARES. Para obter mais informações, consulte [ALTER TABLE](r_ALTER_TABLE.md).
+ 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 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](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html) no *Guia de gerenciamento do Amazon Redshift*. Para obter mais informações sobre o comando ALTER USER, consulte [ALTER USER](r_ALTER_USER.md).
+ 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](r_CREATE_VIEW.md). 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.
+ Você pode usar variáveis de contexto de sessão personalizadas ao criar políticas de DDM. O exemplo a seguir define variáveis de contexto de sessão para uma política de DDM.
```
-- Set a customized context variable.
SELECT set_config('app.city', 'XXXX', FALSE);
-- Create a MASKING policy using current_setting() to get the value of a customized context variable.
CREATE MASKING POLICY city_mask
WITH (city VARCHAR(30))
USING (current_setting('app.city')::VARCHAR(30));
-- Attach the policy on the target table to one or more roles.
ATTACH MASKING POLICY city_mask
ON tickit_users_redshift(city)
TO ROLE analyst, ROLE dbadmin;
```
Para obter detalhes sobre como definir e recuperar variáveis de contexto de sessão personalizadas, acesse [SET](r_SET.md), [SET\$1CONFIG](r_SET_CONFIG.md), [SHOW](r_SHOW.md), [CURRENT\$1SETTING](r_CURRENT_SETTING.md) e [RESET](r_RESET.md). Para obter mais informações sobre como modificar a configuração do servidor em geral, acesse [Modificar a configuração do servidor](cm_chap_ConfigurationRef.md#t_Modifying_the_default_settings).
**Importante**
Quando são usadas variáveis de contexto de sessão em políticas de DDM, a política de segurança depende do usuário ou da função que invoca a política. Tenha cuidado para evitar vulnerabilidades de segurança ao usar variáveis de contexto de sessão em políticas de DDM.
# Exemplo completo do mascaramento dinâmico de dados
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 [https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html) 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;
```
# Permissões em escopo
Com as permissões em escopo, é possível conceder permissões a um usuário ou função em todos os objetos de um tipo em um banco de dados ou esquema. Usuários e funções com permissões em escopo têm as permissões especificadas em todos os objetos atuais e futuros no banco de dados ou esquema.
Você pode visualizar o escopo das permissões com escopo em nível de banco de dados em [SVV\$1DATABASE\$1PRIVILEGES](r_SVV_DATABASE_PRIVILEGES.md). Você pode visualizar o escopo das permissões com escopo em nível de esquema em [SVV\$1SCHEMA\$1PRIVILEGES](r_SVV_SCHEMA_PRIVILEGES.md).
Para obter mais informações sobre a aplicação de permissões em escopo definido, consulte [GRANT](r_GRANT.md) e [REVOKE](r_REVOKE.md).
# Considerações sobre como usar permissões em escopo
Ao usar permissões em escopo, considere o seguinte:
+ Você pode usar permissões em escopo a fim de conceder ou revogar permissões em um escopo de banco de dados ou esquema de uma função ou de um usuário especificado.
+ Não é possível conceder permissões em escopo a grupos de usuários.
+ A concessão ou a revogação de permissões em escopo altera permissões de todos os objetos atuais e futuros no escopo.
+ As permissões em escopo e em nível de objeto operam independentemente uma da outra. Por exemplo, um usuário manterá as permissões em uma tabela nos dois casos a seguir.
+ O usuário recebe a permissão SELECT na tabela schema1.table1 e a permissão SELECT em escopo na tabela schema1. O usuário revoga SELECT para todas as tabelas no esquema schema1. O usuário retém SELECT em schema1.table1.
+ O usuário recebe a permissão SELECT na tabela schema1.table1 e a permissão SELECT em escopo na tabela schema1. O usuário revoga SELECT para schema1.table1. O usuário retém SELECT em schema1.table1.
+ Para conceder ou revogar permissões em escopo, você deve atender a um dos seguintes critérios:
+ Superusuários.
+ Usuários com a opção de concessão dessa permissão. Para obter mais informações sobre opções de concessão, consulte o parâmetro WITH GRANT OPTION em [GRANT](r_GRANT.md).
+ As permissões em escopo só podem ser concedidas a ou revogadas de objetos do banco de dados conectado ou de bancos de dados importados de uma unidade de compartilhamento de dados.
+ Você pode usar permissões em escopo para definir as permissões padrão em um banco de dados criado em uma unidade de compartilhamento de dados. Um usuário da unidade de compartilhamento de dados no lado do consumidor que recebe permissões em escopo em um banco de dados compartilhado vai receber automaticamente essas permissões para qualquer novo objeto adicionado à unidade de compartilhamento de dados no lado do produtor.
+ Os produtores podem conceder permissões em escopo em objetos dentro de um esquema para uma unidade de compartilhamento de dados. (pré-visualização)