Riesgos técnicos que nadie revisa hasta que ya generaron una pérdida

La mayoría de los problemas técnicos que generan una pérdida real no vienen de un ataque sofisticado ni de un error de programación oscuro. Vienen de cosas que todo el mundo sabe que habría que revisar, pero que nunca parecen urgentes. Hasta que lo son.

El patrón es conocido: una empresa opera con normalidad durante meses o años, y un día algo falla. Al investigar, el origen no es un evento imprevisible sino una condición que existía desde antes y que nadie se ocupó de resolver. Lo peor no es el incidente en sí, sino la conversación posterior: "sabíamos que esto podía pasar".

Este artículo no describe incidentes puntuales ni asigna cifras de pérdida. Describe categorías de riesgo que aparecen una y otra vez en empresas de distintos tamaños y sectores. El objetivo no es alarmar, sino dar un marco para identificar estos riesgos antes de que se activen.

Categoría 1: Copias de seguridad que existen pero no funcionan

Tener una política de backups no es lo mismo que tener backups que efectivamente permitan recuperar la operación. La diferencia se descubre, por lo general, en el peor momento posible.

Los puntos ciegos más frecuentes en esta categoría:

• Backups que nunca se probaron restaurar. Se ejecutan todas las noches, ocupan espacio, figuran en el panel de control como "exitosas". Pero nunca nadie simuló una restauración completa para verificar que los datos vuelven íntegros y que los sistemas arrancan con esa copia. Un backup que no se probó es una promesa, no una garantía.
• Backups que están en el mismo lugar físico que los datos originales. Si el servidor principal y la copia comparten el mismo datacenter, una falla de infraestructura —corte de energía, incendio, inundación— puede llevarse ambos. La redundancia geográfica no es un lujo; es el mínimo para que el backup cumpla su función.
• Backups que no incluyen todo lo necesario para operar. Es frecuente respaldar la base de datos pero no los archivos de configuración, las claves de acceso a servicios externos, los certificados o las librerías específicas que el sistema necesita. Recuperar los datos sin el entorno que los hace funcionar equivale a no tener nada.
• Backups que dependen de una sola persona. Si el procedimiento de restauración solo lo conoce una persona, y esa persona no está disponible cuando ocurre el incidente, el backup existe en teoría pero no en la práctica.

Categoría 2: Accesos que deberían haberse revocado y nunca se tocaron

Cada persona que deja la empresa, cambia de rol o termina un proyecto debería perder los accesos que ya no necesita. En la práctica, esto rara vez ocurre de forma sistemática.

Los riesgos en esta categoría incluyen:

• Ex empleados que conservan acceso a sistemas. No necesariamente con mala intención: a veces el acceso persiste por omisión administrativa. Pero mientras exista, es una puerta abierta. El riesgo no es solo de fuga de información: también puede haber modificación accidental o eliminación de datos por parte de alguien que ya no debería poder interactuar con el sistema.
• Cuentas de servicio sin dueño claro. Muchas integraciones entre sistemas usan cuentas genéricas —"admin@", "integrador@", "api@"— que se crearon para un proyecto puntual y después quedaron activas sin que nadie sepa exactamente qué hacen ni quién es responsable de desactivarlas.
• Permisos acumulados por cambio de rol. Una persona que empezó como desarrolladora, pasó a líder técnico y después a gerencia puede conservar permisos de escritura sobre repositorios, bases de datos o entornos de producción que ya no necesita para su función actual. Cuanto más tiempo pasa, más difícil es saber qué permisos son necesarios y cuáles son residuos.

El problema de fondo no es técnico: es de proceso. Si no existe un procedimiento documentado que se active cada vez que alguien cambia de rol o se desvincula, los accesos se acumulan. Y cada acceso innecesario es un riesgo innecesario.

Categoría 3: Dependencias externas sin mantenimiento

Todo sistema moderno depende de software desarrollado por terceros: librerías, frameworks, servicios en la nube, APIs de proveedores. Esas dependencias se actualizan, se deprecian, cambian de precio o simplemente dejan de funcionar. Cuando eso ocurre y el sistema no está preparado, el impacto puede ser inmediato.

Los patrones de riesgo más comunes:

• Librerías con vulnerabilidades conocidas sin actualizar. Las bases de datos públicas de vulnerabilidades —como CVE— documentan fallos de seguridad en software de uso masivo. Si el equipo no tiene un proceso para revisar estas alertas y aplicar actualizaciones, el sistema opera con agujeros que ya son de conocimiento público. No hace falta un atacante sofisticado: alcanza con alguien que sepa buscar.
• APIs de terceros que cambian sin previo aviso suficiente. Un proveedor modifica la estructura de su API, deprecia una versión anterior o cambia las condiciones de uso. Si el sistema no tiene una capa de abstracción que aisle esos cambios, una actualización externa puede romper funcionalidades propias sin que el equipo se entere hasta que un usuario reporta el error.
• Servicios cloud con configuraciones por defecto. Muchos servicios en la nube vienen con configuraciones pensadas para facilitar el inicio rápido, no para operar en producción con datos reales. Puertos abiertos, buckets de almacenamiento públicos, claves de acceso en el código fuente. Son errores de configuración, no de programación, y suelen detectarse solo cuando ocurre un incidente.

