SEMANA 01 · AULA 01 · 45–60 MINUTOS · ESSENCIAL + DESAFIO PROFISSIONAL
← Voltar à trilha de 12 semanas · Read in English
Engenharia de Segurança não é decorar ferramentas nem tentar invadir tudo. É tornar sistemas mais seguros desde o projeto, entender quais riscos importam, implementar proteções e comprovar que funcionam. Hoje você assumirá o papel de engenheiro de segurança de um pequeno SaaS fictício.
O que você vai entregar: uma revisão de segurança de uma página, com desenho do sistema, três riscos, três controles e uma maneira de testar cada controle. Guarde o resultado: é a primeira peça do seu portfólio de estudos.
1. O que você aprenderá?
- Diferenciar ativo, ameaça, vulnerabilidade, risco e controle de segurança.
- Entender o que um engenheiro de segurança entrega a uma empresa.
- Transformar uma preocupação vaga em um requisito técnico verificável.
- Priorizar melhorias úteis, sem fazer uma lista infinita de ferramentas.
2. A mentalidade de um engenheiro de segurança
Faça quatro perguntas, nessa ordem: O que é importante? O que pode dar errado? Como reduzir o risco? Como saberemos se funcionou?
Ativo: algo valioso, como dados dos clientes ou disponibilidade do serviço. Ameaça: possível causa de dano. Vulnerabilidade: fraqueza que pode ser explorada ou causar falha. Risco: cenário de dano considerando probabilidade e impacto. Controle: medida para reduzir o risco, como validação de permissões, MFA, monitoramento ou backups testados.
O NIST Cybersecurity Framework 2.0 organiza o trabalho de segurança em seis funções complementares:
- Governar (Govern): definir responsáveis, objetivos e riscos aceitáveis.
- Identificar (Identify): conhecer sistemas, dados e dependências importantes.
- Proteger (Protect): aplicar menor privilégio, criptografia e outras barreiras.
- Detectar (Detect): perceber atividades inesperadas ou suspeitas.
- Responder (Respond): conter e investigar incidentes.
- Recuperar (Recover): restaurar serviços e aprender com as falhas.
Uma única pessoa não precisa cuidar de todas essas funções. O engenheiro de segurança colabora com desenvolvimento, nuvem, infraestrutura e resposta a incidentes. A entrega importante é uma proteção funcionando e acompanhada de evidências — não apenas uma apresentação de recomendações.
3. Sua empresa fictícia: OrderDesk
A OrderDesk ajuda pequenos negócios a receber pedidos. Ela tem um site, uma API, um banco PostgreSQL e armazenamento de arquivos anexos. Cada lojista faz login para ver apenas seus próprios pedidos. Administradores gerenciam a plataforma. Os registros dos clientes incluem nomes, telefones e dados de entrega.
Durante a primeira conversa, você ouve três frases preocupantes:
- “Os IDs dos pedidos são sequenciais, e não tenho certeza se a API verifica a qual lojista cada pedido pertence.”
- “Os administradores usam senha, mas não habilitamos MFA nem revisamos alertas de tentativas de login.”
- “Fazemos backup do banco toda noite. Ninguém lembra o último teste de restauração.”
Esses pontos são hipóteses para investigar, não incidentes confirmados. Sua tarefa é transformar cada hipótese em verificação, decisão e melhoria concreta.
4. Laboratório prático — faça uma revisão de segurança (30 minutos)
Etapa A — Desenhe o sistema (5 minutos)
No papel ou em um editor de diagramas, desenhe: Navegador do cliente → Site/API → PostgreSQL, além de API → armazenamento de arquivos. Marque a fronteira entre a conta de um lojista e os dados de outro. Indique onde os administradores fazem login. Não é preciso contratar serviços nem criar contas.
Etapa B — Monte seu registro de riscos (10 minutos)
Copie a tabela para suas anotações e procure melhorá-la com suas próprias palavras:
| Ativo | O que pode dar errado? | Controle | Como comprovar? |
|---|---|---|---|
| Pedidos dos lojistas | Lojista A acessa pedidos do lojista B | Autorização no servidor a cada requisição | Com contas fictícias de teste, A não acessa pedido de B (403/404) |
| Contas administrativas | Senha roubada permite acesso privilegiado | MFA, menor privilégio e monitoramento | Testar MFA e alertas com contas de teste |
| Banco de pedidos | Exclusão ou falha causa perda prolongada de dados | Backups protegidos e plano de recuperação | Restaurar em ambiente isolado e conferir registros |
Etapa C — Defina as prioridades (10 minutos)
Para cada risco, anote impacto (baixo/médio/alto), probabilidade (baixa/média/alta) e o que você ainda não sabe. Escolha as três ações mais importantes. Explique o motivo antes de escolher alguma ferramenta. São avaliações qualitativas, não uma fórmula matemática exata de risco.
Etapa D — Escreva critérios de aceitação (5 minutos)
Transforme o maior risco em uma tarefa que possa ser testada. Exemplo: “Quando o lojista A estiver autenticado, solicitar um pedido pertencente ao lojista B nunca pode revelar dados de B. A API precisa validar a autorização independentemente da interface.” Diga como você verificaria isso com contas e dados sob seu controle.
5. Teste suas decisões
Responda mentalmente às perguntas abaixo antes de revelar os gabaritos. Se errar, tente identificar qual suposição levou à resposta.
Pergunta 1 — O lojista A consegue ler o pedido de B. Esconder o link na interface resolve?
Não. Restrições na interface não substituem autorização. A API precisa conferir se o lojista autenticado é dono de cada pedido solicitado. Comprove a proteção usando duas contas fictícias e um teste negativo.
Pergunta 2 — O backup roda toda noite. Isso prova que a OrderDesk consegue recuperar os dados?
Não. Um backup bem-sucedido é apenas parte da evidência. Restaure uma cópia em ambiente isolado, verifique a integridade dos dados e meça quanto tempo a recuperação leva.
Pergunta 3 — Qual entrega é melhor: “Habilitar MFA” ou “MFA administrativo implementado e testado”?
A segunda. Um controle testado tem responsável, critério de aceitação e evidência. “Habilitar MFA” pode continuar sendo apenas uma recomendação no papel. Engenharia de Segurança busca resultados que podemos verificar.
6. Desafio profissional (opcional, 20 minutos)
Se você programa, implemente um pequeno teste automatizado de autorização negativa em um projeto local seu: crie dois lojistas fictícios e um pedido para o lojista B; autentique-se como A; solicite o pedido de B; verifique que nenhum dado sensível é retornado e que a resposta é 403 ou 404. Quando fizer sentido, teste também as rotas de listagem e atualização. Nunca teste sistemas de terceiros sem autorização.
Se você ainda não programa, descreva três casos de teste em linguagem natural. Um teste bem pensado também é trabalho de engenharia.
7. Confira sua entrega
- ☐ Desenhei os componentes e pelo menos uma fronteira de confiança.
- ☐ Identifiquei três ativos e possíveis cenários de falha.
- ☐ Escolhi controles, responsáveis e prioridades.
- ☐ Cada controle tem uma maneira de verificar sua eficácia.
- ☐ Consigo explicar minha decisão mais importante em duas frases.
Autoavaliação: 5/5 significa que você concluiu a aula; abaixo disso, revise os pontos faltantes. Salve seu diagrama e registro de riscos como aula-01-revisao-de-seguranca nas suas notas ou portfólio. Não publique dados reais, credenciais nem detalhes internos sensíveis.
8. Entre na cultura de segurança
Leia a introdução de OWASP Top 10:2025 — Controle de Acesso Quebrado e conheça o NIST NICE Framework. Perceba a diferença entre conhecer o nome de uma vulnerabilidade e ser responsável por uma melhoria comprovável de segurança.
Reflexão final: O que você protegeria primeiro na OrderDesk e qual evidência mostraria que a proteção funciona? Escreva três frases. Próxima aula: Aula 02 — Confidencialidade, Integridade e Disponibilidade na Prática.