OP.PL.2 Arquitectura de Seguridad

Documentos de referencia

• Son de especial relevancia los siguientes principios básicos:
  • Artículo 7. Prevención, reacción y recuperación.
  • Artículo 8. Líneas de defensa.
• ISO 27000
  • 27002:2013
    • 8.1.1 - Inventario de activos
    • 8.1.2 - Propiedad de los activos
    • 13.1.1 - Controles de red
    • 14.2.5 - Principios para la ingeniería de sistemas seguros
• NIST 800-53 rev.4
  • [CM-8] Information system Component Inventory
  • [PM-5] Information Systems Inventory
  • [PM-7] Enterprise Architecture
  • [PM-8] Critical Infrastucture Plan
  • [SA-5] Information System Documentation
  • [SA-8] Security Engineering Principles
  • [PL-8] Information Security Architecture
• Otras referencias:
  • Manageable Network Plan

Guía de implantación

72. Lo que se busca con esta medida de seguridad es tener una visión global, íntegra e integradora de cómo es el sistema de información, cómo se gestiona y cómo se defiende. Esta medida es básicamente documental y descriptiva.

73. La arquitectura de seguridad es elaborada bajo la dirección del Responsable del Sistema, y es aprobada por el Responsable de la Seguridad.

Modelo de trabajo y ubicación de los recursos

La organización opera bajo un modelo de teletrabajo al 100 %, sin oficina física ni instalaciones propias. Todo el personal trabaja de forma remota desde sus domicilios o ubicaciones autorizadas. Como consecuencia:

• No existen instalaciones físicas propias (CPD, oficinas, salas de servidores). Toda la infraestructura se encuentra en centros de datos de AWS, certificados en el ENS y con cumplimiento ISO 27001, SOC 2 y PCI-DSS.
• Los equipos de los empleados (portátiles Mac y, en casos específicos, estaciones Linux) se gestionan de forma remota mediante políticas de seguridad (GPO), agentes de monitorización (Wazuh) y herramientas EDR.
• Las comunicaciones se realizan exclusivamente a través de canales cifrados (HTTPS, TLS 1.3, VPN cuando proceda).
• Los controles de seguridad física del Anexo II del ENS (mp.if.*) se satisfacen mediante las certificaciones de los centros de datos de AWS y las medidas de protección de equipos portátiles definidas en la Normativa de Seguridad (ORG.2).

Esta declaración justifica la no aplicabilidad de los controles de instalaciones físicas propias en la Declaración de Aplicabilidad.

Diagrama de red y arquitectura de ciberseguridad

El siguiente diagrama muestra la arquitectura de red desde la perspectiva de ciberseguridad, incluyendo las líneas de defensa, los componentes de seguridad y los flujos de conexión:

Líneas de defensa

Línea	Componentes	Función
1.ª — Perímetro	CloudFront, WAF, Shield	Filtrado de tráfico malicioso, protección DDoS, reglas OWASP, rate limiting
2.ª — Red	VPC, Security Groups, NACLs, Flow Logs	Segmentación de red, aislamiento de subnets (DMZ → App → Data), control de tráfico
3.ª — Aplicación	ALB, API Gateway, Auth Service, ML Engine	Validación de entrada, autenticación MFA, autorización RBAC/ABAC, sandboxing
4.ª — Datos	DocumentDB, S3, KMS, Secrets Manager	Cifrado en reposo (AES-256) y en tránsito (TLS 1.3), gestión de claves, rotación automática
Transversal — Monitorización	Wazuh SIEM, EDR, CloudWatch, CloudTrail	Correlación de eventos, detección de amenazas, auditoría de accesos, respuesta a incidentes

Equipos de los empleados (endpoints)

Dado el modelo de teletrabajo, los equipos de los empleados constituyen un componente crítico de la arquitectura:

Tipo	SO	Medidas de seguridad
Portátiles de desarrollo y gestión	macOS	Cifrado FileVault, XProtect (antivirus nativo), agente Wazuh, agente EDR, GPO de contraseñas, bloqueo por inactividad, actualizaciones automáticas
Servidores de entrenamiento ML	Linux	Cifrado de disco, agente Wazuh, agente EDR, acceso restringido por SSH con clave, actualizaciones gestionadas

Implementación en la plataforma

Visión General de la Arquitectura de Seguridad

Principios Arquitectónicos

La arquitectura de seguridad de la plataforma se fundamenta en:

• Zero Trust Architecture: Verificación continua, nunca confiar, siempre verificar
• Defense in Depth: Múltiples capas de seguridad superpuestas
• Least Privilege: Acceso mínimo necesario para cada función
• Segregation of Duties: Separación de responsabilidades críticas
• Security by Design: Seguridad integrada desde el diseño
• Data Minimization: Procesamiento mínimo de datos personales
• Privacy by Design: Privacidad incorporada por defecto

Modelo de Referencia

La arquitectura sigue el modelo de capas con seguridad perimetral y en profundidad:

Modelo de capas de la arquitectura de seguridad:

Capa	Componentes	Función
Capa de Presentación	API Client (sistemas de las organizaciones clientes)	Interfaz de integración (API REST)
Capa de Seguridad Perimetral	AWS CloudFront + WAF + Shield, DDoS Protection + Rate Limiting	Protección perimetral contra amenazas externas
Capa de Aplicación	API Gateway (FastAPI), Auth Service (API Key / OAuth 2.0), ML Engine (PyTorch)	Lógica de negocio y procesamiento
Capa de Datos	DocumentDB (Encrypted), S3 Bucket (Encrypted), Redis (Cache)	Almacenamiento y persistencia de datos

Arquitectura Detallada por Componentes

Componentes de Infraestructura

Infraestructura Cloud (AWS):

Componente	Función	Controles de Seguridad
VPC	Aislamiento de red	Subnets privadas, NACLs, Security Groups
EC2/ECS	Computación	IMDSv2, SSM Session Manager, hardening
S3	Almacenamiento objetos	Cifrado AES-256, versioning, MFA delete
DocumentDB	Base de datos	TLS, cifrado en reposo, backup automático
CloudFront	CDN	HTTPS only, geo-restricción, OAC
Route 53	DNS	DNSSEC, health checks
KMS	Gestión de claves	HSM, rotación automática
Secrets Manager	Gestión secretos	Rotación automática, auditoría

Componentes de Aplicación

Servicios Core:

Servicios principales de la aplicación:

