Zero Trust, Segredos e Cadeia de Suprimentos

Uma biblioteca vulnerável de processamento de imagens permite que um atacante execute código dentro de um pod search. Agora repita o filme na configuração padrão. Desse pod, o atacante chama order com o cabeçalho X-Account-Id: acc-42 e lê os pedidos da Ana, porque "só o gateway alcança order". Ele lê as variáveis de ambiente e encontra DATABASE_URL com a única senha que todos os serviços compartilham. Encontra PSP_API_KEY, porque a chave de pagamento foi colocada em um ConfigMap "temporariamente". Abre uma conexão com https://attacker.example e envia tudo, porque a sub-rede privada tem uma rota para o NAT e nada restringe a saída. Cada passo foi possível porque algo confiou na rede.

Esta página trata da arquitetura que remove essa confiança — Zero Trust — e de dois lugares onde a confiança se esconde em todo sistema: os segredos e a cadeia de suprimentos de software.

Do perímetro ao Zero Trust

O modelo de perímetro ("castelo e fosso") protege a borda — firewall, VPN — e confia em tudo o que está dentro. Quando um atacante entra, por um laptop roubado, uma senha capturada por phishing ou uma dependência vulnerável, ele passa de máquina em máquina: movimento lateral.

O Zero Trust remove a ideia de rede confiável. O lema é "nunca confie, sempre verifique": toda requisição — da Internet, do escritório, do pod ao lado — é autenticada, autorizada e criptografada por si só¹. O Google construiu a sua rede corporativa assim no projeto BeyondCorp, a partir de 2011²; o NIST padronizou a arquitetura na SP 800-207¹.

flowchart LR
    subgraph perimeter ["Modelo de perímetro"]
        fw["Firewall / VPN"] -->|"dentro = confiável"| int["search, order, payment, banco<br/>(confiam uns nos outros)"]
    end
    subgraph zt ["Modelo Zero Trust"]
        any["Qualquer requisição<br/>(usuário ou workload)"] -->|"identidade + contexto"| pep["Policy Enforcement Point<br/>(gateway, proxy do mesh)"]
        pep -->|"pergunta"| pdp["Policy Decision Point<br/>(políticas, identidade, dispositivo, risco)"]
        pdp -->|"permite, menor privilégio"| res["Recurso"]
        pdp -->|"nega"| rej["Rejeitada + registrada"]
    end

O NIST dá nome às peças: um Policy Enforcement Point (PEP) fica no caminho de toda requisição e a bloqueia ou encaminha; um Policy Decision Point (PDP) decide a partir da identidade e do contexto. No BoxOffice, o API gateway é o PEP para usuários, e o proxy do mesh ao lado de cada serviço é o PEP para workloads (Service mesh).

Princípios

O pod search comprometido, de novo

O ataque ainda começou — o Zero Trust não impede o primeiro comprometimento. Ele faz do pod comprometido um beco sem saída.

Identidade de workload: chega de chaves de vida longa

O Zero Trust exige que todo workload tenha uma identidade que consiga provar sem um segredo estático. Três formas comuns:

A terceira é uma mudança pequena com grande efeito: o GitHub Actions consegue pedir um token OIDC que diz "sou o workflow release.yaml deste repositório, no branch main", e a nuvem confia nessa afirmação para um papel válido só durante o job³:

permissions:
  contents: read
  id-token: write          # allow the job to request an OIDC token
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/boxoffice-deploy
          aws-region: sa-east-1
      - run: aws eks update-kubeconfig --name boxoffice-prod

Nenhuma chave da AWS fica guardada no GitHub; a política de confiança do papel aceita só tokens cujo sub case com repo:<org>/<repo>:ref:refs/heads/main. Um fork do repositório ou outro branch não consegue assumi-lo.

Gestão de segredos

Um segredo é qualquer valor que concede acesso: a chave de API do provedor de pagamentos, senhas de banco, a chave de assinatura do provedor de identidade, segredos HMAC de webhooks, tokens de registry. Segredos não devem viver onde as coisas são copiadas, versionadas ou registradas em log: código-fonte, imagens de container, ConfigMaps comuns, logs de CI.

