ZTP-prem — guía del operador¶
Otros idiomas: English · Português · Español
Audiencia: operador del banco + auditor de seguridad del cliente corriendo TLSStress.Art en un DC Fortune-500 bajo la postura Zero-Trust-on-Premises de 12 capas. Esta es la guía práctica day-2 — para la decisión arquitectural ver SECURITY_ZTP_PREM.md y la familia de ADRs ZTP-prem.
Qué es ZTP-prem, en un párrafo¶
El threat model no es el atacante externo — es el operador insider con shell root completo en el banco (un sysadmin de DC, un escolta de auditor, un contratado interno). Doce capas defienden contra ese adversario; cada una está nombrada, auditada individualmente, y enviada detrás de una clasificación verificable Tier A (abierta, auditable por el cliente) o Tier B (moat-closed, ofuscada por garble). Ver ADR 0026 para el umbrella.
Las 12 capas en vista rápida¶
| # | Capa | Qué hace | Touchpoint del cliente |
|---|---|---|---|
| 1 | Custodia de clave en Cloud HSM | El banco nunca guarda claves de firma | Verificar en ADR 0027 |
| 2 | Detección de Confidential Computing | Muestra readiness CC por nodo | Dashboard /admin/ztp-prem |
| 3 | Probe TPM 2.0 measured-boot | Detecta surface TPM por nodo | Dashboard /admin/ztp-prem |
| 4 | Partición de código Tier A/B | A auditable; B moat-closed | platform/ztp-prem/tier-policy.yaml |
| 5 | Webhook de admission K8s | Clasifica + audita cada Pod | Dashboard "Admission audit" |
| 6 | Sealed audit hash-chain | Historial WORM tamper-evident | Dashboard "Sealed audit" |
| 7 | Bridge de cross-correlation | Admission ↔ audit alineados | Dashboard "Correlation alerts" |
| 8 | Vault UTXO de tokens | Modelo nota-no-saldo de licencia | Dashboard "Licence vault" |
| 9 | Envelope MÓDULO LICENSE.Art | Envelope de licencia firmado, verificable offline | Dashboard "Licence card" |
| 10 | Scaffold de release de clave sellada | (v6.0+) Unseal de clave anclado en PCR TPM | Planeado |
| 11 | Monitor DLP de egress | Wrapper tracked-fetch, 5 reglas baseline | Dashboard "DLP card" |
| 12 | Detector comportamental de anomalía | 4 detectores rule-based | Dashboard "Anomaly card" |
Checklist operativo day-2 (semanal)¶
# 1. Verificar integridad del sealed audit chain
kubectl exec -n web-agents deploy/dashboard -- \
node /app/scripts/verify-sealed-audit.mjs --since=7d
# 2. Revisar denials del 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 no tiene drift > 30s
kubectl exec -n web-agents deploy/dashboard -- \
node /app/scripts/correlation-drift.mjs --since=7d
# 4. Inspeccionar eventos del DLP de egress
kubectl exec -n web-agents deploy/dashboard -- \
node /app/scripts/dlp-events.mjs --since=7d --rule=any
# 5. Leer reporte del detector comportamental de anomalía
kubectl exec -n web-agents deploy/dashboard -- \
node /app/scripts/anomaly-report.mjs --since=7d
Cada script devuelve un documento JSON estructurado que el banco
archiva en el sealed audit log bajo la clase de evento
ops-checklist.
Capa 1 + 9 — rotación del envelope de licencia¶
# Cloud-side (operador del 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 el envelope firmado al operador del banco en mano
# (canal out-of-band, p.ej. USB cifrado). En el banco, dejar en:
# volumen del dashboard:/data/license/incoming/
# El dashboard lo ingiere automáticamente en el próximo sync del vault.
El contrato de firma cross-language (ADR 0027) es byte-estable — si el verifier del banco rechaza el envelope, la causa más común es edición manual del JSON en tránsito. Regenerar desde el source; no editar a mano.
Capa 4 — auditoría de la partición Tier A/B¶
# Auditor del cliente reproduce la partición localmente:
cat platform/ztp-prem/tier-policy.yaml
# Verificar que el CI recibió la misma policy para la release v3.7.0:
gh release view v3.7.0 --json assets -q '.assets[] | select(.name=="tier-policy.yaml.sha256")'
# Match del hash: el SHA-256 del tier-policy.yaml local debe coincidir
# con el asset de la release.
Los binarios Tier B están ofuscados por garble en el CI, no
por wrapper post-build. El SBOM de la release lista garble como
parte del toolchain string — el auditor confirma en
platform/ztp-prem/TIER-B-OBFUSCATION.md.
Capa 5 — modos del webhook de admission K8s¶
| Modo | Cuándo usar | Efecto |
|---|---|---|
audit (default) |
Day-one + durante recolección de baseline | Cada admission clasificada + registrada; siempre Allow |
enforce |
Producción en régimen | Tier faltante/inválido → Deny |
break-glass (label por pod) |
Respuesta a incidente o inspección de auditor | Allow bajo enforce; ticket ID grabado en audit |
Flip de audit a enforce:
kubectl set env -n web-agents deploy/ztp-prem-admission \
ZTP_PREM_ADMISSION_MODE=enforce
# Observar el ring buffer del audit buscando nuevos denials:
curl -sH "Authorization: Bearer $AUDIT_TOKEN" \
https://admission.tlsstress.art/audit | jq '.[-20:]'
El manifiesto K8s en k8s/ztp-prem/admission-webhook.yaml
embute una guía de rollout canary en 4 pasos (single-replica
audit → multi-replica audit → single-replica enforce → enforce
completo). Usar en el primer rollout en producción.
Capas 6 + 7 — verificando tamper-evidence¶
# Sealed audit log: verificación del hash-chain
node /app/scripts/verify-sealed-audit.mjs --full
# Cross-correlation: decisiones de admission ↔ sealed audit
node /app/scripts/correlation-drift.mjs --full
Un break del chain nunca se auto-corrige. El verifier devuelve:
- Número de sequence donde rompió el chain
- Hash que no coincidió con el
prev_hashde la siguiente entrada - Timestamp de la entrada rota
Tratar como incidente — posible tampering por insider o corrupción de storage. Capturar el estado del banco + escalar por el playbook de respuesta a incidente del cliente.
Capa 11 — baseline de reglas DLP¶
El wrapper DLP entrega 5 reglas baseline que detectan el material sensible del propio proyecto:
- Material de certificado / clave en formato PEM
- Tokens K8s ServiceAccount
- Material TLS de los webservers persona
- Fragmentos del sealed audit hash-chain
- Fingerprints de la ISK del Cloud HSM
Para agregar una regla específica del cliente (p.ej. "bloquear
exfil de cualquier URL coincidiendo *.cliente-interno.com"):
# config del dashboard:/data/dlp/customer-rules.yaml
- name: customer-internal-domain
pattern: '\.cliente-interno\.com'
action: record-and-alert # NO agregar 'block' todavía — observe-only en v3.7.0
DLP corre en modo observe-only en v3.7.0 (registra + alerta, no bloquea). Block-mode está planeado para v6.0+ después de que los baselines de falso-positivo se estabilicen.
Capa 12 — tuning del detector de anomalía¶
Los 4 detectores embarcan con defaults apropiados para una workload Fortune-500 de día hábil:
| Detector | Threshold default | Dónde tunear |
|---|---|---|
| Denial-flood | >50 denials/min sostenidos 5min | dashboard:/data/anomaly/denial-flood.yaml |
| Break-glass-burst | >3 usos/hora | dashboard:/data/anomaly/break-glass.yaml |
| Tier-B-ratio-spike | >2σ por encima de baseline 14d | auto-tuneado (read-only) |
| Off-hours-activity | fuera de 08:00-19:00 TZ del cliente | dashboard:/data/anomaly/business-hours.yaml |
Cada detector emite un evento nombrado en el sealed audit log al disparar, así que la detección en sí es auditable.
Capas 2 + 3 — readiness CC y 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 nodo carga el doc JSON de estado más reciente
de la respectiva probe. Dashboard /admin/ztp-prem renderiza
cobertura fleet-wide.
Postura en v3.7.0: las probes son informativas — workloads schedulean independientemente de la presencia de CC / TPM. v6.0+ flipa las dos a mandatorias: Pods Tier B se rehúsan a schedulear en nodos no-CC, y el sealed audit log gana un anchor measured-boot PCR.
Auditoría de compliance — qué entregar al auditor¶
platform/ztp-prem/tier-policy.yaml— fuente de la particiónplatform/ztp-prem/TIER-B-OBFUSCATION.md— política de garble- ADRs 0026..0033 — decisiones de diseño
- Salida de los 5 scripts del checklist semanal (últimos 90 días)
- El manifiesto release-feed de la versión corriendo
- El SBOM + firma Cosign de cada container corriendo
Para mapeo SOC 2 / ISO 27001 / LGPD / GDPR / NIST 800-53 ver
docs/COMPLIANCE_FRAMEWORK_MAPPINGS.md.
Preguntas comunes¶
"¿Puedo deshabilitar ZTP-prem para simplificar una demo?"
Podés poner el admission webhook en modo audit (default) — eso
clasifica + registra pero nunca bloquea. No podés deshabilitar el
sealed audit chain ni la partición Tier A/B — esas son
propiedades de build-time, no toggles de runtime.
"¿Y si el Cloud HSM no está disponible cuando necesito mintar una licencia?" El banco corre offline indefinidamente sobre las notas ya mintadas (modelo UTXO, ADR 0033). Material nuevo de licencia exige un evento de firma en el Cloud HSM. Para deploys air-gap recomendamos pre-mintar un batch de notas cubriendo los próximos 12 meses.
"¿Por qué el moat está en Tier B si el cliente puede kubectl
exec al container?"
kubectl exec revela el binario, no el source. El pass de garble
en el CI ofusca el binario — nombres de función, control flow y
constantes quedan mangled. El cliente puede correr + auditar el
binario; no puede recompilar fácilmente una versión modificada.
Relacionados¶
- SECURITY_ZTP_PREM.md — postura arquitectural
- ADR 0026 — decisión umbrella
platform/ztp-prem/— tier policy + docs de custodiapkg/ztp-prem-*/— READMEs de los módulos en producción
Última verificación contra el código de producción: v3.7.0 (2026-05-12).