Tema
EVD-MFA-AUTHENTICATION — Evidencia de Autenticacion Multifactor
| Campo | Valor |
|---|---|
| Organizacion | Fintrixs SAS |
| Entorno | DigitalOcean Managed Kubernetes (DOKS) |
| Fecha de evidencia | 2026-04-03 |
| Proxima revision | 2026-10-03 |
| Responsable | Equipo de Seguridad / Infraestructura |
| Clasificacion | Confidencial — Solo para auditoria PCI DSS |
Q54 — Acceso remoto con MFA
Politica de acceso remoto
Todo acceso remoto a los sistemas de Fintrixs (CDE y sistemas conectados) requiere autenticacion multifactor (MFA) sin excepciones.
Metodos de acceso remoto
| Metodo de acceso | MFA requerido | Tipo de MFA | Detalle |
|---|---|---|---|
| DigitalOcean Console | Si | TOTP (Google Authenticator / Authy) | 2FA obligatorio en la cuenta DO de cada miembro del equipo |
kubectl (Kubernetes) | Si | TOTP via DigitalOcean | El kubeconfig se obtiene via doctl, que requiere sesion DO autenticada con 2FA |
| SSH a nodos (emergencia) | Si | Llave SSH + TOTP en DO Console | Acceso a nodos solo via consola DO (con 2FA) o VPN con MFA |
| VPN (WireGuard) | Si | Certificado + TOTP | Acceso a red de management (monitoring, admin tools) |
| PostgreSQL (managed) | Si | Credenciales + 2FA en DO Console | Las credenciales se obtienen desde la consola DO (que requiere 2FA) |
| Dashboard administrativo | Si | JWT RS256 + TOTP in-app | MFA TOTP integrado en el flujo de login de auth-service |
Lista de usuarios con acceso remoto
| Tipo de acceso | Gestion de usuarios | Revision |
|---|---|---|
| DigitalOcean Console | Lista controlada en la cuenta de equipo DO; cada usuario con 2FA | Trimestral |
| kubectl | Solo miembros del equipo con acceso a DO; kubeconfig efimero | Trimestral |
| SSH | Llaves publicas gestionadas via Terraform; lista en authorized_keys | Semestral |
| VPN | Certificados WireGuard emitidos individualmente; revocacion inmediata al offboarding | Continua |
| Dashboard admin | Usuarios en iam_core.iam_users con rol admin o super_admin | Semestral (Q1031) |
Flujo de acceso remoto con MFA
Q56 — Metodos de autenticacion por plataforma
Tabla de autenticacion por plataforma
| Plataforma | Factor 1 (algo que se sabe) | Factor 2 (algo que se tiene) | Metodo MFA | Bypass permitido |
|---|---|---|---|---|
| Kubernetes (kubectl) | Token OIDC (via DO) | TOTP en DigitalOcean Console | Google Authenticator / Authy | No |
| PostgreSQL (managed) | Password (doadmin / fintrix) | Certificado SSL + 2FA en DO Console | SSL client cert + TOTP en DO | No |
| SSH a nodos | Llave privada RSA/Ed25519 | Acceso via DO Console (2FA) | Llave SSH + TOTP | No |
| Kong Admin API | N/A (red interna) | Acceso solo via kubectl port-forward | Hereda MFA de kubectl | No |
| Dashboard (frontend) | Password (PBKDF2-SHA256) | TOTP in-app (6 digitos, 30s) | FintrixPay Authenticator (otpauth) | No para acceso CDE |
| DigitalOcean Console | Password de cuenta DO | TOTP | Google Authenticator / Authy | No |
| Grafana / Prometheus | Via kubectl port-forward | Hereda MFA de kubectl | TOTP en DO | No |
Configuracion de MFA en el dashboard (auth-service)
Protocolo TOTP implementado
| Parametro | Valor |
|---|---|
| Algoritmo | TOTP (RFC 6238) |
| Digitos | 6 |
| Periodo | 30 segundos |
| Emisor | FintrixPay |
| Hash | SHA-1 (estandar TOTP) |
| Secreto | 20 bytes aleatorios, codificado en Base32 |
| URI otpauth | otpauth://totp/FintrixPay:<email>?secret=<base32>&issuer=FintrixPay&digits=6&period=30 |
| Codigos de respaldo | 8 codigos de un solo uso (4 bytes hex cada uno) |
Proteccion anti-replay
| Control | Implementacion |
|---|---|
| Ventana de validacion | Codigo TOTP valido solo durante su periodo de 30 segundos |
| Token MFA temporal | JWT con purpose: 'mfa_challenge', expiracion de 5 minutos |
| Un solo uso del mfaToken | Tras validar el codigo TOTP, se emite un JWT de sesion; el mfaToken queda invalidado por expiracion |
| Formato de codigo | Regex /^\d{6}$/ — solo 6 digitos; cualquier otro formato es rechazado |
Flujo completo de MFA en login
Flujo de configuracion inicial de MFA
Factores de autenticacion (dos factores distintos)
| Factor | Tipo | Detalle |
|---|---|---|
| Factor 1 — Algo que el usuario sabe | Knowledge | Password (PBKDF2-SHA256 con 210,000 iteraciones) |
| Factor 2 — Algo que el usuario tiene | Possession | Dispositivo con app autenticadora (Google Authenticator, Authy, 1Password) |
Nota PCI DSS: Los dos factores son de categorias distintas (knowledge + possession), cumpliendo con el requisito de autenticacion multifactor con al menos dos factores independientes.
Q233 — 2FA obligatorio para todo acceso al CDE
Definicion del CDE (Cardholder Data Environment)
Los siguientes componentes conforman el CDE de Fintrixs:
| Componente | Tipo | Datos sensibles |
|---|---|---|
card-vault-service | Microservicio NestJS | PAN cifrado (AES-256), datos de tarjeta |
tokenization-service | Microservicio NestJS | PAN en transito (tokenizacion) |
auth-service | Microservicio NestJS | Credenciales de usuarios con acceso al CDE |
vault_db | PostgreSQL managed | Almacenamiento cifrado de datos de tarjeta |
auth_db | PostgreSQL managed | Credenciales y configuracion de auth |
| Kong Gateway | API Gateway | Punto de entrada al CDE (proxy TLS) |
| CDE Node Pool | Kubernetes nodes | Nodos fisicos dedicados con taint pci-scope=true |
Matriz de acceso al CDE con 2FA
| Via de acceso | 2FA obligatorio | Mecanismo | Aplica a |
|---|---|---|---|
kubectl al namespace cde | Si | TOTP en DigitalOcean + K8s RBAC | Ingenieros de infraestructura |
| PostgreSQL vault_db / auth_db | Si | SSL cert + TOTP en DO Console | DBA (solo emergencias) |
| API de card-vault-service | Si | Solo accesible desde tokenization-service (no hay acceso humano directo) | Ningun usuario humano |
| API de tokenization-service | Si | Solo via Kong (HTTPS) + JWT con MFA | Microservicios autorizados |
| Logs del CDE | Si | kubectl logs + TOTP en DO | Ingenieros de seguridad |
| SSH a nodos CDE | Si | Llave SSH + TOTP en DO Console | Solo emergencia con aprobacion |
| Dashboard admin (datos tokenizados) | Si | JWT RS256 + TOTP in-app | Usuarios admin |
Diagrama de acceso al CDE con 2FA
Controles que impiden bypass de 2FA
| Control | Implementacion | Evidencia |
|---|---|---|
| No hay acceso directo a la consola | Los nodos K8s de DigitalOcean no tienen IP publica; acceso solo via doctl (con 2FA) | Cloud Firewall rules |
| NetworkPolicy deny-all en namespace CDE | Ningun pod fuera del CDE puede comunicarse con pods del CDE sin regla explicita | backend/infra/kubernetes/network-policies.yaml |
| Kong como unico ingress | Todo trafico HTTP al CDE pasa por Kong; Kong solo es accesible desde el Load Balancer | backend/infra/kong/kong.yaml |
| JWT con validacion de MFA | El checkMfaAndRespond() intercepta el login y devuelve challenge si MFA esta habilitado | backend/apps/auth-service/src/auth/auth.service.ts |
| Kubernetes RBAC | Roles separados para namespace cde vs app; solo roles cde-admin pueden interactuar con pods CDE | K8s RBAC manifests |
| Audit logging | Todo acceso al CDE (kubectl, psql, API) genera registros de auditoria | Prometheus metrics + admin-audit-service |
Acceso de base de datos al CDE
| Base de datos | Metodo de autenticacion | 2FA |
|---|---|---|
vault_db (Managed PostgreSQL) | Password + SSL client certificate | Si — credenciales accesibles solo via DO Console (2FA) |
auth_db (Managed PostgreSQL) | Password + SSL client certificate | Si — credenciales accesibles solo via DO Console (2FA) |
| App databases (no-CDE) | Password + SSL | Si — misma politica aplicada uniformemente |
Acceso de consola (sin 2FA)
| Escenario | Permitido? | Detalle |
|---|---|---|
| Acceso directo a consola de nodo sin MFA | No | No hay IP publica en nodos; no hay SSH directo sin pasar por DO Console (2FA) |
kubectl exec sin MFA | No | kubeconfig requiere token DO obtenido con 2FA |
| psql sin MFA | No | Credenciales solo disponibles en DO Console (2FA) o Kubernetes Secrets (kubectl con 2FA) |
Resumen de cumplimiento MFA
| Requisito PCI DSS | Estado | Evidencia |
|---|---|---|
| Q54 — MFA para acceso remoto | Cumple | TOTP en DO Console para todo acceso remoto |
| Q56 — Metodos de auth por plataforma | Cumple | Tabla detallada con factores por plataforma |
| Q56 — Anti-replay en MFA | Cumple | Token MFA temporal (5min), codigo TOTP por ventana de 30s |
| Q56 — Sin bypass de MFA | Cumple | No hay ruta de acceso al CDE que evite 2FA |
| Q56 — Dos factores distintos | Cumple | Knowledge (password) + Possession (TOTP app) |
| Q233 — 2FA en todo acceso CDE | Cumple | Todas las vias de acceso al CDE requieren 2FA |
Historial de revisiones
| Fecha | Revisor | Cambios |
|---|---|---|
| 2026-04-03 | Equipo de Seguridad | Documento inicial — cobertura Q54, Q56, Q233 |