Servicio	Tecnología/Protocolo	Controles de seguridad
API Gateway	FastAPI + Uvicorn	Rate limiting por IP/usuario, Input validation (Pydantic), CORS configurado restrictivamente, OpenAPI schema validation, Request/response logging
Authentication Service	API keys + OAuth 2.0 client credentials	Autenticación máquina-a-máquina para sistemas clientes, API key rotation, Rate limiting por cliente, Audit logging de todas las peticiones
ML Inference Engine	PyTorch + ONNX Runtime	Model signing y verificación, Input sanitization, Sandboxing de ejecución, Resource limits
Image Processing	OpenCV, Pillow, scikit-image	Validación formato/tamaño, Antivirus scanning, EXIF stripping, Watermarking

2.3 Componentes de Integración

Interfaces Externas:

Interface	Estándar	Seguridad
FHIR	R4	OAuth 2.0, TLS 1.3, audit logging
HL7	v2.x/v3	VPN/TLS, message signing
Webhooks	REST	HMAC signing, retry logic
DICOM	3.0	TLS, de-identification

3. Arquitectura de Seguridad por Capas

3.1 Capa 1: Seguridad Física

Aunque el sistema es cloud-native, se consideran:

• Data Centers AWS: Certificados ISO 27001, SOC 2, PCI-DSS
• Redundancia geográfica: Multi-AZ deployment
• Disaster Recovery: RTO < 4 horas, RPO < 1 hora

3.2 Capa 2: Seguridad de Red

Segmentación de Red:

La red se organiza en tres niveles jerárquicos con diferentes niveles de confianza:

Estructura de subnets:

Nivel de red	Componentes	Nivel de seguridad	Acceso desde
Public Subnet (DMZ)	ALB/NLB, NAT Gateway	Bajo	Internet
Private Subnet (App Tier)	ECS Tasks, Lambda Functions, EC2 Instances	Medio	DMZ únicamente
Private Subnet (Data Tier)	DocumentDB, ElastiCache, EFS	Alto	App Tier únicamente

Flujo de tráfico: Internet → Public Subnet (DMZ) → Private Subnet (App) → Private Subnet (Data)

Controles de Red:

• Security Groups: Stateful, principio least privilege
• NACLs: Stateless, defense in depth
• VPC Flow Logs: Análisis de tráfico
• AWS Network Firewall: IPS/IDS capabilities
• PrivateLink: Conexiones privadas a servicios

3.3 Capa 3: Seguridad de Host

Hardening de Sistemas:

• AMIs personalizadas con CIS benchmarks
• Patch management automatizado (Systems Manager)
• Antimalware: XProtect (macOS nativo) + WatchGuard EPDR (catálogo CCN)
• File Integrity Monitoring (AIDE)
• Log forwarding (CloudWatch Agent)

3.4 Capa 4: Seguridad de Aplicación

Secure Development Lifecycle:

El ciclo de vida de desarrollo seguro integra controles de seguridad en cada fase:

Fases del SDL y controles de seguridad asociados:

Fase	Actividades principales	Controles de seguridad integrados
Requisitos	Recopilación de requerimientos	Requisitos de seguridad
Diseño	Arquitectura y especificaciones	Threat Modeling
Desarrollo	Codificación e implementación	SAST/Code Review
Testing	Pruebas funcionales y de seguridad	DAST/Pentesting
Despliegue	Lanzamiento a producción	Security Gates
Operación	Monitorización continua	Monitoring

El ciclo es iterativo, con feedback continuo desde operación hacia requisitos para mejora continua.

Controles de Aplicación:

• Input validation en todos los endpoints
• Output encoding para prevenir XSS
• Parametrized queries (prevención SQLi)
• Secure session management
• CSRF tokens
• Security headers (CSP, HSTS, etc.)

3.5 Capa 5: Seguridad de Datos

Clasificación de Datos:

Categoría	Ejemplos	Controles
Crítica	Datos médicos, PII	Cifrado AES-256, acceso MFA
Alta	Algoritmos, configuraciones	Cifrado, acceso restringido
Media	Logs operativos	Cifrado en tránsito
Baja	Documentación pública	Integridad

Ciclo de Vida del Dato:

1. Creación: Clasificación automática, etiquetado
2. Almacenamiento: Cifrado en reposo (AES-256-GCM)
3. Transmisión: TLS 1.3 mínimo
4. Procesamiento: Memoria cifrada, secure enclaves
5. Compartición: DLP policies, watermarking
6. Archivado: Glacier con vault lock
7. Destrucción: Secure wipe, certificado destrucción

4. Mecanismos de Control de Acceso

4.1 Modelo de Control de Acceso

RBAC (Role-Based Access Control) + ABAC (Attribute-Based):

Roles definidos en el sistema:

Modelo de acceso: API sin usuarios finales

El producto es una API REST que los sistemas de las organizaciones clientes consumen mediante integración máquina-a-máquina. Los profesionales sanitarios y pacientes no interactúan directamente con nuestro sistema: acceden a través de las aplicaciones propias de sus organizaciones (hospitales, clínicas), que se integran con nuestra API. Por tanto, el control de acceso se aplica a nivel de cliente API (organización) y de empleados internos de la empresa.

Rol	Permisos	Auditoría exenta
SuperAdmin	Acceso completo al sistema (solo personal interno)	No
OrganizationAdmin	Gestionar la configuración de su organización cliente, API keys, webhooks	No
API Client	Enviar peticiones a la API (diagnósticos, imágenes), recibir resultados, según su contrato	No

Atributos adicionales para control de acceso basado en atributos (ABAC):

• Organization ID (identifica al cliente)
• API key / Client ID
• IP allowlist (si configurado por el cliente)
• Rate limit tier (según contrato)

4.2 Autenticación y Autorización

Modelo de autenticación: API máquina-a-máquina

El producto es una API REST consumida por los sistemas de las organizaciones clientes. No existe login de usuarios finales (profesionales sanitarios o pacientes) en nuestro sistema. La autenticación opera en dos niveles:

Nivel 1 — Autenticación de clientes API (sistemas externos):

Paso	Actor origen	Actor destino	Acción
1	Sistema del cliente	API Gateway	El servidor del cliente envía petición con API key / token
2	API Gateway	Auth Service	Se valida la API key y los permisos del cliente
3	Auth Service	API Gateway	Se confirma la autenticación y el rate limit tier del cliente
4	API Gateway	Backend	La petición se enruta al servicio correspondiente
5	Backend	API Gateway	El resultado se devuelve al cliente

