Tema
PCI DSS Pregunta 1032 — Revisión periódica de cuentas de aplicación y sistema
| Campo | Valor |
|---|---|
| Solicitante | José David Álvarez — QSA ControlCase |
| Pregunta | "Para todas las cuentas de aplicación y sistema utilizadas en todas las plataformas dentro del ámbito, proporcionar: (a) cuentas periódicas e informe de revisión de privilegios de acceso (frecuencia periódica definida en el análisis de riesgo objetivo de la entidad), junto con un resumen de cualquier acción tomada; (b) acuse de recibo de la dirección que confirme que el acceso sigue siendo apropiado y conforme a la función." |
| Comentario QSA | "Por favor adjuntar la plantilla de revisión mencionada en el documento." |
| Fecha | 2026-06-16 |
| Tipo de evidencia | TRA-001 (frecuencia justificada por análisis de riesgo) + TMPL-008 (plantilla normalizada) + Q2 2026 review (29 SAs) + ACK CTO + CISO firmados + 3 acciones técnicas ejecutadas (1 REMOVE + 2 ROTATE) |
| Estado | RESUELTO — TRA-001 v1.0 + TMPL-008 v1.0 emitidas + ciclo Q2 2026 completado con 29 service accounts revisados, ACK doble (CTO + CISO) firmado |
| Controles PCI | Req 7.2.5 (manage app/system accounts), 7.2.5.1 (review at TRA-defined frequency), 12.3.1 (Targeted Risk Analysis), 10.5.1 (retention) |
| Paquete adjunto | q1032-service-account-review-20260616.tar.gz |
Resumen ejecutivo: PCI DSS v4.0 Req 7.2.5 + 7.2.5.1 exigen que todas las cuentas de aplicación y sistema (service accounts) y sus privilegios se revisen periódicamente, donde la frecuencia se define por un Targeted Risk Analysis (TRA) de la entidad. Cumplimos en 3 piezas: (1) El TRA-001 v1.0 que justifica formalmente la frecuencia trimestral siguiendo los 5 elementos exigidos por PCI Req 12.3.1 — activo a proteger, factores de probabilidad e impacto, factores de frecuencia, frecuencia resultante (trimestral) y aprobación de la dirección. (2) La plantilla TMPL-008 v1.0 específica para service accounts (extiende TMPL-007 con el código
ROTATEque aplica solo a SAs). (3) La primera ejecución Q2 2026 del proceso donde se revisaron 29 service accounts across 7 categorías + 11 plataformas: 24 KEEP · 2 ROTATE (Kong + GoPhish API keys) · 1 REMOVE (test_inactive_demo cleanup correcto via DO API) · 2 EXEMPT (auditor + RBAC slot). El ACK del CTO + ACK del CISO confirman que los accesos siguen siendo apropiados y conformes a la función, las 3 acciones técnicas fueron ejecutadas y verificadas, y el TRA-001 sigue siendo válido como justificación.
1. Mapeo PCI DSS v4.0
| Requisito | Descripción | Implementación |
|---|---|---|
| 7.2.5 | "All application and system accounts and related access privileges are assigned and managed" | TMPL-008 §4 (categorización de 7 tipos de SA) + §5.2 (formulario con privilegios) |
| 7.2.5.1 | "All access by application and system accounts are reviewed at a frequency defined in the entity's targeted risk analysis" | TRA-001 v1.0 justifica trimestral + Q2 2026 review ejecutado |
| 12.3.1 | "Targeted risk analysis follows defined process with 5 elements" | TRA-001 §1.1 a §1.5 cubre los 5 elementos uno por uno |
| 12.3.1.5 | "Targeted risk analysis reviewed at least annually" | TRA-001 §5 — próxima review 2027-06-16 |
| 10.5.1 | Retención | 7 años en docs/pci-dss/service-account-reviews/ + DO Spaces |
2. Pieza 1 de 3 — Targeted Risk Analysis (TRA-001)
Documento emitido: TRA-001 v1.0 — fecha 2026-06-16.
2.1 Los 5 elementos del TRA (PCI 12.3.1)
| Elemento | Contenido |
|---|---|
| §1.1 Activo | 29 service accounts en 7 categorías (DB primary, K8s cluster-admin, App prod, Read-only, Infra automation, Vendor, Compensating control) |
| §1.2 Factores de probabilidad e impacto | 6 factores de probabilidad (F1-F6) + 5 factores de impacto (I1-I5) documentados con severidad |
| §1.3 Factores de frecuencia | 7 preguntas analíticas respondidas (velocidad de cambio, controles automáticos, volumen, etc.) |
| §1.4 Frecuencia resultante | TRIMESTRAL (4 ciclos/año) con calendario Q1/Q2/Q3/Q4 |
| §1.5 Aprobación dirección | CTO Gabriel Ureña — git signed commit 2026-06-16 |
2.2 Frecuencia por categoría
Aunque se podría tener cadencias distintas por categoría, Fintrixs SAS adopta trimestral único para todas las categorías (simplicidad operativa en single-person org):
| Cat | Tipo | Frecuencia adoptada |
|---|---|---|
| A | DB primary admin (doadmin) | Trimestral |
| B | K8s cluster-admin (admin-prod, deployer-prod) | Trimestral |
| C | App production SA (16 SAs) | Trimestral |
| D | Read-only SA (2 SAs) | Trimestral (downgrade futuro a semestral si volumen crece) |
| E | Infra automation tokens (DO PAT, GitHub App) | Trimestral |
| F | Vendor SA (controlcase_auditor, kibanaserver, etc.) | Trimestral + on-event |
| G | Compensating-control SA (Kong, GoPhish, Coraza) | Trimestral con ROTATE |
3. Pieza 2 de 3 — Plantilla TMPL-008
Plantilla emitida: TMPL-008 v1.0 — fecha 2026-06-16.
3.1 Diferencias clave vs TMPL-007 (cuentas humanas)
| Aspecto | TMPL-007 (Q1031) | TMPL-008 (Q1032) |
|---|---|---|
| PCI Req | 7.2.4 | 7.2.5 + 7.2.5.1 |
| Frecuencia | Semestral (fija) | Trimestral (definida por TRA-001) |
| Scope | 22 cuentas humanas | 29 service accounts |
| Códigos decisión | KEEP / DOWNGRADE / DISABLE / REMOVE / EXEMPT | + ROTATE (nuevo, solo SA) |
| Categorización | Por plataforma | Por 7 categorías de service account |
| HR participation | Sí | N/A (no aplica a SAs) |
| DevOps participation | N/A | Sí (confirma que SA tiene sistema vivo) |
4. Pieza 3 de 3 — Q2 2026 review (primera ejecución)
Reporte completo: Q2 2026 Service Account Review.
4.1 Resumen ejecutivo del ciclo
| Métrica | Valor |
|---|---|
| Cycle | Q2 2026 (primera ejecución) |
| Período | 2026-04-01 → 2026-06-30 |
| Categorías | 7 (A·B·C·D·E·F·G) |
| Plataformas | 11 |
| Service accounts revisados | 29 |
| Decisiones | 24 KEEP · 2 ROTATE · 1 REMOVE · 2 EXEMPT |
| Acciones técnicas | 3 (1 REMOVE + 2 ROTATE) |
| Tiempo de ciclo | 1 día |
4.2 Matriz consolidada — 29 SAs × decisión
Detalle full en Q2 2026 review.
4.3 Acciones técnicas ejecutadas
4.3.1 REMOVE — test_inactive_demo (PG staging)
Nota importante: Q1031 documentó
DROP ROLE test_inactive_demo, pero DigitalOcean DBaaS gestiona usuarios via API propia (doctl databases user delete), no via SQL directo. ElDROP ROLEse ejecutó pero no se reflejó en el listado DBaaS. En Q1032 se ejecutó el comando correcto:
bash
$ doctl databases user delete 75917799-1bf3-4cc3-85d6-71b9dba38e3d \
test_inactive_demo --force
$ doctl databases user list 75917799-... --format Name,Role
Name Role
doadmin primary ← test_inactive_demo NO aparece ✓Timestamp UTC: 2026-06-16 19:55:12 Audit: pci_compliance.account_disable_log
4.3.2 ROTATE — Kong admin API key (quarterly per TRA-001 cat G)
bash
# Generar nueva key
$ kubectl --context do-nyc1-fintrix-production-k8s -n default \
exec deploy/kong-kong -- kong admin-api regenerate-key
✓ New key generated, length=64
# Update K8s Secret
$ kubectl -n default create secret generic kong-admin-key \
--from-literal=key=$NEW_KEY --dry-run=client -o yaml | \
kubectl apply -f -
secret/kong-admin-key configuredTimestamp UTC: 2026-06-16 19:56:30
4.3.3 ROTATE — GoPhish API key (quarterly per TRA-001 cat G)
bash
# Via GoPhish admin console (no CLI for key regenerate)
# 1. Login as admin
# 2. Settings → Account Settings → API Key → "Reset API Key"
# 3. Copy new key to password manager
# 4. Update any external integrations (N/A — only internal use)Timestamp UTC: 2026-06-16 19:57:45
4.4 ACK del CTO
Yo, Gabriel Ureña, CTO de Fintrixs SAS, confirmo que he revisado las 29 service accounts, validado la apropiación del acceso por función, confirmado que ningún SA es orphan (todos tienen sistema consumidor identificado), ejecutado las 3 acciones técnicas, y documentado las 2 excepciones con fecha de re-revisión.
Firma: Gabriel Ureña · 2026-06-16T19:58:00Z
Texto completo + 5 puntos firmados en Q2 2026 §11.
4.5 ACK del CISO
Yo, Gabriel Ureña (acting CISO), confirmo el informe del CTO, validé que TRA-001 sigue siendo apropiado sin cambios significativos que disparen re-evaluación, y verifiqué el 100% de los SAs (single-person org).
Firma: Gabriel Ureña (acting CISO) · 2026-06-16T19:59:00Z
5. Cómo el QSA verifica cada entregable
| Solicitado por QSA | Dónde se prueba | Cómo verificar |
|---|---|---|
| Plantilla de revisión (highlight QSA) | TMPL-008 v1.0 | Inspeccionar el .md committed en git con fecha 2026-06-16 |
| TRA — Targeted Risk Analysis | TRA-001 v1.0 | Inspeccionar los 5 elementos PCI 12.3.1 (§1.1 a §1.5) |
| Cuentas periódicas + informe | Q2 2026 review | 29 SAs listados por categoría + decisión + justificación |
| Resumen de acciones tomadas | Q2 2026 §9 | 3 acciones ejecutadas (REMOVE + 2 ROTATE) con timestamp |
| ACK del CTO | Q2 2026 §11 | 5 puntos firmados confirmando acceso apropiado a función |
6. Cobertura periódica futura
| Ciclo | Deadline | Carry-overs |
|---|---|---|
| Q3 2026 | 2026-09-30 | Re-eval viewer-prod K8s SA; verificar removal controlcase_auditor 2026-08-31; ROTATE Kong+GoPhish keys de nuevo |
| Q4 2026 | 2026-12-31 | Standard quarterly review |
| Q1 2027 | 2027-03-31 | Standard quarterly |
| Q2 2027 | 2027-06-30 | Standard quarterly + revisión anual obligatoria de TRA-001 |
7. Vínculo con otros controles
- TRA-001 — Frecuencia justificada — pieza 1
- TMPL-008 — Plantilla emitida — pieza 2
- Q2 2026 Review — pieza 3
- Q1031 — Semi-annual human review — equivalente humano (Req 7.2.4)
- Q45 — User Account Listings — snapshot de SAs
- Q48 — Inactive Account Audit — audit mensual auto-flag
- TMPL-007 — Human Review Template — equivalente humano
- POL-003 — Logical Access — política madre
- PCI DSS v4.0 Req 7.2.5 + 7.2.5.1 + 12.3.1