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

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

Gerencie o acesso na AWS criando políticas e anexando-as a identidades do IAM (usuários, grupos de usuários ou perfis) ou a recursos da AWS. Uma política é um objeto na AWS que, quando associado a uma identidade ou um recurso, define suas permissões. A AWS avalia essas políticas quando uma entidade de segurança 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 são armazenadas na AWS como documentos JSON. A AWS oferece suporte a seis tipos de políticas: políticas baseadas em identidade, políticas baseadas em recursos, limites de permissões, políticas de controle de serviços (SCP) do Organizations, listas de controle de acesso (ACL) e políticas de sessão.

As políticas do IAM definem permissões para uma ação independente do método usado 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 poderá fazer login nele usando suas credenciais. 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 do usado com mais frequência a menos usado, 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 (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 entidades principais podem ser na mesma conta como o recurso ou em outras contas.

  • Limites de permissões: use uma política gerenciada como o 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 do Organizations: 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 entidades de segurança 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çadas ao 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

As 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 realizar, em quais recursos e em que condições. As políticas baseadas em identidade podem ser categorizadas em:

  • Políticas gerenciadas: políticas autônomas baseadas em identidade que você pode anexar a vários usuários, grupos e perfis na 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 na 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 adicionadas diretamente a um único usuário, grupo ou função. As políticas em linha mantêm um relacionamento estrito de um para um 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 políticas em linha.

Políticas baseadas no recurso

Políticas baseadas em recurso 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. As políticas baseadas em recurso são políticas em linha. Não há políticas baseadas em recurso gerenciadas.

Para permitir o acesso entre contas, você pode especificar uma conta inteira ou as entidades do IAM em outra conta como a entidade principal em uma política baseada em atributo. Adicionar uma entidade 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 da AWS separadas, também será necessário usar uma política baseada em identidade para conceder o acesso a essa entidade principal para o recurso. No entanto, se uma política baseada em recurso conceder acesso a uma entidade principal na mesma conta, nenhuma política baseada em identidade adicional será necessária. Para obter instruções detalhadas sobre a concessão de 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 diferem de outras políticas baseadas em recurso, consulte Acesso a recursos entre contas no IAM.

Para ver quais outros serviços oferecem suporte a políticas baseadas em recurso, consulte Serviços da AWS que funcionam com o IAM. Para saber mais sobre as políticas baseadas em recursos, consulte Políticas baseadas em identidade e em recurso. Para saber se as entidades 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 é o 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 entidades principais não são limitadas pelo limite de permissões. Porém, se as políticas baseadas em recurso especificarem o perfil como a entidade principal, elas estarão sujeitas ao 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 a sua empresa possui. Se você habilitar todos os atributos em uma organização, poderá aplicar políticas de controle de serviço (SCPs) a qualquer uma ou a todas as 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, o que inclui 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 Organizations e SCPs, consulte Service control policies 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 entidades 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 oferecem compatibilidade com ACLs. Para saber mais sobre 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 são a interseção das políticas baseadas em identidade para a entidade (usuário ou função) do IAM usada para criar a sessão e as políticas da sessão. As permissões também podem ser provenientes de uma política baseada em atributo. 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 Permissões de credenciais de segurança temporárias.

Quando você criar uma sessão de usuário federado, use as 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 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 Solicitar credenciais por meio de um intermediador 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 das políticas baseadas em recurso, mais a interseção das políticas de sessão e das 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 de segurança em uma política baseada em recurso ou uma ACL. Um usuário raiz ainda é o membro de uma conta. Se essa conta for membro de uma organização no AWS Organizations, o usuário raiz será afetado por quaisquer SCPs da conta.

Visão geral das políticas de JSON

A maioria das políticas é armazenada 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 recursos 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 Defina permissões personalizadas do IAM com políticas gerenciadas pelo cliente e Editar políticas do IAM.

Quando você cria ou edita uma política JSON, o IAM pode executar a validação de políticas para ajudar você a criar uma política eficaz. O IAM identifica erros de sintaxe JSON, enquanto o IAM Access Analyzer fornece verificações de políticas adicionais com recomendações para ajudar você a refinar ainda mais suas políticas. Para saber mais sobre validação de política, consulte Validação de política do IAM. Para saber mais sobre as verificações de política do IAM Access Analyzer e as recomendações práticas, 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 do idioma da política que deseja usar. É recomendável usar a versão 2012-10-17 mais recente. Para ter mais informações, consulte Elementos de política JSON do IAM: Version.

  • 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 recurso, deverá indicar a conta, o usuário, a função ou o usuário federado ao qual deseja permitir ou negar 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: inclua 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 elemento 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 ou função), você poderá 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. É recomendável dividir 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 na sua Conta da AWS. O elemento Resource nessa instrução é "*" (o que significa "todos os recursos"). Porém, como as políticas não concedem acesso aos recursos em outras contas, o usuário pode listar somente os buckets na 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 amzn-s3-demo-bucket-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 amzn-s3-demo-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:::amzn-s3-demo-bucket-confidential-data", "arn:aws:s3:::amzn-s3-demo-bucket-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 de segurança implícita liste um único bucket do Amazon S3 chamado amzn-s3-demo-bucket:

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::amzn-s3-demo-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 da AWS específica execute qualquer ação do Amazon S3 no bucket denominado amzn-s3-demo-bucket. 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:root"]}, "Action": "s3:*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket", "arn:aws:s3:::amzn-s3-demo-bucket/*" ] }] }

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

Conceder privilégio mínimo

Ao criar políticas do IAM, siga a orientação de segurança padrão de concessão de privilégio mínimo ou conceda apenas as permissões necessárias para realizar uma tarefa. Determine o que os usuários e as funções precisam fazer e, em seguida, crie políticas que permitam que eles executem apenas essas tarefas.

Comece com um conjunto mínimo de permissões e conceda permissões adicionais conforme necessário. Fazer isso é mais seguro do que começar com permissões que são muito lenientes e tentar restringi-las superiormente.

Como alternativa ao privilégio mínimo, você pode usar políticas gerenciadas pela AWS ou políticas com permissões com curinga * para iniciar as políticas. Considere o risco de segurança de conceder às suas entidades de segurança mais permissões do que elas precisam para realizar um trabalho. Monitore esses entidades de segurança para saber quais permissões elas estão usando. Em seguida, escreva políticas de privilégio mínimos.

O IAM fornece várias opções para ajudar você a refinar as permissões concedidas.

  • Compreender agrupamentos de nível de acesso: você pode usar agrupamentos no nível de acesso para entender o nível de acesso que a política concede. As ações da política são classificadas como List, Read, Write, Permissions management ou Tagging. Por exemplo, você pode escolher ações dos níveis de acesso List e Read para conceder acesso somente leitura a seus usuários. Para saber como usar resumos de políticas para entender as permissões no nível de acesso, consulte Níveis de acesso em resumos de política.

  • Validar suas políticas: você pode executar a validação de políticas usando o IAM Access Analyzer ao criar e editar políticas de JSON. Recomendamos que você revise e valide todas as políticas existentes. O IAM Access Analyzer fornece mais de 100 verificações de política para validar suas políticas. Ele gera avisos de segurança quando uma instrução em sua política permite o acesso que consideramos excessivamente permissivo. Você pode usar as recomendações práticas fornecidas por meio dos avisos de segurança à medida que trabalha para conceder privilégios mínimos. Para saber mais sobre as verificações de política fornecidas pelo IAM Access Analyzer, consulte Validação da política do IAM Access Analyzer.

  • Gerar uma política com base na atividade de acesso: para ajudar você a refinar as permissões que você concede, gere uma política do IAM baseada na atividade de acesso de uma entidade do IAM (usuário ou função). O IAM Access Analyzer revisa seus logs do AWS CloudTrail e gera um modelo de política que contém as permissões que foram usadas pela entidade no período especificado. Você pode usar o modelo para criar uma política gerenciada com permissões refinadas e anexá-la à entidade do IAM. Dessa forma, você concede apenas as permissões de que o usuário ou a função precisa para interagir com os recursos da AWS para seu caso de uso específico. Para saber mais, consulte Geração de políticas do IAM Access Analyzer.

  • Usar as informações do último acesso: outro recurso que pode ajudar com privilégios mínimos são as informações do último acesso. Visualize essas informações na guia Access Advisor (Consultor de acesso) na página de detalhes do console do IAM de um usuário, um grupo, uma função ou uma política do IAM. As informações do último acesso também incluem informações sobre as ações que foram acessadas pela última vez para alguns serviços, como Amazon EC2, IAM, Lambda e Amazon S3. Se você fizer login usando credenciais da conta de gerenciamento do AWS Organizations, poderá visualizar as informações do último acesso ao serviço na seção AWS Organizations do console do IAM. Você também pode usar a AWS CLI ou a API da AWS para recuperar um relatório das informações acessadas por último de entidades ou políticas no IAM ou no Organizations. Você pode usar essa informação para identificar permissões desnecessárias, de forma que você possa refinar suas políticas do IAM ou do Organizations para melhor aderir ao princípio de privilégio mínimo. Para ter mais informações, consulte Refinar permissões na AWS usando informações do último acesso.

  • Revisar eventos da conta no AWS CloudTrail: para reduzir ainda mais as permissões, você pode visualizar os eventos da sua conta em AWS CloudTrail Event history (Histórico do evento). Os logs de eventos do CloudTrail incluem informações de eventos detalhadas que você pode usar para reduzir as permissões da política. Os logs incluem apenas as ações e os recursos de que suas entidades do IAM precisam. Para obter mais informações, consulte Visualizar eventos do CloudTrail no console do CloudTrail no Guia do usuário do AWS CloudTrail.

Para obter mais informações, consulte os tópicos de políticas para serviços individuais a seguir, os quais fornecem exemplos de como gravar políticas para recursos específicos do serviço.