Nivel 2 — Autenticación de empleados internos (administración):

Sistema	Método de autenticación
AWS Console	IAM con MFA obligatorio
Google Workspace	Cuenta corporativa con MFA
GitHub	Cuenta corporativa con MFA y branch protection
Wazuh	Credenciales locales con acceso restringido

5. Arquitectura de Monitorización y Respuesta

5.1 Security Information and Event Management (SIEM)

Arquitectura de Logging:

Flujo de agregación de logs:

Fuente de logs	Destino primario	Destino secundario	Destino terciario	Visualización
Application Logs	CloudWatch Logs	Wazuh (correlación)	S3 Archive	Wazuh Dashboard
System Logs	CloudWatch Logs	Wazuh (correlación)	S3 Archive	Wazuh Dashboard
Security Logs	CloudWatch Logs	Wazuh (correlación)	S3 Archive	Wazuh Dashboard
AWS CloudTrail	CloudWatch Logs	Wazuh (correlación)	S3 Archive	Wazuh Dashboard
Endpoint Logs	Agente Wazuh	Wazuh Manager	S3 Archive	Wazuh Dashboard

Todos los logs pasan por CloudWatch Logs para agregación inicial, se envían a Wazuh para correlación de eventos de seguridad y detección de amenazas, y se archivan en S3 para retención a largo plazo y cumplimiento normativo. Wazuh actúa como SIEM centralizado conforme al control op.mon.1 del ENS.

Eventos Monitorizados:

• Intentos de autenticación (exitosos/fallidos)
• Cambios de configuración
• Acceso a datos sensibles
• Operaciones privilegiadas
• Anomalías de comportamiento
• Indicadores de compromiso (IoCs)

5.2 Incident Response Architecture

Niveles de Respuesta:

Nivel	Severidad	Tiempo Respuesta	Escalado
P1	Crítica	< 15 min	CISO + CEO
P2	Alta	< 1 hora	CISO + CTO
P3	Media	< 4 horas	Security Team
P4	Baja	< 24 horas	SOC

6. Arquitectura de Continuidad y Recuperación

6.1 Backup y Recovery

Estrategia 3-2-1:

• 3 copias de datos críticos
• 2 medios diferentes (S3 + Glacier)
• 1 copia offsite (diferente región AWS)

RPO/RTO por Componente:

Componente	RPO	RTO	Método
Base de datos	1 hora	2 horas	Continuous backup
Archivos S3	24 horas	4 horas	Cross-region replication
Configuración	Real-time	30 min	IaC (Terraform)
Aplicación	N/A	1 hora	Blue-green deployment

6.2 Alta Disponibilidad

Arquitectura Multi-AZ:

La arquitectura desplegada en la región eu-west-1 (Ireland) utiliza tres zonas de disponibilidad para garantizar alta disponibilidad:

Availability Zone	ECS Tasks	DocumentDB	Función
AZ 1 (eu-west-1a)	Active	Primary	Zona principal de procesamiento y escritura
AZ 2 (eu-west-1b)	Active	Replica	Zona secundaria activa con réplica de lectura
AZ 3 (eu-west-1c)	Standby	Replica	Zona de standby con réplica para failover

Esta configuración Multi-AZ garantiza disponibilidad del 99.99% mediante distribución geográfica de los recursos dentro de la misma región AWS.

7. Gestión de Componentes SOUP

7.1 Inventario de Componentes

Componentes de Terceros Críticos:

Componente	Versión	Criticidad	Último Análisis
FastAPI	0.104.x	Alta	2025-08-01
PyTorch	2.1.x	Alta	2025-08-01
OpenCV	4.8.x	Media	2025-07-15
Pydantic	2.4.x	Alta	2025-08-01
Redis	7.2.x	Media	2025-07-15

7.2 Gestión de Vulnerabilidades SOUP

Proceso de Gestión:

1. Identificación: Escaneo automático (Trivy, Snyk)
2. Evaluación: Análisis CVSS y contexto
3. Priorización: Basada en exploitability y impacto
4. Remediación: Patching o mitigación
5. Verificación: Testing post-patch
6. Documentación: Registro en el sistema de gestión de vulnerabilidades

8. Cumplimiento y Certificaciones

8.1 Frameworks de Cumplimiento

Framework	Nivel	Estado	Auditoría	Referencia Normativa
ISO 27001:2022	Completo	Certificado	Anual	Base para ENS
ENS (RD 311/2022)	ALTO	En implementación	Bienal	Obligatorio
RGPD/GDPR	Completo	Conforme	Continua	Art. 32 Seguridad
FDA Cybersecurity	Completo	Validado	Por cambio	Premarket Guidance
MDR (EU) 2017/745	Clase IIa	Conforme	Anual	Anexo I, 17.2-17.4
NIS2	Esencial	Conforme	Anual	Directiva (EU) 2022/2555

8.2 Controles ENS Implementados según CCN-STIC-804

Estado de Implementación por Dominio (Categoría ALTA):

Dominio ENS	Código	Controles Requeridos	Implementados	% Cumplimiento	CCN-STIC Ref
Marco Organizativo	org.*	5	5	100%	CCN-STIC-821 Sección 4
org.1 Política de seguridad	org.1	✅	✅	100%	Art. 11 RD 311/2022
org.2 Normativa de seguridad	org.2	✅	✅	100%	Art. 11 RD 311/2022
org.3 Procedimientos	org.3	✅	✅	100%	Art. 13 RD 311/2022
org.4 Proceso autorización	org.4	✅	✅	100%	Art. 13 RD 311/2022
Marco Operacional	op.*	32	25	78%	CCN-STIC-821 Sección 5
op.pl Planificación	op.pl.*	5	4	80%	Art. 12 RD 311/2022
op.pl.2 Arquitectura seguridad	op.pl.2	✅	✅	100%	Art. 12 RD 311/2022
op.acc Control acceso	op.acc.*	7	6	86%	Art. 14 RD 311/2022
op.exp Explotación	op.exp.*	11	8	73%	Art. 16 RD 311/2022
op.cont Continuidad	op.cont.*	4	3	75%	Art. 17 RD 311/2022
op.mon Monitorización	op.mon.*	2	1	50%	Art. 16 RD 311/2022
Medidas Protección	mp.*	45	34	76%	CCN-STIC-821 Sección 6
mp.if Instalaciones	mp.if.*	9	8	89%	Anexo II RD 311/2022
mp.per Personal	mp.per.*	4	4	100%	Anexo II RD 311/2022
mp.eq Equipos	mp.eq.*	5	4	80%	Anexo II RD 311/2022
mp.com Comunicaciones	mp.com.*	4	3	75%	Anexo II RD 311/2022
mp.si Soportes	mp.si.*	7	5	71%	Anexo II RD 311/2022
mp.sw Software	mp.sw.*	6	4	67%	Anexo II RD 311/2022
mp.info Información	mp.info.*	6	4	67%	Anexo II RD 311/2022
mp.s Servicios	mp.s.*	4	2	50%	Anexo II RD 311/2022

