Skip to main content
QMSQMS
QMS
  • Welcome to your QMS
  • Quality Manual
  • Procedures
    • GP-001 Control of documents
    • GP-002 Quality planning
    • GP-003 Audits
    • GP-004 Vigilance system
    • GP-005 Human Resources and Training
    • GP-006 Non-conformity, Corrective and Preventive actions
    • GP-007 Post-market surveillance
    • GP-008 Product requirements
    • GP-009 Sales
    • GP-010 Purchases and suppliers evaluation
    • GP-011 Provision of service
    • GP-012 Design, redesign and development
    • GP-013 Risk management
    • GP-014 Feedback and complaints
    • GP-015 Clinical evaluation
    • GP-016 Traceability and identification
    • GP-017 Technical assistance service
    • GP-018 Infrastructure and facilities
    • GP-019 Software validation plan
    • GP-020 QMS Data analysis
    • GP-021 Communications
    • GP-022 Document translation
    • GP-023 Change control management
    • GP-024 Predetermined Change Control Plan
    • GP-025 Usability and Human Factors Engineering
    • GP-027 Corporate Governance
    • GP-028 AI Development
    • GP-029 Software Delivery and Commissioning
    • GP-030 Cyber Security Management
    • GP-050 Data Protection
    • GP-051 Security violations
    • GP-052 Data Privacy Impact Assessment (DPIA)
    • GP-100 Business Continuity (BCP) and Disaster Recovery plans (DRP)
    • GP-101 Information security
    • GP-200 Remote Data Acquisition in Clinical Investigations
    • GP-026 Market-specific product requirements
    • GP-110 Esquema Nacional de Seguridad
      • ORG Marco organizativo
      • OP Marco operacional
        • OP.PL Planificación
          • OP.PL.1 Análisis de Riesgos
          • OP.PL.2 Arquitectura de Seguridad
          • OP.PL.3 Adquisición de nuevos componentes
          • OP.PL.4 Dimensionamiento y Gestión de Capacidades
          • OP.PL.5 Componentes Certificados
        • OP.ACC Control de acceso
        • OP.EXP Explotación
        • OP.EXT Servicios externos
        • OP.NUB Servicios en la nube
        • OP.CONT Continuidad del servicio
        • OP.MON Monitorización del sistema
      • MP Medidas de protección
      • Sin asignar
      • Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad.
  • Records
  • Legit.Health Plus Version 1.1.0.0
  • Legit.Health Plus Version 1.1.0.1
  • Licenses and accreditations
  • Applicable Standards and Regulations
  • Grants
  • Pricing
  • Public tenders
  • Procedures
  • GP-110 Esquema Nacional de Seguridad
  • OP Marco operacional
  • OP.PL Planificación
  • OP.PL.2 Arquitectura de Seguridad

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​

  1. 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.

  2. 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:

CapaComponentesFunción
Capa de PresentaciónWeb Portal, Mobile App, API ClientInterfaces de usuario y cliente
Capa de Seguridad PerimetralAWS CloudFront + WAF + Shield, DDoS Protection + Rate LimitingProtección perimetral contra amenazas externas
Capa de AplicaciónAPI Gateway (FastAPI), Auth Service (OAuth/OIDC), ML Engine (PyTorch)Lógica de negocio y procesamiento
Capa de DatosDocumentDB (Encrypted), S3 Bucket (Encrypted), Redis (Cache)Almacenamiento y persistencia de datos

Arquitectura Detallada por Componentes​

Componentes de Infraestructura​

Infraestructura Cloud (AWS):

ComponenteFunciónControles de Seguridad
VPCAislamiento de redSubnets privadas, NACLs, Security Groups
EC2/ECSComputaciónIMDSv2, SSM Session Manager, hardening
S3Almacenamiento objetosCifrado AES-256, versioning, MFA delete
DocumentDBBase de datosTLS, cifrado en reposo, backup automático
CloudFrontCDNHTTPS only, geo-restricción, OAC
Route 53DNSDNSSEC, health checks
KMSGestión de clavesHSM, rotación automática
Secrets ManagerGestión secretosRotación automática, auditoría

Componentes de Aplicación​

Servicios Core:

Servicios principales de la aplicación:

ServicioTecnología/ProtocoloControles de seguridad
API GatewayFastAPI + UvicornRate limiting por IP/usuario, Input validation (Pydantic), CORS configurado restrictivamente, OpenAPI schema validation, Request/response logging
Authentication ServiceOAuth 2.0 + OpenID Connect, Azure AD B2CMFA obligatorio para HCPs, SSO para organizaciones, Token refresh automático, Session management
ML Inference EnginePyTorch + ONNX RuntimeModel signing y verificación, Input sanitization, Sandboxing de ejecución, Resource limits
Image ProcessingOpenCV, Pillow, scikit-imageValidación formato/tamaño, Antivirus scanning, EXIF stripping, Watermarking

2.3 Componentes de Integración​

Interfaces Externas:

InterfaceEstándarSeguridad
FHIRR4OAuth 2.0, TLS 1.3, audit logging
HL7v2.x/v3VPN/TLS, message signing
WebhooksRESTHMAC signing, retry logic
DICOM3.0TLS, 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 redComponentesNivel de seguridadAcceso desde
Public Subnet (DMZ)ALB/NLB, NAT GatewayBajoInternet
Private Subnet (App Tier)ECS Tasks, Lambda Functions, EC2 InstancesMedioDMZ únicamente
Private Subnet (Data Tier)DocumentDB, ElastiCache, EFSAltoApp 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:

FaseActividades principalesControles de seguridad integrados
RequisitosRecopilación de requerimientosRequisitos de seguridad
DiseñoArquitectura y especificacionesThreat Modeling
DesarrolloCodificación e implementaciónSAST/Code Review
TestingPruebas funcionales y de seguridadDAST/Pentesting
DespliegueLanzamiento a producciónSecurity Gates
OperaciónMonitorización continuaMonitoring

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íaEjemplosControles
CríticaDatos médicos, PIICifrado AES-256, acceso MFA
AltaAlgoritmos, configuracionesCifrado, acceso restringido
MediaLogs operativosCifrado en tránsito
BajaDocumentación públicaIntegridad

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:

RolPermisosAuditoría exenta
SuperAdminAcceso completo al sistemaNo
OrganizationAdminGestionar usuarios de la organización, Ver datos de la organización, Configurar integracionesNo
ClinicalUser (HCP)Acceder a datos de pacientes (propia organización), Enviar diagnósticos, Ver informesNo
ITAdmin (ITP)Gestionar integraciones, Ver logs técnicos, Configurar webhooksNo
PatientVer datos propios, Gestión de consentimiento, Portabilidad de datosNo

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:

PasoActor origenActor destinoAcción
1UserAppUsuario solicita login
2AppAuthAplicación redirige a servicio de autenticación
3AuthIdPServicio envía request SAML/OIDC
4IdPUserIdentity Provider solicita MFA
5UserIdPUsuario completa desafío MFA
6IdPAuthIdP envía aserción de identidad
7AuthAppServicio genera token JWT
8AppAPIAplicación llama API con JWT
9APIAPIAPI valida JWT internamente
10APIAppAPI 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 logsDestino primarioDestino secundarioDestino terciarioVisualización
Application LogsCloudWatch LogsElasticsearchS3 ArchiveKibana
System LogsCloudWatch LogsElasticsearchS3 ArchiveKibana
Security LogsCloudWatch LogsElasticsearchS3 ArchiveKibana
AWS CloudTrailCloudWatch LogsElasticsearchS3 ArchiveKibana

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:

NivelSeveridadTiempo RespuestaEscalado
P1Crítica< 15 minCISO + CEO
P2Alta< 1 horaCISO + CTO
P3Media< 4 horasSecurity Team
P4Baja< 24 horasSOC

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:

ComponenteRPORTOMétodo
Base de datos1 hora2 horasContinuous backup
Archivos S324 horas4 horasCross-region replication
ConfiguraciónReal-time30 minIaC (Terraform)
AplicaciónN/A1 horaBlue-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 ZoneECS TasksDocumentDBFunción
AZ 1 (eu-west-1a)ActivePrimaryZona principal de procesamiento y escritura
AZ 2 (eu-west-1b)ActiveReplicaZona secundaria activa con réplica de lectura
AZ 3 (eu-west-1c)StandbyReplicaZona 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:

ComponenteVersiónCriticidadÚltimo Análisis
FastAPI0.104.xAlta2025-08-01
PyTorch2.1.xAlta2025-08-01
OpenCV4.8.xMedia2025-07-15
Pydantic2.4.xAlta2025-08-01
Redis7.2.xMedia2025-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 T-024-007

