OP.EXP.3 Gestión de la configuración

Documentos de referencia

• NIST SP 800-53 rev4:
  • [CM-3] Configuration Change Control
  • [CM-9] Configuration Management Plan
• Otras referencias:
  • SANS - CIS Critical Security Controls - Version 6.1
    • CSC.3 - Secure Configurations for Hardware and Software
  • NIST 800-128 Guide for Security-Focused Configuration Management of Information Systems

Guía de implantación

195. Por encima de la configuración de cada equipo, hay que tener una visión integral del sistema, de los equipos que trabajan coordinadamente, de la estructura de líneas de defensa en profundidad y de la dinámica del sistema: su evolución temporal desde el punto de vista de arquitectura del sistema y desde el punto de vista de actualizaciones de los componentes.

196. Los cambios deben ser controlados y la configuración debe ir a la par.

Implementación en Legit Health Plus

Sistema de Gestión de Configuración (CMDB)

Arquitectura del sistema

La organización mantiene una arquitectura de gestión de configuración que integra tres capas principales:

Configuration Items (CIs) - Componentes del Sistema:

• Load Balancer → Aplicación Web → API Backend
• El API Backend se conecta a:
  • Base de Datos
  • Modelos de IA
  • Storage S3

Configuration Management - Gestión:

• ServiceNow CMDB (Configuration Management Database) coordina con:
  • Git Repository (control de versiones del código)
  • CI/CD Pipeline (automatización de despliegues)
  • Terraform State (estado de infraestructura)
• Ansible Inventory alimenta información al CMDB

Monitoring - Monitorización:

• AWS Config y Azure Policy reportan cambios al CMDB
• Prometheus recolecta métricas → Grafana visualiza dashboards

Categorías de elementos de configuración (CIs)

Nivel 1: Componentes críticos del dispositivo médico

Categoría: MEDICAL_CRITICAL

Elementos Controlados:

1. Algoritmos de Diagnóstico:
   • Modelo de Clasificación de Lesiones: v2.3.1
   • Modelo de Severidad ALEGI: v1.8.0
   • Modelo Predictor DLQI: v1.2.4
2. Configuración Clínica:
   • Umbrales de Diagnóstico
   • Parámetros de Sensibilidad
   • Mapeo a terminología ICD-11

Control de Cambios: Requiere validación clínica completa y aprobación del Chief Medical Officer (CMO)

Trazabilidad: Todos los cambios están vinculados al Design History File (DHF) y registros de Verificación y Validación (V&V)

Nivel 2: Infraestructura de soporte

Categoría: INFRASTRUCTURE

Elementos Controlados:

1. Servidores:
   • Web Servers: web-01, web-02, web-03
   • API Servers: api-01, api-02
   • DB Cluster: db-master, db-replica-01
2. Networking:
   • Configuración VPC
   • Security Groups
   • Reglas WAF (Web Application Firewall)
3. Servicios Cloud:
   • AWS Lambda Functions
   • Azure Cognitive Services

Control de Cambios: Aprobación requerida del Change Advisory Board (CAB)

Trazabilidad: Registro completo mediante tickets en ServiceNow

Proceso de gestión de configuración

Identificación y registro

Proceso de Registro de Elementos de Configuración (CIs):

La organización registra todos los elementos de configuración en ServiceNow CMDB con la siguiente información:

Tipos de CIs Soportados:

• SOFTWARE - Aplicaciones y componentes de software
• HARDWARE - Equipos físicos y servidores
• ALGORITHM - Modelos de IA y algoritmos diagnósticos
• DOCUMENTATION - Documentación técnica y regulatoria
• NETWORK - Componentes de red y configuraciones
• SERVICE - Servicios cloud y APIs

Información Capturada en el Registro:

• ID Único: Generado automáticamente (formato CI-XXXXXXXX)
• Nombre: Identificador descriptivo del elemento
• Tipo: Categoría del CI
• Criticidad: CRITICAL, HIGH, MEDIUM, o LOW
• Versión: Número de versión actual
• Estado: DRAFT, ACTIVE, DEPRECATED, RETIRED
• Propietario: Responsable del CI
• Dependencias: Lista de CIs relacionados
• Fecha de Creación: Timestamp UTC
• Componente de Dispositivo Médico: Sí/No
• Impacto Regulatorio: Nivel de impacto en compliance

Proceso de Registro en CMDB:

