Da linha de comando ao pipeline blindado.

O modelo mental: camadas

Uma rede é uma pilha de abstrações. Cada camada só conversa com a de baixo. Você não precisa decorar o modelo OSI de 7 camadas — precisa do modelo TCP/IP prático de 4:

Portas, sockets e o que "escuta" numa máquina

Um serviço abre uma porta (0–65535) e fica escutando. IP + porta = socket. Web = 80/443, SSH = 22, DNS = 53. Metade do trabalho de recon é descobrir quais portas estão abertas. Veja o que sua própria máquina expõe:

# O que está escutando, com processo dono (Linux)
sudo ss -tulpn

# Testar conectividade e caminho até um host
ping -c 4 example.com
traceroute example.com          # mostra cada salto (hop)

# Abrir um socket "na unha" para falar HTTP cru
printf 'GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n' | nc example.com 80

DNS: a lista telefônica (e um alvo constante)

Nomes viram IPs via DNS. A resolução recursiva passa por raiz → TLD → autoritativo. Registros que importam em segurança: A/AAAA (IP), CNAME (apelido — vetor de subdomain takeover), MX (e-mail), TXT (SPF/DKIM/DMARC — antispoofing), NS (delegação).

dig +short A example.com
dig +short TXT example.com         # SPF/DMARC ficam aqui
dig +short NS example.com
dig +trace example.com            # mostra a cadeia de resolução inteira

HTTP e TLS na prática

HTTP é texto: método (GET, POST), caminho, cabeçalhos, corpo. Status importam: 200 ok, 301/302 redirect, 401/403 auth, 500 erro do servidor. TLS envolve o HTTP em criptografia (HTTPS = HTTP sobre TLS). O handshake TLS negocia versão, cifra e valida o certificado do servidor contra uma CA confiável.

# Ver headers da resposta (segurança mora aqui)
curl -sI https://example.com

# Inspecionar o certificado e a cadeia TLS
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Headers de segurança que você vai passar a exigir de toda aplicação: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy. A ausência deles já é um achado de auditoria.

O sistema de arquivos e a filosofia "tudo é arquivo"

No Linux, dispositivos, processos e sockets aparecem como arquivos. Diretórios que você precisa conhecer: /etc (configuração), /var/log (logs — sua fonte forense), /home (usuários), /proc e /sys (kernel e processos em tempo real), /tmp (temporário e mundialmente gravável — vetor comum).

Navegação, busca e o poder dos pipes

A força do shell é compor ferramentas pequenas com o pipe |. Cada comando faz uma coisa; você encadeia.

find /var/www -name "*.php" -mtime -7   # arquivos php mudados nos últimos 7 dias
grep -rniE "password|api_key|secret" .   # caça a segredos hardcoded

# pipeline: top 10 IPs que mais bateram no nginx
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# só as linhas 401/403 (tentativas de acesso negado)
grep -E ' (401|403) ' /var/log/nginx/access.log | wc -l

Processos, jobs e serviços

Você precisa ver o que roda, matar o que trava e entender serviços gerenciados pelo systemd.

ps aux --sort=-%cpu | head        # quem consome CPU
sudo systemctl status ssh          # estado de um serviço
sudo journalctl -u ssh --since "1 hour ago"   # logs do serviço
lsof -i :443                       # que processo usa a porta 443

Scripting: automação é metade do trabalho

Um script defensável tem set -euo pipefail (falha cedo, falha alto). DevSecOps é, em grande parte, escrever automações confiáveis.

#!/usr/bin/env bash
set -euo pipefail
url="${1:?uso: ./verifica-headers.sh https://host}"
faltando=()
for h in strict-transport-security content-security-policy x-content-type-options; do
  if ! curl -sI "$url" | grep -qi "^$h:"; then
    faltando+=("$h")
  fi
