Fundamentos de IAM: A Base da Segurança em Nuvem
Identity and Access Management (IAM) é o alicerce de qualquer infraestrutura segura na nuvem. O IAM controla quem pode acessar o quê e como, funcionando como um guardião digital que valida identidades e autoriza ações. Em projetos reais, uma política IAM mal configurada pode expor dados sensíveis, comprometer compliance (LGPD, HIPAA) ou resultar em custos imensuráveis com recursos roubados. O IAM é tanto um conceito técnico quanto uma responsabilidade estratégica: você precisa garantir que desenvolvedores tenham poder para fazer seu trabalho, sem abrir portas desnecessárias.
Os três pilares fundamentais são: identificação (quem você é), autenticação (prova de identidade) e autorização (o que você pode fazer). Na AWS, Azure e GCP, esses pilares se concretizam através de Users, Groups, Roles e Policies. Entender essa tríade é essencial antes de implementar Least Privilege, que é a filosofia de segurança mais importante que você aprenderá neste artigo.
Users, Groups e Roles: A Estrutura Organizacional
Users representam indivíduos ou aplicações que precisam acessar recursos. Groups são coleções de users que compartilham as mesmas necessidades de acesso, reduzindo o trabalho administrativo exponencialmente. Roles são entidades abstratas que encapsulam permissões e podem ser assumidas por users, grupos, ou até serviços. A chave é entender que roles são reutilizáveis e escaláveis, enquanto permissions diretas em users criam caos em projetos maiores.
Veja um exemplo prático com Terraform (infraestrutura como código), que você usará em projetos reais:
# Criando um grupo para desenvolvedores
resource "aws_iam_group" "developers" {
name = "developers"
}
# Criando um usuário
resource "aws_iam_user" "alice" {
name = "alice.silva"
}
# Adicionando o usuário ao grupo
resource "aws_iam_group_membership" "dev_membership" {
name = "dev-group-membership"
users = [aws_iam_user.alice.name]
group = aws_iam_group.developers.name
}
# Criando uma role para aplicações EC2
resource "aws_iam_role" "ec2_app_role" {
name = "ec2-app-role"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Action = "sts:AssumeRole"
Effect = "Allow"
Principal = {
Service = "ec2.amazonaws.com"
}
}
]
})
}
Este código demonstra a separação clara: users são pessoas, groups organizam users, e roles abstratamente definem responsabilidades. Em uma startup com 50 pessoas, você pode ter 3-4 grupos em vez de 50 políticas espalhadas. Quando a Alice muda de departamento, você a remove de um grupo e adiciona a outro — uma operação.
Policies e Least Privilege: O Coração da Segurança
Policies são documentos JSON que definem exatamente quais ações (actions), em quais recursos (resources), são permitidas (Allow) ou negadas (Deny). Least Privilege é o princípio de conceder apenas as permissões necessárias para realizar uma tarefa específica, nada mais. Este princípio reduz o dano potencial se uma credencial vazar ou um funcionário agir com má intenção.
Uma policy típica de um desenvolvedor backend que precisa acessar S3 e RDS deve ser altamente específica:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "S3ReadProductionBucket",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::production-data",
"arn:aws:s3:::production-data/*"
]
},
{
"Sid": "RDSConnectProduction",
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": "arn:aws:rds:us-east-1:123456789012:db:prod-database"
},
{
"Sid": "DenyS3DeleteInProduction",
"Effect": "Deny",
"Action": [
"s3:DeleteBucket",
"s3:DeleteObject"
],
"Resource": "*"
}
]
}
Repare: ela pode ler do S3 e conectar ao RDS, mas nunca pode deletar — mesmo que tente contornar. Essa negação explícita é crítica. Em um projeto real que auditar, você encontra policies que permitem s3:* (tudo em S3) para "simplificar". Isso é um sinal vermelho de negligência. O custo de 20 minutos definindo permissões é infinitamente menor que o custo de uma invasão.
Implementação em Produção
# Policy document em Terraform para role de aplicação
resource "aws_iam_role_policy" "lambda_dynamodb_policy" {
name = "lambda-dynamodb-policy"
role = aws_iam_role.lambda_role.id
policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Effect = "Allow"
Action = [
"dynamodb:GetItem",
"dynamodb:Query",
"dynamodb:Scan"
]
Resource = "arn:aws:dynamodb:us-east-1:123456789012:table/users"
},
{
Effect = "Allow"
Action = "logs:CreateLogGroup"
Resource = "arn:aws:logs:us-east-1:123456789012:*"
}
]
})
}
Esta função Lambda pode ler dados de uma tabela DynamoDB específica e criar logs, nada mais. Se seu código tiver uma vulnerabilidade SQL injection (improvável em DynamoDB, mas hipoteticamente), o dano é limitado: não há acesso a outras tabelas, bancos ou serviços.
Padrões Reais: Da Teoria à Prática
Em uma empresa típica, você encontrará esses padrões: 1) Separação por Ambiente — desenvolvedores têm acesso limitado a staging, produção requer aprovação extra; 2) Separação por Time — backend, frontend, devops, cada um com suas roles específicas; 3) Time-Based Access — credenciais que expiram automaticamente, rotacionadas a cada 90 dias.
Um exemplo real de staging vs produção:
resource "aws_iam_group" "dev_staging_access" {
name = "dev-staging-access"
}
resource "aws_iam_group" "sre_production_access" {
name = "sre-production-access"
}
# Staging é permissivo
resource "aws_iam_group_policy" "staging_policy" {
name = "staging-policy"
group = aws_iam_group.dev_staging_access.name
policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Action = "ec2:*"
Resource = "*"
Condition = {
StringEquals = {
"aws:RequestedRegion" = "us-east-1-staging"
}
}
}]
})
}
# Produção é restritivo e requer MFA
resource "aws_iam_group_policy" "production_policy" {
name = "production-policy"
group = aws_iam_group.sre_production_access.name
policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Action = ["ec2:DescribeInstances", "ec2:StartInstances"]
Resource = "*"
Condition = {
Bool = {
"aws:MultiFactorAuthPresent" = "true"
}
}
}]
})
}
Este padrão reflete o mundo real: desenvolvedores testam agressivamente em staging, mas produção exige MFA e um conjunto menor de ações. Assim, um desenvolvedor junior com credenciais comprometidas não pode derrubar a produção por acidente.
Conclusão
Dominando IAM significa: 1) Estruturar Users em Groups, não políticas espalhadas — isso reduz complexidade exponencialmente em empresas em crescimento. 2) Implementar Least Privilege como princípio inabalável — cada credencial deve ter o mínimo possível, não o máximo. 3) Usar Roles para abstração e reutilização — roles são seu melhor amigo quando você tem múltiplos ambientes, times ou aplicações.
IAM não é sexy, mas é a diferença entre uma infraestrutura que dorme tranquila e um desastre de segurança. Comece pequeno, implemente Least Privilege desde o dia um, e você evitará refatorações dolorosas depois. Sua equipe de segurança (e seu sono) agradecem.