Seguridad

Modelo de Seguridad

Autenticacion

Usuarios Internos (Admin, Operadores)

Autenticacion via Keycloak con OIDC + PKCE y patron BFF:

Principios del patron BFF:

• Los tokens JWT nunca se exponen al browser
• Solo cookies httpOnly viajan al cliente
• El Gateway almacena tokens en Redis (server-side)
• Sesiones con sliding expiration (30 min por defecto)
• Back-channel logout (Keycloak notifica al Gateway cuando una sesion se invalida)

Usuarios Finales (Ejecucion de flujos, wizard de credito)

Los usuarios finales no se autentican con Keycloak. Acceden mediante un access token unico:

Propiedades del access token:

• UUID v4 (no predecible)
• Firmado con HMAC-SHA256 (integridad)
• TTL configurable (expires_at)
• Single-use por sesion
• No reutilizable despues de completar/expirar

Autorizacion (RBAC)

Roles y Permisos

Rol	Scope	Permisos
platform_admin	Global	CRUD flujos, proveedores, templates. Gestionar todos los tenants.
delegated_admin	Tenants asignados	Gestionar tenants especificos (role admin-tenant-{code})
tenant_admin	Su tenant	Gestionar usuarios, orgs, productos, configuraciones.
operator	Su org	Crear solicitudes, gestionar creditos, operar.
viewer	Su org	Solo lectura.

Maker-Checker (Aprobaciones)

Cambios criticos requieren aprobacion antes de aplicarse:

Entidades que requieren aprobacion (configurable por tenant):

• Configuracion de productos de credito (tasas, costos, plazos)
• Creacion/modificacion de usuarios y roles
• Cambios en proveedores
• Publicacion de versiones de flujos
• Modificacion de listas negras/blancas

Proteccion de Datos

Datos en Reposo

Dato	Clasificacion	Proteccion
Imagenes biometricas	Critico	S3 SSE-KMS, acceso restringido, retencion limitada
Imagenes de documentos	Critico	S3 SSE-KMS, acceso restringido
Credenciales de proveedores	Critico	AWS Secrets Manager, rotacion automatica
Datos personales (nombre, doc)	Sensible	Aurora encryption at-rest (AES-256)
Resultados de validacion	Sensible	Aurora encryption at-rest
Logs de auditoria	Interno	CloudWatch encryption, append-only
Configuracion de flujos	Interno	Aurora encryption at-rest

Datos en Transito

Tramo	Proteccion
Browser - ALB	TLS 1.2+ obligatorio (ACM certificate)
ALB - ECS (Gateway)	TLS interno
Gateway - Servicios	TLS (ECS Service Connect)
Servicios - Aurora	TLS obligatorio (require_ssl)
Servicios - ElastiCache	TLS habilitado
Servicios - Amazon MQ	TLS obligatorio
Servicios - Proveedores externos	TLS 1.2+ obligatorio

AWS KMS

• Customer Managed Keys (CMK) para encryption de datos sensibles
• Key rotation automatica cada 365 dias
• Key policies con least privilege
• Separate keys por servicio/proposito

Seguridad de Red

Security Groups

Componente	Inbound	Outbound
ALB	443 from 0.0.0.0/0	ECS SG on service ports
ECS Services	ALB SG on service ports	Aurora SG:5432, ElastiCache SG:6379, MQ SG:5671, NAT:443
Aurora	ECS SG on 5432	None
ElastiCache	ECS SG on 6379	None
Amazon MQ	ECS SG on 5671	None

AWS WAF

Reglas habilitadas:

• AWS Managed Rules - Core Rule Set (OWASP)
• AWS Managed Rules - SQL Injection
• AWS Managed Rules - Known Bad Inputs
• Rate limiting por IP (configurable por tenant)
• Geo-blocking (opcional, configurable)
• Custom rules para patrones de ataque especificos

Rate Limiting

