As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Visão geral das permissões do Lake Formation Há dois tipos principais de permissões no AWS Lake Formation: + Acesso aos metadados – Permissões nos recursos do catálogo de dados (*Permissões do catálogo de dados*). Com essas permissões, as entidades principais podem criar, ler, atualizar e excluir bancos de dados e tabelas de metadados no catálogo de dados. + Acesso aos dados subjacentes — Permissões em locais no Amazon Simple Storage Service (Amazon S3) (permissões de *acesso a dados e permissões* de *localização de dados*). + As permissões do data lake possibilitam que as entidades principais leiam e gravem dados em locais *subjacentes* do Amazon S3 – dados apontados pelos recursos do catálogo de dados. + Com as permissões de localização de dados, as entidades principais podem criar e alterar bancos de dados e tabelas de metadados que apontam para os locais específicos do Amazon S3. Para ambas as áreas, o Lake Formation usa uma combinação de permissões e permissões do Lake Formation AWS Identity and Access Management (IAM). O modelo de permissões do IAM consiste em políticas do IAM. O modelo de permissões do Lake Formation é implementado como GRANT/REVOKE comandos no estilo DBMS, como. `Grant SELECT on tableName to userName` Quando uma entidade principal faz uma solicitação para acessar os recursos do catálogo de dados ou os dados subjacentes, para que a solicitação seja bem-sucedida, ela deve passar pelas verificações de permissão do IAM e do Lake Formation. ![\[A solicitação de um solicitante deve passar por duas “portas” para acessar os recursos: permissões do Lake Formation e permissões do IAM.\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/images/permissions_doors.png) As permissões do Lake Formation controlam o acesso aos recursos do catálogo de dados, aos locais do Amazon S3 e aos dados subjacentes nesses locais. As permissões do IAM controlam o acesso ao Lake Formation AWS Glue APIs e aos recursos. Portanto, embora você possa ter a permissão do Lake Formation para criar uma tabela de metadados no catálogo de dados (`CREATE_TABLE`), sua operação falhará se você não tiver a permissão do IAM na API `glue:CreateTable`.​ (Por que uma permissão do `glue:`? Porque o Lake Formation usa o catálogo de dados do AWS Glue.) **nota** As permissões do Lake Formation se aplicam somente na região em que foram concedidas. AWS Lake Formation exige que cada diretor (usuário ou função) seja autorizado a realizar ações nos recursos gerenciados pelo Lake Formation. Uma entidade principal recebe as autorizações necessárias do administrador do data lake ou de outra entidade principal com as permissões para conceder as permissões do Lake Formation. Ao conceder uma permissão de Lake Formation a uma entidade principal, você pode, opcionalmente, conceder a capacidade de passar essa permissão para outra entidade principal. Você pode usar a API do Lake Formation, a AWS Command Line Interface (AWS CLI) ou as páginas **Permissões de dados** e **Localizações de dados** do console do Lake Formation para conceder e revogar as permissões do Lake Formation. # Métodos para controle de acesso de alta granularidade Com um data lake, o objetivo é ter um controle de acesso de alta granularidade aos dados. No Lake Formation, isso significa controle de acesso de alta granularidade aos recursos do catálogo de dados e aos locais do Amazon S3. Você pode obter um controle de acesso de alta granularidade com um dos seguintes métodos. | Método | Permissões do Lake Formation | Permissões do IAM | Comentários | | --- | --- | --- | --- | | Método 1 | Abra o | Alta granularidade | **Esse é o método padrão** para compatibilidade com versões anteriores com o AWS Glue. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/access-control-fine-grained.html) No console do Lake Formation, esse método aparece como **Use apenas controle de acesso do IAM**. | | Método 2 | Alta granularidade | Baixa granularidade | **Este é o método recomendado.** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/access-control-fine-grained.html) | **Importante** Esteja ciente do seguinte: Por padrão, o Lake Formation tem as configurações de **Controle de acesso apenas para uso do IAM** habilitadas para compatibilidade com o comportamento existente do catálogo de dados do AWS Glue. Recomendamos que você desative essas configurações após a transição para o uso das permissões do Lake Formation. Para obter mais informações, consulte [Alterando as configurações padrão do seu data lake](change-settings.md). Os administradores do Data Lake e os criadores de bancos de dados têm permissões implícitas do Lake Formation que você precisa entender. Para obter mais informações, consulte [Permissões implícitas do Lake Formation](implicit-permissions.md). # Controle de acesso a metadados Para controle de acesso aos recursos do catálogo de dados, a discussão a seguir pressupõe controle de acesso de alta granularidade com permissões do Lake Formation e controle de acesso de baixa granularidade com políticas do IAM. Há dois métodos distintos para conceder permissões do Lake Formation nos recursos do catálogo de dados: + **Controle de acesso a recursos nomeados** – Com esse método, você concede permissões em bancos de dados ou tabelas específicos especificando nomes de bancos de dados ou tabelas. As concessões têm o seguinte formato: Conceda *Permissões* a *entidades principais* sobre *recursos* [com opção de concessão]. Com a opção de concessão, você pode permitir que o beneficiário conceda as permissões a outras entidades principais. + **Controle de acesso baseado em tags** – Com esse método, você atribui uma ou mais tags do LF aos bancos de dados, tabelas e colunas do catálogo de dados e concede permissões em uma ou mais tags do LF às entidades principais. Cada tag do LF é um par de chave-valor, como `department=sales`. Uma entidade principal que tenha tags do LF que correspondam às tags do LF em um recurso do catálogo de dados pode acessar esse recurso. Esse método é recomendado para data lakes com um grande número de bancos de dados e tabelas. Isso é explicado em detalhes em [Controle de acesso baseado em tags do Lake Formation](tag-based-access-control.md). As permissões que uma entidade principal tem sobre um recurso são a união das permissões concedidas pelos dois métodos. A tabela a seguir resume as permissões disponíveis do Lake Formation nos recursos do catálogo de dados. Os títulos das colunas indicam o recurso no qual a permissão é concedida. | Catálogo | Banco de dados | Tabela | | --- | --- | --- | | CREATE\$1DATABASE | CREATE\$1TABLE | ALTER | | | ALTER | DROP | | | DROP | DESCRIBE | | | DESCRIBE | SELECT\$1 | | | | INSERT\$1 | | | | DELETE\$1 | Por exemplo, a permissão `CREATE_TABLE` é concedida em um banco de dados. Isso significa que a entidade principal tem permissão para criar tabelas nesse banco de dados. As permissões com um asterisco (\$1) são concedidas nos recursos do catálogo de dados, mas se aplicam aos dados subjacentes. Por exemplo, a permissão `DROP` em uma tabela de metadados permite que você remova a tabela do catálogo de dados. No entanto, a permissão `DELETE` concedida na mesma tabela permite que você exclua os dados subjacentes da tabela no Amazon S3, usando, por exemplo, uma instrução `DELETE` do SQL. Com essas permissões, você também pode visualizar a tabela no console do Lake Formation e recuperar informações sobre a tabela com a API do AWS Glue. Portanto, `SELECT`, `INSERT` e `DELETE` são permissões do catálogo de dados e permissões de acesso aos dados. Ao conceder `SELECT` em uma tabela, você pode adicionar um filtro que inclua ou exclua uma ou mais colunas. Isso permite um controle de acesso de alta granularidade nas colunas da tabela de metadados, limitando as colunas que os usuários de serviços integrados podem ver ao executar consultas. Esse recurso não está disponível usando apenas as políticas do IAM. Também há uma permissão especial chamada `Super`. A permissão `Super` permite que uma entidade principal execute todas as operações suportadas do Lake Formation no banco de dados ou na tabela em que ela foi concedida. Essa permissão pode coexistir com as outras permissões do Lake Formation. Por exemplo, você pode conceder `Super`, `SELECT` e `INSERT` em uma tabela de metadados. A entidade principal pode realizar todas as ações suportadas na tabela e, quando você revoga `Super`, as permissões `SELECT` e `INSERT` permanecem. Para obter detalhes sobre cada permissão, consulte [Referência de permissões do Lake Formation](lf-permissions-reference.md). **Importante** Para poder ver uma tabela do catálogo de dados criada por outro usuário, você deve ter pelo menos uma permissão do Lake Formation na tabela. Se você tiver pelo menos uma permissão na tabela, também poderá ver o banco de dados que contém a tabela. Você pode conceder ou revogar as permissões do catálogo de dados usando o console do Lake Formation, a API ou o AWS Command Line Interface (AWS CLI). Veja a seguir um exemplo de um AWS CLI comando que concede ao usuário `datalake_user1` permissão para criar tabelas no `retail` banco de dados. ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "CREATE_TABLE" --resource '{ "Database": {"Name":"retail"}}' ``` Veja a seguir um exemplo de uma política do IAM de controle de acesso de baixa granularidade que complementa o controle de acesso de alta granularidade com as permissões do Lake Formation. Ele permite todas as operações em qualquer banco de dados ou tabela de metadados. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:*Database*", "glue:*Table*", "glue:*Partition*" ], "Resource": "*" } ] } ``` ------ O próximo exemplo também é de baixa granularidade, mas um pouco mais restritivo. Ele permite operações somente para leitura em todos os bancos de dados e tabelas de metadados no catálogo de dados na conta e região designadas. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:GetTables", "glue:SearchTables", "glue:GetTable", "glue:GetDatabase", "glue:GetDatabases" ], "Resource": "arn:aws:glue:us-east-1:111122223333:*" } ] } ``` ------ Compare essas políticas com a política a seguir, que implementa o controle de acesso de alta granularidade baseado em IAM. Ele concede permissões somente em um subconjunto de tabelas no banco de dados de metadados de gerenciamento de relacionamento com o cliente (CRM) na conta e região designadas. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:GetTables", "glue:SearchTables", "glue:GetTable", "glue:GetDatabase", "glue:GetDatabases" ], "Resource": [ "arn:aws:glue:us-east-1:111122223333:catalog", "arn:aws:glue:us-east-1:111122223333:database/CRM", "arn:aws:glue:us-east-1:111122223333:table/CRM/P*" ] } ] } ``` ------ Para obter mais exemplos de políticas de controle de acesso de baixa granularidade, consulte [Referência de personas e permissões do IAM do Lake Formation](permissions-reference.md). # Controle de acesso a dados subjacente Quando um AWS serviço integrado solicita acesso aos dados em um local do Amazon S3 que é controlado pelo acesso, o Lake AWS Lake Formation Formation fornece credenciais temporárias para acessar os dados. Para permitir que o Lake Formation controle o acesso aos dados subjacentes em um local do Amazon S3, você *registra* esse local no Lake Formation. Depois de registrar uma localização no Amazon S3, você pode começar a conceder as seguintes permissões do Lake Formation: + Permissões de acesso aos dados (`SELECT`, `INSERT` e `DELETE)` nas tabelas do catálogo de dados que apontam para esse local. + Permissões de localização de dados nesse local. As permissões de localização de dados do Lake Formation controlam a capacidade de criar recursos do catálogo de dados que apontam para locais específicos do Amazon S3. As permissões de localização de dados fornecem uma camada extra de segurança aos locais dentro do data lake. Ao conceder a permissão `CREATE_TABLE` ou `ALTER` a uma entidade principal, você também concede permissões de localização de dados para limitar os locais para os quais a entidade principal pode criar ou alterar tabelas de metadados. Os locais do Amazon S3 são buckets ou prefixos em um bucket, mas não objetos individuais do Amazon S3. Você pode conceder permissões de localização de dados a uma entidade principal usando o console do Lake Formation, a API ou a AWS CLI. A forma geral de uma subvenção é a seguinte: ``` grant DATA_LOCATION_ACCESS to principal on S3 location [with grant option] ``` Se você incluir `with grant option`, o beneficiário poderá conceder as permissões a outras entidades principais. Lembre-se de que as permissões do Lake Formation sempre funcionam em combinação com as permissões AWS Identity and Access Management (IAM) para um controle de acesso refinado. Para read/write permissões sobre dados subjacentes do Amazon S3, as permissões do IAM são concedidas da seguinte forma: Ao registrar um local, você especifica um perfil do IAM que concede permissões de leitura/gravação nesse local. A Lake Formation assume essa função ao fornecer credenciais temporárias para serviços integrados. AWS Uma função típica pode ter a seguinte política anexada, em que o local registrado é o bucket `awsexamplebucket`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket/*" ] }, { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket" ] } ] } ``` ------ O Lake Formation fornece uma função vinculada ao serviço que você pode usar durante o registro para criar automaticamente políticas como essa. Para obter mais informações, consulte [Usar perfis vinculados ao serviço para o Lake Formation](service-linked-roles.md). Portanto, registrar um local do Amazon S3 concede as permissões necessárias `s3:` do IAM nesse local, onde as permissões são especificadas pela função usada para registrar o local. **Importante** Evite registrar um bucket do Amazon S3 que **tenha o Solicitante paga** ativado. Para buckets registrados no Lake Formation, a função usada para registrar o bucket é sempre vista como solicitante. Se o bucket for acessado por outra AWS conta, o proprietário do bucket será cobrado pelo acesso aos dados se a função pertencer à mesma conta do proprietário do bucket. Para read/write acessar os dados subjacentes, além das permissões do Lake Formation, os diretores também precisam da permissão do `lakeformation:GetDataAccess` IAM. Com essa permissão, o Lake Formation concede a solicitação de credenciais temporárias para acessar os dados. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "lakeformation:GetDataAccess", "Resource": "*" } ] } ``` ------ Na política acima, você deve definir o parâmetro Resource como '\$1' (all). A especificação de qualquer outro recurso para essa permissão não é aceita. Essa configuração garante que o Lake Formation possa gerenciar o acesso aos dados em todo o seu ambiente de data lake de forma eficiente. **nota** O Amazon Athena exige que o usuário tenha a permissão `lakeformation:GetDataAccess`. Outros serviços integrados exigem que sua função de execução subjacente tenha a permissão `lakeformation:GetDataAccess`. Essa permissão está incluída nas políticas sugeridas no [Referência de personas e permissões do IAM do Lake Formation](permissions-reference.md). Resumindo, para permitir que as entidades principais do Lake Formation leiam e gravem dados subjacentes com acesso controlado pelas permissões do Lake Formation: + Registre os locais do Amazon S3 que contêm os dados com o Lake Formation. + As entidades principais que criam tabelas do catálogo de dados que apontam para locais de dados subjacentes devem ter permissões de localização de dados. + As entidades principais que leem e gravam dados subjacentes devem ter permissões de acesso aos dados do Lake Formation nas tabelas do catálogo de dados que apontam para os locais de dados subjacentes. + As entidades principais que leem e gravam dados subjacentes devem ter a permissão `lakeformation:GetDataAccess` do IAM quando o local dos dados subjacentes é registrado no Lake Formation. **nota** O modelo de permissões do Lake Formation não impede o acesso aos locais do Amazon S3 por meio da API ou do console do Amazon S3 se você tiver acesso a eles por meio de políticas do IAM ou do Amazon S3. Você pode anexar políticas do IAM às entidades principais para bloquear esse acesso. **Saiba mais sobre permissões de localização de dados** As permissões de localização de dados governam o resultado das operações de criação e atualização nos bancos de dados e tabelas do catálogo de dados. As regras são as seguintes: + Uma entidade principal deve ter permissões de localização de dados explícitas ou implícitas em um local do Amazon S3 para criar ou atualizar um banco de dados ou tabela que especifique esse local. + A permissão explícita `DATA_LOCATION_ACCESS` é concedida usando o console, a API ou AWS CLI. + As permissões implícitas são concedidas quando um banco de dados tem uma propriedade de localização que aponta para um local registrado, a entidade principal tem a permissão `CREATE_TABLE` no banco de dados e a entidade principal tenta criar uma tabela nesse local ou em um local secundário. + Se uma entidade principal receber permissões de localização de dados em um local, a entidade principal terá permissões de localização de dados em todos os locais secundários. + Um diretor não precisa de permissões de localização de dados para realizar read/write operações nos dados subjacentes. É suficiente ter as permissões de acesso aos dados `SELECT` ou `INSERT`. As permissões de localização de dados se aplicam somente à criação de recursos do catálogo de dados que apontam para o local. Considere o cenário mostrado no diagrama a seguir. ![\[Hierarquia de pastas e dois bancos de dados, banco de dados A e B, com o banco de dados B apontando para a pasta de atendimento ao cliente.\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/images/location-permissions-example.png) Neste diagrama: + Os buckets do Amazon S3 `Products`, `Finance` e `Customer Service` estão registrados no Lake Formation. + `Database A` não tem propriedade de localização e `Database B` tem uma propriedade de localização que aponta para o bucket `Customer Service`. + O usuário `datalake_user` tem `CREATE_TABLE` nos dois bancos de dados. + O usuário `datalake_user` recebeu permissões de localização de dados somente no bucket `Products`. A seguir estão os resultados quando o usuário `datalake_user` tenta criar uma tabela de catálogo em um banco de dados específico em um determinado local. **Local onde `datalake_user` tenta criar uma tabela** | Banco de dados e localização | Sucesso ou falha | Motivo | | --- | --- | --- | | Banco de dados A em Finance/Sales | Falha | Sem permissão de localização de dados | | Banco de dados A em Products | Sucesso | Possui permissão de localização de dados | | Banco de dados A em HR/Plans | Sucesso | O local não está registrado | | Banco de dados B em Customer Service/Incidents | Sucesso | O banco de dados tem propriedade de localização em Customer Service | Para saber mais, consulte: + [Adicionar uma localização do Amazon S3 ao seu data lake](register-data-lake.md) + [Referência de permissões do Lake Formation](lf-permissions-reference.md) + [Referência de personas e permissões do IAM do Lake Formation](permissions-reference.md)