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/). # GRANT GRANT Define permissões de acesso para um usuário ou uma função. As permissões incluem opções de acesso como leitura de dados em tabelas e visualizações, gravação de dados e criação de tabelas. Use este comando para fornecer permissões específicas para uma tabela, banco de dados, esquema, função, procedimento, linguagem ou coluna. Para revogar permissões de um objeto de banco de dados, use o comando [REVOKE](r_REVOKE.md). As permissões também incluem as seguintes opções de acesso do produtor da unidade de compartilhamento de dados: + Concessão de acesso à unidade de compartilhamento de dados para namespaces e contas de consumidores. + Concessão de permissão para alterar uma unidade de compartilhamento de dados adicionando ou removendo objetos da unidade de compartilhamento de dados. + Concessão de permissão para compartilhar uma unidade de compartilhamento de dados adicionando ou removendo namespaces de consumidores da unidade de compartilhamento de dados. As opções de acesso do consumidor à unidade de compartilhamento de dados são as seguintes: + Concessão a usuários de acesso total a bancos de dados criados a partir de uma unidade de compartilhamento de dados ou a esquemas externos que apontem para esses bancos de dados. + Concessão a usuários de permissões no nível do objeto em bancos de dados criados a partir de uma unidade de compartilhamento de dados como a que você pode para objetos de banco de dados. Para conceder esse nível de permissão, você deve usar a cláusula WITH PERMISSIONS ao criar um banco de dados a partir da unidade de compartilhamento de dados. Para obter mais informações, consulte [CREATE DATABASE](r_CREATE_DATABASE.md). Para obter mais informações sobre permissões da unidade de compartilhamento de dados, consulte [Permissões que você pode conceder a unidades de compartilhamento de dados](permissions-datashares.md). As permissões também incluem o seguinte Catálogo de Permissões Federadas do Amazon Redshift: + Conceder permissões em nível de tabela a usuários e perfis. + Conceder permissões refinadas em nível de coluna em tabelas, visualizações e visões materializadas. + Conceder permissões com escopo a usuários e perfis. + Conceder permissões em nível de banco de dados no Catálogo de Permissões Federadas do Amazon Redshift. Para acessar mais informações sobre o gerenciamento de permissões no Catálogo de Permissões Federadas do Amazon Redshift, consulte [Gerenciar o controle de acesso no catálogo de permissões federadas do Amazon RedshiftConcessão/revogação](federated-permissions-managing-access.md). Para acessar mais informações sobre as sintaxes de concessão/revogação aceitas pelo Catálogo de Permissões Federadas do Amazon Redshift, consulte [Concessão/revogação](https://docs.aws.amazon.com/redshift/latest/dg/federated-permissions-managing-access.html#federated-permissions-managing-access-grant-revoke). As permissões também incluem o privilégio CONNECT para usuários federados do Centro de Identidade do AWS IAM. Esse privilégio permite que os administradores controlem o acesso do usuário por meio de permissões granulares em cada grupo de trabalho ou cluster do Amazon Redshift em que as permissões federadas do Amazon Redshift estão habilitadas. O administrador do Amazon Redshift pode especificar quais usuários ou grupos federados do Centro de Identidade do AWS IAM têm acesso para se conectar diretamente ao grupo de trabalho do Amazon Redshift, fornecendo controle refinado sobre o acesso do usuário em cada grupo de trabalho ou cluster do Centro de Identidade do AWS IAM. Você também pode conceder perfis para gerenciar permissões de banco de dados e controlar o que os usuários podem fazer em relação aos seus dados. Ao definir perfis e atribuí-los aos usuários, você pode limitar as ações que esses usuários podem realizar, como limitar os usuários somente aos comandos CREATE TABLE e INSERT. Para obter mais informações sobre o comando CREATE ROLE, consulte [CREATE ROLE](r_CREATE_ROLE.md). O Amazon Redshift tem alguns perfis definidos pelo sistema que você também pode usar para conceder permissões específicas aos seus usuários. Para obter mais informações, consulte [Funções definidas pelo sistema do Amazon Redshift](r_roles-default.md). Só é possível CONCEDER ou REVOGAR permissões de USO em um esquema externo para usuários de banco de dados e grupos de usuários que usam a sintaxe ON SCHEMA. Ao usar ON EXTERNAL SCHEMA com AWS Lake Formation, só é possível conceder (GRANT) e revogar (REVOKE) permissões para um perfil do AWS Identity and Access Management (IAM). Para obter a lista de permissões, consulte a sintaxe. Para procedimentos armazenados, a única permissão que pode ser concedida é EXECUTE. Não é possível executar GRANT (em um recurso externo) em um bloco de transação (BEGIN ... END). Para obter mais informações sobre transações, consulte [Níveis de isolamento no Amazon Redshift](c_serial_isolation.md). Para ver quais permissões os usuários receberam para um banco de dados, use [HAS\$1DATABASE\$1PRIVILEGE](r_HAS_DATABASE_PRIVILEGE.md). Para ver quais permissões os usuários receberam para um esquema, use [HAS\$1SCHEMA\$1PRIVILEGE](r_HAS_SCHEMA_PRIVILEGE.md). Para ver quais permissões os usuários receberam para uma tabela, use [HAS\$1TABLE\$1PRIVILEGE](r_HAS_TABLE_PRIVILEGE.md). ## Sintaxe Sintaxe ``` GRANT { { SELECT | INSERT | UPDATE | DELETE | DROP | REFERENCES | ALTER | TRUNCATE } [,...] | ALL [ PRIVILEGES ] } ON { [ TABLE ] table_name [, ...] | ALL TABLES IN SCHEMA schema_name [, ...] } TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { { CREATE | USAGE | TEMPORARY | TEMP | ALTER } [,...] | ALL [ PRIVILEGES ] } ON DATABASE db_name [, ...] TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { { CREATE | USAGE | ALTER | DROP } [,...] | ALL [ PRIVILEGES ] } ON SCHEMA schema_name [, ...] TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { EXECUTE | ALL [ PRIVILEGES ] } ON { FUNCTION function_name ( [ [ argname ] argtype [, ...] ] ) [, ...] | ALL FUNCTIONS IN SCHEMA schema_name [, ...] } TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { EXECUTE | ALL [ PRIVILEGES ] } ON { PROCEDURE procedure_name ( [ [ argname ] argtype [, ...] ] ) [, ...] | ALL PROCEDURES IN SCHEMA schema_name [, ...] } TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT USAGE ON LANGUAGE language_name [, ...] TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { { ALTER | DROP} [,...] | ALL [ PRIVILEGES ] } ON COPY JOB job_name [,...] TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { { ALTER | DROP | USAGE } [,...] | ALL [ PRIVILEGES ] } ON TEMPLATE [database_name.][schema_name.]template_name [,...] TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] ``` ### Conceder permissões por coluna para tabelas A seguir está a sintaxe para permissões por coluna em tabelas e visualizações do Amazon Redshift. ``` GRANT { { SELECT | UPDATE } ( column_name [, ...] ) [, ...] | ALL [ PRIVILEGES ] ( column_name [,...] ) } ON { [ TABLE ] table_name [, ...] } TO { username | ROLE role_name | GROUP group_name | PUBLIC } [, ...] ``` ### Conceder permissões ASSUMEROLE A seguir está a sintaxe para as permissões ASSUMEROLE concedidas a usuários e grupos com um perfil especificado. Para começar a usar o privilégio ASSUMEROLE, consulte [Observações de uso para conceder a permissão ASSUMEROLE](r_GRANT-usage-notes.md#r_GRANT-usage-notes-assumerole). ``` GRANT ASSUMEROLE ON { 'iam_role' [, ...] | default | ALL } TO { username | ROLE role_name | GROUP group_name | PUBLIC } [, ...] FOR { ALL | COPY | UNLOAD | EXTERNAL FUNCTION | CREATE MODEL } [, ...] ``` ### Conceder permissões para integração do Redshift Spectrum com o Lake Formation A seguir está a sintaxe para integração do Redshift Spectrum com Lake Formation. ``` GRANT { SELECT | ALL [ PRIVILEGES ] } ( column_list ) ON EXTERNAL TABLE schema_name.table_name TO { IAM_ROLE iam_role } [, ...] [ WITH GRANT OPTION ] GRANT { { SELECT | ALTER | DROP | DELETE | INSERT } [, ...] | ALL [ PRIVILEGES ] } ON EXTERNAL TABLE schema_name.table_name [, ...] TO { { IAM_ROLE iam_role } [, ...] | PUBLIC } [ WITH GRANT OPTION ] GRANT { { CREATE | ALTER | DROP } [, ...] | ALL [ PRIVILEGES ] } ON EXTERNAL SCHEMA schema_name [, ...] TO { IAM_ROLE iam_role } [, ...] [ WITH GRANT OPTION ] ``` ### Conceder permissões da unidade de compartilhamento de dados **Permissões da unidade de compartilhamento de dados no lado do produtor** Esta é a sintaxe para usar GRANT a fim de conceder permissões ALTER ou SHARE a um usuário ou perfil. O usuário pode alterar a unidade de compartilhamento de dados com a permissão ALTER ou conceder o uso a um consumidor com a permissão SHARE. ALTER e SHARE são as únicas permissões que você pode conceder em uma unidade de compartilhamento de dados a usuários e funções. ``` GRANT { ALTER | SHARE } ON DATASHARE datashare_name TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] ``` A seguir está a sintaxe para usar GRANT para permissões de uso de unidade de compartilhamento de dados no Amazon Redshift. Você concede acesso de uma unidade de compartilhamento de dados a um consumidor usando a permissão USAGE. Você não pode conceder essa permissão a usuários ou grupos de usuários. Essa permissão também não é compatível com WITH GRANT OPTION para a instrução GRANT. Somente usuários ou grupos de usuários com a permissão SHARE concedida anteriormente a eles para (FOR) a unidade de compartilhamento de dados podem executar esse tipo de instrução GRANT. ``` GRANT USAGE ON DATASHARE datashare_name TO NAMESPACE 'namespaceGUID' | ACCOUNT 'accountnumber' [ VIA DATA CATALOG ] ``` Veja a seguir um exemplo de como conceder o uso de uma unidade de compartilhamento de dados a uma conta do Lake Formation. ``` GRANT USAGE ON DATASHARE salesshare TO ACCOUNT '123456789012' VIA DATA CATALOG; ``` **Permissões da unidade de compartilhamento de dados no lado do consumidor** A seguir está a sintaxe para permissões de uso de compartilhamento de dados GRANT em um banco de dados específico ou esquema criado a partir de um datashare. Outras permissões necessárias para consumidores terem acesso a um banco de dados criado a partir de uma unidade de compartilhamento de dados variam dependendo do comando CREATE DATABASE usado para criar o banco de dados a partir da unidade de compartilhamento de dados ter usado ou não a cláusula WITH PERMISSIONS. Para obter mais informações sobre o comando CREATE DATABASE e a cláusula WITH PERMISSIONS, consulte [CREATE DATABASE](r_CREATE_DATABASE.md). **Bancos de dados criados sem usar a cláusula WITH PERMISSIONS** Ao conceder USAGE em um banco de dados criado a partir de uma unidade de compartilhamento de dados sem a cláusula WITH PERMISSIONS, você não precisa conceder permissões separadamente nos objetos no banco de dados compartilhado. As entidades com uso concedido em bancos de dados criados a partir de unidades de compartilhamento de dados sem a cláusula WITH PERMISSIONS têm acesso automático a todos os objetos no banco de dados. **Bancos de dados criados usando a cláusula WITH PERMISSIONS** Quando você concede USAGE em um banco de dados no qual o banco de dados compartilhado foi criado a partir de uma unidade de compartilhamento de dados com a cláusula WITH PERMISSIONS, as identidades no lado do consumidor ainda devem receber as permissões relevantes para objetos de banco de dados no banco de dados compartilhado para terem acesso a eles, assim como você concederia permissões para objetos de banco de dados locais. Para conceder permissões a objetos em um banco de dados criado a partir de uma unidade de compartilhamento de dados, use a sintaxe de três partes `database_name.schema_name.object_name`. Para conceder permissões a objetos em um esquema externo apontando para um esquema compartilhado no banco de dados compartilhado, use a sintaxe de duas partes `schema_name.object_name`. ``` GRANT USAGE ON { DATABASE shared_database_name [, ...] | SCHEMA shared_schema} TO { username | ROLE role_name | GROUP group_name | PUBLIC } [, ...] ``` ### Concessão de 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 ter mais informações sobre permissões com escopo definido, consulte [Permissões em escopo](t_scoped-permissions.md). Esta é a sintaxe para concessão de permissões em escopo para usuários ou perfis. ``` GRANT { CREATE | USAGE | ALTER | DROP } [,...] | ALL [ PRIVILEGES ] } FOR SCHEMAS IN DATABASE db_name TO { username [ WITH GRANT OPTION ] | ROLE role_name } [, ...] GRANT { { SELECT | INSERT | UPDATE | DELETE | DROP | ALTER | TRUNCATE | REFERENCES } [, ...] } | ALL [PRIVILEGES] } } FOR TABLES IN {SCHEMA schema_name [DATABASE db_name ] | DATABASE db_name } TO { username [ WITH GRANT OPTION ] | ROLE role_name} [, ...] GRANT { EXECUTE | ALL [ PRIVILEGES ] } FOR FUNCTIONS IN {SCHEMA schema_name [DATABASE db_name ] | DATABASE db_name } TO { username [ WITH GRANT OPTION ] | ROLE role_name | } [, ...] GRANT { EXECUTE | ALL [ PRIVILEGES ] } FOR PROCEDURES IN {SCHEMA schema_name [DATABASE db_name ] | DATABASE db_name } TO { username [ WITH GRANT OPTION ] | ROLE role_name | } [, ...] GRANT USAGE FOR LANGUAGES IN {DATABASE db_name} TO { username [ WITH GRANT OPTION ] | ROLE role_name } [, ...] GRANT { { CREATE | ALTER | DROP} [,...] | ALL [ PRIVILEGES ] } FOR COPY JOBS IN DATABASE db_name TO { username [ WITH GRANT OPTION ] | ROLE role_name } [, ...] GRANT { { ALTER | DROP | USAGE } [,...] | ALL [ PRIVILEGES ] } FOR TEMPLATES IN {SCHEMA schema_name [DATABASE db_name ] | DATABASE db_name } TO { username [ WITH GRANT OPTION ] | ROLE role_name } [, ...] ``` Observe que as permissões no escopo não fazem distinção entre permissões para funções e procedimentos. Por exemplo, a declaração a seguir concede a `bob` a permissão `EXECUTE` para funções e procedimentos no esquema `Sales_schema`. ``` GRANT EXECUTE FOR FUNCTIONS IN SCHEMA Sales_schema TO bob; ``` ### Conceder permissões de machine learning A seguir está a sintaxe para permissões de modelos de machine learning no Amazon Redshift. ``` GRANT CREATE MODEL TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { EXECUTE | ALL [ PRIVILEGES ] } ON MODEL model_name [, ...] TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] ``` ### Conceder permissões de perfil A sintaxe a seguir concede perfis no Amazon Redshift. ``` GRANT { ROLE role_name } [, ...] TO { { user_name [ WITH ADMIN OPTION ] } | ROLE role_name }[, ...] ``` A sintaxe a seguir concede permissões de sistema a perfis no Amazon Redshift. Observe que você só pode conceder permissões para perfis, não para usuários. ``` GRANT { { CREATE USER | DROP USER | ALTER USER | CREATE SCHEMA | DROP SCHEMA | ALTER DEFAULT PRIVILEGES | ACCESS CATALOG | ACCESS SYSTEM TABLE CREATE TABLE | DROP TABLE | ALTER TABLE | CREATE OR REPLACE FUNCTION | CREATE OR REPLACE EXTERNAL FUNCTION | DROP FUNCTION | CREATE OR REPLACE PROCEDURE | DROP PROCEDURE | CREATE OR REPLACE VIEW | DROP VIEW | CREATE MODEL | DROP MODEL | CREATE DATASHARE | ALTER DATASHARE | DROP DATASHARE | CREATE LIBRARY | DROP LIBRARY | CREATE ROLE | DROP ROLE | TRUNCATE TABLE VACUUM | ANALYZE | CANCEL | IGNORE RLS | EXPLAIN RLS | EXPLAIN MASKING }[, ...] } | { ALL [ PRIVILEGES ] } TO ROLE role_name [, ...] ``` ### Conceder permissões de explicação para políticas de segurança Veja a seguir a sintaxe para conceder permissões para explicar os filtros de política de segurança de uma consulta no plano EXPLAIN. As políticas de segurança possíveis incluem segurança por linha e políticas de mascaramento dinâmico de dados. ``` GRANT EXPLAIN { RLS | MASKING } TO ROLE rolename ``` Veja a seguir a sintaxe para conceder permissões para ignorar políticas de segurança no nível da linha para uma consulta. Essa sintaxe não se aplica às políticas de mascaramento dinâmico de dados. ``` GRANT IGNORE RLS TO ROLE rolename ``` Veja a seguir a sintaxe para conceder permissões de tabela de pesquisa à política de segurança especificada. As políticas de segurança possíveis incluem segurança por linha e políticas de mascaramento dinâmico de dados. ``` GRANT SELECT ON [ TABLE ] table_name [, ...] TO { RLS | MASKING } POLICY policy_name [, ...] ``` ### Conceder permissões de conexão Veja a seguir a sintaxe para conceder permissões para usuários federados (ou grupos) do Centro de Identidade do AWS IAM se conectarem a um grupo de trabalho/cluster: ``` GRANT CONNECT [ON WORKGROUP] TO [USER] : | ROLE : | PUBLIC; ``` ## Parâmetros Parâmetros SELECT Concede permissão para selecionar dados de uma tabela ou visualização usando uma instrução SELECT. A permissão SELECT também é necessária para fazer referência a valores de coluna existentes para as operações UPDATE ou DELETE. INSERT Concede permissão para carregar dados em uma tabela usando uma instrução INSERT ou COPY. UPDATE Concede permissão para atualizar uma coluna de tabela usando a instrução UPDATE. As operações UPDATE também exigem a permissão SELECT, pois devem fazer referência a colunas da tabela para determinar que linhas atualizar ou computar novos valores para as colunas. DELETE Concede permissão para excluir uma linha de dados de uma tabela. As operações DELETE também necessitam do privilégio SELECT, pois devem fazer referência a colunas da tabela para determinar que linhas excluir. DROP Dependendo do objeto do banco de dados, concede as seguintes permissões ao usuário ou perfil: + Para tabelas, DROP concede permissão para remover uma tabela ou visualização. Para obter mais informações, consulte [DESCARTAR TABELA](r_DROP_TABLE.md). + Para bancos de dados, DROP concede permissão para remover um banco de dados. Para obter mais informações, consulte [DROP DATABASE](r_DROP_DATABASE.md). + Para esquemas, DROP concede permissão para remover um esquema. Para obter mais informações, consulte [DROP SCHEMA](r_DROP_SCHEMA.md). REFERENCES Concede permissão para criar uma restrição de chave estrangeira. Você precisa conceder essa permissão na tabela referenciada e na tabela que faz a referência. Caso contrário, o usuário não poderá criar a restrição. ALTER Dependendo do objeto do banco de dados, as seguintes permissões são concedidas ao usuário ou ao grupo de usuários: + Para tabelas, ALTER concede permissão para alterar uma tabela ou visão. Para obter mais informações, consulte [ALTER TABLE](r_ALTER_TABLE.md). + Para bancos de dados, ALTER concede permissão para alterar um banco de dados. Para obter mais informações, consulte [ALTER DATABASE](r_ALTER_DATABASE.md). + Para esquemas, ALTER concede permissão para alterar um esquema. Para obter mais informações, consulte [ALTER SCHEMA](r_ALTER_SCHEMA.md). + Para tabelas externas, ALTER concede permissão para alterar uma tabela em um AWS Glue Data Catalog habilitado para o Lake Formation. Essa permissão só é aplicada ao usar o Lake Formation. TRUNCATE Concede permissão para truncar uma tabela. Sem essa permissão, somente o proprietário de uma tabela ou um superusuário pode truncar uma tabela. Para obter mais informações sobre o comando TRUNCATE, consulte [TRUNCATE](r_TRUNCATE.md). ALL [ PRIVILEGES ] Concede todas as permissões disponíveis de uma vez ao usuário ou ao perfil especificado. A palavra-chave PRIVILEGES é opcional. GRANT ALL ON SCHEMA não concede permissões CREATE para esquemas externos. É possível conceder a permissão ALL para uma tabela em um AWS Glue Data Catalog habilitado para o Lake Formation. Nesse caso, permissões individuais (como SELECT, ALTER e assim por diante) são registradas no catálogo de dados. O Amazon Redshift não é compatível com as permissões RULE e TRIGGER. Para obter mais informações, acesse [Recursos incompatíveis do PostgreSQL](c_unsupported-postgresql-features.md). ASSUMEROLE Concede permissões para executar comandos COPY, UNLOAD, EXTERNAL FUNCTION e CREATE MODEL a usuários, perfis ou grupos com um perfil especificado. O usuário, perfil ou grupo assume esse perfil ao executar o comando especificado. Para começar a usar a permissão ASSUMEROLE, consulte [Observações de uso para conceder a permissão ASSUMEROLE](r_GRANT-usage-notes.md#r_GRANT-usage-notes-assumerole). ON [ TABLE ] *table\$1name* Concede as permissões especificadas em uma tabela ou visualização. A palavra-chave TABLE é opcional. Você pode listar várias tabelas e exibições em uma instrução. ON ALL TABLES IN SCHEMA *schema\$1name* Concede as permissões especificadas em todas as tabelas e exibições no esquema de referência. ( *column\$1name* [,...] ) ON TABLE *table\$1name* Concede as permissões especificadas a usuários, grupos ou PUBLIC nas colunas especificadas da tabela ou visualização do Amazon Redshift. ( *column\$1list* ) ON EXTERNAL TABLE *schema\$1name.table\$1name* Concede as permissões especificadas para um perfil do IAM nas colunas especificadas da tabela do Lake Formation no esquema mencionado. ON EXTERNAL TABLE *schema\$1name.table\$1name* Concede as permissões especificadas para um perfil do IAM nas tabelas especificadas do Lake Formation no esquema mencionado. ON EXTERNAL SCHEMA *schema\$1name* Concede as permissões especificadas para um perfil do IAM no esquema mencionado. ON *iam\$1role* Concede as permissões especificadas para um perfil do IAM. TO *username* Indica o usuário que está recebendo as permissões. TO IAM\$1ROLE *iam\$1role* Indica o perfil do IAM que está recebendo as permissões. WITH GRANT OPTION Indica que o usuário que recebe as permissões pode, por sua vez, conceder as mesmas permissões a outros. WITH GRANT OPTION não pode ser concedido a um grupo ou a PUBLIC. ROLE *role\$1name* Concede as permissões ao perfil. GROUP *nome\$1grupo* Concede as permissões a um grupo de usuários. Pode ser uma lista separada por vírgulas para especificar vários grupos de usuários. PUBLIC Concede as permissões especificadas a todos os usuários, incluindo os usuários criados posteriormente. PUBLIC representa um grupo que inclui sempre todos os usuários. As permissões de um usuário individual consistem na soma das permissões concedidas a PUBLIC, das permissões concedidas a todos os grupos aos quais o usuário pertence e de quaisquer permissões concedidas ao usuário individualmente. Conceder PUBLIC a um EXTERNAL TABLE do Lake Formation resulta em conceder a permissão para o grupo *todos* do Lake Formation. CONNECT [ON WORKGROUP] TO \$1 [USER] : \$1 ROLE : \$1 PUBLIC \$1 Concede a permissão para se conectar a um grupo de trabalho ou cluster a usuários ou grupos federados do Centro de Identidade do AWS IAM. O prefixo identifica o provedor de identidades. Quando concedida a PUBLIC, a permissão se aplica a todos os usuários federados do Centro de Identidade do AWS IAM, incluindo os usuários criados posteriormente. Essa permissão é aplicável somente quando as permissões federadas do Amazon Redshift estão habilitadas no grupo de trabalho ou cluster. CREATE Dependendo do objeto do banco de dados, as seguintes permissões são concedidas ao usuário ou ao grupo de usuários: + Para bancos de dados, CREATE permite que os usuários criem esquemas no banco de dados. + Para esquemas, CREATE permite que os usuários criem objetos em um esquema. Para renomear um objeto, o usuário deve ter a permissão CREATE e ser proprietário do objeto a ser renomeado. + Não há suporte para CREATE ON SCHEMA nos esquemas externos do Amazon Redshift Spectrum. Para conceder o uso de tabelas externas em um esquema externo, conceda USAGE ON SCHEMA a usuários que precisam de acesso. Somente o proprietário de um esquema externo ou um superusuário tem permissão para criar tabelas externas no esquema externo. Para transferir a propriedade de um esquema externo, use [ALTER SCHEMA](r_ALTER_SCHEMA.md) para alterar o proprietário. TEMPORARY \$1 TEMP Concede permissão para criar tabelas temporárias no banco de dados especificado. Para executar as consultas do Amazon Redshift Spectrum, o usuário do banco de dados precisa ter permissão para criar tabelas temporárias no banco de dados. Por padrão, os usuários recebem permissão para criar tabelas temporárias por associação automática ao grupo PUBLIC. Para remover a permissão para que qualquer usuário crie tabelas temporárias, revogue a permissão TEMP do grupo PUBLIC. Em seguida, conceda explicitamente a permissão para criar tabelas temporárias para usuários ou grupos de usuários específicos. ON DATABASE *nome\$1bd* Concede as permissões especificadas em um banco de dados. USAGE Concede a permissão USAGE em um esquema específico, que torna objetos naquele esquema acessíveis aos usuários. As ações específicas nesses objetos devem ser concedidas separadamente (por exemplo, permissões SELECT ou UPDATE em tabelas) para esquemas locais do Amazon Redshift. Por padrão, todos os usuários têm permissões CREATE e USAGE no esquema PUBLIC. Ao conceder USAGE a esquemas externos usando a sintaxe ON SCHEMA, você não precisa conceder ações separadamente nos objetos no esquema externo. As permissões de catálogo correspondentes controlam as permissões granulares nos objetos externos do esquema. ON SCHEMA *schema\$1name* Concede as permissões especificadas em um esquema. GRANT CREATE ON SCHEMA e a permissão CREATE em GRANT ALL ON SCHEMA não são compatíveis com os esquemas externos do Amazon Redshift Spectrum. Para conceder o uso de tabelas externas em um esquema externo, conceda USAGE ON SCHEMA a usuários que precisam de acesso. Somente o proprietário de um esquema externo ou um superusuário tem permissão para criar tabelas externas no esquema externo. Para transferir a propriedade de um esquema externo, use [ALTER SCHEMA](r_ALTER_SCHEMA.md) para alterar o proprietário. EXECUTE ON ALL FUNCTIONS IN SCHEMA *schema\$1name* Concede as permissões especificadas em todas as funções no esquema de referência. O Amazon Redshift não comporta instruções GRANT ou REVOKE para entradas pg\$1proc builtin definidas no namespace pg\$1catalog. EXECUTE ON PROCEDURE *procedure\$1name* Concede a permissão EXECUTE em um procedimento armazenado específico. Como os nomes de procedimento armazenado podem ser sobrecarregados, você deverá incluir a lista de argumentos para o procedimento. Para obter mais informações, consulte [Nomeação de procedimentos armazenados](stored-procedure-naming.md). EXECUTE ON ALL PROCEDURES IN SCHEMA *schema\$1name* Concede as permissões especificadas em todos os procedimentos armazenados no esquema de referência. USAGE ON LANGUAGE *nome\$1linguagem* Concede a permissão USAGE em um idioma. A partir de 1.º de novembro de 2025, o Amazon Redshift não permitirá mais a criação de UDFs do Python. As UDFs do Python existentes continuarão a funcionar normalmente até 30 de junho de 2026. A partir de 1.º de julho de 2026, o Amazon Redshift não permitirá mais a criação de UDFs do Python. Recomendamos enfaticamente que você migre as UDFs existentes do Python para as UDFs do Lambda antes de 1.º de novembro de 2025. Para ter mais informações sobre como criar e usar UDFs do Lambda, consulte [UDFs escalares do Lambda](udf-creating-a-lambda-sql-udf.md). Para ter informações sobre a conversão de UDFs do Python existentes em UDFs do Lambda, 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/). A permissão USAGE ON LANGUAGE é necessária para criar funções definidas pelo usuário (UDFs) executando o comando [CREATE FUNCTION](r_CREATE_FUNCTION.md). Para obter mais informações, consulte [Segurança e permissões de UDFs](udf-security-and-privileges.md). A permissão USAGE ON LANGUAGE é necessária para criar procedimentos armazenados executando o comando [CREATE PROCEDURE](r_CREATE_PROCEDURE.md). Para obter mais informações, consulte [Segurança e privilégios para procedimentos armazenados](stored-procedure-security-and-privileges.md). Para UDFs Python, use `plpythonu`. Para UDFs SQL, use `sql`. Para procedimentos armazenados, use `plpgsql`. ON COPY JOB *job\$1name* Concede as permissões especificadas em um esquema. FOR \$1 ALL \$1 COPY \$1 UNLOAD \$1 EXTERNAL FUNCTION \$1 CREATE MODEL \$1 [, ...] Especifica o comando SQL para o qual a permissão é concedida. Você pode especificar ALL para conceder a permissão nas instruções COPY, UNLOAD, EXTERN FUNCTION e CREATE MODEL. Esta cláusula aplica-se apenas à concessão da permissão ASSUMEROLE. ALTER Concede a permissão ALTER aos usuários para adicionar ou remover objetos de uma unidade de compartilhamento de dados ou para definir a propriedade PUBLICACCESSIBLE. Para obter mais informações, consulte [ALTER DATASHARE](r_ALTER_DATASHARE.md). SHARE Concede permissões a usuários e grupos de usuários para adicionar consumidores de dados a uma unidade de compartilhamento de dados. Essa permissão é necessária para permitir que o consumidor específico (conta ou namespace) acesse a unidade de compartilhamento de dados de seus clusters. O consumidor pode ser o mesmo ou de uma conta da AWS diferente, com o mesmo ou um namespace de cluster diferente, conforme especificado por um identificador globalmente exclusivo (GUID). ON DATASHARE *datashare\$1name* Concede as permissões especificadas na unidade de compartilhamento de dados de referência. Para obter informações sobre granularidade de controle de acesso de consumidor, consulte [Compartilhamento de dados em diferentes níveis no Amazon Redshift](datashare-overview.md#granularity). USAGE Quando USO é concedido a uma conta de consumidor ou namespace dentro da mesma conta, a conta de consumidor específica ou namespace dentro da conta pode acessar o datashare e os objetos do datashare de forma somente leitura. TO NAMESPACE 'clusternamespace GUID' Indica um namespace na mesma conta em que os consumidores podem receber as permissões especificadas para a unidade de compartilhamento de dados. Os namespaces usam um GUID alfanumérico de 128 bits. TO ACCOUNT 'accountnumber' [ VIA DATA CATALOG ] Indica o número de outra conta cujos consumidores podem receber as permissões especificadas para a unidade de compartilhamento de dados. Especificar “VIA DATA CATALOG” indica que você está concedendo o uso da unidade de compartilhamento de dados a uma conta do Lake Formation. Omitir esse parâmetro significa que você está concedendo uso a uma conta que possui o cluster. ON DATABASE *shared\$1database\$1name> [, ...]* Concede as permissões de uso especificadas no banco de dados especificado que é criado na unidade de compartilhamento de dados especificada. ON SCHEMA* shared\$1schema* Concede as permissões especificadas no esquema especificado que é criado na unidade de compartilhamento de dados especificada. FOR \$1 SCHEMAS \$1 TABLES \$1 FUNCTIONS \$1 PROCEDURES \$1 LANGUAGES \$1 COPY JOBS\$1 IN Especifica os objetos de banco de dados aos quais conceder permissão. Os parâmetros após IN definem o escopo da permissão concedida. CREATE MODEL Concede a permissão CREATE MODEL a usuários ou grupos de usuários específicos. ON MODEL *model\$1name* Concede a permissão EXECUTE em um modelo específico. ACCESS CATALOG Concede a permissão para exibir metadados relevantes de objetos aos quais a função tem acesso. \$1 role \$1 [, ...] A função a ser concedida a outra função, um usuário ou PUBLIC. PUBLIC representa um grupo que inclui sempre todos os usuários. As permissões de um usuário individual consistem na soma das permissões concedidas a PUBLIC, das permissões concedidas a todos os grupos aos quais o usuário pertence e de quaisquer permissões concedidas ao usuário individualmente. TO \$1 \$1 *user\$1name* [ WITH ADMIN OPTION ] \$1 \$1 role \$1[, ...] Concede a função especificada a um usuário especificado com a WITH ADMIN OPTION, outra função ou PUBLIC. A cláusula WITH ADMIN OPTION fornece as opções de administração para todas as funções concedidas a todos os beneficiários. EXPLAIN \$1 RLS \$1 MASKING \$1 TO ROLE *rolename* Concede permissão para explicar os filtros de política de segurança de uma consulta no plano EXPLAIN a um perfil. RLS concede permissão para explicar filtros de política de segurança por linha. MASKING concede permissão para explicar os filtros da política de mascaramento dinâmico de dados. IGNORE RLS TO ROLE *rolename* Concede permissão para ignorar políticas de segurança por linha para uma consulta a um perfil. TO \$1 RLS \$1 MASKING \$1 POLICY *policy\$1name* Indica a política de segurança que está recebendo as permissões. TO RLS POLICY indica uma política de segurança por linha. TO MASKING POLICY indica uma política de mascaramento dinâmico de dados. ## Observações de uso Observações de uso Para saber mais sobre as observações de uso de GRANT, consulte [Observações de uso](r_GRANT-usage-notes.md). ## Exemplos Exemplos Para conferir exemplos de como usar GRANT, consulte [Exemplos](r_GRANT-examples.md). # Observações de uso Observações de uso Para conceder privilégios a um objeto, você deve atender a um dos seguintes critérios: + Ser o proprietário do objeto. + Ser um superusuário. + Ter um privilégio concedido para o objeto e privilégio. Por exemplo, o comando a seguir fornece ao usuário HR a capacidade de executar comandos SELECT na tabela de funcionários e conceder e revogar o mesmo privilégio para outros usuários. ``` grant select on table employees to HR with grant option; ``` HR não pode conceder privilégios a nenhuma operação além de SELECT ou a qualquer outra tabela além da de funcionários. Por exemplo, o comando a seguir fornece ao usuário HR a capacidade de executar comandos ALTER na tabela de funcionários e conceder e revogar o mesmo privilégio para outros usuários. ``` grant ALTER on table employees to HR with grant option; ``` HR não pode conceder privilégios a nenhuma operação além de ALTER ou a qualquer outra tabela além da de funcionários. Ter os privilégios concedidos em uma exibição não significa ter privilégios nas tabelas subjacentes. Da mesma forma, ter os privilégios concedidos em um esquema não significa ter privilégios nas tabelas do esquema. Em vez disso, conceda acesso às tabelas subjacentes explicitamente. Para conceder privilégios para uma tabela do AWS Lake Formation, a função do IAM associada ao esquema externo da tabela deve ter permissão para conceder privilégios para a tabela externa. O exemplo a seguir cria um esquema externo com uma função do IAM associada `myGrantor`. A função do IAM `myGrantor` tem permissão para conceder permissões a outros. O comando GRANT usa a permissão da função do IAM `myGrantor` que está associada ao esquema externo para conceder permissão para a função do IAM `myGrantee`. ``` create external schema mySchema from data catalog database 'spectrum_db' iam_role 'arn:aws:iam::123456789012:role/myGrantor' create external database if not exists; ``` ``` grant select on external table mySchema.mytable to iam_role 'arn:aws:iam::123456789012:role/myGrantee'; ``` Se você conceder todos os privilégios a uma função do IAM, privilégios individuais serão concedidos no catálogo de dados habilitado para o Lake Formation relacionado. Por exemplo, o comando GRANT ALL a seguir resulta na exibição dos privilégios individuais concedidos (SELECT, ALTER, DROP, DELETE e INSERT) no console do Lake Formation. ``` grant all on external table mySchema.mytable to iam_role 'arn:aws:iam::123456789012:role/myGrantee'; ``` Superusuários podem acessar todos os objetos, independentemente de comandos GRANT e REVOKE que definem privilégios de objeto. ## Observações de uso para controle de acesso no nível da coluna Observações de uso para controle de acesso no nível da coluna As observações de uso a seguir são aplicáveis a privilégios de nível de coluna em tabelas e visualizações do Amazon Redshift. Essas notas descrevem tabelas; as mesmas notas são aplicáveis a visualizações, a menos que observemos uma exceção explicitamente. + Para uma tabela do Amazon Redshift, é possível conceder somente os privilégios SELECT e UPDATE em nível da coluna. Para uma exibição do Amazon Redshift, somente é possível conceder o privilégio SELECT em nível de coluna. + A palavra-chave ALL é um sinônimo de privilégios SELECT e UPDATE combinados quando usada no contexto de um GRANT em nível de coluna em uma tabela. + Se você não tiver o privilégio SELECT em todas as colunas de uma tabela, a execução de uma operação SELECT \$1 retornará somente as colunas às quais você tem acesso. Ao usar uma visualização, uma operação SELECT \$1 tenta acessar todas as colunas na visualização. Se você não tiver permissão para acessar todas as colunas, essas consultas apresentarão falha com um erro de permissão negada. + SELECT \$1 não se expande apenas a colunas acessíveis nos seguintes casos: + Não é possível criar uma visão normal com apenas colunas acessíveis usando SELECT \$1. + Não é possível criar uma visão materializada com apenas colunas acessíveis usando SELECT \$1. + Se tiver o privilégio SELECT ou UPDATE em uma tabela ou exibição, e adicionar uma coluna, você ainda terá os mesmos privilégios na tabela ou exibição e, portanto, todas as colunas dela. + Somente o proprietário de uma tabela ou um superusuário pode conceder privilégios em nível de coluna. + A cláusula WITH GRANT OPTION não é compatível com privilégios de nível de coluna. + Não é possível manter o mesmo privilégio em nível de tabela e em nível de coluna. Por exemplo, o usuário `data_scientist` não pode ter o privilégio SELECT na tabela `employee` e o privilégio SELECT na coluna `employee.department`. Ao conceder o mesmo privilégio a uma tabela e a uma coluna dentro da tabela, considere os seguintes resultados: + Se um usuário tiver um privilégio em nível de tabela em uma tabela, conceder o mesmo privilégio em nível de coluna não terá efeito. + Se um usuário tiver um privilégio em nível de tabela em uma tabela, a revogação do mesmo privilégio para uma ou mais colunas da tabela retornará um erro. Em vez disso, revogue o privilégio em nível de tabela. + Se um usuário tiver um privilégio em nível de coluna, conceder o mesmo privilégio em nível de tabela retornará um erro. + Se um usuário tiver um privilégio em nível de coluna, a revogação do mesmo privilégio no nível da tabela revoga os privilégios de coluna e tabela para todas as colunas da tabela. + Não é possível conceder privilégios em nível de coluna em exibições de vinculação tardia. + Você deve ter o privilégio SELECT no nível da tabela nas tabelas base para criar uma visão materializada. Mesmo que você tenha privilégios no nível da coluna para colunas específicas, não poderá criar uma visão materializada somente para essas colunas. No entanto, você poderá conceder o privilégio SELECT às colunas de uma visão materializada, semelhante às visualizações regulares. + Para pesquisar concessões de privilégios de nível de coluna, use a exibição [PG\$1ATTRIBUTE\$1INFO](r_PG_ATTRIBUTE_INFO.md). ## Observações de uso para conceder a permissão ASSUMEROLE Observações de uso para conceder a permissão ASSUMEROLE As observações de uso a seguir são aplicáveis à concessão da permissão ASSUMEROLE no Amazon Redshift. Use a permissão ASSUMEROLE para controlar as permissões de acesso ao perfil do IAM para usuários, perfis e grupos de banco de dados em comandos como COPY, UNLOAD, EXTERNAL FUNCTION ou CREATE MODEL. Depois de conceder a permissão ASSUMEROLE a um usuário, perfil ou grupo para um perfil do IAM, o usuário, perfil ou grupo poderá assumir esse perfil ao executar o comando. A permissão ASSUMEROLE permite que você conceda acesso aos comandos apropriados conforme necessário. Somente um superusuário de banco de dados pode conceder ou revogar a permissão ASSUMEROLE para usuários, perfis e grupos. Um superusuário sempre mantém a permissão ASSUMEROLE. Para habilitar o uso da permissão ASSUMEROLE para usuários, perfis e grupos, um superusuário executa estas duas ações: + Execute a seguinte instrução uma vez no cluster: ``` revoke assumerole on all from public for all; ``` + Conceda a permissão ASSUMEROLE aos usuários, perfis e grupos para os comandos apropriados. Você pode especificar o encadeamento de perfis na cláusula ON ao conceder a permissão ASSUMEROLE. É usado vírgula para separar funções em uma cadeia de funções, por exemplo, `Role1,Role2,Role3`. Se o encadeamento de perfis tiver sido especificado ao conceder a permissão ASSUMEROLE, você deverá especificar a cadeia de perfis ao executar operações concedidas pela permissão ASSUMEROLE. Não é possível especificar perfis individuais dentro da cadeia de perfis ao executar operações concedidas pela permissão ASSUMEROLE. Por exemplo, se um usuário, perfil ou grupo receber a cadeia de perfis `Role1,Role2,Role3`, não é possível especificar apenas `Role1` para executar operações. Se um usuário tentar executar uma operação COPY, UNLOAD, EXTERNAL FUNCTION ou CREATE MODEL e não tiver recebido a permissão ASSUMEROLE, uma mensagem semelhante à seguinte será exibida. ``` ERROR: User awsuser does not have ASSUMEROLE permission on IAM role "arn:aws:iam::123456789012:role/RoleA" for COPY ``` Para listar usuários que receberam acesso a perfis do IAM e comandos por meio da permissão ASSUMEROLE, consulte [HAS\$1ASSUMEROLE\$1PRIVILEGE](r_HAS_ASSUMEROLE_PRIVILEGE.md). Para listar os perfis do IAM e as permissões comandos que foram concedidos a um usuário especificado, consulte [PG\$1GET\$1IAM\$1ROLE\$1BY\$1USER](PG_GET_IAM_ROLE_BY_USER.md). Para listar usuários, perfis e grupos que receberam acesso a um perfil do IAM especificado por você, consulte [PG\$1GET\$1GRANTEE\$1BY\$1IAM\$1ROLE](PG_GET_GRANTEE_BY_IAMROLE.md). ## Observações de uso para conceder permissões de machine learning Observações de uso para conceder permissões de machine learning Você não pode conceder ou revogar diretamente as permissões relacionadas a uma função de ML. Uma função de ML pertence a um modelo de ML, e as permissões são controladas por meio do modelo. Em vez disso, você pode conceder permissões relacionadas ao modelo de ML. O exemplo a seguir demonstra como conceder permissões a todos os usuários para executar a função de ML associada ao modelo `customer_churn`. ``` GRANT EXECUTE ON MODEL customer_churn TO PUBLIC; ``` Você também pode conceder todas as permissões a um usuário para o modelo de ML `customer_churn`. ``` GRANT ALL on MODEL customer_churn TO ml_user; ``` A concessão da permissão `EXECUTE` relacionada a uma função de ML falhará se houver uma função de ML no esquema, mesmo que essa função de ML já tenha a permissão `EXECUTE` por meio de `GRANT EXECUTE ON MODEL`. Recomendamos usar um esquema separado ao usar o comando `CREATE MODEL` para manter as funções de ML em um esquema separado. O exemplo a seguir demonstra como fazer isso. ``` CREATE MODEL ml_schema.customer_churn FROM customer_data TARGET churn FUNCTION ml_schema.customer_churn_prediction IAM_ROLE default SETTINGS ( S3_BUCKET 'amzn-s3-demo-bucket' ); ``` # Exemplos Exemplos O exemplo a seguir concede o privilégio SELECT na tabela SALES ao usuário `fred`. ``` grant select on table sales to fred; ``` O exemplo a seguir concede o privilégio SELECT em todas as tabelas no esquema QA\$1TICKIT ao usuário `fred`. ``` grant select on all tables in schema qa_tickit to fred; ``` O exemplo a seguir concede todos os privilégios de esquema no esquema QA\$1TICKIT ao grupo de usuários QA\$1USERS. Os privilégios de esquema são CREATE e USAGE. USAGE permite que os usuários acessem os objetos no esquema, mas não concede privilégios como INSERT ou SELECT em tais objetos. Conceder privilégios em cada objeto separadamente. ``` create group qa_users; grant all on schema qa_tickit to group qa_users; ``` O exemplo a seguir concede todos os privilégios na tabela SALES no esquema QA\$1TICKIT a todos os usuários do grupo QA\$1USERS. ``` grant all on table qa_tickit.sales to group qa_users; ``` O exemplo a seguir concede todos os privilégios na tabela SALES no esquema QA\$1TICKIT a todos os usuários dos grupos QA\$1USERS e RO\$1USERS. ``` grant all on table qa_tickit.sales to group qa_users, group ro_users; ``` O exemplo a seguir concede o privilégio DROP na tabela SALES no esquema QA\$1TICKIT a todos os usuários no grupo QA\$1USERS. ``` grant drop on table qa_tickit.sales to group qa_users;> ``` A sequência de comandos a seguir mostra como o acesso a um esquema não concede privilégios a uma tabela no esquema. ``` create user schema_user in group qa_users password 'Abcd1234'; create schema qa_tickit; create table qa_tickit.test (col1 int); grant all on schema qa_tickit to schema_user; set session authorization schema_user; select current_user; current_user -------------- schema_user (1 row) select count(*) from qa_tickit.test; ERROR: permission denied for relation test [SQL State=42501] set session authorization dw_user; grant select on table qa_tickit.test to schema_user; set session authorization schema_user; select count(*) from qa_tickit.test; count ------- 0 (1 row) ``` A sequência de comandos a seguir mostra como o acesso a uma exibição não implica acesso às suas tabelas subjacentes. O usuário chamado VIEW\$1USER não pode selecionar da tabela DATE, embora todos os privilégios de VIEW\$1DATE tenham sido concedidos a ele. ``` create user view_user password 'Abcd1234'; create view view_date as select * from date; grant all on view_date to view_user; set session authorization view_user; select current_user; current_user -------------- view_user (1 row) select count(*) from view_date; count ------- 365 (1 row) select count(*) from date; ERROR: permission denied for relation date ``` O exemplo a seguir concede o privilégio SELECT nas colunas `cust_name` e `cust_phone` da tabela `cust_profile` ao usuário `user1`. ``` grant select(cust_name, cust_phone) on cust_profile to user1; ``` O exemplo a seguir concede o privilégio SELECT nas colunas `cust_name` e `cust_phone`, e o privilégio UPDATE na coluna `cust_contact_preference` da tabela `cust_profile` ao grupo `sales_group`. ``` grant select(cust_name, cust_phone), update(cust_contact_preference) on cust_profile to group sales_group; ``` O exemplo a seguir mostra o uso da palavra-chave ALL para conceder privilégios SELECT e UPDATE em três colunas da tabela `cust_profile` ao grupo `sales_admin`. ``` grant ALL(cust_name, cust_phone,cust_contact_preference) on cust_profile to group sales_admin; ``` O exemplo a seguir concede o privilégio SELECT na coluna `cust_name` da exibição `cust_profile_vw` ao usuário `user2`. ``` grant select(cust_name) on cust_profile_vw to user2; ``` ## Exemplos da concessão de acesso a unidades de compartilhamento de dados Exemplos de concessão do privilégio USAGE para datashares Os exemplos a seguir mostram permissões de uso de datashare GRANT em um banco de dados específico ou esquema criado a partir de um datashare. No exemplo a seguir, um administrador no lado do produtor concede a permissão USAGE na unidade de compartilhamento de dados `salesshare` ao namespace especificado. ``` GRANT USAGE ON DATASHARE salesshare TO NAMESPACE '13b8833d-17c6-4f16-8fe4-1a018f5ed00d'; ``` No exemplo a seguir, um administrador no lado do consumidor concede a permissão USAGE no `sales_db` a `Bob`. ``` GRANT USAGE ON DATABASE sales_db TO Bob; ``` No exemplo a seguir, um administrador no lado do consumidor concede a permissão GRANT USAGE no esquema `sales_schema` à função `Analyst_role`. `sales_schema` é um esquema externo que aponta para sales\$1db. ``` GRANT USAGE ON SCHEMA sales_schema TO ROLE Analyst_role; ``` Neste ponto, `Bob` e `Analyst_role` podem ter acesso a todos os objetos do banco de dados em `sales_schema` e `sales_db`. O exemplo a seguir mostra a concessão de permissão adicional no nível do objeto para objetos em um banco de dados compartilhado. Essas permissões extras só serão necessárias se o comando CREATE DATABASE usado para criar o banco de dados compartilhado usar a cláusula WITH PERMISSIONS. Se o comando CREATE DATABASE não usou WITH PERMISSIONS, a concessão de USAGE no banco de dados compartilhado concede acesso total a todos os objetos nesse banco de dados. ``` GRANT SELECT ON sales_db.sales_schema.tickit_sales_redshift to Bob; ``` ## Exemplos de concessão de permissões em escopo definido Exemplos de concessão de permissões em escopo definido O exemplo a seguir concede uso para todos os esquemas atuais e futuros no banco de dados `Sales_db` à função `Sales`. ``` GRANT USAGE FOR SCHEMAS IN DATABASE Sales_db TO ROLE Sales; ``` O exemplo a seguir concede a permissão SELECT para todas as tabelas atuais e futuras no banco de dados `Sales_db` ao usuário `alice` e também dá a `alice` a permissão para conceder permissões em escopo em tabelas em `Sales_db` a outros usuários. ``` GRANT SELECT FOR TABLES IN DATABASE Sales_db TO alice WITH GRANT OPTION; ``` O exemplo a seguir concede a permissão EXECUTE para funções no esquema `Sales_schema` ao usuário `bob`. ``` GRANT EXECUTE FOR FUNCTIONS IN SCHEMA Sales_schema TO bob; ``` O exemplo a seguir concede todas as permissões para todas as tabelas no esquema do `ShareSchema` do banco de dados `ShareDb` à função `Sales`. Ao especificar o esquema, você pode especificar o banco de dados do esquema usando o formato de duas partes `database.schema`. ``` GRANT ALL FOR TABLES IN SCHEMA ShareDb.ShareSchema TO ROLE Sales; ``` O exemplo a seguir é o mesmo do anterior. Você pode especificar o banco de dados usando a palavra-chave `DATABASE`, em vez de usar um formato de duas partes. ``` GRANT ALL FOR TABLES IN SCHEMA ShareSchema DATABASE ShareDb TO ROLE Sales; ``` ## Exemplos de concessão do privilégio ASSUMEROLE Exemplos de concessão do privilégio ASSUMEROLE Veja a seguir exemplos de concessão do privilégio ASSUMEROLE. O exemplo a seguir mostra a instrução REVOKE que um superusuário executa uma vez no cluster para habilitar o uso do privilégio ASSUMEROLE para usuários e grupos. Em seguida, o superusuário concede o privilégio ASSUMEROLE aos usuários e grupos para os comandos apropriados. Para obter informações sobre como habilitar o uso do privilégio ASSUMEROLE para usuários e grupos, consulte [Observações de uso para conceder a permissão ASSUMEROLE](r_GRANT-usage-notes.md#r_GRANT-usage-notes-assumerole). ``` revoke assumerole on all from public for all; ``` O exemplo a seguir concede o privilégio ASSUMEROLE ao usuário `reg_user1` para a função do IAM `Redshift-S3-Read` para executar operações COPY. ``` grant assumerole on 'arn:aws:iam::123456789012:role/Redshift-S3-Read' to reg_user1 for copy; ``` O exemplo a seguir concede o privilégio ASSUMEROLE ao usuário `reg_user1` para a cadeia de função do IAM `RoleA` e `RoleB` para executar operações COPY. ``` grant assumerole on 'arn:aws:iam::123456789012:role/RoleA,arn:aws:iam::210987654321:role/RoleB' to reg_user1 for unload; ``` Veja a seguir um exemplo do comando UNLOAD usando a cadeia de função do IAM `RoleA` e `RoleB`. ``` unload ('select * from venue limit 10') to 's3://companyb/redshift/venue_pipe_' iam_role 'arn:aws:iam::123456789012:role/RoleA,arn:aws:iam::210987654321:role/RoleB'; ``` O exemplo a seguir concede o privilégio ASSUMEROLE ao usuário `reg_user1` para a função do IAM `Redshift-Exfunc` para criar funções externas. ``` grant assumerole on 'arn:aws:iam::123456789012:role/Redshift-Exfunc' to reg_user1 for external function; ``` O exemplo a seguir concede o privilégio ASSUMEROLE ao usuário `reg_user1` para a função do IAM `Redshift-model` para criar modelos de Machine Learning. ``` grant assumerole on 'arn:aws:iam::123456789012:role/Redshift-ML' to reg_user1 for create model; ``` ## Exemplos de concessão do privilégio ROLE Exemplos de concessão do privilégio ROLE O exemplo a seguir concede a função sample\$1role1 ao usuário user1. ``` CREATE ROLE sample_role1; GRANT ROLE sample_role1 TO user1; ``` O exemplo a seguir concede sample\$1role1 ao user1 com a WITH ADMIN OPTION, define a sessão atual para user1 e user1 concede sample\$1role1 ao user2. ``` GRANT ROLE sample_role1 TO user1 WITH ADMIN OPTION; SET SESSION AUTHORIZATION user1; GRANT ROLE sample_role1 TO user2; ``` O exemplo a seguir concede a função sample\$1role1 a sample\$1role2. ``` GRANT ROLE sample_role1 TO ROLE sample_role2; ``` O exemplo a seguir concede a função sample\$1role2 a sample\$1role3 e sample\$1role4. Em seguida, ele tenta conceder sample\$1role3 a sample\$1role1. ``` GRANT ROLE sample_role2 TO ROLE sample_role3; GRANT ROLE sample_role3 TO ROLE sample_role2; ERROR: cannot grant this role, a circular dependency was detected between these roles ``` O exemplo a seguir concede privilégios de sistema CREATE USER a sample\$1role1. ``` GRANT CREATE USER TO ROLE sample_role1; ``` O exemplo a seguir concede a função definida pelo sistema `sys:dba` a user1. ``` GRANT ROLE sys:dba TO user1; ``` O exemplo a seguir tenta conceder sample\$1role3 em uma dependência circular a sample\$1role2. ``` CREATE ROLE sample_role3; GRANT ROLE sample_role2 TO ROLE sample_role3; GRANT ROLE sample_role3 TO ROLE sample_role2; -- fail ERROR: cannot grant this role, a circular dependency was detected between these roles ```