Una copia que el atacante puede borrar no es una copia

El patrón de todos los informes de incidente por ransomware se lee igual. La intrusión no se detecta durante semanas. En ese tiempo el atacante hace reconocimiento, encuentra el sistema de copias y, o bien las borra, o las cifra junto con todo lo demás, o cambia en silencio la política de retención para que caduquen. Solo entonces dispara el cifrado. Cuando alguien se da cuenta, el camino de recuperación se había eliminado días antes.

Por eso "tenemos copias" y "podemos recuperar" son afirmaciones distintas. La primera va de si los datos se copiaron. La segunda va de si alguna copia sobrevive a un atacante que tiene tus credenciales de administración.

La inmutabilidad es el control que más importa

Todos los almacenes de objetos grandes admiten ya retención de escritura única y lectura múltiple, vendida como bloqueo de objetos o almacenamiento inmutable. Cuando se fija un periodo de retención en modo de cumplimiento, nadie puede borrar ni sobrescribir ese objeto hasta que el periodo expire. Ni un administrador, ni la cuenta raíz, ni el soporte del proveedor.

Es el control con más valor de esta lista, porque es el único que aguanta cuando el atacante tiene acceso administrativo completo. El modo de gobernanza, donde un rol privilegiado puede saltarse el bloqueo, sirve para protegerse de errores y no vale nada frente a un intruso decidido que pueda obtener ese rol.

Dos cosas que hay que acertar. El periodo de retención tiene que superar tu tiempo realista de detección. Si las intrusiones pasan un mes de media sin detectarse y tu bloqueo es de siete días, el bloqueo no ayuda. Y la retención legal combinada con una regla de ciclo de vida interactúan de formas que conviene probar, porque una combinación mal configurada o borra antes de tiempo o acumula coste para siempre.

Separa las credenciales, separa la cuenta

Si la identidad que ejecuta tu carga de producción puede además borrar tus copias, tienes un solo radio de impacto, no dos.

El destino de las copias va en otra cuenta, suscripción o proyecto, con su propia frontera de identidad y sin ninguna relación de confianza que un rol de producción comprometido pueda atravesar. El lado de producción recibe permiso de solo escritura o solo adición sobre el destino. La capacidad de borrar vive en un número pequeño de identidades que no existen en el entorno de producción, protegidas con doble factor respaldado por hardware.

Comprueba el camino que seguiría un atacante. ¿Puede el pipeline de integración continua de producción asumir un rol en la cuenta de copias? ¿Puede llegar la cuenta de gestión de la organización, y quién puede llegar a la cuenta de gestión? Casi todos los entornos tienen un enlace que no pretendían, y suele ser un rol con alcance demasiado amplio creado durante una migración.

La copia que está en otra parte

La vieja regla de tres copias, dos medios y una fuera sobrevive al traslado a la nube con una aclaración: "fuera" significa ahora fuera del dominio de fallo que incluye tu cuenta de nube, no simplemente en otra región.

Una región separada protege contra un fallo regional. No protege contra el compromiso de la cuenta, contra un fallo de facturación que suspenda la cuenta entera ni contra una política equivocada a nivel de organización. Para los datos que de verdad no puedes perder, mantén una copia en otro proveedor o en almacenamiento físico. Esa copia puede ser más pequeña, más lenta y menos actual que la principal, porque su trabajo es sobrevivir, no ser cómoda.

Aquí es también donde aprietan las expectativas del regulador. Tanto NIS2 como DORA presionan sobre la recuperabilidad demostrable y no sobre la existencia de un documento de proceso, lo que se ve desde el lado de la obligación en el ámbito y las obligaciones de NIS2 y en DORA para un proveedor tecnológico.

Las claves de cifrado son parte de la copia

Una copia cifrada con una clave que vive en el entorno comprometido no es recuperable si el atacante borra la clave, y borrar claves es una técnica documentada de ransomware porque es más rápida que cifrar los datos.

Guarda la clave de los datos de copia en un almacén de claves separado en la cuenta separada, activa la protección contra borrado y la ventana de protección más larga que ofrezca tu proveedor, y anota el identificador de la clave en algún sitio fuera de todo esto. Prueba el descifrado desde un entorno limpio, porque descubrir durante una recuperación que nadie sabe dónde está el material de clave es una mala tarde.

Detecta el borrado, no solo el cifrado

El borrado masivo de objetos de copia es un evento inusual con una firma clara, y ocurre antes del daño visible. Eso lo convierte en una de las detecciones más valiosas disponibles.

Alerta sobre: cualquier borrado de objetos en el cubo de copias, cualquier cambio en una política de ciclo de vida o de retención, cualquier cambio en la programación o el destino del trabajo de copia, la desactivación del versionado o del bloqueo de objetos, y un trabajo de copia que reporta éxito con un tamaño bastante menor que el de la ejecución anterior. Este último caza tanto el ataque como la rotura silenciosa, que es mucho más frecuente.

Encamina esto a un canal que alguien vigile, y a una identidad que no esté en el entorno comprometido. Una alerta que envía un correo a una cuenta que controla el atacante es decoración.

Prueba de restauración, porque una copia es una hipótesis

Nada de esto significa nada si la restauración no funciona, y las restauraciones fallan por motivos mundanos mucho más a menudo que por motivos dramáticos: un esquema que falta, una dependencia de un secreto que nadie exportó, una versión de base de datos que ya no existe, un bloqueo de objetos que impide escribir de vuelta los datos restaurados.

Prueba de forma programada, restaura en un entorno limpio y cronométralo. El número que produzcas es tu objetivo de tiempo de recuperación real, y suele ser varias veces el que figura en el plan. Esa disciplina entera es el tema de objetivos de recuperación y la prueba de restauración.

La tensión con la privacidad

Las copias inmutables y el derecho de supresión tiran en direcciones opuestas, y fingir lo contrario suspende una auditoría.

La posición defendible es una ventana máxima de conservación de copias, acotada y documentada, con un proceso que reaplica los borrados pendientes después de cualquier restauración, y ese proceso implementado y evidenciado de verdad. Fija el periodo de inmutabilidad para que coincida con la ventana de conservación en vez de excederla. El razonamiento está en el RGPD como controles de ingeniería.

Lo que se olvida

• Las instantáneas en la misma cuenta no son copias. Comparten dominio de fallo y modelo de permisos con aquello que protegen.
• La recuperación a un punto en el tiempo de las bases de datos gestionadas tiene una ventana corta. Es excelente contra un borrado accidental e inútil contra una intrusión descubierta en la tercera semana.
• La configuración es dato. Las definiciones de infraestructura, la configuración de pipelines, las políticas de identidad y los registros DNS tienen que ser recuperables, y un repositorio de git sobre el que el atacante puede forzar un empuje tampoco es una copia.
• El software como servicio de terceros es responsabilidad tuya. El proveedor protege frente a sus fallos, no frente a que tu administrador borre un espacio de trabajo. Exporta lo que importe.
• La capacidad para restaurar tiene que existir. Recuperar un entorno grande necesita cómputo y red para los que puede que no tengas cuota, un día en el que todo el mundo está nervioso.

Qué hacer esta semana

Coge la credencial que usa tu entorno de producción y comprueba, con precisión, si puede borrar un objeto en tu destino de copias. No leyendo políticas, intentándolo en una ruta de prueba. Si puede, ese es el hallazgo, y poner bloqueo de objetos en ese cubo es una hora de trabajo que cambia por completo tu peor día. Comprobamos exactamente esto en un proyecto de seguridad.