¿Quién pilota el viaje a la nube del sector financiero? (III)

Seguimos con el tercer capítulo del viaje a la nube, tras los dos primeros (aquí y aquí). Hoy nos vamos a centrar en quién pilota, quién lleva los mandos en este viaje, controlando y mitigando los riesgos e incidencias que van surgiendo por el camino. Los riesgos de contar con un modelo 'on premise' (basado en la entidad) o en la nube son esencialmente coincidentes, por ejemplo, la seguridad de la información, el fraude o la continuidad del servicio. Pero la diferencia es la compartición de riesgos, ya que, en la nube, rige el principio de responsabilidad compartida. Y en este sentido, es importante determinar de qué se va a encargar la entidad bancaria, por un lado, y el proveedor de servicios en la nube, por el otro. En función de esto, habrá que establecer el marco de control de riesgos, ya que la entidad bancaria tendrá que establecer mecanismos para supervisar las responsabilidades asumidas por el proveedor de servicios en la nube.

Un mecanismo de control adecuado por parte de la entidad bancaria debería contar con tres líneas de defensa. La primera línea consiste en el desarrollo de medidas técnicas y operativas de los servicios que la entidad bancaria va a querer trasladar a la nube. Estas medidas deberán cumplir con los objetivos de control fijados por la segunda línea defensa. La segunda línea de defensa deberá valorar de forma independiente si las medidas propuestas por la primera línea cumplen, efectivamente, con los objetivos de control. Y ya como tercera línea de defensa estarían los auditores internos de la entidad bancaria. No obstante, conforme más y más servicios se van externalizando a la nube, el sistema de control debería pasar a ser más general, reflejando desde el control de riesgos de iniciativas individuales al control de riesgos de una estrategia tecnológica en su conjunto.

El proveedor de servicios en la nube debe hacer todo lo posible para facilitar el ejercicio del control por parte de la entidad bancaria. Existen múltiples mecanismos complementarios para facilitar esta tarea. De manera regular, se pueden poner a disposición de la entidad bancaria webs de estado que permitan conocer cómo están los servicios en todo momento, así como una revisión cuatrimestral del Acuerdo de Nivel de Servicios (SLA, por sus siglas en inglés). En caso de que tengan lugar incidencias, las mejores prácticas indican que el proveedor de servicios debería producir un informe en el que se explique qué ha sucedido, cómo se ha reaccionado y qué medidas se van a adoptar para que no vuelva a ocurrir. Y para eventos puntuales, como los picos de ventas en el Black Friday, en los que se prevé que vaya a haber un posible tensionamiento de los servicios, debería haber una preparación especial.

En cuanto al supervisor bancario, las expectativas pasan por que la entidad bancaria sea consciente de que la delegación de tareas no equivale a la delegación de responsabilidad y por ello, cobra vital importancia el marco de gestión de riesgos del banco, que no debería ofrecer ningún ángulo muerto. Las labores del supervisor bancario, a la espera de que sea de aplicación el Reglamento sobre la resiliencia operativa digital (DORA, por sus siglas en inglés), son complejas, en la medida en que, en la actualidad, no está contemplada la supervisión directa al proveedor de servicios en la nube. Sólo se puede llevar a cabo la supervisión a través del contrato firmado entre la entidad bancaria y el proveedor de servicios en la nube, pero esto no está exento de complejidades legales y obstáculos desde el punto de vista de las capacidades. Una vez DORA sea de aplicación, los proveedores tecnológicos calificados como críticos para el sector financiero europeo podrán ser supervisados de manera directa a nivel europeo (no a nivel de Estado miembro).

Entre todos los riesgos identificados, hay dos que sobresalen especialmente: el riesgo derivado de un uso inadecuado de las regiones y zonas de disponibilidad y el conocido como “vendor lock-in”.

