Puntos clave
- Las arquitecturas soberanas suelen dar prioridad a las auditorías y los controles de acceso frente a la preparación para la recuperación.
- El personal encargado de la recuperación y las copias de seguridad, así como los modelos de custodia de claves, pueden generar lagunas en la soberanía durante los incidentes.
- Es fundamental que los controles sean uniformes tanto en el entorno principal como en el de recuperación.
- Para lograr una resiliencia preparada para la soberanía, se necesitan procedimientos de recuperación probados en condiciones reales.
Imagina la situación. El ataque ya se ha producido. El equipo de respuesta a incidentes se está reuniendo. Alguien debe decidir qué sistemas se restablecen primero, en qué orden y utilizando los puntos de Recovery correctos.
Y entonces alguien se da cuenta de que: el personal con acceso al sistema de Recovery se encuentra en otro país. Y lo que es peor, el propio entorno de Recovery (alojado en la nube, en un centro de datos de un socio o en una sede secundaria) nunca ha estado sujeto a los mismos controles de soberanía que los datos principales. Esta práctica no estaba sujeta a los mismos controles de soberanía que los datos primarios. El regulador quiere saber en qué punto nos encontramos. El tiempo corre.
Este es el escenario para el que no se diseñaron la mayoría de las arquitecturas soberanas, y para el que el Informe sobre la Preparación para la Soberanía Digital señala directamente: la mayoría de las aplicaciones soberanas están pensadas para la auditoría, no para los incidentes. La mayoría de las aplicaciones soberanas están diseñadas para la auditoría, no para los incidentes. La diferencia se nota justo en el peor momento posible.
El punto ciego de la recuperación en la arquitectura soberana
Los programas de soberanía se basan en el control de acceso: quién puede acceder a los datos, bajo qué autoridad y a través de qué vía. Esa arquitectura es necesaria. Pero no es suficiente. Y está directamente relacionada con las lagunas de soberanía operativa analizadas en la tercera entrega de esta serie: si las personas que gestionan tu entorno operan fuera de los límites de tu soberanía, ese problema no desaparece durante un incidente. Se convierte en el problema.
Lo que el control de acceso deja sin respuesta es la pregunta más difícil: ¿qué ocurre tras un incidente, cuando la recuperación no es solo una operación técnica, sino que también está sujeta a restricciones legales?
Un ataque de ransomware contra una organización europea sujeta a regulación no solo supone un problema de recuperación. Supone un problema de recuperación que hay que resolver dentro de una jurisdicción, con personal que cuente con las autorizaciones adecuadas y utilizando puntos de recuperación de los que se pueda demostrar que están limpios y no se han visto comprometidos. La arquitectura soberana diseñada para proteger los datos puede complicar la recuperación si no se ha incorporado la resiliencia en el diseño original.
Los modos de fallo específicos
Las formas en que fallan las arquitecturas de recuperación soberana son predecibles… y habituales:
- Personal de recuperación fuera de los límites de la soberanía. Los ingenieros que conocen los sistemas de Recovery pueden trabajar en una jurisdicción diferente. Bajo presión, recurrir a ellos es la opción más fácil. Además, supone una violación de la soberanía justo en el momento menos oportuno.
- Infraestructura de copia de seguridad sin los controles adecuados. Los entornos soberanos principales se controlan minuciosamente. La infraestructura de copias de seguridad —sobre todo los entornos más antiguos o secundarios— no suele estar sujeta a los mismos requisitos de soberanía. Si los puntos de recuperación se almacenan o procesan fuera de los límites establecidos, no es posible llevar a cabo una recuperación conforme a la normativa desde una infraestructura que cumpla con los requisitos.
- La custodia de las claves en situaciones de crisis. Los acuerdos de «cada uno con su propia clave» están pensados para el funcionamiento normal. En situaciones de crisis —cuando los sistemas principales se ven comprometidos y la presión del tiempo es enorme—, el modelo de custodia de claves que funciona en una ventana de mantenimiento rutinario puede convertirse en un obstáculo para la recuperación. Si no se ha probado, es solo una suposición, no un control.
- Lagunas de gobernanza entre entornos. Las organizaciones que operan en varios niveles soberanos —que son la mayoría— suelen tener controles sólidos en los entornos principales y controles más débiles en los entornos secundarios, que también forman parte de la ruta de recuperación. Lo que buscarán los auditores es la coherencia en el conjunto de entornos. Las lagunas en los entornos secundarios se hacen evidentes precisamente cuando la coherencia es más importante.
Por qué los controles de soberanía pueden complicar la recuperación
Los mismos controles que hacen que un entorno soberano sea defendible ante un auditor pueden dificultar la recuperación. Las restricciones al movimiento de datos que impiden la filtración no autorizada también limitan la coordinación de la recuperación. Los acuerdos clave de custodia que garantizan que ningún proveedor pueda acceder a tus datos sin autorización también suponen un obstáculo cuando necesitas restaurarlos rápidamente.
Nada de esto significa que estos controles sean incorrectos. Lo que significa es que hay que diseñarlos pensando en la recuperación desde el principio, y no añadirlos a una arquitectura en la que la recuperación se haya tenido en cuenta a posteriori. Este es el núcleo del principio de soberanía mínima viable: ajustar los controles a las necesidades reales incluye los requisitos de recuperación, no solo los de control de acceso.
Lo que requiere una resiliencia preparada para la soberanía
- Validación de la recuperación limpia. Demostrar que los puntos de recuperación no se han visto comprometidos antes de restaurarlos en el entorno de producción —no solo que sean recientes, sino que no se hayan visto comprometidos—. En un escenario de ransomware, una copia de seguridad reciente puede estar ella misma comprometida. La capacidad de identificar y restaurar desde un punto de recuperación que se sabe que está limpio, validado antes de que sea necesario, es un requisito de soberanía, no solo un requisito de recuperación ante desastres.
- Gestión entre entornos. Controles de soberanía y pruebas de auditoría coherentes en todo el conjunto de entornos, no solo en el entorno soberano principal. Cada entorno de la ruta de recuperación debe cumplir los mismos requisitos que el entorno principal.
- Probado en condiciones reales. Ejercicios periódicos que comprueben la recuperación en las condiciones que realmente se darán durante un incidente: las restricciones legales aplicables, el personal disponible y los puntos de recuperación que estén operativos. Una prueba anual de recuperación ante desastres que no tenga en cuenta las restricciones de soberanía no es un ejercicio preparado para la soberanía.
La pregunta que debes añadir a tu análisis sobre la soberanía
Hay una forma directa de comprobar si tu arquitectura de recuperación cumple los mismos requisitos de soberanía que tu entorno de datos principal: haz la pregunta y exige una respuesta sincera. ¿Eres capaz de recuperar tus datos soberanos, de forma limpia y dentro de los límites de tolerancia establecidos, utilizando personal que opere dentro de tus fronteras soberanas, ahora mismo —en condiciones reales, no en un ejercicio controlado—?
Para la mayoría de las organizaciones, la respuesta sincera pone de manifiesto una carencia. Las que la detecten ahora —antes de que se produzca el incidente— estarán mejor preparadas para presentar pruebas cuando el organismo regulador se las solicite. Las que no lo hagan tendrán que prepararlas bajo presión, ante las personas a las que menos quieren decepcionar. El Informe sobre la preparación para la soberanía digital incluye una pregunta sobre la evaluación de la arquitectura de recuperación directa.
Preguntas frecuentes
P: ¿Por qué es importante la recuperación para la soberanía digital?
R: La soberanía no es plena si las organizaciones no pueden recuperar los datos dentro de los mismos límites legales y operativos que se utilizan para protegerlos.
P: ¿Cuáles son los fallos más comunes en la Recovery soberana?
R: Entre los fallos más habituales se encuentran que el personal de recuperación trabaje fuera de los límites de la soberanía, que las copias de seguridad carezcan de los controles adecuados y que la gobernanza no sea coherente en todos los entornos.
P: ¿Cómo puede la custodia de claves complicar Recovery?
R: Los modelos en los que uno mismo gestiona su clave refuerzan la seguridad durante el funcionamiento normal, pero pueden ralentizar las tareas de recuperación en caso de incidentes si no se prueban adecuadamente.
P: ¿Qué es la validación de Recovery limpia?
R: La validación de la recuperación limpia confirma que los puntos de recuperación no se han visto comprometidos antes de restaurar los sistemas. Esto es especialmente importante en casos de ransomware.
P: ¿Cómo deberían las organizaciones poner a prueba su resiliencia en materia de soberanía?
R: Deberían realizar simulacros realistas que tengan en cuenta las restricciones legales, la disponibilidad operativa y los puntos de recuperación validados, y no limitarse a las pruebas estándar de recuperación ante desastres.
Alex Zinin es vicepresidente y director general del área de proveedores de servicios gestionados en Commvault.
