Gobierno de la nube en servicios financieros: responsabilidades y controles mínimos

Mover cargas a la nube no traslada la responsabilidad regulatoria. Una entidad financiera que contrata infraestructura, una plataforma o una aplicación en la nube sigue respondiendo ante su supervisor por la seguridad de los datos de sus clientes, la continuidad de sus servicios y el cumplimiento de sus obligaciones. Lo que cambia es quién opera cada capa técnica y, por lo tanto, dónde tienen que estar los controles.

El problema habitual no es la falta de controles del proveedor, que suelen estar documentados y certificados, sino los huecos en la frontera: capas que cada parte supone que gestiona la otra. Este artículo ordena esa frontera por tipo de servicio, identifica lo que la entidad nunca delega y propone una base mínima de controles para empezar.

La responsabilidad compartida cambia con el tipo de servicio

La definición de computación en la nube del NIST (SP 800-145) distingue tres modelos de servicio: infraestructura (IaaS), plataforma (PaaS) y software (SaaS). En la práctica, la diferencia entre ellos es hasta qué capa llega el control del cliente. AWS, Microsoft Azure y Google Cloud publican su propia versión del modelo de responsabilidad compartida y, con matices de nombre, coinciden en lo esencial.

• IaaS. El proveedor opera el centro de datos, el hardware, la red física y la virtualización. El cliente gestiona el sistema operativo, el middleware, las aplicaciones, la red virtual y todo lo que está por encima. Es el modelo con más control y, por lo tanto, con más tareas de seguridad del lado del cliente: parches, endurecimiento, protección contra malware, reglas de red.
• PaaS. El proveedor también gestiona el sistema operativo y el entorno de ejecución. El cliente despliega código y configura el servicio: quién accede, desde qué redes, con qué cifrado, cuánto tiempo se conservan los registros. Los controles de red y de la aplicación quedan compartidos.
• SaaS. El proveedor opera la aplicación completa. El cliente decide quién la usa, con qué permisos, qué datos carga y cómo configura las opciones de seguridad que el producto ofrece.

Dos advertencias prácticas. Primero, una misma arquitectura suele mezclar los tres modelos: una aplicación en máquinas virtuales que usa una base de datos gestionada y envía correo con un servicio SaaS tiene tres fronteras distintas. Conviene documentar la matriz por servicio, no por proveedor. Segundo, "gestionado por el proveedor" no significa "configurado por el proveedor". Una base de datos PaaS llega parcheada, pero si queda expuesta a internet o sin el cifrado que exige tu política, esa decisión es tuya.

Lo que nunca se delega

Hay cuatro ámbitos que quedan del lado de la entidad en cualquier modelo de servicio. La documentación de Microsoft lo dice de forma explícita para datos, identidades y configuración, y la lógica es la misma con cualquier proveedor.

Datos

La clasificación de la información, la decisión de qué datos pueden ir a la nube y en qué región, el cifrado y el ciclo de vida (retención y borrado) son decisiones del cliente. El proveedor ofrece las herramientas; no decide qué es confidencial ni cuánto tiempo hay que conservarlo.

Identidades y accesos

Quién entra, con qué privilegios, con qué factor de autenticación y quién aprueba los accesos privilegiados. En la nube, la consola de administración y las API de gestión son el nuevo perímetro: una credencial administrativa comprometida tiene más alcance que el acceso físico a un centro de datos.

Configuración

Almacenamiento con acceso público, puertos abiertos, registros desactivados, cifrado opcional sin activar. Un error de configuración del cliente puede exponer datos aunque la infraestructura del proveedor funcione perfectamente, y ningún contrato traslada esa responsabilidad.

Cumplimiento

Las certificaciones del proveedor (ISO/IEC 27001, informes SOC 2, PCI DSS) cubren su parte del modelo. Son evidencia útil, pero no acreditan que la entidad use bien el servicio. Ante el supervisor y el auditor, la responsabilidad por la función externalizada sigue siendo de la entidad. Las Directrices de la EBA sobre externalización, aplicables desde el 30 de septiembre de 2019, lo establecen así para las entidades de la Unión Europea. En Latinoamérica, cada supervisor tiene su propia normativa de tercerización y de nube; conviene que Cumplimiento confirme qué exige en cada país donde operas.

Una base de controles mínimos

No hace falta implementar todos los dominios de la Cloud Controls Matrix (CCM) de la Cloud Security Alliance antes de la primera carga. Su versión 4, publicada este año, organiza los controles en 17 dominios y los relaciona con otros marcos, lo que la hace útil como referencia de largo plazo. Para empezar, recomendamos esta base mínima, que debería estar operativa antes de alojar datos de clientes:

• Identidad y accesos. Federación con el directorio corporativo, sin usuarios locales en la consola. MFA obligatorio para todos, y del tipo más robusto disponible para administradores. Cuenta raíz o de emergencia bajo doble custodia y con alerta ante cualquier uso. Roles de mínimo privilegio y revisión periódica de accesos.
• Landing zone y estructura de cuentas. Una estructura de cuentas, suscripciones o proyectos definida desde el inicio: producción separada de no producción, cuentas dedicadas a seguridad y registro, y políticas preventivas a nivel de organización (regiones permitidas, servicios aprobados, prohibición de desactivar registros).
• Cifrado y llaves. Cifrado en reposo y en tránsito activado por defecto. Para datos sensibles, llaves gestionadas por el cliente en el servicio de gestión de llaves del proveedor o en un HSM, con rotación, separación de funciones entre quien administra llaves y quien administra datos, y registro de cada uso.
• Registro centralizado. Registros de actividad de la plataforma (llamadas a la API, accesos a la consola, cambios de configuración) de todas las cuentas, enviados a una cuenta de registro aislada, con retención según la política de la entidad y protección contra borrado. Integración con el SIEM o con el centro de operaciones de seguridad.
• Configuración segura. Línea base definida a partir de los CIS Benchmarks del proveedor correspondiente y evaluada de forma continua, con herramientas del propio proveedor o de terceros. Cada desviación genera una alerta con dueño y plazo.
• Gestión del proveedor. Evaluación de riesgo previa a la contratación, revisión de certificaciones e informes de auditoría, y cláusulas de acceso, auditoría, notificación de incidentes, ubicación de datos y subcontratación. Registro actualizado de los acuerdos de externalización.
• Salida. Estrategia de salida documentada para funciones críticas: cómo se recuperan los datos, en qué formato, en qué plazo, con qué costo y quién lo ejecuta.

Cada control necesita un dueño, una evidencia que se pueda mostrar en una auditoría y un indicador de cumplimiento. Sin eso, la lista es una declaración de intenciones.

Proveedores, auditoría y estrategia de salida

Las Directrices de la EBA tratan la externalización a proveedores de nube dentro del marco general de externalización y sustituyeron las recomendaciones específicas sobre nube que la EBA había publicado en 2017. Tres de sus requisitos son especialmente relevantes para el gobierno de la nube, y sirven como buena práctica también fuera de la UE:

• Evaluar si la función es crítica o importante. De esa clasificación dependen el nivel de diligencia, las cláusulas exigibles y la comunicación con el supervisor.
• Derechos de acceso, información y auditoría para la entidad y para la autoridad competente. En la nube suelen materializarse con informes de auditoría independientes, certificaciones y, cuando hace falta, auditorías conjuntas entre varios clientes.
• Estrategia de salida documentada para funciones críticas o importantes, que contemple la terminación del contrato, la falla del proveedor y el deterioro del servicio, con un análisis de impacto, recursos asignados y criterios de éxito para la transición.

La estrategia de salida es el control que más se posterga y el que más cuesta improvisar. No exige tener una segunda nube activa. Exige saber, con un plan revisado y al menos probado en papel, cómo se recuperarían datos y servicios si el contrato terminara. Elegir formatos de datos exportables y definir la infraestructura como código reduce el costo de esa salida desde el primer día.

El seguimiento del proveedor también debe ser continuo: niveles de servicio, incidentes, cambios de subcontratistas. Para decidir qué medir, puedes ver nuestro artículo sobre SLA que importan, y para integrar esta gestión en un modelo de proveedores, el de PMO y VMO como servicio.

Quién hace qué dentro de la entidad

El modelo de responsabilidad compartida tiene una contraparte interna que suele quedar sin definir. Una asignación simple evita que los controles queden en tierra de nadie. La tabla siguiente es un ejemplo ilustrativo; los nombres de los equipos cambian en cada organización.

Control	Opera	Rinde cuentas	Supervisa
Identidad y accesos	Equipo de identidad	CISO	Auditoría interna
Landing zone y políticas	Equipo de plataforma de nube	Responsable de infraestructura	Seguridad
Cifrado y llaves	Seguridad	CISO	Riesgo
Registro centralizado	Seguridad y Operaciones	CISO	Auditoría interna
Configuración segura	Equipo de plataforma de nube	Responsable de infraestructura	Seguridad
Gestión del proveedor y salida	Gestión de proveedores	Dueño del servicio de negocio	Riesgo y Cumplimiento

Lo importante es que cada control tenga una sola persona que rinda cuentas. Cuando ocurre un incidente en la nube, la investigación cruza las fronteras entre cliente y proveedor, y entre equipos internos: los registros centralizados y una asignación clara de dueños son lo que permite llegar a la causa, como explicamos en causa raíz en sistemas distribuidos.

Antes de aprobar el modelo, valídalo con Riesgo, Cumplimiento y Legal, en especial la clasificación de funciones críticas y las cláusulas contractuales.