Endpoint	Limite por tenant	Ventana
POST /api/v1/auth/login	20/min	Sliding window
POST /api/v1/auth/logout	10/min	Sliding window
POST /api/v1/applications	100/min	Sliding window
POST /execute/{token}/steps/*	30/min per token	Sliding window
GET /* (queries)	200/min	Sliding window
Default	100/min	Sliding window

JWT - Estructura y Validacion

Claims del JWT

{
  "sub": "user-uuid",
  "tenant_id": "tenant-uuid",
  "organization_id": "org-uuid",
  "roles": ["operator", "viewer"],
  "email": "user@company.com",
  "name": "John Doe",
  "iss": "https://auth.reimaginetech.io/realms/tenant-code",
  "aud": "imagy-gateway",
  "exp": 1705312800,
  "iat": 1705309200
}

Validacion en cada servicio

Cada servicio valida el JWT independientemente:

• Firma RS256 (JWKS del realm)
• Expiracion (exp)
• Issuer (iss debe ser Keycloak del realm correcto)
• Audience (aud)
• Claims requeridos (sub, tenant_id)

JWKS Cache

• Cada servicio cachea las JWKS keys en Valkey
• TTL: 1 hora
• Invalidacion: cuando la validacion falla, se refresca el JWKS

Seguridad en Mensajeria (RabbitMQ)

Aspecto	Mecanismo
Transporte	TLS 1.2+ obligatorio
Autenticacion	Credenciales por servicio (no compartidas)
Integridad	Firma HMAC-SHA256 por mensaje
Anti-replay	Timestamp < 5 minutos + idempotencia
Permisos	Cada servicio solo puede publicar/consumir en sus exchanges/queues

Seguridad de Webhooks (Notificaciones a Clientes)

Secrets Management

AWS Secrets Manager

Secret	Rotacion	Acceso
DB credentials (por servicio)	Automatica 30 dias	Solo el servicio owner
Keycloak client secrets	Manual	Gateway + Tenant Management
RabbitMQ credentials (por servicio)	Automatica 90 dias	Solo el servicio owner
Provider API keys	Manual (depende del proveedor)	Solo Provider Gateway
HMAC signing keys	Automatica 90 dias	Servicios que firman mensajes
Webhook secrets (por tenant)	Manual (tenant admin)	Notification Service

Reglas

• Nunca secrets en codigo, variables de entorno de build, o imagenes Docker
• En desarrollo local: archivo .env (en .gitignore)
• En produccion: AWS Secrets Manager exclusivamente
• Rotacion automatica donde sea posible
• Least privilege: cada servicio solo accede a sus propios secrets

Auditoria

Todas las acciones se registran para trazabilidad:

Evento	Datos registrados
Login/Logout	user_id, tenant_id, timestamp, IP, user_agent
CRUD de recursos	actor, entity, action, old_value, new_value, timestamp
Cambios de configuracion	actor, entity, change_request_id, timestamp
Acceso cross-tenant	delegated_admin, source_tenant, target_tenant
Ejecucion de flujos	request_id, steps, results, providers_used
Operaciones de credito	credit_id, action, amount, actor
Firma de documentos	signature_id, signer, document, provider

Inmutabilidad

Los logs de auditoria son append-only:

-- El rol de aplicacion no puede UPDATE ni DELETE
REVOKE UPDATE, DELETE ON audit_logs FROM app_user;

Compliance y Certificaciones

AWS FTR (Foundational Technical Review)

Requisitos cubiertos por diseno:

• Multi-AZ deployment (Aurora, ElastiCache)
• Encryption at-rest y in-transit
• Centralized logging (CloudWatch)
• Automated backups con retention
• IAM least privilege (roles por servicio, no access keys)
• No hardcoded credentials
• Disaster recovery plan
• Security incident response
• VPC isolation
• WAF protection

Consideraciones Regulatorias por Region

Region	Regulacion	Impacto en la plataforma
Global	GDPR-like (data residency)	Despliegue multi-region, data en la region del tenant
Latam	Regulacion financiera local	Auditoria, retencion de datos, reportes
USA	SOC 2, PCI-DSS (si aplica)	Controles de acceso, encryption, logging
EU	GDPR	Derecho al olvido, consentimiento, DPO

Data Residency

• Cada tenant puede configurar su region de datos
• Los datos nunca salen de la region configurada
• Despliegue multi-region disponible (Aurora Global Database)
• Proveedores externos deben cumplir con la region del tenant

Checklist de Seguridad

Desarrollo

• [ ] Input validation en frontend (Zod) Y backend (FluentValidation)
• [ ] Queries parametrizadas (nunca string interpolation)
• [ ] No loggear datos sensibles (tokens, passwords, PII)
• [ ] Dependencias pinned y escaneadas por vulnerabilidades
• [ ] Headers de seguridad en todas las respuestas
• [ ] No exponer stack traces al cliente
• [ ] HTTPS obligatorio en produccion

Infraestructura

• [ ] TLS en todas las conexiones
• [ ] Security Groups restrictivos
• [ ] WAF habilitado con reglas OWASP
• [ ] Secrets en AWS Secrets Manager (no en env vars de ECS)
• [ ] KMS CMK para encryption
• [ ] VPC endpoints para servicios AWS
• [ ] CloudTrail habilitado
• [ ] GuardDuty habilitado

Operacional

• [ ] Rotacion automatica de secrets
• [ ] Alertas de seguridad configuradas
• [ ] Backups encriptados y probados
• [ ] Penetration testing periodico
• [ ] Revision de dependencias (Dependabot/Snyk)
• [ ] Incident response plan documentado