O IAM no AWS (Identity and Access Management) é um componente fundamental de qualquer infraestrutura em nuvem. Essencialmente, o IAM permite atribuir permissões a diferentes entidades, autorizando ou negando a execução de ações dentro do seu ambiente de nuvem. Ele serve como a base sobre a qual todo o resto da sua infraestrutura é construído.
Cada provedor de serviços em nuvem oferece sua própria versão do IAM. Este artigo aborda especificamente o IAM e conceitos relacionados no contexto da Amazon Web Services (AWS). Exploraremos um cenário onde o uso do Terraform para gerenciar o IAM pode levar a problemas no seu ambiente e mostraremos como solucionar essas questões, além de discutir as melhores práticas para o IAM.
O que é Identity and Access Management no AWS?
Para interagir com a AWS, é necessário autenticar-se na plataforma utilizando suas credenciais do IAM, que funciona como a primeira barreira de entrada na AWS. No ambiente AWS, existem diferentes tipos de entidades, também conhecidas como principais. Um principal é uma entidade à qual você pode atribuir permissões, permitindo que ela execute ações no seu ambiente AWS.
Os três tipos mais comuns de entidades são usuários, grupos e papéis (roles). Um usuário é exatamente o que o nome sugere: seus funcionários podem ter seus próprios usuários na AWS. Para facilitar a administração, você pode agrupar usuários em grupos, o que permite atribuir permissões a vários usuários que devem ter o mesmo nível de acesso.
Um papel é uma entidade de máquina na AWS. Ao criar aplicações ou utilizar outros serviços da AWS, você atribui papéis a eles e, a esses papéis, você concede permissões para o que eles podem fazer no seu ambiente AWS.
As permissões na AWS são concedidas por meio de políticas. Uma política é uma coleção de uma ou mais permissões específicas que definem o que um usuário ou papel tem permissão para fazer. Existem dois tipos principais de políticas:
- Políticas que você anexa a entidades (usuários, grupos, papéis).
- Políticas que você anexa a recursos.
O segundo tipo de política é suportado para diversos recursos, incluindo S3 buckets, tópicos SNS e API Gateways.
Você pode utilizar ambos os tipos de políticas em conjunto. Se você estiver trabalhando em aplicações na AWS que abrangem várias contas AWS, em muitos casos, é necessário utilizar políticas de recursos. O conteúdo de uma política consiste em uma ou mais declarações de política. Cada declaração representa uma ou mais permissões que são permitidas ou negadas para um determinado recurso ou recursos.
Um exemplo de política que você pode atribuir a uma entidade é a política AdministratorAccess:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
Essa política consiste em uma única declaração que permite todas as ações em todos os recursos. Em geral, é uma política que você deve ter cuidado ao atribuir aos seus principais.
Como uma configuração incorreta de IAM no AWS pode quebrar sua infraestrutura
Devido à importância do IAM no AWS, é evidente que a falha em um recurso do IAM pode ter consequências de grande alcance. Se seus papéis, usuários ou políticas do IAM mudarem inesperadamente, isso afetará sua infraestrutura e suas aplicações.
Imagine que você é um engenheiro de plataforma em uma organização que executa uma arquitetura de microsserviços na AWS. Você trabalha na equipe central da plataforma e uma de suas responsabilidades é gerenciar o recurso compartilhado AWS API Gateway, que é o ponto de entrada para partes da sua arquitetura de microsserviços. O API Gateway lida com o tráfego interno e externo.
Uma parte do gerenciamento do recurso API Gateway é controlar o acesso à API usando políticas de recursos. Uma política de recursos é uma política do IAM onde você pode permitir ou negar o acesso à API e seus métodos. A política de recursos atual se parece com isto:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/development-team"
},
"Action": "execute-api:Invoke",
"Resource": "arn:aws:execute-api:eu-west-1:123456789012:p61xuhn9cd"
}
]
}
Em essência, a política permite que uma de suas equipes de desenvolvimento invoque todos os métodos do recurso API. A equipe de desenvolvimento tem um papel chamado development-team. Este papel existe em uma conta AWS com o ID 123456789012.
Sua organização está utilizando o Terraform para configurar toda a sua infraestrutura e você mantém todo o código da infraestrutura em um repositório git. A configuração atual do Terraform para o API Gateway e sua política de recursos usa a seguinte fonte de dados como uma referência ao papel do IAM da equipe de desenvolvimento:
data "aws_iam_role" "development_team" {
name = "development-team"
}
A equipe de desenvolvimento está trabalhando em uma nova versão de sua aplicação e infraestrutura. A equipe não está ciente de como sua infraestrutura é referenciada em outras partes da organização, mas eles assumem que devem ser capazes de atualizar sua própria infraestrutura sem encontrar quaisquer problemas. Como parte de sua nova configuração de infraestrutura, eles mudarão o nome de seu papel do IAM de development-team para development-team-a para melhor refletir o nome de sua equipe. Eles também excluirão o antigo papel chamado development-team.
A equipe de desenvolvimento realiza essas mudanças sem primeiro consultar você e seus colegas na equipe da plataforma. Pouco depois de a equipe de desenvolvimento ter realizado suas mudanças, você percebe um aumento repentino nas respostas “403 Forbidden” no API Gateway.
Após alguma resolução de problemas, você descobre que há um novo papel chamado development-team-a que está tentando usar a API. Você entra em contato com a equipe que informa sobre as mudanças que eles fizeram e você os esclarece sobre o problema atual que você está vendo.
A equipe de desenvolvimento rapidamente reverte sua mudança, mudando o nome do papel do IAM de volta para o nome original de development-team e recria o papel. Você assume que o problema foi resolvido, já que o papel original do IAM está de volta. No entanto, você percebe que a taxa de respostas 403 permanece constante, mesmo depois que a equipe de desenvolvimento reverteu sua mudança. Você se pergunta o que está acontecendo e decide inspecionar a política de recursos do API Gateway. Você descobre o seguinte:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "AROAZE64MWFAASURXM4E6"
},
"Action": "execute-api:Invoke",
"Resource": "arn:aws:execute-api:eu-west-1:123456789012:p61xuhn9cd"
}
]
}
A política não se parece nada com o que você esperava. Em vez de listar o papel do IAM na política de recursos, agora há um ID aleatório AROAZE64MWFAASURXM4E6. De onde vem este ID?
Você olha para a configuração do Terraform para a política de recursos do API Gateway e vê que ela parece correta:
data "aws_iam_role" "development_team" {
name = "development-team"
}
data "aws_iam_policy_document" "test" {
statement {
effect = "Allow"
principals {
type = "AWS"
identifiers = [
data.aws_iam_role.development_team.arn,
]
}
# parts of the code left out for brevity
}
}
O aws_iam_policy_document está corretamente referenciando a fonte de dados aws_iam_role. A fonte de dados está corretamente referenciando um papel chamado development-team. Numa tentativa desesperada de corrigir o problema, você aplica a configuração do Terraform novamente para trazer a infraestrutura de volta ao estado desejado. A saída de terraform plan parece indicar que a política de recursos será mudada de volta para um estado de funcionamento:
O Terraform realizará as seguintes ações:
# aws_api_gateway_rest_api_policy.test will be updated in-place
~ resource "aws_api_gateway_rest_api_policy" "test" {
id = "p61xuhn9cd"
~ policy = jsonencode(
~ {
~ Statement = [
~ {
~ Principal = {
~ AWS = "AROAZE64MWFAASURXM4E6" -> "arn:aws:iam::123456789012:role/development-team"
}
# (3 unchanged attributes hidden)
},
]
# (1 unchanged attribute hidden)
}
)
# (1 unchanged attribute hidden)
}
Plan: 0 to add, 1 to change, 0 to destroy.
Especificamente, o ID aleatório AROAZE64MWFAASURXM4E6 será substituído por arn:aws:iam::123456789012:role/development-team como você espera. Você executa terraform apply e espera que o problema seja resolvido.
A mudança é aplicada e o Terraform relata sucesso. No entanto, os erros 403 permanecem na mesma taxa alarmante. O Terraform não atualizou a política de recursos! Você entra em pânico.
Você executa outro terraform apply para ver qual é o estado atual da sua infraestrutura. Você descobre que o plano se parece exatamente com o plano anterior. Você descobriu o que parece ser um bug no provedor AWS e você não tem certeza de como proceder. Após uma reunião de emergência com a equipe de desenvolvimento, você decide deixar a equipe de desenvolvimento atualizar seu nome de papel do IAM para o novo nome de development-team-a, e você atualiza sua política de recursos para acomodar essas mudanças:
data "aws_iam_role" "development_team" {
# you update the name in this data source
name = "development-team-a"
}
data "aws_iam_policy_document" "test" {
statement {
effect = "Allow"
principals {
type = "AWS"
identifiers = [
# the reference stays the same
data.aws_iam_role.development_team.arn,
]
}
# parts of the code left out for brevity
}
}
A saída de terraform plan mais uma vez indica que a mudança desejada será realizada:
O Terraform realizará as seguintes ações:
# aws_api_gateway_rest_api_policy.test will be updated in-place
~ resource "aws_api_gateway_rest_api_policy" "test" {
id = "p61xuhn9cd"
~ policy = jsonencode(
~ {
~ Statement = [
~ {
~ Principal = {
~ AWS = "AROAZE64MWFAASURXM4E6" -> "arn:aws:iam::629138043200:role/development-team-a"
}
# (3 unchanged attributes hidden)
},
]
# (1 unchanged attribute hidden)
}
)
# (1 unchanged attribute hidden)
}
Plan: 0 to add, 1 to change, 0 to destroy.
O valor do ID aleatório AROAZE64MWFAASURXM4E6 agora será substituído por arn:aws:iam::123456789012:role/development-team-a . Você não está esperançoso, mas você aplica a mudança de qualquer maneira. Os erros desaparecem! Parece que desta vez o Terraform realizou a mudança.
Você percebe que a política de recursos do API Gateway parece melhor desta vez:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/development-team-a"
},
"Action": "execute-api:Invoke",
"Resource": "arn:aws:execute-api:eu-west-1:123456789012:p61xuhn9cd"
}
]
}
Você e o resto da equipe de engenharia da plataforma marcaram uma reunião post mortem junto com a equipe de desenvolvimento para discutir como vocês podem evitar problemas como este no futuro. O cenário descrito acima pode acontecer, e já aconteceu.
Cada principal na AWS tem um ID principal único, um exemplo de tal ID é AROAZE64MWFAASURXM4E6. Destruir um papel do IAM e criar um novo papel com o mesmo nome pode parecer uma coisa segura de se fazer, mas não é. O novo papel do IAM tem um novo ID principal que não corresponde ao papel original do IAM. Existem alguns lugares onde esta distinção é importante, e um deles é na política de recursos do API Gateway.
O que as equipes de plataforma e desenvolvimento poderiam ter feito para evitar este problema? Há uma série de coisas que poderiam ter sido feitas:
- Conhecimento: saber sobre IDs principais e como as políticas de recursos se comportam poderia ter levado a equipe de desenvolvimento a pensar um passo adiante antes de aplicar suas mudanças. Fazer isso com sucesso requer habilidade, comunicação e um pouco de sorte.
- Rearquitetar suas configurações do Terraform: atualmente, a equipe da plataforma usa fontes de dados para ler dados (por exemplo, ARN do papel do IAM) das equipes de desenvolvimento. Esta é uma dependência oculta entre diferentes configurações do Terraform, e requer que certos atributos dos recursos permaneçam os mesmos. Você pode trazer partes relacionadas para uma única configuração do Terraform e garantir que elas sejam sempre atualizadas juntas. Isso pode não ser viável para grandes peças de infraestrutura distribuída.
- Descobrir dependências: se você tem uma maneira de descobrir dependências entre suas configurações do Terraform, você pode automatizar o processo de descoberta e informar sobre quaisquer problemas potenciais que uma mudança em uma configuração do Terraform poderia significar em uma configuração diferente do Terraform. Este processo poderia ser incluído em seus sistemas de CI/CD, pull-requests e muito mais.
Das três opções discutidas acima, a terceira opção é a mais razoável em todas as situações. Não requer que você refatore todas as suas configurações do Terraform em uma grande mono-infraestrutura.
Melhores práticas para IAM no AWS
Existem várias práticas recomendadas para o IAM no AWS que você deve implementar.
Use o princípio do menor privilégio
Ao escrever políticas do IAM para suas entidades, use o princípio do menor privilégio. Isso significa que você deve atribuir as permissões que uma entidade precisa para realizar seu trabalho, mas nada mais. Um papel que só precisa ler blobs em um S3 bucket não precisa ter acesso total de administrador.
Você pode restringir as políticas tanto em termos das permissões que você atribui a uma entidade, quanto em termos de quais recursos as permissões se aplicam. Você também pode dar um passo adiante para usar condições para quando as permissões são válidas.
Use autenticação multifator
Use autenticação multifator (MFA) para todas as suas contas de usuário humano na AWS. O benefício é que, mesmo que a senha do usuário seja vazada, não será suficiente para obter acesso à conta. Para garantir a segurança de seu ambiente de nuvem, é fundamental implementar as melhores práticas de segurança do IAM.
Proteja a conta raiz da AWS
A conta raiz da AWS deve ser usada apenas para a configuração inicial da conta AWS. Tal como acontece com qualquer outro usuário na AWS, habilite o MFA. Você pode usar um dispositivo MFA físico (por exemplo, uma chave Yubi) que você armazena em um local seguro.
Use papéis em vez de usuários
Se possível, use papéis do IAM em vez de usuários do IAM. Os papéis usam credenciais de segurança temporárias por padrão, o que minimiza os riscos de credenciais vazadas. Você pode atribuir papéis para suas aplicações e serviços em execução na AWS e atribuir-lhes as permissões que eles precisam.
Para seus usuários normais, você pode habilitar o SSO sign-in e conectar usuários conectados a papéis em vez de contas de usuário do IAM.
Audite a atividade do IAM
Você deve habilitar os logs do CloudTrail para sua conta e configurar alertas para eventos incomuns. Você deve alertar para qualquer atividade realizada pela conta de usuário raiz para garantir que você esteja ciente quando esta conta for usada. Uma medida adicional para a segurança de sua conta é utilizar um gerenciador de senhas que facilite a exclusão de credenciais salvas, minimizando riscos em caso de comprometimento.
Eduque sua organização sobre as melhores práticas de segurança
A segurança do IAM é fundamental para o seu ambiente de nuvem. Você deve educar sua organização sobre como usar o IAM e seguir as melhores práticas.
Desloque a segurança para a esquerda
Uma prática recomendada geral é deslocar a segurança para a esquerda. Use políticas do IAM, políticas de controle de serviço (SCPs) e ferramentas de governança, como o AWS IAM Access Analyzer para proteger seu ambiente. Realize uma análise de segurança de cada mudança que você introduz em seu ambiente. Integre recursos de segurança em todo o seu ambiente AWS e além.
Resumo
O AWS Identity and Access Management (IAM) é um serviço central na AWS.
Dois conceitos importantes do IAM incluem principais (usuários, grupos, papéis) e políticas (permissões). As políticas controlam o que é permitido ou negado em seu ambiente, e essas políticas controlam o que seus principais podem fazer em suas contas AWS.
Dada a centralidade do IAM, é evidente que esta é uma parte sensível de sua infraestrutura, onde configurações incorretas podem levar a uma parada completa em seu ambiente de produção.
Neste artigo, seguimos um cenário onde partes de uma arquitetura de microsserviços experimentaram um problema devido a uma política quebrada de uma mudança inocente de um papel do IAM.
A infraestrutura quebrou porque cada principal do IAM tem um ID principal que é único. Recriar um papel do IAM com o mesmo nome ainda cria um principal com um novo ID único. Uma mudança inocente como essa pode quebrar referências ao papel de maneiras inesperadas que são difíceis de corrigir.
Mudanças como a destacada no cenário são comuns, e é fundamental entender quais consequências suas mudanças de infraestrutura podem ter.
Este conteúdo foi auxiliado por Inteligência Artificiado, mas escrito e revisado por um humano.
Via Dev.to