AWS para Iniciantes: Publicação responsável do site — permissões, atualizações e proteção básica

O que é “publicação responsável” (e por que isso importa)

Colocar um site no ar é só o começo. Publicação responsável é o conjunto de práticas operacionais para reduzir riscos comuns (invasão por credenciais fracas, serviços desatualizados, permissões excessivas, chaves expostas) e para manter rastreabilidade do que foi criado e alterado. Na prática, isso envolve: atualizar o sistema e pacotes, controlar usuários e chaves SSH, reduzir superfícies de ataque (ex.: desativar login por senha), aplicar o princípio do menor privilégio no IAM, registrar mudanças e revisar acessos periodicamente.

Checklist operacional mínimo (visão geral)

• Atualizações: sistema e pacotes em dia; reinícios planejados.
• Usuários: nada de usar root no dia a dia; contas nomeadas; remoção de acessos antigos.
• SSH: chaves fortes, sem senha no SSH quando possível, sem login direto de root.
• Permissões AWS (IAM): menor privilégio; evitar chaves de acesso permanentes; revisar políticas.
• Inventário e tags: saber o que existe, por quê e quem é dono; rastrear custo.
• Registro de mudanças: anotar alterações e manter um histórico simples.
• Revisão periódica: rotina mensal/trimestral para checar acessos e configurações.

Atualização do sistema: mantendo o servidor “em dia”

Conceito

Atualizações corrigem vulnerabilidades conhecidas. Um servidor desatualizado é um alvo comum porque muitas explorações são automatizadas. O objetivo aqui é ter um processo simples: atualizar com frequência e reiniciar quando necessário.

Passo a passo (Ubuntu/Debian)

sudo apt update
sudo apt upgrade -y
sudo apt autoremove -y

Se o kernel ou bibliotecas críticas forem atualizados, planeje um reinício:

sudo reboot

Passo a passo (Amazon Linux 2023 / RHEL-like)

sudo dnf update -y

Dica operacional: defina uma janela semanal (ex.: toda terça-feira) para atualizar e reiniciar se necessário, fora do horário de pico.

Gerenciamento de usuários no servidor: contas nomeadas e rastreáveis

Conceito

Evite compartilhar um único usuário para todos. Contas nomeadas facilitam auditoria (quem fez o quê) e revogação de acesso (remover uma pessoa sem impactar as outras).

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

Passo a passo: criar um usuário e dar permissão administrativa

Crie um usuário (ex.: joao) e adicione ao grupo de administração:

sudo adduser joao
sudo usermod -aG sudo joao

Em distribuições onde o grupo administrativo é wheel:

sudo usermod -aG wheel joao

Boas práticas rápidas

• Não use root para tarefas diárias.
• Remova usuários antigos quando alguém sai do projeto.
• Evite “contas genéricas” como admin compartilhado.

Chaves SSH: como usar do jeito certo

Conceito

SSH com chave é mais seguro do que senha, porque reduz risco de força bruta e reutilização de senhas. A chave privada fica com você; a pública vai para o servidor.

Passo a passo: gerar chave (no seu computador)

ssh-keygen -t ed25519 -C "seu-email@exemplo.com"

Isso cria uma chave privada (não compartilhe) e uma pública (pode copiar para o servidor). Use passphrase na chave privada quando possível.

Passo a passo: instalar a chave no servidor

Opção 1 (mais prática):

ssh-copy-id -i ~/.ssh/id_ed25519.pub joao@IP_DO_SERVIDOR

Opção 2 (manual): copie o conteúdo do arquivo id_ed25519.pub para:

/home/joao/.ssh/authorized_keys

Garanta permissões corretas:

sudo mkdir -p /home/joao/.ssh
sudo chmod 700 /home/joao/.ssh
sudo chmod 600 /home/joao/.ssh/authorized_keys
sudo chown -R joao:joao /home/joao/.ssh

Rotação e revogação de chaves

• Rotação: troque chaves periodicamente (ex.: a cada 6–12 meses) ou quando houver suspeita.
• Revogação: remova a linha da chave em authorized_keys do usuário correspondente.

Desativar login por senha e endurecer SSH (hardening básico)

Conceito

O alvo mais comum em servidores expostos é o SSH com senha. Ao desativar autenticação por senha e impedir login direto do root, você corta uma grande parte de ataques automatizados.

Roteiro de hardening básico (compatível com iniciantes)

Antes de mudar qualquer coisa: confirme que você consegue acessar o servidor com chave SSH usando um usuário não-root.

Passo a passo: ajustar configuração do SSH

Edite o arquivo:

sudo nano /etc/ssh/sshd_config

Procure e ajuste (ou adicione) estas linhas:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Opcional (reduz tentativas automáticas, mas exige lembrar a porta):

Port 2222

Reinicie o serviço SSH:

sudo systemctl restart sshd

Teste sem encerrar sua sessão atual: abra um novo terminal e tente conectar novamente. Só depois feche a sessão antiga.

Proteção adicional simples: Fail2ban (opcional)

Fail2ban bloqueia IPs que fazem muitas tentativas de login. Para Ubuntu/Debian:

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban

Para Amazon Linux/RHEL-like (se disponível no repositório):

sudo dnf install fail2ban -y
sudo systemctl enable --now fail2ban