Nota: Los controles marcados corresponden al nivel ALTO según CCN-STIC-821.

9. Documentación de la Arquitectura según ENS

9.1 Documentos de Arquitectura Requeridos por RD 311/2022

En cumplimiento del Artículo 12 del RD 311/2022 y las guías CCN-STIC-809 y CCN-STIC-811, se mantienen los siguientes documentos:

Documento	Código	Propósito	Requisito ENS	CCN-STIC
Documento de Arquitectura de Seguridad	(por definir)	Descripción técnica completa del sistema	Art. 12 RD 311/2022	CCN-STIC-811
Análisis de Riesgos	(por definir)	Identificación y valoración de riesgos	Art. 11 RD 311/2022	CCN-STIC-803
Modelo de Amenazas	(por definir)	Análisis de amenazas y vulnerabilidades	op.pl.1	CCN-STIC-812
Declaración de Aplicabilidad	(por definir)	Matriz de cumplimiento ENS	Art. 41 RD 311/2022	CCN-STIC-804
Inventario de Activos	GP-110/op.exp.1	Registro completo de activos	op.exp.1	CCN-STIC-821
Topología de Red	(por definir)	Arquitectura de red y segmentación	op.pl.2	CCN-STIC-811
Matriz de Flujos de Información	(por definir)	Intercambio de información entre componentes	mp.com.1	CCN-STIC-811
Procedimientos Operativos	GP-110/*	Runbooks y guías operativas	org.3	CCN-STIC-821
Plan de Adecuación	(por definir)	Roadmap de cumplimiento ENS	Art. 40 RD 311/2022	CCN-STIC-806

9.2 Mantenimiento de la Documentación

Proceso de Actualización:

1. Revisión trimestral: Validación de accuratez
2. Actualización por cambio: Via change management
3. Auditoría anual: Revisión completa
4. Versionado: Git con tags semánticos

10. Métricas de Arquitectura

10.1 KPIs de Seguridad

Métrica	Objetivo	Actual	Tendencia
Cobertura de segmentación	100%	98%	↑
Componentes parcheados	>95%	97%	→
Tiempo detección amenazas	<1 hora	45 min	↓
Disponibilidad servicios	99.9%	99.95%	↑
Cumplimiento controles	>90%	94%	↑

10.2 Indicadores de Madurez

Modelo de Madurez de Arquitectura:

1. Inicial: Arquitectura ad-hoc
2. Repetible: Patrones definidos
3. Definido: Arquitectura estándar ✓
4. Gestionado: Métricas y optimización ✓
5. Optimizado: Mejora continua (objetivo)

11. Responsabilidades

11.1 Roles y Responsabilidades

Rol	Responsabilidades
Enterprise Architect	Diseño y evolución de la arquitectura
Security Architect	Controles de seguridad y threat modeling
Cloud Architect	Infraestructura AWS y optimización
Solution Architect	Integración de componentes
CISO	Aprobación y governance

11.2 Comité de Arquitectura

Miembros:

• CTO (Presidente)
• CISO
• Enterprise Architect
• Representante QA/RA
• DevOps Lead

Funciones:

• Revisión mensual de arquitectura
• Aprobación de cambios significativos
• Evaluación de nuevas tecnologías
• Gestión de deuda técnica

12. Evolución y Roadmap de Cumplimiento ENS

12.1 Plan de Mejora según CCN-STIC-806

Alineado con el Artículo 40 del RD 311/2022 (Planes de mejora de la seguridad):

Trimestre	Iniciativas ENS	Controles CCN-STIC	Estado Objetivo	Presupuesto
Q1 2025	• Completar op.mon (Monitorización) • Implementar mp.s (Protección servicios) • Zero Trust Network Access	CCN-STIC-835 (Monitorización) CCN-STIC-836 (Zero Trust)	87% cumplimiento ENS	€15,000
Q2 2025	• Certificación ENS Nivel ALTO • Quantum-safe cryptography prep • Completar toda documentación	CCN-STIC-809 (Certificación) CCN-STIC-807 (Criptografía)	95% cumplimiento ENS Auditoría formal	€20,000
Q3 2025	• Obtención Certificado ENS • AI-powered threat detection • Automated incident response	CCN-STIC-817 (IA en Seguridad) CCN-STIC-816 (Automatización)	100% cumplimiento ENS Certificado obtenido	€10,000
Q4 2025	• Mejora continua post-certificación • Blockchain audit trail • Advanced DLP implementation	CCN-STIC-825 (Blockchain) CCN-STIC-823 (Cloud avanzado)	Mantenimiento certificación Preparación re-certificación	€5,000

12.2 Tecnologías Emergentes

En Evaluación:

• SASE (Secure Access Service Edge)
• SOAR (Security Orchestration)
• Homomorphic encryption
• Federated learning
• WebAuthn/Passkeys

Anexo A: Diagrama de Despliegue Detallado

Estructura de cuentas AWS:

Entorno	Región AWS	VPC CIDR	Subnets públicas	Subnets privadas (App)	Subnets privadas (Data)	Características
Production	eu-west-1	10.0.0.0/16	10.0.1.0/24, 10.0.2.0/24	10.0.10.0/24, 10.0.11.0/24	10.0.20.0/24, 10.0.21.0/24	Entorno productivo con controles estrictos
Staging	eu-west-1	10.1.0.0/16	Similar a Production	Similar a Production	Similar a Production	Réplica de producción para testing
Development	eu-west-2	10.2.0.0/16	Configuración simplificada	Configuración simplificada	Configuración simplificada	Acceso más permisivo para developers

Anexo B: Matriz de Comunicaciones

Origen	Destino	Puerto	Protocolo	Cifrado
Internet	ALB	443	HTTPS	TLS 1.3
ALB	ECS Tasks	8000	HTTP	VPC interno
ECS Tasks	DocumentDB	27017	MongoDB Wire	TLS 1.2
ECS Tasks	Redis	6379	Redis	TLS + AUTH
ECS Tasks	S3	443	HTTPS	TLS 1.3

Anexo C: Definición Completa del Perímetro de Seguridad

C.1 Zonas de Seguridad y Fronteras

Definición del perímetro de seguridad:

El perímetro de seguridad se estructura en cinco zonas de seguridad con diferentes niveles de confianza y controles específicos:

Resumen de zonas de seguridad:

Zona	Nivel de confianza	Nivel de riesgo	Propósito
External Zone	Untrusted	Alto	Internet público no confiable
DMZ Zone	Limited Trust	Medio-Alto	Servicios públicos, balanceo de carga
Application Zone	Medium Trust	Medio	Lógica de negocio, procesamiento API, autenticación
Data Zone	High Trust	Bajo-Medio	Almacenamiento, procesamiento, backup de datos
Management Zone	High Trust	Medio	Administración, monitorización, logging

Zona Externa (Internet/Untrusted):

Atributo	Descripción
Trust Level	Untrusted
Risk Level	High
Connectivity	Public Internet
Controles	DDoS Protection (AWS Shield Advanced), Geographic blocking (CloudFront), Rate limiting (WAF), Bot detection and mitigation

Zona DMZ (Desmilitarizada):

Atributo	Descripción
Trust Level	Limited Trust
Risk Level	Medium-High
Purpose	Public-facing services, load balancing
Componentes	Application Load Balancer (ALB), CloudFront CDN, WAF (Web Application Firewall), API Gateway (external endpoints)
Security Controls	TLS termination and inspection, HTTP/HTTPS filtering, Request validation and sanitization, SSL/TLS certificate management
Network Restrictions	Inbound: HTTPS (443) only, Outbound: Limited to internal zones, Logging: Full packet capture

Zona Aplicación (Application Tier):

Atributo	Descripción
Trust Level	Medium Trust
Risk Level	Medium
Purpose	Business logic, API processing, authentication
Componentes	ECS Fargate containers, Lambda functions, API Gateway (internal + external), Authentication services (API key validation), ML inference engines
Security Controls	Container security scanning, Runtime protection (Falco), Secrets management (AWS Secrets Manager), Application-level encryption, Code integrity verification
Network Restrictions	Inbound: From DMZ only (port 8000), Outbound: To data zone and external APIs, Inter-service: Service mesh (Istio)

Zona Datos (Data Tier):

Atributo	Descripción
Trust Level	High Trust
Risk Level	Low-Medium
Purpose	Data storage, processing, backup
Componentes	DocumentDB clusters (MongoDB-compatible), Redis ElastiCache clusters, S3 buckets (encrypted), EFS file systems
Security Controls	Encryption at rest (AES-256), Database activity monitoring, Backup encryption and versioning, Data loss prevention (DLP), Database firewall rules
Network Restrictions	Inbound: From application zone only, Outbound: Backup to S3, replication, Database ports restricted by security groups

Zona Gestión (Management/Admin):

Atributo	Descripción
Trust Level	High Trust
Risk Level	Medium
Purpose	System administration, monitoring, logging
Componentes	Bastion hosts (EC2 Systems Manager), CloudWatch monitoring, CloudTrail logging, Config compliance checking, Security Hub aggregation
Security Controls	MFA required for all access, Session recording and monitoring, Privileged access management (PAM), Just-in-time access (JIT)
Network Restrictions	VPN or PrivateLink access only, Source IP restrictions, Time-based access controls

C.2 Definición de Interfaces y Flujos de Datos

Interfaces del perímetro de seguridad:

El sistema define cinco interfaces principales que controlan el flujo de datos entre zonas de seguridad:

1. Interface External-DMZ Gateway (Internet → DMZ)

Aspecto	Especificación
Ubicación física	AWS CloudFront Edge Locations
Autenticación	No requerida (público)
Autorización	WAF rules and rate limiting
Cifrado	TLS 1.3 obligatorio
Integridad	Validación HMAC
Logging	Registro completo de request/response
Protocolos permitidos	HTTPS
Puertos permitidos	443
Clasificación de datos	Público a Confidencial
Capacidad máxima	10,000 requests/segundo

Inspección de tráfico (External-DMZ):

Control	Implementación
Escaneo de malware	Sí (CloudFront)
Filtrado de contenido	Sí (WAF)
Detección de anomalías	Sí (GuardDuty)
Bloqueo geográfico	Configurable por país

Monitorización (External-DMZ):

Tipo	Herramientas/Eventos
Alertas en tiempo real	Ataques DDoS, IPs maliciosas, Patrones inusuales
Dashboards	CloudWatch, WAF Console
Integración SIEM	AWS Security Hub

2. Interface DMZ-Application Gateway (DMZ → Zona Aplicación)

Aspecto	Especificación
Ubicación física	AWS Application Load Balancer
Autenticación	Validación de token JWT
Autorización	Aplicación de políticas RBAC
Cifrado	TLS 1.2+ (VPC interna)
Integridad	Validación de firma de request
Session management	JWT sin estado
Protocolos permitidos	HTTP, gRPC
Puertos permitidos	8000, 8443

Security Groups (DMZ-Application):

Dirección	Protocolo	Puerto	Origen/Destino
Inbound	TCP	8000	DMZ_Security_Group
Inbound	TCP	8443	Internal_LB
Outbound	TCP	27017	Data_Zone
Outbound	TCP	6379	Cache_Zone
Outbound	TCP	443	External_APIs

Load Balancing (DMZ-Application):

Parámetro	Valor
Algoritmo	Round robin with health checks
Ruta health check	/health
Intervalo health check	30 segundos
Umbral unhealthy	3 fallos consecutivos

3. Interface Application-Data Gateway (Aplicación → Zona Datos)

Aspecto	Especificación
Ubicación física	AWS Private Subnets
Autenticación	Credenciales de base de datos + IAM roles
Autorización	Permisos a nivel de base de datos
Cifrado	TLS 1.2 + cifrado a nivel de aplicación
Data masking	Enmascaramiento PII/PHI en entornos no productivos
Audit logging	Todas las operaciones de acceso a datos

Conexiones de base de datos (Application-Data):

Base de datos	Puerto	Protocolo	Connection pooling	Configuración adicional
DocumentDB	27017	MongoDB Wire Protocol over TLS	Sí (máx. 100 conexiones)	Read preference: Primary preferred, Write concern: Majority
Redis	6379	RESP over TLS	N/A	Auth token requerido, Timeout: 5s, Retry: Exponential backoff

Controles de flujo de datos (Application-Data):

Control	Implementación
Validación de entrada	Validación de esquema antes de escrituras
Filtrado de salida	Aplicación de clasificación de datos
Rate limiting	Límites por usuario y por endpoint
Transaction logging	Registro de todas las operaciones CRUD

4. Interfaces de Gestión y Administración

Acceso administrativo:

Aspecto	Especificación
Método de acceso	AWS Systems Manager Session Manager
Autenticación	MFA + IAM roles
Autorización	Políticas IAM de mínimo privilegio
Grabación de sesiones	Todas las sesiones registradas en CloudTrail
Restricciones temporales	Solo horario laboral (configurable)
Restricciones de origen	VPN corporativa o IPs aprobadas

Interfaces de monitorización:

Recolección de métricas:

Aspecto	Especificación
Agente	CloudWatch Agent + custom collectors
Frecuencia	Tiempo real (intervalos de 1 minuto)
Cifrado	TLS 1.3 hacia endpoints de CloudWatch
Retención de datos	90 días detallados, 1 año agregados

Agregación de logs:

Aspecto	Especificación
Recolección	CloudWatch Logs + Fluentd
Forwarding	Hacia Security Hub y S3
Parsing	Structured logging (JSON)
Correlación	IDs de correlación cross-service

Interfaces de backup:

Aspecto	Especificación
Red de backup	VPC de backup separada
Replicación	Replicación cross-region hacia eu-central-1
Cifrado	AWS KMS con claves gestionadas por cliente
Controles de acceso	Solo procedimientos break-glass

C.3 Arquitectura de Red

Componentes por zona de seguridad:

Zona	Nivel de confianza	Componentes
Internet	No confiable	Internet Users, Threat Actors
AWS Edge	Perimetral	CloudFront, Web Application Firewall, AWS Shield Advanced
DMZ Zone	Confianza limitada	Application Load Balancer, Internet Gateway
Application Zone	Confianza media	ECS Fargate (AZ1, AZ2), Lambda Functions, Auth Service
Data Zone	Alta confianza	DocumentDB Cluster, Redis Cluster, S3 Encrypted Buckets
Management Zone	Alta confianza	Systems Manager, CloudWatch, CloudTrail, Security Hub

Flujos de tráfico principal:

Origen	Destino	Protocolo/Puerto	Tipo de flujo	Control aplicado
Internet Users	CloudFront	HTTPS/443	Tráfico legítimo	—
Threat Actors	AWS Shield	—	Bloqueado	Protección DDoS
CloudFront	WAF	—	Filtrado	Inspección de contenido
WAF	ALB	—	Tráfico limpio	Validación completada
ALB	ECS Fargate AZ1	HTTP/8000	Balanceo	Health checks
ALB	ECS Fargate AZ2	HTTP/8000	Balanceo	Health checks
ECS Fargate AZ1	DocumentDB	TLS/27017	Base de datos	Cifrado TLS
ECS Fargate AZ2	Redis	TLS/6379	Cache	Cifrado TLS + Auth
ECS Fargate AZ1	S3	—	Backup	Cifrado en reposo

Flujos de gestión y monitorización:

Origen	Destino	Tipo de flujo	Propósito
Systems Manager	ECS Fargate AZ1	Secure Shell	Administración remota segura
Systems Manager	ECS Fargate AZ2	Secure Shell	Administración remota segura
CloudWatch	Security Hub	Logs	Agregación de logs operativos
CloudTrail	Security Hub	Audit	Agregación de eventos de auditoría

Clasificación de zonas por nivel de riesgo:

Nivel de riesgo	Color visual	Zonas
No confiable	Rojo	Internet (Internet Users, Threat Actors)
Medio-Alto	Amarillo	AWS Edge, DMZ Zone
Medio	Verde	Application Zone
Bajo	Azul	Data Zone
Controlado	Rosa	Management Zone

C.4 Matriz de Controles por Zona

External Zone (Zona Externa):

Tipo de control	Controles implementados
Network Controls	DDoS mitigation (AWS Shield Advanced), Geographic IP filtering, Bot protection and CAPTCHA, Rate limiting per source IP
Application Controls	OWASP Top 10 protection (WAF), Input validation at edge, Malicious payload detection
Monitoring Controls	Real-time threat intelligence, Anomaly detection (GuardDuty), Security events correlation

DMZ Zone (Zona Desmilitarizada):

Tipo de control	Controles implementados
Network Controls	Stateful inspection firewall, Network ACLs (NACLs), Security groups (microsegmentation), VPC Flow Logs
Application Controls	TLS certificate validation, HTTP header security, Cookie security enforcement, CORS policy enforcement
Identity Controls	API key validation, JWT token verification, Rate limiting per user

Application Zone (Zona de Aplicación):

Tipo de control	Controles implementados
Compute Controls	Container runtime security (Falco), Image vulnerability scanning, Resource limits and quotas, Process whitelisting
Data Controls	Data encryption in memory, Secure coding practices, Input/output validation, SQL injection prevention
Identity Controls	RBAC policy enforcement, Attribute-based access control, Session management, Audit logging all actions

Data Zone (Zona de Datos):

Tipo de control	Controles implementados
Storage Controls	Encryption at rest (AES-256-GCM), Key management (AWS KMS), Backup encryption, Data versioning and retention
Access Controls	Database firewall rules, Privileged access management, Query monitoring and blocking, Data masking for non-production
Integrity Controls	Database integrity checking, Transaction logging, Change data capture (CDC), Forensic logging

Management Zone (Zona de Gestión):

Tipo de control	Controles implementados
Administrative Controls	Just-in-time access (JIT), Break-glass emergency access, Session recording and playback, Privileged account monitoring
Monitoring Controls	SIEM event correlation, Compliance reporting, Threat hunting capabilities, Incident response orchestration
Audit Controls	Immutable audit logs, Log integrity protection, Compliance evidence collection, Forensic data preservation

C.5 Procedimientos de Control de Perímetro

PRO-PER-001: Validación de cruce de zonas de seguridad

Objetivo: Validar todo el tráfico que cruza entre zonas de seguridad antes de permitir o denegar el acceso.

Proceso de validación:

Paso	Actividad	Acción si falla	Resultado
1	Verificar existencia de regla de cruce	DENY - "No zone crossing rule defined"	Tráfico denegado inmediatamente
2	Validar protocolo permitido	DENY - "Protocol not allowed"	Tráfico denegado con razón específica
3	Ejecutar verificaciones de seguridad	DENY - "Security check failed" + pasos de remediación	Tráfico denegado con guía de corrección
4	Registrar tráfico permitido en logs	—	Auditoría completa del tráfico
5	Permitir tráfico con controles aplicados	—	ALLOW con controles documentados

PRO-PER-002: Verificaciones de seguridad para tráfico entre zonas

Objetivo: Realizar verificaciones de seguridad exhaustivas antes de permitir tráfico entre zonas.

Verificaciones realizadas:

Verificación	Propósito	Impacto si falla
Encryption required	Validar que el cifrado requerido esté presente	Tráfico denegado
Authentication required	Verificar autenticación según requisitos de zona destino	Acceso denegado
Rate limiting	Comprobar límites de tasa entre zonas	Throttling o bloqueo temporal
Malware scanning	Escanear contenido según tipo de tráfico	Cuarentena o bloqueo
Data classification	Validar cumplimiento de clasificación de datos	Bloqueo de datos sensibles

Resultado de verificaciones:

Estado	Condición	Acción
Passed	Todas las verificaciones OK	Permitir tráfico
Failed	Al menos una verificación falló	DENY con indicación de verificación fallida
Remediation	Verificaciones fallidas	Proporcionar pasos de remediación específicos

PRO-PER-003: Monitorización de violaciones del perímetro

Objetivo: Detectar y responder automáticamente a violaciones del perímetro de seguridad.

Indicadores de violación monitorizados:

Indicador	Descripción	Gravedad típica
Unauthorized zone crossing	Tráfico entre zonas sin autorización	HIGH/CRITICAL
Protocol violations	Uso de protocolos no permitidos	MEDIUM/HIGH
Encryption violations	Tráfico sin cifrado cuando es obligatorio	HIGH/CRITICAL
Authentication bypasses	Intentos de evitar autenticación	CRITICAL
Data exfiltration attempts	Intentos de extraer datos sin autorización	CRITICAL

PRO-PER-004: Manejo de violaciones del perímetro

Objetivo: Responder de forma automática y proporcional a violaciones detectadas del perímetro de seguridad.

Matriz de respuesta por severidad:

Severidad	Respuesta inmediata	Alerta	Investigación	Actualización de reglas
CRITICAL	Bloqueo inmediato de fuente	Equipo de seguridad (urgencia HIGH)	Automatizada	Automática si confianza > 80%
HIGH	Aplicar rate limiting a fuente	Equipo de seguridad (urgencia MEDIUM)	Automatizada	Automática si confianza > 80%
MEDIUM/LOW	Registro en log de evento de seguridad	—	Automatizada	Automática si confianza > 80%

Flujo de manejo de violación:

1. Detección: Identificar violación con severidad asignada
2. Respuesta inmediata: Ejecutar acción según tabla de severidad
3. Alerta: Notificar al equipo de seguridad según nivel de urgencia
4. Investigación automatizada: Iniciar análisis forense automatizado
5. Actualización de reglas: Si confianza > 80%, actualizar reglas de seguridad automáticamente
6. Documentación: Registrar ID de violación, respuesta tomada, investigación iniciada, y reglas actualizadas

Referencias Normativas y Guías

Normativa Principal

• Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad
• Reglamento (UE) 2017/745 sobre productos sanitarios (MDR)
• Directiva (UE) 2022/2555 (NIS2) sobre ciberseguridad

Guías CCN-STIC Aplicables

• CCN-STIC-803: Valoración de sistemas en el ENS
• CCN-STIC-804: Guía de implantación del ENS
• CCN-STIC-806: Plan de adecuación del ENS
• CCN-STIC-809: Declaración y certificación de conformidad
• CCN-STIC-811: Interconexión de sistemas
• CCN-STIC-812: Seguridad en entornos y aplicaciones web
• CCN-STIC-821: Normas de seguridad en el ENS
• CCN-STIC-823: Utilización de servicios en la nube

Documentación Relacionada

• GP-110: Procedimiento principal del ENS

Anexo D: Sistema de Interfaces

D.1 Catálogo de Interfaces del Sistema

Catálogo de Interfaces del Sistema:

El sistema mantiene un catálogo completo de interfaces organizadas en tres categorías: interfaces de usuario, interfaces sistema-a-sistema, e interfaces administrativas.

Nota sobre interfaces de usuario

El producto es una API REST. No existe portal web ni aplicación móvil propia. Los profesionales sanitarios y pacientes acceden a través de las aplicaciones de sus organizaciones clientes, que se integran con nuestra API. La seguridad de esas aplicaciones de usuario final es responsabilidad de la organización cliente.

Interfaces de cliente API (Machine-to-Machine):

Interface	Tipo	Consumidores	Nivel de seguridad	Autenticación	Clasificación de datos	Protocolos
API REST pública	RESTful API	Sistemas de organizaciones clientes	Alto	API key + OAuth 2.0 client credentials	Confidential (PHI)	HTTPS

Controles API REST pública:

• Rate limiting por cliente (según contrato)
• Input validation (Pydantic schemas)
• API key rotation recomendada cada 90 días
• Audit logging de todas las peticiones
• IP allowlist (opcional, configurable por cliente)

Interfaces Sistema-a-Sistema (System-to-System):

Interface	Tipo	Propósito	Nivel de seguridad	Autenticación	Clasificación de datos	Estándares
FHIR R4 API	RESTful API	Healthcare data interoperability	Alto	OAuth 2.0 client credentials	Confidential (PHI)	FHIR R4, SMART on FHIR
HL7 v2 Integration	Message-based Integration	Legacy system integration	Medio-Alto	VPN + Mutual TLS	Confidential (Clinical Data)	HL7 v2.5, HL7 v2.8
DICOM Imaging	Medical Imaging Protocol	Medical image exchange	Alto	AE Title + TLS	Confidential (Medical Images)	DICOM 3.0, IHE profiles

Controles FHIR R4 API:

• API rate limiting: 1000 requests/minute
• Request/response validation
• Audit logging all transactions
• Data minimization policies

Controles HL7 v2 Integration:

• Message encryption at rest and transit
• Digital signatures for message integrity
• Sequence number validation
• Acknowledgment tracking

Controles DICOM Imaging:

• Image de-identification
• Audit trail (DICOM Structured Reports)
• Storage commitment verification
• Patient privacy filters

Interfaces Administrativas:

Interface	Tipo	Usuarios	Nivel de seguridad	Autenticación	Clasificación de datos	Protocolos
AWS Management Console	Web-based Management	Cloud Administrators	Alto	IAM + MFA + SAML Federation	Confidential (Infrastructure)	HTTPS
Systems Manager Session	Secure Shell Access	System Administrators	Alto	IAM roles + MFA	Confidential (System Access)	SSM Session Manager

Controles AWS Management Console:

• IP address restrictions
• Time-based access controls
• Session recording
• Least privilege IAM policies

Controles Systems Manager Session:

• No direct SSH access
• All sessions logged and recorded
• Just-in-time access
• Session timeout: 1 hour

D.2 Flujos de Datos entre Interfaces

Flujos de datos entre interfaces:

El sistema gestiona flujos de datos entre sistemas externos, interfaces del sistema, y procesamiento interno.

Sistemas externos conectados:

• Electronic Health Records (EHR)
• Picture Archiving System (PACS)
• Laboratory Systems (LAB)
• Pharmacy Systems (PHARMACY)

Interfaces del sistema:

• FHIR R4 API
• HL7 v2 Gateway
• DICOM Service
• REST API (endpoint principal)

Componentes de procesamiento interno:

• API Gateway
• Authentication Service
• ML Engine
• Database

Flujos de datos principales:

Origen	Destino	Protocolo/Método	Autenticación	Controles de seguridad
EHR	FHIR R4 API	FHIR R4	OAuth 2.0	Rate Limit, Audit Log
PACS	DICOM Service	DICOM/TLS	AE Title Auth	De-identification, Access Control
LAB	HL7 v2 Gateway	HL7 v2.5	VPN + mTLS	Message Validation, Sequence Check
PHARMACY	FHIR R4 API	FHIR R4	Client Credentials	Rate Limit, Audit Log
API Client	API Gateway	HTTPS	API Key + OAuth 2.0 client credentials	Rate Limit, Audit Log
FHIR API	API Gateway	Internal	—	Rate Limit, Audit Log
HL7 Gateway	API Gateway	Internal	—	Message Validation, Sequence Check
DICOM Service	API Gateway	Internal	—	De-identification, Access Control
Authentication	API Gateway	Internal	—	—
API Gateway	ML Engine	Internal	—	—
API Gateway	Database	Internal	—	—

Clasificación de componentes por tipo:

• Sistemas externos (rojo claro): EHR, PACS, LAB, PHARMACY
• Interfaces (verde claro): FHIR, HL7, DICOM, REST API
• Procesamiento interno (azul claro): API Gateway, Authentication Service, ML Engine, Database

D.3 Documentación de Interfaces de Datos

Documentación de Interfaces de Datos:

Implementación FHIR R4:

Aspecto	Especificación
Base URL	https://api.<dominio>/fhir/R4
Recursos soportados	Patient (demographics, identifiers), DiagnosticReport (dermatology findings), Media (clinical images), Observation (clinical measurements), Condition (diagnoses and differential)

Implementación de seguridad FHIR:

Componente	Implementación
OAuth 2 Scopes	patient/*.read (patient data access), user/_.write (healthcare professional access), system/*.read (system integration)
SMART on FHIR	Full compliance with SMART App Launch
Audit Events	FHIR AuditEvent resources for all access

Privacidad de datos FHIR:

Aspecto	Implementación
Consent Management	FHIR Consent resource implementation
Data Segmentation	Patient-level access control
Anonymization	Configurable de-identification

Implementación HL7 v2:

Tipos de mensajes:

Tipo mensaje	Descripción
ADT_A01	Patient admission notification
ORU_R01	Observation result unsolicited
MDM_T02	Medical document management
ACK	General acknowledgment message

Capa de transporte:

Aspecto	Implementación
MLLP over TLS	Minimal Lower Layer Protocol over TLS 1.3
Connection Management	Persistent connections with heartbeat
Error Handling	Automatic retry with exponential backoff

Seguridad de mensajes:

Aspecto	Implementación
Encryption	AES-256-GCM for message payload
Digital Signatures	RSA-PSS signatures for integrity
Sequence Validation	Message sequence number tracking

Implementación DICOM:

Clases de servicio:

Clase de servicio	Descripción
Storage SCP	C-STORE operations for image receipt
Query Retrieve SCP	C-FIND and C-MOVE operations
Verification SCP	C-ECHO for connectivity testing

Transfer Syntaxes soportados:

• Explicit VR Little Endian
• JPEG 2000 Lossless
• JPEG Lossless
• Uncompressed

Implementación de privacidad:

Aspecto	Implementación
De-identification	DICOM Supplement 142 compliance
Audit Trail	DICOM Structured Reports for access
Access Control	Application Entity Title validation

Referencias cruzadas

Controles ENS Relacionados

• OP.PL.1: Análisis de riesgos base para diseño de arquitectura
• OP.ACC.*: Controles de acceso implementados en cada capa
• OP.EXP.*: Controles operacionales para gestión de la arquitectura
• MP.COM.*: Protección de comunicaciones entre componentes
• MP.EQ.*: Protección de equipos en la arquitectura cloud
• OP.CONT.*: Continuidad del servicio mediante arquitectura resiliente

Documentos QMS

• GP-013: Marco general de ciberseguridad
• GP-001: Control documental para documentación de arquitectura

Estándares y Regulaciones

• Real Decreto 311/2022: Artículo 12 - Arquitectura de seguridad
• CCN-STIC 811: Interconexiones en el ENS
• CCN-STIC 821: Normas de seguridad en el ENS
• ISO/IEC 27001:2022: Controls A.8.9 (Configuration management)
• NIST SP 800-53: SA-8 Security Engineering Principles
• MDR (EU) 2017/745: Anexo I, 17.2 (Software lifecycle)

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

• Author: Team members involved
• Reviewer: JD-003 Design & Development Manager, JD-004 Quality Manager & PRRC
• Approver: JD-001 General Manager

ㅤ