Conviene explicar, en primer lugar, qué son las regiones, las zonas de disponibilidad y los centros de datos. Las mejores prácticas indican que una región es una agrupación de zonas de disponibilidad, y a su vez una zona de disponibilidad es una agrupación de centros de datos en una zona geográfica determinada, por ejemplo, España. Cada región está dividida en zonas de disponibilidad, que están separadas por km de distancia. La distancia máxima entre las zonas de disponibilidad se define para que si hay un desastre natural (por ejemplo, un terremoto), no afecte a más de una zona, pero garantizando que la distancia no es tan larga como para que haya disfuncionalidades o latencia. Cada zona de disponibilidad cuenta con su propia energía, su agua, refrigeración, etc. de forma que, si hay un problema en una zona de disponibilidad, no afecte a la región completa. Obviamente, cuantas más regiones o zonas de disponibilidad tenga contratadas la entidad bancaria, menor será el riesgo de que cualquier incidente afecte a la provisión de sus servicios, pero como contrapartida, incurrirá en mayores gastos operativos. Por ello, para tomar esta decisión, la entidad bancaria tiene analizar la criticidad del servicio para saber las necesidades de respaldar el servicio en caso de que hubiera un incidente. En lo que al supervisor bancario respecta, se espera que la entidad bancaria tome la decisión conforme a esa criticidad y tenga la información relevante por parte del proveedor para saber cómo están definidas las regiones y las zonas.

Por otro lado, el riesgo de “vendor lock-in” consiste en la posibilidad de quedar atrapado en la relación contractual con el proveedor de servicios en la nube, especialmente, si se trata de un servicio crítico. Por ello es tan importante desde la perspectiva supervisora que la entidad bancaria cuente con una estrategia de salida completa, reduciendo al mínimo cualquier riesgo residual. En este sentido, la colaboración del proveedor se servicios en la nube es esencial y debe verse desde dos perspectivas: primero, actuando a modo de consultor, el proveedor debería incluso poner a disposición de la entidad bancaria guías para facilitar la salida a otro proveedor; y segundo, y por el lado de los componentes, con servicios y herramientas, que puedan ayudar en la salida. Lógicamente, es mucho más sencillo portar aplicaciones simples que complejas. Desde este punto de vista, arquitecturas como contenedores pueden contribuir a la portabilidad. Por lo tanto, para optimizar la portabilidad, que no es un proceso de un día para otro, hay que tener en cuenta varios factores, como los tiempos mínimos de permanencia requeridos por el proveedor, si las licencias de uso no permiten usar servicios de otro proveedor, la arquitectura utilizada como posibilidad de minimizar los costes de migración, los estándares de implantación, etc. Con todo y con esto, no hay que engañarse: la portabilidad se debe planificar desde el inicio, para así evitar el interés de algunas empresas de retener al máximo a sus clientes, minimizando las barreras de salida que son comunes tanto en este sector como en cualquier otro.

Y ya para terminar, es interesante referirse a una modalidad relativamente nueva de auditoría, conocida como “pooled audit” o auditoría conjunta, que se incluyó por primera vez en la recomendación de cloud de la Autoridad Bancaria Europea, para luego pasar a incorporarse en las guías de externalización (no solo de cloud sino de todos los servicios). La razón de ser de este tipo de iniciativa es que es difícil para una entidad bancaria auditar a una empresa de cierta complejidad y tamaño. Además, hay un claro núcleo de servicios comunes entre las distintas entidades bancarias. De este modo, se pensó que las entidades bancarias que así lo desearan podían unir fuerzas, beneficiándose ellas mismas, pero también el propio proveedor de servicios en la nube, que ve su papel como receptor de la auditoría mucho más simplificado.

Hasta aquí el capítulo de hoy del viaje a la nube del sector financiero. Seguiremos después del verano, con la seguridad en vuelo, para tratar sobre continuidad de negocio, resiliencia, ciberseguridad y estabilidad financiera. No se lo pierdan.