AWS Identity and Access Management
Guia do usuário

Políticas e permissões

Você gerencia o acesso no AWS criando políticas e anexando-as a identidades do IAM (usuários, grupos de usuários ou regras) ou recursos do AWS. Uma política é um objeto no AWS que, quando associado a uma identidade ou recurso, define suas permissões. O AWS avalia essas políticas quando uma entidade principal (usuário ou função) faz uma solicitação. As permissões nas políticas determinam se a solicitação é consentida ou negada. A maioria das políticas é armazenada no AWS como documentos JSON. O AWS é compatível com seis tipos de políticas: políticas baseadas em identidade, políticas baseadas em recurso, limites de permissões, SCPs do Organizações, ACLs e políticas de sessão.

As políticas do IAM definem permissões para uma ação, independentemente do método que você usa para executar a operação. Por exemplo, se uma política permitir a ação GetUser, um usuário com essa política poderá obter informações de usuários no Console de gerenciamento da AWS, na AWS CLI ou na API da AWS. Ao criar um usuário do IAM, você pode optar por permitir acesso ao console ou programático. Se o acesso ao console for permitido, o usuário do IAM pode fazer login no console usando um nome de usuário e senha. Ou se o acesso programático for permitido, o usuário poderá usar as chaves de acesso para trabalhar com a CLI ou a API.

Tipos de políticas

Os seguintes tipos de políticas, listados em ordem de frequência, estão disponíveis para uso na AWS. Para obter mais detalhes, consulte as seções a seguir para cada tipo de política.

  • Políticas baseadas em identidade – Anexe políticas gerenciadas e em linha a identidades do IAM (como usuários, grupos aos quais os usuários pertencem ou funções). As políticas baseadas em identidade concedem permissões a uma identidade.

  • Políticas baseadas em recurso – anexe políticas em linha a recursos. Os exemplos de políticas baseadas em recurso mais comuns são as políticas de bucket do Amazon S3 e as políticas de confiança de funções do IAM. As políticas baseadas em recurso concedem permissões a uma entidade principal que é especificada na política. As principais podem ser na mesma conta como o recurso ou em outras contas.

  • Limites de permissões – Use uma política gerenciada como limite de permissões para uma entidade do IAM (usuário ou função). Essa política define o número máximo de permissões que as políticas baseadas em identidade podem conceder a uma entidade, mas não concede permissões. Os limites de permissões não definem o número máximo de permissões que uma política baseada em recurso pode conceder a uma entidade.

  • SCPs de organizações – Use uma política de controle de serviço (SCP) do AWS Organizations para definir o número máximo de permissões para os membros da conta de uma organização ou unidade organizacional (UO). As SCPs limitam as permissões que as políticas baseadas em identidade ou políticas baseadas em recurso concedem a entidades (usuários ou funções) dentro da conta, mas não concedem permissões.

  • Listas de controle de acesso (ACLs) – Use ACLs para controlar quais principais em outras contas podem acessar o recurso ao qual a ACL está anexada. As ACLs são semelhantes às políticas baseadas em recurso, embora sejam o único tipo de política que não usa a estrutura de documento de política JSON. As ACLs são políticas de permissões entre contas que concedem permissões para a entidade principal especificada. As ACLs não podem conceder permissões para entidades na mesma conta.

  • Políticas de sessão – Transmita uma sessão avançada quando você usar a API de AWS CLI ou AWS para assumir uma função ou um usuário federado. As políticas de sessão limitam as permissões que as políticas baseada em identidade do usuário ou função concedem à sessão. As políticas de sessão limitam as permissões para uma sessão criada, mas não concedem permissões. Para obter mais informações, consulte Políticas de sessão.

Políticas baseadas em identidade

As políticas baseadas em identidade são documentos de políticas de permissão JSON que você pode anexar a uma identidade (usuário, grupo de usuários ou função). Essas políticas controlam quais ações uma entidade (usuário ou função) pode realizar, em quais recursos e em que condições. As políticas baseadas em identidade podem ser categorizadas em:

  • Políticas gerenciadas – Políticas independentes baseadas em identidade que você pode anexar a vários usuários, grupos e funções na sua conta da AWS. Você pode usar dois tipos de políticas gerenciadas:

    • Políticas gerenciadas pela AWS – políticas gerenciadas que são criadas e gerenciadas pela AWS. Se você não tiver experiência com o uso de políticas, recomendamos começar usando políticas gerenciadas pela AWS.

    • Políticas gerenciadas pelo cliente – políticas gerenciadas que você criar e gerenciar em sua conta da AWS. As políticas gerenciadas pelo cliente oferecem um controle mais preciso de suas políticas do que as políticas gerenciadas pela AWS. Você pode criar e editar uma política do IAM no editor visual ou criando diretamente o documento de política JSON. Para obter mais informações, consulte Como criar políticas do IAM e Editar políticas do IAM.

  • Políticas em linha – Políticas que você cria e gerencia e que são incorporadas diretamente em um único usuário, grupo ou função. Na maioria dos casos, não recomendamos o uso de políticas embutidas.

