Todos os cursos > Tecnologia, Informática e Programação > Servidores Web e Redes de computadores ::

AWS para Iniciantes: Checklist final de implantação segura do site e próximos passos práticos

Capítulo 11

Tempo estimado de leitura: 9 minutos

Checklist operacional de implantação segura (o que precisa estar verdadeiro antes de “abrir” o site)

Este capítulo consolida tudo em um checklist prático para você validar, em poucos minutos, se o site está realmente pronto para receber acesso externo com segurança e previsibilidade. A ideia é transformar “acho que está certo” em “está comprovadamente certo”, com verificações objetivas e um roteiro de testes ponta a ponta.

1) Conta e acesso: itens obrigatórios de segurança

Root protegido e guardado: root sem uso diário, com MFA habilitado e credenciais armazenadas com segurança.
MFA para usuários humanos: usuários/roles administrativas com MFA obrigatório.
IAM com menor privilégio: permissões apenas do necessário para operar a instância, DNS e certificados; sem políticas amplas do tipo *:*.
Chaves de acesso (Access Keys) minimizadas: evitar chaves para usuários humanos; preferir acesso via console com MFA e/ou roles.
CloudTrail/registro de auditoria: trilhas habilitadas e você sabe onde consultar eventos (quem fez o quê e quando).

2) Rede e exposição: VPC e rotas sem surpresas

Sub-rede correta: a instância está na sub-rede planejada (pública se você expõe direto; privada se houver camada intermediária).
Rota para Internet: se a instância precisa ser acessível publicamente, a tabela de rotas da sub-rede aponta para o Internet Gateway.
IP público/EIP: existe um endereço público consistente (Elastic IP) ou você tem certeza de como o IP muda e como o DNS acompanha.
NACLs (se usados): não estão bloqueando portas necessárias (entrada/saída) para HTTP/HTTPS e respostas.

3) Security Groups: mínimo necessário, nada além

Entrada (Inbound): apenas 80/tcp (HTTP) e/ou 443/tcp (HTTPS) a partir de 0.0.0.0/0 e ::/0 (se IPv6 estiver em uso). SSH (22/tcp) restrito ao seu IP (ou desabilitado se não for necessário).
Saída (Outbound): permitir o necessário para atualizações e dependências (tipicamente saída liberada, ou regras específicas se você estiver restringindo).
Sem portas “temporárias” esquecidas: remover regras abertas para testes (ex.: 0-65535).

4) EC2 e serviço web: o site responde como esperado

Instância saudável: status checks 2/2 OK.
Servidor web ativo: serviço (Nginx/Apache) iniciado e habilitado para subir com o boot.
Conteúdo correto: página/arquivos do site no diretório esperado e permissões corretas.
Firewall do SO (se habilitado): liberando 80/443.
Logs acessíveis: você sabe onde ver logs do web server e do sistema para diagnosticar falhas.

5) Armazenamento: persistência e espaço sob controle

EBS anexado e montado (se aplicável): ponto de montagem correto e persistência após reboot.
Espaço em disco: volume com tamanho suficiente e monitorado (evitar “disco cheio” derrubando o site).
Permissões de arquivos: usuário do servidor web consegue ler o conteúdo; escrita apenas onde necessário.

6) DNS: resolução correta e previsível

Registros corretos: A/AAAA (ou CNAME quando aplicável) apontando para o destino certo.
TTL adequado: TTL não está exageradamente alto durante mudanças (para facilitar correções).
Propagação verificada: você testou resolução em mais de um resolvedor (ex.: seu provedor e um público).

7) HTTPS: plano validado e teste real no navegador

Certificado válido: domínio correto (CN/SAN), não expirado.
Redirecionamento: se você decidiu forçar HTTPS, o HTTP redireciona para HTTPS.
Conteúdo misto: sem recursos HTTP dentro de página HTTPS (imagens/scripts).
Cadeia de confiança: navegador não apresenta alerta de certificado.

8) Custos e operação: monitoramento mínimo para não ser pego de surpresa

Orçamentos/alertas: budget configurado com alertas por e-mail.
Recursos “sobrando”: sem instâncias paradas esquecidas, volumes órfãos, IP elástico não associado, snapshots desnecessários.
Tags básicas: pelo menos Name, Owner, Env (ex.: prod/dev) para facilitar auditoria e custos.

Roteiro de validação ponta a ponta (do navegador ao servidor)

Use este roteiro sempre que publicar uma mudança relevante (DNS, Security Group, certificado, atualização do servidor). Ele segue a cadeia real: navegador → DNS → rede → portas → serviço web → conteúdo.

Passo 1 — Validar DNS (antes de culpar o servidor)

No seu computador, verifique se o domínio resolve para o IP esperado:

nslookup seudominio.com

Se você usa IPv6:

nslookup -type=AAAA seudominio.com

Valide também com um resolvedor público para evitar cache local:

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

nslookup seudominio.com 8.8.8.8

O que deve acontecer: o IP retornado deve ser o IP público/EIP correto (ou o destino que você planejou).

Passo 2 — Testar conectividade de porta (rede e Security Group)

Teste se as portas estão acessíveis externamente:

curl -I http://seudominio.com

Se HTTPS estiver ativo:

curl -I https://seudominio.com

Se quiser testar direto no IP (para separar DNS de conectividade):

curl -I http://SEU_IP_PUBLICO

O que deve acontecer: você deve receber um status HTTP (ex.: 200, 301, 302). Timeouts geralmente indicam bloqueio de rede/porta.

Passo 3 — Validar o certificado e o handshake TLS (quando houver HTTPS)

Verifique se o certificado apresentado corresponde ao domínio:

curl -Iv https://seudominio.com

