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
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 * retornará somente as colunas às quais você tem acesso. Ao usar uma visualização, uma operação SELECT * 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 * 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 *.
Não é possível criar uma visão materializada com apenas colunas acessíveis usando SELECT *.
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_scientistnão pode ter o privilégio SELECT na tabelaemployeee o privilégio SELECT na colunaemployee.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 visualização materializada. Mesmo que você tenha privilégios no nível da coluna para colunas específicas, não poderá criar uma visualização materializada somente para essas colunas. No entanto, você poderá conceder o privilégio SELECT às colunas de uma visualização materializada, semelhante às visualizações regulares.
Para pesquisar concessões de privilégios de nível de coluna, use a exibição PG_ATTRIBUTE_INFO.
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_ASSUMEROLE_PRIVILEGE. Para listar os perfis do IAM e as permissões comandos que foram concedidos a um usuário especificado, consulte PG_GET_IAM_ROLE_BY_USER. Para listar usuários, perfis e grupos que receberam acesso a um perfil do IAM especificado por você, consulte PG_GET_GRANTEE_BY_IAM_ROLE.
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' );
