Políticas e permissões no IAM - AWS Identity and Access Management

Políticas e permissões no IAM

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 na AWS que, quando associado a uma identidade ou a um recurso, define suas permissões. A AWS avalia essas políticas quando uma entidade principal do IAM (usuário ou função) faz uma solicitação. As permissões nas políticas determinam se a solicitação será permitida 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 Organizations, 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 AWS Management Console, 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 tipos de política a seguir, listados dos mais usados aos usados com menos frequência, estão disponíveis para uso em 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 à 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 políticas de sessão avançada quando você usar a AWS CLI ou a API da 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

Políticas baseadas em identidade são documentos de política de permissões JSON que controlam quais ações uma identidade (usuários, grupos de usuários e funções) pode executar, 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. Existem dois tipos de políticas gerenciadas:

    • Políticas gerenciadas pela AWS – políticas gerenciadas que são criadas e 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.

  • Políticas em linha – políticas que você adiciona diretamente a um único usuário, a um único grupo ou a uma única função. As políticas em linha mantêm uma relação individual estrita entre uma política e uma identidade. Elas são excluídas quando você exclui a identidade.

Para saber como escolher entre políticas gerenciadas e em linha, consulte Escolher entre políticas gerenciadas e em linha.

Políticas baseadas em recursos

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 a entidade principal e o recurso estiverem em contas separadas da AWS, também será necessário 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. Para obter instruções passo a passo sobre como conceder acesso entre serviços, consulte Tutorial do IAM: delegar acesso entre contas da AWS usando funções do IAM .

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. Uma função do IAM é uma identidade e um recurso que é compatível com as políticas baseadas em recurso. Por esse motivo, 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. Para saber se os principais de contas fora de sua zona de confiança (organização confiável ou conta) têm acesso para assumir as suas funções, consulte O que é IAM Access Analyzer?.

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 Organizations e SCPs, consulte Como SCPs funcionam no Guia do usuário do AWS Organizations.

Listas de controle de acesso (ACLs)

As listas de controle de acesso (ACLs) são políticas de serviço que 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 políticas de sessão de forma programática usando as operações de API AssumeRole, AssumeRoleWithSAML ou AssumeRoleWithWebIdentity. Você pode passar um único documento de política JSON de sessão em linha usando o parâmetro Policy. Você pode usar o parâmetro PolicyArns para especificar até 10 políticas de sessão gerenciadas. Para obter mais informações sobre a criação de uma sessão de função, consulte Solicitar 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. Você também deve transmitir as políticas da sessão. As permissões da sessão resultam da interseção da política baseada em identidade do usuário do IAM e da política de sessão. 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.

Uma política baseada em recurso pode especificar o ARN do usuário ou função como uma entidade principal. Nesse caso, as permissões da política baseada em recurso são adicionadas à função ou política baseada em identidade do usuário antes que a sessão seja 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. As permissões da sessão resultante são a interseção das políticas de sessão e as políticas baseadas em recursos, além da interseção das políticas de sessão e políticas baseadas em identidade.


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

Uma política baseada em recurso pode especificar o ARN da sessão como uma entidade principal. Nesse caso, as permissões da política baseada em recurso são adicionadas depois que a sessão for 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 da interseção da política baseada em identidade e da 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

Um limite de permissões pode definir o número máximo de permissões para um usuário ou uma função que é usada para criar uma sessão. Nesse caso, as permissões da sessão resultam da interseção da política de sessão, do limite de permissões e da política baseada em identidade. No entanto, um limite de permissões não limita as permissões concedidas por uma política baseada em recurso que especifica o ARN da sessão resultante.


          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. Um usuário raiz ainda é o membro de uma conta. Se essa conta for membro de uma organização em AWS Organizations, o usuário raiz será afetado por quaisquer SCPs da conta.

Visão geral de 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 ou usuário federado.

Você não precisa compreender a sintaxe JSON. Você pode usar o editor visual no AWS Management Console para criar e editar políticas gerenciadas pelo cliente sem nunca ter usado o JSON. No entanto, se você 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 Criar políticas do IAM e Editar políticas do IAM.

Quando você cria ou edita uma política JSON, o IAM pode executar a validação de política para ajudar a criar uma política efetiva. O IAM identifica erros de sintaxe JSON, enquanto o IAM Access Analyzer fornece verificações de políticas adicionais com recomendações para ajudar a refinar ainda mais as políticas. Para saber mais sobre a validação de políticas, consulte Validar políticas do IAM. Para saber mais sobre verificações de políticas do IAM Access Analyzer e recomendações acionáveis, consulte Validação de política do IAM Access Analyzer.

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 da política 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.

  • Version – 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.

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

  • Sid (Opcional) – Inclua um ID de instrução opcional para diferenciar entre suas instruções.

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

  • Principal (Obrigatório apenas em algumas circunstâncias) – Se você criar uma política baseada em recursos, deverá indicar a conta, o usuário, a função ou o usuário federado ao qual deseja permitir ou negar o acesso. Se estiver criando uma política de permissões do IAM 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.

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

  • Resource (Obrigatório apenas em algumas circunstâncias) – Se você criar uma política de permissões do IAM, deverá especificar uma lista de recursos aos quais as ações se aplicam. Se você criar uma política baseada em recursos, esse elemento será opcional. Se você não incluir esse elemento, o recurso ao qual a ação se aplica será o recurso ao qual a política está anexada.

  • Condition (Opcional) – Especifique 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

Para definir mais de uma permissão para uma entidade (usuário ou função), é possível usar várias instruções em uma única política. Você também pode 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 nessa instrução é "*" (o que significa "todos os recursos"). No entanto, na prática, a operação de API ChangePassword (ou o comando da CLI change-password equivalente) 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", "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.