O blog da AWS
Tipos de política do IAM: Como e quando usá-las
Diferentes tipos de política e quando usá-las
A AWS tem diferentes tipos de políticas que oferecem flexibilidade poderosa, e é importante saber como e quando usar cada uma delas. Também é importante que você entenda como estruturar as responsabilidades pelas políticas do IAM para evitar que uma equipe centralizada se torne um gargalo. A responsabilidade explícita da política pode permitir que suas equipes se movam mais rapidamente, enquanto permanecem dentro das barreiras de proteção seguras definidas de forma centralizada.
Visão geral sobre as SCPs
As políticas de controle de serviço (SCPs) são recursos do AWS Organizations. O AWS Organizations é um serviço para agrupar e gerenciar de forma centralizada as contas da AWS que sua empresa possui. SCPs são políticas que especificam as permissões máximas para uma organização, unidade organizacional (OU) ou conta individual. Uma SCP pode limitar as permissões para entidades principais em contas de membros, incluindo o usuário raiz da conta da AWS.
As SCPs devem ser usadas como barreiras de proteção de granularidade grossa e não para conceder acesso diretamente. A principal função das SCPs é impor invariantes de segurança em contas da AWS e OUs em uma organização. Invariantes de segurança são objetivos de controle ou configurações que você aplica a várias contas, OUs ou a toda a organização da AWS. Por exemplo, você pode usar uma SCP para impedir que contas de membros saiam da sua organização ou para garantir que os recursos da AWS só possam ser implantados em determinadas Regiões.
Visão geral dos limites de permissão
Os limites de permissões são um recurso avançado do IAM no qual você define o máximo de permissões que uma política baseada em identidade pode conceder a uma entidade principal do IAM. Quando você define um limite de permissões para uma entidade principal, essa entidade pode executar somente as ações permitidas por suas políticas baseadas em identidade e seus limites de permissões.
Um limite de permissões é um tipo de política baseada em identidade que não concede acesso diretamente. Em vez disso, como uma SCP, um limite de permissões atua como uma barreira de proteção para suas entidades principais do IAM permitindo que você defina controles de acesso de granularidade grossa. Normalmente, um limite de permissões é usado para delegar a criação de entidades principais do IAM. A delegação permite que outras pessoas em suas contas criem novas entidades principais do IAM, mas limita as permissões que podem ser concedidas às novas entidades principais do IAM.
Visão geral das políticas baseadas em identidade
Políticas baseadas em identidade são documentos de política que você anexa a uma entidade principal (role, usuários e grupos de usuários) para controlar quais ações uma entidade principal pode executar, em quais recursos e sob quais condições. As políticas baseadas em identidade podem ser categorizadas em políticas gerenciadas pela AWS, políticas gerenciadas pelo cliente e políticas em linha. As políticas gerenciadas pela AWS são políticas baseadas em identidade reutilizáveis que são criadas e gerenciadas pela AWS. Você pode usar as políticas gerenciadas pela AWS como ponto de partida para criar suas próprias políticas baseadas em identidade específicas para sua organização. As políticas gerenciadas pelo cliente são políticas reutilizáveis baseadas em identidade que podem ser anexadas a várias identidades. As políticas gerenciadas pelo cliente são úteis quando você tem várias entidades principais com requisitos de acesso idênticos. As políticas em linha (Inline policies) são políticas baseadas em identidade anexadas a uma única entidade principal. Use políticas em linha quando quiser criar permissões de privilégios mínimos que sejam específicas para determinada entidade principal.
Você terá muitas políticas baseadas em identidade em sua conta da AWS que são usadas para habilitar o acesso em cenários como acesso humano, acesso por aplicações, workloads de machine learning e pipelines de implantação. Essas políticas devem ser refinadas e usadas para aplicar diretamente as permissões de privilégio mínimo às suas entidades principais do IAM. Você deve escrever as políticas com permissões para a tarefa específica que a entidade principal precisa realizar.
Visão geral das políticas baseadas em recursos
Políticas baseadas em recursos são documentos de política que você anexa a um recurso, como um bucket do S3. Essas políticas concedem à entidade principal especificada permissão para executar ações específicas nesse recurso e definir sob quais condições essa permissão se aplica. As políticas baseadas em recursos são políticas em linha. Para obter uma lista de serviços da AWS que oferecem suporte a políticas baseadas em recursos, consulte Serviços da AWS que funcionam com o IAM.
As políticas baseadas em recursos são opcionais para muitos workloads que não abrangem várias contas da AWS. O acesso refinado em uma única conta da AWS geralmente é concedido com políticas baseadas em identidade. Chaves do AWS Key Management Service (AWS KMS) e políticas de confiança do perfil do IAM são duas exceções, e esses dois recursos devem ter uma política baseada em recursos mesmo quando a entidade principal e a chave do KMS ou o perfil do IAM estiverem na mesma conta. Os perfis do IAM e as chaves do KMS se comportam dessa maneira como uma camada extra de proteção que exige que o proprietário do recurso (chave ou role) permita ou negue explicitamente que as entidades principais usem o recurso. Para outros recursos que oferecem suporte a políticas baseadas em recursos, aqui estão alguns casos de uso em que são mais comumente usados:
- Conceder acesso ao bucket entre contas a um perfil específico do IAM.
- Conceder a um serviço da AWS acesso ao seu recurso quando o serviço da AWS usar uma entidade principal de serviço da AWS. Por exemplo, ao usar o AWS CloudTrail, você deve conceder explicitamente à entidade principal do serviço do CloudTrail acesso para gravar arquivos em um bucket do Amazon S3.
- Aplicação de amplas barreiras de proteção de acesso aos seus recursos da AWS. Você pode ver alguns exemplos na publicação do blog O IAM facilita o gerenciamento de permissões para serviços da AWS que acessam seus recursos.
- Aplicação de uma camada adicional de proteção para recursos que armazenam dados confidenciais, como segredos do AWS Secrets Manager ou um bucket do S3 com dados confidenciais. Você pode usar uma política baseada em recursos para negar acesso a entidades principais do IAM que não deveriam ter acesso a dados confidenciais, mesmo que concedido acesso por uma política baseada em identidade. Uma negação explícita em uma política do IAM sempre substitui uma permissão.
Como implementar diferentes tipos de políticas
Nesta seção, mostraremos um exemplo de um projeto que inclui os quatro tipos de política explicados nesta publicação.
O exemplo a seguir mostra uma aplicação executada em uma instância do Amazon Elastic Compute Cloud (Amazon EC2), que precisa ler e gravar arquivos em um bucket do S3 na mesma conta. A aplicação também lê (mas não grava) arquivos de um bucket do S3 em uma conta diferente. A empresa neste exemplo, a Example Corp, usa uma estratégia de várias contas e cada aplicação tem sua própria conta da AWS. A arquitetura da aplicação é mostrada na Figura 1.
Figura 1: Exemplo de arquitetura de aplicação que precisa acessar buckets do S3 em duas contas diferentes da AWS
Há três equipes que participam deste exemplo: a equipe de cloud, a equipe de aplicações e a equipe de data lake. A equipe de cloud é responsável pela segurança e governança gerais do ambiente da AWS em todas as contas da AWS na Example Corp. A equipe de aplicações é responsável por criar, implantar e executar a aplicação na conta (111111111111) que possuem e gerenciam. Da mesma forma, a equipe do Data Lake possui e gerencia a conta do data lake (222222222222) que hospeda um data lake na Example Corp.
Com esse histórico em mente, orientaremos você em uma implementação para cada um dos quatro tipos de política e incluiremos uma explicação de qual equipe recomendamos que seja proprietária de cada política. O proprietário da política é também a equipe responsável por cria-la e mantê-la.
Políticas de controle de serviço
A equipe de cloud é proprietária da implementação dos controles de segurança que devem ser aplicados amplamente a todas as contas da AWS da Example Corp. Na Example Corp, a equipe de cloud tem dois requisitos de segurança que querem aplicar a todas as contas em sua organização:
- Todas as chamadas de API da AWS devem ser criptografadas em trânsito.
- As contas não podem sair da organização por conta própria.
A equipe de cloud opta por implementar essas invariantes de segurança usando SCPs e aplica as SCPs à raiz da organização. A primeira declaração na Política 1 nega todas as solicitações que não são enviadas usando SSL (TLS). A segunda declaração na Política 1 impede que uma conta saia da organização.
Este é apenas um subconjunto das instruções SCP que a Example Corp usa. A Example Corp usa uma estratégia de lista de negação, e também deve haver uma declaração de acompanhamento com um efeito de permissão em todos os níveis da organização que não é mostrado na SCP na Política 1.
Política 1: SCP anexada à raiz da organização do AWS Organizations
Políticas de limite de permissões
A equipe de cloud quer garantir que eles não se tornem um gargalo para a equipe de aplicações. Eles querem permitir que a equipe de aplicações implante suas próprias entidades principais e políticas do IAM às aplicações. A equipe de cloud também quer garantir que todas as entidades principais criadas pela equipe de aplicações só possam usar APIs da AWS aprovadas pela equipe de cloud.
Na Example Corp, a equipe de aplicações faz a implantação no ambiente de produção da AWS por meio de um pipeline de integração contínua/implantação contínua (CI/CD). O pipeline em si tem amplo acesso para criar recursos da AWS necessários para executar aplicações, incluindo permissões para criar perfis adicionais do IAM. A equipe de cloud implementa um controle que exige que todos os perfis do IAM criados pelo pipeline tenham um limite de permissões anexado. Isso permite que o pipeline crie perfis adicionais do IAM, mas limita as permissões que os perfis recém-criados podem ter ao que é permitido pelo limite de permissões. Essa delegação atinge um equilíbrio para a equipe de cloud. Eles podem evitar se tornar um gargalo para a equipe de aplicações, permitindo que a equipe de aplicações crie seus próprios perfis e políticas do IAM garantindo que esses perfis e políticas do IAM não sejam excessivamente privilegiadas.
Um exemplo da política de limite de permissões que a equipe de cloud anexa aos perfis do IAM criados pelo pipeline de CI/CD é mostrado abaixo. Essa mesma política de limite de permissões pode ser gerenciada centralmente e anexada aos perfis do IAM criados por outros pipelines na Example Corp. A política descreve o máximo de permissões possíveis que perfis adicionais criados pela equipe de aplicações podem ter e limita essas permissões a algumas ações de acesso a dados do Amazon S3 e do Amazon Simple Queue Service (Amazon SQS). É comum que uma política de limite de permissões inclua ações de acesso a dados quando usada para delegar a criação de role. Isso ocorre porque a maioria das aplicações só precisa de permissões para ler e gravar dados (por exemplo, gravar um objeto em um bucket do S3 ou ler uma mensagem de uma fila do SQS) e só às vezes precisa de permissão para modificar a infraestrutura (por exemplo, criar um bucket do S3 ou excluir uma fila do SQS). À medida que a Example Corp adota serviços adicionais da AWS, a equipe de cloud atualiza esse limite de permissões com ações desses serviços.
Política 2: política de limite de permissões anexada aos perfis do IAM criados pelo pipeline de CI/CD
Na próxima seção, você aprenderá a impor que esse limite de permissões seja anexado aos perfis do IAM criados pelo pipeline de CI/CD.
Políticas baseadas em identidade
Neste exemplo, as equipes da Example Corp só podem modificar o ambiente de produção da AWS por meio de seu pipeline de CI/CD. O acesso de gravação ao ambiente de produção não é permitido de outra forma. Para oferecer suporte às diferentes personas que precisam ter acesso a uma conta de aplicação na Example Corp, três perfis básicos do IAM com políticas baseadas em identidade são criados nas contas da aplicação:
- Uma role a ser usada pelo pipeline de CI/CD para implantar recursos de aplicações.
- Uma role somente leitura para a equipe de cloud, com um processo para acesso elevado temporário.
- Uma role somente leitura para membros da equipe de aplicações.
Todas essas baselines de roles são de propriedade, gerenciamento e implantação da equipe de cloud.
A equipe de cloud recebe uma role somente leitura por padrão (CentralCloudTeamReadOnlyRole) que permite acesso de leitura a todos os recursos da conta. Isso é feito anexando a política ReadOnlyAccess gerenciada pela AWS à role da equipe de cloud. Você pode usar o console do IAM para anexar a política ReadOnlyAccess, que concede acesso somente leitura a todos os serviços. Quando um membro da equipe precisa executar uma ação que não é coberta por esta política, ele segue um processo temporário de acesso elevado para garantir que esse acesso seja válido e registrado.
Uma role somente leitura também é dada aos desenvolvedores da equipe de aplicações (DeveloperReadOnlyRole) para análise e resolução de problemas. Na Example Corp, os desenvolvedores podem ter acesso somente leitura ao Amazon EC2, Amazon S3, Amazon SQS, AWS CloudFormation e Amazon CloudWatch. Seus requisitos para acesso somente leitura podem ser diferentes. Vários serviços da AWS oferecem suas próprias políticas gerenciadas somente leitura, e há também a política ReadOnlyAccess gerenciada pela AWS, mencionada anteriormente, que concede acesso somente leitura a todos os serviços. Para personalizar o acesso somente leitura em uma política baseada em identidade, você pode usar as políticas gerenciadas pela AWS como ponto de partida e limitar as ações aos serviços que sua organização usa. A política personalizada baseada em identidade para a role DeveloperReadOnlyRole da Example Corp é mostrada abaixo.
Política 3: política baseada em identidade anexada a uma role somente leitura de desenvolvedor para dar suporte ao acesso humano e à solução de problemas
A role do pipeline de CI/CD tem amplo acesso à conta para criar recursos. O acesso para implantação por meio do pipeline de CI/CD deve ser rigorosamente controlado e monitorado. O pipeline de CI/CD tem permissão para criar novos perfis do IAM para uso com a aplicação, mas essas roles são limitadas apenas às ações permitidas pelo limite de permissões discutido anteriormente. As roles, políticas e perfis de instância do EC2 que o pipeline cria também devem ser restritos a caminhos de role específicos. Isso permite que você imponha que o pipeline só possa modificar roles e políticas ou passar roles que ele criou. Isso ajuda a impedir que o pipeline e as roles criadas pelo pipeline aumentem os privilégios modificando ou aprovando uma roles mais privilegiada. Preste muita atenção à role e aos caminhos da política no elemento Resource da seguinte política de role do pipeline de CI/CD (Política 4). A política de role do pipeline de CI/CD também fornece alguns exemplos de declarações que permitem a passagem e a criação de um conjunto limitado de roles vinculadas ao serviço (que são criadas no caminho /aws-service-role/). Você pode adicionar outras roles vinculadas a serviços a essas declarações à medida que sua organização adota serviços adicionais da AWS.
Política 4: política baseada em identidade anexada à role do pipeline de CI/CD
Além dos três baselines de roles com políticas baseadas em identidade que você viu até agora, há perfil adicional do IAM que a equipe de aplicações cria usando o pipeline de CI/CD. Essa é a role que a aplicação em execução na instância do EC2 usará para obter e colocar objetos dos buckets do S3 na figura 1. A propriedade explícita permite que a equipe de aplicações crie essa política baseada em identidade que atenda às suas necessidades sem ter que esperar e depender da equipe de cloud. Como o pipeline de CI/CD só pode criar roles que tenham a política de limite de permissões anexada, a Política 5 não pode conceder mais acesso do que a política de limite de permissões permite (Política 2).
Se você comparar a política baseada em identidade anexada à role da instância do EC2 (Política 5 à esquerda) com a política de limite de permissões descrita anteriormente (Política 2 à direita), poderá ver que as ações permitidas pela role da instância do EC2 também são permitidas pela política de limite de permissões. As ações devem ser permitidas por ambas as políticas para que a instância do EC2 realize as ações s3:GetObject e s3:PutObject. O acesso para criar um bucket seria negado mesmo se a role anexada à instância do EC2 recebesse permissão para executar a ação s3:CreateBucket porque a ação s3:CreateBucket excede as permissões permitidas pelo limite de permissões.
| Política 5: política baseada em identidade vinculada pelo limite de permissões e anexada à instância do EC2 da aplicação | Política 2: política de limite de permissões anexada aos perfis do IAM criados pelo pipeline de CI/CD. |
Políticas baseadas em recursos
A única política baseada em recursos necessária neste exemplo é anexada ao bucket na conta externa à conta da aplicação (DOC-EXAMPLE-BUCKET2 na conta do data lake na Figura 1). Tanto a política baseada em identidade quanto a política baseada em recursos devem conceder acesso a uma ação no bucket do S3 para que o acesso seja permitido em um cenário entre contas. A política de bucket abaixo só permite que a ação GetObject seja executada no bucket, independentemente de quais permissões a role da aplicação (ApplicationRole) recebe de sua política baseada em identidade (Política 5).
Essa política baseada em recursos pertence à equipe do Data Lake que possui e gerencia a conta do data lake (222222222222) e a política (Política 6). Isso permite que a equipe do Data Lake tenha controle total sobre quais equipes externas à sua conta da AWS podem acessar seu bucket do S3.
Política 6: política baseada em recursos anexada ao bucket do S3 na conta do data lake externo (222222222222)
Nenhuma política baseada em recursos é necessária no bucket do S3 na conta da aplicação (DOC-EXAMPLE-BUCKET1 na figura 1). O acesso à aplicação é concedido ao bucket do S3 na conta da aplicação pela própria política baseada em identidade. O acesso pode ser concedido por uma política baseada em identidade ou por uma política baseada em recursos quando o acesso estiver dentro da mesma conta da AWS.
Juntando tudo
A figura 2 mostra a arquitetura e inclui as sete políticas diferentes e os recursos aos quais estão vinculadas. A tabela a seguir resume as várias políticas do IAM implantadas no ambiente da AWS da Example Corp e especifica qual equipe é responsável por cada uma das políticas.
Figura 2: Exemplo de arquitetura de aplicação com pipeline de CI/CD usado para implantar a infraestrutura
As políticas descritas na figura 2 correspondem aos números da política na tabela a seguir.
| Número da política | Descrição da política | Tipo de política | Proprietário da política | Anexado a |
| 1 | Imponha SSL e evite que contas de membros saiam da organização para todas as entidades principais da organização | Política de controle de serviços (SCP) | Equipe de cloud | Raiz da organização |
| 2 | Restringir o máximo de permissões para roles criadas pelo pipeline de CI/CD | Limite de permissões | Equipe de cloud | Todas as roles criadas pelo pipeline (ApplicationRole) |
| 3 | Política somente leitura com escopo | Política baseada em identidade | Equipe de cloud | Perfil do IAM DeveloperReadOnlyRole |
| 4 | Política de pipeline de CI/CD | Política baseada em identidade | Equipe de cloud | Perfil do IAM CICDPipelineRole |
| 5 | Política usada ao executar a aplicação para ler e gravar em buckets do S3 | Política baseada em identidade | Equipe de aplicação | ApplicationRole na instância do EC2 |
| 6 | Política de bucket na conta do data lake que concede acesso a uma role na conta da aplicação | Política baseada em recursos | Equipe de data lake | Bucket do S3 na conta do data lake |
| 7 | Política ampla de somente leitura | Política baseada em identidade | Equipe de cloud | Perfil do IAM CentralCloudTeamReadonlyRole |
Conclusão
Nesta publicação do blog, você aprendeu sobre quatro tipos diferentes de política: políticas baseadas em identidade, políticas baseadas em recursos, políticas de controle de serviço (SCPs) e políticas de limite de permissões. Você viu exemplos de situações em que cada tipo de política é comumente aplicado. Depois, você passou por um exemplo real que descreve uma implementação que usa esses tipos de política.
Você pode usar esta publicação do blog como ponto de partida para desenvolver a estratégia de IAM da sua organização. Você pode decidir que não precisa de todos os tipos de política explicados nesta publicação, e tudo bem. Nem toda organização precisa usar todos os tipos de política. Talvez seja necessário implementar políticas de forma diferente em um ambiente de produção do que em um ambiente de área restrita para testes. Os conceitos importantes a serem retirados desta publicação são as situações em que cada tipo de política é aplicável e a importância da propriedade explícita da política. Também recomendamos aproveitar a validação de políticas no AWS IAM Access Analyzer ao escrever políticas do IAM para validar suas políticas em relação à gramática e às práticas recomendadas da política do IAM.
Para obter mais informações, incluindo as políticas descritas nesta solução e o exemplo da aplicação, consulte o repositório do GitHub how-and-when-to-use-aws-iam-policy-blog-samples. O repositório mostra um exemplo de implementação usando um pipeline de CI/CD com o AWS CodePipeline.
Se você tiver alguma dúvida, publique-a no tópico re:Post do AWS Identity and Access Management ou entre em contato com o AWS Support.
Este artigo foi traduzido do Blog da AWS em Inglês.
Sobre os autores
Matt Luttrell é um Arquiteto de Soluções Senior no time de Soluções de Identidade da AWS. Quando ele não dedica tempo para correr atrás dos filhos, ele gosta de esquiar, andar de bicicleta e jogar vídeo game ocasionalmente.