kubectl get secret psp-api-key -n boxoffice -o jsonpath='{.data.PSP_API_KEY}' | base64 -d

Onde os segredos devem morar

O External Secrets Operator (ESO) liga os dois mundos: a fonte da verdade é o gerenciador de segredos; o ESO sincroniza os valores em Secrets nativos que os pods leem como sempre.

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: psp-api-key
  namespace: boxoffice
spec:
  refreshInterval: 1h
  secretStoreRef:
    kind: ClusterSecretStore
    name: aws-secrets-manager
  target:
    name: psp-api-key            # Kubernetes Secret created and kept in sync by ESO
  data:
    - secretKey: PSP_API_KEY
      remoteRef:
        key: prod/boxoffice/payment/psp-api-key

A vida da chave da API de pagamentos

O provedor de pagamentos permite que um lojista tenha duas chaves ativas ao mesmo tempo — o truque padrão para rotacionar sem indisponibilidade. O ciclo de vida do segredo mais valioso do BoxOffice:

sequenceDiagram
    autonumber
    actor Ops as Plantão de pagamentos
    participant PSP as Provedor de pagamentos
    participant SM as Secrets Manager
    participant ESO as External Secrets Operator
    participant K8s as Secret psp-api-key
    participant Pay as pods de payment
    Ops->>PSP: cria a chave 2 (chave 1 ainda ativa)
    Ops->>SM: grava a chave 2 como nova versão de prod/boxoffice/payment/psp-api-key
    ESO->>SM: atualiza (a cada 1 h, ou forçado)
    SM-->>ESO: versão 2
    ESO->>K8s: atualiza o Secret
    K8s-->>Pay: arquivo montado muda → app recarrega (ou rolling restart)
    Pay->>PSP: cobranças agora assinadas com a chave 2
    Ops->>Ops: confirma nas métricas: zero chamadas com a chave 1 por 24 h
    Ops->>PSP: revoga a chave 1

Repare no que o projeto oferece: só a service account de payment pode ler esse segredo (IAM); toda leitura fica no log de auditoria; a chave nunca aparece no Git, em imagens ou em logs de CI; e, se ela vazar, o mesmo procedimento roda em minutos, não em dias.

Segredos dinâmicos

Melhor ainda que rotacionar um segredo compartilhado é não ter um. Segredos dinâmicos (o database engine do Vault, autenticação IAM em bancos da nuvem) criam uma credencial única e de vida curta para cada solicitante:

$ vault read database/creds/order
Key                Value
lease_id           database/creds/order/8sTt3lV0b2yL
lease_duration     1h
username           v-k8s-order-x7Qa2
password           A1a-4kd0s8f7GQpz

Cada pod de order recebe o seu próprio usuário de banco, que expira em uma hora. Uma credencial roubada de um pod para de funcionar sozinha, e os logs do banco mostram exatamente qual pod fez o quê.

Criptografia em repouso com envelope encryption

Bancos de dados, object storage e backups são criptografados em repouso com envelope encryption: cada objeto é criptografado com uma chave de dados; a chave de dados, por sua vez, é criptografada com uma chave de criptografia de chaves que nunca sai de um KMS (Key Management Service) ou HSM (hardware security module).

flowchart LR
    D["dados de order"] -->|"AES-256-GCM com a chave de dados"| E["texto cifrado"]
    DK["chave de dados (em claro, só em memória)"] -->|"cifrada pela API do KMS"| EDK["chave de dados cifrada<br/>(guardada ao lado do texto cifrado)"]
    KMS["chave-mestra do KMS<br/>(nunca sai do KMS/HSM)"] -.-> EDK

Rotacionar ou revogar a chave-mestra no KMS controla o acesso a todos os dados sem recriptografar terabytes; toda chamada de decriptação é autorizada pelo IAM e registrada.

Mantenha segredos fora do Git

Faça a varredura antes que eles cheguem: um hook de pre-commit e um job de CI com um scanner de segredos (gitleaks, trufflehog, GitHub secret scanning com push protection) bloqueiam commits que parecem chaves. Se um segredo for versionado alguma vez, rotacione-o — apagar o commit não apaga clones, forks nem caches.

Segurança da cadeia de suprimentos

