AWS para Iniciantes: Preparando a conta e o acesso com IAM do jeito seguro

Por que começar pelo IAM (e não “sair criando serviços”)

Antes de hospedar qualquer site, o passo mais importante é garantir que sua conta AWS esteja protegida e que os acessos sejam organizados. O IAM (Identity and Access Management) é o serviço que controla quem pode acessar a AWS e o que essa pessoa pode fazer. As boas práticas essenciais aqui são: proteger o usuário raiz (root) com MFA, criar um usuário administrador para o dia a dia, aplicar menor privilégio e organizar permissões com grupos e políticas gerenciadas.

Conceitos que você precisa dominar

• Usuário raiz (root): é o “dono” da conta. Tem poderes máximos e não deve ser usado no dia a dia.
• MFA (Multi-Factor Authentication): uma segunda camada de segurança (ex.: app autenticador) além da senha.
• Usuário IAM: identidade para uma pessoa (ou sistema) operar na conta.
• Grupo IAM: conjunto de permissões para vários usuários (ex.: Admins, Billing, ReadOnly).
• Política (Policy): documento que define permissões (ações, recursos e condições). Pode ser gerenciada pela AWS (AWS Managed) ou criada por você (Customer Managed).
• Menor privilégio: dar apenas as permissões necessárias, pelo menor tempo necessário.
• Chaves de acesso (Access Keys): credenciais para uso programático (CLI/SDK). Devem ser criadas apenas quando realmente necessário e tratadas como segredo.

Estrutura recomendada para iniciantes (simples e segura)

Uma estrutura prática para começar sem se perder:

• Root: usado somente para tarefas raras (ex.: configurações de conta, faturamento crítico). Sempre com MFA.
• Seu usuário pessoal IAM: para uso diário no Console.
• Grupo “Admin-Temporary”: você entra nele no início para configurar tudo com rapidez, e depois reduz permissões (ou troca por grupos mais específicos).
• Grupos por função (exemplos): Billing-ReadOnly, Support, ReadOnly, Deploy (mais à frente, quando você souber exatamente o que precisa).

O objetivo é: começar com controle, e depois apertar as permissões conforme seu uso real.

Passo a passo 1: proteger o usuário raiz (root) com MFA

1) Faça login como root

Entre no Console AWS com o e-mail da conta (root). Se você já usa root no dia a dia, pare aqui e siga os passos abaixo para criar seu usuário IAM.

2) Ative o MFA do root

No Console, procure por configurações de segurança da conta (Security credentials) e habilite MFA para o usuário raiz.

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

• Prefira aplicativo autenticador (TOTP) em vez de SMS.
• Guarde os códigos de recuperação (se fornecidos) em local seguro (ex.: cofre de senhas).

3) Valide imediatamente

• Saia da conta.
• Entre novamente como root.
• Confirme que o Console exige o código MFA.

Passo a passo 2: criar um usuário administrador IAM para o dia a dia

Você vai criar um usuário IAM pessoal e dar permissão administrativa inicialmente (temporária) para configurar o ambiente com agilidade. Depois, você reduz permissões.

1) Crie um grupo de administradores temporário

No IAM, crie um grupo chamado Admin-Temporary e anexe a política gerenciada pela AWS:

• AdministratorAccess

Por que grupo? Porque fica mais fácil remover/alterar permissões depois sem editar usuário por usuário.

2) Crie seu usuário IAM pessoal

• Nome sugerido: seu-nome ou seu-nome.admin (padrão consistente ajuda).
• Habilite acesso ao Console (senha).
• Exija troca de senha no primeiro login (se aplicável).
• Adicione o usuário ao grupo Admin-Temporary.

3) Ative MFA no seu usuário IAM

No IAM, configure MFA também para o seu usuário IAM (não apenas para o root). Isso reduz muito o risco de invasão por senha vazada.

4) Faça login com o usuário IAM e pare de usar root

Saia do root e entre com seu usuário IAM. A partir daqui, o root deve ficar “guardado”.

Passo a passo 3: aplicar menor privilégio (reduzindo o Admin temporário)

O erro comum é deixar AdministratorAccess para sempre. A prática recomendada é usar admin total só enquanto você está configurando o básico e ainda não sabe exatamente quais permissões serão necessárias.

