Visão geral

O BoxOffice sai do laptop e vai para produção na nuvem. Em um mês, quatro histórias chegam à mesa do time. O laptop de um prestador de serviço é roubado, e nele há um arquivo .env com a chave de API do provedor de pagamentos. O novo app mobile precisa de login, e alguém propõe "é só guardar a senha no app". Às 10:00 do dia em que um show de estádio abre as vendas, bots pegam 30% das reservas de assento no primeiro minuto e revendem os ingressos pelo triplo do preço. E uma biblioteca vulnerável no serviço search permite que um atacante execute código dentro de um pod — de onde, na configuração padrão, todos os outros serviços, o banco de dados e a Internet estão a uma conexão de distância.

Nenhum desses casos é um bug em uma linha de código. São problemas de projeto: onde ficam as fronteiras de rede, quem pode falar com quem, como as identidades são provadas, onde os segredos vivem e com que rapidez podem ser revogados. Esta aula trata segurança e redes do jeito que o resto do curso trata escalabilidade — como decisões de arquitetura com trade-offs, tomadas de propósito, desenhadas no diagrama e defendidas em uma entrevista.

Roteiro

1. Esta visão geral — segurança como projeto: modelagem de ameaças com STRIDE, defesa em profundidade e o OWASP API Security Top 10 aplicado ao BoxOffice. A identidade — tokens, OAuth 2.1 e OIDC — foi ensinada onde o BoxOffice precisou dela primeiro, no gateway: aula 4 — Identidade.
2. Como a Internet funciona — camadas, roteamento salto a salto e BGP, endereços IP e CIDR, endereços públicos vs privados, NAT, sub-redes e o gateway padrão; dois simuladores (explorador de endereços, caminho do pacote na VPC do BoxOffice).
3. Redes em nuvem — VPC, sub-redes, tabelas de rotas, Internet e NAT gateways, security groups vs NACLs, endpoints privados, VPN e links dedicados.
4. Service mesh — plano de dados e plano de controle, sidecar vs ambient vs eBPF, mTLS, políticas de autorização e de tráfego.
5. Zero Trust, segredos e cadeia de suprimentos — nunca confiar na rede, identidade de workloads, gestão de segredos, SBOM, assinatura de imagens e SLSA.
6. Quiz — verifique seu entendimento.

Slides

Clique nos slides e use ← → para navegar; F abre em tela cheia e P abre a visão do apresentador, com as notas. Abrir os slides em uma nova aba

Segurança é uma propriedade do projeto

Um erro comum é tratar segurança como uma checklist aplicada no fim ("coloca HTTPS e uma tela de login"). Nessa hora as decisões caras já foram tomadas: o banco de dados está numa sub-rede com rota para a Internet, todos os serviços compartilham uma senha de banco, o gateway é o único lugar que verifica alguma coisa. Mudar isso depois significa refazer a arquitetura.

A alternativa é fazer as perguntas de segurança enquanto se desenha a arquitetura, com a mesma seriedade de "quantas QPS?". Três ideias organizam toda a aula:

Dois termos usados ao longo da aula:

• Superfície de ataque (attack surface) — a soma de todos os pontos por onde um atacante pode tentar entrar ou extrair dados: endpoints públicos, portas abertas, dependências, pessoas com acesso.
• Raio de impacto (blast radius) — o que um atacante alcança depois que um componente é comprometido. Um bom projeto o mantém pequeno.

Modelagem de ameaças com STRIDE

Modelagem de ameaças (threat modeling) é uma conversa estruturada sobre um projeto: desenhar como os dados fluem, marcar onde o nível de confiança muda e perguntar sistematicamente o que pode dar errado em cada elemento¹. Adam Shostack a resume em quatro perguntas²:

1. Em que estamos trabalhando? — desenhe um diagrama de fluxo de dados (DFD).
2. O que pode dar errado? — enumere ameaças, por exemplo com STRIDE.
3. O que vamos fazer a respeito? — escolha um controle para cada ameaça (mitigar, aceitar, transferir, eliminar).
4. Fizemos um bom trabalho? — revise, teste, repita quando o projeto mudar.

Passo 1 — o diagrama de fluxo de dados do checkout

Uma fronteira de confiança (trust boundary) é uma linha onde os dados passam entre componentes com níveis diferentes de confiança: a Internet e a nossa borda, o nosso cluster e o provedor de pagamentos, um serviço e o seu banco. As ameaças se concentram nas fronteiras.

flowchart LR
    subgraph internet ["Internet (não confiável)"]
        M(["App mobile"])
        B(["Bot"])
    end
    subgraph edge ["Borda (sub-rede pública)"]
        W["WAF + API gateway"]
    end
    subgraph cluster ["Cluster BoxOffice (sub-redes privadas)"]
        O["order"]
        I["inventory"]
        P["payment"]
        A["auth"]
    end
    subgraph data ["Dados (sub-redes isoladas)"]
        DB[("PostgreSQL")]
    end
    subgraph ext ["Provedor de pagamentos (terceiro)"]
        PSP["API do PSP"]
    end
    M -->|"POST /orders + token"| W
    B -.->|"POST /holds × 10 000"| W
    W --> O
    O --> I
    I --> DB
    O --> P
    P -->|"chave de API, via NAT"| PSP
    PSP -.->|"webhook: pagamento capturado"| W
    M -->|"login"| A

Cinco fronteiras de confiança são atravessadas em um único checkout: Internet → borda, borda → cluster, serviço → banco, cluster → provedor e provedor → cluster (o webhook). Cada seta é uma pergunta: quem está chamando, como sabemos, e o que ele pode fazer?

Passo 2 — STRIDE

