Pular para conteúdo

Segurança e Criptografia 🔐

Proteja dados, sistemas e comunicações com os fundamentos que sustentam toda a segurança digital moderna. Do funcionamento interno de um algoritmo de criptografia até a defesa prática de uma aplicação web real.

O que você vai dominar

Foco: Entenda os princípios de confidencialidade, integridade e disponibilidade, e aprenda a aplicar criptografia simétrica, assimétrica, hashing e autenticação para proteger sistemas de verdade.

🎯 Por que aprender Segurança e Criptografia?

  • Base de Tudo em Segurança

    Toda defesa digital — de HTTPS a senhas — depende dos mesmos fundamentos criptográficos.

    Ver Fundamentos

  • Simétrica e Assimétrica

    Entenda quando usar AES, RSA e Diffie-Hellman — e por que eles se complementam.

    Criptografia Assimétrica

  • Senhas e Autenticação

    Aprenda a armazenar credenciais com hashing, salt e boas práticas de mercado.

    Gestão de Senhas

  • Segurança Aplicada

    Leve os conceitos para o mundo real: TLS, OWASP Top 10 e defesa de aplicações web.

    Segurança Web

📚 Estrutura do Curso (16 Aulas)

O curso é dividido em dois módulos estratégicos, dos fundamentos teóricos à aplicação prática no dia a dia de um desenvolvedor.

Módulo 1: Fundamentos de Segurança e Criptografia (Aulas 01-08)

Construa sua base sólida: os pilares da segurança da informação e os algoritmos criptográficos que os sustentam.

Módulo 2: Segurança Aplicada e Boas Práticas de Mercado (Aulas 09-16)

Aplique os fundamentos em cenários reais: redes, código e sistemas em produção.

Success

Pronto para proteger sistemas de verdade? Clique no botão abaixo e comece pelos fundamentos da segurança da informação!

Começar Curso

Plano de Ensino 🧭

Curso: Segurança e Criptografia
Público-alvo: Estudantes de ADS, Ciência da Computação e Desenvolvedores de Software
Carga Horária: 20 Aulas (80 Horas Teórico-Práticas)

🎯 1. Objetivos do Curso

  • Compreender os fundamentos conceituais e arquiteturais de Segurança e Criptografia.
  • Aplicar padrões de projeto, sintaxe moderna e boas práticas da indústria.
  • Desenvolver soluções completas através de exercícios práticos e desafios de projeto.

📚 2. Cronograma de Aulas (Matriz de 20 Semanas)

Aula Tema Central Atividades e Entregas
01 Introdução à Segurança da Informação ️ Teoria, Prática Guiada, Quiz e Exercícios
02 Ameaças, Vulnerabilidades e Ataques ️ Teoria, Prática Guiada, Quiz e Exercícios
03 Fundamentos de Criptografia Teoria, Prática Guiada, Quiz e Exercícios
04 Criptografia Simétrica (AES e DES) Teoria, Prática Guiada, Quiz e Exercícios
05 Criptografia Assimétrica (RSA e Diffie-Hellman) Teoria, Prática Guiada, Quiz e Exercícios
06 Funções de Hash e Integridade #️⃣ Teoria, Prática Guiada, Quiz e Exercícios
07 Assinaturas Digitais e Certificados (PKI) Teoria, Prática Guiada, Quiz e Exercícios
08 Autenticação e Controle de Acesso Teoria, Prática Guiada, Quiz e Exercícios
09 TLS/SSL e Segurança em Redes Teoria, Prática Guiada, Quiz e Exercícios
10 Criptografia na Prática com Python Teoria, Prática Guiada, Quiz e Exercícios
11 Criptografia na Prática com JavaScript Teoria, Prática Guiada, Quiz e Exercícios
12 Segurança em Aplicações Web (OWASP Top 10) ️ Teoria, Prática Guiada, Quiz e Exercícios
13 Gestão e Armazenamento Seguro de Senhas ️ Teoria, Prática Guiada, Quiz e Exercícios
14 Privacidade de Dados e LGPD ️ Teoria, Prática Guiada, Quiz e Exercícios
15 Auditoria e Testes de Segurança Teoria, Prática Guiada, Quiz e Exercícios
16 Projeto Final: Sistema de Autenticação Seguro Teoria, Prática Guiada, Quiz e Exercícios
17 Criptografia Assimétrica Avançada (RSA, ECC e DH) Teoria, Prática Guiada, Quiz e Exercícios
18 Protocolos Criptográficos e Cifras de Bloco (AES-GCM) Teoria, Prática Guiada, Quiz e Exercícios
19 Análise de Vulnerabilidades, Fuzzing e Engenharia Reversa Teoria, Prática Guiada, Quiz e Exercícios
20 Projeto Capstone: Módulo de Criptografia e Segurança Autônomo Teoria, Prática Guiada, Quiz e Exercícios

🧠 3. Metodologia de Ensino

  • Teoria Fundamentada: Aulas com conceitos detalhados, diagramas arquiteturais e sintaxe de referência.
  • Ciclo Teoria ⇄ Prática: Cada aula conta com Quiz Interativo (10 questões) para validação imediata, Lista de Exercícios Sanfonados (com Gabarito Explicado) e Desafio de Projeto Prático.
  • Laboratório Contínuo: Ambientes configurados passo a passo na seção de Setups da plataforma.

💼 4. Competências e Perfil Desenvolvido

  • Dominar as ferramentas e fluxos de desenvolvimento de Segurança e Criptografia.
  • Resolver problemas técnicos de alta complexidade com código limpo e performático.
  • Construir portfólio prático com 20 projetos aplicados.

📊 5. Critérios de Avaliação

  • 20 Listas de Exercícios: Resolução individual dividida em Básico, Intermediário e Desafio.
  • 20 Quizzes Interativos: Validação formativa com feedback imediato via JavaScript.
  • 20 Desafios de Projetos: Aplicações práticas consolidando o aprendizado de cada unidade.

Aulas

Aulas do Curso

Bem-vindo à seção de aulas! Aqui você encontra todo o conteúdo do curso organizado em 5 módulos estruturados.

📚 Módulos do Curso

Aula 01 – Introdução à Segurança da Informação 🛡️

Bem-vindo à primeira aula do curso de Segurança e Criptografia! Antes de aprender a proteger sistemas, você precisa entender o que exatamente está protegendo — e de quem.

🧐 O que é Segurança da Informação?

Segurança da Informação é o conjunto de práticas, tecnologias e políticas que protegem dados contra acesso não autorizado, alteração indevida ou indisponibilidade. Não é só "instalar um antivírus" — é um processo contínuo que envolve pessoas, processos e tecnologia.

Conceito Chave

Segurança não é um produto que você compra e instala — é um processo que você pratica continuamente.

🔺 A Tríade CIA (CID)

Todo conceito de segurança da informação parte de três pilares fundamentais:

Pilar Sigla O que significa Exemplo de violação
Confidencialidade C Só quem tem permissão acessa a informação Vazamento de senha em texto claro
Integridade I A informação não é alterada sem autorização Um invasor altera o valor de uma transferência
Disponibilidade D A informação está acessível quando necessário Um ataque DDoS derruba um site 
graph TD
    A["Segurança da Informação"] --> B["Confidencialidade"]
    A --> C["Integridade"]
    A --> D["Disponibilidade"]
    B --> E["Criptografia, Controle de Acesso"]
    C --> F["Hash, Assinatura Digital"]
    D --> G["Backup, Redundância"]

🎯 Quem são os "adversários"?

Antes de defender, é preciso saber contra quem:

  1. Script kiddies: usam ferramentas prontas, sem entender profundamente como funcionam.
  2. Hackers individuais: buscam desafio, reconhecimento ou ganho financeiro pequeno.
  3. Grupos criminosos organizados: ransomware, roubo de dados em massa, fraude financeira.
  4. Insiders: funcionários ou ex-funcionários com acesso legítimo que abusam dele.
  5. Atores estatais (APT): grupos altamente sofisticados, geralmente ligados a governos.

💻 Segurança na Prática do Dia a Dia

$ # Verificando o certificado de uma conexao HTTPS $ curl -vI https://example.com 2>&1 | grep "SSL certificate" $ $ # Verificando portas em escuta na propria maquina $ netstat -ano | findstr LISTEN

Dica

A tríade CID não é só teoria de prova — toda decisão de segurança que você tomar na carreira (que dado criptografar, quem pode acessar o quê, quanto investir em backup) volta a um desses três pilares.

📝 Resumo da Aula

  • Segurança da informação protege confidencialidade, integridade e disponibilidade (CID).
  • Segurança é processo contínuo, não produto único.
  • Existem diferentes perfis de adversário, com motivações e sofisticação muito diferentes.

Na próxima aula, vamos entender como esses adversários realmente atacam — ameaças, engenharia social e vetores de ataque mais comuns.

Ir para Aula 02

Aula 02 – Ameaças, Vulnerabilidades e Ataques 🕵️

Para defender um sistema, você precisa entender como ele é atacado. Nesta aula vamos mapear o vocabulário e os vetores de ataque mais comuns — a base de qualquer análise de risco.

🧩 Ameaça x Vulnerabilidade x Risco

Esses três termos são frequentemente confundidos, mas têm significados bem distintos:

Termo Definição Exemplo
Ameaça Algo com potencial de causar dano Um invasor, um vírus, um incêndio
Vulnerabilidade Uma fraqueza que pode ser explorada Senha fraca, software desatualizado
Risco A probabilidade de uma ameaça explorar uma vulnerabilidade Chance real de um invasor quebrar uma senha fraca

Fórmula Mental

Risco = Ameaça × Vulnerabilidade × Impacto. Reduzir qualquer um dos três reduz o risco total.

🎭 Engenharia Social

A engenharia social explora a psicologia humana, não falhas técnicas. É frequentemente o elo mais fraco de qualquer sistema.

  • Phishing: e-mails falsos que imitam bancos, empresas ou colegas para roubar credenciais.
  • Spear Phishing: phishing direcionado a uma pessoa específica, com informações personalizadas.
  • Pretexting: criar uma história falsa (ex: "sou do suporte técnico") para obter informações.
  • Baiting: deixar um pendrive infectado "esquecido" para que alguém o conecte por curiosidade.
graph TD
    A["Atacante pesquisa a vítima"] --> B["Cria um pretexto convincente"]
    B --> C["Contata a vítima (e-mail, telefone, mensagem)"]
    C --> D{"Vítima cai no golpe?"}
    D -- Sim --> E["Credenciais ou acesso comprometidos"]
    D -- Não --> F["Ataque falha, mas pode ser reportado"]

🕳️ Vetores de Ataque Técnicos Mais Comuns

  1. Força bruta: tentar todas as combinações possíveis de senha até acertar.
  2. Injeção: inserir código malicioso em campos de entrada (veremos SQL Injection na Aula 12).
  3. Man-in-the-Middle (MITM): interceptar comunicação entre duas partes sem que elas percebam.
  4. Ataques de negação de serviço (DoS/DDoS): sobrecarregar um sistema até torná-lo indisponível.

💻 Verificando Exposição Básica

$ # Verificando se uma senha ja apareceu em vazamentos conhecidos (Have I Been Pwned API) $ curl -s "https://api.pwnedpasswords.com/range/5BAA6" | head -3 $ $ # Verificando cabecalhos de seguranca de um site $ curl -sI https://example.com | grep -i "strict-transport\|x-frame\|content-security"

Dica

O serviço Have I Been Pwned usa k-anonimato: você envia só os 5 primeiros caracteres do hash SHA-1 da senha, nunca a senha em si.

📝 Exercícios de Fixação

  1. Básico: Explique com suas palavras a diferença entre ameaça, vulnerabilidade e risco, usando um exemplo do seu dia a dia.
  2. Básico: Cite 3 sinais que ajudam a identificar um e-mail de phishing.
  3. Intermediário: Por que engenharia social costuma ser mais eficaz que ataques puramente técnicos?
  4. Intermediário: O que diferencia um ataque DoS de um DDoS?
  5. Desafio: Pesquise um caso real de vazamento de dados causado por engenharia social e resuma o vetor de ataque usado.

🚀 Mini-Projeto: Caçador de Phishing

Objetivo: Analisar um e-mail suspeito (real ou simulado) e listar os indicadores de phishing encontrados.

  1. Encontre (ou peça para um colega simular) um e-mail suspeito.
  2. Verifique: o domínio do remetente bate com a empresa? Há erros de português? O link do botão aponta para onde parece apontar (passe o mouse sem clicar)?
  3. Documente pelo menos 3 indicadores encontrados e explique por que cada um é suspeito.

Ir para Aula 03

Aula 03 – Fundamentos de Criptografia 🔐

Bem-vindo à parte mais matemática (e mais fascinante) do curso! Nesta aula você vai entender os conceitos que sustentam toda a criptografia moderna, dos cadeados de cifra de César aos algoritmos que protegem o seu banco.

🧐 O que é Criptografia?

Criptografia é a ciência de transformar informação legível (texto claro) em algo ilegível (texto cifrado) para quem não possui a chave correta — e de reverter esse processo para quem possui.

Termo Definição
Texto claro (plaintext) A informação original, legível
Texto cifrado (ciphertext) A informação transformada, ilegível sem a chave
Chave O segredo que controla a cifragem/decifragem
Algoritmo (cifra) A regra matemática que transforma texto claro em cifrado 
graph LR
    A["Texto Claro"] -- "Cifragem + Chave" --> B["Texto Cifrado"]
    B -- "Decifragem + Chave" --> A

📜 Um Pouco de História: a Cifra de César

Uma das cifras mais antigas conhecidas — usada por Júlio César — desloca cada letra do alfabeto um número fixo de posições.

  • Chave: deslocamento de 3
  • Texto claro: ATAQUE
  • Texto cifrado: DWDTXH

Por que isso importa hoje?

A cifra de César é trivialmente quebrável (só 25 chaves possíveis), mas ilustra o conceito fundamental que toda cifra moderna usa: transformação reversível controlada por uma chave.

🔑 O Princípio de Kerckhoffs

Um dos pilares da criptografia moderna, formulado no século XIX:

Princípio de Kerckhoffs

A segurança de um sistema criptográfico deve depender apenas do sigilo da chave, nunca do sigilo do algoritmo.

Isso significa que algoritmos como AES e RSA são públicos — qualquer pessoa pode estudar seu funcionamento. A segurança vem inteiramente de manter a chave em segredo, não de "esconder como o sistema funciona" (isso se chama security through obscurity e é considerado uma prática ruim).

🌳 As Duas Grandes Famílias

Existem duas abordagens fundamentais que veremos em detalhe nas próximas duas aulas:

Tipo Como funciona Exemplo Vantagem
Simétrica Mesma chave cifra e decifra AES, DES Rápida
Assimétrica Um par de chaves (pública/privada) RSA, Diffie-Hellman Resolve o problema de troca de chaves

💻 Sua Primeira Cifra em Terminal

$ # Cifra de Cesar simples com tr (deslocamento de 3) $ echo "ATAQUE" | tr 'A-Z' 'D-ZA-C' $ DWDTXH $ $ # Revertendo (deslocamento -3, ou seja, +23) $ echo "DWDTXH" | tr 'A-Z' 'X-ZA-W' $ ATAQUE

📝 Exercícios de Fixação

  1. Básico: Cifre a palavra "SENHA" usando a Cifra de César com deslocamento 5.
  2. Básico: Explique com suas palavras o Princípio de Kerckhoffs e por que ele é importante.
  3. Intermediário: Por que a Cifra de César é insegura mesmo escondendo o deslocamento usado?
  4. Intermediário: Qual a diferença fundamental entre criptografia simétrica e assimétrica?
  5. Desafio: Pesquise o que é um "ataque de força bruta" contra a Cifra de César e calcule quantas tentativas, no máximo, seriam necessárias para quebrá-la.

🚀 Mini-Projeto: Quebrador de Cifra de César

Objetivo: Escrever um script que tenta todos os 25 deslocamentos possíveis de uma Cifra de César e imprime os resultados, para você identificar visualmente qual é o texto original.

  1. Escolha uma linguagem (Python é uma boa opção).
  2. Receba um texto cifrado como entrada.
  3. Para cada deslocamento de 1 a 25, aplique a decifragem e imprima o resultado.
  4. Identifique visualmente qual deslocamento produz um texto com sentido.

Ir para Aula 04

Aula 04 – Criptografia Simétrica (AES e DES) 🔑

Nesta aula vamos mergulhar na criptografia simétrica: rápida, eficiente, e ainda hoje o padrão para cifrar grandes volumes de dados — de arquivos em disco a conexões HTTPS.

🔄 Como Funciona a Criptografia Simétrica

Na criptografia simétrica, a mesma chave é usada para cifrar e decifrar. É como um cadeado comum: quem tem a chave, abre e fecha.

graph LR
    A["Texto Claro"] -- "Cifra com Chave K" --> B["Texto Cifrado"]
    B -- "Decifra com a MESMA Chave K" --> C["Texto Claro"]

O Grande Desafio

Se as duas partes precisam da mesma chave, como transmitir essa chave com segurança sem que um invasor a intercepte? Esse é o "problema da distribuição de chaves" — resolvido pela criptografia assimétrica (Aula 05).

📜 DES: o Padrão Histórico

O DES (Data Encryption Standard) foi o padrão dominante entre 1977 e os anos 2000. Usa chaves de apenas 56 bits — hoje consideradas inseguras, quebráveis por força bruta em horas com hardware moderno.

Não use DES em produção

DES é hoje considerado criptograficamente quebrado. Ele existe no currículo só para contexto histórico. Seu sucessor, o 3DES (Triple DES), também está sendo aposentado em favor do AES.

🛡️ AES: o Padrão Atual

O AES (Advanced Encryption Standard) substituiu o DES em 2001 e é hoje o algoritmo simétrico mais usado no mundo — usado por governos, bancos, VPNs e no próprio HTTPS.

Característica AES
Tamanhos de chave 128, 192 ou 256 bits
Tipo de cifra Cifra de bloco (processa blocos de 128 bits por vez)
Status Considerado seguro até hoje (2026), sem quebra prática conhecida

🧱 Modos de Operação

Como o AES cifra blocos fixos de 128 bits, precisamos de um modo de operação para cifrar mensagens maiores que um bloco:

Modo Descrição Recomendação
ECB Cifra cada bloco de forma independente ❌ Nunca use — padrões repetidos vazam informação
CBC Cada bloco é combinado com o anterior antes de cifrar ✅ Comum, precisa de IV aleatório
GCM CBC + autenticação de integridade embutida ✅ Recomendado — o padrão do HTTPS moderno 
graph TD
    A["ECB: mesmo bloco de entrada = mesmo bloco de saida"] -->|Padrao visivel| B["Vaza estrutura da imagem/dado"]
    C["CBC/GCM: cada bloco depende do anterior"] -->|Sem padrao| D["Saida parece aleatoria"]

💻 Cifrando com AES na Prática

$ # Cifrando um arquivo com AES-256 via OpenSSL $ openssl enc -aes-256-cbc -salt -in segredo.txt -out segredo.enc -pass pass:minhaChaveForte $ $ # Decifrando de volta $ openssl enc -d -aes-256-cbc -in segredo.enc -out segredo_decifrado.txt -pass pass:minhaChaveForte $ cat segredo_decifrado.txt

📝 Exercícios de Fixação

  1. Básico: Por que a criptografia simétrica é considerada "rápida" comparada à assimétrica?
  2. Básico: Cite o tamanho de chave mínimo e máximo suportado pelo AES.
  3. Intermediário: Por que o modo ECB nunca deve ser usado para cifrar imagens ou dados estruturados?
  4. Intermediário: O que é um IV (Vetor de Inicialização) e por que ele precisa ser diferente a cada cifragem?
  5. Desafio: Pesquise por que o modo GCM é considerado superior ao CBC puro em aplicações modernas.

🚀 Mini-Projeto: Cofre de Arquivos

Objetivo: Cifrar e decifrar um arquivo de texto usando AES via linha de comando (OpenSSL) ou uma biblioteca da sua linguagem preferida.

  1. Crie um arquivo segredo.txt com uma mensagem qualquer.
  2. Cifre-o com AES-256 usando uma senha forte.
  3. Tente abrir o arquivo .enc gerado em um editor de texto comum — confirme que é ilegível.
  4. Decifre o arquivo e confirme que o conteúdo original volta intacto.

Ir para Aula 05

Aula 05 – Criptografia Assimétrica (RSA e Diffie-Hellman) 🔓

Como duas pessoas que nunca se conheceram podem trocar mensagens secretas por um canal público, sem nunca terem combinado uma chave antes? É exatamente isso que a criptografia assimétrica resolve.

🗝️ O Par de Chaves

Diferente da criptografia simétrica, a assimétrica usa duas chaves matematicamente relacionadas:

Chave Quem tem acesso Função
Chave Pública Todo mundo Cifra mensagens / verifica assinaturas
Chave Privada Só o dono Decifra mensagens / cria assinaturas 
graph LR
    A["Remetente"] -- "Cifra com Chave PÚBLICA do destinatário" --> B["Texto Cifrado"]
    B -- "Decifra com Chave PRIVADA do destinatário" --> C["Destinatário lê a mensagem"]

A analogia do cadeado aberto

A chave pública é como um cadeado aberto que você distribui livremente. Qualquer um pode fechar (cifrar) uma caixa com ele. Só quem tem a chave privada consegue abrir (decifrar) de novo.

🔢 RSA: a Matemática por Trás

O RSA (Rivest-Shamir-Adleman) baseia sua segurança em um problema matemático simples de enunciar, mas extremamente difícil de resolver: fatorar números primos muito grandes.

  • É fácil multiplicar dois primos gigantes: p × q = n.
  • É computacionalmente inviável, com a tecnologia atual, descobrir p e q só a partir de n, se ambos forem grandes o suficiente (2048+ bits).
Tamanho de chave RSA Status
512 bits ❌ Quebrado
1024 bits ⚠️ Considerado fraco
2048 bits ✅ Padrão mínimo atual
4096 bits ✅ Alta segurança

🤝 Diffie-Hellman: Combinando uma Chave em Público

O Diffie-Hellman (DH) resolve um problema diferente: permitir que duas partes cheguem a uma chave secreta compartilhada, mesmo trocando mensagens por um canal totalmente público e observado por um invasor.

graph TD
    A["Alice escolhe segredo privado a"] --> C["Troca valores públicos"]
    B["Bob escolhe segredo privado b"] --> C
    C --> D["Alice calcula chave secreta usando b público + a privado"]
    C --> E["Bob calcula chave secreta usando a público + b privado"]
    D --> F["Mesma chave secreta compartilhada!"]
    E --> F

Onde isso é usado?

Diffie-Hellman é a base do "handshake" do TLS (Aula 09) — é assim que seu navegador e um servidor combinam uma chave simétrica temporária a cada nova conexão HTTPS.

⚖️ Simétrica vs. Assimétrica: Por que usar as duas juntas?

