Despliegue a producción NO AUTORIZADO — 10 hallazgos críticos detectados
La infraestructura cloud de NovaMed presenta vulnerabilidades críticas incompatibles con el manejo de datos de salud (RGPD Art. 9).
Todos los hallazgos CRITICAL deben ser remediados antes del Go-Live. Exit code 2 en los tres controles.
Acciones requeridas con carácter inmediato.
13
Total Hallazgos
10
Críticos
2
Altos
1
Medios
0
Bajos
Resumen por módulo
IAM — novamed-app-role
Wildcard Action Grant
CRITICAL
Privilege Escalation (PassRole+Lambda)
CRITICAL
Escalation Combo Detectado
CRITICAL
Exfiltración de datos (wildcard)
HIGH
Principal público (*)
CRITICAL
S3 — novamed-patient-records
Principal público en bucket policy
CRITICAL
Public Access Block deshabilitado
CRITICAL
Sin cifrado en reposo (SSE)
CRITICAL
Versionado deshabilitado
HIGH
PDFs de pacientes expuestos públicamente
SG — sg-novamed-ecs-tasks
SSH (22) abierto a 0.0.0.0/0
CRITICAL
PostgreSQL (5432) abierto a internet
CRITICAL
Puerto 443 sin restricción CIDR
MEDIUM
Modifier: internet-facing aplicado
BBDD de pacientes directamente expuesta
Hallazgos detallados
CRITICAL
IAM-S01-WILD-001
Wildcard Action Grant — Acceso sin restricciones al rol de servicio
T1078.004
La política del rol
novamed-app-role contiene Action: "*", Resource: "*" en el primer Statement. Cualquier compromiso del rol de la aplicación equivale a acceso de Administrador a toda la cuenta AWS.
Acciones afectadas
*
Recurso
* (toda la cuenta)
Remediación
Eliminar el Statement con Action: "*". Definir únicamente las acciones necesarias para la aplicación:
s3:GetObject, s3:PutObject, secretsmanager:GetSecretValue, rds-db:connect sobre recursos específicos con ARN explícito.
CRITICAL
IAM-S02-COMBO-001
Escalation Combo: PassRole + Lambda Invoke
T1548
El rol concede simultáneamente
iam:PassRole + lambda:InvokeFunction. Un atacante puede pasar un rol privilegiado a una función Lambda y ejecutarlo, obteniendo privilegios de administrador de forma silenciosa sin alertas en CloudTrail estándar.
Combo de escalada
iam:PassRole
lambda:InvokeFunction
lambda:CreateFunction
Técnica MITRE
T1548 — Abuse Elevation Control Mechanism
Privilege Escalation via IAM
Privilege Escalation via IAM
Remediación
Separar iam:PassRole en un rol de despliegue distinto con restricción por Condition
iam:PassedToService: lambda.amazonaws.com. El rol de la aplicación en runtime no debe tener iam:PassRole.
CRITICAL
S3-001
S3 Bucket Policy: Principal Público — Historiales de pacientes expuestos
T1530
El bucket
novamed-patient-records-prod tiene una bucket policy con Principal: "*" y Action: s3:GetObject. Cualquier persona en internet puede descargar los PDFs de historiales médicos. Infracción RGPD Art. 9 con potencial multa de hasta 4% facturación global (AEPD).
Exposición
Historial médico de pacientes accesible públicamente sin autenticación
Regulación afectada
RGPD Art. 9 · ENS · HIPAA (clientes internacionales)
Remediación inmediata
1. Eliminar bucket policy pública. 2. Habilitar todos los Block Public Access flags. 3. Acceso mediante IAM Identity-based policy del rol de la aplicación + URLs prefirmadas con expiración ≤ 15 minutos para descarga de historiales.
CRITICAL
S3-003
Sin cifrado en reposo — datos de salud almacenados en claro
T1022
El bucket no tiene configuración SSE (ni SSE-S3 ni SSE-KMS). Los objetos se almacenan sin cifrado en reposo, violando el principio de protección de datos por defecto del RGPD y los requisitos del Esquema Nacional de Seguridad (ENS) para datos de salud.
Impacto regulatorio
Sin SSE-KMS no es posible auditar quién ha accedido a las claves de cifrado. Requerido por ENS nivel Alto para datos de salud.
Tipo de datos afectados
PDFs de historiales médicos · Diagnósticos · Tratamientos
Remediación
Habilitar SSE-KMS con CMK (Customer Managed Key) en KMS eu-west-1. Usar aws:kms con BucketKeyEnabled para minimizar costes. Añadir bucket policy que deniegue uploads sin cifrado:
aws:SecureTransport + s3:x-amz-server-side-encryption.
CRITICAL
SG-001
SSH (puerto 22) abierto a Internet — 0.0.0.0/0
T1133
Las tareas ECS tienen el puerto SSH 22 abierto a todo Internet. Con el modificador
internet-facing la severidad sube a CRITICAL. Permite ataques de fuerza bruta, credential stuffing y explotación de vulnerabilidades SSH directamente desde Internet.
Superficie de ataque
Todo Internet (0.0.0.0/0) · ~4.000M IPs · Scanners automatizados activos 24/7
Tiempo promedio hasta primer ataque
< 3 minutos tras exposición
Remediación
Eliminar la regla de entrada en puerto 22. Utilizar AWS Systems Manager Session Manager para acceso a instancias sin puertos inbound. Si SSH es imprescindible, restringir al CIDR de la VPN corporativa únicamente.
CRITICAL
SG-002
PostgreSQL (5432) expuesto a Internet — BBDD de pacientes accesible
T1133
El puerto PostgreSQL 5432 está abierto a 0.0.0.0/0. La base de datos de pacientes de NovaMed (registros clínicos, datos demográficos) es directamente alcanzable desde Internet. Combinado con la política IAM de administrador completo, un atacante podría acceder y exfiltrar toda la base de datos.
Riesgo combinado
BBDD expuesta + rol IAM admin = exfiltración total de datos de pacientes
Violación RGPD potencial
Notificación AEPD obligatoria en 72h · Multa hasta 20M€ o 4% facturación
Remediación
Mover RDS/PostgreSQL a subred privada sin acceso Internet. Crear Security Group específico que solo permita conexiones desde el Security Group de las tareas ECS (referencia SG a SG). Nunca abrir puertos de base de datos a CIDRs públicos.
HIGH
IAM-S01-EXFIL-001
Data Exfiltration Risk — 15 acciones de exfiltración con wildcard
T1530
El wildcard
Action: "*" incluye implícitamente todas las acciones de exfiltración: s3:GetObject, secretsmanager:GetSecretValue, ssm:GetParameter, rds:DownloadDBLogFilePortion, cloudtrail:StopLogging y más.
Acciones de exfiltración incluidas
s3:GetObject
secretsmanager:GetSecretValue
ssm:GetParameter
cloudtrail:StopLogging
rds:DownloadDBLogFilePortion
+10 más
Remediación
Eliminar wildcard. Usar AWS Access Analyzer para identificar las acciones realmente utilizadas por la aplicación en las últimas 90 días y generar política de mínimo privilegio automáticamente.
HIGH
S3-004
Versionado S3 deshabilitado — sin recuperación ante ransomware
T1485
Sin versionado activo, un atacante con acceso al bucket (facilitado por las vulnerabilidades anteriores) puede eliminar o sobrescribir todos los historiales sin posibilidad de recuperación. Técnica T1485 — Data Destruction.
Remediación
Habilitar S3 Versioning + S3 Object Lock en modo Compliance para datos regulados. Configurar lifecycle policy para expirar versiones antiguas tras el período de retención legal (5 años para historiales médicos en España).
Mapa MITRE ATT&CK
T1078.004
Valid Cloud Accounts
Tactic: Initial Access · Persistence
Hallazgos relacionados: 2
T1548
Abuse Elevation Control Mechanism
Tactic: Privilege Escalation
Hallazgos relacionados: 3
T1530
Data from Cloud Storage
Tactic: Collection · Exfiltration
Hallazgos relacionados: 3
T1133
External Remote Services
Tactic: Initial Access · Persistence
Hallazgos relacionados: 2
T1098
Account Manipulation
Tactic: Persistence · Privilege Escalation
Hallazgos relacionados: 2
T1022
Data Encrypted (impact)
Tactic: Exfiltration
Hallazgos relacionados: 1
T1485
Data Destruction
Tactic: Impact
Hallazgos relacionados: 1
T1190
Exploit Public-Facing App
Tactic: Initial Access
Hallazgos relacionados: 2
Plan de remediación priorizado
🔴 Inmediato (hoy)
→
Eliminar bucket policy pública del S3 de historiales. Habilitar Block Public Access.
→
Revocar el Statement
Action:"*" de la política IAM del rol de app.→
Cerrar puerto 5432 (PostgreSQL) en el Security Group. Base de datos no debe tener inbound desde internet.
→
Cerrar puerto 22 (SSH). Activar AWS SSM Session Manager.
🟠 Próximas 24 horas
→
Habilitar SSE-KMS con CMK en bucket novamed-patient-records-prod.
→
Separar iam:PassRole a un rol de despliegue CI/CD distinto con Condition de scope.
→
Ejecutar AWS Access Analyzer para generar política de mínimo privilegio para novamed-app-role.
→
Habilitar S3 Versioning + Object Lock en modo Governance.
🟡 Esta semana (pre Go-Live)
→
Mover RDS a subred privada sin route a internet. Configurar SG solo con referencia al SG de ECS.
→
Implementar Permission Boundaries en todos los roles de producción.
→
Activar GuardDuty, CloudTrail multi-región y AWS Config con reglas de conformidad.
→
Re-ejecutar cloud_posture_check.py — objetivo: exit code 0 en todos los controles.