Para saber como escolher entre uma política gerenciada ou uma política em linha, consulte Políticas gerenciadas e embutidas.

Políticas com base em recurso

Políticas baseadas em recursos são documentos de política JSON que você anexa a um recurso, como um bucket do Amazon S3. Essas políticas concedem permissão ao principal especificado para executar ações específicas nesse recurso e definem em que condições isso se aplica. Políticas baseadas em recurso são políticas embutidas. Não há políticas baseadas em recurso gerenciados.

Para permitir o acesso entre contas, você pode especificar uma conta inteira ou as entidades do IAM em outra conta como o principal em uma política baseada em recurso. Adicionar um principal entre contas à política baseada em recurso é apenas metade da tarefa de estabelecimento da relação de confiança. Quando o principal e o recurso estiverem em contas separadas do AWS, você também deverá usar uma política baseada em identidade para conceder o acesso à entidade principal para o recurso. No entanto, se uma política baseada em recurso conceder acesso a um principal na mesma conta, nenhuma política baseada em identidade adicional será necessária.

O serviço do IAM oferece suporte a apenas um tipo de política baseada em recurso chamada política de confiança de uma função, que é anexada a uma função do IAM. Como uma função do IAM é uma identidade e um recurso que oferece suporte a políticas baseadas em recurso, você deve anexar uma política de confiança e uma política baseada em identidade a uma função do IAM. As políticas de confiança definem quais entidades principais (contas, usuários, funções e usuários federados) podem assumir a função. Para saber como as funções do IAM são diferentes das outras políticas baseadas em recurso, consulte Como as funções do IAM diferem de políticas baseadas em recursos.

Para ver quais outros serviços oferecem suporte a políticas baseadas em recurso, consulte Serviços da AWS compatíveis com o IAM. Para saber mais sobre as políticas baseadas em recursos, consulte Políticas baseadas em identidade e em recursos.

Limites de permissões do IAM

Um limite de permissões é um recurso avançado no qual você define as permissões máximas que uma política baseada em identidade pode conceder a uma entidade do IAM. Quando você definir um limite de permissões para uma entidade, a entidade poderá executar apenas as ações que são permitidas por ambas as políticas baseadas em identidade e seus limites de permissões. As políticas baseadas em recurso que especificam o usuário ou a função como principais não são limitadas pelo limite de permissões. Uma negação explícita em qualquer uma dessas políticas substitui a permissão. Para obter mais informações sobre esses limites de permissões, consulte Limites de permissões para entidades do IAM.

Políticas de controle de serviço (SCPs)

O AWS Organizations é um serviço para agrupar e gerenciar centralmente as contas da AWS que sua empresa possui. Se você ativar todos os recursos em uma organização, poderá aplicar políticas de controle de serviço (SCPs) a qualquer uma ou a todas as suas contas. SCPs são políticas JSON que especificam o máximo de permissões para uma organização ou unidade organizacional (UO). O SCP limita as permissões para entidades em contas-membro, incluindo cada Usuário raiz da conta da AWS. Uma negação explícita em qualquer uma dessas políticas substitui a permissão.

Para obter mais informações sobre o Organizações e SCPs, consulte Sobre políticas de controle de serviço no Guia do usuário do AWS Organizations.

Políticas de controle de acesso (ACLs)

As listas de controle de acesso (ACLs) permitem controlar quais principais em outra conta podem acessar um recurso. As ACLs não podem ser usadas para controlar o acesso a um principal na mesma conta. As ACLs são semelhantes às políticas baseadas em recurso, embora sejam o único tipo de política que não usa o formato de documento de política JSON. Amazon S3, AWS WAF e Amazon VPC são exemplos de serviços que dão suporte a ACLs. Para saber mais sobre as ACLs, consulte Visão geral da lista de controle de acesso (ACL) no Guia do desenvolvedor do Amazon Simple Storage Service.

Políticas de sessão

As políticas de sessão são políticas avançadas que você transmite como um parâmetro quando você cria de forma programática uma sessão temporária para uma função ou usuário federado. As permissões para uma sessão vêm de políticas baseadas em identidade para a entidade do IAM (usuário ou função) usada para criar a sessão e da política da sessão. As permissões também podem ser provenientes de uma política baseada em recurso. Uma negação explícita em qualquer uma dessas políticas substitui a permissão.