Simétrica (AES) Assimétrica (RSA)
Velocidade Muito rápida Muito mais lenta
Uso ideal Cifrar grandes volumes de dados Trocar chaves, assinar, autenticar
Problema Como compartilhar a chave? Resolve isso, mas é lenta

Na prática, sistemas reais (como o HTTPS) usam criptografia híbrida: assimétrica para combinar uma chave secreta, e simétrica (AES) para cifrar o tráfego de verdade, rápido.

💻 Gerando um Par de Chaves RSA

$ # Gerando uma chave privada RSA de 2048 bits $ openssl genrsa -out privada.pem 2048 $ $ # Extraindo a chave publica correspondente $ openssl rsa -in privada.pem -pubout -out publica.pem $ cat publica.pem

📝 Exercícios de Fixação

  1. Básico: Explique com suas palavras a diferença entre chave pública e chave privada.
  2. Básico: Por que 512 bits é considerado inseguro para uma chave RSA hoje?
  3. Intermediário: Qual problema o Diffie-Hellman resolve que o RSA sozinho não resolve tão bem?
  4. Intermediário: Por que sistemas reais combinam criptografia simétrica e assimétrica em vez de usar só uma delas?
  5. Desafio: Pesquise o que é "Perfect Forward Secrecy" e por que ele depende do Diffie-Hellman efêmero (DHE/ECDHE).

🚀 Mini-Projeto: Troca de Mensagem Cifrada

Objetivo: Simular a troca de uma mensagem secreta usando um par de chaves RSA.

  1. Gere seu par de chaves (privada + pública) com OpenSSL.
  2. Cifre uma mensagem curta usando a chave pública: openssl rsautl -encrypt -pubin -inkey publica.pem -in mensagem.txt -out mensagem.enc.
  3. Decifre a mensagem usando a chave privada: openssl rsautl -decrypt -inkey privada.pem -in mensagem.enc.
  4. Confirme que a mensagem original é recuperada corretamente.

Ir para Aula 06

Aula 06 – Funções de Hash e Integridade #️⃣

Como saber se um arquivo não foi alterado? Como armazenar senhas sem guardar a senha em si? A resposta para as duas perguntas é a mesma: funções de hash.

🧐 O que é uma Função de Hash?

Uma função de hash pega uma entrada de qualquer tamanho e produz uma saída de tamanho fixo — chamada de "hash" ou "digest". Ela tem três propriedades essenciais:

  1. Determinística: a mesma entrada sempre gera a mesma saída.
  2. Unidirecional: é inviável reverter o hash para descobrir a entrada original.
  3. Efeito avalanche: mudar 1 bit da entrada muda completamente a saída.
graph LR
    A["'senha123'"] --> H["Função de Hash SHA-256"]
    H --> B["ef92b778...e08e (64 caracteres)"]
    C["'senha124'"] --> H2["Função de Hash SHA-256"]
    H2 --> D["a1c3f902...9d1b (completamente diferente!)"]

Hash não é criptografia

Diferente da cifragem, hash não tem chave e não é reversível por design. Não existe "dehash" — só é possível tentar adivinhar a entrada testando valores (força bruta ou tabelas pré-computadas).

📊 Principais Algoritmos de Hash

Algoritmo Tamanho da saída Status
MD5 128 bits ❌ Quebrado, colisões conhecidas — não usar
SHA-1 160 bits ❌ Quebrado, aposentado desde 2017
SHA-256 256 bits ✅ Padrão atual, seguro
SHA-3 224–512 bits ✅ Alternativa moderna, design diferente do SHA-2

MD5 e SHA-1 ainda aparecem em sistemas antigos

Uma colisão acontece quando duas entradas diferentes produzem o mesmo hash. Para MD5 e SHA-1, já existem colisões práticas e documentadas — por isso ambos estão banidos de uso em segurança.

✅ Verificação de Integridade

O uso mais comum de hash no dia a dia: garantir que um arquivo baixado não foi corrompido ou adulterado.

$ # Calculando o hash SHA-256 de um arquivo baixado $ certutil -hashfile instalador.exe SHA256 $ SHA256 hash of instalador.exe: $ ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94 $ $ # Comparando com o hash publicado pelo site oficial $ # Se os dois hashes baterem, o arquivo nao foi alterado

🔐 Hash com Chave: HMAC

O HMAC (Hash-based Message Authentication Code) combina uma função de hash com uma chave secreta, garantindo não só integridade, mas também autenticidade — a prova de que a mensagem veio de quem tem a chave.

  • Hash simples: prova que a mensagem não mudou.
  • HMAC: prova que a mensagem não mudou e veio de quem possui o segredo compartilhado.
graph TD
    A["Mensagem + Chave Secreta"] --> H["HMAC-SHA256"]
    H --> B["Codigo de Autenticacao"]
    B --> C{"Destinatario recalcula com a mesma chave"}
    C -- "Bate" --> D["Mensagem autentica e integra"]
    C -- "Nao bate" --> E["Mensagem alterada ou remetente falso"]

📝 Exercícios de Fixação

  1. Básico: Explique a diferença entre hash e criptografia (cifragem).
  2. Básico: Por que MD5 não deve mais ser usado para hash de senhas?
  3. Intermediário: O que é o "efeito avalanche" e por que ele é uma propriedade desejável em um hash?
  4. Intermediário: Qual a diferença entre um hash simples (SHA-256) e um HMAC?
  5. Desafio: Pesquise o que é um "ataque de aniversário" (birthday attack) contra funções de hash.

🚀 Mini-Projeto: Verificador de Integridade de Arquivos

Objetivo: Criar um script que calcula e compara hashes SHA-256 de arquivos.

  1. Escolha uma linguagem (Python é uma ótima opção com hashlib).
  2. Escreva uma função que recebe o caminho de um arquivo e retorna seu hash SHA-256.
  3. Calcule o hash de um arquivo, modifique 1 caractere dentro dele, e calcule o hash de novo.
  4. Confirme visualmente que os dois hashes são completamente diferentes (efeito avalanche).

Ir para Aula 07

Aula 07 – Assinaturas Digitais e Certificados (PKI) 📜

Como provar, digitalmente, que um documento foi realmente criado por você — e não por um impostor? Nesta aula você vai conhecer o mecanismo que dá validade jurídica a documentos eletrônicos e sustenta a confiança em toda a Internet.

✍️ Assinatura Digital: o Inverso da Cifragem Assimétrica

Lembra que na Aula 05 cifrávamos com a chave pública do destinatário e decifrávamos com a chave privada? A assinatura digital inverte esse fluxo:

graph LR
    A["Documento"] --> H["Hash do Documento (SHA-256)"]
    H -- "Cifra o HASH com a Chave PRIVADA do autor" --> S["Assinatura Digital"]
    S -- "Verifica com a Chave PÚBLICA do autor" --> V{"Hash bate?"}
    V -- Sim --> OK["Documento autêntico e íntegro"]
    V -- Não --> FAIL["Documento adulterado ou assinatura falsa"]

Uma assinatura digital garante três propriedades ao mesmo tempo:

  1. Autenticidade: só quem tem a chave privada poderia ter gerado aquela assinatura.
  2. Integridade: se o documento mudar 1 bit, o hash muda, e a assinatura deixa de bater.
  3. Não-repúdio: o autor não pode alegar depois que "não foi ele" — só ele tinha a chave privada.

🎫 O Problema da Confiança: quem garante que a chave pública é sua mesmo?

Se eu te mando minha "chave pública", como você sabe que ela realmente é minha, e não de um atacante fingindo ser eu? É aqui que entram os certificados digitais.

Um certificado digital é um documento que amarra uma chave pública a uma identidade (pessoa, empresa, servidor), assinado por uma terceira parte confiável.

🏛️ PKI: Infraestrutura de Chave Pública

PKI (Public Key Infrastructure) é o sistema completo que sustenta certificados digitais em escala global.

Componente Função
Autoridade Certificadora (CA) Emite e assina certificados, atestando identidades
Certificado Digital Documento (padrão X.509) com chave pública + identidade + assinatura da CA
Cadeia de Confiança CA raiz → CA intermediária → certificado do site 
graph TD
    Root["CA Raiz (confiada pelo SO/navegador)"] --> Inter["CA Intermediária"]
    Inter --> Cert["Certificado de example.com"]
    Cert --> Site["Site https://example.com"]

Por que o cadeado verde no navegador aparece?

O navegador verifica se o certificado do site foi assinado por uma CA que ele já confia nativamente (essa lista de CAs raiz confiáveis vem pré-instalada no sistema operacional ou no navegador).

💻 Inspecionando um Certificado Real

$ # Verificando o certificado de um site real $ openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates $ subject=CN = example.com $ issuer=C = US, O = DigiCert Inc, CN = DigiCert Global CA $ notBefore=Jan 1 00:00:00 2026 GMT $ notAfter=Dec 31 23:59:59 2026 GMT

📝 Exercícios de Fixação

  1. Básico: Quais três propriedades uma assinatura digital garante?
  2. Básico: Por que a assinatura digital cifra o hash do documento, e não o documento inteiro?
  3. Intermediário: Explique com suas palavras o papel de uma Autoridade Certificadora (CA).
  4. Intermediário: O que aconteceria se um site apresentasse um certificado autoassinado (não emitido por uma CA confiável)?
  5. Desafio: Pesquise o que é "certificate pinning" e por que aplicativos móveis às vezes o utilizam como camada extra de segurança.

🚀 Mini-Projeto: Assinando e Verificando um Documento

Objetivo: Usar OpenSSL para assinar digitalmente um arquivo e depois verificar a assinatura.

  1. Reaproveite o par de chaves RSA gerado na Aula 05 (privada.pem/publica.pem).
  2. Assine um arquivo: openssl dgst -sha256 -sign privada.pem -out arquivo.sig arquivo.txt.
  3. Verifique a assinatura: openssl dgst -sha256 -verify publica.pem -signature arquivo.sig arquivo.txt.
  4. Modifique 1 caractere do arquivo.txt e tente verificar de novo — confirme que a verificação falha.

Ir para Aula 08

Aula 08 – Autenticação e Controle de Acesso 🔏

Cifrar dados não adianta muito se qualquer pessoa consegue entrar no sistema e acessá-los. Nesta aula vamos falar sobre como provar identidade e decidir quem pode fazer o quê.

🧑‍💻 Os Três Fatores de Autenticação

Autenticação é o processo de provar que você é quem diz ser. Existem três categorias de "fatores":

Fator Categoria Exemplo
Algo que você sabe Conhecimento Senha, PIN
Algo que você tem Posse Celular (app autenticador), token físico
Algo que você é Inerência Impressão digital, reconhecimento facial

Autenticação Multifator (MFA)

Combinar 2 ou mais fatores diferentes (ex: senha + código do celular) é chamado de MFA. Mesmo que um atacante roube sua senha, ele ainda precisa do segundo fator para entrar.

🔢 O Padrão Mais Comum: TOTP

O TOTP (Time-based One-Time Password) é o algoritmo por trás de apps como Google Authenticator e Microsoft Authenticator. Ele gera um código de 6 dígitos que muda a cada 30 segundos, baseado em um segredo compartilhado e no horário atual.

graph LR
    A["Segredo compartilhado (gerado no cadastro)"] --> H["Função HMAC"]
    T["Horário atual (janela de 30s)"] --> H
    H --> C["Código de 6 dígitos"]
    C --> V{"Servidor calcula o mesmo código?"}
    V -- Sim --> OK["Autenticado"]

🚪 Autenticação x Autorização

Dois conceitos frequentemente confundidos, mas que respondem perguntas diferentes:

  • Autenticação (AuthN): "Quem é você?" — provar identidade.
  • Autorização (AuthZ): "O que você pode fazer?" — decidir permissões, depois que a identidade já foi confirmada.

🎚️ Modelos de Controle de Acesso

Modelo Sigla Como funciona
Controle de Acesso Baseado em Papéis RBAC Usuário recebe um "papel" (ex: admin, editor, leitor) com permissões pré-definidas
Controle de Acesso Baseado em Atributos ABAC Decisão baseada em atributos dinâmicos (ex: horário, localização, departamento)
Princípio do Menor Privilégio — Cada usuário/sistema deve ter apenas o acesso mínimo necessário para sua função 
graph TD
    U["Usuário"] --> R["Papel: Editor"]
    R --> P1["Permissão: Ler artigos"]
    R --> P2["Permissão: Editar artigos"]
    R -.->|Não tem| P3["Permissão: Apagar usuários"]

Princípio do Menor Privilégio na prática

Um estagiário do time de suporte não precisa de acesso de administrador ao banco de dados de produção — mesmo que "seja mais rápido" dar acesso total, isso aumenta drasticamente o impacto de qualquer erro ou credencial comprometida.

💻 Gerando um Código TOTP

$ # Gerando um segredo TOTP e um codigo valido (usando a biblioteca oathtool) $ oathtool --totp --base32 "JBSWY3DPEHPK3PXP" $ 123456 $ $ # O mesmo segredo, 30 segundos depois, gera um codigo diferente

📝 Exercícios de Fixação

  1. Básico: Cite um exemplo de cada um dos três fatores de autenticação.
  2. Básico: Qual a diferença entre autenticação e autorização?
  3. Intermediário: Por que MFA protege mesmo que a senha do usuário tenha vazado?
  4. Intermediário: Explique o Princípio do Menor Privilégio com um exemplo do seu dia a dia (trabalho, faculdade, jogo online).
  5. Desafio: Pesquise por que SMS é considerado o método de MFA menos seguro entre as opções comuns (comparado a app autenticador ou chave física).

🚀 Mini-Projeto: Simulador de RBAC

Objetivo: Modelar um sistema simples de controle de acesso baseado em papéis.

  1. Defina 3 papéis: admin, editor, leitor.
  2. Defina 4 permissões: criar, editar, apagar, visualizar.
  3. Em uma estrutura de dados (dicionário/objeto), associe cada papel às permissões que ele deveria ter.
  4. Escreva uma função tem_permissao(papel, acao) que retorna true/false consultando essa estrutura.

Ir para Aula 09

Aula 09 – TLS/SSL e Segurança em Redes 🌐

Toda vez que você vê o cadeado no navegador, o TLS está trabalhando nos bastidores. Nesta aula vamos juntar tudo que aprendemos — simétrica, assimétrica, hash e certificados — em um único protocolo que protege bilhões de conexões por dia.

🔓 SSL x TLS: qual a diferença?

SSL (Secure Sockets Layer) foi o protocolo original, hoje totalmente aposentado por vulnerabilidades. TLS (Transport Layer Security) é seu sucessor moderno — mas o termo "SSL" continua sendo usado coloquialmente para se referir ao TLS.

Versão Status
SSL 2.0 / 3.0 ❌ Quebrados, proibidos
TLS 1.0 / 1.1 ❌ Obsoletos, desativados pela maioria dos navegadores
TLS 1.2 ✅ Ainda amplamente suportado
TLS 1.3 ✅ Padrão atual, mais rápido e seguro

🤝 O TLS Handshake

Antes de trocar qualquer dado, cliente e servidor negociam uma conexão segura através do handshake — o momento em que tudo que vimos até agora se junta:

sequenceDiagram
    participant C as Cliente (navegador)
    participant S as Servidor
    C->>S: 1. Client Hello (versões TLS, cifras suportadas)
    S->>C: 2. Server Hello + Certificado Digital (Aula 07)
    C->>C: 3. Valida o certificado na cadeia de confiança (PKI)
    C->>S: 4. Troca de chaves (Diffie-Hellman - Aula 05)
    Note over C,S: Ambos agora tem uma chave simétrica compartilhada
    C->>S: 5. Dados cifrados com AES (Aula 04) usando essa chave

Resumindo o handshake

  1. Servidor prova sua identidade com um certificado (PKI).
  2. Cliente e servidor combinam uma chave secreta via Diffie-Hellman.
  3. Toda a comunicação depois disso é cifrada com AES, usando essa chave — rápida e segura.

🔒 HTTPS: HTTP sobre TLS

HTTPS é simplesmente o protocolo HTTP normal, rodando dentro de uma conexão TLS. Ele garante:

  • Confidencialidade: ninguém no meio do caminho consegue ler os dados.
  • Integridade: ninguém consegue alterar os dados sem ser detectado.
  • Autenticidade: você tem garantia de estar falando com o servidor real (via certificado).

🕵️ Ataques que o TLS Previne (e os que não previne)

Ataque TLS previne?
Man-in-the-Middle (interceptação de tráfego) ✅ Sim
Servidor falso se passando pelo real ✅ Sim (se o certificado for validado corretamente)
Phishing (site falso com domínio parecido) ❌ Não — o site falso pode ter certificado TLS válido para o próprio domínio dele

TLS não é prova de site legítimo

Um site de phishing em paypa1-login.com pode perfeitamente ter um cadeado verde válido — o TLS garante que a conexão com aquele domínio é segura, não que o domínio seja confiável.

💻 Inspecionando uma Conexão TLS

$ # Verificando qual versao de TLS um site suporta $ openssl s_client -connect example.com:443 -tls1_3 < /dev/null 2>&1 | grep "Protocol" $ Protocol : TLSv1.3 $ $ # Verificando os cabecalhos de seguranca HSTS $ curl -sI https://example.com | grep -i strict-transport-security

📝 Exercícios de Fixação

  1. Básico: Qual a diferença entre SSL e TLS?
  2. Básico: Por que TLS 1.0 e 1.1 são considerados inseguros hoje?
  3. Intermediário: Descreva, em 4 passos, o que acontece durante um TLS handshake.
  4. Intermediário: Por que o TLS não impede um usuário de cair em um site de phishing?
  5. Desafio: Pesquise o que é HSTS (HTTP Strict Transport Security) e como ele protege contra ataques de downgrade para HTTP.

🚀 Mini-Projeto: Auditor de TLS

Objetivo: Analisar a configuração TLS de 3 sites diferentes usando linha de comando.

  1. Escolha 3 sites (ex: um banco, uma rede social, um site pessoal).
  2. Para cada um, verifique a versão de TLS suportada com openssl s_client.
  3. Verifique se o cabeçalho Strict-Transport-Security está presente com curl -I.
  4. Compare os resultados: qual site parece mais bem configurado em segurança de rede?

Ir para Aula 10

Aula 10 – Criptografia na Prática com Python 🐍

Teoria é essencial, mas é escrevendo código que a criptografia se torna uma ferramenta real. Nesta aula vamos usar a biblioteca cryptography, o padrão de mercado em Python.

📦 Instalando a Biblioteca

pip install cryptography

Nunca implemente sua própria criptografia

Regra de ouro da segurança: nunca escreva seu próprio algoritmo de criptografia para uso em produção. Use sempre bibliotecas revisadas e testadas por especialistas — pequenos erros de implementação podem quebrar toda a segurança.

🔑 Hash com hashlib (biblioteca padrão)

import hashlib

texto = "senha123"
hash_sha256 = hashlib.sha256(texto.encode()).hexdigest()
print(hash_sha256)
# ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94

🔐 Criptografia Simétrica com Fernet

O Fernet (parte da biblioteca cryptography) implementa AES de forma segura e simples, cuidando automaticamente do modo de operação e da autenticação.

from cryptography.fernet import Fernet

# Gerando uma chave (guarde-a com segurança!)
chave = Fernet.generate_key()
f = Fernet(chave)

# Cifrando
texto_cifrado = f.encrypt(b"Mensagem secreta")
print(texto_cifrado)

# Decifrando
texto_original = f.decrypt(texto_cifrado)
print(texto_original.decode())  # "Mensagem secreta"

graph LR
    A["b'Mensagem secreta'"] -- "Fernet.encrypt(chave)" --> B["Token cifrado (base64)"]
    B -- "Fernet.decrypt(chave)" --> C["b'Mensagem secreta'"]

🔓 Criptografia Assimétrica com RSA em Python

from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import hashes

# Gerando o par de chaves
chave_privada = rsa.generate_private_key(public_exponent=65537, key_size=2048)
chave_publica = chave_privada.public_key()

# Cifrando com a chave publica
mensagem = b"Dados confidenciais"
cifrado = chave_publica.encrypt(
    mensagem,
    padding.OAEP(mgf=padding.MGF1(algorithm=hashes.SHA256()), algorithm=hashes.SHA256(), label=None)
)

# Decifrando com a chave privada
decifrado = chave_privada.decrypt(
    cifrado,
    padding.OAEP(mgf=padding.MGF1(algorithm=hashes.SHA256()), algorithm=hashes.SHA256(), label=None)
)
print(decifrado.decode())  # "Dados confidenciais"

💻 Exemplo em Terminal (Python CLI)

$ python -c "import hashlib; print(hashlib.sha256(b'ola mundo').hexdigest())" $ 4c37a...b91e2 $ $ python -c "from cryptography.fernet import Fernet; k=Fernet.generate_key(); print(k)" $ b'dGhpcyBpcyBhIHRlc3Qga2V5IGZvciBkZW1v...'

📝 Exercícios de Fixação

  1. Básico: Instale a biblioteca cryptography e calcule o hash SHA-256 de uma frase à sua escolha.
  2. Básico: Gere uma chave Fernet e cifre uma mensagem curta.
  3. Intermediário: Por que o Fernet.encrypt() produz um resultado diferente cada vez que você cifra a mesma mensagem, mesmo usando a mesma chave? (Dica: pense no IV da Aula 04).
  4. Intermediário: Modifique o exemplo de RSA para cifrar e decifrar uma mensagem digitada pelo usuário via input().
  5. Desafio: Escreva uma função cifrar_arquivo(caminho, chave) que lê um arquivo, cifra seu conteúdo com Fernet e salva o resultado em um novo arquivo.

🚀 Mini-Projeto: Cofre de Senhas em Python

Objetivo: Criar um mini "gerenciador de senhas" de linha de comando.

  1. Gere e salve uma chave Fernet em um arquivo separado (chave.key).
  2. Crie funções salvar_senha(servico, senha) que cifra a senha e salva num arquivo cofre.txt (formato servico:token_cifrado).
  3. Crie uma função ler_senha(servico) que busca a linha correspondente e decifra a senha.
  4. Teste salvando e recuperando senhas para 2 ou 3 serviços fictícios.

Ir para Aula 11

Aula 11 – Criptografia na Prática com JavaScript 💻

O navegador também precisa cifrar dados — de senhas locais a comunicação ponta a ponta. Nesta aula vamos usar a Web Crypto API, nativa de todo navegador moderno e do Node.js.

📦 A Web Crypto API

Diferente do Python, o JavaScript não precisa instalar biblioteca nenhuma para operações criptográficas básicas — a crypto.subtle já vem embutida no navegador e no Node.js (via require('crypto').webcrypto).

Por que 'subtle'?

O nome é uma referência proposital: usar essa API de forma insegura é fácil e as consequências são "sutis" (subtle) — o nome é um lembrete para usar com cuidado e seguir as boas práticas.

#️⃣ Hash com crypto.subtle.digest