O que deve acontecer: sem erros de validação de certificado. Se houver erro, pode ser certificado errado, cadeia incompleta, ou o tráfego não está chegando no endpoint correto.

Passo 4 — Validar o serviço web dentro da instância

Conecte na instância (método que você já utiliza) e teste localmente:

curl -I http://localhost

Confira status do serviço:

sudo systemctl status nginx

sudo systemctl status httpd

O que deve acontecer: serviço “active (running)” e resposta HTTP local.

Passo 5 — Validar logs para confirmar o caminho completo

Faça um acesso pelo navegador e, em seguida, verifique se o request apareceu nos logs do servidor web. Exemplos comuns:

Nginx: /var/log/nginx/access.log e /var/log/nginx/error.log
Apache: /var/log/httpd/access_log e /var/log/httpd/error_log (ou variações)

O que deve acontecer: o acesso externo gera uma linha no access log. Se não gera, o tráfego não está chegando até o serviço.

Cenários de falha comuns (com diagnóstico guiado)

A tabela abaixo ajuda a identificar rapidamente onde está o problema com base no sintoma.

Sintoma	Causa provável	Como confirmar	Correção típica
Domínio não resolve (NXDOMAIN)	Registro DNS ausente/errado; zona errada	`nslookup seudominio.com` retorna NXDOMAIN	Corrigir/ criar registro na hosted zone correta; conferir nameservers no registrador
Domínio resolve, mas abre outro site	IP/registro apontando para destino antigo	`nslookup` mostra IP inesperado	Ajustar registro A/AAAA; reduzir TTL durante migração
Timeout ao acessar HTTP/HTTPS	Security Group bloqueando; rota/sub-rede sem saída; NACL bloqueando	`curl -I` fica pendurado; logs do servidor não registram acesso	Liberar portas 80/443 no SG; revisar rota para IGW; revisar NACL
Connection refused	Porta fechada no servidor (serviço parado) ou firewall do SO	`curl -I http://SEU_IP` retorna refused; `systemctl status` mostra serviço parado	Iniciar/habilitar serviço; liberar porta no firewall do SO
HTTP 403 Forbidden	Permissão de arquivos/diretório; configuração do web server	Access log registra request; error log indica “permission denied”	Ajustar permissões/owner; revisar config de root do site
HTTP 404 Not Found	Conteúdo no caminho errado; virtual host/server block incorreto	Access log registra; error log pode indicar arquivo inexistente	Corrigir diretório do site; ajustar configuração do servidor
HTTPS com alerta de certificado	Certificado não corresponde ao domínio; expirado; endpoint errado	Navegador alerta; `curl -Iv` mostra CN/SAN diferente	Usar certificado correto; revisar associação do certificado ao endpoint; renovar
HTTPS funciona, mas alguns itens não carregam	Conteúdo misto (HTTP dentro de HTTPS)	Console do navegador mostra “Mixed Content”	Atualizar URLs para HTTPS; ajustar links/recursos
Site instável após reboot	Serviço não sobe no boot; volume não monta automaticamente	Após reiniciar, `systemctl status` mostra inativo; `df -h` sem mount	Habilitar serviço (`enable`); configurar montagem persistente
Custo inesperado	Recursos órfãos; tráfego; snapshots/volumes; IP elástico solto	Billing/Cost Explorer mostra aumento; inventário de recursos	Remover recursos não usados; ajustar tamanho; criar alertas e revisar periodicamente

Checklist rápido de “pronto para produção” (versão curta para repetir sempre)

Acesso: MFA ativo; root guardado; IAM mínimo.
DNS: resolve para o destino certo em mais de um resolvedor.
Portas: 80/443 acessíveis; SSH restrito.
Servidor: serviço web rodando e habilitado no boot; logs ok.
HTTPS: certificado válido; sem alertas; redirecionamento conforme planejado.
Custos: budget/alertas ativos; sem recursos órfãos.

Próximos passos práticos (evolução moderada, sem arquiteturas complexas)

1) Automação simples de operação

Script de verificação: crie um script local que rode nslookup + curl -I e registre data/hora do teste para você ter histórico.
Atualizações com rotina: defina uma janela semanal/quinzenal para aplicar updates do sistema e reiniciar o serviço web de forma controlada.

2) Backups essenciais (o mínimo que salva seu dia)

Snapshot do volume: agende snapshots do EBS (ex.: diário com retenção curta) para recuperar rapidamente após erro humano.
Cópia do conteúdo do site: mantenha o conteúdo versionado (ex.: repositório) ou sincronizado para um local seguro, para reconstrução rápida.

3) Monitoramento básico e alertas úteis

Uptime externo: monitore HTTP/HTTPS (status code e tempo de resposta) para saber quando o site caiu.
Métricas da instância: CPU, disco (uso), rede; alarme para “disco quase cheio”.
Alertas de segurança: notificações para mudanças críticas (ex.: alteração em Security Group, criação de chaves, login suspeito).

4) Higiene operacional (reduz incidentes)

Inventário mensal: revisar instâncias, volumes, snapshots, IPs elásticos, regras de SG e registros DNS.
Padronização: documentar em um arquivo simples (runbook) o que foi configurado, onde ficam logs e como reiniciar o serviço.
Teste de restauração: pelo menos uma vez, restaurar um snapshot em um ambiente de teste para garantir que o backup é utilizável.

Agora responda o exercício sobre o conteúdo:

Ao validar um site recém-implantado na AWS, qual sequência de verificação ajuda a identificar rapidamente onde está a falha antes de culpar o servidor?

Você acertou! Parabéns, agora siga para a próxima página

Você errou! Tente novamente.

A validação ponta a ponta segue a cadeia real: primeiro confirme que o domínio resolve corretamente, depois se as portas respondem, em seguida valide o TLS (se aplicável) e só então investigue serviço e logs na instância.