Você pode criar uma sessão de função e transmitir uma política de sessão de forma programática usando as operações de API AssumeRole, AssumeRoleWithSAML ouAssumeRoleWithWebIdentity. A sessão resultante terá apenas as permissões concedidas pela política de sessão e política baseada em identidade da função Para obter mais informações sobre a criação de uma sessão de função, consulte Solicitação de credenciais de segurança temporárias.

Quando você criar uma sessão de usuário federado, use chaves de acesso do usuário do IAM para chamar de forma programática a operação da API GetFederationToken. Ao fazer isso e transmitir uma política de sessão, a sessão resultante terá apenas as permissões concedidas pela política de sessão e política baseada em identidade do usuário do IAM. Para obter mais informações sobre a criação de uma sessão de usuário federado, consulte GetFederationToken— Federação por meio de um agente de identidades personalizado.

Se uma política baseada em recurso especificar o ARN do usuário ou da função como um principal, então as permissões da política baseada em recurso serão adicionadas à política baseada em identidade da função ou do usuário antes de a sessão ser criada. A política de sessão limita o total de permissões concedidas pela política baseada em recurso e política baseada em identidade. A sessão resultante terá as permissões da política de sessão, além das da política baseada em recurso ou em identidade.


          Avaliação da política de sessão com uma política baseada em recurso especificando o ARN da entidade

Se uma política baseada em recurso especificar o ARN da sessão como um principal, então as permissões da política baseada em recurso serão adicionadas depois de a sessão ser criada. As permissões da política baseada em recurso não são limitadas pela política de sessão. A sessão resultante tem todas as permissões da política baseada em recurso além das permissões concedidas tanto pela política baseada em identidade quanto pela política de sessão.


          Avaliação da política de sessão com uma política baseada em recurso especificando o ARN da sessão

Se um limite máximo de permissões definir as permissões para um usuário ou uma função que são usadas para criar uma sessão, então a sessão resultante terá apenas as permissões na política de sessão, os limites de permissões e a política baseada em identidade.


          Avaliação da política de sessão com um limite de permissões

Políticas e o usuário raiz

O Usuário raiz da conta da AWS é afetado por alguns tipos de políticas, mas não por outros. Você não pode anexar políticas baseadas em identidade ao usuário raiz e não pode definir o limite de permissões para o usuário raiz. No entanto, você pode especificar o usuário raiz como a entidade principal em uma política baseada em recurso ou em uma ACL. Como membro de uma conta, o usuário raiz é afetado por qualquer SCP da conta.

Visão geral das políticas JSON

A maioria das políticas são armazenadas na AWS como documentos JSON. As políticas baseadas em identidade e as políticas usadas para definir limites de permissões são documentos de política JSON que você anexa a um usuário ou a uma função. Políticas baseadas em recurso são documentos de políticas JSON que você anexa a um recurso. As SCPs são documentos de políticas JSON com sintaxe restrita que você anexa a uma unidade organizacional (UO) do AWS Organizations. As ACLs também são anexadas a um recurso, mas você deve usar uma sintaxe diferente. As políticas de sessão são políticas JSON que você fornece ao assumir uma sessão de função.

Você não precisa compreender a sintaxe JSON. Você pode usar o editor visual no Console de gerenciamento da AWS para criar e editar políticas gerenciadas pelo cliente sem nunca ter usado o JSON. No entanto, se você optar por usar políticas em linha para grupos ou políticas complexas, ainda será necessário criar e editar essas políticas no editor de JSON usando o console. Para obter informações sobre como usar o editor visual, consulte Como criar políticas do IAM e Editar políticas do IAM.

Estrutura de documento de política JSON

Como mostrado na figura a seguir, um documento de política JSON inclui estes elementos:

  • Informações opcionais de políticas na parte superior do documento

  • Uma ou mais instruções individuais

Cada instrução inclui informações sobre uma única permissão. Se uma política incluir várias instruções, a AWS aplicará um OR lógico a todas as instruções ao avaliá-las. Se várias políticas se aplicarem a uma solicitação, a AWS aplicará um OR lógico a todas essas políticas ao avaliá-las.


          Estrutura de documento de política JSON