A imagem de order do BoxOffice contém algumas centenas de bibliotecas escritas por desconhecidos, construídas por um sistema de CI, guardadas em um registry e baixadas pelo cluster. Cada passo é um caminho de ataque: uma dependência maliciosa ou comprometida (o backdoor do xz-utils, em 2024), uma vulnerável (Log4Shell, 2021), um sistema de build comprometido (SolarWinds, 2020), typosquatting (spring-boot-strater) e dependency confusion (um pacote público com o nome do seu pacote interno). A segurança da cadeia de suprimentos responde a três perguntas: o que tem dentro?, está vulnerável?, veio do nosso pipeline, sem alterações?

flowchart LR
    src["Código<br/>(PR revisado)"] --> build["Build no CI<br/>(runner isolado)"]
    build --> sbom["SBOM<br/>(syft → CycloneDX)"]
    build --> scan["Varredura<br/>(trivy / grype)"]
    scan -->|"sem CVEs críticas"| sign["Assinatura + proveniência<br/>(cosign keyless, SLSA)"]
    sbom --> sign
    sign --> reg[("Registry<br/>imagem@sha256 + atestações")]
    reg --> adm{"Política de admissão<br/>(Kyverno)"}
    adm -->|"assinatura válida"| run["Pod roda"]
    adm -->|"sem assinatura / assinante errado"| deny["Rejeitado"]

O que tem dentro: o SBOM

Um SBOM (Software Bill of Materials) é a lista de ingredientes de um artefato: cada pacote, versão e licença, em um formato padrão — CycloneDX (OWASP) ou SPDX (Linux Foundation, ISO/IEC 5962)⁵. Quando o próximo Log4Shell for anunciado, a pergunta "quais das nossas imagens contêm esta versão?" vira uma consulta, e não uma semana de pânico.

Está vulnerável: varredura

Scanners (Trivy, Grype, Dependabot/Renovate para atualizações) cruzam o SBOM com bases de vulnerabilidades (identificadores CVE, advisories do GitHub). Bloqueie o pipeline com base em uma política — por exemplo, "nenhuma vulnerabilidade crítica com correção disponível" — e não em zero achados, o que nunca acontece.

Veio de nós: assinatura e proveniência

O cosign, do Sigstore, assina imagens de container. No modo keyless, o job de CI prova a sua identidade com o seu token OIDC, um certificado de vida curta é emitido pela CA do Sigstore (Fulcio) e a assinatura é registrada em um log público de transparência (Rekor) — nenhuma chave de assinatura de vida longa para proteger⁶. O SLSA (Supply-chain Levels for Software Artifacts) define níveis de integridade do build; a sua atestação de proveniência registra qual código, workflow e builder produziram o artefato⁷.

O job de release do BoxOffice, reduzido aos passos de segurança (instalação das ferramentas omitida):

permissions:
  contents: read
  packages: write
  id-token: write                      # keyless signing uses the job's OIDC identity
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - id: build
        uses: docker/build-push-action@v6
        with:
          push: true
          tags: registry.example.com/boxoffice/order:${{ github.sha }}
      - name: SBOM
        run: syft registry.example.com/boxoffice/order@${{ steps.build.outputs.digest }} -o cyclonedx-json > sbom.cdx.json
      - name: Scan (fail on fixable critical CVEs)
        run: trivy image --severity CRITICAL --ignore-unfixed --exit-code 1 registry.example.com/boxoffice/order@${{ steps.build.outputs.digest }}
      - name: Sign and attest
        run: |
          IMAGE=registry.example.com/boxoffice/order@${{ steps.build.outputs.digest }}
          cosign sign --yes "$IMAGE"
          cosign attest --yes --type cyclonedx --predicate sbom.cdx.json "$IMAGE"

