Copias de seguridad y recuperación en la prestación de servicios TIC: ¿cuándo las probó por última vez?
La pregunta "¿tiene una copia de seguridad?" no es la pregunta que importa. La pregunta que importa es: ¿cuándo intentó alguien por última vez restaurar un sistema realmente desde esa copia de seguridad, y cuánto tiempo tardó? Una copia de seguridad que se realiza pero nunca se restaura es en la práctica una suposición. Por eso, los organismos reguladores y los clientes que se basan en las medidas de obligaciones de diligencia debida de la Directiva NIS2 no solo miran la existencia de una política de copia de seguridad, sino la prueba de que la recuperación funciona realmente.
Para un proveedor de servicios TIC, esto no es un asunto menor. A menudo gestiona no solo su propio entorno, sino también sistemas de clientes, de forma remota, a veces con ayuda de un subcontratista. Si algo sale mal, no importa quién cometió el error, sino si la recuperación funcionó dentro de un plazo que el cliente pudiera justificar. Eso hace que la prueba de recuperación sea una de las pocas medidas que no puede verificar solo con un documento.
Por qué una copia de seguridad no probada no cuenta
Una copia de seguridad puede no ser utilizable por muchas razones: un archivo corrupto, una configuración incorrecta, una contraseña que nadie recuerda, o un procedimiento de recuperación que en papel funciona pero en la práctica tarda tres días en lugar de tres horas. Ninguno de estos problemas se hace evidente hasta que alguien realmente utiliza la copia de seguridad. El artículo 21 de la Directiva NIS2 menciona explícitamente la política de copia de seguridad y recuperación como parte de las medidas de gestión del riesgo que una organización tiene en cuenta en relación con sus proveedores. En la práctica, esto significa que un cliente que está sujeto a obligaciones de diligencia debida pregunta a su proveedor de servicios TIC cómo se organiza la recuperación y, cada vez más a menudo, cuándo se probó por última vez.
Lo que un organismo regulador o un cliente entiende por "probado" no está establecido de manera uniforme, pero la pregunta central vuelve cada vez: ¿hubo un momento en el que un sistema o un conjunto de datos se restauró realmente, separado del entorno de producción, y se documentó el resultado? Un informe de prueba con una fecha y un resultado es algo diferente de una comunicación interna de que "las copias de seguridad funcionan".
Gestión remota: ¿de quién es realmente la copia de seguridad?
En la gestión remota, la copia de seguridad de un sistema de cliente a menudo no se encuentra físicamente con el cliente, sino con el proveedor de servicios, o con un servicio en la nube que el proveedor ha configurado en nombre del cliente. Esto desplaza una pregunta que a primera vista parece técnica hacia una pregunta sobre responsabilidad: ¿quién prueba, quién conserva el resultado de la prueba, y quién puede demostrar que la recuperación funciona cuando el cliente lo solicita? Un cuestionario de seguridad de un cliente pregunta cada vez más concretamente sobre esto, y "nuestro proveedor de alojamiento se encarga de ello" no es una respuesta para un organismo regulador o un auditor — es una referencia que pide su propia verificación.
Por lo tanto, es aconsejable documentar por cada sistema de cliente quién tiene acceso a la copia de seguridad, cómo está protegido ese acceso, y quién es responsable de la última prueba de recuperación. las medidas de obligaciones de diligencia debida organizadas por tema muestra cómo la copia de seguridad y la recuperación se relacionan con otras medidas de obligaciones de diligencia debida, como el control de acceso y el registro de incidentes.
Subcontratistas: quién prueba qué
Muchos proveedores de servicios TIC trabajan con subcontratistas para partes específicas: un proveedor de alojamiento, una empresa que gestiona el firewall, un profesional independiente que implementa parches. Si uno de ellos también gestiona la copia de seguridad, la prueba de recuperación se pierde fácilmente entre dos partes: el proveedor de servicios piensa que el subcontratista prueba, el subcontratista piensa que eso no es parte de su encargo. Para el cliente no hace diferencia — formula la pregunta a la parte con la que tiene un contrato.
Por ello, es conveniente especificar explícitamente en los acuerdos con un subcontratista quién realiza la prueba de restauración, con qué frecuencia, y quién conserva la prueba. Esta prueba no tiene por qué ser un informe extenso; una fecha, una descripción de lo que se ha restaurado y el resultado suelen ser suficientes para demostrar a un cliente que la restauración no es una suposición.
Lo que documenta y lo que no
Una prueba de restauración es trabajo humano: alguien restaura un sistema, mide cuánto tiempo tarda y comprueba si los datos son correctos. Este trabajo lo realiza usted mismo o lo encarga a su proveedor de servicios de TI; una plataforma no puede hacerlo por usted, del mismo modo que no puede sustituir una prueba de penetración o una auditoría. Lo que sí ayuda es un lugar donde el resultado de cada prueba se encuentra junto con las demás medidas de cumplimiento de deberes, de modo que en el siguiente cuestionario de seguridad no tenga que buscar cuándo se realizó por última vez.
Si aún no sabe si su organización está directamente sujeta al deber de cumplimiento, o solo se ve afectada a través de un cliente con estas preguntas, en cinco preguntas vea dónde se encuentra le da una primera indicación. Si desea saber cómo tratamos los datos que registra en un dossier de este tipo, cómo tratamos sus datos lo explica. Y si tiene dudas sobre si su situación se ajusta exactamente a esto, consulte respuestas a preguntas frecuentes o póngase en contacto con la autoridad supervisora de su sector.
La verificación NIS2 gratuita y la base de conocimientos en secria.eu muestran dónde se encuentran exactamente la copia de seguridad y la restauración en su situación, sin necesidad de una cuenta.