STRIDE é um mnemônico criado na Microsoft para seis categorias de ameaça, cada uma a violação de uma propriedade de segurança¹:

STRIDE é aplicado a cada elemento do DFD: processos estão expostos às seis categorias; repositórios de dados, principalmente a adulteração, vazamento de informação e negação de serviço; fluxos de dados, a adulteração, vazamento e DoS; entidades externas, a falsificação e repúdio².

Passo 3 — avaliar o risco e decidir

Nem toda ameaça merece o mesmo esforço. Uma prática simples é estimar probabilidade × impacto (baixo / médio / alto) e agir a partir do topo da lista. O resultado de uma sessão de modelagem de ameaças é uma tabela curta de ameaça → decisão → responsável, guardada junto com o documento de projeto e revisitada quando o projeto muda.

Defesa em profundidade

Nenhum controle é perfeito: regras de WAF têm lacunas, tokens são roubados, uma biblioteca sai com um bug de execução remota de código. Defesa em profundidade empilha camadas independentes, de modo que um atacante que vence uma ainda enfrenta a próxima. As camadas do BoxOffice, de fora para dentro:

flowchart LR
    U(["Cliente"]) -->|"1 · TLS, WAF, rate limit"| GW["API gateway"]
    GW -->|"2 · valida token (OAuth/OIDC)"| O["order"]
    O -->|"3 · verifica dono (authZ)"| O
    O -->|"4 · mTLS + política do mesh"| P["payment"]
    P -->|"5 · sub-rede + security group"| DB[("PostgreSQL")]
    P -->|"6 · segredo de vida curta"| PSP["PSP"]

As camadas são independentes: o security group do banco não se importa se o token era válido, e a política do mesh não se importa se o WAF foi contornado. Essa independência é o ponto.

OWASP API Security Top 10 (2023)

A OWASP (Open Worldwide Application Security Project) publica uma lista dos riscos mais críticos de APIs³. É a melhor checklist para levar a uma revisão de projeto, porque quase todo item é uma decisão de arquitetura, não um erro de digitação. Aplicada ao BoxOffice:

Experimente. Abra o cenário flash-sale e aperte Run: observe como a rajada da abertura da venda (t = 60 s, as nossas 10:00) satura o app e depois o inventory-db. Agora selecione users, ajuste o tráfego de bots para 0,45 — os bots passam a ser cerca de 30% das requisições (API6) — e rode de novo. Qual componente você adicionaria primeiro, e onde — WAF na borda, rate limiting no gateway ou a fila da sala de espera? Use o playground completo (↗) para adicionar os componentes e comparar o p99 e a taxa de erros (as metas contam só usuários reais).

O mapa de conceitos de rede e segurança

Segurança não é uma caixa no diagrama: cada salto de uma requisição responde a uma pergunta de confiança diferente. O mapa liga cada componente da paleta (verde) aos conceitos que ele aplica (azul) e à subpágina que os ensina; os nós azuis são as camadas da defesa em profundidade:

flowchart LR
    client["client · mobile"]:::comp -->|"login"| auth["auth"]:::comp
    client --> waf["waf"]:::comp
    waf --> apigw["apigw"]:::comp
    apigw --> mesh["mesh<br/>(order, payment, …)"]:::comp
    mesh -->|"saída via nat"| pay["payment (PSP)"]:::comp
    vpc["vpc · subnet ·<br/>nat · vpn"]:::comp -.->|"contém"| mesh
    waf -.- c1["bots, rate limits,<br/>OWASP API4 / API6"]:::tech
    auth -.- c2["OAuth 2.1 + PKCE, OIDC,<br/>RBAC / ABAC / ReBAC"]:::tech
    apigw -.- c3["validação de JWT (JWKS),<br/>remover headers de identidade"]:::tech
    mesh -.- c4["mTLS, identidade SPIFFE,<br/>política de authz, NetworkPolicy"]:::tech
    vpc -.- c5["plano de CIDR, sub-redes públicas /<br/>privadas / isoladas, SGs"]:::tech
    pay -.- c6["gerenciador de segredos,<br/>rotação com duas chaves"]:::tech
    c4 -.- d1["Zero Trust: suponha a invasão,<br/>negar por padrão"]
    c1 -.- d2["STRIDE, OWASP API Top 10<br/>(esta visão geral)"]
    classDef comp fill:#1e9e5a22,stroke:#1e9e5a
    classDef tech fill:#2f6fed22,stroke:#2f6fed

Relacionados

• Componentes no catálogo: VPC, Subnet, NAT Gateway, VPN, Service Mesh; além de Auth Service e WAF.
• Aulas: Tráfego e borda (WAF, API gateway, rate limiting), Cloud-native (Kubernetes, CI/CD), Observabilidade (trilhas de auditoria, alertas de segurança).
• Hands-on: 4 — Gateway e identidade, 10 — Kubernetes, 11 — Entrega (varredura de imagens, SBOM, proveniência assinada).
• Estudo de caso: Sistema de pagamentos. Exercício: Design doc. Projeto: projeto em equipe.

Pontos-chave

O que quebra em seguida

Todo chamador desta aula é uma pessoa ou um serviço que nós escrevemos: o fã com um token, o order com uma identidade de workload, o pipeline com uma proveniência assinada. O próximo chamador não é nenhum dos dois. Os fãs querem pedir "dois lugares abaixo de R$ 300 no sábado, reserve", e um assistente responde chamando catalog e inventory por eles: uma dependência lenta, cara e não determinística que pode agir sobre o estoque, em nome do fã, e que pode ser convencida a fazer a coisa errada pelo texto que lê. Projetar um sistema em torno de um modelo — e decidir o que ele pode tocar — é a aula 13 — Sistemas de IA.