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á. # Identity and Access Management no Amazon OpenSearch Service O Amazon OpenSearch Service oferece várias maneiras de controlar o acesso aos seus domínios. Esta seção aborda os diversos tipos de políticas, como elass interagem entre si e como você pode criar suas próprias políticas personalizadas. **Importante** O suporte à VPC introduz algumas considerações adicionais sobre o controle de acesso ao OpenSearch serviço. Para obter mais informações, consulte [Sobre políticas de acesso em domínios da VPC](vpc.md#vpc-security). ## Tipos de políticas OpenSearch O serviço oferece suporte a três tipos de políticas de acesso: + [Políticas baseadas em recursos](#ac-types-resource) + [Políticas baseadas em identidade](#ac-types-identity) + [Políticas baseadas em IP](#ac-types-ip) ### Políticas baseadas em recursos Quando um domínio é criado, uma política baseada em recurso é adicionada, muitas vezes chamada de política de acesso ao domínio. Essas políticas especificam que ações uma entidade principal pode executar nos *sub-recursos* do domínio (com exceção da [pesquisa entre clusters](cross-cluster-search.md#cross-cluster-search-walkthrough)). Os sub-recursos incluem OpenSearch índices e. APIs O elemento de política JSON [Entidade principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) no IAM especifica as contas, os usuários ou os perfis que têm acesso permitido. O elemento de política JSON [Recurso](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_resource.html) especifica quais sub-recursos essas entidades principais podem acessar. Por exemplo, a política baseada em recurso a seguir concede ao `test-user` (`es:*`) acesso total aos sub-recursos em `test-domain`: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:*" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" } ] } ``` ------ Duas considerações importantes se aplicam a essa política: + Esses privilégios se aplicam apenas a esse domínio. A menos que você crie políticas semelhantes em outros domínios, `test-user` só poderá acessar `test-domain`. + O terminador `/*` no elemento `Resource` é significativo e indica que as políticas baseadas em recursos só se aplicam aos sub-recursos do domínio, e não ao próprio domínio. Em políticas baseadas em recursos, a ação `es:*` é equivalente a `es:ESHttp*`. Por exemplo, o `test-user` pode fazer solicitações em relação a um índice (`GET https://search-test-domain.us-west-1.es.amazonaws.com/test-index`), mas não pode atualizar a configuração do domínio (`POST https://es.us-west-1.amazonaws.com/2021-01-01/opensearch/domain/test-domain/config`). Observe a diferença entre os dois endpoints. O acesso à API de configuração requer uma [política baseada em identidade](#ac-types-identity). Você pode especificar um nome de índice parcial adicionando um curinga. Este exemplo identifica todos os índices que começam com `commerce`: ``` arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce* ``` Nesse caso, o curinga significa que o `test-user` pode fazer solicitações para índices em `test-domain` que tenham nomes que comecem com `commerce`. Para restringir ainda mais o `test-user`, você pode aplicar a seguinte política: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:ESHttpGet" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce-data/_search" } ] } ``` ------ Agora, o `test-user` só pode executar uma operação: pesquisar no índice `commerce-data`. Todos os outros índices no domínio estão inacessíveis, e sem permissões para usar as ações `es:ESHttpPut` ou `es:ESHttpPost`, o `test-user` não pode adicionar ou modificar documentos. Em seguida, você pode optar por configurar uma função para usuários avançados. Essa política dá `power-user-role` acesso aos métodos HTTP GET e PUT para todos URIs no índice: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:role/power-user-role" ] }, "Action": [ "es:ESHttpGet", "es:ESHttpPut" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce-data/*" } ] } ``` ------ Se o seu domínio estiver em uma VPC ou usar controle de acesso refinado, você poderá usar uma política de acesso a domínios abertos. Caso contrário, sua diretiva de acesso ao domínio deverá conter alguma restrição, seja por endereço IP ou entidade principal. Para obter informações sobre todas as ações disponíveis, consulte [Referência de elementos da política](#ac-reference). Para obter um controle muito mais granular sobre seus dados, use uma política de acesso a domínio aberto com [controle de acesso refinado](fgac.md). ### Políticas baseadas em identidade Ao contrário das políticas baseadas em recursos, que fazem parte de cada domínio de OpenSearch serviço, você anexa políticas baseadas em identidade a usuários ou funções usando o serviço AWS Identity and Access Management (IAM). Assim como nas [políticas baseadas em recursos](#ac-types-resource), as políticas baseadas em identidade especificam quem pode acessar um serviço, quais ações podem ser executadas e, se aplicável, em quais recursos essas ações podem ser executadas. As políticas baseadas em identidade tendem a ser mais genéricas, embora não exista essa exigência. Elas geralmente controlam somente as ações de API de configuração que um usuário pode realizar. Depois de implementar essas políticas, você pode usar políticas baseadas em recursos (ou [controle de acesso refinado) no OpenSearch Service para oferecer aos usuários acesso](fgac.md) a índices e. OpenSearch APIs **nota** Os usuários com a `AmazonOpenSearchServiceReadOnlyAccess` política AWS gerenciada não conseguem ver o status de integridade do cluster no console. Para permitir que eles vejam o status de integridade do cluster (e outros OpenSearch dados), adicione a `es:ESHttpGet` ação a uma política de acesso e anexe-a às suas contas ou funções. Como as políticas baseadas em identidade são anexadas a usuários ou funções (principais), o JSON não especifica um principal. A política a seguir concede acesso a ações que começam com `Describe` e `List`. Essa combinação de ações fornece acesso somente leitura a configurações de domínio, mas não aos dados armazenados no próprio domínio: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "es:Describe*", "es:List*" ], "Effect": "Allow", "Resource": "*" } ] } ``` ------ Um administrador pode ter acesso total ao OpenSearch Serviço e a todos os dados armazenados em todos os domínios: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "es:*" ], "Effect": "Allow", "Resource": "*" } ] } ``` ------ As políticas baseadas em identidade permitem que você use tags para controlar o acesso à API de configuração. A seguinte política, por exemplo, permitirá que as entidades principais anexadas visualizem e atualizem a configuração de um domínio se o domínio tiver a tag `team:devops`: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Action": [ "es:UpdateDomainConfig", "es:DescribeDomain", "es:DescribeDomainConfig" ], "Effect": "Allow", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:ResourceTag/team": [ "devops" ] } } }] } ``` ------ Você também pode usar tags para controlar o acesso à OpenSearch API. As políticas baseadas em tags para a OpenSearch API se aplicam somente aos métodos HTTP. Por exemplo, a política a seguir permite que os diretores anexados enviem solicitações GET e PUT para a OpenSearch API se o domínio tiver a `environment:production` tag: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Action": [ "es:ESHttpGet", "es:ESHttpPut" ], "Effect": "Allow", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:ResourceTag/environment": [ "production" ] } } }] } ``` ------ Para um controle mais granular da OpenSearch API, considere usar um controle de [acesso refinado](fgac.md). **nota** Depois de adicionar uma ou mais OpenSearch APIs políticas baseadas em tags, você deve realizar uma única [operação de tag](managedomains-awsresourcetagging.md) (como adicionar, remover ou modificar uma tag) para que as alterações entrem em vigor em um domínio. Você deve usar o software de serviço R20211203 ou posterior para incluir operações de OpenSearch API em políticas baseadas em tags. OpenSearch O serviço oferece suporte às chaves de condição `TagKeys` globais `RequestTag` e da API de configuração, não da OpenSearch API. Essas condições aplicam-se somente a chamadas de API que incluem tags dentro da solicitação, como `CreateDomain`, `AddTags` e `RemoveTags`. A política a seguir permite que as entidades principais anexadas criem domínios, mas somente se incluírem a tag `team:it` na solicitação: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "es:CreateDomain", "es:AddTags" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/team": [ "it" ] } } } } ``` ------ Para saber mais sobre o uso de tags para controle de acesso e sobre as diferenças entre as políticas baseadas em recursos e as políticas baseadas em identidades, consulte [Definir permissões com base em atributos com autorização ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) no *Guia do usuário do IAM*. ### Políticas baseadas em IP As políticas baseadas em IP restringem o acesso a um domínio para um ou mais endereços IP ou blocos CIDR. Tecnicamente, as políticas baseadas em IP não são um tipo de política diferente. Mas na verdade, elas são apenas políticas baseadas em recursos que especificam uma entidade principal anônima e incluem uma condição especial. Para saber mais, consulte [Elementos de política JSON do IAM: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) no *Guia do usuário do IAM*. O principal atrativo das políticas baseadas em IP é que elas permitem solicitações não assinadas a um domínio de OpenSearch serviço, o que permite usar clientes como [curl](https://curl.haxx.se/) e [OpenSearch painéis](dashboards.md) ou acessar o domínio por meio de um servidor proxy. Para saber mais, consulte [Usando um proxy para acessar o OpenSearch serviço a partir de painéis](dashboards.md#dashboards-proxy). **nota** Se você ativou o acesso à VPC para seu domínio, não poderá configurar uma política baseada em IP. Em vez disso, você pode usar `security groups` para controlar quais endereços IP podem acessar o domínio. Para saber mais, consulte os seguintes tópicos: [Sobre políticas de acesso em domínios da VPC](vpc.md#vpc-security) [Controle o tráfego para seus AWS recursos usando grupos de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) no Guia do *usuário da Amazon VPC* A política a seguir concede a todas as solicitações HTTP que se originam no intervalo de IP especificado acesso ao `test-domain`: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": [ "es:ESHttp*" ], "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/24" ] } }, "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" } ] } ``` ------ Se o seu domínio tiver um endpoint público e não usar [controle de acesso refinado](fgac.md), recomendamos combinar entidades principais do IAM e endereços IP. Esta política concederá acesso HTTP ao `test-user` somente se a solicitação se originar do intervalo de IP especificado: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::987654321098:user/test-user" ] }, "Action": [ "es:ESHttp*" ], "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/24" ] } }, "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" }] } ``` ------ ## Quando há colisão de políticas Quando as políticas discordam entre si ou não fazem nenhuma referência explícita a um usuário, surgem complexidades. [Como o IAM funciona](https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-structure.html) no *Guia do usuário do IAM* fornece um breve resumo da lógica de avaliação de políticas: + Por padrão, todas as solicitações são negadas. + Uma permissão explícita substitui esse padrão. + Uma negar explícito substitui todas as permissões. Por exemplo, se uma política baseada em recursos conceder acesso a um sub-recurso de domínio (um OpenSearch índice ou API), mas uma política baseada em identidade negar seu acesso, você terá acesso negado. Se uma política baseada em identidade concede acesso e uma política baseada em recursos não especifica se você deve ou não ter acesso, esse acesso é concedido. Consulte a tabela a seguir com o cruzamento de políticas para obter um resumo completo dos resultados para sub-recursos de domínios. **** | | Permitido na política baseada em recursos | Negado na política baseada em recursos | Nem permitido nem negado na política baseada em recursos | | --- |--- |--- |--- | | **Allowed in identity-based policy** | Permitir | Deny | Permitir | | --- |--- |--- |--- | | **Denied in identity-based policy** | Deny | Deny | Deny | | --- |--- |--- |--- | | **Neither allowed nor denied in identity-based policy** | Permitir | Deny | Deny | | --- |--- |--- |--- | ## Referência de elementos da política OpenSearch O serviço oferece suporte à maioria dos elementos de [política na Referência de elementos de política do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/AccessPolicyLanguage_ElementDescriptions.html), com exceção de`NotPrincipal`. A tabela a seguir mostra os elementos mais comuns. **** | Elemento da política de JSON | Resumo | | --- | --- | | Version | Versão atual da linguagem de política é `2012-10-17`. Todas as políticas de acesso devem especificar esse valor. | | Effect | Esse elemento especifica se a declaração permite ou nega o acesso às ações especificadas. Os valores válidos são `Allow` ou `Deny`. | | Principal | Esse elemento especifica a função Conta da AWS ou o usuário do IAM que tem acesso permitido ou negado a um recurso e pode assumir várias formas: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/opensearch-service/latest/developerguide/ac.html) Especificar o curinga `*` permite o acesso anônimo ao domínio, o que não recomendamos, a menos que você adicione uma [condição baseada em IP](#ac-types-ip), use o [suporte à VPC](vpc.md) ou habilite o [controle de acesso refinado](fgac.md). Além disso inspecione com cuidado as seguintes políticas para garantir que elas não concedam acesso amplo: Políticas baseadas em identidade vinculadas a entidades principais da AWS associadas (por exemplo, perfis do IAM). Políticas baseadas em recursos anexadas aos AWS recursos associados (por exemplo, chaves AWS Key Management Service KMS) | | Action | OpenSearch O serviço usa `ESHttp*` ações para métodos OpenSearch HTTP. O resto das ações se aplicam à API de configuração.Determinadas ações `es:` dão suporte a permissões no nível do recurso. Por exemplo, você pode conceder a um usuário permissões para excluir um determinado domínio sem conceder a esse usuário permissões para excluir *qualquer* domínio. Outras ações se aplicam apenas ao serviço em si. Por exemplo, `es:ListDomainNames` não faz sentido no contexto de um único domínio e, portanto, requer um curinga.Para obter uma lista de todas as ações disponíveis e se elas se aplicam aos sub-recursos do domínio (`test-domain/*`), à configuração do domínio (`test-domain`) ou somente ao serviço (`*`), consulte [Ações, recursos e chaves de condição do Amazon OpenSearch Service na Referência](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonopensearchservice.html) de *Autorização de Serviço*Políticas baseadas em recursos são diferentes das permissões no nível do recurso. As [políticas baseadas em recursos](#ac-types-resource) são políticas JSON completas anexadas aos domínios. As permissões no nível do recurso tornam possível a restrição de ações em domínios específicos ou sub-recursos. Na prática, você pode pensar na permissão no nível do recurso como uma seção opcional de um recurso ou uma política baseada em identidade.Embora as permissões no nível de recurso para `es:CreateDomain` possam parecer não intuitivas — afinal de contas, por que conceder permissões a um usuário para criar um domínio que já existe? —, o uso de um curinga permite aplicar um esquema de nomenclatura simples aos seus domínios, como `"Resource": "arn:aws:es:us-west-1:987654321098:domain/my-team-name-*"`.Naturalmente, nada impede que você inclua ações juntamente com elementos de recursos menos restritivos, como estes: JSON **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "es:ESHttpGet", "es:DescribeDomain" ], "Resource": "*" } ] } ``` Para saber mais sobre o emparelhamento de ações e recursos, consulte o elemento `Resource` nesta tabela. | | Condition | OpenSearch O serviço é compatível com a maioria das condições descritas nas [chaves de contexto de condição AWS global](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#AvailableKeys) no *Guia do usuário do IAM*. Exceções notáveis incluem a `aws:PrincipalTag` chave, que o OpenSearch Serviço não suporta. Ao configurar uma [política baseada em IP](#ac-types-ip), você especifica os endereços IP ou bloco CIDR como uma condição, como esta: 
"Condition": {
  "IpAddress": {
    "aws:SourceIp": [
      "192.0.2.0/32"
    ]
  }
}
Conforme observado em [Políticas baseadas em identidade](#ac-types-identity)`aws:ResourceTag`, as chaves de `aws:TagKeys` condição`aws:RequestTag`, e se aplicam à API de configuração, bem como OpenSearch APIs a. | | Resource | OpenSearch O serviço usa `Resource` elementos de três maneiras básicas: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/opensearch-service/latest/developerguide/ac.html) Para obter detalhes sobre quais ações dão suporte a permissões no nível do recurso, consulte o elemento `Action` nesta tabela. | ## Opções avançadas e considerações sobre a API OpenSearch O serviço tem várias opções avançadas, uma das quais tem implicações de controle de acesso:`rest.action.multi.allow_explicit_index`. Como sua configuração padrão é verdadeiro, ela permite que os usuários ignorem as permissões de sub-recursos em determinadas circunstâncias. Por exemplo, considere a seguinte política baseada em recurso: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:ESHttp*" ], "Resource": [ "arn:aws:es:us-west-1:987654321098:domain/test-domain/test-index/*", "arn:aws:es:us-west-1:987654321098:domain/test-domain/_bulk" ] }, { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:ESHttpGet" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/restricted-index/*" } ] } ``` ------ Essa política concede acesso `test-user` total `test-index` e à API OpenSearch em massa. Ela também permite solicitações `GET` ao `restricted-index`. A seguinte solicitação de indexação, como você pode esperar, falha devido a um erro de permissão: ``` PUT https://search-test-domain.us-west-1.es.amazonaws.com/restricted-index/movie/1 { "title": "Your Name", "director": "Makoto Shinkai", "year": "2016" } ``` Ao contrário da API de índice, a API em massa permite criar, atualizar e excluir vários documentos em uma única chamada. Contudo, normalmente você especifica essas operações no corpo da solicitação, em vez de na URL da solicitação. Como o OpenSearch Service usa URLs para controlar o acesso aos sub-recursos do domínio, `test-user` pode, na verdade, usar a API em massa para fazer alterações em. `restricted-index` Embora o usuário não tenha permissões `POST` no índice, a seguinte solicitação **é bem-sucedida**: ``` POST https://search-test-domain.us-west-1.es.amazonaws.com/_bulk { "index" : { "_index": "restricted-index", "_type" : "movie", "_id" : "1" } } { "title": "Your Name", "director": "Makoto Shinkai", "year": "2016" } ``` Nesta situação, a política de acesso não consegue cumprir o que pretendia. Para evitar que os usuários ignorem esses tipos de restrições, você pode alterar o `rest.action.multi.allow_explicit_index` para o valor falso. Se esse valor for falso, todas as chamadas para bulk, mget e msearch APIs que especificam nomes de índice no corpo da solicitação deixarão de funcionar. Em outras palavras, as chamadas para `_bulk` não funcionam mais, mas as chamadas para o `test-index/_bulk` funcionam. Este segundo endpoint contém um nome de índice, portanto, você não precisa especificar um no corpo da solicitação. [OpenSearch Os painéis](dashboards.md) dependem muito de mget e msearch, portanto, é improvável que funcionem corretamente após essa alteração. Para remediação parcial, você pode deixar `rest.action.multi.allow_explicit_index` como verdadeiro e negar a determinados usuários o acesso a um ou mais deles APIs. Para obter informações sobre como alterar essa configuração, consulte [Configurações avançadas do cluster](createupdatedomains.md#createdomain-configure-advanced-options). Da mesma forma, a seguinte política baseada em recursos contém dois problemas sutis: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/test-user" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" }, { "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::123456789012:user/test-user" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/restricted-index/*" } ] } ``` ------ + Apesar da negação explícita, o `test-user` ainda pode fazer chamadas, como `GET https://search-test-domain.us-west-1.es.amazonaws.com/_all/_search` e `GET https://search-test-domain.us-west-1.es.amazonaws.com/*/_search` para acessar os documentos no `restricted-index`. + Como o elemento `Resource` faz referência ao `restricted-index/*`, o `test-user` não tem permissões para acessar diretamente os documentos do índice. O usuário, no entanto, tem permissões para *excluir todo o índice*. Para evitar o acesso e a exclusão, a política deve especificar `restricted-index*`. Em vez de misturar permissões amplas e negações focadas, a abordagem mais segura é seguir o princípio do [privilégio mínimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) e conceder apenas as permissões necessárias para executar uma tarefa. Para obter mais informações sobre como controlar o acesso a índices ou OpenSearch operações individuais, consulte[Controle de acesso refinado no Amazon Service OpenSearch](fgac.md). **Importante** A especificação de um caractere curinga \$1 permite acesso anônimo ao domínio. Não é recomendável usar o caractere curinga. Além disso analise com cuidado as seguintes políticas para garantir que não concedam amplo acesso: Políticas baseadas em identidade vinculadas aos AWS diretores associados (por exemplo, funções do IAM) Políticas baseadas em recursos anexadas aos AWS recursos associados (por exemplo, chaves AWS Key Management Service KMS) ## Configuração de políticas de acesso + Para obter instruções sobre como criar ou modificar políticas baseadas em recursos e IP no OpenSearch Service, consulte. [Configuração de políticas de acesso](createupdatedomains.md#createdomain-configure-access-policies) + Para obter instruções para criar ou modificar políticas baseadas em identidades no IAM, consulte [Defina permissões personalizadas do IAM com políticas gerenciadas pelo cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) no *Guia do usuário do IAM*. ## Exemplos adicionais de políticas Embora este capítulo inclua muitos exemplos de políticas, o controle de AWS acesso é um assunto complexo que é melhor compreendido por meio de exemplos. Para saber mais, consulte [Exemplo de políticas baseadas em identidade do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_examples.html) no*Manual do usuário do IAM*.