Tema
TRA-001: Análisis de riesgo objetivo — Frecuencia de revisión de cuentas de aplicación y sistema
| Campo | Valor |
|---|---|
| ID | TRA-001 |
| Versión | 1.0 |
| Fecha de emisión | 2026-06-16 |
| Próxima revisión | 2027-06-16 (anual, PCI 12.3.1) |
| Propietario | CISO (acting: CTO Gabriel Ureña) |
| PCI DSS | Req 7.2.5.1 — "All access by application and system accounts and related access privileges are reviewed: at a frequency defined in the entity's targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1" |
| Vínculo con Req 12.3.1 | Sí — este TRA sigue los 5 elementos del análisis de riesgo dirigido |
Propósito: Determinar la frecuencia con la que Fintrixs SAS revisa las cuentas de aplicación y sistema (service accounts) y sus privilegios. Esta frecuencia es diferente a la revisión semestral de cuentas humanas (Req 7.2.4, cubierta por TMPL-007). PCI 7.2.5.1 exige que la frecuencia sea justificada por un Targeted Risk Analysis (TRA) y no por una regla fija.
1. Cumplimiento de los 5 elementos de PCI Req 12.3.1
PCI v4.0 Req 12.3.1 exige que todo TRA documente 5 elementos. Aquí los abordamos uno por uno.
1.1 Elemento 1 — Activo a proteger
Activo: Las cuentas de aplicación y sistema (service accounts) que tienen acceso al CDE (Cardholder Data Environment) o a sistemas que lo conectan/soportan.
Categorías de service accounts en alcance:
| Categoría | Ejemplos | # estimado | Privilegios |
|---|---|---|---|
| A — DB primary admin | doadmin (PG prod + staging) | 2 | Full DB superuser |
| B — K8s cluster-admin | admin-prod SA, deployer-prod SA | 2 | Cluster-wide write |
| C — App service accounts production | fintrix_app (PG), microservices JWT secrets | ~12 | Read/write production data |
| D — Read-only service accounts | fintrix_readonly, viewer-prod SA | 2 | Read-only access |
| E — Infra automation tokens | DO PAT, GitHub Apps token, Terraform runner | 3 | Infra provisioning |
| F — Vendor service accounts | controlcase_auditor, kibanaserver (Wazuh) | 4 | Scoped per vendor |
| G — Compensating-control accounts | Kong admin API key, GoPhish API, Wazuh wui | 4 | Compensating via IP allowlist |
Total estimado del scope: ~29 service accounts (sujeto al inventario oficial en TMPL-008).
1.2 Elemento 2 — Factores que contribuyen a la probabilidad y/o impacto del compromiso del activo
Factores de probabilidad de compromiso
| Factor | Severidad | Razonamiento |
|---|---|---|
| F1 — Service account credentials no rotan automáticamente | Alta | Si una credencial se compromete (commit accidental, leak), sigue siendo válida hasta que humano la rote |
| F2 — Service accounts son no-MFA por naturaleza | Media | Una contraseña/token robado da acceso inmediato sin segundo factor |
| F3 — Volumen de service accounts | Media | ~29 cuentas — mayor el inventario, mayor probabilidad de drift no detectado |
| F4 — Privilegios elevados concentrados en pocos service accounts | Alta | doadmin y admin-prod SA son single-point-of-compromise |
| F5 — Vendor accounts con TTL definido pueden quedar olvidados | Media | controlcase_auditor (QSA temporal) debe removerse el 2026-08-31 — riesgo de olvido |
| F6 — Microservicios con JWT secrets pueden retenerse tras retirar el servicio | Media | Microservicio decomisionado → secret aún válido si no se rotó |
Factores de impacto si se compromete
| Factor | Severidad | Razonamiento |
|---|---|---|
| I1 — Acceso a PANs almacenados | Crítica | fintrix_app puede tocar card_vault_service schema |
| I2 — Cambios irreversibles en DBaaS | Crítica | doadmin puede DROP TABLE / DELETE |
| I3 — Pivote a otros sistemas via service token | Alta | Token K8s admin → cualquier secret del cluster |
| I4 — Acción no-trazable de logs (si el service account no audita) | Alta | Requiere correlación con compensating controls |
| I5 — Cuentas vendor → atacante extorsiona al vendor | Baja | ControlCase tiene sus propios controles SOC2 |
1.3 Elemento 3 — Factores que contribuyen a la frecuencia de revisión
| Pregunta del TRA | Respuesta |
|---|---|
| ¿Con qué velocidad pueden cambiar los privilegios de un service account? | Días a semanas (CI/CD deploys, micro-services nuevas features) |
| ¿Con qué velocidad se descubren nuevos service accounts? | Continuo — cada microservicio nuevo añade ≥1 SA |
| ¿Existen controles automáticos? | Q48 audit mensual + Q45 listing snapshot (parcial cobertura) |
| ¿Cuánta gente toca el ciclo de vida del service account? | 1 humano (CTO) — riesgo de single-point-of-failure |
| ¿La frecuencia anual sería suficiente para detectar drift? | No — drift de >12 meses inaceptable |
| ¿La frecuencia semestral coincide con la review humana (Q1031)? | Sí — opción simple pero los SA son más volátiles |
| ¿La frecuencia trimestral añade valor proporcional al esfuerzo? | Sí — alinea con ciclos de release + reduce ventana de drift |
1.4 Elemento 4 — Frecuencia resultante (decisión)
Basado en los factores anteriores, Fintrixs SAS adopta una frecuencia escalonada por categoría de service account:
| Categoría | Frecuencia | Justificación |
|---|---|---|
| A (DB primary) | Trimestral | F2+F4+I2 → impacto crítico + no-MFA → 3 meses máximo |
| B (K8s cluster-admin) | Trimestral | F4+I3 → pivote completo del cluster |
| C (App production) | Trimestral | F1+I1 → acceso a PAN posible |
| D (Read-only) | Semestral | Bajo impacto si comprometido (solo SELECT) |
| E (Infra automation) | Trimestral | F1 → tokens persistentes con scope amplio |
| F (Vendor) | Trimestral + on-event | F5 → vendor accounts con TTL deben verificarse |
| G (Compensating control) | Trimestral | Compensating control debe re-validarse 4×/año |
Resumen: trimestral por defecto para 27 de 29 cuentas, semestral solo para las 2 cuentas read-only.
Decisión final: Ciclo único trimestral (toda categoría incluida en cada ciclo) por simplicidad operativa — un single-person org no se beneficia de tener cadencias distintas por categoría.
Frecuencia adoptada: TRIMESTRAL (4 ciclos al año)
Q1: 1-31 marzo (review of jan-feb-mar)
Q2: 1-30 junio (review of apr-may-jun)
Q3: 1-30 septiembre (review of jul-aug-sep)
Q4: 1-31 diciembre (review of oct-nov-dic)1.5 Elemento 5 — Aprobación de la dirección
Esta frecuencia trimestral ha sido aprobada por el CTO (single-person org) el 2026-06-16 mediante firma git signed-off en el commit que añade este TRA.
2. Comparación con el threshold mínimo de PCI
PCI Req 7.2.5.1 no especifica un mínimo absoluto, solo dice "at a frequency defined in the entity's targeted risk analysis". Sin embargo, las guías de ControlCase + PCI SSC mention que:
- Anual = mínimo aceptable para entornos de bajo riesgo
- Semestral = típico para entidades pequeñas
- Trimestral = recomendado para entornos con CDE + multi-tenant
Fintrixs SAS es un entorno con CDE multi-tenant. Por eso elegimos trimestral, alineado con la recomendación más estricta.
3. Mecanismo de revisión
Cada ciclo trimestral usa la plantilla TMPL-008 y se archiva en:
docs/pci-dss/service-account-reviews/YYYY-QX-review.mdRetención: 7 años (PCI 10.5.1).
4. Calendario adoptado
| Año | Q1 deadline | Q2 deadline | Q3 deadline | Q4 deadline |
|---|---|---|---|---|
| 2026 | (no aplica — TRA emitido 2026-06-16) | 2026-06-30 | 2026-09-30 | 2026-12-31 |
| 2027 | 2027-03-31 | 2027-06-30 | 2027-09-30 | 2027-12-31 |
| 2028 | 2028-03-31 | 2028-06-30 | 2028-09-30 | 2028-12-31 |
Primera ejecución: Q2 2026 (este ciclo) — el TRA se publica + el primer review se ejecuta en la misma fecha (2026-06-16) para iniciar el ciclo inmediatamente.
5. Revisión del propio TRA
Per PCI 12.3.1.5, este TRA debe revisarse anualmente o cuando ocurra un cambio significativo. Próxima revisión obligatoria:
| Tipo | Fecha |
|---|---|
| Revisión anual obligatoria | 2027-06-16 |
| Trigger de revisión inmediata | Cambio significativo en arquitectura, nuevo CDE asset, breach de service account |
6. Aprobación
Aprobado por:
| Rol | Nombre | Fecha | Mecanismo |
|---|---|---|---|
| CTO / CISO acting | Gabriel Ureña | 2026-06-16 | git signed commit |
7. Vínculo con otros documentos
- TMPL-008 — Quarterly Service Account Review Template — la plantilla concreta
- TMPL-007 — Semi-Annual Human Account Review — equivalente para cuentas humanas (Req 7.2.4)
- POL-003 — Logical Access Control — política madre
- PCI DSS v4.0 Req 7.2.5 + 7.2.5.1 + 12.3.1