ZTP-prem — guia do operador¶
Outros idiomas: English · Português · Español
Audiência: operador do bench + auditor de segurança do cliente rodando TLSStress.Art em um DC Fortune-500 sob a postura Zero-Trust-on-Premises de 12 camadas. Este é o guia prático day-2 — para a decisão arquitetural ver SECURITY_ZTP_PREM.md e a família de ADRs ZTP-prem.
O que é ZTP-prem, em um parágrafo¶
O threat model não é o atacante externo — é o operador insider com shell root completo no bench (um sysadmin de DC, um escolta de auditor, um contratado interno). Doze camadas defendem contra esse adversário; cada uma é nomeada, auditada individualmente, e despachada atrás de uma classificação verificável Tier A (aberta, auditável pelo cliente) ou Tier B (moat-closed, ofuscada por garble). Ver ADR 0026 para o umbrella.
As 12 camadas em visão rápida¶
| # | Camada | O que faz | Touchpoint do cliente |
|---|---|---|---|
| 1 | Custódia de chave em Cloud HSM | Bench nunca guarda chaves de assinatura | Verificar em ADR 0027 |
| 2 | Detecção de Confidential Computing | Mostra prontidão CC por nó | Dashboard /admin/ztp-prem |
| 3 | Probe TPM 2.0 measured-boot | Detecta surface TPM por nó | Dashboard /admin/ztp-prem |
| 4 | Partição de código Tier A/B | A auditável; B moat-closed | platform/ztp-prem/tier-policy.yaml |
| 5 | Webhook de admission K8s | Classifica + audita cada Pod | Dashboard "Admission audit" |
| 6 | Sealed audit hash-chain | Histórico WORM tamper-evident | Dashboard "Sealed audit" |
| 7 | Bridge de cross-correlation | Admission ↔ audit alinhados | Dashboard "Correlation alerts" |
| 8 | Vault UTXO de tokens | Modelo nota-não-saldo de licença | Dashboard "Licence vault" |
| 9 | Envelope MÓDULO LICENSE.Art | Envelope de licença assinado, verificável offline | Dashboard "Licence card" |
| 10 | Scaffold de release de chave selada | (v6.0+) Unseal de chave ancorado em PCR TPM | Planejado |
| 11 | Monitor DLP de egress | Wrapper tracked-fetch, 5 regras baseline | Dashboard "DLP card" |
| 12 | Detector comportamental de anomalia | 4 detectores rule-based | Dashboard "Anomaly card" |
Checklist operacional day-2 (semanal)¶
# 1. Verificar integridade do sealed audit chain
kubectl exec -n web-agents deploy/dashboard -- \
node /app/scripts/verify-sealed-audit.mjs --since=7d
# 2. Revisar denials do admission audit + uso de break-glass
kubectl exec -n web-agents deploy/dashboard -- \
node /app/scripts/admission-audit-summary.mjs --since=7d
# 3. Confirmar que cross-correlation não tem drift > 30s
kubectl exec -n web-agents deploy/dashboard -- \
node /app/scripts/correlation-drift.mjs --since=7d
# 4. Inspecionar eventos do DLP de egress
kubectl exec -n web-agents deploy/dashboard -- \
node /app/scripts/dlp-events.mjs --since=7d --rule=any
# 5. Ler relatório do detector comportamental de anomalia
kubectl exec -n web-agents deploy/dashboard -- \
node /app/scripts/anomaly-report.mjs --since=7d
Cada script retorna um documento JSON estruturado que o bench
arquiva no sealed audit log sob a classe de evento
ops-checklist.
Camada 1 + 9 — rotação do envelope de licença¶
# Cloud-side (operador do HSM)
./pkg/ztp-prem-signctl/cmd/ztp-signctl/ztp-signctl sign \
--key=keys/isk.pem \
--in=envelope-2026-Q3.json \
--out=envelope-2026-Q3.signed.json
# Entregar o envelope assinado ao operador do bench em mão (canal
# out-of-band, p.ex. pen drive criptografado). No bench, soltar em:
# volume do dashboard:/data/license/incoming/
# O dashboard ingere automaticamente no próximo sync do vault.
O contrato de assinatura cross-language (ADR 0027) é byte-estável — se o verifier do bench rejeitar o envelope, a causa mais comum é edição manual do JSON em trânsito. Regerar a partir do source; não editar à mão.
Camada 4 — auditoria da partição Tier A/B¶
# Auditor do cliente reproduz a partição localmente:
cat platform/ztp-prem/tier-policy.yaml
# Verificar que o CI recebeu a mesma policy para a release v3.7.0:
gh release view v3.7.0 --json assets -q '.assets[] | select(.name=="tier-policy.yaml.sha256")'
# Bate o hash: o SHA-256 do tier-policy.yaml local tem que casar com
# o asset da release.
Binários Tier B são ofuscados por garble no CI, não por
wrapper pós-build. O SBOM da release lista garble como parte da
toolchain string — auditor confirma em
platform/ztp-prem/TIER-B-OBFUSCATION.md.
Camada 5 — modos do webhook de admission K8s¶
| Modo | Quando usar | Efeito |
|---|---|---|
audit (default) |
Day-one + durante coleta de baseline | Toda admission classificada + registrada; sempre Allow |
enforce |
Produção em regime | Tier faltando/inválido → Deny |
break-glass (label por pod) |
Resposta a incidente ou inspeção de auditor | Allow sob enforce; ticket ID gravado no audit |
Flip de audit para enforce:
kubectl set env -n web-agents deploy/ztp-prem-admission \
ZTP_PREM_ADMISSION_MODE=enforce
# Observar o ring buffer do audit em busca de novos denials:
curl -sH "Authorization: Bearer $AUDIT_TOKEN" \
https://admission.tlsstress.art/audit | jq '.[-20:]'
O manifesto K8s em k8s/ztp-prem/admission-webhook.yaml embute
um guia de rollout canary em 4 passos (single-replica audit →
multi-replica audit → single-replica enforce → enforce completo).
Usar no primeiro rollout em produção.
Camadas 6 + 7 — verificando tamper-evidence¶
# Sealed audit log: verificação do hash-chain
node /app/scripts/verify-sealed-audit.mjs --full
# Cross-correlation: decisões de admission ↔ sealed audit
node /app/scripts/correlation-drift.mjs --full
Um break do chain nunca é auto-corrigido. O verifier retorna:
- Número de sequence onde o chain quebrou
- Hash que não bateu com o
prev_hashda entrada seguinte - Timestamp da entrada quebrada
Tratar como incidente — possível tampering por insider ou corrupção de storage. Capturar o estado do bench + escalar pelo playbook de resposta a incidente do cliente.
Camada 11 — baseline de regras DLP¶
O wrapper DLP entrega 5 regras baseline que pegam o material sensível do próprio projeto:
- Material de certificado / chave em formato PEM
- Tokens K8s ServiceAccount
- Material TLS dos webservers persona
- Fragmentos do sealed audit hash-chain
- Fingerprints da ISK do Cloud HSM
Para adicionar uma regra específica do cliente (p.ex. "bloquear
exfil de qualquer URL casando *.cliente-interno.com"):
# config do dashboard:/data/dlp/customer-rules.yaml
- name: customer-internal-domain
pattern: '\.cliente-interno\.com'
action: record-and-alert # NÃO adicione 'block' ainda — observe-only em v3.7.0
DLP roda em modo observe-only em v3.7.0 (registra + alerta, não bloqueia). Block-mode é planejado para v6.0+ depois que as baselines de falso-positivo estabilizarem.
Camada 12 — tuning do detector de anomalia¶
Os 4 detectores embarcam com defaults apropriados para uma workload Fortune-500 de dia útil:
| Detector | Threshold default | Onde tunar |
|---|---|---|
| Denial-flood | >50 denials/min sustentados 5min | dashboard:/data/anomaly/denial-flood.yaml |
| Break-glass-burst | >3 usos/hora | dashboard:/data/anomaly/break-glass.yaml |
| Tier-B-ratio-spike | >2σ acima da baseline 14d | auto-tunado (read-only) |
| Off-hours-activity | fora de 08:00-19:00 TZ do cliente | dashboard:/data/anomaly/business-hours.yaml |
Cada detector emite um evento nomeado no sealed audit log ao disparar, então a detecção em si é auditável.
Camadas 2 + 3 — prontidão CC e TPM¶
kubectl get configmap -n web-agents -l ztp-prem.tlsstress.art/probe=detect
kubectl get configmap -n web-agents -l ztp-prem.tlsstress.art/probe=tpm
Cada ConfigMap por nó carrega o doc JSON de status mais recente
da respectiva probe. Dashboard /admin/ztp-prem renderiza
cobertura fleet-wide.
Postura em v3.7.0: as probes são informativas — workloads são escalonadas independentemente da presença de CC / TPM. v6.0+ flipa as duas para mandatórias: Pods Tier B vão se recusar a escalonar em nós não-CC, e o sealed audit log ganha um anchor measured-boot PCR.
Auditoria de compliance — o que entregar para o auditor¶
platform/ztp-prem/tier-policy.yaml— fonte da partiçãoplatform/ztp-prem/TIER-B-OBFUSCATION.md— política do garble- ADRs 0026..0033 — decisões de design
- Saída dos 5 scripts do checklist semanal (últimos 90 dias)
- O manifesto release-feed da versão em execução
- O SBOM + assinatura Cosign de cada container em execução
Para mapeamento SOC 2 / ISO 27001 / LGPD / GDPR / NIST 800-53, ver
docs/COMPLIANCE_FRAMEWORK_MAPPINGS.md.
Perguntas comuns¶
"Posso desabilitar o ZTP-prem para simplificar uma demo?"
Pode colocar o admission webhook em modo audit (default) —
isso classifica + registra mas nunca bloqueia. Não pode
desabilitar o sealed audit chain nem a partição Tier A/B — essas
são propriedades de build-time, não toggles de runtime.
"E se o Cloud HSM estiver indisponível quando eu precisar mintar uma licença?" O bench roda offline indefinidamente sobre as notas já mintadas (modelo UTXO, ADR 0033). Material novo de licença exige um evento de assinatura no Cloud HSM. Para deploys air-gap recomendamos pré-mintar um batch de notas cobrindo os próximos 12 meses.
"Por que o moat está em Tier B se o cliente pode kubectl
exec no container?"
kubectl exec revela o binário, não o source. O pass de garble
no CI ofusca o binário — nomes de função, fluxo de controle e
constantes ficam mangled. O cliente pode rodar + auditar o
binário; não consegue facilmente recompilar uma versão
modificada.
Relacionados¶
- SECURITY_ZTP_PREM.md — postura arquitetural
- ADR 0026 — decisão umbrella
platform/ztp-prem/— tier policy + docs de custódiapkg/ztp-prem-*/— READMEs dos módulos em produção
Última verificação contra o código de produção: v3.7.0 (2026-05-12).