Princípio do menor privilégio no IAM (sem reinventar o que você já fez)

Conceito

Menor privilégio significa dar apenas as permissões necessárias para uma tarefa específica, pelo tempo necessário. Isso reduz o impacto de erros e de credenciais comprometidas.

Práticas objetivas para aplicar agora

• Separe perfis por função: um perfil para administração (uso raro) e outro para operação do dia a dia (permissões limitadas).
• Evite chaves de acesso permanentes quando não forem necessárias. Prefira acesso via console com MFA e/ou papéis (roles) quando aplicável.
• Escopo por recurso: sempre que possível, restrinja políticas a ARNs específicos (ex.: apenas uma instância, apenas um bucket, apenas uma zona).
• Escopo por condição: use condições como região, tags e MFA (quando fizer sentido).

Exemplo prático: política limitada por tags

Um padrão útil é permitir ações apenas em recursos com tags específicas (por exemplo, Projeto=SiteIniciante e Ambiente=Prod). Exemplo ilustrativo (ajuste serviços e ações ao seu caso):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowDescribe",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeTags"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowStartStopOnlyTagged",
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/Projeto": "SiteIniciante",
          "ec2:ResourceTag/Ambiente": "Prod"
        }
      }
    }
  ]
}

Esse tipo de abordagem força disciplina de tags e evita que alguém opere recursos fora do escopo do projeto.

Inventário do que foi criado: controle simples que evita confusão

Conceito

Inventário é uma lista viva dos recursos criados, com finalidade, dono e ambiente. Isso reduz “recursos órfãos”, facilita troubleshooting e ajuda a controlar custos.

Modelo prático de inventário (tabela)

Você pode manter isso em um arquivo versionado (ex.: repositório Git do projeto) ou em uma planilha compartilhada, desde que exista um “local oficial”.

Tags padronizadas: Projeto, Ambiente, Dono, Custo

Conceito

Tags são metadados que ajudam a organizar, filtrar, delegar e cobrar custos. Um padrão mínimo já resolve grande parte do caos.

Padrão recomendado (mínimo)

• Projeto: nome do projeto (ex.: SiteIniciante).
• Ambiente: Dev, Homolog, Prod.
• Dono: time ou responsável (ex.: time-web ou e-mail).
• Custo: centro de custo/agrupador (ex.: Web, Infra).

Boas práticas de padronização

• Valores consistentes: evite variações como prod, Prod, PROD. Defina um padrão e siga.
• Tag em tudo que for possível: instâncias, volumes, IPs elásticos, grupos, buckets, etc.
• Use tags para controle: políticas IAM podem restringir ações por tags (como no exemplo anterior).

Registro de mudanças (change log): rastreabilidade sem burocracia

Conceito

Registrar mudanças evita “ninguém sabe o que foi alterado” e acelera a recuperação quando algo quebra. Para iniciantes, um registro simples já funciona.

Modelo prático de change log

O que sempre registrar

• Alterações de acesso (IAM, usuários do servidor, chaves SSH).
• Alterações de rede/portas (ex.: SSH mudou de porta).
• Atualizações relevantes (kernel, web server, bibliotecas críticas).
• Criação/remoção de recursos (para manter inventário coerente).

Guia de revisão periódica de acessos (rotina prática)

Objetivo

Garantir que apenas as pessoas certas tenham acesso, com o nível certo, e que credenciais antigas não permaneçam válidas.

Roteiro mensal (15–30 minutos)

• Servidor: listar usuários com acesso SSH e confirmar se ainda precisam.
• Chaves SSH: revisar authorized_keys dos usuários; remover chaves antigas/desconhecidas.
• SSH: confirmar que PasswordAuthentication continua desativado e PermitRootLogin continua no.
• Atualizações: verificar se há atualizações pendentes e aplicar.

Roteiro trimestral (30–60 minutos)

• IAM: revisar usuários/grupos/políticas anexadas; remover permissões não usadas; checar se há credenciais antigas.
• Chaves e segredos: confirmar que não há chaves em repositórios, backups ou arquivos soltos.
• Inventário e tags: procurar recursos sem tags e corrigir; validar Dono/Custo.
• Recursos não utilizados: identificar e remover o que não é mais necessário (com cuidado e registro).

Comandos úteis no servidor para auditoria rápida

Ver usuários humanos (varia por distro, mas ajuda):

cut -d: -f1 /etc/passwd

Ver tentativas de SSH (Ubuntu/Debian):

sudo tail -n 200 /var/log/auth.log

Ver tentativas de SSH (RHEL-like/Amazon Linux):

sudo tail -n 200 /var/log/secure

Hardening básico: roteiro resumido para aplicar em ordem segura

1. Garanta acesso por chave com um usuário nomeado (não-root).

2. Atualize o sistema e reinicie se necessário.

3. Endureça o SSH: PermitRootLogin no, PasswordAuthentication no.

4. Revise usuários: remova contas antigas e evite compartilhamento.

5. Implemente tags padrão em recursos e atualize o inventário.

6. Restrinja IAM por menor privilégio e, quando possível, por tags.

7. Crie/atualize o change log com o que foi feito e como reverter.

8. Agende revisões: mensal (acessos/SSH/updates) e trimestral (IAM/tags/inventário).