La mentira de lo “no crítico”: por qué tus sistemas fuera de producción son tu mayor riesgo para la resiliencia
Durante décadas, los programas de resiliencia se han organizado en torno a una sola palabra reconfortante: producción.
Los clasificamos por niveles. Los replicamos. Probamos su recuperación. Los rodeamos de monitoreo, procedimientos operativos y atención ejecutiva. Es en producción donde vive el programa de resiliencia.
Todo lo demás recibe una etiqueta más discreta: no producción. Desarrollo. QA. Sandbox. Capacitación. Preproducción. El refresco del sistema del trimestre pasado. La copia de recuperación ante desastres (DR) a la que nadie ha accedido desde la auditoría.
Con esa etiqueta viene una suposición implícita: si no es producción, no es crítico.
Y es precisamente en esa suposición donde los programas modernos de resiliencia comienzan a fallar silenciosamente.
La pregunta que nadie hace
Esta es la pregunta incómoda que todo líder de resiliencia debería plantearse:
Si mañana tus sistemas no productivos fueran vulnerados —o simplemente desaparecieran—, ¿qué ocurriría realmente?
Para la mayoría de las organizaciones, la respuesta real es alarmante. Una brecha en un solo entorno sandbox de SAP puede exponer los mismos datos de clientes, empleados y financieros que en producción, porque ese entorno fue refrescado a partir de una copia de producción y los datos nunca fueron enmascarados. La pérdida de un entorno de QA puede paralizar un proceso de liberación del que el negocio depende más de lo que reconoce. Un sistema de desarrollo comprometido puede convertirse en una puerta sin protección hacia el entorno de producción al que está conectado.
Los datos son reales. La conectividad es real. La exposición es real.
Lo único que no es real es la protección.
Por qué la “no producción” se convirtió en un punto ciego
Los entornos no productivos se ganaron legítimamente su condición de segunda categoría. Existen para ser desechables, copiados, dañados y reconstruidos. En muchos sentidos, tratarlos como prescindibles es precisamente el propósito.
Pero tres cosas cambiaron mientras la etiqueta permaneció igual.
- Los entornos no productivos ahora contienen datos de producción
Un entorno SAP moderno no es un único sistema: es una constelación. Por cada instancia de producción puede haber tres, cinco o diez copias derivadas: desarrollo, pruebas, QA, capacitación, preproducción y clones para recuperación ante desastres.
Cada refresco del sistema copia los datos de producción junto con la configuración de producción. Nombres, direcciones, documentos nacionales de identidad, registros salariales, datos bancarios: todo el contenido de las tablas que hace que producción sea sensible termina en entornos que cuentan con apenas una fracción de los controles.
A menos que los datos sean deliberadamente enmascarados durante el refresco, un sandbox “no crítico” es una réplica completa y sin protección de tu información más regulada.
- La superficie de ataque se multiplicó de forma invisible
Cada sistema no productivo tiene sus propias credenciales, rutas de red, cuentas de servicio y relaciones de confianza. Muchos fueron implementados rápidamente, recibieron amplios permisos de acceso “temporalmente” y nunca volvieron a ser revisados.
Los atacantes entienden esto mejor que la mayoría de los programas de resiliencia. No atacan la puerta principal fortificada. Buscan el clon olvidado con una cuenta de servicio compartida y una ruta de acceso hacia producción.
El sistema más peligroso de tu entorno rara vez es el que estás vigilando. Es aquel que dejaste de vigilar.
- El cumplimiento normativo no reconoce esa etiqueta
A los reguladores no les importa si un sistema está etiquetado como producción o no producción. Una copia de datos personales regulados sigue siendo información personal regulada, sin importar dónde se encuentre, cómo haya sido creada o cómo se denomine el entorno que la contiene.
El RGPD, las normas de residencia de datos y las obligaciones de notificación de brechas se aplican a un sandbox exactamente igual que a producción. La etiqueta “no crítico” no ofrece protección legal alguna ni reduce la responsabilidad. Solo reduce la atención que reciben esos datos.
¿Dónde entra esto en conflicto con la recuperación ante desastres?
Esto no es únicamente un problema de seguridad o cumplimiento normativo. Es un problema de resiliencia, y se manifiesta en el peor momento posible: durante la recuperación.
Pensemos en lo que realmente es una copia de recuperación ante desastres. Por definición, es una instancia no productiva de producción. Contiene datos de producción, pero con demasiada frecuencia se gestiona con la disciplina propia de un entorno no productivo en materia de acceso, enmascaramiento y monitoreo.
Por lo tanto, los modos de falla se combinan y agravan entre sí:
- Un evento de recuperación activa entornos que nunca estuvieron sujetos a controles de nivel de producción.
- Un proceso de refresco diseñado por conveniencia reintroduce configuraciones desactualizadas o datos sin enmascarar en sistemas que, de repente, deben asumir un rol crítico.
- Las rutas de identidad y acceso que “funcionaban bien durante las pruebas” se convierten en el eslabón frágil cuando producción está caída y el entorno de DR debe soportar la carga.
No puedes recuperar la resiliencia utilizando entornos que nunca trataste como resilientes.
Qué deben hacer diferente los líderes de resiliencia
La solución no consiste en dotar a cada sandbox de controles de máximo nivel. Eso sería un desperdicio y desvirtuaría el propósito desechable para el que fueron concebidos estos sistemas. La solución consiste en dejar de permitir que la etiqueta no producción signifique sin gestión.
Hay tres cambios de enfoque especialmente importantes.
- Enmascarar los datos en el momento del refresco, no después
La protección de la información de identificación personal (PII) no puede ser una tarea de limpieza que se realice “eventualmente” después de copiar un sistema. Para entonces, la ventana de exposición ya está abierta.
El enmascaramiento debe integrarse en el propio proceso de refresco: debe aplicarse específicamente a las tablas y campos que contienen datos sensibles, ejecutarse automáticamente y verificarse antes de que el entorno sea habilitado para su uso. El objetivo es sencillo: un sistema no productivo nunca debería contener datos personales reales que no necesita.
- Incorporar los entornos no productivos al inventario de resiliencia
No puedes proteger aquello que te niegas a contabilizar. Cada entorno no productivo debería aparecer en el mismo inventario que producción, con un responsable, una clasificación de datos, una periodicidad definida para la revisión de accesos y un ciclo de vida establecido.
La pregunta para cada uno no es: «¿Es crítico?». La pregunta es: «¿Qué contiene?, ¿con qué se conecta? y ¿qué ocurre si se pierde o es vulnerado?». Este simple cambio de enfoque permite identificar riesgos que una clasificación basada únicamente en etiquetas siempre pasará por alto.
- Validar la ruta de recuperación, no solo el objetivo de recuperación
Debido a que los entornos de DR son, por naturaleza, no productivos, heredan las debilidades propias de estos entornos. Por ello, la validación de la resiliencia también debe incluir los controles que rodean la recuperación – enmascaramiento, identidad, acceso e integridad de la configuración – y no limitarse a comprobar si los datos pueden recuperarse.
Una copia de DR que se recupera exitosamente pero expone datos sin enmascarar, o abre una ruta sin protección hacia producción, no ha proporcionado resiliencia. Simplemente ha trasladado el riesgo.
Lo que los líderes deben desaprender
Para cerrar este punto ciego, es necesario abandonar algunas creencias cómodas:
- No producción significa no crítico.
- Los datos sensibles solo importan en producción.
- Los sistemas desechables no necesitan controles rigurosos.
En realidad:
- El riesgo de un sistema está definido por lo que contiene y con qué se conecta, no por su nombre.
- Los datos regulados siguen estando regulados dondequiera que se encuentren.
- Los entornos que tú consideras prescindibles son precisamente los que los atacantes consideran oportunidades.
La verdadera encrucijada
Los líderes de resiliencia dedican una enorme cantidad de energía a fortalecer los sistemas que todos consideran críticos. Ese trabajo es necesario, pero ya no es suficiente.
Las brechas, los incumplimientos normativos y las recuperaciones que silenciosamente salen mal se producen cada vez más a través de sistemas que nadie se molestó en clasificar. No porque esos sistemas sean más importantes, sino porque nunca fueron tratados como si importaran.
La pregunta ya no es: “¿Está protegida la producción?”
Ahora es: “¿Qué se esconde en los sistemas que decidimos ignorar?”
Esa es la encrucijada. Y, para la mayoría de las organizaciones, el camino más arriesgado es el que ya están recorriendo.
PUNEET KHATRI
Puneet Khatri es un experimentado líder en tecnología SAP con más de 18 años de experiencia en el diseño, gestión y protección de entornos SAP empresariales complejos. Actualmente se desempeña como jefe de servicio y se especializa en planificación de recuperación ante desastres, alta disponibilidad y estrategias de nube híbrida para sistemas de misión crítica.
Khatri ha liderado programas globales de resiliencia de SAP en diversos sectores, con especial énfasis en arquitecturas basadas en AWS y Azure. Le apasiona alinear la resiliencia de TI con la continuidad del negocio y es autor de diversos
