Fundamentos do IAM

Quem pode fazer o quê

Toda ação na AWS se resume a uma pergunta: esta identidade tem permissão para fazer isto com este recurso? O AWS Identity and Access Management, ou IAM, é o serviço que responde a ela. O IAM é onde você decide quem pode entrar na sua conta e o que cada pessoa ou aplicação pode fazer depois de entrar.

Isso importa porque uma conta da AWS começa com um único login todo-poderoso e nada além disso. O trabalho real envolve muitas pessoas e muitas aplicações, cada uma precisando de uma fatia diferente de acesso. O IAM é como você distribui essas fatias com segurança. Ele carrega boa parte do domínio de Segurança e conformidade na prova, então vale aprender bem as peças daqui.

O que é o IAM

O IAM é um serviço web que controla o acesso aos seus recursos da AWS. Ele faz dois trabalhos:

• A autenticação confirma quem está fazendo uma solicitação. Quando você entra com uma senha ou uma aplicação chama a AWS com uma chave, o IAM verifica essas credenciais contra uma identidade em que ele confia.
• A autorização decide o que essa identidade pode fazer. Depois que a AWS sabe quem você é, ela confere suas permissões para ver se a ação específica que você pediu é permitida.

Dois fatos sobre o IAM são pontos fáceis na prova. Primeiro, o IAM é um serviço global: as identidades que você cria não ficam presas a uma região, então você nunca escolhe uma região ao criar um usuário ou uma role. Segundo, o IAM em si é gratuito. Você paga apenas pelos recursos da AWS que as suas identidades usam, não pelo IAM.

As peças do IAM

O IAM oferece quatro coisas para você trabalhar. Deixe essas quatro claras e quase todo o tópico se encaixa.

Usuários IAM

Um usuário IAM é uma identidade para uma pessoa ou uma aplicação que precisa de acesso de longo prazo à sua conta. Um usuário pode ter uma senha para entrar no console, chaves de acesso para acesso programático, ou as duas coisas. Cada usuário é uma identidade distinta com suas próprias credenciais, e é isso que permite saber quem fez o quê.

Grupos IAM

Um grupo é um conjunto de usuários. Você anexa políticas ao grupo, e todo usuário dentro dele herda essas permissões. Grupos facilitam a gestão das permissões: coloque seus desenvolvedores em um grupo Developers, anexe as políticas certas uma vez, e um desenvolvedor novo já ganha o mesmo acesso no momento em que você o adiciona. Um grupo não é uma identidade com a qual você entra, não tem credenciais, e você não pode aninhar um grupo dentro de outro.

Roles do IAM

Uma role é uma identidade que você cria com um conjunto de permissões, mas, diferente de um usuário, ela não fica ligada a uma pessoa e não tem senha nem chaves de acesso de longo prazo. Em vez disso, um principal confiável assume a role e recebe credenciais de segurança temporárias para aquela sessão. Roles são como você concede acesso sem distribuir chaves permanentes. Usos comuns incluem dar a uma instância EC2 permissão para ler do S3, deixar uma conta da AWS acessar outra, e conceder acesso a usuários que já têm identidades fora da AWS.

A diferença entre um usuário e uma role é um ponto frequente na prova. Um usuário é uma identidade permanente com credenciais próprias. Uma role é um chapéu temporário que um principal coloca, recebe credenciais de curta duração e depois tira.

Políticas do IAM

Uma política é um documento, normalmente escrito em JSON, que lista permissões. Você anexa políticas a usuários, grupos ou roles para definir o que eles podem fazer. A AWS também oferece políticas gerenciadas pela AWS, políticas prontas para tarefas comuns que você pode anexar como ponto de partida, ao lado das políticas gerenciadas pelo cliente que você mesmo escreve.

Uma declaração de política simples tem algumas partes principais:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::meu-bucket-de-exemplo"
    }
  ]
}

• Effect é Allow ou Deny.
• Action lista as operações, como s3:ListBucket.
• Resource nomeia sobre o que as ações se aplicam.

Você não precisa escrever JSON na mão para a prova, mas deve reconhecer essas partes e saber que o Effect é o que faz uma declaração permitir ou bloquear uma ação.

Como uma solicitação é avaliada

Quando um principal faz uma solicitação, a AWS percorre os passos em ordem.

1. Autenticação. A AWS associa as credenciais da solicitação a um principal em que confia: um usuário IAM, uma sessão de role ou uma identidade federada.
2. Autorização. A AWS reúne toda política que se aplica e verifica se a ação é permitida.

A resposta padrão é não. O acesso é negado a menos que uma política o permita explicitamente, e um Deny explícito em qualquer política sempre vence, mesmo sobre um Allow. Então uma solicitação só dá certo quando algo a permite e nada a nega.

Políticas baseadas em identidade e em recurso

As políticas vêm em dois formatos amplos, e saber distingui-los ajuda na prova.

Políticas baseadas em identidade dizem "esta identidade pode fazer estas coisas". Políticas baseadas em recurso dizem "estes principais podem fazer estas coisas comigo". A role é um caso especial: ela carrega tanto uma política de permissões quanto uma política de confiança que nomeia quem tem permissão para assumi-la.

Dicas para a prova

• O IAM controla a autenticação (quem você é) e a autorização (o que você pode fazer).
• O IAM é um serviço global e é gratuito. Você paga apenas pelos recursos que as identidades usam.
• Quatro peças: usuários (uma pessoa ou aplicação), grupos (um conjunto de usuários), roles (assumíveis, credenciais temporárias) e políticas (permissões em JSON).
• Um usuário tem credenciais de longo prazo; uma role é assumida para obter credenciais temporárias. Saiba essa diferença.
• Grupos não têm credenciais e não podem ser aninhados.
• O acesso é negado por padrão; um Deny explícito sempre vence um Allow.
• Políticas baseadas em identidade são anexadas a usuários, grupos e roles. Políticas baseadas em recurso são anexadas a um recurso e nomeiam o principal.