As informações em uma instrução estão contidas em uma série de elementos.

  • Versão – Especifique a versão da linguagem de política que você deseja usar. Como uma melhor prática, use a versão 2012-10-17 mais recente.

  • Instrução – Use este elemento de política principal como um contêiner para os seguintes elementos. Você pode incluir mais de uma instrução em uma política.

  • Sid – inclua um ID de instrução opcional para diferenciar entre suas instruções.

  • Efeito – Use Allow ou Deny para indicar se a política permite ou nega acesso.

  • Principal – Indique a conta, o usuário, a função ou o usuário federado ao qual você deseja permitir ou negar o acesso. Se estiver criando uma política para anexar a um usuário ou a uma função, você não poderá incluir esse elemento. A entidade principal é implícita como esse usuário ou função.

  • Ação – Inclui uma lista de ações que a política permite ou nega.

  • Recurso – Especifica uma lista de recursos aos quais as ações se aplicam.

  • Condição (opcional) – Especifica as circunstâncias sob as quais a política concede a permissão.

Para saber mais sobre esses e outros elementos mais avançados de políticas, consulte Referência de elementos de política JSON do IAM.

Várias instruções e várias políticas

Se desejar definir mais de uma permissão para uma entidade (usuário, grupo ou função), você poderá usar várias instruções em uma única política ou anexar várias políticas. Se você tentar definir várias permissões em uma única instrução, sua política poderá não conceder o acesso esperado. Como uma melhor prática, divida as políticas por tipo de recurso.

Devido ao tamanho limitado das políticas, poderá ser necessário usar várias políticas para permissões mais complexas. Também é uma boa ideia criar agrupamentos funcionais de permissões em uma política gerenciada pelo cliente separada. Por exemplo, crie uma política para gerenciamento de usuários do IAM, uma para autogerenciamento e outra política para gerenciamento de buckets do S3. Independentemente da combinação de várias instruções e de várias políticas, a AWS avalia suas políticas da mesma forma.

Por exemplo, a política a seguir tem três instruções, cada uma delas define um conjunto separado de permissões em uma única conta. As instruções definem o seguinte:

  • A primeira instrução, com um Sid (ID de instrução) de FirstStatement, permite que o usuário com a política anexada altere sua própria senha. O elemento Resource nesta instrução é "*" (que significa "todos os recursos"), mas, na prática, a operação da API ChangePassword (ou o comando equivalente change-password da CLI) afeta somente a senha do usuário que faz a solicitação.

  • A segunda instrução permite que o usuário liste todos os buckets do Amazon S3 em sua conta da AWS. O elemento Resource nessa instrução é "*" (o que significa "todos os recursos"). Mas como as políticas não concedem acesso aos recursos em outras contas, o usuário pode listar somente os buckets em sua própria conta da AWS.

  • A terceira instrução permite que o usuário liste e recupere qualquer objeto que esteja em um bucket chamado confidential-data, mas somente quando o usuário estiver autenticado com autenticação multifator (MFA). O elemento Condition na política impõe a autenticação MFA.

    Quando uma instrução de política contém um elemento Condition, ela só entrará em vigor quando o elemento Condition for verdadeiro. Nesse caso, a Condition é avaliada como verdadeira quando o usuário é autenticado por MFA. Se o usuário não for autenticado por MFA, essa Condition será avaliada como falsa. Nesse caso, a terceira instrução dessa política não se aplicará, e o usuário não terá acesso ao bucket confidential-data.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "FirstStatement", "Effect": "Allow", "Action": ["iam:ChangePassword"], "Resource": "*" }, { "Sid": "SecondStatement", "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" }, { "Sid": "ThirdStatement", "Effect": "Allow", "Action": [ "s3:List*", "s3:Get*" ], "Resource": [ "arn:aws:s3:::confidential-data", "arn:aws:s3:::confidential-data/*" ], "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}} } ] }

Exemplos de sintaxe de política JSON

A seguinte política baseada em identidade permite que a entidade principal implícita liste um único bucket do Amazon S3 denominado example_bucket:

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::example_bucket" } }

A seguinte política baseada em recurso pode ser anexada a um bucket do Amazon S3. A política permite que membros de uma conta específica da AWS execute qualquer ação do Amazon S3 no bucket denominado mybucket. Ela permite qualquer ação que pode ser executada em um bucket ou em seus objetos. (Como a política concede confiança apenas à conta, os usuários individuais da conta ainda devem receber permissões para as ações especificadas do Amazon S3.)

{ "Version": "2012-10-17", "Id": "S3-Account-Permissions", "Statement": [{ "Sid": "1", "Effect": "Allow", "Principal": {"AWS": ["arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:root"]}, "Action": "s3:*", "Resource": [ "arn:aws:s3:::mybucket", "arn:aws:s3:::mybucket/*" ] }] }

Para visualizar políticas de exemplo para cenários comuns, consulte Exemplos de políticas baseadas em identidade do IAM.