1. Crear CI con todos los metadatos requeridos
2. Determinar Requisitos Regulatorios Aplicables:
   • Si es componente de dispositivo médico:
     • MDR Annex I - General Safety and Performance Requirements
     • IEC 62304 - Medical Device Software Lifecycle
     • FDA 21 CFR Part 820 - Quality System Regulation
   • Si es algoritmo de IA:
     • ISO 14971 - Risk Management
     • FDA Guidance - AI/ML-Based SaMD
     • EU AI Act - High Risk System Requirements
3. Registrar en ServiceNow CMDB mediante API
4. Estado de Validación:
   • PENDING si es componente de dispositivo médico
   • N/A para componentes no médicos
5. Crear entrada en audit log con detalles del registro

Control de versiones

Política de Versionado:

La organización utiliza el formato de versionado MAJOR.MINOR.PATCH.BUILD para todos los elementos de configuración.

Nivel	Descripción	Aprobación Requerida	Validación	Ejemplos
MAJOR	Cambios que afectan la indicación clínica	CMO + Regulatory Affairs	Estudio clínico completo	• Nuevo algoritmo diagnóstico • Nueva indicación de uso • Cambio en población objetivo
MINOR	Mejoras funcionales sin impacto clínico	CTO + QA Manager	Pruebas de regresión completas	• Mejoras en UI/UX • Nuevas integraciones • Optimizaciones de rendimiento
PATCH	Correcciones y ajustes menores	DevOps Lead	Pruebas unitarias y de integración	• Bug fixes • Actualizaciones de seguridad • Ajustes de configuración
BUILD	Número de compilación automático	Automático	CI/CD pipeline	• Generado automáticamente en cada compilación

Control de cambios

Flujo de Control de Cambios - Legit Health Plus

Fase 1: Solicitud de Cambio

1. Iniciación (RFC - Request for Change)
   • Formulario T-024-006 en ServiceNow
   • Clasificación automática según CI afectado
   • Asignación de prioridad (P1-P4)
2. Evaluación de Impacto
   • Análisis de riesgos (R-TF-013-002)
   • Impacto clínico (si aplica)
   • Impacto regulatorio
   • Dependencias identificadas

Fase 2: Aprobación

Matriz de Aprobación

Tipo de Cambio	Aprobador Nivel 1	Aprobador Nivel 2	CAB Requerido
Algoritmo IA	Clinical Safety Officer	Chief Medical Officer	Sí
Configuración Crítica	Security Officer	CTO	Sí
Infraestructura	DevOps Lead	Infrastructure Manager	No
Documentación	QA Manager	-	No

Fase 3: Implementación

Proceso de Implementación del Cambio:

El equipo DevOps ejecuta el cambio siguiendo un procedimiento estructurado para cada RFC aprobado:

1. Cargar RFC desde ServiceNow con número de solicitud
2. Validaciones Pre-Implementación:
   • Verificar que todas las aprobaciones están completas
   • Confirmar disponibilidad de recursos
   • Revisar criterios de validación definidos
3. Crear Backup/Snapshot antes de cualquier modificación
4. Ejecutar Cambio en Etapas:
   • Para cada etapa del plan de implementación:
     • Ejecutar la etapa
     • Validar que la etapa se completó correctamente
     • Si la etapa falla:
       • Iniciar procedimiento de rollback usando el backup
       • Lanzar excepción y detener la implementación
5. Validaciones Post-Implementación:
   • Verificar que el sistema funciona correctamente
   • Confirmar que los servicios están operativos
6. Actualizar CMDB con las nuevas configuraciones
7. Generar Reporte de Compliance documentando el cambio

Si Ocurre un Error:

• Manejar la falla del cambio
• Registrar en el sistema de auditoría
• Notificar al equipo responsable
• Escalar según procedimiento de gestión de incidentes

Fase 4: Verificación y Cierre

• Pruebas de aceptación
• Validación clínica (si aplica)
• Actualización de documentación
• Comunicación a stakeholders
• Cierre formal del RFC

Baseline de configuración

Definición del baseline

Ejemplo de Baseline de Configuración:

Identificación del Baseline:

• ID: BL-2024-Q1-001
• Versión: 1.1.0.0
• Estado: APPROVED
• Fecha Efectiva: 2024-01-15

Componentes Incluidos:

Categoría	Componente	Versión
Aplicación	Web Frontend	v1.1.0
	API Backend	v1.1.0
	Mobile App iOS	v1.0.8
	Mobile App Android	v1.0.9