Categoría 4: Conocimiento concentrado en pocas personas

Cuando una sola persona entiende cómo funciona una parte del sistema —o peor, cuando una sola persona entiende cómo funciona todo—, la empresa tiene un riesgo de continuidad que no aparece en ningún tablero de control.

Este riesgo se manifiesta de varias formas:

• Documentación inexistente o desactualizada. Si el conocimiento está en la cabeza de una persona y no en un lugar accesible para el resto del equipo, la ausencia de esa persona —por vacaciones, enfermedad o salida de la empresa— paraliza la capacidad de respuesta ante cualquier problema.
• Procedimientos que solo una persona puede ejecutar. Publicar una nueva versión, restaurar una base de datos, modificar una configuración crítica. Si estas tareas dependen de un único individuo, no hay redundancia operativa.
• Decisiones de arquitectura que nadie más conoce. ¿Por qué se eligió esa base de datos? ¿Qué supuestos se hicieron al diseñar ese módulo? Si las respuestas se fueron con quien tomó las decisiones, el equipo actual opera sobre un sistema que no entiende del todo.

Categoría 5: Entornos de prueba que no reflejan producción

Un cambio funciona en el entorno de desarrollo, pasa las pruebas y, al desplegarse en producción, rompe algo. La causa más frecuente: el entorno donde se probó no se parece lo suficiente al entorno real.

Las diferencias que suelen pasarse por alto:

• Versiones distintas de base de datos, sistema operativo o dependencias. Una consulta que funciona en MySQL 8.0 puede fallar en 5.7. Una librería que se instaló en desarrollo puede no estar disponible en el servidor de producción. Si los entornos no se mantienen sincronizados, cada despliegue es una apuesta.
• Volúmenes de datos irreales. Probar con cien registros cuando producción tiene dos millones no valida el rendimiento real. Las consultas que funcionan en segundos con pocos datos pueden bloquear la base cuando el volumen es real.
• Configuraciones de infraestructura distintas. Límites de memoria, tiempo de ejecución máximo, cantidad de conexiones simultáneas. Si estos parámetros difieren entre entornos, un código correcto puede fallar por razones que no son del código.

La solución no es tener entornos idénticos —eso rara vez es viable en términos de costo—, sino identificar las diferencias y tener un plan para detectar problemas antes de que lleguen a producción: pruebas de humo, despliegues graduales, monitoreo activo durante las primeras horas tras cada cambio.

Por qué estos riesgos persisten

Ninguna de estas categorías requiere conocimientos avanzados de seguridad informática para ser identificada. Lo que las hace persistentes no es la complejidad técnica sino la combinación de tres factores:

• No son urgentes hasta que son catastróficos. Mientras todo funciona, revisar backups o auditar accesos compite con tareas que tienen una fecha de entrega visible. La urgencia aparece recién cuando el daño ya ocurrió.
• La responsabilidad no está asignada. ¿Quién debería ocuparse de probar los backups? ¿El equipo de desarrollo, el de operaciones, el responsable de seguridad? Si la tarea no tiene dueño claro, simplemente no se hace.
• El costo de prevenir es visible; el costo de no prevenir es abstracto. Dedicar horas a una auditoría de accesos tiene un costo concreto hoy. El costo de un incidente futuro es una probabilidad, no una certeza. Esa asimetría favorece la inacción.

Cómo empezar a reducir estos riesgos

No se necesita un plan de gestión de riesgos de cien páginas. Algunas acciones de bajo esfuerzo y alto impacto:

• Probar una restauración completa una vez por trimestre. No alcanza con verificar que el archivo de backup existe. Hay que restaurarlo en un entorno aislado y confirmar que el sistema arranca y los datos están íntegros.
• Revisar la lista de accesos una vez por mes. Quién tiene acceso a qué, y si cada acceso sigue estando justificado. La primera revisión suele ser la más reveladora.
• Designar un responsable de dependencias. Una persona —no necesariamente dedicada a tiempo completo— que revise alertas de seguridad, fechas de fin de soporte y cambios en APIs de proveedores críticos.
• Documentar lo que solo sabe una persona. No hace falta documentar todo. Alcanza con identificar las tres cosas que, si la persona clave no estuviera disponible, pondrían en riesgo la operación, y documentar esas tres primero.

Estas acciones no eliminan el riesgo —ninguna acción lo hace—, pero lo reducen a un nivel donde deja de ser una bomba de tiempo para convertirse en algo gestionable. La diferencia entre un incidente que se resuelve en horas y uno que paraliza la operación durante días suele estar en si alguien hizo estas verificaciones antes de que fueran urgentes.

Si tu empresa todavía depende de planillas para procesos críticos, el artículo sobre cuándo dejar de usar planillas aborda otra categoría de riesgo operativo que conviene revisar en paralelo. Y si estás por iniciar un desarrollo nuevo, validar antes de desarrollar ayuda a reducir el riesgo de construir algo que después no se usa —que también es una pérdida evitable.