Estratégia simples para reduzir permissões sem quebrar seu trabalho

• Fase 1 (início): seu usuário está no grupo Admin-Temporary com AdministratorAccess.
• Fase 2 (após configurar o essencial): remova seu usuário do grupo Admin-Temporary e coloque em grupos mais restritos.
• Fase 3 (ajuste fino): se algo falhar por falta de permissão, você identifica a ação necessária e adiciona apenas o mínimo.

Como descobrir permissões necessárias sem “chutar”

Quando uma ação falha no Console, normalmente aparece uma mensagem de AccessDenied. Use isso como pista do que está faltando. Em vez de voltar para admin total, crie/ajuste uma política específica.

Exemplo conceitual de política (apenas ilustrativo):

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListAllMyBuckets", "s3:ListBucket" ], "Resource": "*" } ] }

Na prática, você vai criar políticas alinhadas ao que você realmente precisa (por exemplo, leitura de faturamento, leitura de logs, deploy em um serviço específico).

Organizando acessos com grupos e políticas gerenciadas

Para iniciantes, priorize políticas gerenciadas pela AWS quando elas atenderem seu caso, porque são mantidas e atualizadas. Conforme você amadurece, você cria políticas próprias para reduzir permissões.

Exemplo de organização por grupos (modelo inicial)

Dica prática: evite anexar políticas diretamente no usuário. Prefira grupos. Isso facilita revisar e revogar acessos.

Chaves de acesso (Access Keys): crie só quando necessário

Para usar Console, você não precisa de Access Keys. Elas são para uso programático (AWS CLI, SDK, automações). Criar chaves “por via das dúvidas” aumenta o risco de vazamento.

Quando faz sentido criar Access Keys

• Você vai usar AWS CLI no seu computador.
• Uma aplicação precisa acessar a AWS via SDK (idealmente com outra abordagem, como roles, quando aplicável).
• Uma automação controlada precisa executar ações específicas.

Boas práticas essenciais com Access Keys

• Não crie para o root.
• Guarde em um cofre de senhas ou gerenciador de segredos apropriado, nunca em texto puro.
• Nunca envie por e-mail/WhatsApp e nunca cole em tickets.
• Não commite no Git. Se acontecer, trate como incidente: revogue e gere novas imediatamente.
• Rotacione (troque) periodicamente, especialmente se houver suspeita de vazamento.

Checklist rápido antes de criar uma chave

• Eu realmente preciso de acesso programático agora?
• Posso resolver só com Console?
• Tenho um local seguro para armazenar a chave?
• Consigo limitar permissões desse usuário ao mínimo?

Erros comuns (e como evitar)

1) Usar root no dia a dia

Problema: se a senha vazar, o invasor tem controle total. Correção: root só para tarefas raras e sempre com MFA; use usuário IAM para o cotidiano.

2) Compartilhar senha ou usuário

Problema: você perde rastreabilidade (não sabe quem fez o quê) e aumenta risco. Correção: cada pessoa deve ter seu próprio usuário IAM (ou mecanismo equivalente de identidade), com MFA.

3) Deixar AdministratorAccess permanente

Problema: qualquer erro humano ou conta comprometida vira desastre. Correção: admin temporário, depois grupos com menor privilégio.

4) Criar Access Keys sem necessidade

Problema: chaves vazam com facilidade (logs, prints, repositórios). Correção: só crie quando houver caso real; revogue quando não usar.

Passo a passo de validação (checklist de segurança do acesso)

Validação 1: root protegido

• Consigo logar como root e o MFA é exigido.
• Eu não uso root para tarefas diárias.

Validação 2: usuário IAM pronto para o dia a dia

• Consigo logar com meu usuário IAM.
• MFA está habilitado no meu usuário IAM.
• Minha senha é forte e não é reutilizada.

Validação 3: permissões sob controle

• Meu usuário está em grupos (não depende de políticas anexadas diretamente).
• Se eu ainda estiver no Admin-Temporary, existe um plano para remover em breve.
• Eu sei quais grupos existem e por que existem (sem “grupos esquecidos”).

Validação 4: credenciais e chaves

• Não existem Access Keys para root.
• Se eu tenho Access Keys, sei onde estão armazenadas e por que existem.
• Eu sei como revogar uma chave imediatamente se suspeitar de vazamento.