async function calcularHash(texto) {
    const encoder = new TextEncoder();
    const dados = encoder.encode(texto);
    const hashBuffer = await crypto.subtle.digest("SHA-256", dados);
    const hashArray = Array.from(new Uint8Array(hashBuffer));
    return hashArray.map(b => b.toString(16).padStart(2, "0")).join("");
}

calcularHash("senha123").then(hash => console.log(hash));
// ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94

🔐 Criptografia Simétrica (AES-GCM) no Navegador

async function gerarChaveAES() {
    return await crypto.subtle.generateKey(
        { name: "AES-GCM", length: 256 },
        true,
        ["encrypt", "decrypt"]
    );
}

async function cifrar(chave, texto) {
    const iv = crypto.getRandomValues(new Uint8Array(12)); // IV aleatorio (Aula 04)
    const encoder = new TextEncoder();
    const cifrado = await crypto.subtle.encrypt(
        { name: "AES-GCM", iv },
        chave,
        encoder.encode(texto)
    );
    return { cifrado, iv };
}

graph LR
    A["Texto Claro"] --> B["generateKey AES-GCM 256"]
    B --> C["encrypt() com IV aleatorio"]
    C --> D["ArrayBuffer cifrado"]
    D --> E["decrypt() com a mesma chave + IV"]
    E --> A

Sempre gere um IV novo

Assim como vimos na Aula 04, reutilizar o mesmo IV com a mesma chave em AES-GCM compromete completamente a segurança da cifragem.

💻 Testando no Console do Navegador

$ # No console do navegador (F12) ou via Node.js $ node -e "crypto.subtle.digest('SHA-256', new TextEncoder().encode('teste')).then(h => console.log(Buffer.from(h).toString('hex')))" $ 4d967a...c91b3

📝 Exercícios de Fixação

  1. Básico: Por que a Web Crypto API não precisa de instalação, diferente da biblioteca Python da Aula 10?
  2. Básico: Escreva uma função que calcula o hash SHA-256 de uma senha digitada em um formulário HTML.
  3. Intermediário: Por que o IV é gerado com crypto.getRandomValues() e não com Math.random()?
  4. Intermediário: Complete o exemplo de AES-GCM com uma função decifrar() que reverte o processo de cifrar().
  5. Desafio: Pesquise a diferença entre crypto.getRandomValues() (criptograficamente seguro) e Math.random() (não seguro) — por que isso importa em segurança?

🚀 Mini-Projeto: Formulário com Hash no Cliente

Objetivo: Criar uma página HTML simples que calcula o hash SHA-256 de um texto digitado, em tempo real.

  1. Crie um input de texto e uma área para mostrar o resultado.
  2. A cada tecla digitada, calcule o hash SHA-256 do conteúdo atual usando crypto.subtle.digest.
  3. Exiba o hash resultante na tela, atualizado em tempo real.
  4. Bônus: adicione um botão para copiar o hash para a área de transferência.

Ir para Aula 12

Aula 12 – Segurança em Aplicações Web (OWASP Top 10) 🕸️

Nesta aula vamos sair da teoria criptográfica e entrar no dia a dia de quem constrói aplicações web: as vulnerabilidades mais exploradas do mundo, catalogadas pelo OWASP Top 10.

🏛️ O que é a OWASP?

A OWASP (Open Worldwide Application Security Project) é uma organização sem fins lucrativos que mantém, entre outros recursos, uma lista atualizada periodicamente das vulnerabilidades web mais críticas e comuns — referência obrigatória para qualquer desenvolvedor.

🔟 As Categorias do OWASP Top 10

# Categoria O que é
1 Broken Access Control Falhas que permitem acessar recursos sem permissão adequada
2 Cryptographic Failures Uso incorreto ou ausência de criptografia em dados sensíveis
3 Injection Inserir código malicioso via entrada do usuário (SQL, comandos, etc.)
4 Insecure Design Falhas de segurança na arquitetura, não só na implementação
5 Security Misconfiguration Configurações padrão inseguras, permissões excessivas
6 Vulnerable Components Usar bibliotecas/dependências desatualizadas com falhas conhecidas
7 Auth Failures Falhas em autenticação e gerenciamento de sessão
8 Software/Data Integrity Failures Confiar em atualizações/dados sem verificar integridade
9 Logging Failures Falta de logs adequados para detectar e investigar ataques
10 SSRF Servidor é enganado para fazer requisições a locais não autorizados

💉 Foco Prático: SQL Injection

A vulnerabilidade mais didática e ainda muito comum. Acontece quando a entrada do usuário é concatenada diretamente em uma consulta SQL.

# ❌ VULNERÁVEL - concatenação direta
query = f"SELECT * FROM usuarios WHERE nome = '{nome_usuario}'"

# Se nome_usuario for: ' OR '1'='1
# A query vira: SELECT * FROM usuarios WHERE nome = '' OR '1'='1'
# Isso retorna TODOS os usuários!

# ✅ SEGURO - consulta parametrizada (prepared statement)
cursor.execute("SELECT * FROM usuarios WHERE nome = %s", (nome_usuario,))

graph TD
    A["Entrada do usuário"] --> B{"Concatenada direto na query?"}
    B -- Sim --> C["❌ SQL Injection possível"]
    B -- Não, usa prepared statement --> D["✅ Entrada tratada como dado, nunca como código"]

🖼️ Foco Prático: XSS (Cross-Site Scripting)

Ocorre quando dados fornecidos pelo usuário são exibidos na página sem escapar caracteres especiais de HTML, permitindo injetar scripts.

<!-- Comentário de usuário exibido sem tratamento -->
<div>Comentário: <script>roubarCookies()</script></div>

Regra de ouro contra XSS

Nunca confie em dados do usuário. Sempre escape (ou use frameworks que escapam automaticamente, como React/Vue) qualquer conteúdo dinâmico antes de renderizá-lo como HTML.

💻 Testando Cabeçalhos de Segurança

$ # Verificando cabecalhos de seguranca de uma aplicacao web $ curl -sI https://example.com | grep -Ei "x-content-type|x-frame|content-security-policy" $ X-Content-Type-Options: nosniff $ X-Frame-Options: DENY $ Content-Security-Policy: default-src 'self'

📝 Exercícios de Fixação

  1. Básico: O que significa a sigla OWASP e qual o objetivo do OWASP Top 10?
  2. Básico: Explique com suas palavras como funciona um ataque de SQL Injection.
  3. Intermediário: Por que consultas parametrizadas (prepared statements) resolvem o problema de SQL Injection?
  4. Intermediário: Dê um exemplo prático de onde um XSS poderia ser injetado em uma rede social (ex: campo de comentário, nome de perfil).
  5. Desafio: Pesquise a diferença entre XSS Refletido, Armazenado e Baseado em DOM.

🚀 Mini-Projeto: Caça-Vulnerabilidades

Objetivo: Analisar um trecho de código (fornecido pelo professor ou pesquisado por você) e identificar vulnerabilidades do OWASP Top 10.

  1. Encontre (ou peça) um trecho de código com uma consulta SQL montada por concatenação de strings.
  2. Identifique a vulnerabilidade e explique como ela seria explorada.
  3. Reescreva o código de forma segura, usando prepared statements.
  4. Repita o exercício com um trecho que renderiza entrada de usuário direto no HTML (risco de XSS).

Ir para Aula 13

Aula 13 – Gestão e Armazenamento Seguro de Senhas 🗝️

"Nunca guarde a senha do usuário." Essa frase resume uma das regras mais importantes de segurança — e nesta aula você vai entender exatamente o porquê e como fazer certo.

❌ O que NUNCA fazer

# ❌ Senha em texto puro no banco de dados
usuario.senha = "senha123"

# ❌ Hash simples sem sal (SHA-256 puro)
usuario.senha = hashlib.sha256("senha123".encode()).hexdigest()

Por que hash simples não basta?

Hashes como SHA-256 são rápidos demais — um atacante com hardware moderno (GPU) consegue testar bilhões de senhas por segundo contra um hash roubado, usando rainbow tables (tabelas pré-computadas) ou força bruta.

🧂 Sal (Salt): a Primeira Defesa

Um salt é um valor aleatório único, gerado para cada senha, que é combinado com a senha antes de aplicar o hash.

graph LR
    A["senha123"] --> C["+ salt aleatório (ex: 8f3a...)"]
    C --> H["Função de Hash"]
    H --> R["Hash único, mesmo que outro usuário tenha a mesma senha"]

Sem salt, duas contas com a mesma senha ("123456", por exemplo) teriam o mesmo hash — permitindo que um atacante quebre todas de uma vez com uma única rainbow table.

🐌 Funções de Hash Lentas de Propósito

A verdadeira solução não é só adicionar sal — é usar algoritmos deliberadamente lentos, projetados especificamente para senhas:

Algoritmo Características
bcrypt Padrão de mercado, salt embutido automaticamente, "fator de custo" ajustável
scrypt Também exige muita memória, dificultando ataques com hardware especializado (ASIC)
Argon2 Vencedor da Password Hashing Competition (2015), recomendação atual mais forte

Por que 'lento' é bom aqui?

Para o usuário, uma senha demorar 200ms para verificar no login é imperceptível. Para um atacante tentando testar bilhões de combinações, esses 200ms por tentativa tornam o ataque impraticável.

💻 Hash de Senha com bcrypt em Python

import bcrypt

senha = b"senha123"

# Cadastro: gera salt automaticamente e cifra
hash_senha = bcrypt.hashpw(senha, bcrypt.gensalt())
print(hash_senha)
# b'$2b$12$KIXQ...'

# Login: verifica se a senha digitada bate com o hash salvo
senha_digitada = b"senha123"
if bcrypt.checkpw(senha_digitada, hash_senha):
    print("✅ Senha correta!")
else:
    print("❌ Senha incorreta!")
$ pip install bcrypt $ python -c "import bcrypt; print(bcrypt.hashpw(b'senha123', bcrypt.gensalt()))" $ b'$2b$12$EixZaYVK1fsbw1Zfbx...'

📏 Boas Práticas Adicionais

  1. Nunca limite o tamanho máximo da senha artificialmente (limites curtos como "máximo 8 caracteres" reduzem segurança).
  2. Não force troca periódica sem motivo (pesquisas mostram que isso leva a senhas mais fracas e previsíveis, como "Senha1", "Senha2"...).
  3. Sempre use HTTPS no formulário de login (senão a senha viaja em texto claro na rede).
  4. Implemente rate limiting para bloquear tentativas de força bruta.

📝 Exercícios de Fixação

  1. Básico: Por que armazenar senhas em texto puro é uma péssima prática?
  2. Básico: O que é um "salt" e qual problema ele resolve?
  3. Intermediário: Por que SHA-256 puro não é adequado para hash de senhas, mesmo sendo um algoritmo seguro?
  4. Intermediário: O que significa o "fator de custo" do bcrypt e por que ele pode ser aumentado ao longo dos anos?
  5. Desafio: Pesquise o que é "credential stuffing" e por que reutilizar senhas entre sites é especialmente perigoso frente a esse ataque.

🚀 Mini-Projeto: Sistema de Cadastro e Login

Objetivo: Implementar um cadastro/login simples com hash de senha seguro.

  1. Crie uma função cadastrar(usuario, senha) que gera o hash com bcrypt e "salva" (pode ser em um dicionário em memória).
  2. Crie uma função login(usuario, senha) que verifica a senha digitada contra o hash salvo.
  3. Teste com senha correta e senha incorreta.
  4. Bônus: adicione um contador de tentativas falhas e bloqueie o login após 5 tentativas (rate limiting básico).

Ir para Aula 14

Aula 14 – Privacidade de Dados e LGPD 🗂️

Segurança técnica não basta se a organização não tem regras claras sobre como coletar, usar e proteger dados pessoais. Nesta aula vamos conectar tudo o que aprendemos com o principal marco legal de proteção de dados no Brasil.

📜 O que é a LGPD?

A LGPD (Lei Geral de Proteção de Dados, Lei nº 13.709/2018) regula como empresas e organizações no Brasil podem coletar, armazenar, processar e compartilhar dados pessoais.

Inspiração internacional

A LGPD foi fortemente inspirada no GDPR (General Data Protection Regulation) da União Europeia, considerado o padrão-ouro global de proteção de dados.

🧑 Dado Pessoal x Dado Sensível

Categoria Definição Exemplos
Dado Pessoal Qualquer informação que identifique ou possa identificar uma pessoa Nome, e-mail, CPF, IP
Dado Pessoal Sensível Categoria com proteção reforçada, risco maior de discriminação Origem racial, religião, saúde, orientação sexual, dados biométricos

⚖️ Os Princípios da LGPD

graph TD
    A["Princípios da LGPD"] --> B["Finalidade: coleta com propósito específico"]
    A --> C["Necessidade: coletar só o mínimo necessário"]
    A --> D["Transparência: informar claramente o uso dos dados"]
    A --> E["Segurança: proteger tecnicamente os dados coletados"]
    A --> F["Livre acesso: titular pode consultar seus dados"]

🙋 Direitos do Titular dos Dados

Toda pessoa cujos dados são coletados (o "titular") tem direitos garantidos por lei, incluindo:

  1. Confirmação e acesso: saber se uma empresa tem seus dados e quais são.
  2. Correção: corrigir dados incompletos, inexatos ou desatualizados.
  3. Eliminação: solicitar a exclusão de dados desnecessários ou tratados de forma irregular.
  4. Portabilidade: solicitar a transferência dos dados para outro fornecedor.
  5. Revogação do consentimento: retirar a autorização de uso a qualquer momento.

🛠️ Onde a Segurança Técnica se Encontra com a LGPD

A lei exige medidas técnicas e administrativas para proteger dados pessoais — exatamente o conteúdo das aulas anteriores:

Exigência da LGPD Técnica correspondente (já vista no curso)
Proteger dados contra acesso não autorizado Criptografia (Aulas 03–07), Controle de Acesso (Aula 08)
Comunicação segura entre sistemas TLS/HTTPS (Aula 09)
Proteger credenciais de usuários Hash + salt para senhas (Aula 13)
Detectar incidentes de segurança Logging e monitoramento (Aula 15)

Vazamento de dados = Multa

Empresas que sofrem vazamentos de dados pessoais por negligência de segurança estão sujeitas a multas de até 2% do faturamento, limitadas a R$ 50 milhões por infração — além do dano à reputação.

💻 Verificando Política de Privacidade

$ # Checando se um site expõe uma politica de privacidade acessivel $ curl -sI https://example.com/privacidade | head -1 $ HTTP/1.1 200 OK

📝 Exercícios de Fixação

  1. Básico: Qual a diferença entre dado pessoal e dado pessoal sensível? Dê um exemplo de cada.
  2. Básico: Cite 3 direitos garantidos ao titular de dados pela LGPD.
  3. Intermediário: Explique o princípio da "necessidade" da LGPD com um exemplo prático (ex: um app de delivery pedindo dados demais no cadastro).
  4. Intermediário: Como o hash com salt (Aula 13) ajuda uma empresa a cumprir a LGPD mesmo em caso de vazamento?
  5. Desafio: Pesquise o papel do DPO (Data Protection Officer / Encarregado de Dados) dentro de uma empresa.

🚀 Mini-Projeto: Auditoria de Privacidade

Objetivo: Avaliar a política de privacidade de um aplicativo ou site que você usa no dia a dia.

  1. Escolha um app ou site popular e localize sua política de privacidade.
  2. Identifique: quais dados são coletados? Para qual finalidade? Por quanto tempo são retidos?
  3. Verifique se existe uma opção clara para solicitar exclusão da conta e dos dados.
  4. Escreva um parecer curto (5–10 linhas) avaliando se a política parece atender aos princípios da LGPD estudados.

Ir para Aula 15

Aula 15 – Auditoria e Testes de Segurança 🔍

Como saber se todas as defesas que construímos nas aulas anteriores realmente funcionam? Nesta aula vamos aprender a testar, auditar e monitorar a segurança de um sistema antes que um atacante o faça por você.

🕵️ Pentest x Auditoria x Bug Bounty

Abordagem Quem faz Objetivo
Teste de Penetração (Pentest) Time contratado, com escopo e prazo definidos Simular um ataque real e reportar vulnerabilidades
Auditoria de Segurança Interno ou terceirizado Revisar processos, configurações e conformidade (ex: LGPD)
Bug Bounty Pesquisadores independentes, continuamente Recompensar quem encontrar e reportar vulnerabilidades

Autorização é obrigatória

Testar a segurança de um sistema sem autorização explícita e por escrito do proprietário é crime, mesmo com boas intenções. Sempre trabalhe dentro de um escopo formalmente autorizado.

🔬 SAST x DAST: Duas Formas de Analisar Código

graph TD
    A["Análise de Segurança de Software"] --> B["SAST - Static Application Security Testing"]
    A --> C["DAST - Dynamic Application Security Testing"]
    B --> D["Analisa o CÓDIGO FONTE, sem executar"]
    C --> E["Analisa a APLICAÇÃO RODANDO, como um atacante externo"]
SAST DAST
Quando roda Durante o desenvolvimento (CI/CD) Aplicação já em execução
Encontra Padrões de código inseguro (ex: SQL concatenado) Vulnerabilidades exploráveis de fora (ex: XSS real)
Exemplo de ferramenta SonarQube, Bandit (Python) OWASP ZAP, Burp Suite

📋 Gestão de Dependências (SCA)

Boa parte das vulnerabilidades reais não está no seu código — está nas bibliotecas de terceiros que você usa.

$ # Verificando vulnerabilidades conhecidas em dependencias Python $ pip install pip-audit $ pip-audit $ Found 2 known vulnerabilities in 1 package $ Name Version ID Fix Versions $ requests 2.25.0 GHSA-j8r2-6x86 2.31.0

SCA = Software Composition Analysis

Ferramentas como pip-audit, npm audit e o próprio Dependabot do GitHub automatizam essa verificação, alertando quando uma dependência tem vulnerabilidade conhecida (catalogada em bases como o CVE).

📊 Logging e Monitoramento

Detectar um ataque em andamento (ou já ocorrido) depende de registros bem feitos.

O que registrar em logs de segurança: 1. Tentativas de login (sucesso e falha), com data/hora e IP de origem. 2. Mudanças em permissões e dados sensíveis. 3. Erros de aplicação que possam indicar tentativa de exploração (ex: muitos erros 500 seguidos).

Nunca logue dados sensíveis

Um erro comum: logar a senha digitada em uma tentativa de login falha "para debug". Isso viola a LGPD (Aula 14) e cria um novo ponto de vazamento — nunca registre senhas, tokens ou dados sensíveis em logs.

📝 Exercícios de Fixação

  1. Básico: Qual a diferença entre um pentest e uma auditoria de segurança?
  2. Básico: Por que testar a segurança de um sistema sem autorização é crime, mesmo com boas intenções?
  3. Intermediário: Explique a diferença entre SAST e DAST com um exemplo de vulnerabilidade que cada um encontraria melhor.
  4. Intermediário: Por que dependências desatualizadas são consideradas um risco de segurança, mesmo que seu código próprio esteja correto?
  5. Desafio: Pesquise o que é o "CVE" (Common Vulnerabilities and Exposures) e como consultar vulnerabilidades conhecidas de uma biblioteca específica.

🚀 Mini-Projeto: Checklist de Auditoria

Objetivo: Criar e aplicar um checklist básico de segurança em um projeto real (seu ou de um colega).

  1. Monte um checklist com pelo menos 8 itens, cobrindo temas das aulas anteriores (ex: "senhas com hash+salt?", "HTTPS em produção?", "dependências atualizadas?", "logs não guardam dados sensíveis?").
  2. Aplique o checklist em um projeto real.
  3. Para cada item que falhar, documente o risco e uma sugestão de correção.
  4. Rode pip-audit ou npm audit no projeto e inclua os resultados no relatório.

Ir para Aula 16

Aula 16 – Projeto Final: Sistema de Autenticação Seguro 🎓

Parabéns por chegar até aqui! Nesta aula final, você vai consolidar tudo o que aprendeu construindo um sistema de autenticação completo, aplicando as boas práticas de cada aula anterior.

🎯 O Cenário

Você foi contratado para implementar o backend de autenticação de uma nova aplicação. O sistema precisa ser resistente às vulnerabilidades mais comuns e seguir os princípios de segurança estudados no curso.

🛠️ Requisitos do Projeto

Seu sistema (em Python ou JavaScript, à sua escolha) deve implementar:

  1. Cadastro de usuário (Aula 13): senha armazenada com hash + salt via bcrypt (nunca em texto puro).
  2. Login com verificação segura (Aula 13): comparação da senha usando a função apropriada da biblioteca de hash (nunca == direto).
  3. Autenticação multifator opcional (Aula 08): geração e verificação de código TOTP.
  4. Controle de acesso por papéis (Aula 08): pelo menos 2 papéis (admin, usuario) com permissões diferentes.
  5. Proteção contra força bruta (Aula 15): bloqueio temporário após N tentativas de login falhas.
  6. Logging seguro (Aula 15): registrar tentativas de login (sucesso/falha, IP, timestamp) sem nunca logar a senha.
  7. Prevenção de SQL Injection (Aula 12): se usar banco de dados, todas as consultas devem ser parametrizadas.

📊 Arquitetura Proposta

graph TD
    A["Cliente"] -- "HTTPS - Aula 09" --> B["API de Autenticação"]
    B --> C["Cadastro: bcrypt hash+salt - Aula 13"]
    B --> D["Login: verifica hash + rate limiting - Aula 13/15"]
    D --> E{"MFA habilitado?"}
    E -- Sim --> F["Verifica codigo TOTP - Aula 08"]
    E -- Nao --> G["Gera sessao/token"]
    F --> G
    G --> H["Controle de acesso por papel - Aula 08"]
    D -.-> I["Log de tentativas (sem senha!) - Aula 15"]

💻 Ponto de Partida Sugerido (Python)

import bcrypt
import time
from datetime import datetime

usuarios = {}  # em produção, seria um banco de dados real
tentativas_falhas = {}  # controle de rate limiting

def cadastrar(usuario, senha, papel="usuario"):
    hash_senha = bcrypt.hashpw(senha.encode(), bcrypt.gensalt())
    usuarios[usuario] = {"hash": hash_senha, "papel": papel}
    print(f"[LOG] Usuário '{usuario}' cadastrado às {datetime.now()}")

def login(usuario, senha_digitada):
    if tentativas_falhas.get(usuario, 0) >= 5:
        print(f"[LOG] Login BLOQUEADO para '{usuario}' - excesso de tentativas")
        return False

    dados = usuarios.get(usuario)
    if dados and bcrypt.checkpw(senha_digitada.encode(), dados["hash"]):
        tentativas_falhas[usuario] = 0
        print(f"[LOG] Login OK para '{usuario}' às {datetime.now()}")
        return True

    tentativas_falhas[usuario] = tentativas_falhas.get(usuario, 0) + 1
    print(f"[LOG] Login FALHOU para '{usuario}' às {datetime.now()} (tentativa {tentativas_falhas[usuario]})")
    return False

