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
- 27002:2013
- 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
-
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.
-
La arquitectura de seguridad es elaborada bajo la dirección del Responsable del Sistema, y es aprobada por el Responsable de la Seguridad.
Implementación en Legit Health Plus
Visión General de la Arquitectura de Seguridad
Principios Arquitectónicos
La arquitectura de seguridad de Legit Health Plus 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 | Web Portal, Mobile App, API Client | Interfaces de usuario y cliente |
| 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 (OAuth/OIDC), 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 | OAuth 2.0 + OpenID Connect, Azure AD B2C | MFA obligatorio para HCPs, SSO para organizaciones, Token refresh automático, Session management |
| 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/EDR (CrowdStrike Falcon)
- 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:
- Creación: Clasificación automática, etiquetado
- Almacenamiento: Cifrado en reposo (AES-256-GCM)
- Transmisión: TLS 1.3 mínimo
- Procesamiento: Memoria cifrada, secure enclaves
- Compartición: DLP policies, watermarking
- Archivado: Glacier con vault lock
- 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:
| Rol | Permisos | Auditoría exenta |
|---|---|---|
| SuperAdmin | Acceso completo al sistema | No |
| OrganizationAdmin | Gestionar usuarios de la organización, Ver datos de la organización, Configurar integraciones | No |
| ClinicalUser (HCP) | Acceder a datos de pacientes (propia organización), Enviar diagnósticos, Ver informes | No |
| ITAdmin (ITP) | Gestionar integraciones, Ver logs técnicos, Configurar webhooks | No |
| Patient | Ver datos propios, Gestión de consentimiento, Portabilidad de datos | No |
Atributos adicionales para control de acceso basado en atributos (ABAC):
- Organization ID
- Department
- Location
- Time of access
- Device trust level
4.2 Autenticación y Autorización
Flujo de Autenticación:
El proceso de autenticación sigue un flujo SAML/OIDC con MFA obligatorio:
Secuencia de autenticación del usuario:
| Paso | Actor origen | Actor destino | Acción |
|---|---|---|---|
| 1 | User | App | Usuario solicita login |
| 2 | App | Auth | Aplicación redirige a servicio de autenticación |
| 3 | Auth | IdP | Servicio envía request SAML/OIDC |
| 4 | IdP | User | Identity Provider solicita MFA |
| 5 | User | IdP | Usuario completa desafío MFA |
| 6 | IdP | Auth | IdP envía aserción de identidad |
| 7 | Auth | App | Servicio genera token JWT |
| 8 | App | API | Aplicación llama API con JWT |
| 9 | API | API | API valida JWT internamente |
| 10 | API | App | API responde con datos solicitados |
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 | Elasticsearch | S3 Archive | Kibana |
| System Logs | CloudWatch Logs | Elasticsearch | S3 Archive | Kibana |
| Security Logs | CloudWatch Logs | Elasticsearch | S3 Archive | Kibana |
| AWS CloudTrail | CloudWatch Logs | Elasticsearch | S3 Archive | Kibana |
Todos los logs pasan por CloudWatch Logs para agregación inicial, se envían a Elasticsearch para análisis en tiempo real con visualización en Kibana, y se archivan en S3 para retención a largo plazo y cumplimiento normativo.
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:
- Identificación: Escaneo automático (Trivy, Snyk)
- Evaluación: Análisis CVSS y contexto
- Priorización: Basada en exploitability y impacto
- Remediación: Patching o mitigación
- Verificación: Testing post-patch
- Documentación: Registro en T-024-007
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) | MEDIO (NP30) | 82% Implementado | 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 MEDIA - NP30):
| 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 MEDIO (NP30) según CCN-STIC-821, con refuerzos adicionales para las dimensiones de Integridad, Autenticidad y Trazabilidad que requieren nivel ALTO.
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 | T-024-009 | Descripción técnica completa del sistema | Art. 12 RD 311/2022 | CCN-STIC-811 |
| Análisis de Riesgos | R-TF-013-002 | Identificación y valoración de riesgos | Art. 11 RD 311/2022 | CCN-STIC-803 |
| Modelo de Amenazas | T-024-006 | Análisis de amenazas y vulnerabilidades | op.pl.1 | CCN-STIC-812 |
| Declaración de Aplicabilidad | T-110-003 | 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 | Diagramas en SharePoint | Arquitectura de red y segmentación | op.pl.2 | CCN-STIC-811 |
| Matriz de Flujos de Información | Excel documentado | 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 | T-110-001 | Roadmap de cumplimiento ENS | Art. 40 RD 311/2022 | CCN-STIC-806 |
9.2 Mantenimiento de la Documentación
Proceso de Actualización:
- Revisión trimestral: Validación de accuratez
- Actualización por cambio: Via change management
- Auditoría anual: Revisión completa
- 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:
- Inicial: Arquitectura ad-hoc
- Repetible: Patrones definidos
- Definido: Arquitectura estándar ✓
- Gestionado: Métricas y optimización ✓
- 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 MEDIO • 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), Authentication services (Azure AD B2C), 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:
- Detección: Identificar violación con severidad asignada
- Respuesta inmediata: Ejecutar acción según tabla de severidad
- Alerta: Notificar al equipo de seguridad según nivel de urgencia
- Investigación automatizada: Iniciar análisis forense automatizado
- Actualización de reglas: Si confianza > 80%, actualizar reglas de seguridad automáticamente
- 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
- T-110-001: Plan de implementación del ENS
- T-110-002: Guía de implementación CCN-STIC
- T-110-003: Matriz de cumplimiento ENS
- R-TF-013-002: Registro de análisis de riesgos
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.
Interfaces de Usuario (Human Interfaces):
| Interface | Tipo | Usuarios | Nivel de seguridad | Autenticación | Clasificación de datos | Protocolos |
|---|---|---|---|---|---|---|
| Web Portal HCP | HTTPS Web Application | Healthcare Professionals | Alto | SAML SSO + MFA | Confidential (PHI) | HTTPS, WebSocket Secure |
| Mobile App Patient | Mobile Application (iOS/Android) | Patients | Alto | OAuth 2.0 + Biometric | Confidential (Personal Health) | HTTPS, HTTP/2 |
Controles Web Portal HCP:
- Session timeout: 30 minutes
- Concurrent session limit: 3
- Strong password policy
- Account lockout after 5 failures
Controles Mobile App Patient:
- Certificate pinning
- App attestation
- Root/jailbreak detection
- Runtime application self-protection (RASP)
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 Legit Health Plus:
- FHIR R4 API
- HL7 v2 Gateway
- DICOM Service
- Web Portal
- Mobile App
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 |
| Web Portal | Authentication | HTTPS | SAML + MFA | — |
| Mobile App | Authentication | HTTPS | OAuth + Biometric | — |
| 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, Web Portal, Mobile App
- 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.legitimhealth.com/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
- R-TF-013-002: Análisis de riesgos que informa decisiones arquitectónicas
- T-024-006: Plan de gestión de riesgos de ciberseguridad
- T-024-007: Modelo de amenazas alineado con arquitectura
- 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: Medidas de seguridad nivel medio
- 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)
Registros y Evidencias
- R-110-008: Documentación de arquitectura de seguridad
- R-110-009: Evidencias de implementación de controles
- R-110-010: Registros de cambios arquitectónicos
- R-110-011: Validaciones de seguridad de la arquitectura
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, JD-004
- Approver: JD-001