Gerenciamento de identidade e acesso

Uma senha, a conta inteira

Digamos que uma empresa dá a senha do root user da conta AWS para cada novo desenvolvedor, para que ninguém precise esperar o time de TI liberar acesso. É rápido, e por meses nada dá errado. Depois um notebook com essa senha salva no navegador é roubado de uma cafeteria. Quem estiver com ele agora pode iniciar instâncias, ler todo arquivo guardado, apagar todo backup e mudar os dados de cobrança, porque o root user não tem limite nenhum.

Gerenciamento de identidade e acesso existe para deixar esse cenário muito menor. Em vez de uma única credencial compartilhada e todo-poderosa, o IAM deixa um time dar a cada pessoa e a cada aplicação sua própria identidade, restrita exatamente ao que essa identidade precisa fazer. Um notebook roubado então expõe uma fatia estreita da conta, não a conta inteira.

Root user, usuários IAM e roles

Toda conta AWS começa com um único root user, criado automaticamente, com acesso irrestrito a tudo. A própria orientação da AWS é direta sobre isso: não use o root user para tarefas do dia a dia, guarde as credenciais dele em um lugar seguro, e configure outras identidades para o trabalho de verdade.

Duas dessas outras identidades importam mais. Um usuário IAM é uma identidade persistente, tipicamente para uma pessoa específica ou uma aplicação que precisa de acesso permanente, com credenciais que duram até alguém rotacioná-las ou revogá-las. Uma role é diferente: é uma identidade sem credenciais próprias, assumida temporariamente por um usuário, uma aplicação ou um serviço da AWS, que recebe credenciais de curta duração e expiração automática durante a sessão. A prática moderna pende forte para roles justamente porque não sobra nada de longa duração para vazar.

Duas verificações separadas: autenticação, depois autorização

Imagine um desenvolvedor entrando com senha e código MFA, e então solicitando iniciar uma nova máquina virtual. A AWS roda 2 verificações distintas, nessa ordem, não uma verificação combinada.

Primeiro, autenticação: essa senha e esse código MFA correspondem a uma identidade real, confiável para essa conta? Se sim, a identidade está confirmada. Segundo, e separadamente, autorização: a política anexada a essa identidade confirmada realmente permite iniciar uma instância? Um usuário pode passar pela autenticação perfeitamente, com senha correta e código MFA válido, e ainda assim ser barrado na autorização se a política dele não conceder essa ação. As 2 verificações protegem contra falhas diferentes: uma senha roubada derrota a autenticação, enquanto uma política que concede permissão demais derrota a autorização mesmo com a autenticação funcionando exatamente como deveria.

Menor privilégio: comece estreito, não amplo

Digamos que a role de um desenvolvedor precisa ler arquivos de um único bucket de relatórios e nada mais. Uma política de menor privilégio concede exatamente isso: a ação s3:GetObject, restrita àquele bucket, nada além. Compare com uma política ampla concedendo acesso total ao S3 "por segurança": se as credenciais dessa role forem usadas de forma indevida algum dia, a política estreita limita o estrago ao acesso de leitura de um bucket, enquanto a ampla entrega todo bucket da conta.

Menor privilégio é uma direção para seguir, não uma configuração única. A própria orientação da AWS recomenda começar com uma política gerenciada mais ampla enquanto um time descobre o que uma nova carga de trabalho realmente precisa, e depois restringi-la conforme os padrões de uso ficam claros, usando ferramentas que analisam a atividade real de acesso para gerar uma política mais estreita automaticamente. Times que nunca revisitam essa primeira política ampla são os que uma auditoria acaba sinalizando.

A fronteira: grupos versus roles

Essas 2 se confundem porque ambas deixam mais de uma entidade compartilhar um conjunto de permissões, mas resolvem problemas diferentes. Um grupo é uma coleção de usuários IAM, útil para conceder as mesmas políticas para, digamos, todo mundo em um time de dados, sem anexar essa política a cada usuário individualmente. Uma role não é uma coleção de nada; é uma única identidade que diferentes principals podem assumir temporariamente, um de cada vez, recebendo credenciais que expiram. Pergunte qual questão o cenário coloca: "conceder as mesmas permissões permanentes para várias pessoas" aponta para um grupo; "deixar essa aplicação ou essa pessoa agir temporariamente como uma identidade específica" aponta para uma role.

Equívoco: uma senha forte basta

É tentador achar que uma senha longa e única já é proteção suficiente para uma conta. Não é: senhas são phishadas, reaproveitadas em sites vazados ou capturadas por malware, não importa quão forte sejam. MFA fecha essa lacuna exigindo um segundo fator, algo que o dono da conta possui ou gera, que uma senha roubada sozinha não consegue satisfazer. A AWS recomenda especificamente MFA resistente a phishing, como chaves de segurança ou passkeys, em vez de códigos únicos enviados por SMS, já que até esse código às vezes pode ser interceptado ou o fluxo enganado.

Dicas para a prova: relacionando o cenário com a ferramenta

Onde isso deixa você

Identidade é a linha da tabela de responsabilidade compartilhada que nunca passa para o provedor, e o IAM é o conjunto de ferramentas que deixa você de fato ser dono dela: confirmar quem está pedindo acesso com autenticação, decidir o que essa pessoa pode fazer com autorização, e manter as duas estreitas com menor privilégio e roles em vez de credenciais permanentes e todo-poderosas. Saber quem pode tocar nos seus dados resolve metade do problema. A próxima lição cobre o que protege esses dados mesmo se alguém passar por todas essas verificações: criptografia.