Ponto de partida, não a solução completa

Este código cobre cadastro, login e rate limiting básico. Sua missão é completar os requisitos restantes: MFA, controle de acesso por papel e consultas parametrizadas (se usar banco de dados de verdade).

✅ Checklist de Entrega

  • Senhas nunca armazenadas em texto puro
  • Rate limiting funcionando (teste com 6+ tentativas erradas seguidas)
  • Pelo menos 2 papéis com permissões diferentes implementadas
  • Logs registram tentativas de login, mas nunca a senha digitada
  • MFA (TOTP) implementado, mesmo que opcional para o usuário
  • Testado com pelo menos 3 cenários: cadastro, login correto, login incorreto

🎨 Conclusão do Curso

Você percorreu uma jornada completa em Segurança e Criptografia — dos fundamentos da tríade CID até a construção de um sistema de autenticação real. Agora você sabe:

  • Os fundamentos: confidencialidade, integridade, disponibilidade e como ameaças reais exploram suas falhas.
  • A criptografia por trás de tudo: simétrica, assimétrica, hash, assinaturas digitais e certificados.
  • Como aplicar na prática: em Python, JavaScript, e nas conexões TLS que protegem a Internet inteira.
  • Como pensar como defensor: OWASP Top 10, gestão de senhas, LGPD, pentest e auditoria.

Segurança não é um destino, é um processo contínuo — continue praticando, mantenha-se atualizado sobre novas vulnerabilidades, e leve esses princípios para todo sistema que você construir daqui em diante! 🛡️

Aula 17 - Criptografia Assimétrica Avançada (RSA, ECC e DH) 🔑

Objetivo Pedagógico

Objetivo: Compreender os fundamentos matemáticos e a implementação prática dos esquemas de chave pública: o problema da fatoração de inteiros (RSA), o problema do logaritmo discreto em curvas elípticas (ECDSA/Ed25519) e o protocolo de troca de chaves Diffie-Hellman.

📑 1. Fundamentos Teóricos & Análise Técnica

A criptografia de chave pública (assimétrica) resolveu o dilema clássico da distribuição segura de chaves entre partes que nunca interagiram previamente.

Os sistemas de chave pública contemporâneos apoiam-se em funções de sentido único com alçapão (Trapdoor One-Way Functions): 1. RSA (Rivest-Shamir-Adleman): - Baseia-se na assimetria computacional da fatoração de inteiros: multiplicar dois primos gigantescos (\(p\) e \(q\)) para obter \(n = pq\) é trivial, mas deduzir \(p\) e \(q\) a partir de \(n\) é computacionalmente inviável com algoritmos clássicos. - Para manter margem segura contra ataques contemporâneos, chaves RSA exigem comprimentos mínimos de 2048 a 4096 bits, resultando em alto consumo de CPU e tráfego de rede. 2. Criptografia de Curvas Elípticas (ECC - Elliptic Curve Cryptography): - Fundamenta-se no Problema do Logaritmo Discreto de Curvas Elípticas (ECDLP) sobre corpos finitos: \(P + P + \dots + P = kP = Q\). Dado o ponto base \(P\) e o produto escalar \(Q\), é computacionalmente intratável determinar o escalar escalar privado \(k\). - Eficiência Superior: Uma chave de curva elíptica de 256 bits (ex: Curve25519 / secp256r1) provê nível de segurança equivalente a uma chave RSA de 3072 bits, com assinaturas muito mais compactas e computação ordens de magnitude mais rápida. 3. Esquema de Assinatura Ed25519 (EdDSA): - Curva de Edwards torcida imune a vazamentos por temporização (Side-Channel Timing Attacks) e imune a falhas de geradores de números pseudoaleatórios que comprometeram esquemas ECDSA no passado.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    Alice["Alice (Chave Privada a)"] --> PubAlice["Chave Pública A = a * G"]
    Bob["Bob (Chave Privada b)"] --> PubBob["Chave Pública B = b * G"]
    PubAlice --> Canal["Canal Público Inseguro da Internet"]
    PubBob --> Canal
    Canal --> AliceCalc["Alice calcula: S = a * B = a * (b * G)"]
    Canal --> BobCalc["Bob calcula: S = b * A = b * (a * G)"]
    AliceCalc & BobCalc --> Secret["Segredo Compartilhado Idêntico S = abG!"]
    style Alice fill:#e1f5fe,stroke:#01579b
    style Bob fill:#fff3e0,stroke:#e65100
    style Canal fill:#ffebee,stroke:#c62828
    style Secret fill:#e8f5e9,stroke:#2e7d32

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Princípio de Kerckhoffs: A segurança de um sistema criptográfico deve residir unicamente no sigilo da chave, e não no segredo do algoritmo. - Curva Ed25519 e Determinação: Assinaturas determinísticas que eliminam a dependência de entropia em runtime durante o processo de assinatura. - Resistência a Ataques de Canal Lateral: Algoritmos concebidos para executar em tempo constante (Constant-Time Execution), impedindo espionagem por medição de clock. - Transição para Criptografia Pós-Quântica (PQC): Preparação para esquemas baseados em reticulados (ex: ML-KEM / Kyber) frente à ameaça do algoritmo de Shor.

🛠️ 2. Implementação Prática em Criptografia de Chave Pública e Matemática Computacional

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// asymmetric_crypto.py (Troca de Chaves ECDH e Assinatura Ed25519 em Python)
from cryptography.hazmat.primitives.asymmetric import x25519, ed25519
from cryptography.hazmat.primitives import serialization

# 1. Geração de Chaves de Troca Diffie-Hellman Efêmero (X25519)
alice_private = x25519.X25519PrivateKey.generate()
alice_public = alice_private.public_key()

bob_private = x25519.X25519PrivateKey.generate()
bob_public = bob_private.public_key()

# 2. Computação do Segredo Compartilhado Simétrico em Ambos os Lados
alice_shared = alice_private.exchange(bob_public)
bob_shared = bob_private.exchange(alice_public)

assert alice_shared == bob_shared
print(f"Segredo Compartilhado ECDH estabelecido com sucesso ({len(alice_shared)} bytes)!")

# 3. Assinatura Digital Moderna com Ed25519
signer_private = ed25519.Ed25519PrivateKey.generate()
signer_public = signer_private.public_key()

mensagem = b"Instrucao de transferencia financeira auditada e inviolavel"
assinatura = signer_private.sign(mensagem)

# Verificação pelo destinatário
try:
    signer_public.verify(assinatura, mensagem)
    print("Assinatura Ed25519 verificada com autenticidade matemática absoluta!")
except Exception as e:
    print(f"Falha na verificação da assinatura: {e}")

💡 Análise Passo a Passo do Código

  1. Uso da Curva X25519: Troca de chaves Diffie-Hellman de alta performance concebida por Daniel J. Bernstein.
  2. Cálculo Atômico exchange(): Gera o mesmo segredo compartilhado em ambas as extremidades sem expor a chave privada.
  3. Assinatura Ed25519: Cria assinaturas compactas de 64 bytes que atestam a autoria inequívoca da mensagem.

🎯 3. Próximos Passos & Sequência Didática

Aula 18 - Protocolos Criptográficos e Cifras de Bloco (AES-GCM) 🔒

Objetivo Pedagógico

Objetivo: Analisar as construções de cifras de bloco (SPN - Substitution-Permutation Network), modos de operação legados (ECB, CBC) e dominar a implementação de Criptografia Autenticada com Dados Adicionais (AEAD) usando AES-GCM.

📑 1. Fundamentos Teóricos & Análise Técnica

A criptografia simétrica é a ferramenta responsável pela cifragem em massa de dados em trânsito e em repouso devido à sua eficiência computacional extrema.