Modelos IA	Lesion Classifier	v2.3.1
	Severity Scorer	v1.8.0
	DLQI Predictor	v1.2.4
Infraestructura	Kubernetes	v1.28.5
	PostgreSQL	v14.10
	Redis	v7.2.3
	Nginx	v1.24.0
Seguridad	TLS Version	1.3
	Cipher Suites	TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256
	WAF Ruleset	OWASP_CRS_3.3.4

Compliance Regulatorio:

• Conformidad MDR: Verificada el 2024-01-10
• FDA Listing: K231234
• Auditoría ISO 13485: Completada el 2023-12-15

Gestión de baselines

Proceso de Gestión de Baselines de Configuración:

La organización mantiene un historial completo de baselines (baseline actual + histórico completo).

Creación de Nuevo Baseline

Quién: Configuration Manager

Proceso:

1. Crear Estructura del Baseline:
   • Generar ID único del baseline
   • Registrar timestamp (UTC) de creación
   • Recolectar versiones actuales de todos los componentes
   • Calcular hash de la configuración completa (para integridad)
   • Adjuntar evidencia de aprobación
   • Estado inicial: PENDING
2. Ejecutar Validación Automática:
   • Verificar compatibilidad entre componentes
   • Verificar requisitos de seguridad
   • Validar compliance regulatorio (MDR, FDA, ISO 13485)
   • Probar puntos de integración
   • Verificar métricas de rendimiento
3. Resultado de Validación:
   • Si pasa todas las validaciones:
     • Cambiar estado a VALIDATED
     • Promover como baseline oficial
   • Si falla alguna validación:
     • Registrar errores de validación
     • Mantener en estado PENDING hasta corrección

Validación de Baseline

Validaciones Ejecutadas Automáticamente:

1. Compatibilidad de Componentes - Verificar que las versiones son compatibles entre sí
2. Requisitos de Seguridad - Confirmar configuraciones de seguridad (TLS, cifrado, WAF)
3. Compliance Regulatorio - Validar cumplimiento con MDR, FDA, ISO 13485
4. Puntos de Integración - Probar que todas las integraciones funcionan correctamente
5. Métricas de Rendimiento - Verificar que el rendimiento cumple con SLAs definidos

Comparación de Baselines

Propósito: Analizar diferencias entre dos baselines para gestión de cambios.

Reporte de Diferencias Generado:

1. Componentes Añadidos - Nuevos elementos no presentes en el baseline anterior
2. Componentes Eliminados - Elementos que se retiraron
3. Componentes Modificados - Para cada componente modificado:
   • Nombre del componente
   • Versión anterior
   • Versión nueva
4. Cambios de Configuración - Ajustes en parámetros de configuración
5. Evaluación de Riesgos - Análisis automático del riesgo de los cambios detectados

Automatización y herramientas

GitOps para gestión de configuración

Pipeline Automatizado de Gestión de Configuración:

La organización utiliza GitHub Actions para automatizar la validación y despliegue de cambios de configuración.

Trigger: El pipeline se ejecuta automáticamente cuando se crea un Pull Request que modifica archivos en:

• infrastructure/** (infraestructura como código)
• config/** (archivos de configuración)
• k8s/** (manifiestos de Kubernetes)

Job 1: Validación de Configuración

Ejecutado en: Entorno Ubuntu Linux

Pasos del Proceso de Validación:

1. Checkout del Código desde el repositorio
2. Validar Terraform:
   • Inicializar Terraform
   • Validar sintaxis
   • Generar plan de ejecución (tfplan)
3. Security Scan:
   • Ejecutar tfsec para análisis de seguridad → Genera tfsec-report.json
   • Ejecutar checkov para validación de compliance → Genera checkov-report.json
4. Policy Compliance:
   • Evaluar el plan contra políticas definidas usando Open Policy Agent (OPA)
   • Verificar que no se violan políticas de seguridad
5. Generar Reporte de Cambios:
   • Comparar configuración actual (baseline) vs propuesta (tfplan)
   • Generar reporte markdown con análisis de impacto
6. Publicar Reporte:
   • Publicar automáticamente el reporte de cambios como comentario en el Pull Request
   • Permite revisión humana antes de aprobar

Job 2: Despliegue a Staging

Requisitos:

• Validación exitosa (Job 1 completado)
• Pull Request merged (aprobado y fusionado)

Ejecutado en: Entorno Ubuntu Linux

Pasos del Despliegue:

1. Desplegar Configuración:
   • Aplicar cambios de Terraform automáticamente en staging
2. Actualizar CMDB:
   • Registrar el nuevo baseline en ServiceNow CMDB
   • Asociar con entorno staging
3. Ejecutar Smoke Tests:
   • Pruebas básicas para verificar funcionamiento del sistema
   • Detectar problemas inmediatos post-despliegue
4. Generar Reporte de Compliance:
   • Crear reporte PDF de compliance con estándar MDR
   • Documentar conformidad regulatoria del cambio

Monitoreo continuo de configuración

Sistema de Detección de Configuration Drift:

La organización utiliza AWS Config para monitorear continuamente desviaciones de la configuración baseline.

Proceso de Detección de Drift

Quién: Sistema automatizado ejecutándose continuamente

Proceso:

1. Obtener Configuración Actual del recurso desde AWS Config
2. Comparar con Baseline:
   • Usar comparación profunda (DeepDiff) entre baseline y configuración actual
   • Ignorar cambios en orden de elementos
   • Excluir campos temporales (LastModified, CreationTime)
3. Si se Detectan Diferencias:
   • Registrar el drift detectado
   • Activar proceso de manejo de desviaciones

Manejo de Desviaciones Detectadas

El sistema evalúa la severidad de la desviación y actúa según el nivel:

Severidad	Acción Automática	Descripción
CRITICAL	Auto-remediación inmediata	• Ejecutar corrección automática del recurso • Enviar alerta crítica al equipo de seguridad • Registrar incidente
HIGH	Crear Change Request	• Generar ticket en ServiceNow automáticamente • Asignar al equipo responsable • Requiere aprobación humana antes de corregir
MEDIUM/LOW	Log de advertencia	• Registrar en logs para revisión • Incluir en reporte semanal de configuración

Auto-remediación

Recursos con Auto-remediación Habilitada:

• Security Groups - Restaurar reglas de firewall al baseline
• S3 Buckets - Corregir políticas de acceso y cifrado
• IAM Policies - Revertir cambios no autorizados en permisos

Proceso:

1. Identificar tipo de recurso afectado
2. Buscar procedimiento de remediación específico
3. Si existe remediación automatizada → Ejecutar corrección
4. Registrar acción tomada en audit log

Auditoría y compliance

Registro de auditoría de configuración

Tabla de Auditoría de Configuraciones:

La organización mantiene un registro completo e inmutable de todos los cambios de configuración en la base de datos PostgreSQL.

Campos Registrados en Cada Entrada de Auditoría:

Campo	Descripción	Valor por Defecto
audit_id	ID único de la entrada (UUID)	Generado automáticamente
timestamp	Fecha/hora del cambio (con zona horaria)	Timestamp actual UTC
ci_id	ID del Configuration Item afectado	Requerido
action	Tipo de acción realizada	CREATE, UPDATE, DELETE, ROLLBACK
old_value	Valor anterior (JSON)	-
new_value	Valor nuevo (JSON)	-
change_request_id	ID del RFC asociado	-
user_id	Usuario que realizó el cambio	Requerido
user_role	Rol del usuario	-
approval_evidence	Evidencia de aprobación (JSON)	-
medical_device_impact	¿Impacta dispositivo médico?	FALSE
regulatory_notification_required	¿Requiere notificación a autoridades?	FALSE
compliance_check_result	Resultado de verificación de compliance (JSON)	-

Índices para Búsqueda Rápida:

• Por CI ID (búsqueda de historial de un componente)
• Por timestamp (búsqueda cronológica)
• Por usuario (auditoría de acciones de un usuario)

Vista de Compliance:

La organización mantiene una vista SQL que combina información de CIs con su última modificación para reportes de compliance:

Información Mostrada:

• ID y nombre del CI
• Nivel de criticidad
• Fecha del último cambio
• Usuario que realizó el último cambio
• Estado de compliance actual
• Nivel regulatorio:
  • "MDR/FDA Required" si es componente de dispositivo médico
  • "Standard" para componentes no médicos

Método: La vista usa un LEFT JOIN LATERAL para obtener solo la entrada más reciente del audit log para cada CI.

Reportes de configuración

Reporte Mensual de Configuración para Compliance:

La organización genera automáticamente un reporte mensual de gestión de configuración con firma digital.

Quién: Configuration Manager (proceso automatizado)

Frecuencia: Mensual

Contenido del Reporte:

1. Período: Mes y año del reporte (formato YYYY-MM)
2. Resumen Ejecutivo - Estadísticas de Cambios:
   • Total de cambios realizados en el mes
   • Cambios de emergencia (fuera del proceso normal)
   • Cambios fallidos (que no se completaron exitosamente)
   • Rollbacks ejecutados (reversiones de cambios)
   • Cambios no autorizados detectados
3. Lista Detallada de Cambios:
   • Información completa de cada cambio del mes
   • Con trazabilidad a RFCs y aprobaciones
4. Incidentes Relacionados:
   • Incidentes causados por cambios de configuración
   • Análisis de root cause
5. Compliance con Baselines:
   • Tasa de Compliance con Baseline: Porcentaje de sistemas alineados con baseline aprobado
   • Compliance de Seguridad: Estado de configuraciones de seguridad
   • Compliance Regulatorio:
     • MDR: Estado de cumplimiento con Medical Device Regulation
     • FDA: Estado de cumplimiento con regulaciones FDA
     • ISO 13485: Estado de cumplimiento con sistema de calidad
6. Recomendaciones:
   • Mejoras identificadas para el proceso de gestión de configuración
   • Acciones correctivas propuestas

Proceso de Generación:

1. Recopilar todas las métricas del período
2. Generar reporte en formato PDF
3. Firmar digitalmente el documento para garantizar autenticidad e integridad
4. Distribuir a stakeholders (QA Manager, CTO, Compliance Officer)

Métricas e indicadores

KPIs de gestión de configuración

Indicadores Clave de Rendimiento (KPIs):

La organización monitorea los siguientes KPIs para evaluar la efectividad de la gestión de configuración:

Precisión (Accuracy)

KPI	Objetivo	Descripción
CI Accuracy Rate	99.2%	CIs correctamente documentados en el CMDB
Baseline Compliance	98.5%	Sistemas alineados con baseline aprobado
Discovery Coverage	97.8%	Assets descubiertos automáticamente vs documentados manualmente

Gestión de Cambios (Change Management)

KPI	Objetivo	Descripción
Change Success Rate	96.3%	Porcentaje de cambios implementados exitosamente sin rollback
Emergency Change Percentage	2.1%	Porcentaje de cambios de emergencia (fuera de proceso normal)
Average Change Lead Time	4.2 días	Tiempo promedio desde solicitud hasta implementación
Rollback Rate	1.8%	Porcentaje de cambios que requirieron reversión

Compliance

KPI	Objetivo	Descripción
Audit Finding Rate	0.3 por auditoría	Hallazgos de auditoría relacionados con gestión de configuración
Time to Remediation	2.1 días promedio	Tiempo para corregir desviaciones de compliance
Policy Violation Rate	0.5%	Porcentaje de cambios que violan políticas establecidas

Automatización (Automation)

KPI	Objetivo	Descripción
Automated Discovery Rate	94%	Porcentaje de CIs descubiertos automáticamente
Auto Remediation Success	87%	Porcentaje de configuration drifts corregidos automáticamente
Manual Intervention Required	13%	Porcentaje de casos que requieren intervención manual

Integración con otros controles ENS

• OP.EXP.1: Actualización automática del inventario de activos
• OP.EXP.2: Aplicación de configuraciones de seguridad
• OP.EXP.5: Proceso integrado de gestión de cambios
• OP.EXP.7: Configuraciones relacionadas con incidentes
• MP.SI.2: Configuración de controles criptográficos

Consideraciones específicas para dispositivo médico

Control de configuración de algoritmos de IA

• Versionado inmutable de modelos
• Trazabilidad con datasets de entrenamiento
• Registro de métricas de performance clínica
• Procedimiento de rollback validado clínicamente

Requisitos regulatorios

• Cumplimiento con IEC 62304 para control de configuración de software
• Documentación en DHF de todas las versiones released
• Notificación a autoridades de cambios significativos
• Retención de configuraciones históricas por 10 años

Referencias y documentación relacionada

• T-024-006: Procedimiento de gestión de cambios
• T-024-007: Guía de versionado y release
• R-TF-013-002: Registro de gestión de riesgos
• GP-005: Control de cambios
• GP-013: Gestión de la ciberseguridad

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