done
if [ ${#faltando[@]} -eq 0 ]; then echo "OK: headers presentes";
else echo "FALTANDO: ${faltando[*]}"; exit 1; fi

Usuários, grupos e o modelo de permissão

Todo arquivo tem dono, grupo e "outros", cada um com read/write/execute. rwxr-x--- = dono lê/escreve/executa, grupo lê/executa, outros nada. Em octal: 750. Isso é o coração do controle de acesso — e do que um atacante busca burlar.

chmod 640 config.env          # dono rw, grupo r, outros nada
chown app:app config.env
umask 027                     # novos arquivos nascem sem permissão p/ "outros"

SUID, sudo e escalada de privilégios

O bit SUID faz um binário rodar com o dono dele (geralmente root), não com quem o executa. É necessário para coisas como passwd, mas um SUID mal configurado é o caminho clássico de escalada. A caça a esses arquivos é rotina em pentest e em hardening.

# todos os binários SUID do sistema
find / -perm -4000 -type f 2>/dev/null

# o que este usuário pode rodar como root
sudo -l

Hardening de um servidor Linux

Reduzir superfície de ataque = princípio do menor privilégio aplicado ao sistema inteiro.

• Desabilitar login SSH por senha e por root; usar apenas chaves
• Firewall padrão-negar (ufw default deny incoming)
• Atualizações automáticas de segurança (unattended-upgrades)
• Remover pacotes e serviços não usados
• Habilitar auditd/journald e enviar logs para fora da máquina
• Aplicar um benchmark CIS ou usar lynis audit system como baseline

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
MaxAuthTries 3
AllowUsers deploy

Os três pilares e para que servem

Confidencialidade, integridade, autenticidade

Criptografia entrega objetivos, não "segurança" genérica. Cifrar dá confidencialidade. MAC/assinatura dá integridade + autenticidade. Quase todo bug de cripto vem de confundir isso — por isso AEAD (que faz os dois de uma vez) é o default moderno.

# impressão digital de um arquivo
sha256sum artefato.tar.gz

# par de chaves moderno para SSH (Ed25519)
ssh-keygen -t ed25519 -C "deploy@ci"

# hash de senha com Argon2 (via ferramenta argon2)
echo -n "minhasenha" | argon2 "$(openssl rand -hex 16)" -id -t 3 -m 16

PKI, certificados e a cadeia de confiança

Um certificado X.509 amarra uma chave pública a uma identidade (domínio), assinado por uma Autoridade Certificadora (CA) em quem seu sistema confia. Cadeia: certificado do site → CA intermediária → CA raiz (no seu truststore). Se qualquer elo falhar (expirado, hostname errado, CA desconhecida), a validação quebra. Isto é o que sustenta TLS e, mais adiante, o mTLS de Zero Trust (módulo 21).

# CA raiz de laboratório
openssl req -x509 -newkey rsa:4096 -nodes -keyout ca.key -out ca.crt \
  -days 365 -subj "/CN=Lab Root CA"

# chave + CSR do serviço
openssl req -newkey rsa:2048 -nodes -keyout svc.key -out svc.csr \
  -subj "/CN=svc.local"

# CA assina o cert do serviço
openssl x509 -req -in svc.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -out svc.crt -days 90

JWT: onde AppSec encontra cripto

Tokens JWT são três partes base64: header, payload, assinatura. A assinatura (HMAC ou assimétrica) garante que ninguém alterou o payload. Vulnerabilidades famosas: aceitar alg: none, confundir chave pública com segredo HMAC (algorithm confusion), ou não validar expiração. Você vai explorar e corrigir isso no módulo 06.

Threat modeling: STRIDE em 4 perguntas

Modelagem de ameaças é responder cedo, no design: o que estamos construindo? o que pode dar errado? o que faremos a respeito? fizemos um bom trabalho? O mnemônico STRIDE te dá as categorias de "o que pode dar errado":

Na prática você desenha um data flow diagram (usuário → API → banco → serviços externos), marca as fronteiras de confiança (trust boundaries) e aplica STRIDE em cada travessia. É barato fazer no whiteboard e caro descobrir em produção.

OWASP Top 10 — o vocabulário obrigatório

É a lista de referência das categorias de risco mais críticas em aplicações web. Você precisa reconhecer cada uma de cor:

Injeção SQL — a mãe dos exemplos

Acontece quando entrada do usuário é concatenada numa query. Se o código faz "SELECT * FROM users WHERE nome='" + input + "'", o input ' OR '1'='1 transforma a condição em sempre-verdadeira. A correção não é "filtrar aspas" — é separar código de dados com queries parametrizadas.

# ❌ VULNERÁVEL — concatenação
cur.execute(f"SELECT * FROM users WHERE email='{email}'")

# ✅ SEGURO — query parametrizada (o driver escapa)
cur.execute("SELECT * FROM users WHERE email=%s", (email,))

XSS — quando o navegador executa o que não devia

Cross-Site Scripting injeta JavaScript que roda no navegador da vítima (roubo de sessão, keylogging). Tipos: refletido (na resposta imediata), armazenado (salvo no banco, atinge todos) e DOM-based (no client). Defesa em camadas: escape de saída conforme o contexto (HTML, atributo, JS), Content-Security-Policy, e cookies HttpOnly.

# payload de teste clássico (refletido)
<script>alert(document.cookie)</script>

# defesa: CSP restritiva no header de resposta
Content-Security-Policy: default-src 'self'; script-src 'self'

SSRF — o servidor como seu proxy

Server-Side Request Forgery faz a aplicação buscar uma URL que o atacante controla. Em nuvem, o alvo é o endpoint de metadados (169.254.169.254), que pode vazar credenciais temporárias da instância. É por isso que SSRF é catastrófico em AWS/GCP e entrou no Top 10. Defesa: allowlist de destinos, bloquear IPs internos/link-local, e usar IMDSv2 (módulo 17).

IDOR & Broken Access Control

Se /api/pedido/1001 mostra o pedido de outro usuário só trocando o número, é IDOR. A causa: o servidor confia no ID sem checar se aquele usuário pode ver aquele recurso. A correção é sempre server-side: valide a posse do objeto em toda requisição, nunca esconda o botão e ache que basta.

Falhas de autenticação e JWT

Retomando o módulo 04: um JWT que aceita {"alg":"none"} ignora a assinatura — qualquer um forja um admin. Outra: servidor que valida token HMAC usando a chave pública como segredo. Sempre fixe o algoritmo esperado no servidor e valide exp, iss e aud.

As fases de um engajamento

Um pentest segue etapas bem definidas — o mesmo mapa que o defensor usa para saber onde plantar detecção:

Recon e scanning na prática

# descoberta de hosts na sua rede de lab
nmap -sn 10.10.10.0/24

# portas + versões + scripts default
nmap -sV -sC -p- 10.10.10.5

# fuzzing de diretórios web
ffuf -u http://10.10.10.5/FUZZ -w /usr/share/wordlists/dirb/common.txt

O MITRE ATT&CK é o dicionário que conecta cada técnica ofensiva a táticas (Initial Access, Persistence, Lateral Movement…). Domine-o: é a linguagem comum de red e blue team, e você vai usá-lo para escrever detecções no módulo 22.

Pós-exploração e movimento lateral

Acesso inicial raramente é o objetivo — é o começo. O atacante escala privilégio (módulo 03), busca credenciais em memória e arquivos, e pivota para outras máquinas. Entender isso te ensina onde o defensor deve segmentar rede, rotacionar credenciais e monitorar.

Sem log, sem defesa

A9 do OWASP existe por um motivo: você não responde ao que não vê. Um bom pipeline de observabilidade de segurança coleta, centraliza e correlaciona: logs de aplicação, sistema (auditd), rede (flow logs) e nuvem (CloudTrail). O agregador é o SIEM (Splunk, Elastic, Wazuh, Sentinel).

Do log ao alerta: detecção

Detecção é transformar sinal em alerta acionável. Regras respondem a padrões: 5 falhas de login seguidas de um sucesso (possível brute-force bem-sucedido), execução de whoami logo após acesso a um serviço web (possível RCE), criação de usuário IAM fora do horário. O padrão aberto para escrever isso é Sigma, que você converte para a query do seu SIEM.

title: Possível brute force SSH bem-sucedido
logsource:
  product: linux
  service: auth
detection:
  falhas:
    message|contains: 'Failed password'
  sucesso:
    message|contains: 'Accepted password'
  condition: falhas | count() > 5 near sucesso
level: high

Resposta a incidentes: o ciclo

Quando o alerta dispara, entra o processo de IR (referência: NIST SP 800-61). Memorize as fases:

De "gate no final" para "segurança contínua"

No modelo antigo, o time de segurança auditava no fim e barrava o release — gerando atrito, atraso e conflito. Shift-left move os controles para o começo do ciclo, onde corrigir é ordens de magnitude mais barato. DevSecOps é a cultura + automação que torna isso viável: a segurança vira código que roda no pipeline, e o dev recebe feedback em minutos, não semanas.

O SDLC seguro, etapa por etapa

Medindo maturidade e escalando com "guardrails"

Modelos como OWASP SAMM e BSIMM medem a maturidade do programa. Mas o conceito operacional mais importante é guardrails, não gates: em vez de bloquear, você dá caminhos pavimentados seguros (templates de pipeline, módulos de IaC aprovados, imagens base endurecidas) para que o time de dev faça a coisa certa por padrão. Segurança que escala é segurança que se torna a opção fácil.

O vazamento nº1: segredos no repositório

Chaves de API, tokens e senhas commitados são uma das causas mais comuns de invasão. E o Git nunca esquece: apagar num commit novo não remove do histórico. A defesa é prevenir na origem com pre-commit hooks e escanear o histórico.

# escanear o repo inteiro (histórico incluso)
gitleaks detect --source . --verbose

# instalar pre-commit hooks que barram o segredo antes do commit
pip install pre-commit
# .pre-commit-config.yaml aponta para gitleaks / detect-secrets
pre-commit install

Onde segredos realmente devem morar

A regra: segredo nunca no código, nunca em imagem, nunca em log. Ele vive num cofre e é injetado em runtime. Escala de maturidade:

• Variáveis de ambiente + .env fora do git — mínimo viável, ainda frágil.
• Secret manager gerenciado — AWS Secrets Manager, GCP Secret Manager, Azure Key Vault. Rotação, auditoria, IAM.
• HashiCorp Vault — cofre dedicado com segredos dinâmicos (credencial de banco criada sob demanda, válida por minutos) e leasing.

# app pede um segredo em runtime, autenticado por sua identidade
vault kv get -field=password secret/prod/db

# segredo dinâmico: credencial de banco efêmera, revogada sozinha
vault read database/creds/app-readonly

Proteção do repositório e da colaboração

• Branch protection na main: exigir PR, review e checks verdes
• Commits assinados (GPG/SSH/Sigstore) para autenticidade
• 2FA obrigatório na organização e menor privilégio nos tokens de CI
• Dependabot/Renovate para atualizar dependências (conecta ao M11)
• CODEOWNERS para exigir review de segurança em paths sensíveis

O trio de scanners e o que cada um vê

Nenhum sozinho é suficiente — eles têm ângulos complementares. Some IaC scanning (M14) e container scanning (M12) e você tem cobertura de ponta a ponta.

Um pipeline real (GitHub Actions)

Veja como isso vira YAML. Este é o tipo de artefato que você vai escrever e defender numa entrevista técnica:

name: security-scan
on: [push, pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # secret scanning
      - name: Gitleaks
        uses: gitleaks/gitleaks-action@v2

      # SAST — regras da comunidade + próprias
      - name: Semgrep
        run: |
          pip install semgrep
          semgrep --config=auto --error .

      # SCA — dependências e imagem
      - name: Trivy (deps + fs)
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: fs
          severity: HIGH,CRITICAL
          exit-code: '1'   # falha o build se achar HIGH/CRITICAL

Gates: quando quebrar o build?

Retomando o M09: nem todo achado bloqueia. Uma política sensata: bloquear segredo vazado e vuln CRITICAL com exploit conhecido sempre; para o resto, criar issue e dar prazo (SLA de remediação por severidade). A chave é triagem: reduzir ruído para que os alertas bloqueantes sejam confiáveis.

DAST no pipeline

# sobe a app efêmera, roda scan passivo/baseline, gera relatório
docker run --rm -t ghcr.io/zaproxy/zaproxy zap-baseline.py \
  -t http://staging.app.local -r zap-report.html

O que é (e o que não é) um container

Um container é um processo isolado por recursos do kernel — namespaces (o que ele vê) e cgroups (quanto ele usa) — compartilhando o kernel do host. Isso é fundamental: container não é VM. O isolamento é mais fino, então um escape de container atinge o host. Entender namespaces/cgroups é o que separa quem "usa Docker" de quem "protege Docker".

Anatomia de um Dockerfile seguro

# estágio de build
FROM golang:1.22 AS build
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /app ./cmd

# imagem final mínima — sem shell, sem package manager
FROM gcr.io/distroless/static:nonroot
COPY --from=build /app /app
USER nonroot:nonroot        # nunca rode como root
ENTRYPOINT ["/app"]

Princípios embutidos aí: multi-stage (ferramentas de build ficam fora da imagem final), base mínima (distroless/alpine — menos pacotes, menos CVEs, sem shell para o atacante usar), usuário não-root, e imagem imutável (nada instalado em runtime).

Escaneando e endurecendo

# CVEs na imagem (integra ao pipeline do M11)
trivy image minhaapp:latest --severity HIGH,CRITICAL

# rodar com privilégios reduzidos
docker run --read-only --cap-drop ALL \
  --security-opt no-new-privileges \
  --user 10001 minhaapp:latest

• Nunca --privileged; drope todas as capabilities e adicione só as necessárias
• Sistema de arquivos read-only; monte volumes específicos como writable
• Nunca monte o docker.sock dentro de um container (= root no host)
• Fixe a base por digest (@sha256:...), não por tag mutável
• Escaneie na build E no registry; bloqueie push de imagem vulnerável

A superfície de ataque do cluster

Kubernetes tem muitas fronteiras: API server (o cérebro), etcd (o banco com todos os segredos), kubelet (agente em cada nó), e as cargas em si. A referência mental são os 4 C's: Cloud, Cluster, Container, Code — segurança é em camadas, de fora para dentro. Um pod comprometido não pode virar cluster comprometido.

RBAC: menor privilégio no cluster

RBAC controla quem faz o quê. O erro clássico é dar cluster-admin "para funcionar". Comece negando e conceda o mínimo por namespace.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata: { namespace: app, name: pod-reader }
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list"]   # nada de create/delete/exec

Isolar cargas: Pod Security & Network Policy

Por padrão, todo pod fala com todo pod — péssimo. NetworkPolicy aplica micro-segmentação (base do Zero Trust, M21). Pod Security Standards (restricted) impedem pods privilegiados, root e escalada.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata: { name: default-deny, namespace: app }
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]   # sem regras = nega tudo; libere explicitamente

Admission control: a política que barra na porta

Admission controllers avaliam cada objeto antes de criá-lo. Com OPA/Gatekeeper ou Kyverno você impõe regras como "nenhuma imagem sem tag fixa", "nenhum container privilegiado", "todo pod tem limites de recurso". É o guardrail do M09 aplicado ao cluster — Policy as Code no runtime.

kubectl auth can-i --list           # o que ESTA identidade pode fazer
kube-bench                          # auditoria CIS do cluster
trivy k8s --report summary cluster # CVEs e misconfigs

Infra como código = risco como código (e correção como código)

Quando a infraestrutura é declarada em texto (Terraform, CloudFormation, Bicep), uma configuração insegura — bucket público, security group aberto, banco sem criptografia — vira um bug detectável antes do deploy. Esse é o shift-left mais poderoso da nuvem: você corrige no PR, não em produção.

# ❌ security group escancarado
ingress { from_port=22 to_port=22 protocol="tcp" cidr_blocks=["0.0.0.0/0"] }

# ✅ acesso restrito a uma rede conhecida
ingress { from_port=22 to_port=22 protocol="tcp" cidr_blocks=[var.bastion_cidr] }

Scanners de IaC

trivy config .           # misconfigs em TF/K8s/Docker
checkov -d .             # centenas de checks prontos + custom
tfsec .                  # foco em Terraform

Todos plugam no pipeline (M11) e falham o PR quando encontram uma política violada. A saída em formato SARIF integra ao GitHub Security, centralizando findings.

Policy as Code com OPA/Rego

Além de checks prontos, você escreve suas políticas organizacionais em Rego (linguagem do Open Policy Agent). Ex.: "todo bucket S3 desta org deve ter criptografia e bloqueio de acesso público". A mesma engine (OPA) governa Terraform no CI, admission no Kubernetes (M13) e autorização de API — um só vocabulário de política.

package terraform.s3
deny[msg] {
  bucket := input.resource.aws_s3_bucket[name]
  bucket.acl == "public-read"
  msg := sprintf("bucket %v não pode ser público", [name])
}

Por que isso virou prioridade

Ataques como SolarWinds, Log4Shell e pacotes maliciosos em npm/PyPI mostraram que o elo mais fraco pode ser uma dependência ou o próprio build. Supply chain security (A08 do OWASP) responde a três perguntas: o que tem no meu software? de onde veio? posso provar que não foi adulterado?

SBOM: a lista de ingredientes

Um SBOM (Software Bill of Materials) é o inventário completo de componentes e versões, em formato padrão (CycloneDX, SPDX). Com ele, quando sai um novo CVE (tipo Log4Shell), você responde em minutos "estou afetado?" em vez de dias.

syft minhaapp:latest -o cyclonedx-json > sbom.json   # gera o SBOM
grype sbom:sbom.json                                 # cruza com CVEs conhecidos

Assinatura e proveniência: Sigstore & SLSA

Sigstore/cosign assina artefatos (imagens, SBOMs) usando identidade — sem gerenciar chaves de longo prazo (keyless, via OIDC). O consumidor verifica antes de rodar. SLSA é um framework de níveis que atesta como o artefato foi construído (proveniência do build), dificultando adulteração no pipeline.

cosign sign minhaapp@sha256:abc...            # assina (keyless via OIDC do CI)
cosign verify minhaapp@sha256:abc... \
  --certificate-identity-regexp=".*" \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com

No Kubernetes, uma policy de admission (M13) pode exigir assinatura válida — nenhuma imagem não assinada roda. É o fechamento do círculo: build → assina → verifica → executa.

Responsabilidade compartilhada

A nuvem protege "a infraestrutura da nuvem"; você protege "o que roda nela": suas configurações, dados, IAM e código. A maioria dos vazamentos famosos (buckets abertos) é falha do cliente, não do provedor. Saber onde termina a responsabilidade deles e começa a sua é a primeira pergunta de qualquer arquitetura.

IAM: identidade é o novo perímetro

Não existe mais "dentro da rede confiável". O que um ator pode fazer depende inteiramente da identidade e das políticas dela. Conceitos que você precisa dominar:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::relatorios/*",
  "Condition": { "IpAddress": { "aws:SourceIp": "203.0.113.0/24" } }
}

Fim das chaves estáticas: OIDC & workload identity

O padrão moderno elimina credenciais de longa duração. Seu pipeline (GitHub Actions) autentica na nuvem via OIDC, recebendo credenciais temporárias — nada de AKIA... guardado em secret. Isso conecta diretamente ao M10 (segredos) e é hoje a resposta certa em entrevista para "como o CI acessa a AWS?".

Os mesmos conceitos, nomes diferentes

Aprenda os conceitos e a tradução entre nuvens vem fácil. Este é o mapa que te deixa "multi-cloud":

Os quatro controles que você sempre configura

• Rede: segmentar com sub-redes privadas, security groups padrão-negar, sem SSH/RDP aberto ao mundo, endpoints privados para serviços gerenciados.
• Dados: criptografia em repouso (KMS) e em trânsito (TLS) por padrão; bloqueio de acesso público em storage; versionamento.
• Logs: CloudTrail/Audit Logs habilitados em todas as regiões, imutáveis, centralizados em conta separada.
• Chaves: envelope encryption via KMS, rotação automática, políticas de chave restritas.

O clássico: SSRF + metadata (fechando o M06)

Instâncias expõem um endpoint de metadados com credenciais. Um SSRF que alcança 169.254.169.254 rouba essas credenciais. A defesa na AWS é IMDSv2 (exige token, bloqueia o ataque). Saber essa cadeia ataque→defesa é sinal de maturidade em cloud.

A sopa de siglas, decodificada

Na prática, com ferramentas abertas

Você não precisa de produto pago para aprender o conceito. O Prowler faz CSPM open-source direto contra sua conta:

prowler aws --severity critical high   # auditoria de postura AWS
prowler aws --compliance cis_2.0_aws   # contra o benchmark CIS

# mapa de permissões e riscos IAM (ScoutSuite)
scout aws

O valor de uma CNAPP é correlação: unir "esse container tem CVE crítico" + "está exposto à internet" + "roda com role admin" = um caminho de ataque priorizado. Postura isolada gera milhares de alertas; correlação gera os 5 que importam.

O log que conta tudo: CloudTrail & amigos

Na nuvem, cada ação é uma chamada de API registrada. CloudTrail (AWS), Audit Logs (GCP) e Activity Log (Azure) são sua fonte forense primária. Habilitados em todas as regiões, imutáveis e centralizados, respondem "quem fez o quê, quando, de onde" — a base de toda investigação.

Detecção gerenciada + regras próprias

Serviços como GuardDuty analisam logs e fluxos com ML e threat intel, alertando sobre credencial usada de local incomum, chamada de reconhecimento, comunicação com IP malicioso. Você complementa com detecções sob medida (Sigma/EventBridge) para o que é específico do seu ambiente — retomando o M08.

{
  "source": ["aws.iam"],
  "detail": {
    "eventName": ["CreateAccessKey", "AttachUserPolicy"],
    "userIdentity": { "type": ["IAMUser"] }
  }
}
# dispara p/ SNS/Lambda quando alguém cria chave ou eleva permissão

Resposta automatizada (SOAR cloud-native)

O poder da nuvem é responder com código. Um alerta pode disparar uma função que isola a instância (muda o security group), revoga a credencial suspeita ou tira um snapshot forense — em segundos, sem humano no loop para a contenção inicial. É o ciclo de IR do M08 executado por automação.

Princípios que viram decisões de arquitetura

Segurança madura não é uma lista de controles, e sim princípios aplicados no design. Os que você vai justificar em revisões de arquitetura:

Threat modeling em escala

Além do STRIDE do M05, arquitetos usam attack trees (decompor um objetivo do atacante em caminhos) e mapeiam controles ao MITRE ATT&CK para medir cobertura. Em sistemas grandes, threat modeling vira contínuo: cada mudança de arquitetura relevante passa por uma revisão leve, e decisões ficam registradas em ADRs de segurança (Architecture Decision Records).

Padrões de arquitetura segura na nuvem

• Isolamento por conta/projeto: prod, dev e dados sensíveis em contas separadas, com organização e SCPs (guardrails no topo).
• Perímetro de dados: políticas que garantem que dados só saem por caminhos aprovados (VPC endpoints, resource policies).
• Identidade federada e efêmera: zero chave de longa duração; tudo via roles assumidas e OIDC (M16).
• Criptografia com chaves gerenciadas por você (BYOK/envelope): controle e revogação centralizados via KMS.

O que Zero Trust realmente significa

Zero Trust abandona a ideia de "rede interna confiável". Cada requisição é autenticada, autorizada e cifrada, independentemente de onde vem. Os pilares: identidade forte para usuários E workloads, menor privilégio por requisição, micro-segmentação (M13) e verificação contínua (não só no login). Não é um produto — é uma arquitetura que você monta com peças.

mTLS: identidade mútua entre serviços

No TLS comum (M04), só o servidor prova identidade. No mTLS, cliente e servidor apresentam certificados — cada serviço prova quem é. Isso dá autenticação de workload e cifra o tráfego leste-oeste (serviço-a-serviço). O desafio é operacional: emitir, rotacionar e revogar certificados em escala. Padrões como SPIFFE/SPIRE dão a cada workload uma identidade criptográfica verificável (SVID).

Service mesh: mTLS e política sem tocar no código

Um service mesh (Istio, Linkerd) injeta um sidecar proxy ao lado de cada serviço, que faz mTLS, roteamento e aplica política de autorização automaticamente — o dev não muda a aplicação. É Zero Trust aplicado à camada de rede do cluster.

# exige mTLS para todo tráfego no namespace
kind: PeerAuthentication
spec: { mtls: { mode: STRICT } }
---
# só o serviço "frontend" pode chamar "payments"
kind: AuthorizationPolicy
metadata: { name: payments-allow }
spec:
  selector: { matchLabels: { app: payments } }
  rules:
    - from: [{ source: { principals: ["cluster.local/ns/app/sa/frontend"] } }]

Detection engineering: detecção como software

Detecção madura é tratada como código: cada regra tem hipótese, testes, versionamento e métricas de qualidade (taxa de falso positivo, cobertura de ATT&CK). O ciclo do purple team fecha o loop: o red team executa uma técnica (ex.: via Atomic Red Team), o blue team verifica se a detecção disparou, e a regra é refinada. Detecção que nunca foi testada contra o ataque real é fé, não engenharia.

eBPF: visibilidade no kernel

eBPF permite rodar programas seguros dentro do kernel Linux, observando syscalls, rede e processos com overhead mínimo — sem módulos de kernel arriscados. É a tecnologia por trás da observabilidade e segurança runtime modernas. O Falco usa isso para detectar comportamento suspeito em containers em tempo real.

- rule: Shell interativo em container
  condition: >
    spawned_process and container
    and shell_procs and proc.tty != 0
  output: "Shell aberto em container (user=%user.name container=%container.id)"
  priority: WARNING

Ferramentas como Tetragon e Cilium (também eBPF) levam isso a política de rede e de execução em nível de kernel — enforcement, não só observação. É o estado da arte em runtime security cloud-native.

Threat hunting

Nem toda ameaça dispara um alerta. Hunting é a busca proativa por comprometimento com base em hipóteses ("se um atacante tivesse persistência aqui, veríamos X"). Combina conhecimento de ATT&CK (M07), dados ricos (M08) e curiosidade estruturada. É onde blue team vira arte.

Por que LLMs quebram suposições de AppSec

Aplicações com LLM misturam instruções e dados no mesmo canal de texto — exatamente o que a injeção (M06) explora, agora em linguagem natural. Se o modelo tem acesso a ferramentas (buscar na web, chamar APIs, ler arquivos), uma instrução maliciosa escondida em conteúdo pode virar ação real. É AppSec com uma superfície nova e não-determinística.

OWASP Top 10 for LLM Applications

Existe um Top 10 dedicado. Os riscos centrais:

Defesas em camadas

• Trate a saída do LLM como entrada não confiável — valide e escape antes de qualquer ação (retomando M06).
• Menor privilégio para agentes — cada ferramenta com escopo mínimo; ações sensíveis exigem confirmação humana (human-in-the-loop).
• Isole instruções de dados — delimitadores, e nunca confie que conteúdo externo é "só dados".
• Guardrails de entrada/saída — classificadores para detectar injeção e filtrar dados sensíveis.
• Red teaming de LLM — teste sistemático de jailbreaks e injeções (ferramentas como Garak).

O portfólio importa mais que o currículo

Em segurança, prova de habilidade vence linhas de currículo. Se você fez os laboratórios desta apostila, já tem os alicerces de um portfólio forte. Organize-os:

• Repositório público com um pipeline DevSecOps completo (M11) — SAST, SCA, secret scanning, DAST, com README explicando cada decisão de gate
• Projeto "hardening de container" com antes/depois de CVEs (M12)
• Baseline de IaC seguro com políticas OPA/Rego próprias (M14)
• Relatório de findings do Juice Shop com remediações (M06)
• Write-ups de máquinas do TryHackMe/HackTheBox (M07)
• Relatório de CSPM (Prowler) com correções aplicadas (M18)
• Um blog técnico: escrever sobre o que você aprendeu prova comunicação — habilidade sênior subvalorizada

Certificações que valem o investimento

Certificação abre portas em triagem de RH, mas não substitui prática. Escolha por objetivo, não por colecionismo:

Preparação para entrevista

Entrevistas de segurança misturam três frentes. Prepare-se para cada uma:

Um roadmap realista

Esse ritmo assume estudo consistente ao lado de outras responsabilidades. Ajuste ao seu contexto — o que não muda é a sequência: fundamentos sólidos, prática documentada, especialização, exposição ao mercado.