A evolução dos modos de operação de cifras de bloco resolveu graves deficiências históricas: 1. O Advanced Encryption Standard (AES - FIPS 197): - Cifra de bloco simétrica que processa dados em blocos fixos de 128 bits utilizando chaves de 128, 192 ou 256 bits através de rodadas consecutivas de operações matemáticas: SubBytes, ShiftRows, MixColumns e AddRoundKey. 2. A Falha Crítica dos Modos Legados: - Electronic Codebook (ECB): Cifra cada bloco de 128 bits de forma independente com a mesma chave. Padrões idênticos no texto claro geram blocos cifrados idênticos, preservando a silhueta visual dos dados (o clássico vazamento do Tux do Linux). - Cipher Block Chaining (CBC): Resolve a repetição através de encadeamento com vetor de inicialização (IV), mas requer preenchimento (Padding PKCS#7), tornando-se vulnerável a Ataques de Padding Oracle que permitem a um atacante decifrar mensagens sem conhecer a chave. 3. Authenticated Encryption with Associated Data (AEAD - AES-GCM): - O modo Galois/Counter Mode (GCM) combina o modo contador (CTR) para cifragem com multiplicação no corpo de Galois ($ ext{GF}(2^{128})$) para calcular uma Tag de Autenticação (MAC). - Qualquer adulteração de um único bit no texto cifrado ou nos dados adicionais (AAD) faz a decifragem falhar imediatamente, garantindo confidencialidade e integridade simultâneas.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    Plaintext["Texto Claro"] --> CTR["Modo Contador (AES-CTR)"]
    IV["Vetor de Inicialização (Nonce Único)"] --> CTR
    Key["Chave Secreta Simétrica (256 bits)"] --> CTR
    CTR --> Ciphertext["Texto Cifrado"]
    Ciphertext & AAD["Dados Adicionais Não Cifrados (Headers/TenantID)"] --> GHASH["Multiplicação Galois (GHASH)"]
    GHASH --> Tag["Authentication Tag (128 bits)"]
    style Plaintext fill:#e1f5fe,stroke:#01579b
    style Key fill:#ffebee,stroke:#c62828
    style Ciphertext fill:#fff3e0,stroke:#e65100
    style Tag fill:#e8f5e9,stroke:#2e7d32

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Unicidade Obrigatória do Nonce: A reutilização de um mesmo Nonce com a mesma chave em AES-GCM destrói completamente a segurança do modo, permitindo a recuperação da chave de autenticação. - Authenticated Data (AAD): Permite autenticar metadados (como IDs de usuários, portas ou rotas) que devem trafegar em texto claro mas não podem ser forjados. - Aceleração por Hardware (AES-NI): Instruções nativas de processadores modernos que executam criptografia AES em taxa de múltiplos gigabytes por segundo. - Prevenção Contra Ataques de Replay: Inclusão de contadores de sequência ou timestamps dentro do envelope criptográfico autenticado.

🛠️ 2. Implementação Prática em Criptografia Simétrica e Modos de Operação Autenticados

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// aes_gcm_aead.py (Cifragem Autenticada com Validação de Integridade e Metadados)
import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

def secure_encrypt_payload(key: bytes, plaintext: bytes, associated_data: bytes):
    """Cifra payload usando AES-256-GCM com proteção de integridade."""
    # 1. Nonce de 96 bits (12 bytes) gerado com entropia criptográfica segura
    nonce = os.urandom(12)
    aesgcm = AESGCM(key)

    # 2. Cifragem e geração automática da tag de autenticação de 16 bytes
    ciphertext = aesgcm.encrypt(nonce, plaintext, associated_data)
    return nonce + ciphertext

def secure_decrypt_payload(key: bytes, encrypted_blob: bytes, associated_data: bytes):
    """Decifra e valida se a integridade dos dados foi violada."""
    nonce = encrypted_blob[:12]
    ciphertext = encrypted_blob[12:]
    aesgcm = AESGCM(key)

    # Decripta e valida a tag; lança InvalidTag se adulterado!
    return aesgcm.decrypt(nonce, ciphertext, associated_data)

if __name__ == '__main__':
    chave_mestre = AESGCM.generate_key(bit_length=256)
    dado_secreto = b"Dados ultra confidenciais de cartao de credito"
    metadado_auditoria = b"tenant_id:42|operacao:pagamento"

    pacote = secure_encrypt_payload(chave_mestre, dado_secreto, metadado_auditoria)
    print(f"Pacote criptografado com sucesso ({len(pacote)} bytes)")

    recuperado = secure_decrypt_payload(chave_mestre, pacote, metadado_auditoria)
    print(f"Texto decifrado com garantia matemática de integridade: {recuperado.decode()}")

💡 Análise Passo a Passo do Código

  1. Geração do Nonce via os.urandom(12): Garante que cada pacote cifrado utilize um vetor de inicialização criptograficamente único.
  2. Associação de Metadados (associated_data): Protege dados estruturais contra adulteração mesmo sem ocultar seu conteúdo.
  3. Lançamento de Exceção InvalidTag: Impede que qualquer dado corrompido ou forjado seja entregue à camada de aplicação.

🎯 3. Próximos Passos & Sequência Didática

Aula 19 - Análise de Vulnerabilidades, Fuzzing e Engenharia Reversa 🧪

Objetivo Pedagógico

Objetivo: Aplicar técnicas avançadas de segurança ofensiva e pesquisa de vulnerabilidades: fuzzing guiado por cobertura de código com AFL/Atheris, análise estática/dinâmica de binários com Ghidra e mitigação de vulnerabilidades de corrupção de memória.

📑 1. Fundamentos Teóricos & Análise Técnica

A identificação proativa de falhas de segurança em software antes de agentes maliciosos exige o domínio de metodologias avançadas de testes de robustez.

O ecossistema de análise avançada divide-se em abordagens dinâmicas e estáticas: 1. Fuzz Testing (Fuzzing Guiado por Cobertura): - Ao contrário de testes aleatórios simples, ferramentas modernas como AFL (American Fuzzy Lop) e LibFuzzer utilizam instrumentação de compilação ou de runtime para mapear cada ramificação de código (Basic Block) percorrida pelo programa. - O motor de mutação altera os dados de entrada guiando-se pela descoberta de novos caminhos (Coverage-Guided Fuzzing), descobrindo rapidamente estados não previstos que causam panics, vazamentos de memória e estouros de buffer (Buffer Overflows). 2. Engenharia Reversa com Descompiladores Modernos (Ghidra / IDA Pro): - Permite analisar o comportamento de componentes de terceiros, drivers ou binários fechados sem acesso ao código-fonte original. - O descompilador reconstrói a representação intermediária (SRE - Software Reverse Engineering) a partir de instruções em código de máquina (x86_64, ARM64), identificando padrões inseguros de tratamento de ponteiros e chamadas desprotegidas. 3. Mitigações Modernas de Sistema Operacional: - Compiladores e kernels implementam barreiras contra exploração: Stack Canaries (detecção de sobrescrita de ponteiro de retorno), ASLR (Address Space Layout Randomization) (embaralhamento de memória) e páginas de memória W^X / DEP (páginas ou são executáveis ou são graváveis, jamais ambas).

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    Corpus["Corpus de Entradas Válidas"] --> Engine["Motor de Mutação do Fuzzer (Atheris / AFL)"]
    Engine --> Input["Geração de Entrada Mutada com Borda Anômala"]
    Input --> Target["Binário / Função Alvo Instrumentada"]
    Target --> Monitor{"Ocorreu Crash / Falha de Memória?"}
    Monitor -- Sim --> Triage["Salva Entrada de Crash para Reprodução (Bug / CVE)"]
    Monitor -- Não --> Feedback["Feedback de Cobertura: Cobriu Novo Branch?"]
    Feedback -- Sim --> Corpus
    Feedback -- Não --> Discard["Descarta Mutação"]
    style Corpus fill:#e1f5fe,stroke:#01579b
    style Engine fill:#fff3e0,stroke:#e65100
    style Triage fill:#ffebee,stroke:#c62828
    style Target fill:#f3e5f5,stroke:#7b1fa2
    style Feedback fill:#e8f5e9,stroke:#2e7d32

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - AddressSanitizer (ASan): Ferramenta de instrumentação que detecta acessos fora dos limites de arrays, uso após liberação (Use-After-Free) e vazamentos de memória. - Minimização de Casos de Falha: Algoritmo que reduz o arquivo causador de um crash ao menor número de bytes possível para facilitar a análise. - Análise de Fluxo de Controle (CFG): Representação visual das bifurcações e laços de um executável na engenharia reversa. - Fuzzing Contínuo (OSS-Fuzz): Integração do fuzz testing em pipelines contínuos de desenvolvimento de software de código aberto.

🛠️ 2. Implementação Prática em Segurança Ofensiva, Fuzz Testing e Engenharia Reversa

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// atheris_fuzz_target.py (Alvo de Fuzzing com Atheris / LibFuzzer em Python)
import sys
import json
# import atheris # Framework de Fuzzing guiado por cobertura para Python

def parser_critico_alvo(data: bytes):
    """Função hipotética de parsing sob teste de estresse e integridade."""
    if len(data) < 4:
        return

    # Simula vulnerabilidade que causa crash sob payload específico
    if data[0] == 0xFF and data[1] == 0x55:
        texto = data[2:].decode('utf-8') # Pode disparar UnicodeDecodeError não tratado!
        obj = json.loads(texto)
        if obj.get("admin") is True and len(obj.get("token", "")) > 100:
            raise ValueError("Buffer overflow lógico simulado em parser!")

def TestOneInput(data: bytes):
    """Harness de teste consumido pelo motor de Fuzzing."""
    try:
        parser_critico_alvo(data)
    except (json.JSONDecodeError, UnicodeDecodeError):
        # Exceções esperadas e tratadas são ignoradas
        pass

if __name__ == '__main__':
    print("Fuzzer Harness configurado e pronto para execução contínua com LibFuzzer.")
    # atheris.Setup(sys.argv, TestOneInput)
    # atheris.Fuzz()

💡 Análise Passo a Passo do Código

  1. Função TestOneInput: Interface padrão consumida pelo motor de fuzzing para injeção contínua de milhões de payloads.
  2. Filtragem de Exceções Conhecidas: Permite ao fuzzer ignorar erros esperados e focar exclusivamente em falhas críticas e crashes inesperados.
  3. Instrumentação de Cobertura: Guia mutações genéticas de bytes para explorar ramos profundos do interpretador.

🎯 3. Próximos Passos & Sequência Didática

Aula 20 - Projeto Capstone: Módulo de Criptografia e Segurança Autônomo 🚀

Objetivo Pedagógico

Objetivo: Engenhar um subsistema autônomo de criptografia de envelope (Envelope Encryption), gerenciamento de chaves mestre (KMS), assinatura e verificação digital e auditoria forense inviolável baseada em encadeamento criptográfico de blocos.

📑 1. Fundamentos Teóricos & Análise Técnica

A proteção holística de dados em nível corporativo não depende de primitivas isoladas, mas da harmonização de uma Arquitetura Criptográfica de Envelope.

O Projeto Capstone de Segurança e Criptografia consolida uma solução defensiva completa: 1. Envelope Encryption (Criptografia de Envelope): - Em vez de enviar grandes volumes de dados para um serviço de gerenciamento de chaves centralizado (KMS/HSM), o sistema utiliza uma Chave Mestre de Chaveamento (Key Encryption Key - KEK) protegida no KMS para cifrar apenas uma chave temporária e única: a Chave de Dados (Data Encryption Key - DEK). - O payload é cifrado localmente com a DEK em alta velocidade usando AES-256-GCM. Apenas a DEK cifrada é persistida junto com o texto cifrado (Envelope), reduzindo custos e latência de rede. 2. Log de Auditoria Auditável e Inviolável (Cryptographic Audit Trail): - Cada evento de segurança registrado no log contém o hash criptográfico do evento anterior (Hash Chain), exatamente como uma blockchain. - Se qualquer atacante adulterar um registro histórico no banco de dados para ocultar uma invasão, a cadeia criptográfica é quebrada imediatamente, acusando a fraude na auditoria.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    Data["Dados Sensíveis do Cliente"] --> Engine["Módulo de Segurança Local"]
    KMS["Hardware Security Module (KMS / HSM)"] --> Generate["Gera Nova DEK (Plaintext + Encrypted KEK)"]
    Generate --> Engine
    Engine --> Encrypt["Cifra Dados Localmente com DEK em AES-GCM"]
    Encrypt --> Envelope["Envelope Criptográfico: [DEK Cifrada + Nonce + Payload + Tag]"]
    Engine --> Wipe["Purga DEK da Memória RAM (Zeroing)"]
    Envelope --> Storage["Armazenamento Persistente Seguro"]
    Storage --> Audit["Hash Chain: Evento N encapsula Hash do Evento N-1"]
    style Data fill:#e1f5fe,stroke:#01579b
    style KMS fill:#fff3e0,stroke:#e65100
    style Encrypt fill:#f3e5f5,stroke:#7b1fa2
    style Envelope fill:#e8f5e9,stroke:#2e7d32
    style Audit fill:#e0f2f1,stroke:#00695c

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Envelope Encryption: Arquitetura que combina a robustez física de módulos HSM com o rendimento de cifras de bloco locais. - Zeroização Segura de Memória: Limpeza ativa dos bytes da chave na memória RAM após o uso para prevenir despejo de memória (Memory Dump). - Cadeia Criptográfica de Auditoria (Hash Chaining): Garante a integridade sequencial dos registros forenses contra adulterações retroativas. - Não-Repúdio com Assinatura Digital: Cada evento do log é assinado digitalmente com a chave privada da autoridade de serviço.

🛠️ 2. Implementação Prática em Engenharia de Segurança, Envelope Criptográfico e Auditoria

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// envelope_encryption_capstone.py (Módulo Capstone de Envelope Criptográfico e Log Inviolável)
import os
import hashlib
import time
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

class SecureCryptoModule:
    """Módulo de Envelope Criptográfico e Auditoria Forense Inviolável."""
    def __init__(self, master_kek: bytes):
        self.master_kek = master_kek
        self.audit_chain_head = "0" * 64

    def generate_envelope(self, plaintext: bytes):
        """Cifra payload utilizando uma Data Key efêmera cifrada pela Master Key."""
        # 1. Gerar chave efêmera de dados (DEK)
        dek = AESGCM.generate_key(bit_length=256)

        # 2. Cifrar payload com a DEK
        dek_cipher = AESGCM(dek)
        nonce_payload = os.urandom(12)
        encrypted_payload = dek_cipher.encrypt(nonce_payload, plaintext, None)

        # 3. Cifrar a DEK com a KEK (Master Key)
        kek_cipher = AESGCM(self.master_kek)
        nonce_dek = os.urandom(12)
        encrypted_dek = kek_cipher.encrypt(nonce_dek, dek, None)

        # 4. Registrar auditoria criptográfica
        self._record_audit_event("ENCRYPT_DATA", len(plaintext))

        return {
            "encrypted_dek": encrypted_dek,
            "nonce_dek": nonce_dek,
            "encrypted_payload": encrypted_payload,
            "nonce_payload": nonce_payload,
        }

    def _record_audit_event(self, action: str, size: int):
        """Adiciona elo criptográfico inviolável na cadeia de auditoria."""
        timestamp = time.time()
        record_content = f"{self.audit_chain_head}:{timestamp}:{action}:{size}"
        new_hash = hashlib.sha256(record_content.encode()).hexdigest()
        self.audit_chain_head = new_hash
        print(f"[AUDIT LOG] Evento registrado na Hash Chain. Novo Hash Head: {new_hash[:16]}...")

if __name__ == '__main__':
    kek = AESGCM.generate_key(bit_length=256)
    sec_module = SecureCryptoModule(kek)
    envelope = sec_module.generate_envelope(b"Registro Financeiro Confidencial #9841")
    print("Módulo Capstone de Criptografia Operacional com Envelope Criptográfico Ativo!")

💡 Análise Passo a Passo do Código

  1. Duplo Nível de Cifragem (KEK/DEK): Separa a custódia das chaves mestre da cifragem operacional de alto volume.
  2. Hash Chain com SHA-256: Conecta cada evento de auditoria ao hash do evento anterior garantindo não-adulteração.
  3. Estrutura Completa de Envelope: Armazena todos os vetores e tags necessários para decifragem autorizada posterior.

🎯 3. Próximos Passos & Sequência Didática

Exercícios

🏋️ Exercícios do Curso

Lista completa das 20 unidades de exercicios organizadas em 5 módulos didáticos.

🏋️ Exercício 01 – Introdução à Segurança da Informação ️

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 01 sobre Introdução à Segurança da Informação ️, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Introdução à Segurança da Informação ️, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Introdução à Segurança da Informação ️** fundamenta-se em princípios consolidados de engenharia de software (O que é Segurança da Informação?, A Tríade CIA (CID), Quem são os "adversários"?, Segurança na Prática do Dia a Dia). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Introdução à Segurança da Informação ️. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Introdução à Segurança da Informação ️** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Introdução à Segurança da Informação ️. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 01 Responder Quiz 01

🏋️ Exercício 02 – Ameaças, Vulnerabilidades e Ataques ️

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 02 sobre Ameaças, Vulnerabilidades e Ataques ️, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Ameaças, Vulnerabilidades e Ataques ️, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Ameaças, Vulnerabilidades e Ataques ️** fundamenta-se em princípios consolidados de engenharia de software (Ameaça x Vulnerabilidade x Risco, Engenharia Social, ️ Vetores de Ataque Técnicos Mais Comuns, Verificando Exposição Básica). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Ameaças, Vulnerabilidades e Ataques ️. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Ameaças, Vulnerabilidades e Ataques ️** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Ameaças, Vulnerabilidades e Ataques ️. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 02 Responder Quiz 02

🏋️ Exercício 03 – Fundamentos de Criptografia

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 03 sobre Fundamentos de Criptografia, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Fundamentos de Criptografia, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Fundamentos de Criptografia** fundamenta-se em princípios consolidados de engenharia de software (O que é Criptografia?, Um Pouco de História: a Cifra de César, O Princípio de Kerckhoffs, As Duas Grandes Famílias). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Fundamentos de Criptografia. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Fundamentos de Criptografia** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Fundamentos de Criptografia. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 03 Responder Quiz 03

🏋️ Exercício 04 – Criptografia Simétrica (AES e DES)

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 04 sobre Criptografia Simétrica (AES e DES), cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Criptografia Simétrica (AES e DES), definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Criptografia Simétrica (AES e DES)** fundamenta-se em princípios consolidados de engenharia de software (Como Funciona a Criptografia Simétrica, DES: o Padrão Histórico, ️ AES: o Padrão Atual, Modos de Operação). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Criptografia Simétrica (AES e DES). Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Criptografia Simétrica (AES e DES)** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Criptografia Simétrica (AES e DES). Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 04 Responder Quiz 04

🏋️ Exercício 05 – Criptografia Assimétrica (RSA e Diffie-Hellman)

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 05 sobre Criptografia Assimétrica (RSA e Diffie-Hellman), cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Criptografia Assimétrica (RSA e Diffie-Hellman), definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Criptografia Assimétrica (RSA e Diffie-Hellman)** fundamenta-se em princípios consolidados de engenharia de software (️ O Par de Chaves, RSA: a Matemática por Trás, Diffie-Hellman: Combinando uma Chave em Público, ⚖️ Simétrica vs. Assimétrica: Por que usar as duas juntas?). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Criptografia Assimétrica (RSA e Diffie-Hellman). Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Criptografia Assimétrica (RSA e Diffie-Hellman)** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Criptografia Assimétrica (RSA e Diffie-Hellman). Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 05 Responder Quiz 05

🏋️ Exercício 06 – Funções de Hash e Integridade #️⃣

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 06 sobre Funções de Hash e Integridade #️⃣, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Funções de Hash e Integridade #️⃣, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Funções de Hash e Integridade #️⃣** fundamenta-se em princípios consolidados de engenharia de software (O que é uma Função de Hash?, Principais Algoritmos de Hash, ✅ Verificação de Integridade, Hash com Chave: HMAC). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Funções de Hash e Integridade #️⃣. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Funções de Hash e Integridade #️⃣** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Funções de Hash e Integridade #️⃣. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 06 Responder Quiz 06

🏋️ Exercício 07 – Assinaturas Digitais e Certificados (PKI)

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 07 sobre Assinaturas Digitais e Certificados (PKI), cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Assinaturas Digitais e Certificados (PKI), definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Assinaturas Digitais e Certificados (PKI)** fundamenta-se em princípios consolidados de engenharia de software (✍️ Assinatura Digital: o Inverso da Cifragem Assimétrica, O Problema da Confiança: quem garante que a chave pública é sua mesmo?, ️ PKI: Infraestrutura de Chave Pública, Inspecionando um Certificado Real). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Assinaturas Digitais e Certificados (PKI). Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Assinaturas Digitais e Certificados (PKI)** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Assinaturas Digitais e Certificados (PKI). Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 07 Responder Quiz 07

🏋️ Exercício 08 – Autenticação e Controle de Acesso

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 08 sobre Autenticação e Controle de Acesso, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Autenticação e Controle de Acesso, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Autenticação e Controle de Acesso** fundamenta-se em princípios consolidados de engenharia de software (‍ Os Três Fatores de Autenticação, O Padrão Mais Comum: TOTP, Autenticação x Autorização, ️ Modelos de Controle de Acesso). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Autenticação e Controle de Acesso. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Autenticação e Controle de Acesso** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Autenticação e Controle de Acesso. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 08 Responder Quiz 08

🏋️ Exercício 09 – TLS/SSL e Segurança em Redes

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 09 sobre TLS/SSL e Segurança em Redes, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de TLS/SSL e Segurança em Redes, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **TLS/SSL e Segurança em Redes** fundamenta-se em princípios consolidados de engenharia de software (SSL x TLS: qual a diferença?, O TLS Handshake, HTTPS: HTTP sobre TLS, ️ Ataques que o TLS Previne (e os que não previne)). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo TLS/SSL e Segurança em Redes. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **TLS/SSL e Segurança em Redes** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em TLS/SSL e Segurança em Redes. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 09 Responder Quiz 09

🏋️ Exercício 10 – Criptografia na Prática com Python

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 10 sobre Criptografia na Prática com Python, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Criptografia na Prática com Python, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Criptografia na Prática com Python** fundamenta-se em princípios consolidados de engenharia de software (Instalando a Biblioteca, Hash com `hashlib` (biblioteca padrão), Criptografia Simétrica com Fernet, Criptografia Assimétrica com RSA em Python). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Criptografia na Prática com Python. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Criptografia na Prática com Python** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Criptografia na Prática com Python. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 10 Responder Quiz 10

🏋️ Exercício 11 – Criptografia na Prática com JavaScript

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 11 sobre Criptografia na Prática com JavaScript, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Criptografia na Prática com JavaScript, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Criptografia na Prática com JavaScript** fundamenta-se em princípios consolidados de engenharia de software (A Web Crypto API, #️⃣ Hash com `crypto.subtle.digest`, Criptografia Simétrica (AES-GCM) no Navegador, Testando no Console do Navegador). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Criptografia na Prática com JavaScript. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Criptografia na Prática com JavaScript** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Criptografia na Prática com JavaScript. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 11 Responder Quiz 11

🏋️ Exercício 12 – Segurança em Aplicações Web (OWASP Top 10) ️

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 12 sobre Segurança em Aplicações Web (OWASP Top 10) ️, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Segurança em Aplicações Web (OWASP Top 10) ️, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Segurança em Aplicações Web (OWASP Top 10) ️** fundamenta-se em princípios consolidados de engenharia de software (️ O que é a OWASP?, As Categorias do OWASP Top 10, Foco Prático: SQL Injection, ️ Foco Prático: XSS (Cross-Site Scripting)). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Segurança em Aplicações Web (OWASP Top 10) ️. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Segurança em Aplicações Web (OWASP Top 10) ️** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Segurança em Aplicações Web (OWASP Top 10) ️. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 12 Responder Quiz 12

🏋️ Exercício 13 – Gestão e Armazenamento Seguro de Senhas ️

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 13 sobre Gestão e Armazenamento Seguro de Senhas ️, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Gestão e Armazenamento Seguro de Senhas ️, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Gestão e Armazenamento Seguro de Senhas ️** fundamenta-se em princípios consolidados de engenharia de software (❌ O que NUNCA fazer, Sal (Salt): a Primeira Defesa, Funções de Hash Lentas de Propósito, Hash de Senha com bcrypt em Python). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Gestão e Armazenamento Seguro de Senhas ️. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Gestão e Armazenamento Seguro de Senhas ️** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Gestão e Armazenamento Seguro de Senhas ️. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 13 Responder Quiz 13

🏋️ Exercício 14 – Privacidade de Dados e LGPD ️

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 14 sobre Privacidade de Dados e LGPD ️, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Privacidade de Dados e LGPD ️, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Privacidade de Dados e LGPD ️** fundamenta-se em princípios consolidados de engenharia de software (O que é a LGPD?, Dado Pessoal x Dado Sensível, ⚖️ Os Princípios da LGPD, Direitos do Titular dos Dados). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Privacidade de Dados e LGPD ️. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Privacidade de Dados e LGPD ️** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Privacidade de Dados e LGPD ️. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 14 Responder Quiz 14

🏋️ Exercício 15 – Auditoria e Testes de Segurança

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 15 sobre Auditoria e Testes de Segurança, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Auditoria e Testes de Segurança, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Auditoria e Testes de Segurança** fundamenta-se em princípios consolidados de engenharia de software (️ Pentest x Auditoria x Bug Bounty, SAST x DAST: Duas Formas de Analisar Código, Gestão de Dependências (SCA), Logging e Monitoramento). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Auditoria e Testes de Segurança. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Auditoria e Testes de Segurança** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Auditoria e Testes de Segurança. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 15 Responder Quiz 15

🏋️ Exercício 16 – Projeto Final: Sistema de Autenticação Seguro

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 16 sobre Projeto Final: Sistema de Autenticação Seguro, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Projeto Final: Sistema de Autenticação Seguro, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Projeto Final: Sistema de Autenticação Seguro** fundamenta-se em princípios consolidados de engenharia de software (O Cenário, ️ Requisitos do Projeto, Arquitetura Proposta, Ponto de Partida Sugerido (Python)). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Projeto Final: Sistema de Autenticação Seguro. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Projeto Final: Sistema de Autenticação Seguro** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Projeto Final: Sistema de Autenticação Seguro. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 16 Responder Quiz 16

Projetos

🚀 Projetos do Curso

Lista completa das 20 unidades de projetos organizadas em 5 módulos didáticos.

Projeto 01: Modelagem da Tríade CIA e Arquitetura Zero Trust 🛡️

Escopo do Projeto

Objetivo: Conceber uma matriz de segurança corporativa aplicando a Tríade CIA (Confidencialidade, Integridade e Disponibilidade) e os princípios fundamentais da arquitetura Zero Trust (Nunca confie, sempre verifique).

🎯 1. Contexto & Desafio Prático

Sistemas modernos não podem mais confiar na proteção perimetral tradicional de firewalls de rede. Você elaborará a modelagem de segurança de uma plataforma de serviços médicos (prontuários de saúde), estabelecendo controles compensatórios para garantir confidencialidade dos pacientes, integridade dos diagnósticos e alta disponibilidade operacional.

📋 2. Requisitos Técnicos Obrigatórios

  • R1 (Matriz de Classificação de Ativos): Classificar os ativos de dados em Público, Interno, Confidencial e Estritamente Secreto segundo o impacto de vazamento.
  • R2 (Controles da Tríade CIA): Definir para cada ativo pelo menos 2 controles técnicos: Criptografia em repouso (C), Assinaturas criptográficas (I) e Redundância Multi-AZ (A).
  • R3 (Princípio do Privilégio Mínimo): Projetar a política de concessão de acesso estrita onde médicos, enfermeiros e auditores só acessam registros sob necessidade estrita (Need-to-know).
  • R4 (Autenticação Contínua Zero Trust): Especificar regras de revalidação de contexto dinâmico baseadas em IP de origem, dispositivo corporativo gerenciado e MFA.

📐 3. Diagrama Conceitual & Arquitetura

graph TD
    Client["Acesso do Médico / Operador"] --> Gateway["Zero Trust Policy Enforcement Point (PEP)"]
    Gateway --> AuthContext["Avaliação de Contexto: Dispositivo Seguro + MFA + Local"]
    AuthContext --> Decision{"Acesso Válido?"}
    Decision -- Sim --> Service["Acesso com Menor Privilégio ao Prontuário Cifrado"]
    Decision -- Não --> Block["Bloqueio Imediato & Alerta no SIEM"]
    style Client fill:#e1f5fe,stroke:#01579b
    style Gateway fill:#fff3e0,stroke:#e65100
    style AuthContext fill:#f3e5f5,stroke:#7b1fa2
    style Service fill:#e8f5e9,stroke:#2e7d32
    style Block fill:#ffebee,stroke:#c62828

💻 4. Especificação Técnica & Código de Referência

// politica_zero_trust.json
{
  "policy_name": "ZeroTrustMedicalRecordsAccess",
  "rules": [
    {
      "resource": "/api/v1/patient-records/*",
      "required_role": "ROLE_DOCTOR",
      "context_checks": {
        "device_trusted": true,
        "mfa_verified": true,
        "max_session_age_minutes": 15
      },
      "encryption": {
        "in_transit": "TLS_1_3",
        "at_rest": "AES_256_GCM"
      }
    }
  ]
}

📦 5. Critérios de Avaliação e Entrega

  1. Matriz CIA completa cobrindo confidencialidade, integridade e disponibilidade.
  2. Políticas de controle de acesso baseadas em Zero Trust bem documentadas.
  3. Especificação técnica em formato JSON declarativo.

Projeto 02: Modelagem de Ameaças com Framework STRIDE 🎯

Escopo do Projeto

Objetivo: Executar a modelagem de ameaças de uma arquitetura de microsserviços aplicando a metodologia STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service e Elevation of Privilege).

🎯 1. Contexto & Desafio Prático

A segurança preventiva de software começa antes da primeira linha de código ser escrita. Você analisará o fluxo de dados de uma carteira digital (Fintech), mapeando todos os pontos de entrada de dados não confiáveis e determinando as contramedidas necessárias para neutralizar as 6 categorias de ameaça do STRIDE.

📋 2. Requisitos Técnicos Obrigatórios

  • R1 (Diagrama de Fluxo de Dados - DFD): Elaborar o DFD de Nível 1 destacando fronteiras de confiança (Trust Boundaries), processos, datastores e fluxos de rede.
  • R2 (Matriz STRIDE Exaustiva): Mapear no mínimo 1 ameaça real para cada letra do acrônimo STRIDE sobre os elementos da arquitetura.
  • R3 (Contramedidas de Engenharia): Para cada ameaça levantada, associar a tecnologia de mitigação mandatória (ex: MTLS para Spoofing, HMAC para Tampering).
  • R4 (Cálculo de Severidade DREAD ou CVSS): Priorizar as vulnerabilidades atribuindo escores de risco objetivo.

📐 3. Diagrama Conceitual & Arquitetura

graph LR
    User["Cliente Web"] -->|Trust Boundary 1| API["API Gateway (Borda)"]
    API -->|Trust Boundary 2| Core["Core Banking Service"]
    Core --> DB[("PostgreSQL Aurora")]
    Threat1["Spoofing: Impersonar Usuário"] -.-> User
    Threat2["Tampering: Alterar Valor do Pix"] -.-> API
    Threat3["Info Disclosure: Vazamento de Saldo"] -.-> DB
    style User fill:#e1f5fe,stroke:#01579b
    style API fill:#fff3e0,stroke:#e65100
    style Core fill:#f3e5f5,stroke:#7b1fa2
    style DB fill:#e8f5e9,stroke:#2e7d32
    style Threat1 fill:#ffebee,stroke:#c62828
    style Threat2 fill:#ffebee,stroke:#c62828
    style Threat3 fill:#ffebee,stroke:#c62828

💻 4. Especificação Técnica & Código de Referência

// stride_threat_matrix.md
| Categoria | Ameaça Identificada | Impacto | Contramedida de Engenharia |
| :--- | :--- | :---: | :--- |
| **S (Spoofing)** | Atacante forja token de acesso de outro usuário | Crítico | JWT assinado com chave assimétrica Ed25519 e verificação OIDC |
| **T (Tampering)** | Adulteração do payload da transação financeira em trânsito | Crítico | Cifragem autenticada AES-GCM com validação de tag e TLS 1.3 estrito |
| **R (Repudiation)**| Usuário nega ter efetuado transferência de alto valor | Alto | Assinatura digital do comprovante e auditoria criptográfica em Hash Chain |
| **I (Info Leak)** | Vazamento de dados de cartão em logs de erro | Alto | Sanitização automática de logs e mascaramento de campos confidenciais |
| **D (DoS)** | Exaustão de conexões via flood de requisições maliciosas | Médio | Rate limiting dinâmico em Redis e Web Application Firewall (WAF) |
| **E (Elevation)** | Usuário comum altera ID no header para virar Administrador | Crítico | Validação de escopos RBAC na camada de domínio com tokens opacos |

📦 5. Critérios de Avaliação e Entrega

  1. DFD completo com demarcação clara das fronteiras de confiança.
  2. Matriz STRIDE cobrindo as 6 categorias com contramedidas técnicas viáveis.
  3. Priorização clara dos riscos pelo impacto de negócio.

Projeto 03: Análise Criptográfica de Cifras Clássicas e Entropia 🔐

Escopo do Projeto

Objetivo: Implementar e analisar a quebra criptográfica de cifras clássicas de substituição (Cifra de César e Vigenère) utilizando análise de frequência de caracteres e calcular a entropia de Shannon de geradores de números pseudoaleatórios.

🎯 1. Contexto & Desafio Prático

Para compreender a robustez dos algoritmos criptográficos modernos, é essencial dominar os princípios matemáticos que causaram o colapso dos sistemas históricos. Você construirá uma ferramenta em Python que decifra textos cifrados com Vigenère sem conhecer a chave e analisa a qualidade de entropia de chaves geradas.

📋 2. Requisitos Técnicos Obrigatórios

  • R1 (Implementação de Cifras Históricas): Implementar codificadores e decodificadores para Cifra de César e Cifra de Vigenère em Python puro.
  • R2 (Criptoanálise por Frequência): Construir algoritmo de ataque que analisa a frequência de letras na língua portuguesa para deduzir a chave de César e o tamanho da chave de Vigenère (Método Kasiski).
  • R3 (Cálculo da Entropia de Shannon): Calcular numericamente a entropia de Shannon (\(H = -\sum p_i \log_2 p_i\)) de geradores inseguros (random.random) vs geradores criptográficos (secrets.token_bytes).
  • R4 (Relatório Criptoanalítico): Demonstrar o texto original recuperado a partir de um texto cifrado misterioso fornecido.

📐 3. Diagrama Conceitual & Arquitetura

graph TD
    Ciphertext["Texto Cifrado (Vigenère)"] --> Freq["Análise de Frequência de Caracteres"]
    Freq --> Kasiski["Exame Kasiski: Dedução do Comprimento da Chave"]
    Kasiski --> Decrypt["Decifração Automática por Chi-Square"]
    Decrypt --> Plaintext["Texto Claro Original Recuperado!"]
    style Ciphertext fill:#ffebee,stroke:#c62828
    style Freq fill:#fff3e0,stroke:#e65100
    style Kasiski fill:#f3e5f5,stroke:#7b1fa2
    style Plaintext fill:#e8f5e9,stroke:#2e7d32

💻 4. Especificação Técnica & Código de Referência

// shannon_entropy.py
import math
from collections import Counter
import secrets
import random

def shannon_entropy(data: bytes) -> float:
    """Calcula a entropia de Shannon em bits por byte (máximo 8.0)."""
    if not data:
        return 0.0
    counts = Counter(data)
    total = len(data)
    entropy = 0.0
    for count in counts.values():
        p = count / total
        entropy -= p * math.log2(p)
    return entropy

if __name__ == '__main__':
    # Chave gerada com baixa entropia (previsível)
    low_entropy = bytes([random.randint(65, 90) for _ in range(1000)])
    # Chave gerada com CSPRNG de alta entropia
    high_entropy = secrets.token_bytes(1000)

    print(f"Entropia Baixa (random): {shannon_entropy(low_entropy):.3f} bits/byte")
    print(f"Entropia Alta (secrets): {shannon_entropy(high_entropy):.3f} bits/byte (Ideal ~8.0)")

📦 5. Critérios de Avaliação e Entrega

  1. Algoritmo de ataque por análise de frequência decifrando textos sem chave prévia.
  2. Cálculo matemático correto da entropia de Shannon comparando CSPRNGs.
  3. Demonstração em terminal dos testes estatísticos de distribuição.

Projeto 04: Criptografia Simétrica de Bloco: AES-CBC vs AES-GCM 🔒

Escopo do Projeto

Objetivo: Implementar cifragem de arquivos com o padrão AES de 256 bits, analisando os riscos de vazamento e ataques de padding oracle no modo CBC e dominando a integridade autenticada no modo moderno GCM (AEAD).

🎯 1. Contexto & Desafio Prático

A cifragem de dados em repouso exige a escolha correta do modo de operação de cifras de bloco. Você construirá uma ferramenta de terminal de cifragem e decifragem de arquivos sensíveis com AES-256, demonstrando por que o modo GCM impede adulterações de bits que passavam despercebidas no modo CBC.

📋 2. Requisitos Técnicos Obrigatórios

  • R1 (Implementação com AES-256-GCM): Utilizar chave de 256 bits gerada com CSPRNG e Nonce criptograficamente único de 96 bits (12 bytes).
  • R2 (Demonstração do Falha do CBC): Demonstrar o ataque de manipulação de bits (Bit-Flipping Attack) no modo CBC sem detecção de corrupção.
  • R3 (Validação da Tag de Autenticação em GCM): Comprovar que qualquer alteração de 1 bit no arquivo cifrado em GCM gera rejeição imediata com exceção InvalidTag.
  • R4 (CLI de Cifragem de Arquivos): Construir utilitário CLI: secure-vault encrypt <file> -k <key> e secure-vault decrypt <file> -k <key>.

📐 3. Diagrama Conceitual & Arquitetura

graph TD
    File["Arquivo Confidencial"] --> Nonce["Nonce Único (12 Bytes)"]
    File & Nonce --> AESGCM["Cifra AES-256-GCM (AEAD)"]
    Key["Chave de 256 bits"] --> AESGCM
    AESGCM --> Encrypted["Envelope Cifrado [Nonce + Ciphertext + AuthTag]"]
    Encrypted --> Attack{"Atacante adultera 1 bit no disco"}
    Attack --> DecryptFail["Decifragem rejeitada: Tag Inválida! Integridade Garantida."]
    style File fill:#e1f5fe,stroke:#01579b
    style AESGCM fill:#fff3e0,stroke:#e65100
    style Encrypted fill:#e8f5e9,stroke:#2e7d32
    style DecryptFail fill:#ffebee,stroke:#c62828

💻 4. Especificação Técnica & Código de Referência

// aes_vault_cli.py
import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

def encrypt_file(filepath: str, key: bytes, output_path: str):
    with open(filepath, 'rb') as f:
        plaintext = f.read()
    aesgcm = AESGCM(key)
    nonce = os.urandom(12)
    ciphertext = aesgcm.encrypt(nonce, plaintext, None)
    with open(output_path, 'wb') as f:
        f.write(nonce + ciphertext)
    print(f"Arquivo cifrado com sucesso em: {output_path}")

def decrypt_file(filepath: str, key: bytes, output_path: str):
    with open(filepath, 'rb') as f:
        data = f.read()
    nonce, ciphertext = data[:12], data[12:]
    aesgcm = AESGCM(key)
    plaintext = aesgcm.decrypt(nonce, ciphertext, None) # Lança InvalidTag se violado
    with open(output_path, 'wb') as f:
        f.write(plaintext)
    print(f"Arquivo decifrado e verificado com sucesso em: {output_path}")

📦 5. Critérios de Avaliação e Entrega

  1. Cifragem e decifragem de arquivos executando sem erros em AES-256-GCM.
  2. Teste de corrupção intencional de bytes comprovando a rejeição pelo GCM.
  3. Utilização estrita de vetores de inicialização de alta entropia sem repetição.

Projeto 05: Criptografia Assimétrica: RSA e Diffie-Hellman 🔑

Escopo do Projeto

Objetivo: Implementar esquemas de chave pública: geração de pares de chaves RSA de 4096 bits em formato PEM, cifragem híbrida e o algoritmo de troca de chaves Diffie-Hellman sobre Curvas Elípticas (ECDH).

🎯 1. Contexto & Desafio Prático

A distribuição segura de chaves é o maior desafio em canais abertos da Internet. Você construirá uma aplicação de mensagens seguras ponto a ponto (P2P) que utiliza troca de chaves Diffie-Hellman efêmera para derivar uma chave simétrica de sessão compartilhada sem nunca trafegar a chave pela rede.

📋 2. Requisitos Técnicos Obrigatórios

  • R1 (Geração de Chaves RSA e PEM): Gerar pares de chaves RSA de 4096 bits protegidas por passphrase e salvas nos formatos private_key.pem e public_key.pem.
  • R2 (Troca de Chaves ECDH): Implementar a negociação de segredo compartilhado utilizando a curva X25519 com a biblioteca cryptography.
  • R3 (Derivação de Chave de Sessão - HKDF): Aplicar a função de derivação de chaves baseada em HMAC (HKDF) sobre o segredo para gerar a chave simétrica de aplicação.
  • R4 (Cifragem Híbrida): Cifrar o payload de mensagem com AES-GCM utilizando a chave derivada da troca assimétrica.

📐 3. Diagrama Conceitual & Arquitetura

sequenceDiagram
    autonumber
    participant Alice as Alice (X25519)
    participant Canal as Canal Aberto Inseguro
    participant Bob as Bob (X25519)
    Alice->>Bob: Alice Envia Chave Pública Pública_A
    Bob->>Alice: Bob Envia Chave Pública Pública_B
    Note over Alice: Calcula Segredo: S = Priv_A * Pub_B
    Note over Bob: Calcula Segredo: S = Priv_B * Pub_A
    Note over Alice,Bob: Segredo Compartilhado S é Idêntico em Ambos!
    Alice->>Alice: Deriva Chave de Sessão via HKDF
    Alice->>Canal: Mensagem Cifrada com AES-GCM (Chave Derivada)
    Canal->>Bob: Entrega Mensagem Cifrada
    Bob->>Bob: Decifra Mensagem com Garantia Matemática!

💻 4. Especificação Técnica & Código de Referência

// ecdh_key_exchange.py
from cryptography.hazmat.primitives.asymmetric import x25519
from cryptography.hazmat.primitives.kdf.hkdf import HKDF
from cryptography.hazmat.primitives import hashes

# 1. Cada participante gera seu par de chaves efêmero
alice_priv = x25519.X25519PrivateKey.generate()
alice_pub = alice_priv.public_key()

bob_priv = x25519.X25519PrivateKey.generate()
bob_pub = bob_priv.public_key()

# 2. Troca de chaves e cálculo do segredo compartilhado
alice_shared = alice_priv.exchange(bob_pub)
bob_shared = bob_priv.exchange(alice_pub)
assert alice_shared == bob_shared

# 3. Derivação de Chave Simétrica (HKDF)
hkdf = HKDF(algorithm=hashes.SHA256(), length=32, salt=None, info=b"p2p-session-key")
session_key = hkdf.derive(alice_shared)
print(f"Chave de Sessão de 256 bits derivada com sucesso: {session_key.hex()[:16]}...")

📦 5. Critérios de Avaliação e Entrega

  1. Demonstração da troca ECDH sem vazamento de chaves privadas.
  2. Derivação determinística de chaves simétricas com HKDF.
  3. Cifragem e decifragem de mensagens entre as duas partes virtuais.

Projeto 06: Funções de Hash Criptográfico, HMAC e Integridade #️⃣

Escopo do Projeto

Objetivo: Dominar a integridade criptográfica com funções de hash (SHA-256, SHA-3), demonstrando o Efeito Avalanche, prevenção de ataques de extensão de comprimento e autenticação de mensagens com HMAC.

🎯 1. Contexto & Desafio Prático

Arquivos de atualização de firmware e transações bancárias dependem de hashes para garantir que nem um único bit foi corrompido em trânsito. Você construirá uma ferramenta de validação de integridade de software que calcula hashes, gera assinaturas HMAC com chave secreta e audita manifestos de verificação.

📋 2. Requisitos Técnicos Obrigatórios

  • R1 (Demonstração do Efeito Avalanche): Comprovar matematicamente que a alteração de um único bit no arquivo de entrada altera mais de 50% dos bits do hash SHA-256 final.
  • R2 (Implementação de HMAC-SHA256): Construir função de assinatura e validação de autenticidade de mensagens via HMAC, explicando por que hash(key + msg) é vulnerável a ataques de extensão de comprimento.
  • R3 (Comparação em Tempo Constante): Utilizar hmac.compare_digest para evitar ataques de temporização (Timing Attacks) na checagem de hashes.
  • R4 (Verificador de Checksum de Arquivos): Construir script que gera e audita arquivos SHA256SUMS padrão Linux.

📐 3. Diagrama Conceitual & Arquitetura

graph LR
    Message["Payload da Transação Financeira"] --> HMACEngine["HMAC-SHA256 Engine"]
    SecretKey["Chave Secreta Compartilhada"] --> HMACEngine
    HMACEngine --> Digest["Código de Autenticação (MAC 256 bits)"]
    Digest --> ConstantTime["hmac.compare_digest() (Tempo Constante)"]
    ConstantTime --> Valid["Autenticidade e Integridade Confirmadas!"]
    style Message fill:#e1f5fe,stroke:#01579b
    style SecretKey fill:#fff3e0,stroke:#e65100
    style HMACEngine fill:#f3e5f5,stroke:#7b1fa2
    style Valid fill:#e8f5e9,stroke:#2e7d32

💻 4. Especificação Técnica & Código de Referência

// hmac_integrity.py
import hmac
import hashlib

def generate_message_auth_code(secret_key: bytes, message: bytes) -> str:
    """Gera HMAC-SHA256 com garantia contra Length Extension Attacks."""
    return hmac.new(secret_key, message, hashlib.sha256).hexdigest()

def verify_message_integrity(secret_key: bytes, message: bytes, received_hmac: str) -> bool:
    expected_hmac = generate_message_auth_code(secret_key, message)
    # Comparação estritamente em tempo constante para anular Timing Attacks!
    return hmac.compare_digest(expected_hmac, received_hmac)

if __name__ == '__main__':
    key = b"chave-secreta-corporativa-super-segura"
    msg = b"TRANSFERIR 5000.00 BRL PARA CONTA 9841"
    tag = generate_message_auth_code(key, msg)
    print(f"HMAC Gerado: {tag}")
    print(f"Verificação de Integridade: {verify_message_integrity(key, msg, tag)}")

📦 5. Critérios de Avaliação e Entrega

  1. Demonstração numérica do Efeito Avalanche no relatório.
  2. Uso estrito de hmac.compare_digest na verificação.
  3. Script gerador e auditor de manifestos SHA256SUMS funcional.

Projeto 07: Infraestrutura de Chaves Públicas (PKI) e Certificados X.509 📜

Escopo do Projeto

Objetivo: Criar uma Autoridade Certificadora (CA) raiz privada com OpenSSL e Python, emitir Certificados Digitais X.509 para servidores e clientes, e implementar a validação da cadeia de confiança e revogação de certificados.

🎯 1. Contexto & Desafio Prático

A segurança da web baseia-se na confiança hierárquica de certificados digitais. Você construirá uma Infraestrutura de Chaves Públicas (PKI) corporativa completa, gerando a CA raiz autoassinada, criando solicitações de assinatura de certificado (CSR), assinando certificados de servidores web e validando a cadeia criptográfica de ponta a ponta.

📋 2. Requisitos Técnicos Obrigatórios

  • R1 (Criação de CA Raiz Privada): Gerar par de chaves RSA 4096 e certificado X.509 autoassinado com extensões basicConstraints=CA:TRUE.
  • R2 (Geração de CSR): Gerar Certificate Signing Request (CSR) para o domínio portal.interno.empresa com Subject Alternative Name (SAN).
  • R3 (Assinatura e Emissão): Assinar o certificado do servidor utilizando a CA raiz com validade de 365 dias e extensões de uso de chave.
  • R4 (Validação da Cadeia com OpenSSL): Verificar o certificado emitido com o comando openssl verify -CAfile ca.crt server.crt confirmando status OK.

📐 3. Diagrama Conceitual & Arquitetura

graph TD
    RootCA["Autoridade Certificadora Raiz Privada (Root CA: ca.crt)"] --> Sign["Assinatura Criptográfica X.509"]
    CSR["Certificate Signing Request (CSR do Servidor Web)"] --> Sign
    Sign --> ServerCert["Certificado do Servidor (server.crt com SAN)"]
    ServerCert --> Browser["Validador TLS: Confirma Cadeia até a Root CA"]
    style RootCA fill:#e1f5fe,stroke:#01579b
    style CSR fill:#fff3e0,stroke:#e65100
    style Sign fill:#f3e5f5,stroke:#7b1fa2
    style ServerCert fill:#e8f5e9,stroke:#2e7d32
    style Browser fill:#e0f2f1,stroke:#00695c

💻 4. Especificação Técnica & Código de Referência

// pki_setup.sh
#!/usr/bin/env bash
set -euo pipefail

# 1. Gerar chave privada e certificado da Root CA
openssl req -x509 -new -nodes -keyout ca.key -sha256 -days 1825 -out ca.crt \
  -subj "/C=BR/ST=SP/O=Empresa Corp/CN=Empresa Root CA"

# 2. Gerar chave privada e CSR do servidor
openssl req -new -nodes -keyout server.key -out server.csr \
  -subj "/C=BR/ST=SP/O=Empresa Corp/CN=portal.interno.empresa"

# 3. Assinar o certificado do servidor com a CA raiz
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -out server.crt -days 365 -sha256

# 4. Validar cadeia de confiança
openssl verify -CAfile ca.crt server.crt

📦 5. Critérios de Avaliação e Entrega

  1. Arquivos ca.crt, server.crt e chaves gerados com sucesso.
  2. Validação com openssl verify retornando OK.
  3. Presença de extensões básicas de autoridade certificadora no certificado raiz.

Projeto 08: Autenticação Multifator (MFA) e TOTP RFC 6238 📱

Escopo do Projeto

Objetivo: Desenvolver um subsistema completo de Autenticação Multifator (MFA) implementando o algoritmo Time-Based One-Time Password (TOTP - RFC 6238) em Python, integrando com geradores QR Code para aplicativos como Google Authenticator.

🎯 1. Contexto & Desafio Prático

Senhas estáticas são insuficientes para conter credenciais vazadas em ataques de phishing e credential stuffing. Você construirá um módulo de segurança MFA que gera segredos Base32 compartilhados, emite URLs otpauth:// legíveis por apps de autenticação e valida tokens dinâmicos de 6 dígitos com janela de tolerância de tempo.

📋 2. Requisitos Técnicos Obrigatórios

  • R1 (Algoritmo TOTP RFC 6238): Implementar a computação matemática do token: extração do contador de tempo (30s) e hash HMAC-SHA1 com truncamento dinâmico.
  • R2 (Geração de QR Code de Pareamento): Gerar URI padronizada otpauth://totp/Empresa:usuario@empresa.com?secret=...&issuer=Empresa para leitura por smartphone.
  • R3 (Janela de Deriva de Relógio / Drift): Aceitar tokens da janela de tempo corrente (\(T_0\)) e adjacentes (\(T_{-1}\) e \(T_{+1}\)) para acomodar pequenas diferenças de relógio no celular.
  • R4 (Prevenção de Ataques de Replay): Impedir que um mesmo token de 6 dígitos seja reutilizado duas vezes dentro da mesma janela de 30 segundos.

📐 3. Diagrama Conceitual & Arquitetura

sequenceDiagram
    autonumber
    participant Server as Servidor de Autenticação
    participant App as App Authenticator (Celular)
    participant User as Usuário
    Server->>User: Exibe QR Code com Segredo Base32 (otpauth://)
    User->>App: Escaneia QR Code
    Note over App,Server: Relógios Sincronizados em Janelas de 30 Segundos
    App->>User: Exibe Token Rotativo de 6 Dígitos (ex: 492105)
    User->>Server: Submete Senha + Token 492105
    Server->>Server: Calcula HMAC-SHA1 local e valida janela [-1, 0, +1]
    Server-->>User: Autenticação Aprovada com MFA!

💻 4. Especificação Técnica & Código de Referência

// totp_mfa_engine.py
import hmac
import hashlib
import time
import struct
import base64

def generate_totp_token(secret_base32: str, interval: int = 30) -> str:
    """Implementação pura do algoritmo TOTP (RFC 6238 / RFC 4226)."""
    key = base64.b32decode(secret_base32, casefold=True)
    # Contador de passos de tempo em 8 bytes (Big-Endian)
    counter = int(time.time() // interval)
    counter_bytes = struct.pack(">Q", counter)

    # HMAC-SHA1
    mac = hmac.new(key, counter_bytes, hashlib.sha1).digest()

    # Truncamento Dinâmico (Dynamic Truncation)
    offset = mac[-1] & 0x0F
    binary = struct.unpack(">I", mac[offset:offset + 4])[0] & 0x7FFFFFFF

    token = binary % 1_000_000
    return f"{token:06d}"

if __name__ == '__main__':
    secret = "JBSWY3DPEHPK3PXP" # Segredo Base32 de teste
    token_atual = generate_totp_token(secret)
    print(f"Token TOTP de 6 dígitos gerado: {token_atual} (Válido por 30s)")

📦 5. Critérios de Avaliação e Entrega

  1. Geração de tokens de 6 dígitos compatível com Google Authenticator.
  2. Validação com tolerância a desvios de relógio de +/- 30 segundos.
  3. Armazenamento de segredos em Base32 padronizado.

Projeto 09: Inspeção e Hardening de Conexões TLS 1.3 🌐

Escopo do Projeto

Objetivo: Projetar e validar um túnel de comunicação seguro baseado no protocolo TLS 1.3, implementando Perfect Forward Secrecy (PFS), cipher suites modernos e Mutual TLS (mTLS).

🎯 1. Contexto & Desafio Prático

A proteção de dados em trânsito é o pilar central das comunicações modernas na Internet. Neste projeto, você configurará e inspecionará uma terminação TLS 1.3 de alta segurança para microsserviços, eliminando cifras legadas suscetíveis a ataques conhecidos (BEAST, POODLE, ROBOT) e garantindo autenticação mútua rigorosa entre clientes corporativos e o backend.

📋 2. Requisitos Técnicos Obrigatórios

  • R1 (Aperto de Mão TLS 1.3 - Handshake 1-RTT): Mapear o fluxo de handshake TLS 1.3 demonstrando a redução de latência para 1-RTT e a remoção de negociações inseguras em texto plano.
  • R2 (Hardening de Cipher Suites): Restringir estritamente as cifras permitidas a TLS_AES_256_GCM_SHA384 e TLS_CHACHA20_POLY1305_SHA256, desabilitando TLS 1.0, 1.1 e 1.2.
  • R3 (Autenticação Mútua - mTLS): Configurar validação bidirecional onde tanto o cliente quanto o servidor validam seus respectivos certificados emitidos por uma autoridade certificadora (CA) raiz interna.
  • R4 (Headers de Proteção de Rede): Configurar cabeçalhos HSTS (Strict-Transport-Security) com max-age de 1 ano e diretivas includeSubDomains e preload.

📐 3. Diagrama Conceitual & Arquitetura

sequenceDiagram
    autonumber
    participant Client as Cliente mTLS
    participant Server as Gateway TLS 1.3
    Client->>Server: ClientHello (Supported Groups, Key Share ECDHE, Cipher Suites)
    Server-->>Client: ServerHello (Key Share) + EncryptedExtensions + Certificate Request
    Server-->>Client: Certificate + CertificateVerify + Finished
    Note over Client,Server: Chave de Sessão Efêmera Derivada (PFS)
    Client->>Server: Certificate (Cliente) + CertificateVerify + Finished
    Note over Client,Server: Canal Cifrado Estabelecido em 1-RTT
    Client->>Server: Requisição HTTP/2 Segura (mTLS Validado)
    Server-->>Client: Resposta Protegida (HSTS Ativo)

💻 4. Especificação Técnica & Código de Referência

// tls_hardened_context.py
import ssl
import socket

def create_hardened_ssl_context(ca_cert_path: str, server_cert_path: str, server_key_path: str) -> ssl.SSLContext:
    """Cria um contexto TLS 1.3 ultrasseguro com suporte a mTLS e cifras modernas."""
    context = ssl.create_default_context(ssl.Purpose.CLIENT_AUTH)

    # Impor estritamente TLS 1.3
    context.minimum_version = ssl.TLSVersion.TLSv1_3
    context.maximum_version = ssl.TLSVersion.TLSv1_3

    # Cipher suites modernas recomendadas pelo NIST
    context.set_ciphers('TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256')

    # Exigir autenticação mútua do cliente (mTLS)
    context.verify_mode = ssl.CERT_REQUIRED
    context.load_verify_locations(cafile=ca_cert_path)

    # Carregar certificado e chave privada do servidor
    context.load_cert_chain(certfile=server_cert_path, keyfile=server_key_path)

    # Opções adicionais de hardening contra side-channel
    context.options |= ssl.OP_NO_COMPRESSION
    context.options |= ssl.OP_CIPHER_SERVER_PREFERENCE
    return context

if __name__ == '__main__':
    print("Módulo de contexto TLS 1.3 de alta segurança inicializado com sucesso.")

📦 5. Critérios de Avaliação e Entrega

  1. Handshake TLS 1.3 e eliminação de cifras legadas devidamente especificados.
  2. Configuração de autenticação mútua (mTLS) com validação de CA interna.
  3. Inclusão de políticas de cabeçalhos HSTS para mitigação de downgrade.

Projeto 10: Cofre de Segredos e Envelope Encryption em Python 🐍

Escopo do Projeto

Objetivo: Construir um módulo em Python para gerenciamento de dados confidenciais em repouso empregando a arquitetura de Criptografia em Envelope (Envelope Encryption) com AES-256-GCM.

🎯 1. Contexto & Desafio Prático

Em plataformas de nuvem e sistemas de alta escala, criptografar grandes volumes de dados diretamente com uma chave mestra (KEK) gera gargalos e riscos catastróficos em caso de comprometimento da chave. Você implementará o padrão industrial de Envelope Encryption, gerando chaves de dados efêmeras (DEK) para cada registro e encapsulando-as com uma chave mestra de alta segurança.

📋 2. Requisitos Técnicos Obrigatórios

  • R1 (Geração de Chaves de Dados - DEK): Implementar a geração segura de chaves efêmeras de 256 bits com secrets.token_bytes(32) para cada operação de escrita.
  • R2 (Cifragem de Dados com AES-GCM): Cifrar a carga útil de dados usando AES-256-GCM com IV único de 96 bits gerado pelo sistema operacional e coletar a tag de autenticação.
  • R3 (Encapsulamento da DEK com KEK Mestra): Cifrar a DEK efêmera utilizando a chave mestra de criptografia (Key Encryption Key) protegida em memória.
  • R4 (Decifragem e Validação de Adulteração): Construir a rotina inversa que decifra a DEK, valida a tag de autenticação dos dados e rejeita imediatamente payloads violados.

📐 3. Diagrama Conceitual & Arquitetura

graph TD
    Data["Dados do Usuário (Plaintext)"] -->|Cifra AES-256-GCM| EncData["Ciphertext dos Dados"]
    DEK["Chave de Dados Efêmera (DEK - 256 bits)"] -->|Cifra o Dado| EncData
    DEK -->|Cifrada pela KEK| EncDEK["DEK Envelopada (Cifrada)"]
    KEK["Chave Mestra (KEK - Armazenada em Vault/HSM)"] -->|Protege a DEK| EncDEK
    EncData --> Envelope["Envelope Final (Payload JSON com IV, Tag, DEK Cifrada e Dados)"]
    EncDEK --> Envelope
    style Data fill:#e1f5fe,stroke:#01579b
    style DEK fill:#fff3e0,stroke:#e65100
    style KEK fill:#f3e5f5,stroke:#7b1fa2
    style Envelope fill:#e8f5e9,stroke:#2e7d32

💻 4. Especificação Técnica & Código de Referência

// envelope_vault.py
import os
import json
import base64
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

class EnvelopeVault:
    def __init__(self, master_kek: bytes):
        if len(master_kek) != 32:
            raise ValueError("A KEK mestra deve possuir exatamente 256 bits (32 bytes).")
        self.kek_cipher = AESGCM(master_kek)

    def encrypt_envelope(self, plaintext: bytes) -> str:
        # 1. Gerar DEK efêmera de 256 bits
        dek = os.urandom(32)

        # 2. Cifrar o dado com a DEK via AES-GCM
        data_nonce = os.urandom(12)
        data_cipher = AESGCM(dek)
        ciphertext = data_cipher.encrypt(data_nonce, plaintext, None)

        # 3. Cifrar a DEK com a KEK mestra
        kek_nonce = os.urandom(12)
        encrypted_dek = self.kek_cipher.encrypt(kek_nonce, dek, None)

        # 4. Montar o envelope estruturado
        envelope = {
            "kek_nonce": base64.b64encode(kek_nonce).decode('utf-8'),
            "encrypted_dek": base64.b64encode(encrypted_dek).decode('utf-8'),
            "data_nonce": base64.b64encode(data_nonce).decode('utf-8'),
            "ciphertext": base64.b64encode(ciphertext).decode('utf-8')
        }
        return json.dumps(envelope)

    def decrypt_envelope(self, envelope_json: str) -> bytes:
        data = json.loads(envelope_json)
        kek_nonce = base64.b64decode(data["kek_nonce"])
        encrypted_dek = base64.b64decode(data["encrypted_dek"])
        data_nonce = base64.b64decode(data["data_nonce"])
        ciphertext = base64.b64decode(data["ciphertext"])

        # Recuperar a DEK original decifrando com a KEK
        dek = self.kek_cipher.decrypt(kek_nonce, encrypted_dek, None)

        # Decifrar os dados confidenciais
        data_cipher = AESGCM(dek)
        return data_cipher.decrypt(data_nonce, ciphertext, None)

if __name__ == '__main__':
    master_key = os.urandom(32)
    vault = EnvelopeVault(master_key)
    msg = b"Dados Confidenciais de Pagamento: Cartao 4532-XXXX-XXXX-8910"
    pack = vault.encrypt_envelope(msg)
    recovered = vault.decrypt_envelope(pack)
    assert recovered == msg
    print("Envelope Encryption validado com sucesso. Dados decifrados com integridade!")

📦 5. Critérios de Avaliação e Entrega

  1. Arquitetura de duas camadas com separação clara de DEK efêmera e KEK mestra.
  2. Uso estrito de cifras autenticadas (AES-256-GCM) sem reuso de IVs.
  3. Payload serializado em JSON com campos codificados em Base64 e validação de tampering.

Projeto 11: Criptografia End-to-End no Navegador com Web Crypto API 💻

Escopo do Projeto

Objetivo: Desenvolver uma biblioteca de criptografia ponta a ponta (E2EE) em JavaScript cliente utilizando a Web Crypto API nativa do navegador (window.crypto.subtle).

🎯 1. Contexto & Desafio Prático

Aplicações de mensagens seguras e registros médicos exigem que os dados cheguem aos servidores já cifrados, garantindo que mesmo um banco de dados totalmente invadido revele apenas ruído criptográfico aos atacantes (Zero-Knowledge). Você construirá o módulo de criptografia cliente derivando chaves com PBKDF2 e cifrando mensagens via AES-GCM.

📋 2. Requisitos Técnicos Obrigatórios

  • R1 (Derivação Segura via PBKDF2): Derivar uma chave criptográfica simétrica a partir da senha do usuário e salt de 16 bytes utilizando PBKDF2 com HMAC-SHA-256 e no mínimo 100.000 iterações.
  • R2 (Cifragem AES-GCM Assíncrona): Implementar a cifragem de strings UTF-8 usando subtle.encrypt com AES-GCM e vetor de inicialização criptográfico de 96 bits (crypto.getRandomValues).
  • R3 (Decifragem com Validação de Integridade): Implementar a função de decifragem que captura automaticamente falhas de integridade (OperationError) caso os dados cifrados sofram adulteração no canal.
  • R4 (Compatibilidade com Padrões Web): Formatar os dados cifrados em formato portátil Base64 para envio transparente via requisições REST JSON ou WebSockets.

📐 3. Diagrama Conceitual & Arquitetura

sequenceDiagram
    autonumber
    participant Alice as Navegador Alice (Cliente A)
    participant Server as Servidor Relé (Não Confiável)
    participant Bob as Navegador Bob (Cliente B)
    Note over Alice: 1. Derivação de Chave (PBKDF2)<br/>2. Cifragem AES-GCM (Web Crypto)
    Alice->>Server: Envia Payload Cifrado {iv, salt, ciphertext} (Zero-Knowledge)
    Note over Server: Servidor armazena e repassa sem ler o conteúdo
    Server->>Bob: Entrega Payload Cifrado
    Note over Bob: 1. Deriva Mesma Chave Compartilhada<br/>2. Decifragem Autenticada via subtle.decrypt
    Bob-->>Bob: Mensagem Original Restaurada em Texto Claro!

💻 4. Especificação Técnica & Código de Referência

// e2ee_client.js
// Implementação E2EE utilizando a Web Crypto API nativa
async function deriveKeyFromPassword(password, salt) {
  const enc = new TextEncoder();
  const baseKey = await window.crypto.subtle.importKey(
    "raw", enc.encode(password), { name: "PBKDF2" }, false, ["deriveKey"]
  );
  return window.crypto.subtle.deriveKey(
    {
      name: "PBKDF2",
      salt: salt,
      iterations: 100000,
      hash: "SHA-256"
    },
    baseKey,
    { name: "AES-GCM", length: 256 },
    false,
    ["encrypt", "decrypt"]
  );
}

async function encryptMessage(password, plainText) {
  const salt = window.crypto.getRandomValues(new Uint8Array(16));
  const iv = window.crypto.getRandomValues(new Uint8Array(12));
  const key = await deriveKeyFromPassword(password, salt);

  const enc = new TextEncoder();
  const cipherBuffer = await window.crypto.subtle.encrypt(
    { name: "AES-GCM", iv: iv },
    key,
    enc.encode(plainText)
  );

  return {
    salt: btoa(String.fromCharCode(...salt)),
    iv: btoa(String.fromCharCode(...iv)),
    ciphertext: btoa(String.fromCharCode(...new Uint8Array(cipherBuffer)))
  };
}

async function decryptMessage(password, envelope) {
  const salt = Uint8Array.from(atob(envelope.salt), c => c.charCodeAt(0));
  const iv = Uint8Array.from(atob(envelope.iv), c => c.charCodeAt(0));
  const cipherData = Uint8Array.from(atob(envelope.ciphertext), c => c.charCodeAt(0));

  const key = await deriveKeyFromPassword(password, salt);
  const decryptedBuffer = await window.crypto.subtle.decrypt(
    { name: "AES-GCM", iv: iv },
    key,
    cipherData
  );
  return new TextDecoder().decode(decryptedBuffer);
}

📦 5. Critérios de Avaliação e Entrega

  1. Utilização integral das primitivas criptográficas da Web Crypto API moderna.
  2. Derivação de chaves resistente a ataques de força bruta com PBKDF2 e 100.000 iterações.
  3. Geração correta de vetores de inicialização com crypto.getRandomValues.

Projeto 12: Defesa Ativa e Mitigação contra OWASP Top 10 🕸️

Escopo do Projeto

Objetivo: Conceber uma camada de middleware de proteção para APIs Web mitigando as principais falhas do OWASP Top 10, com foco em Injeção (SQLi), Cross-Site Scripting (XSS) e Quebra de Controle de Acesso (BOLA).

🎯 1. Contexto & Desafio Prático

A vulnerabilidade em código web é o vetor de ataque mais explorado por agentes maliciosos para roubo de dados corporativos. Neste projeto, você desenvolverá filtros defensivos e middlewares de sanitização que interceptam requisições HTTP maliciosas, aplicam cabeçalhos de segurança rígidos e blindam endpoints de API contra invasões comuns.

📋 2. Requisitos Técnicos Obrigatórios

  • R1 (Prevenção de Injeções via Queries Parametrizadas): Implementar validação estrita de tipos e garantir o uso obrigatório de Prepared Statements no acesso ao banco de dados.
  • R2 (Mitigação de XSS e Cabeçalhos de Segurança): Injetar automaticamente cabeçalhos defensivos: Content-Security-Policy (CSP), X-Content-Type-Options: nosniff e cookies HttpOnly; Secure; SameSite=Strict.
  • R3 (Validação de Propriedade contra BOLA/IDOR): Construir checagem de autorização em nível de objeto onde o identificador do usuário autenticado no token deve bater com o proprietário do registro.
  • R4 (Rate Limiting e Defesa contra Força Bruta): Implementar limitador de requisições baseado em endereço IP e identificador de usuário para frustrar ataques de enumeração.

📐 3. Diagrama Conceitual & Arquitetura

graph TD
    Req["Requisição HTTP Entrante"] --> WAF["Security Interceptor Middleware"]
    WAF --> Check1{"Headers & Rate Limit OK?"}
    Check1 -- Não --> Drop429["HTTP 429 Too Many Requests"]
    Check1 -- Sim --> Check2{"Parâmetros Sanitizados (Anti-SQLi / XSS)?"}
    Check2 -- Não --> Drop400["HTTP 400 Bad Request & Log de Ataque"]
    Check2 -- Sim --> Check3{"Autorização no Objeto (Anti-BOLA)?"}
    Check3 -- Não --> Drop403["HTTP 403 Forbidden"]
    Check3 -- Sim --> Controller["Execução do Endpoint com Cabeçalhos de Proteção"]
    style Req fill:#e1f5fe,stroke:#01579b
    style WAF fill:#fff3e0,stroke:#e65100
    style Controller fill:#e8f5e9,stroke:#2e7d32
    style Drop429 fill:#ffebee,stroke:#c62828
    style Drop400 fill:#ffebee,stroke:#c62828
    style Drop403 fill:#ffebee,stroke:#c62828

💻 4. Especificação Técnica & Código de Referência

// security_defense_middleware.py
import re
import html
from typing import Dict, Any

class SecurityDefenseMiddleware:
    def __init__(self):
        # Padrões suspeitos de SQL Injection clássica
        self.sqli_pattern = re.compile(r"(--|union|select|drop|insert|delete|where.*=)", re.IGNORECASE)

    def sanitize_input(self, value: str) -> str:
        """Sanitiza entradas contra Cross-Site Scripting (XSS)."""
        if not isinstance(value, str):
            return value
        # Escapa caracteres especiais HTML (&, <, >, ", ')
        return html.escape(value.strip())

    def validate_no_sqli(self, value: str) -> bool:
        """Detecta tentativas óbvias de injeção em parâmetros raw."""
        if isinstance(value, str) and self.sqli_pattern.search(value):
            return False
        return True

    def apply_security_headers(self, headers: Dict[str, str]) -> Dict[str, str]:
        """Injeta cabeçalhos recomendados pelo OWASP Secure Headers Project."""
        headers["Content-Security-Policy"] = "default-src 'self'; script-src 'self'; object-src 'none';"
        headers["X-Content-Type-Options"] = "nosniff"
        headers["X-Frame-Options"] = "DENY"
        headers["Strict-Transport-Security"] = "max-age=31536000; includeSubDomains"
        headers["Referrer-Policy"] = "no-referrer-when-downgrade"
        return headers

if __name__ == '__main__':
    defense = SecurityDefenseMiddleware()
    malicious = "<script>alert('pwned')</script>"
    clean = defense.sanitize_input(malicious)
    print(f"Entrada higienizada: {clean}")
    assert "<script>" not in clean
    print("Middleware de defesa ativa OWASP validado.")

📦 5. Critérios de Avaliação e Entrega

  1. Camada defensiva cobrindo os vetores do OWASP Top 10 mais comuns.
  2. Sanitização e escape explícito contra XSS refletido e persistente.
  3. Injeção consistente de cabeçalhos HTTP defensivos (CSP, HSTS, X-Frame-Options).

Projeto 13: Gestão e Armazenamento Seguro de Senhas com Argon2id 🗝️

Escopo do Projeto

Objetivo: Desenvolver um subsistema completo para armazenamento de credenciais de usuários utilizando a função de derivação de chaves com memória rígida Argon2id (vencedora do Password Hashing Competition e padrão RFC 9106).

🎯 1. Contexto & Desafio Prático

Algoritmos clássicos de hash como MD5 e SHA-1 são completamente inadequados para armazenamento de senhas, e até mesmo SHA-256 é vulnerável a ataques massivos de quebra por GPU. Você projetará uma biblioteca de armazenamento de senhas de última geração configurando custo de memória, tempo e paralelismo com Argon2id, incluindo suporte a rehash transparente.

📋 2. Requisitos Técnicos Obrigatórios

  • R1 (Configuração dos Parâmetros de Custo): Configurar Argon2id com custo de memória de 64 MB (65536 KiB), tempo de 3 iterações e paralelismo de 4 threads, respeitando as recomendações oficiais da OWASP.
  • R2 (Geração e Incorporação de Salt Criptográfico): Gerar salt criptograficamente aleatório de 16 bytes para cada credencial gerada, impedindo ataques via Rainbow Tables.
  • R3 (Verificação em Tempo Constante): Realizar a conferência de hashes prevenindo ataques de temporização (Timing Attacks) por meio de comparação segura de bytes.
  • R4 (Mecanismo de Upgrade e Rehash Automático): Identificar no momento do login quando uma senha foi cifrada com algoritmo legado ou parâmetros obsoletos e reexecutar o hash de forma transparente.

📐 3. Diagrama Conceitual & Arquitetura

flowchart TD
    Login["Tentativa de Login (Usuário e Senha)"] --> Fetch["Buscar Registro do Usuário no DB"]
    Fetch --> Verify{"Verificação Argon2id em Tempo Constante"}
    Verify -- Inválida --> Reject["Rejeitar com HTTP 401 (Atraso Constante)"]
    Verify -- Válida --> CheckCost{"Parâmetros de Custo Atualizados?"}
    CheckCost -- Sim --> Success["Gerar Sessão / JWT Seguro"]
    CheckCost -- Não (Hash Legado) --> Rehash["Gerar Novo Hash Argon2id Atualizado"]
    Rehash --> SaveDB["Atualizar Registro no Banco sem Pedir Troca ao Usuário"]
    SaveDB --> Success
    style Login fill:#e1f5fe,stroke:#01579b
    style Verify fill:#fff3e0,stroke:#e65100
    style Success fill:#e8f5e9,stroke:#2e7d32
    style Reject fill:#ffebee,stroke:#c62828

💻 4. Especificação Técnica & Código de Referência

// argon2_password_manager.py
import secrets
import hashlib
import hmac

class MockArgon2idManager:
    """Simulação educacional da mecânica de salt + memória/tempo do Argon2id (RFC 9106)."""
    def __init__(self, memory_cost_kib: int = 65536, time_cost: int = 3, parallelism: int = 4):
        self.memory_cost = memory_cost_kib
        self.time_cost = time_cost
        self.parallelism = parallelism

    def hash_password(self, password: str) -> str:
        # Salt criptográfico de 128 bits
        salt = secrets.token_bytes(16)

        # Derivação simulada aplicando múltiplas rodadas dependentes
        current = hashlib.sha256(salt + password.encode('utf-8')).digest()
        for _ in range(self.time_cost * 1000):
            current = hashlib.sha256(current + salt).digest()

        salt_hex = salt.hex()
        hash_hex = current.hex()
        return f"$argon2id$v=19$m={self.memory_cost},t={self.time_cost},p={self.parallelism}${salt_hex}${hash_hex}"

    def verify_password(self, password: str, encoded_hash: str) -> bool:
        parts = encoded_hash.split('$')
        if len(parts) < 6 or parts[1] != 'argon2id':
            return False
        salt_hex = parts[4]
        target_hash = parts[5]

        salt = bytes.fromhex(salt_hex)
        current = hashlib.sha256(salt + password.encode('utf-8')).digest()
        for _ in range(self.time_cost * 1000):
            current = hashlib.sha256(current + salt).digest()

        # Comparação em tempo constante contra Timing Attacks
        return hmac.compare_digest(current.hex(), target_hash)

if __name__ == '__main__':
    pwd_mgr = MockArgon2idManager()
    minha_senha = "SenhaForteCorporativa@2026!"
    hash_gerado = pwd_mgr.hash_password(minha_senha)
    print(f"Hash seguro formatado: {hash_gerado}")
    assert pwd_mgr.verify_password(minha_senha, hash_gerado) is True
    assert pwd_mgr.verify_password("SenhaIncorreta", hash_gerado) is False
    print("Mecanismo de senhas Argon2id validado com sucesso!")

📦 5. Critérios de Avaliação e Entrega

  1. Implementação de parâmetros de custo de memória, iterações e paralelismo.
  2. Geração de salteamento aleatório independente por usuário.
  3. Comparação segura de hashes em tempo constante imune a ataques de temporização.

Projeto 14: Mecanismo de Anonimização, Pseudonimização e Conformidade LGPD 🗂️

Escopo do Projeto

Objetivo: Projetar e codificar um motor de privacidade de dados em conformidade com a LGPD (Lei 13.709/2018) e GDPR, implementando pseudonimização determinística via HMAC, mascaramento dinâmico e o mecanismo de destruição criptográfica (Crypto-Shredding).

🎯 1. Contexto & Desafio Prático

A conformidade com legislações de privacidade exige que sistemas saibam proteger dados de identificação pessoal (PII) mesmo em relatórios analíticos ou logs, e atendam ao direito do titular de ser esquecido sem corromper a integridade referencial dos bancos relacionais. Você criará a infraestrutura de anonimização e o método de destruição de chaves por titular.

📋 2. Requisitos Técnicos Obrigatórios

  • R1 (Pseudonimização Determinística de PII): Gerar identificadores de usuários irreversíveis mas consistentes para reconciliação contábil utilizando HMAC-SHA-256 com chave secreta corporativa.
  • R2 (Mascaramento Dinâmico de Apresentação): Implementar filtros de visualização parcial para CPF (***.123.456-**), cartões de crédito e e-mails (j***@empresa.com.br) conforme o privilégio da sessão do operador.
  • R3 (Mecanismo de Crypto-Shredding para Esquecimento): Estruturar o armazenamento dos dados pessoais cifrados com uma chave individual por titular; ao receber solicitação de exclusão, destruir a chave do titular tornando os dados matematicamente irrecuperáveis.
  • R4 (Livro de Registro de Operações - Trilha de Consentimento): Construir log de auditoria encadeado (Hash Chain) registrando quando o consentimento foi concedido ou revogado.

📐 3. Diagrama Conceitual & Arquitetura

graph LR
    Input["Dado Pessoal (Nome, CPF, E-mail)"] --> Engine["LGPD Privacy Engine"]
    Engine -->|Regra de Exibição| Mask["Dado Mascarado (j***@corp.com)"]
    Engine -->|HMAC com Pepper Secreto| Pseudo["Identificador Pseudonimizado (Hash Imutável)"]
    Engine -->|Chave Individual do Titular K_user| EncData["Payload Cifrado em Repouso"]
    DeleteReq["Pedido de Exclusão (Direito ao Esquecimento)"] --> Shred["Crypto-Shredding: Deletar K_user"]
    Shred -.->|Chave Inexistente: Dado Inutilizado Irreversivelmente| EncData
    style Input fill:#e1f5fe,stroke:#01579b
    style Engine fill:#fff3e0,stroke:#e65100
    style Shred fill:#ffebee,stroke:#c62828
    style Pseudo fill:#e8f5e9,stroke:#2e7d32

💻 4. Especificação Técnica & Código de Referência

// lgpd_privacy_engine.py
import hmac
import hashlib
import re

class LGPDPrivacyEngine:
    def __init__(self, pepper_key: bytes):
        self.pepper_key = pepper_key
        # Repositório de chaves individuais de usuários para Crypto-Shredding
        self.user_keys = {}

    def pseudonymize(self, raw_cpf: str) -> str:
        """Gera um identificador determinístico pseudoanonimizado via HMAC."""
        clean_cpf = re.sub(r"\D", "", raw_cpf)
        return hmac.new(self.pepper_key, clean_cpf.encode('utf-8'), hashlib.sha256).hexdigest()

    def mask_email(self, email: str) -> str:
        """Aplica máscara preservando contexto sem expor a identidade."""
        parts = email.split('@')
        if len(parts) != 2:
            return "***@***"
        user, domain = parts
        masked_user = user[0] + "***" if len(user) > 1 else "*"
        return f"{masked_user}@{domain}"

    def mask_cpf(self, cpf: str) -> str:
        clean = re.sub(r"\D", "", cpf)
        if len(clean) != 11:
            return "***.***.***-**"
        return f"***.{clean[3:6]}.{clean[6:9]}-**"

    def crypto_shred_user(self, user_id: str) -> bool:
        """Executa o direito ao esquecimento destruindo a chave de criptografia do titular."""
        if user_id in self.user_keys:
            del self.user_keys[user_id]
            return True
        return False

if __name__ == '__main__':
    engine = LGPDPrivacyEngine(pepper_key=b'segredo_mestre_lgpd_2026')
    print("Pseudônimo CPF:", engine.pseudonymize("123.456.789-00"))
    print("E-mail mascarado:", engine.mask_email("ricardo@empresa.com.br"))
    print("CPF mascarado:", engine.mask_cpf("123.456.789-00"))

📦 5. Critérios de Avaliação e Entrega

  1. Pseudonimização determinística com HMAC prevenindo correlação direta de dados.
  2. Políticas de mascaramento para diferentes tipos de dados sensíveis.
  3. Conceituação e código demonstrativo do padrão Crypto-Shredding para direito ao esquecimento.

Projeto 15: Pipeline Automatizado de DevSecOps (SAST, DAST e Dependency Check) 🔍

Escopo do Projeto

Objetivo: Conceber e implementar um pipeline de integração contínua focado em segurança de software (DevSecOps), com portas de qualidade (Quality Gates) automáticas bloqueando códigos com vulnerabilidades.

🎯 1. Contexto & Desafio Prático

A segurança integrada no início do ciclo de desenvolvimento (Shift-Left Security) reduz o custo de correção de falhas em até 100 vezes comparado à correção após o incidente em produção. Neste projeto, você criará a especificação de um pipeline de segurança automatizado que executa análise estática (SAST), varredura de dependências conhecidas (SCA) e verificação de segredos expostos.

📋 2. Requisitos Técnicos Obrigatórios

  • R1 (Análise Estática de Código - SAST): Configurar regras para detecção de injeções de código, funções perigosas e uso de algoritmos criptográficos depreciados (ex: MD5, DES).
  • R2 (Verificação de Dependências - SCA): Integrar scanner de vulnerabilidades conhecidas (CVEs) em pacotes externos com avaliação de severidade baseada no escore CVSS v3.
  • R3 (Varredura de Segredos Hardcoded): Implementar checagem automática com detecção de padrões de alta entropia para bloquear commits que exponham tokens JWT, chaves privadas ou senhas de banco.
  • R4 (Security Gate com Bloqueio de Build): Definir regra rígida de automação que interrompe a esteira caso sejam encontradas vulnerabilidades de risco Crítico ou Alto.

📐 3. Diagrama Conceitual & Arquitetura

graph TD
    Code["Push / Pull Request do Desenvolvedor"] --> G1["Secret Detection (Gitleaks / TruffleHog)"]
    G1 --> Pass1{"Segredos Expostos?"}
    Pass1 -- Sim --> FailBuild["Build Quebrado: Bloqueio Imediato & Notificação"]
    Pass1 -- Não --> SAST["SAST: Análise Estática de Código"]
    SAST --> SCA["SCA: Varredura de Dependências (CVEs)"]
    SCA --> EvalGate{"CVSS >= 7.0 (High / Critical)?"}
    EvalGate -- Sim --> FailBuild
    EvalGate -- Não --> PassBuild["Build Aprovado para Ambientes de Teste"]
    style Code fill:#e1f5fe,stroke:#01579b
    style FailBuild fill:#ffebee,stroke:#c62828
    style PassBuild fill:#e8f5e9,stroke:#2e7d32
    style SAST fill:#fff3e0,stroke:#e65100
    style SCA fill:#fff3e0,stroke:#e65100

💻 4. Especificação Técnica & Código de Referência

// .github/workflows/devsecops-pipeline.yml
name: DevSecOps Quality Gate Pipeline

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  security-audit:
    name: Security Vulnerability Scan
    runs-on: ubuntu-latest
    steps:
      - name: Checkout do Repositório
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Varredura de Segredos Hardcoded
        run: |
          echo "Executando análise de vazamento de credenciais..."
          # Simulação de verificação de chaves privadas ou tokens
          ! grep -rE "BEGIN (RSA|EC|OPENSSH) PRIVATE KEY" . --exclude-dir=.git

      - name: Análise Estática de Segurança (SAST)
        run: |
          echo "Executando varredura SAST contra cifras fracas..."
          # Rejeitar uso de MD5 ou SHA1 em novos códigos
          ! grep -rn "hashlib.md5(" src/ || exit 1

      - name: Verificação de Dependências Vulneráveis (SCA)
        run: |
          echo "Consultando base nacional de vulnerabilidades (NVD/CVE)..."
          echo "Quality Gate validado: 0 vulnerabilidades de severidade Alta ou Crítica."

📦 5. Critérios de Avaliação e Entrega

  1. Esteira de segurança contemplando SAST, SCA e detecção de credenciais.
  2. Critérios objetivos de bloqueio de build baseados em severidade CVSS.
  3. Geração de relatórios claros de conformidade antes de qualquer deploy.

Projeto 16: Projeto Capstone: Sistema Completo de Autenticação e Cofre Criptográfico 🎓

Escopo do Projeto

Objetivo: Conceber e desenvolver o sistema unificado de segurança da informação do curso: uma plataforma de autenticação com senhas Argon2id, segundo fator MFA TOTP obrigatório, tokens JWT assinados assimetricamente e cofre de segredos cifrado com AES-256-GCM.

🎯 1. Contexto & Desafio Prático

Este projeto integrador consolida os 15 tópicos estudados na especialização. Você construirá o núcleo de autenticação e proteção de dados de uma aplicação corporativa: desde o onboarding com geração de segredos TOTP, até o armazenamento com hash de alta memória, geração de sessões sem estado com verificação de assinatura digital e armazenamento cifrado de anotações confidenciais do usuário.

📋 2. Requisitos Técnicos Obrigatórios

  • R1 (Ciclo de Cadastro e Senha Segura): Cadastrar credenciais de usuários gerando hashes Argon2id com parâmetros oficiais da OWASP e rejeitando senhas fracas.
  • R2 (Segundo Fator de Autenticação - MFA TOTP): Exigir geração e validação de código numérico de 6 dígitos baseado em HMAC (RFC 6238) antes de conceder a sessão.
  • R3 (Tokens de Acesso JWT com Assinatura Digital): Emitir Access Tokens assinados com algoritmo assimétrico (RS256 ou Ed25519) contendo tempo de expiração curto (15 min) e emissor validado.
  • R4 (Cofre Pessoal Cifrado com AES-256-GCM): Implementar módulo de armazenamento onde cada anotação secreta do usuário é protegida com chave de 256 bits derivada do segredo do usuário, com verificação de integridade.

📐 3. Diagrama Conceitual & Arquitetura

sequenceDiagram
    autonumber
    participant User as Usuário / Cliente
    participant Auth as Auth Server (Argon2id + TOTP)
    participant Vault as Cofre Criptográfico (AES-GCM)
    participant DB as Banco Seguro
    User->>Auth: 1. Login (E-mail + Senha)
    Auth->>DB: Busca Hash Argon2id
    Auth->>Auth: Valida Senha em Tempo Constante
    Auth-->>User: Solicita Desafio MFA TOTP (6 Dígitos)
    User->>Auth: 2. Submete Código TOTP do App Authenticator
    Auth->>Auth: Valida Janela de Tempo TOTP
    Auth-->>User: Retorna JWT Assinado Assimetricamente (RS256)
    User->>Vault: 3. Salvar Segredo (Bearer JWT + Payload)
    Vault->>Vault: Valida Assinatura do JWT
    Vault->>DB: Persiste Dado Cifrado com AES-256-GCM
    Vault-->>User: Confirmação de Gravação Segura!

💻 4. Especificação Técnica & Código de Referência

// secure_capstone_core.py
import os
import time
import secrets
import hmac
import hashlib
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

class SecureCapstoneSystem:
    def __init__(self):
        self.users_db = {}
        self.vault_db = {}

    def register_user(self, username: str, password: str) -> str:
        salt = secrets.token_bytes(16)
        pwd_hash = hashlib.sha256(salt + password.encode('utf-8')).hexdigest()
        totp_secret = secrets.token_hex(16)

        self.users_db[username] = {
            "salt": salt.hex(),
            "hash": pwd_hash,
            "totp_secret": totp_secret
        }
        return totp_secret

    def verify_login(self, username: str, password: str, totp_token: str) -> bool:
        user = self.users_db.get(username)
        if not user:
            return False

        # 1. Validar senha
        salt = bytes.fromhex(user["salt"])
        computed_hash = hashlib.sha256(salt + password.encode('utf-8')).hexdigest()
        if not hmac.compare_digest(computed_hash, user["hash"]):
            return False

        # 2. Validar token MFA (TOTP simplificado de 6 dígitos)
        secret = user["totp_secret"].encode('utf-8')
        timestep = int(time.time() // 30)
        expected_token = f"{int(hashlib.sha256(secret + str(timestep).encode()).hexdigest(), 16) % 1_000_000:06d}"

        return hmac.compare_digest(totp_token, expected_token)

    def store_vault_secret(self, username: str, user_encryption_key: bytes, note_plaintext: bytes):
        aesgcm = AESGCM(user_encryption_key)
        iv = os.urandom(12)
        ciphertext = aesgcm.encrypt(iv, note_plaintext, None)
        self.vault_db[username] = {"iv": iv.hex(), "ciphertext": ciphertext.hex()}
        return True

if __name__ == '__main__':
    capstone = SecureCapstoneSystem()
    totp = capstone.register_user("aluno_seguranca", "MasterKey@2026_Secure")
    print("Usuário registrado com credencial e segredo MFA gerados.")

📦 5. Critérios de Avaliação e Entrega

  1. Arquitetura ponta a ponta com autenticação em múltiplos fatores (Argon2id + TOTP).
  2. Sessões baseadas em tokens assinados digitalmente com curto tempo de vida.
  3. Armazenamento autenticado de dados confidenciais via AES-256-GCM.

Quizzes

🧠 Quizzes de Fixação

Lista completa das 20 unidades de quizzes organizadas em 5 módulos didáticos.

🧠 Quiz 01 – Introdução à Segurança da Informação 🛡️

  1. Qual é o conceito fundamental e objetivo principal de Introdução à Segurança da Informação 🛡️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Introdução à Segurança da Informação 🛡️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Introdução à Segurança da Informação 🛡️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Introdução à Segurança da Informação 🛡️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Introdução à Segurança da Informação 🛡️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Introdução à Segurança da Informação 🛡️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Introdução à Segurança da Informação 🛡️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Introdução à Segurança da Informação 🛡️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Introdução à Segurança da Informação 🛡️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Introdução à Segurança da Informação 🛡️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 02 – Ameaças, Vulnerabilidades e Ataques 🕵️

  1. Qual é o conceito fundamental e objetivo principal de Ameaças, Vulnerabilidades e Ataques 🕵️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Ameaças, Vulnerabilidades e Ataques 🕵️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Ameaças, Vulnerabilidades e Ataques 🕵️, Vulnerabilidades e Ataques 🕵️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Ameaças, Vulnerabilidades e Ataques 🕵️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Ameaças, Vulnerabilidades e Ataques 🕵️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Ameaças, Vulnerabilidades e Ataques 🕵️, Vulnerabilidades e Ataques 🕵️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Ameaças, Vulnerabilidades e Ataques 🕵️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Ameaças, Vulnerabilidades e Ataques 🕵️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Ameaças, Vulnerabilidades e Ataques 🕵️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Ameaças, Vulnerabilidades e Ataques 🕵️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 03 – Fundamentos de Criptografia 🔐

  1. Qual é o conceito fundamental e objetivo principal de Fundamentos de Criptografia 🔐?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Fundamentos de Criptografia 🔐?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Fundamentos de Criptografia 🔐, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Fundamentos de Criptografia 🔐?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Fundamentos de Criptografia 🔐 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Fundamentos de Criptografia 🔐, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Fundamentos de Criptografia 🔐?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Fundamentos de Criptografia 🔐 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Fundamentos de Criptografia 🔐 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Fundamentos de Criptografia 🔐 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 04 – Criptografia Simétrica (AES e DES) 🔑

  1. Qual é o conceito fundamental e objetivo principal de Criptografia Simétrica (AES e DES) 🔑?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Criptografia Simétrica (AES e DES) 🔑?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Criptografia Simétrica (AES e DES) 🔑, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Criptografia Simétrica (AES e DES) 🔑?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Criptografia Simétrica (AES e DES) 🔑 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Criptografia Simétrica (AES e DES) 🔑, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Criptografia Simétrica (AES e DES) 🔑?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Criptografia Simétrica (AES e DES) 🔑 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Criptografia Simétrica (AES e DES) 🔑 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Criptografia Simétrica (AES e DES) 🔑 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 05 – Criptografia Assimétrica (RSA e Diffie-Hellman) 🔓

  1. Qual é o conceito fundamental e objetivo principal de Criptografia Assimétrica (RSA e Diffie-Hellman) 🔓?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Criptografia Assimétrica (RSA e Diffie-Hellman) 🔓?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Criptografia Assimétrica (RSA e Diffie-Hellman) 🔓, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Criptografia Assimétrica (RSA e Diffie-Hellman) 🔓?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Criptografia Assimétrica (RSA e Diffie-Hellman) 🔓 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Criptografia Assimétrica (RSA e Diffie-Hellman) 🔓, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Criptografia Assimétrica (RSA e Diffie-Hellman) 🔓?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Criptografia Assimétrica (RSA e Diffie-Hellman) 🔓 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Criptografia Assimétrica (RSA e Diffie-Hellman) 🔓 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Criptografia Assimétrica (RSA e Diffie-Hellman) 🔓 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 06 – Funções de Hash e Integridade #️⃣

  1. Qual é o conceito fundamental e objetivo principal de Funções de Hash e Integridade #️⃣?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Funções de Hash e Integridade #️⃣?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Funções de Hash e Integridade #️⃣, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Funções de Hash e Integridade #️⃣?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Funções de Hash e Integridade #️⃣ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Funções de Hash e Integridade #️⃣, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Funções de Hash e Integridade #️⃣?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Funções de Hash e Integridade #️⃣ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Funções de Hash e Integridade #️⃣ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Funções de Hash e Integridade #️⃣ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 07 – Assinaturas Digitais e Certificados (PKI) 📜

  1. Qual é o conceito fundamental e objetivo principal de Assinaturas Digitais e Certificados (PKI) 📜?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Assinaturas Digitais e Certificados (PKI) 📜?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Assinaturas Digitais e Certificados (PKI) 📜, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Assinaturas Digitais e Certificados (PKI) 📜?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Assinaturas Digitais e Certificados (PKI) 📜 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Assinaturas Digitais e Certificados (PKI) 📜, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Assinaturas Digitais e Certificados (PKI) 📜?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Assinaturas Digitais e Certificados (PKI) 📜 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Assinaturas Digitais e Certificados (PKI) 📜 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Assinaturas Digitais e Certificados (PKI) 📜 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 08 – Autenticação e Controle de Acesso 🔏

  1. Qual é o conceito fundamental e objetivo principal de Autenticação e Controle de Acesso 🔏?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Autenticação e Controle de Acesso 🔏?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Autenticação e Controle de Acesso 🔏, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Autenticação e Controle de Acesso 🔏?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Autenticação e Controle de Acesso 🔏 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Autenticação e Controle de Acesso 🔏, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Autenticação e Controle de Acesso 🔏?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Autenticação e Controle de Acesso 🔏 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Autenticação e Controle de Acesso 🔏 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Autenticação e Controle de Acesso 🔏 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 09 – TLS/SSL e Segurança em Redes 🌐

  1. Qual é o conceito fundamental e objetivo principal de TLS/SSL e Segurança em Redes 🌐?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de TLS/SSL e Segurança em Redes 🌐?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em TLS/SSL e Segurança em Redes 🌐, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em TLS/SSL e Segurança em Redes 🌐?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de TLS/SSL e Segurança em Redes 🌐 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em TLS/SSL e Segurança em Redes 🌐, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em TLS/SSL e Segurança em Redes 🌐?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a TLS/SSL e Segurança em Redes 🌐 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar TLS/SSL e Segurança em Redes 🌐 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a TLS/SSL e Segurança em Redes 🌐 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 10 – Criptografia na Prática com Python 🐍

  1. Qual é o conceito fundamental e objetivo principal de Criptografia na Prática com Python 🐍?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Criptografia na Prática com Python 🐍?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Criptografia na Prática com Python 🐍, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Criptografia na Prática com Python 🐍?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Criptografia na Prática com Python 🐍 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Criptografia na Prática com Python 🐍, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Criptografia na Prática com Python 🐍?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Criptografia na Prática com Python 🐍 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Criptografia na Prática com Python 🐍 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Criptografia na Prática com Python 🐍 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 11 – Criptografia na Prática com JavaScript 💻

  1. Qual é o conceito fundamental e objetivo principal de Criptografia na Prática com JavaScript 💻?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Criptografia na Prática com JavaScript 💻?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Criptografia na Prática com JavaScript 💻, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Criptografia na Prática com JavaScript 💻?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Criptografia na Prática com JavaScript 💻 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Criptografia na Prática com JavaScript 💻, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Criptografia na Prática com JavaScript 💻?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Criptografia na Prática com JavaScript 💻 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Criptografia na Prática com JavaScript 💻 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Criptografia na Prática com JavaScript 💻 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 12 – Segurança em Aplicações Web (OWASP Top 10) 🕸️

  1. Qual é o conceito fundamental e objetivo principal de Segurança em Aplicações Web (OWASP Top 10) 🕸️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Segurança em Aplicações Web (OWASP Top 10) 🕸️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Segurança em Aplicações Web (OWASP Top 10) 🕸️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Segurança em Aplicações Web (OWASP Top 10) 🕸️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Segurança em Aplicações Web (OWASP Top 10) 🕸️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Segurança em Aplicações Web (OWASP Top 10) 🕸️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Segurança em Aplicações Web (OWASP Top 10) 🕸️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Segurança em Aplicações Web (OWASP Top 10) 🕸️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Segurança em Aplicações Web (OWASP Top 10) 🕸️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Segurança em Aplicações Web (OWASP Top 10) 🕸️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 13 – Gestão e Armazenamento Seguro de Senhas 🗝️

  1. Qual é o conceito fundamental e objetivo principal de Gestão e Armazenamento Seguro de Senhas 🗝️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Gestão e Armazenamento Seguro de Senhas 🗝️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Gestão e Armazenamento Seguro de Senhas 🗝️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Gestão e Armazenamento Seguro de Senhas 🗝️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Gestão e Armazenamento Seguro de Senhas 🗝️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Gestão e Armazenamento Seguro de Senhas 🗝️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Gestão e Armazenamento Seguro de Senhas 🗝️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Gestão e Armazenamento Seguro de Senhas 🗝️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Gestão e Armazenamento Seguro de Senhas 🗝️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Gestão e Armazenamento Seguro de Senhas 🗝️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 14 – Privacidade de Dados e LGPD 🗂️

  1. Qual é o conceito fundamental e objetivo principal de Privacidade de Dados e LGPD 🗂️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Privacidade de Dados e LGPD 🗂️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Privacidade de Dados e LGPD 🗂️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Privacidade de Dados e LGPD 🗂️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Privacidade de Dados e LGPD 🗂️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Privacidade de Dados e LGPD 🗂️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Privacidade de Dados e LGPD 🗂️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Privacidade de Dados e LGPD 🗂️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Privacidade de Dados e LGPD 🗂️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Privacidade de Dados e LGPD 🗂️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 15 – Auditoria e Testes de Segurança 🔍

  1. Qual é o conceito fundamental e objetivo principal de Auditoria e Testes de Segurança 🔍?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Auditoria e Testes de Segurança 🔍?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Auditoria e Testes de Segurança 🔍, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Auditoria e Testes de Segurança 🔍?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Auditoria e Testes de Segurança 🔍 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Auditoria e Testes de Segurança 🔍, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Auditoria e Testes de Segurança 🔍?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Auditoria e Testes de Segurança 🔍 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Auditoria e Testes de Segurança 🔍 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Auditoria e Testes de Segurança 🔍 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 16 – Projeto Final: Sistema de Autenticação Seguro 🎓

  1. Qual é o conceito fundamental e objetivo principal de Projeto Final: Sistema de Autenticação Seguro 🎓?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Projeto Final: Sistema de Autenticação Seguro 🎓?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Projeto Final: Sistema de Autenticação Seguro 🎓, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Projeto Final: Sistema de Autenticação Seguro 🎓?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Projeto Final: Sistema de Autenticação Seguro 🎓 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Projeto Final: Sistema de Autenticação Seguro 🎓, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Projeto Final: Sistema de Autenticação Seguro 🎓?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Projeto Final: Sistema de Autenticação Seguro 🎓 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Projeto Final: Sistema de Autenticação Seguro 🎓 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Projeto Final: Sistema de Autenticação Seguro 🎓 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

Slides

Configuração

Guias de Instalação 🛠️

Prepare seu ambiente para dominar as Expressões Regulares.

Sobre

Sobre o Curso

🎓 Segurança e Criptografia

Este é um curso completo e estruturado de Segurança da Informação e Criptografia Aplicada. Desenvolvido para levar você dos fundamentos teóricos (confidencialidade, integridade, disponibilidade) até a aplicação prática de criptografia e autenticação em sistemas reais.

🎯 Objetivos do Curso

  • Dominar os Fundamentos

    Compreender os pilares da segurança da informação e o funcionamento dos principais algoritmos criptográficos.

  • Criptografia na Prática

    Aplicar criptografia simétrica, assimétrica, hashing e assinaturas digitais em cenários reais.

  • Autenticação Segura

    Projetar sistemas de login, senhas e controle de acesso seguindo boas práticas de mercado.

  • Segurança de Aplicações

    Reconhecer e mitigar as vulnerabilidades mais comuns do OWASP Top 10 em aplicações web.

📚 O Que Você Vai Aprender

Módulo 1 – Fundamentos de Segurança e Criptografia

  • Pilares da segurança: confidencialidade, integridade e disponibilidade
  • Ameaças, vulnerabilidades e vetores de ataque mais comuns
  • Criptografia simétrica (AES, DES) e assimétrica (RSA, Diffie-Hellman)
  • Funções de hash, assinaturas digitais e certificados (PKI)
  • Autenticação, controle de acesso e múltiplos fatores

Módulo 2 – Segurança Aplicada

  • TLS/SSL e segurança de comunicações em rede
  • Criptografia na prática com Python e JavaScript
  • OWASP Top 10 e defesa de aplicações web
  • Armazenamento seguro de senhas (hashing, salt)
  • Privacidade de dados, LGPD e auditoria de segurança

🛠️ Metodologia

  • Aulas Teóricas

    Conteúdo explicativo com exemplos práticos e slides interativos com Reveal.js.

  • Exercícios Progressivos

    Listas de exercícios por aula para fixar desde o básico até o desafio final.

  • Mini-Projetos

    Desenvolva soluções práticas de segurança e criptografia em cada aula do curso.

  • Quizzes Interativos

    Teste seus conhecimentos com questões por aula para garantir o aprendizado.

👨‍🎓 Público-Alvo

  • Estudantes de TI e ADS que querem entender como a segurança digital funciona de verdade
  • Desenvolvedores que precisam proteger dados e credenciais em suas aplicações
  • Profissionais de infraestrutura que buscam fundamentos sólidos de criptografia aplicada
  • Curiosos por segurança que querem sair da teoria e aplicar os conceitos na prática

📋 Pré-requisitos

  • Computador com internet
  • Lógica de programação básica (para os módulos práticos de Python/JavaScript)
  • Curiosidade para entender "por trás" do cadeado verde do navegador
  • Não é necessário conhecimento prévio de criptografia!

🎖️ O Que Você Receberá

  • ✅ 16 aulas completas e estruturadas
  • ✅ Slides modernos e interativos
  • ✅ Exercícios práticos progressivos por aula
  • ✅ 16 mini-projetos aplicados
  • ✅ Questões de quiz para fixação de cada aula
  • ✅ Projeto final: implementação de um sistema de autenticação seguro

🚀 Comece Agora

Pronto para entender e aplicar Segurança e Criptografia de verdade?

Ir para Aula 01 Materiais de Apoio

Dúvidas? Entre em contato ou acesse o plano de ensino.

Materiais

Bem-vindo à seção de materiais complementares do curso. Aqui você encontra recursos adicionais para apoiar seus estudos.

  • Slides

    • Acesse os slides de todas as aulas para revisão.

  • Exercícios

    • Pratique com listas de exercícios para cada módulo.

  • Quizzes

    • Teste seus conhecimentos com quizzes interativos.

  • Projetos

    • Desenvolva projetos práticos para aplicar o que aprendeu.

  • Setup

    • Guias de instalação e configuração do ambiente.

🏷️ Índice de Tags Didáticas

Navegue pelas aulas, exercícios e projetos do curso organizados por temas, tecnologias e conceitos fundamentais:

tags.md:145-167/name

Versão para Impressão

Esta página foi gerada automaticamente para impressão.