Segurançaדִּגְלוֹ
RBAC: cada um junto à sua bandeira
Como o acesso por papel organiza o acampamento, por que os papéis explodem, como minerá-los do uso real e quando RBAC sozinho não basta.
דַּע יָדֹעַ פְּנֵי צֹאנֶךָ
da yadoa penei tzonecha · conhece bem o rosto do teu rebanho · Mishlei 27:23
Blog/Artigos · Segurança
IAM: conhece bem o rosto do teu rebanho
Autenticação e autorização, o ciclo de vida da identidade, menor privilégio e IAM como código com evidência.
Mishlei manda o pastor conhecer bem o rosto do seu rebanho, porque poder algum é para sempre e riqueza nenhuma se guarda sozinha. IAM é isso levado à identidade digital: saber quem é cada conta, humana ou de serviço, o que ela pode fazer e por quê. Onde ninguém conhece o rebanho, o acesso cresce sem dono, e é por uma dessas contas esquecidas que quase todo incidente que eu investiguei começou.
A identidade é o perímetro
Quando o dado estava dentro de um datacenter, o perímetro era a rede: firewall na borda e confiança em quem já estava dentro. Com cloud, SaaS e trabalho remoto, o recurso está em toda parte e o acesso vem de qualquer lugar. O que separa o legítimo do hostil deixou de ser o endereço de rede e passou a ser a identidade que se apresenta e o contexto em que ela aparece.
Zero Trust parte daí: nenhuma rede é confiável por si só, toda requisição é autenticada e autorizada, e o privilégio é o menor que resolve a tarefa. Não é produto que se compra, é a consequência de tratar cada identidade como a fronteira. Por isso IAM deixou de ser função de retaguarda e virou o controle de segurança de maior alcance.
Figura 1O que compõe uma identidade governada, da conta ao contexto
- Conta quempessoa, serviço ou carga de trabalho, com dono nomeado e origem declarada
- Credencial provao que a conta usa para se autenticar: senha com MFA, chave, token de curta duração
- Direito de acesso o que podepapéis e permissões efetivas, sempre no menor privilégio que a função exige
- Contexto quandodispositivo, postura, localização e risco da sessão no momento do pedido
- Trilha prova depoisquem acessou o quê, quando e sob qual decisão, registrado e imutável
Autenticar não é autorizar
Autenticação, AuthN, responde quem você é: prova a identidade com um fator que você sabe, tem ou é, e MFA existe porque um fator sozinho cai fácil. Autorização, AuthZ, responde o que você pode: dado que a identidade é conhecida, qual ação em qual recurso ela tem direito de executar. Confundir as duas é a raiz de metade das falhas de acesso.
O erro clássico é autenticar bem e autorizar mal: login forte com MFA e, depois de entrar, permissão de administrador para todo mundo. O login prova o rosto do rebanho; a autorização decide o portão que cada um pode abrir. Um controle não substitui o outro, e um SSO robusto não conserta uma política de permissão frouxa.
Figura 2Da requisição à decisão: onde AuthN termina e AuthZ começa
- 01Requisiçãoa identidade pede uma ação sobre um recurso
- 02Autenticaçãoprova de identidade com MFA; falhou aqui, para aqui
- 03IAContexto da sessãodispositivo, postura e risco entram na conta
- 04Autorizaçãoa política decide se aquela identidade pode aquela ação
- 05Decisão registradapermite ou nega, e o motivo vai para a trilha
Negado não é fim de fluxo: o pedido negado é sinal, e pedido negado repetido é indício de acesso mal desenhado ou de abuso.
O ciclo de vida: joiner, mover, leaver
Identidade não é estado, é ciclo. Alguém entra e precisa do acesso do primeiro dia (joiner), muda de função e deveria trocar de acesso, não somar (mover), e sai e precisa perder tudo na hora (leaver). O elo que quase sempre falha é o mover: a pessoa acumula os acessos do papel antigo e do novo, e ninguém remove o que sobrou.
Esse acúmulo tem nome, privilege creep, e é o combustível do risco de acesso. O leaver malfeito é o pior: conta ativa de quem já saiu, chave de serviço de um sistema desligado. A recertificação periódica existe para reencontrar o rebanho, mas ela só é sustentável se o ciclo estiver automatizado, não como caça manual trimestral.
Figura 3O ciclo de vida da identidade, do provisionamento à revogação
- Joiner provisiona o acesso do papel de entrada, nem mais nem menos
- Mover troca o acesso ao mudar de função, remove o antigo em vez de somar
- Recertificação o dono confirma periodicamente que cada acesso ainda se justifica
- Leaver revoga tudo no desligamento, humano e de serviço, sem atraso
Menor privilégio e o acesso que ninguém usa
Menor privilégio é conceder só o que a tarefa exige, pelo tempo que exige. Na prática, o que se vê é o contrário: permissão ampla concedida por conveniência e nunca revista, porque tirar acesso dá trabalho e medo de quebrar algo. O resultado é uma superfície de ataque que cresce em silêncio, permissão a permissão.
A medida que importa não é quanto acesso foi concedido, é quanto foi usado. Permissão concedida e nunca exercida em noventa dias é candidata natural a corte, e a maior parte do privilégio excessivo cai sem quebrar nada quando a decisão parte do uso real, não da suposição de quem pediu.
Figura 4Permissões concedidas contra permissões efetivamente usadas em 90 dias
IAM como código, com evidência
Acesso clicado no console é acesso sem história: ninguém sabe quem concedeu, quando nem por quê, e a próxima auditoria vira arqueologia. IAM como código inverte isso: papel, política e associação vivem no repositório, mudam por pull request com revisão e deixam no histórico do Git a resposta para quem, quando e por quê.
O código também é o lugar de declarar a segregação de deveres, a regra de que a mesma identidade não acumula funções que se controlam, como criar um pagamento e aprovar o mesmo pagamento. Declarada como política versionada e testada, a segregação deixa de ser promessa em documento e passa a ser barreira que o pipeline verifica a cada mudança.
Figura 5Política de menor privilégio com condição, escrita para revisão
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "LeituraDeArtefatosDoTime",
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:ListBucket"],
"Resource": [
"arn:aws:s3:::artefatos-time-pagamentos",
"arn:aws:s3:::artefatos-time-pagamentos/*"
],
"Condition": {
"StringEquals": { "aws:PrincipalTag/time": "pagamentos" },
"Bool": { "aws:MultiFactorAuthPresent": "true" }
}
}
]
}Para levar
IAM começa por conhecer o rebanho: inventariar cada identidade, separar autenticar de autorizar, fechar o ciclo joiner-mover-leaver, cortar o privilégio que ninguém usa e sustentar tudo como código com trilha. Não é o controle mais visível, é o de maior alcance, porque quase todo incidente passa por uma identidade que ninguém estava olhando. A IA ajuda a inventariar, priorizar e redigir; conhecer o rebanho continua sendo dever de quem o pastoreia.
Quem escreve: Juliano Vince de Campos
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
