Cloud para servicios financieros

Ningún proveedor puede, por sí solo, garantizar el cumplimiento normativo; cualquier declaración que sugiera lo contrario debería ponerse en cuestión. En el marco de DORA, las obligaciones son responsabilidad de la entidad financiera: la titularidad del marco de gestión de riesgos TIC, del registro de información y del programa de pruebas de resiliencia le corresponde a la entidad. La función de un proveedor consiste en aportar la evidencia que el supervisor requiere: las disposiciones contractuales del Artículo 30, los detalles de subcontratación y localización de datos que exige tu registro, derechos de auditoría y acceso tanto para ti como para tu supervisor, así como notificación de incidentes y soporte documentado para la salida.

Tener centros de datos en la UE y tener acceso a los datos exclusivamente desde la UE no es lo mismo. La ley CLOUD Act estadounidense se aplica a todo proveedor sometido a la jurisdicción de Estados Unidos, con independencia de la ubicación física de sus servidores; en consecuencia, una región de Fráncfort o de París operada por una compañía matriz estadounidense permanece dentro de su ámbito de aplicación. OVHcloud SAS es de capital francés y se rige por la legislación de la UE, sin ninguna empresa matriz estadounidense. Además, para los requisitos más estrictos, la cualificación SecNumCloud añade criterios verificados por la ANSSI.

En el fondo, ambas son la misma pregunta. Hosted Private Cloud sobre VMware o Nutanix se alinea con la infraestructura actual del cliente, por lo que el proceso constituye una migración y no una reescritura: se hace carga por carga, con ambos entornos funcionando en paralelo hasta que decidas hacer el cambio definitivo. Public Cloud, por su parte, se basa en estándares abiertos —OpenStack, Kubernetes, almacenamiento compatible con S3—, lo que elimina la dependencia de API propietarias que pudieran complicar una futura migración. Esta es, precisamente, la diferencia entre un plan de salida meramente documental y uno efectivamente ejecutable.

La respuesta depende del tipo de carga de trabajo: los parámetros válidos para un libro contable de «core banking» difieren de los aplicables a una plataforma de «reporting». El diseño se basa en regiones 3-AZ para escenarios de falla dentro de la región, y en replicación multiregión para los supuestos que un supervisor evaluará con mayor detalle, complementado con registros de auditoría y copias de seguridad inmutables, así como procesos de recuperación previamente probados, de manera que un incidente de ransomware se resuelva mediante un proceso de recuperación y no mediante una negociación. Se recomienda solicitar la arquitectura objetivo junto con la evidencia de las pruebas realizadas, dado que una sin la otra no resultaría suficiente ante una prueba de resiliencia.