Entendendo os tipos de políticas de IAM
O controle de acesso na AWS é baseado na criação e anexação de políticas a entidades do AWS Identity and Access Management (IAM) — como funções (roles), usuários ou grupos de usuários — ou diretamente aos recursos. A AWS avalia essas políticas quando um principal do IAM faz uma requisição, como enviar um objeto para um bucket do Amazon S3. As permissões definidas determinam se a requisição é permitida ou negada.
Embora o IAM funcione principalmente no nível de uma conta AWS individual, organizações com múltiplas contas podem estender esses controles através do AWS Organizations, que oferece tipos de políticas adicionais para aplicar padrões de governança e segurança em toda a estrutura organizacional. Isso permite agrupar contas em unidades organizacionais (OUs) e aplicar controles baseados em políticas.
Compreender qual tipo de política usar — e quem na sua organização deve possuir e gerenciar cada uma — é essencial para evitar gargalos centralizados e manter um modelo de segurança flexível mas controlado.
Os principais tipos de políticas
Políticas de Controle de Serviço (SCPs)
As Políticas de Controle de Serviço (SCPs) são um recurso do AWS Organizations. Elas especificam as permissões máximas para uma organização, unidade organizacional ou conta individual, funcionando como guardrails de segurança em escala ampla.
As SCPs não concedem acesso diretamente; em vez disso, limitam o que pode ser feito. Sua principal função é impor invariantes de segurança — objetivos ou configurações de controle que você aplica a múltiplas contas ou a toda a organização. Por exemplo, você pode usar uma SCP para impedir que contas membros saiam da organização ou garantir que recursos AWS sejam implantados apenas em regiões específicas.
As SCPs são ideais para aplicar controles amplos que atravessam toda a sua infraestrutura de nuvem, sendo gerenciadas por equipes centrais de segurança e governança.
Políticas de Controle de Recursos (RCPs)
As Políticas de Controle de Recursos (RCPs) são outro recurso do AWS Organizations que permite gerenciar permissões de forma centralizada, mas com foco nos recursos. As RCPs estabelecem as permissões máximas disponíveis para recursos em sua organização, ajudando a garantir que os recursos nas suas contas permaneçam dentro das diretrizes de controle de acesso da sua organização.
As RCPs são tipicamente utilizadas para implementar controles de perímetro de dados, prevenindo compartilhamento acidental fora da organização, e para controlar padrões de acesso entre contas. Elas também adicionam uma camada de proteção extra para recursos sensíveis, como buckets S3 que armazenam dados confidenciais.
Uma diferença importante: enquanto as SCPs são focadas no principal (qual usuário ou função pode fazer algo), as RCPs são focadas no recurso (quem pode acessar este recurso e sob quais condições). Para explorar melhor essas distinções, veja casos de uso gerais para SCPs e RCPs.
Limites de Permissões
Os Limites de Permissões são um recurso avançado do IAM que define o máximo que uma política baseada em identidade pode conceder a um principal. Quando você estabelece um limite para um principal, ele pode realizar apenas as ações permitidas tanto pela sua política baseada em identidade quanto pelo limite.
Como as SCPs, os limites de permissões não concedem acesso diretamente — eles atuam como guardrails. São frequentemente usados para delegar a criação de principais do IAM, permitindo que outras equipes criem novos usuários e funções, mas limitando quais permissões podem ser concedidas a esses novos principais.
Políticas Baseadas em Identidade
As Políticas Baseadas em Identidade são documentos de política anexados a um principal (funções, usuários e grupos) para controlar quais ações podem ser executadas, em quais recursos e sob quais condições. Elas se dividem em três categorias:
- Políticas gerenciadas pela AWS: políticas reutilizáveis criadas e mantidas pela AWS, que servem como ponto de partida para políticas específicas da sua organização.
- Políticas gerenciadas pelo cliente: políticas reutilizáveis criadas por você que podem ser anexadas a múltiplas identidades, úteis quando vários principals têm os mesmos requisitos de acesso.
- Políticas inline: políticas anexadas a um único principal, ideais quando você quer criar permissões com privilégio mínimo específicas para um principal em particular.
Políticas Baseadas em Recursos
As Políticas Baseadas em Recursos são anexadas a um recurso como um bucket S3. Elas concedem permissão a um principal específico para executar ações específicas naquele recurso e definem sob quais condições isso se aplica. Ao contrário de muitos outros tipos de política, as baseadas em recursos são sempre inline.
Embora sejam opcionais para muitas cargas de trabalho que não abrangem múltiplas contas, existem exceções importantes. O AWS Key Management Service (AWS KMS) e as políticas de confiança de funções do IAM exigem políticas baseadas em recursos mesmo quando o principal e o recurso estão na mesma conta, como camada extra de proteção.
As políticas baseadas em recursos são mais comumente usadas para conceder acesso entre contas, para permitir que serviços AWS acessem seus recursos (como quando o AWS CloudTrail precisa de permissão explícita para escrever em um bucket S3), e para adicionar camadas de proteção extra em recursos com dados sensíveis.
Implementando diferentes tipos de políticas: um exemplo prático
Para ilustrar como esses tipos de políticas trabalham juntos, consideremos uma empresa fictícia chamada Example Corp que utiliza uma estratégia multi-conta, com cada aplicação rodando em sua própria conta AWS. A aplicação está em execução em um Amazon EC2 e precisa ler e escrever em um bucket S3 na mesma conta, além de ler arquivos de um bucket em uma conta diferente.
Três equipes participam deste exemplo: a Equipe Central de Nuvem (responsável pela segurança geral), a Equipe de Aplicação (que constrói e executa a aplicação) e a Equipe de Data Lake (que gerencia a conta de data lake). Cada equipe possui responsabilidades claras sobre qual tipo de política gerencia.
Exemplo 1: Políticas de Controle de Serviço (SCP)
A Equipe Central de Nuvem implementa SCPs na raiz da organização para aplicar dois requisitos de segurança em todas as contas: todas as chamadas de API devem ser criptografadas em trânsito e nenhuma conta pode deixar a organização por conta própria. Essas SCPs atuam como guardrails organizacionais que evitam desvios de segurança em qualquer ponto da infraestrutura.
Exemplo 2: Políticas de Controle de Recursos (RCP)
A Equipe Central de Nuvem também aplica RCPs para impor três controles adicionais em recursos S3: exigir TLS versão 1.2 ou superior, usar criptografia de objetos com AWS KMS, e negar acesso de contas fora da organização. Essas políticas implementam um perímetro de dados em toda a organização, protegendo dados sensíveis de compartilhamento acidental.
Exemplo 3: Limites de Permissões
A Equipe de Aplicação implanta através de um pipeline de integração contínua/implantação contínua (CI/CD). Para evitar que a Equipe Central fique sobrecarregada de requisições, o pipeline recebe permissões amplas para criar recursos, mas as funções do IAM que cria devem ter um limite de permissões anexado. Esse limite restringe quais ações essas novas funções podem executar, mesmo que o pipeline tentasse dar permissões muito amplas.
O limite típico permite ações de acesso a dados em Amazon SQS, S3 e logs, mas não permite ações de modificação de infraestrutura. Quando a Example Corp adota novos serviços AWS, a Equipe Central atualiza centralmente esse limite de permissões.
Exemplo 4: Políticas Baseadas em Identidade
A Equipe Central de Nuvem cria três funções baseline na conta de aplicação: uma para o pipeline CI/CD (com acesso amplo para criar recursos), uma para a própria Equipe Central (com acesso somente leitura a todos os recursos, com um processo de elevação temporária quando necessário), e uma para desenvolvedores da Equipe de Aplicação (com acesso somente leitura limitado a EC2, S3, SQS, CloudFormation e CloudWatch).
A função do pipeline CI/CD tem permissões para criar novas funções do IAM dentro de caminhos específicos, e pode anexar políticas específicas a essas funções, mas apenas políticas dentro de caminhos aprovados. Isso impede que o pipeline modifique funções mais privilegiadas ou se auto-escalone.
A Equipe de Aplicação cria suas próprias políticas baseadas em identidade para a função que roda na instância EC2, respeitando o limite de permissões. Se a política tentasse incluir ações não permitidas pelo limite, essas ações seriam negadas.
Exemplo 5: Políticas Baseadas em Recursos
O único recurso que requer uma política baseada em recurso neste exemplo é o bucket S3 na conta external (conta de data lake). Essa política, gerenciada pela Equipe de Data Lake, especifica explicitamente qual função em qual conta externa pode fazer quê. Isso garante que a Equipe de Data Lake mantém total controle sobre quem acessa seus dados, mesmo que a Equipe de Aplicação tivesse permissões mais amplas.
Em cenários de acesso entre contas, tanto a política baseada em identidade quanto a política baseada em recurso precisam permitir a ação para que o acesso seja concedido. O bucket na conta de aplicação não precisa de uma política baseada em recurso, pois o acesso é concedido pela política baseada em identidade.
Estrutura de propriedade de políticas
Um aspecto crítico da implementação bem-sucedida é deixar claro quem é responsável por cada tipo de política. Na Example Corp, a distribuição é:
- SCPs e RCPs: Equipe Central de Nuvem (aplicadas na raiz da organização)
- Limites de Permissões: Equipe Central de Nuvem (aplicados ao pipeline)
- Políticas Baseadas em Identidade para acesso de equipes: Equipe Central de Nuvem
- Políticas Baseadas em Identidade para aplicações: Equipe de Aplicação (dentro dos limites)
- Políticas Baseadas em Recursos: Equipe proprietária do recurso (Equipe de Data Lake)
Essa distribuição evita que a Equipe Central se torne um gargalo, ao mesmo tempo em que mantém guardrails de segurança centralizados.
Validação e boas práticas
Ao implementar políticas de IAM, a AWS oferece ferramentas para garantir qualidade. A validação de políticas no AWS IAM Access Analyzer permite validar suas políticas contra a gramática do IAM e melhores práticas, evitando configurações que possam causar problemas de segurança ou acesso.
Para explorar mais detalhes sobre implementações como essa, consulte o repositório how-and-when-to-use-aws-iam-policy-blog-samples, que demonstra uma implementação de exemplo usando AWS CodePipeline.
Conclusão
A segurança robusta em ambientes AWS multi-conta requer uma abordagem em camadas, usando diferentes tipos de políticas em conjunto. As SCPs e RCPs fornecem guardrails organizacionais, os limites de permissões delegam autoridade sem perder controle, e as políticas baseadas em identidade e recurso permitem acesso fino e controlado.
Nem todas as organizações precisam usar todos esses tipos de políticas, e os requisitos podem variar entre ambientes de produção e sandbox. O importante é compreender quando cada tipo é apropriado e estruturar claramente a propriedade das políticas. Com essa abordagem, você consegue um modelo de segurança que é ao mesmo tempo flexível e seguro, permitindo que equipes se movam rapidamente dentro de guardrails bem definidos.
Para mais informações, consulte o tópico AWS Identity and Access Management re:Post ou entre em contato com o AWS Support.
Fonte
IAM policy types: How and when to use them (https://aws.amazon.com/blogs/security/iam-policy-types-how-and-when-to-use-them/)
Leave a Reply