🚀 Capítulo 18: Segurança na Engenharia (Tema: Batman)
NOTE
Este capítulo utiliza a temática de Batman para explicar a Segurança. Não espere o Coringa invadir para colocar trancas na porta: construa a sua Batcaverna protegida desde a fundação!
1. 🎯 Objetivo da Aula
Compreender a importância da segurança na Engenharia de Software, entendendo o conceito de Security by Design (Segurança desde o Projeto) e as práticas básicas para evitar vulnerabilidades no código.
2. 🏢 O Cenário Prático (Seu Desafio)
O Batman não constrói a Batcaverna e só depois de pronta decide colocar um cadeado na porta para evitar que o Coringa entre.
- A Batcaverna é planejada desde a fundação para ser segura.
- Ela tem entradas secretas, reconhecimento de voz, câmeras térmicas e sistemas de defesa automáticos.
- O Batman assume que os vilões vão tentar invadir, e se prepara para isso antes mesmo de acontecer!
Na Engenharia de Software tradicional, muitas equipes cometem o erro de criar o sistema inteiro e só no final perguntar: “E agora, como colocamos segurança nisso?“. Isso é o equivalente a colocar um cadeado em uma porta de vidro! A segurança deve fazer parte do design do sistema desde o primeiro dia. Isso se chama Security by Design. Seu desafio é construir um sistema impenetrável como a Batcaverna!
🧠 Fundamentos: A Teoria Traduzida
🛡️ 1. Security by Design:
Significa que o software foi projetado desde o início para ser seguro. A segurança não é uma camada extra; ela está na raiz do projeto.
🔑 2. Princípios Básicos de Segurança no Código:
A. Nunca Confie na Entrada do Usuário:
Tudo o que o usuário digita pode ser uma tentativa de ataque. O sistema deve validar e limpar todos os dados antes de processar.
- Exemplo: Se o campo pede a idade, e o usuário digita um código malicioso em SQL, o sistema deve recusar!
B. Princípio do Menor Privilégio:
Um usuário (ou uma parte do sistema) só deve ter acesso àquilo que é estritamente necessário para ele fazer o seu trabalho.
- Exemplo: O programador estagiário não precisa ter a senha do banco de dados de produção da empresa. O atendente do suporte não precisa ver os dados do cartão de crédito do cliente.
C. Defesa em Profundidade:
Não dependa de apenas uma barreira de segurança. Use várias camadas. Se o invasor passar pela primeira (firewall), ele deve dar de cara com a segunda (criptografia) e com a terceira (autenticação).
4. 📖 Exemplo Guiado: O Teste de Invasão
Como sabemos se a Batcaverna está segura? O Batman pede para o Asa Noturna ou para o Robin tentarem invadir! No software, fazemos a mesma coisa através do Pentest (Teste de Penetração). Contratamos hackers éticos (do bem) para tentarem invadir o nosso sistema. Eles nos entregam um relatório dizendo onde estão as falhas para que possamos corrigi-las antes que os “vilões” de verdade as descubram!
5. 🛠️ Prática Obrigatória 1: Falha de Segurança
Identifique qual princípio de segurança foi violado nas situações abaixo:
- O sistema de um hospital permite que qualquer funcionário (incluindo os faxineiros e os cozinheiros) acesse e altere o prontuário médico secreto de qualquer paciente.
- O sistema aceitou que um usuário digitasse caracteres no campo “Nome” (que deveria ter no máximo 50), fazendo o banco de dados travar por falta de memória.
6. 🛠️ Prática Obrigatória 2: O Cadeado na Porta de Vidro
Por que tentar adicionar segurança apenas no final do projeto (depois que o sistema já está programado) costuma ser muito mais difícil e ineficiente do que pensar nela desde o início?
7. 📤 Instruções de Entrega (GitHub Desktop + Microsoft Teams)
- Faça o Commit: No GitHub Desktop, digite a mensagem (ex:
Finaliza Capítulo 18 EngSoftware) e clique em Commit to main. - Envie para a Nuvem (Push): Clique em Push origin.
8. 📂 Estrutura de Pastas
extra_engenharia_de_software/
├── capitulos/
│ ├── capitulo_18_seguranca.md
│ └── codigos/
│ └── cap18/
│ └── check_seguranca.txt💡 Checkpoint de Lógica
Segurança perfeita não existe. O objetivo da Engenharia de Software é tornar o ataque tão difícil, demorado e caro que o invasor desista e vá procurar outro alvo mais fácil!
10. 🔥 Desafio de Fixação
Pesquise o que é o OWASP Top 10 (A lista das 10 vulnerabilidades mais críticas em aplicações web).
🔑 Gabarito de Código/Fórmulas
Gabarito da Prática 1:
- Princípio do Menor Privilégio. Funcionários que não são médicos não precisam ter acesso a dados clínicos sigilosos dos pacientes.
- Nunca Confie na Entrada do Usuário. O sistema deveria ter validado e limitado o tamanho do texto recebido. Gabarito da Prática 2:
- Porque muitas vulnerabilidades dependem da forma como a arquitetura do sistema foi desenhada (ex: como os dados fluem ou como as tabelas se comunicam). Mudar isso no final pode exigir quebrar e refazer metade do código do sistema, o que custa caro e gera novos bugs!