permissions:
  contents: read
  packages: write          # push to ghcr.io
  id-token: write          # keyless signing of the attestations (Sigstore)
  attestations: write      # store the provenance and SBOM attestations
  security-events: write   # upload the Trivy report to the Security tab
  - name: Gate - no CRITICAL vulnerability that has a fix
    uses: aquasecurity/trivy-action@ed142fd0673e97e23eac54620cfb913e5ce36c25 # v0.36.0
    with:
      image-ref: boxoffice-${{ matrix.service }}:ci
      format: table
      severity: CRITICAL
      ignore-unfixed: true
      exit-code: "1"
  - name: Attest build provenance (who built it, from which commit, how)
    uses: actions/attest-build-provenance@4d101475d8b20a2381f78447822ac1eab6504dd8 # v4.2.2
    with:
      subject-name: ${{ env.IMAGE }}
      subject-digest: ${{ steps.push.outputs.digest }}
      push-to-registry: true
  - name: Attest the SBOM
    uses: actions/attest-sbom@c604332985a26aa8cf1bdc465b92731239ec6b9e # v4.1.0
    with:
      subject-name: ${{ env.IMAGE }}
      subject-digest: ${{ steps.push.outputs.digest }}
      sbom-path: sbom.spdx.json
      push-to-registry: true

O último elo é a verificação no momento do deploy. Um admission controller (Kyverno, Sigstore policy-controller, OPA Gatekeeper) rejeita qualquer pod cuja imagem não tenha sido assinada pelo nosso workflow de release:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-boxoffice-images
spec:
  validationFailureAction: Enforce
  rules:
    - name: signed-by-release-workflow
      match:
        any:
          - resources:
              kinds: ["Pod"]
              namespaces: ["boxoffice"]
      verifyImages:
        - imageReferences: ["registry.example.com/boxoffice/*"]
          mutateDigest: true             # pin the tag to the verified digest
          attestors:
            - entries:
                - keyless:
                    issuer: "https://token.actions.githubusercontent.com"
                    subject: "https://github.com/repo-classes/pma271/.github/workflows/release.yaml@refs/heads/main"

Outros hábitos que fecham lacunas comuns: fixar por digest (image@sha256:…, actions pelo SHA do commit), usar imagens base mínimas ou distroless, rodar containers sem root e com sistema de arquivos somente leitura, usar um proxy de pacotes privado com nomes escopados para evitar dependency confusion, e seguir o Secure Software Development Framework (SSDF) do NIST como checklist do processo⁸.

Experimente. Abra o cenário ai-assistant. O assistente chama ferramentas (catalog, order) em nome do usuário: liste cada identidade no caminho (usuário, assistente, registro de ferramentas, serviços) e o que cada uma deveria poder fazer. Onde você colocaria o PEP de uma chamada de ferramenta? Quais segredos o LLM gateway guarda? (A aula de Sistemas de IA aprofunda o safety mesh.)

Uma checklist de defesa para o BoxOffice

Como se conecta

flowchart LR
    PER["modelo de perímetro:<br/>dentro = confiável"] -->|"substituído por"| ZT["Zero Trust:<br/>nunca confie, sempre verifique"]
    ZT --> PEP["PEP: gateway para usuários,<br/>proxy do mesh para workloads"]
    PEP --> MESH["mTLS + política de autorização<br/>→ Service mesh"]
    ZT --> WI["identidade de workload:<br/>SPIFFE, papéis na nuvem, OIDC do CI"]
    WI --> SEC["gerenciador de segredos, segredos<br/>dinâmicos, rotação com duas chaves"]
    SEC --> KMS["envelope encryption<br/>com um KMS"]
    ZT --> SC["cadeia de suprimentos: SBOM,<br/>scan, cosign, SLSA"]
    SC --> ADM["política de admissão no deploy<br/>→ Cloud-native"]
    ZT --> DET["chamadas negadas registradas e alertadas<br/>→ Observabilidade"]
    DET --> IR["runbook de chave vazada<br/>→ resposta a incidentes"]

Componentes da paleta: apigw e mesh (os pontos de aplicação) · payment (a chave que só o payment pode ler) · logs · alerting (auditoria e alertas de chamadas negadas) · llmgw · toolreg (identidades nas chamadas de ferramentas de um agente). Cenários: ai-assistant, payment-system. Continua em: Service mesh, Identidade, Cloud-native — entrega, Observabilidade — resposta a incidentes, Sistemas de IA — segurança e avaliações, Hands-on 11 — cadeia de suprimentos, Hands-on 13 — segurança.

Pontos-chave