8. Cumplimiento y Certificaciones​

8.1 Frameworks de Cumplimiento​

FrameworkNivelEstadoAuditoríaReferencia Normativa
ISO 27001:2022CompletoCertificadoAnualBase para ENS
ENS (RD 311/2022)MEDIO (NP30)82% ImplementadoBienalObligatorio
RGPD/GDPRCompletoConformeContinuaArt. 32 Seguridad
FDA CybersecurityCompletoValidadoPor cambioPremarket Guidance
MDR (EU) 2017/745Clase IIaConformeAnualAnexo I, 17.2-17.4
NIS2EsencialConformeAnualDirectiva (EU) 2022/2555

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

Estado de Implementación por Dominio (Categoría MEDIA - NP30):

Dominio ENSCódigoControles RequeridosImplementados% CumplimientoCCN-STIC Ref
Marco Organizativoorg.*55100%CCN-STIC-821 Sección 4
org.1 Política de seguridadorg.1✅✅100%Art. 11 RD 311/2022
org.2 Normativa de seguridadorg.2✅✅100%Art. 11 RD 311/2022
org.3 Procedimientosorg.3✅✅100%Art. 13 RD 311/2022
org.4 Proceso autorizaciónorg.4✅✅100%Art. 13 RD 311/2022
Marco Operacionalop.*322578%CCN-STIC-821 Sección 5
op.pl Planificaciónop.pl.*5480%Art. 12 RD 311/2022
op.pl.2 Arquitectura seguridadop.pl.2✅✅100%Art. 12 RD 311/2022
op.acc Control accesoop.acc.*7686%Art. 14 RD 311/2022
op.exp Explotaciónop.exp.*11873%Art. 16 RD 311/2022
op.cont Continuidadop.cont.*4375%Art. 17 RD 311/2022
op.mon Monitorizaciónop.mon.*2150%Art. 16 RD 311/2022
Medidas Protecciónmp.*453476%CCN-STIC-821 Sección 6
mp.if Instalacionesmp.if.*9889%Anexo II RD 311/2022
mp.per Personalmp.per.*44100%Anexo II RD 311/2022
mp.eq Equiposmp.eq.*5480%Anexo II RD 311/2022
mp.com Comunicacionesmp.com.*4375%Anexo II RD 311/2022
mp.si Soportesmp.si.*7571%Anexo II RD 311/2022
mp.sw Softwaremp.sw.*6467%Anexo II RD 311/2022
mp.info Informaciónmp.info.*6467%Anexo II RD 311/2022
mp.s Serviciosmp.s.*4250%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:

