← Volver al índice | Docker Compose | Análisis Tecnológico
ENS y Soberanía de Datos
Tipo: Documentación de Infraestructura — Seguridad
Audiencia: Responsables TIC, CISO, auditores, dirección
Fecha: 20 de marzo de 2026
Relacionado con: Análisis Tecnológico Integral | Docker Compose
1. Marco Regulador: Esquema Nacional de Seguridad
1.1 Normativa Aplicable
El sistema se rige por el RD 311/2022 (Esquema Nacional de Seguridad). Como sistema del sector público que gestiona datos de investigación del CSIC, la categorización se basa en la criticidad de los datos manejados.
| Marco |
Referencia |
Relevancia |
| ENS |
RD 311/2022 |
Categorización de sistemas de información públicos |
| RGPD |
Reglamento (UE) 2016/679 |
Protección de datos personales de investigadores |
| LOPDGDD |
Ley Orgánica 3/2018 |
Transposición nacional del RGPD |
| Ley de Ciencia |
Ley 17/2022 |
Datos de investigación abiertos |
1.2 Categorización del Sistema
| Dimensión |
Nivel |
Justificación |
| Confidencialidad |
MEDIO |
Datos de investigación no clasificados pero con propiedad intelectual |
| Integridad |
ALTO |
Datos históricos irrepetibles (colecciones desde 1907) |
| Disponibilidad |
MEDIO |
Disponibilidad necesaria pero no crítica 24/7 |
| Autenticidad |
MEDIO |
Trazabilidad de identificaciones IA y autoría |
| Trazabilidad |
ALTO |
Registro de accesos, modificaciones y resultados IA |
[!IMPORTANT]
La categorización resultante es MEDIA como umbral mínimo, con preparación para auditoría ALTA en las dimensiones de integridad y trazabilidad.
2. Controles de Seguridad
2.1 Gestión de Identidad y Acceso
flowchart TB
subgraph IDP ["Proveedor de Identidad"]
ENTRA["Microsoft Entra ID"]
end
subgraph AUTH3 ["Autenticación"]
OIDC["OpenID Connect"]
MFA["MFA - Segundo factor"]
JWT2["JWT firmados RS256"]
end
subgraph AUTHZ ["Autorización"]
RBAC["RBAC por departamento"]
SCOPE["Scopes por recurso"]
ROW["Row-Level Security"]
end
ENTRA --> OIDC --> JWT2
ENTRA --> MFA
JWT2 --> RBAC --> SCOPE --> ROW
style ENTRA fill:#3498db,color:#fff
style RBAC fill:#e74c3c,color:#fff
| Control |
Implementación |
| Autenticación |
Entra ID (OIDC/OAuth2) con MFA obligatorio |
| Tokens |
JWT firmados (RS256), expiración 1h, refresh 24h |
| Roles |
RBAC: Investigador, Responsable, Admin, API_Client |
| Segregación |
Permisos granulares por departamento |
| Row-Level Security |
PostgreSQL RLS para aislamiento de datos por departamento |
2.2 Cifrado
| Capa |
Mecanismo |
Detalle |
| En tránsito |
TLS 1.3 |
Obligatorio para todas las comunicaciones |
| En reposo (BD) |
AES-256 (TDE) |
PostgreSQL con Transparent Data Encryption |
| En reposo (ficheros) |
AES-256 |
MinIO con encriptación server-side (SSE) |
| Claves |
CMEK |
Customer-Managed Encryption Keys gestionadas por el CSIC |
| Backups |
AES-256-GCM |
Backups cifrados con clave independiente |
2.3 Auditoría y Trazabilidad
| Evento |
Registro |
Retención |
| Inicio/cierre de sesión |
Timestamp, IP, usuario, resultado |
2 años |
| Acceso a datos |
Recurso, acción, usuario, timestamp |
2 años |
| Identificación IA |
Modelo, entrada, resultado, confianza |
Permanente |
| Modificación de datos |
Antes/después, usuario, timestamp |
2 años |
| Operaciones privilegiadas |
Todas las acciones admin |
5 años |
flowchart LR
subgraph Fuentes ["Fuentes de Eventos"]
F1["API - Quarkus + Dapr"]
F2["Base de datos"]
F3["Autenticación"]
F4["Motor IA"]
end
subgraph Audit ["Sistema de Auditoría"]
LOG["Log centralizado"]
SIEM["SIEM - Alertas"]
ARCH["Archivo a largo plazo"]
end
F1 --> LOG
F2 --> LOG
F3 --> LOG
F4 --> LOG
LOG --> SIEM
LOG --> ARCH
style SIEM fill:#e74c3c,color:#fff
3. Soberanía de Datos
3.1 Principios de Soberanía
| Principio |
Implementación |
| Residencia de datos |
Todos los datos almacenados en infraestructura dentro de la UE |
| Procesamiento local |
Modelos de IA ejecutados localmente (Ollama), sin envío a APIs externas |
| Control de claves |
Claves de cifrado gestionadas exclusivamente por el CSIC (CMEK) |
| Anti vendor lock-in |
Arquitectura portable basada en estándares abiertos |
| Sin legislación extraterritorial |
Prevención de exposición a normativas de terceros países (e.g., CLOUD Act) |
3.2 Arquitectura de Soberanía
flowchart TB
subgraph CSIC ["Infraestructura CSIC"]
subgraph LOCAL ["Entorno Local - Muelle 9"]
DC["Docker Compose"]
OLL2["Ollama - IA local"]
PG3["PostgreSQL"]
MIN2["MinIO"]
end
subgraph CLOUD ["Cloud Certificada ENS - Futuro"]
K8S["Kubernetes"]
VAULT["HashiCorp Vault"]
BACKUP["Backups cifrados"]
end
end
subgraph FUERA ["Fuera del perímetro"]
M365B["Microsoft 365 - Solo colaboración"]
ENTRA2["Entra ID - Solo autenticación"]
end
ENTRA2 -->|"tokens OIDC"| LOCAL
M365B -->|"datos via Graph API"| LOCAL
style CSIC fill:#2ecc71,color:#fff
style FUERA fill:#95a5a6,color:#fff
[!WARNING]
Microsoft 365 se usa exclusivamente como herramienta de colaboración y autenticación. Los datos del IEO nunca se almacenan en M365 como destino; M365 es solo una fuente de ingesta. Todos los datos ingestados se copian y procesan dentro de la infraestructura del CSIC.
3.3 Proveedores Cloud Certificados ENS ALTO
Para la escala futura, los proveedores elegibles son:
| Proveedor |
Certificación |
Regiones UE |
| Microsoft Azure |
ENS ALTO |
España (Madrid), Norte de Europa |
| Google Cloud Platform |
ENS ALTO |
España (Madrid), Bélgica |
| RedIRIS |
Infraestructura pública española |
Red académica nacional |
4. Gestión de Vulnerabilidades
| Actividad |
Frecuencia |
Responsable |
| Escaneo de imágenes Docker |
En cada build (CI/CD) |
Automatizado (Trivy/Grype) |
| Actualización de dependencias |
Mensual |
Equipo de desarrollo |
| Auditoría de código |
Trimestral |
Herramienta SAST + revisión manual |
| Pentesting |
Semestral |
Equipo externo certificado |
| Revisión de permisos |
Trimestral |
Responsable TIC |
5. Plan de Contingencia y Recuperación
| Componente |
RPO |
RTO |
Estrategia |
| PostgreSQL |
1 hora |
4 horas |
WAL archiving + pg_basebackup diario |
| ChromaDB |
24 horas |
4 horas |
Snapshot diario, regenerable desde PostgreSQL |
| MinIO |
24 horas |
8 horas |
rclone sync a almacenamiento secundario |
| Configuración |
0 (Git) |
1 hora |
Docker Compose + scripts en repositorio |
RPO = Recovery Point Objective (datos máximos que se pueden perder)
RTO = Recovery Time Objective (tiempo máximo para recuperar servicio)
Documentos Relacionados