DocumentoCódigoPropósitoRequisito ENSCCN-STIC
Documento de Arquitectura de SeguridadT-024-009Descripción técnica completa del sistemaArt. 12 RD 311/2022CCN-STIC-811
Análisis de RiesgosR-TF-013-002Identificación y valoración de riesgosArt. 11 RD 311/2022CCN-STIC-803
Modelo de AmenazasT-024-006Análisis de amenazas y vulnerabilidadesop.pl.1CCN-STIC-812
Declaración de AplicabilidadT-110-003Matriz de cumplimiento ENSArt. 41 RD 311/2022CCN-STIC-804
Inventario de ActivosGP-110/op.exp.1Registro completo de activosop.exp.1CCN-STIC-821
Topología de RedDiagramas en SharePointArquitectura de red y segmentaciónop.pl.2CCN-STIC-811
Matriz de Flujos de InformaciónExcel documentadoIntercambio de información entre componentesmp.com.1CCN-STIC-811
Procedimientos OperativosGP-110/*Runbooks y guías operativasorg.3CCN-STIC-821
Plan de AdecuaciónT-110-001Roadmap de cumplimiento ENSArt. 40 RD 311/2022CCN-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étricaObjetivoActualTendencia
Cobertura de segmentación100%98%↑
Componentes parcheados>95%97%→
Tiempo detección amenazas<1 hora45 min↓
Disponibilidad servicios99.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​

RolResponsabilidades
Enterprise ArchitectDiseño y evolución de la arquitectura
Security ArchitectControles de seguridad y threat modeling
Cloud ArchitectInfraestructura AWS y optimización
Solution ArchitectIntegración de componentes
CISOAprobació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):

TrimestreIniciativas ENSControles CCN-STICEstado ObjetivoPresupuesto
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:

EntornoRegión AWSVPC CIDRSubnets públicasSubnets privadas (App)Subnets privadas (Data)Características
Productioneu-west-110.0.0.0/1610.0.1.0/24, 10.0.2.0/2410.0.10.0/24, 10.0.11.0/2410.0.20.0/24, 10.0.21.0/24Entorno productivo con controles estrictos
Stagingeu-west-110.1.0.0/16Similar a ProductionSimilar a ProductionSimilar a ProductionRéplica de producción para testing
Developmenteu-west-210.2.0.0/16Configuración simplificadaConfiguración simplificadaConfiguración simplificadaAcceso más permisivo para developers

Anexo B: Matriz de Comunicaciones​

OrigenDestinoPuertoProtocoloCifrado
InternetALB443HTTPSTLS 1.3
ALBECS Tasks8000HTTPVPC interno
ECS TasksDocumentDB27017MongoDB WireTLS 1.2
ECS TasksRedis6379RedisTLS + AUTH
ECS TasksS3443HTTPSTLS 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:

ZonaNivel de confianzaNivel de riesgoPropósito
External ZoneUntrustedAltoInternet público no confiable
DMZ ZoneLimited TrustMedio-AltoServicios públicos, balanceo de carga
Application ZoneMedium TrustMedioLógica de negocio, procesamiento API, autenticación
Data ZoneHigh TrustBajo-MedioAlmacenamiento, procesamiento, backup de datos
Management ZoneHigh TrustMedioAdministración, monitorización, logging

Zona Externa (Internet/Untrusted):

AtributoDescripción
Trust LevelUntrusted
Risk LevelHigh
ConnectivityPublic Internet
ControlesDDoS Protection (AWS Shield Advanced), Geographic blocking (CloudFront), Rate limiting (WAF), Bot detection and mitigation

Zona DMZ (Desmilitarizada):

AtributoDescripción
Trust LevelLimited Trust
Risk LevelMedium-High
PurposePublic-facing services, load balancing
ComponentesApplication Load Balancer (ALB), CloudFront CDN, WAF (Web Application Firewall), API Gateway (external endpoints)
Security ControlsTLS termination and inspection, HTTP/HTTPS filtering, Request validation and sanitization, SSL/TLS certificate management
Network RestrictionsInbound: HTTPS (443) only, Outbound: Limited to internal zones, Logging: Full packet capture

Zona Aplicación (Application Tier):

AtributoDescripción
Trust LevelMedium Trust
Risk LevelMedium
PurposeBusiness logic, API processing, authentication
ComponentesECS Fargate containers, Lambda functions, API Gateway (internal), Authentication services (Azure AD B2C), ML inference engines
Security ControlsContainer security scanning, Runtime protection (Falco), Secrets management (AWS Secrets Manager), Application-level encryption, Code integrity verification
Network RestrictionsInbound: From DMZ only (port 8000), Outbound: To data zone and external APIs, Inter-service: Service mesh (Istio)

Zona Datos (Data Tier):

AtributoDescripción
Trust LevelHigh Trust
Risk LevelLow-Medium
PurposeData storage, processing, backup
ComponentesDocumentDB clusters (MongoDB-compatible), Redis ElastiCache clusters, S3 buckets (encrypted), EFS file systems
Security ControlsEncryption at rest (AES-256), Database activity monitoring, Backup encryption and versioning, Data loss prevention (DLP), Database firewall rules
Network RestrictionsInbound: From application zone only, Outbound: Backup to S3, replication, Database ports restricted by security groups

Zona Gestión (Management/Admin):

AtributoDescripción
Trust LevelHigh Trust
Risk LevelMedium
PurposeSystem administration, monitoring, logging
ComponentesBastion hosts (EC2 Systems Manager), CloudWatch monitoring, CloudTrail logging, Config compliance checking, Security Hub aggregation
Security ControlsMFA required for all access, Session recording and monitoring, Privileged access management (PAM), Just-in-time access (JIT)
Network RestrictionsVPN 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)​
AspectoEspecificación
Ubicación físicaAWS CloudFront Edge Locations
AutenticaciónNo requerida (público)
AutorizaciónWAF rules and rate limiting
CifradoTLS 1.3 obligatorio
IntegridadValidación HMAC
LoggingRegistro completo de request/response
Protocolos permitidosHTTPS
Puertos permitidos443
Clasificación de datosPúblico a Confidencial
Capacidad máxima10,000 requests/segundo

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

ControlImplementación
Escaneo de malwareSí (CloudFront)
Filtrado de contenidoSí (WAF)
Detección de anomalíasSí (GuardDuty)
Bloqueo geográficoConfigurable por país

Monitorización (External-DMZ):

TipoHerramientas/Eventos
Alertas en tiempo realAtaques DDoS, IPs maliciosas, Patrones inusuales
DashboardsCloudWatch, WAF Console
Integración SIEMAWS Security Hub
2. Interface DMZ-Application Gateway (DMZ → Zona Aplicación)​
AspectoEspecificación
Ubicación físicaAWS Application Load Balancer
AutenticaciónValidación de token JWT
AutorizaciónAplicación de políticas RBAC
CifradoTLS 1.2+ (VPC interna)
IntegridadValidación de firma de request
Session managementJWT sin estado
Protocolos permitidosHTTP, gRPC
Puertos permitidos8000, 8443

Security Groups (DMZ-Application):

DirecciónProtocoloPuertoOrigen/Destino
InboundTCP8000DMZ_Security_Group
InboundTCP8443Internal_LB
OutboundTCP27017Data_Zone
OutboundTCP6379Cache_Zone
OutboundTCP443External_APIs

Load Balancing (DMZ-Application):

ParámetroValor
AlgoritmoRound robin with health checks
Ruta health check/health
Intervalo health check30 segundos
Umbral unhealthy3 fallos consecutivos
3. Interface Application-Data Gateway (Aplicación → Zona Datos)​
AspectoEspecificación
Ubicación físicaAWS Private Subnets
AutenticaciónCredenciales de base de datos + IAM roles
AutorizaciónPermisos a nivel de base de datos
CifradoTLS 1.2 + cifrado a nivel de aplicación
Data maskingEnmascaramiento PII/PHI en entornos no productivos
Audit loggingTodas las operaciones de acceso a datos

Conexiones de base de datos (Application-Data):

Base de datosPuertoProtocoloConnection poolingConfiguración adicional
DocumentDB27017MongoDB Wire Protocol over TLSSí (máx. 100 conexiones)Read preference: Primary preferred, Write concern: Majority
Redis6379RESP over TLSN/AAuth token requerido, Timeout: 5s, Retry: Exponential backoff

Controles de flujo de datos (Application-Data):

ControlImplementación
Validación de entradaValidación de esquema antes de escrituras
Filtrado de salidaAplicación de clasificación de datos
Rate limitingLímites por usuario y por endpoint
Transaction loggingRegistro de todas las operaciones CRUD
4. Interfaces de Gestión y Administración​

Acceso administrativo:

AspectoEspecificación
Método de accesoAWS Systems Manager Session Manager
AutenticaciónMFA + IAM roles
AutorizaciónPolíticas IAM de mínimo privilegio
Grabación de sesionesTodas las sesiones registradas en CloudTrail
Restricciones temporalesSolo horario laboral (configurable)
Restricciones de origenVPN corporativa o IPs aprobadas

Interfaces de monitorización:

Recolección de métricas:

AspectoEspecificación
AgenteCloudWatch Agent + custom collectors
FrecuenciaTiempo real (intervalos de 1 minuto)
CifradoTLS 1.3 hacia endpoints de CloudWatch
Retención de datos90 días detallados, 1 año agregados

Agregación de logs:

AspectoEspecificación
RecolecciónCloudWatch Logs + Fluentd
ForwardingHacia Security Hub y S3
ParsingStructured logging (JSON)
CorrelaciónIDs de correlación cross-service

Interfaces de backup:

AspectoEspecificación
Red de backupVPC de backup separada
ReplicaciónReplicación cross-region hacia eu-central-1
CifradoAWS KMS con claves gestionadas por cliente
Controles de accesoSolo procedimientos break-glass

C.3 Arquitectura de Red​

Componentes por zona de seguridad:

ZonaNivel de confianzaComponentes
InternetNo confiableInternet Users, Threat Actors
AWS EdgePerimetralCloudFront, Web Application Firewall, AWS Shield Advanced
DMZ ZoneConfianza limitadaApplication Load Balancer, Internet Gateway
Application ZoneConfianza mediaECS Fargate (AZ1, AZ2), Lambda Functions, Auth Service
Data ZoneAlta confianzaDocumentDB Cluster, Redis Cluster, S3 Encrypted Buckets
Management ZoneAlta confianzaSystems Manager, CloudWatch, CloudTrail, Security Hub

Flujos de tráfico principal:

OrigenDestinoProtocolo/PuertoTipo de flujoControl aplicado
Internet UsersCloudFrontHTTPS/443Tráfico legítimo—
Threat ActorsAWS Shield—BloqueadoProtección DDoS
CloudFrontWAF—FiltradoInspección de contenido
WAFALB—Tráfico limpioValidación completada
ALBECS Fargate AZ1HTTP/8000BalanceoHealth checks
ALBECS Fargate AZ2HTTP/8000BalanceoHealth checks
ECS Fargate AZ1DocumentDBTLS/27017Base de datosCifrado TLS
ECS Fargate AZ2RedisTLS/6379CacheCifrado TLS + Auth
ECS Fargate AZ1S3—BackupCifrado en reposo

Flujos de gestión y monitorización:

OrigenDestinoTipo de flujoPropósito
Systems ManagerECS Fargate AZ1Secure ShellAdministración remota segura
Systems ManagerECS Fargate AZ2Secure ShellAdministración remota segura
CloudWatchSecurity HubLogsAgregación de logs operativos
CloudTrailSecurity HubAuditAgregación de eventos de auditoría

Clasificación de zonas por nivel de riesgo:

Nivel de riesgoColor visualZonas
No confiableRojoInternet (Internet Users, Threat Actors)
Medio-AltoAmarilloAWS Edge, DMZ Zone
MedioVerdeApplication Zone
BajoAzulData Zone
ControladoRosaManagement Zone

C.4 Matriz de Controles por Zona​

External Zone (Zona Externa):

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

DMZ Zone (Zona Desmilitarizada):

Tipo de controlControles implementados
Network ControlsStateful inspection firewall, Network ACLs (NACLs), Security groups (microsegmentation), VPC Flow Logs
Application ControlsTLS certificate validation, HTTP header security, Cookie security enforcement, CORS policy enforcement
Identity ControlsAPI key validation, JWT token verification, Rate limiting per user

Application Zone (Zona de Aplicación):

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

Data Zone (Zona de Datos):

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

Management Zone (Zona de Gestión):

Tipo de controlControles implementados
Administrative ControlsJust-in-time access (JIT), Break-glass emergency access, Session recording and playback, Privileged account monitoring
Monitoring ControlsSIEM event correlation, Compliance reporting, Threat hunting capabilities, Incident response orchestration
Audit ControlsImmutable 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:

PasoActividadAcción si fallaResultado
1Verificar existencia de regla de cruceDENY - "No zone crossing rule defined"Tráfico denegado inmediatamente
2Validar protocolo permitidoDENY - "Protocol not allowed"Tráfico denegado con razón específica
3Ejecutar verificaciones de seguridadDENY - "Security check failed" + pasos de remediaciónTráfico denegado con guía de corrección
4Registrar tráfico permitido en logs—Auditoría completa del tráfico
5Permitir 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ónPropósitoImpacto si falla
Encryption requiredValidar que el cifrado requerido esté presenteTráfico denegado
Authentication requiredVerificar autenticación según requisitos de zona destinoAcceso denegado
Rate limitingComprobar límites de tasa entre zonasThrottling o bloqueo temporal
Malware scanningEscanear contenido según tipo de tráficoCuarentena o bloqueo
Data classificationValidar cumplimiento de clasificación de datosBloqueo de datos sensibles

Resultado de verificaciones:

EstadoCondiciónAcción
PassedTodas las verificaciones OKPermitir tráfico
FailedAl menos una verificación fallóDENY con indicación de verificación fallida
RemediationVerificaciones fallidasProporcionar 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:

IndicadorDescripciónGravedad típica
Unauthorized zone crossingTráfico entre zonas sin autorizaciónHIGH/CRITICAL
Protocol violationsUso de protocolos no permitidosMEDIUM/HIGH
Encryption violationsTráfico sin cifrado cuando es obligatorioHIGH/CRITICAL
Authentication bypassesIntentos de evitar autenticaciónCRITICAL
Data exfiltration attemptsIntentos de extraer datos sin autorizaciónCRITICAL
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:

SeveridadRespuesta inmediataAlertaInvestigaciónActualización de reglas
CRITICALBloqueo inmediato de fuenteEquipo de seguridad (urgencia HIGH)AutomatizadaAutomática si confianza > 80%
HIGHAplicar rate limiting a fuenteEquipo de seguridad (urgencia MEDIUM)AutomatizadaAutomática si confianza > 80%
MEDIUM/LOWRegistro en log de evento de seguridad—AutomatizadaAutomá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
  • 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):

InterfaceTipoUsuariosNivel de seguridadAutenticaciónClasificación de datosProtocolos
Web Portal HCPHTTPS Web ApplicationHealthcare ProfessionalsAltoSAML SSO + MFAConfidential (PHI)HTTPS, WebSocket Secure
Mobile App PatientMobile Application (iOS/Android)PatientsAltoOAuth 2.0 + BiometricConfidential (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):

InterfaceTipoPropósitoNivel de seguridadAutenticaciónClasificación de datosEstándares
FHIR R4 APIRESTful APIHealthcare data interoperabilityAltoOAuth 2.0 client credentialsConfidential (PHI)FHIR R4, SMART on FHIR
HL7 v2 IntegrationMessage-based IntegrationLegacy system integrationMedio-AltoVPN + Mutual TLSConfidential (Clinical Data)HL7 v2.5, HL7 v2.8
DICOM ImagingMedical Imaging ProtocolMedical image exchangeAltoAE Title + TLSConfidential (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:

InterfaceTipoUsuariosNivel de seguridadAutenticaciónClasificación de datosProtocolos
AWS Management ConsoleWeb-based ManagementCloud AdministratorsAltoIAM + MFA + SAML FederationConfidential (Infrastructure)HTTPS
Systems Manager SessionSecure Shell AccessSystem AdministratorsAltoIAM roles + MFAConfidential (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:

OrigenDestinoProtocolo/MétodoAutenticaciónControles de seguridad
EHRFHIR R4 APIFHIR R4OAuth 2.0Rate Limit, Audit Log
PACSDICOM ServiceDICOM/TLSAE Title AuthDe-identification, Access Control
LABHL7 v2 GatewayHL7 v2.5VPN + mTLSMessage Validation, Sequence Check
PHARMACYFHIR R4 APIFHIR R4Client CredentialsRate Limit, Audit Log
Web PortalAuthenticationHTTPSSAML + MFA—
Mobile AppAuthenticationHTTPSOAuth + Biometric—
FHIR APIAPI GatewayInternal—Rate Limit, Audit Log
HL7 GatewayAPI GatewayInternal—Message Validation, Sequence Check
DICOM ServiceAPI GatewayInternal—De-identification, Access Control
AuthenticationAPI GatewayInternal——
API GatewayML EngineInternal——
API GatewayDatabaseInternal——

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:

AspectoEspecificación
Base URLhttps://api.legitimhealth.com/fhir/R4
Recursos soportadosPatient (demographics, identifiers), DiagnosticReport (dermatology findings), Media (clinical images), Observation (clinical measurements), Condition (diagnoses and differential)

Implementación de seguridad FHIR:

ComponenteImplementación
OAuth 2 Scopespatient/*.read (patient data access), user/_.write (healthcare professional access), system/*.read (system integration)
SMART on FHIRFull compliance with SMART App Launch
Audit EventsFHIR AuditEvent resources for all access

Privacidad de datos FHIR:

AspectoImplementación
Consent ManagementFHIR Consent resource implementation
Data SegmentationPatient-level access control
AnonymizationConfigurable de-identification

Implementación HL7 v2:

Tipos de mensajes:

Tipo mensajeDescripción
ADT_A01Patient admission notification
ORU_R01Observation result unsolicited
MDM_T02Medical document management
ACKGeneral acknowledgment message

Capa de transporte:

AspectoImplementación
MLLP over TLSMinimal Lower Layer Protocol over TLS 1.3
Connection ManagementPersistent connections with heartbeat
Error HandlingAutomatic retry with exponential backoff

Seguridad de mensajes:

AspectoImplementación
EncryptionAES-256-GCM for message payload
Digital SignaturesRSA-PSS signatures for integrity
Sequence ValidationMessage sequence number tracking

Implementación DICOM:

Clases de servicio:

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

Transfer Syntaxes soportados:

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

Implementación de privacidad:

AspectoImplementación
De-identificationDICOM Supplement 142 compliance
Audit TrailDICOM Structured Reports for access
Access ControlApplication 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
Previous
OP.PL.1 Análisis de Riesgos
Next
OP.PL.3 Adquisición de nuevos componentes
  • Documentos de referencia
  • Guía de implantación
  • Implementación en Legit Health Plus
    • Visión General de la Arquitectura de Seguridad
      • Principios Arquitectónicos
      • Modelo de Referencia
    • Arquitectura Detallada por Componentes
      • Componentes de Infraestructura
      • Componentes de Aplicación
      • 2.3 Componentes de Integración
    • 3. Arquitectura de Seguridad por Capas
      • 3.1 Capa 1: Seguridad Física
      • 3.2 Capa 2: Seguridad de Red
      • 3.3 Capa 3: Seguridad de Host
      • 3.4 Capa 4: Seguridad de Aplicación
      • 3.5 Capa 5: Seguridad de Datos
    • 4. Mecanismos de Control de Acceso
      • 4.1 Modelo de Control de Acceso
      • 4.2 Autenticación y Autorización
    • 5. Arquitectura de Monitorización y Respuesta
      • 5.1 Security Information and Event Management (SIEM)
      • 5.2 Incident Response Architecture
    • 6. Arquitectura de Continuidad y Recuperación
      • 6.1 Backup y Recovery
      • 6.2 Alta Disponibilidad
    • 7. Gestión de Componentes SOUP
      • 7.1 Inventario de Componentes
      • 7.2 Gestión de Vulnerabilidades SOUP
    • 8. Cumplimiento y Certificaciones
      • 8.1 Frameworks de Cumplimiento
      • 8.2 Controles ENS Implementados según CCN-STIC-804
    • 9. Documentación de la Arquitectura según ENS
      • 9.1 Documentos de Arquitectura Requeridos por RD 311/2022
      • 9.2 Mantenimiento de la Documentación
    • 10. Métricas de Arquitectura
      • 10.1 KPIs de Seguridad
      • 10.2 Indicadores de Madurez
    • 11. Responsabilidades
      • 11.1 Roles y Responsabilidades
      • 11.2 Comité de Arquitectura
    • 12. Evolución y Roadmap de Cumplimiento ENS
      • 12.1 Plan de Mejora según CCN-STIC-806
      • 12.2 Tecnologías Emergentes
    • Anexo A: Diagrama de Despliegue Detallado
    • Anexo B: Matriz de Comunicaciones
    • Anexo C: Definición Completa del Perímetro de Seguridad
      • C.1 Zonas de Seguridad y Fronteras
      • C.2 Definición de Interfaces y Flujos de Datos
        • 1. Interface External-DMZ Gateway (Internet → DMZ)
        • 2. Interface DMZ-Application Gateway (DMZ → Zona Aplicación)
        • 3. Interface Application-Data Gateway (Aplicación → Zona Datos)
        • 4. Interfaces de Gestión y Administración
      • C.3 Arquitectura de Red
      • C.4 Matriz de Controles por Zona
      • C.5 Procedimientos de Control de Perímetro
        • PRO-PER-001: Validación de cruce de zonas de seguridad
        • PRO-PER-002: Verificaciones de seguridad para tráfico entre zonas
        • PRO-PER-003: Monitorización de violaciones del perímetro
        • PRO-PER-004: Manejo de violaciones del perímetro
  • Referencias Normativas y Guías
    • Normativa Principal
    • Guías CCN-STIC Aplicables
    • Documentación Relacionada
    • Anexo D: Sistema de Interfaces
      • D.1 Catálogo de Interfaces del Sistema
      • D.2 Flujos de Datos entre Interfaces
      • D.3 Documentación de Interfaces de Datos
  • Referencias cruzadas
    • Controles ENS Relacionados
    • Documentos QMS
    • Estándares y Regulaciones
    • Registros y Evidencias
All the information contained in this QMS is confidential. The recipient agrees not to transmit or reproduce the information, neither by himself nor by third parties, through whichever means, without obtaining the prior written permission of Legit.Health (AI LABS GROUP S.L.)