Durante años, la planificación de la Recovery siguió un patrón habitual: elaborar el plan, documentar los pasos y dar por hecho que funcionaría cuando fuera necesario. Durante mucho tiempo, ese enfoque funcionó. Fallos de hardware, interrupciones aisladas e incluso desastres naturales: eran situaciones que las organizaciones podían anticipar y para las que podían planificar con cierto grado de confianza. Pero la situación ha cambiado.

En este episodio de STRIVE, he hablado con Jason Cray, responsable principal de experiencia de producto de Commvault, para analizar una realidad que seguimos viendo en organizaciones de todos los tamaños: la mayoría no fracasa porque le falte un plan de recuperación. Fracasa porque nunca ha comprobado que ese plan vaya a funcionar bajo presión real. Mira el episodio completo.

Puntos clave: Por qué fracasan los planes de recuperación

• Un plan documentado no es lo mismo que uno que haya demostrado su eficacia. Si no se ha probado en condiciones reales, sigue siendo solo una suposición.
• La recuperación es un trabajo en equipo. La seguridad, la infraestructura y las operaciones deben estar coordinadas; si no, la recuperación se ralentiza.
• La mayor parte de la inversión sigue realizándose «antes de que llegue el auge». La prevención es importante, pero a menudo se pasa por alto la preparación para la recuperación.
• Las pruebas sacan a la luz las carencias y generan confianza. Sin ellas, las organizaciones se quedan solo con la esperanza.
• La resiliencia es una disciplina operativa. Requiere iteración, comunicación y mejora continua.

El problema con eso de «debería funcionar»

Sobre el papel, la recuperación parece sencilla. Tienes que definir hasta qué punto quieres recuperar, qué es lo que hay que recuperar y dónde debe restaurarse. El proceso parece lógico, estructurado y fácil de gestionar. Pero, como señala Jason, esa sencillez rara vez se mantiene en las condiciones del mundo real.

Los planes se redactan en entornos controlados, pero se ejecutan en medio del caos. Cuando se produce un incidente, los equipos no revisan tranquilamente la documentación: reaccionan, resuelven problemas e intentan coordinarse en tiempo real. Ahí es donde surge la brecha. No entre las herramientas y la tecnología, sino entre las expectativas y la ejecución.

Avance: ¿Por qué fracasan los planes cuando hay presión?

En este fragmento de la conversación, Jason y yo analizamos por qué no basta con tener un plan, y qué hace falta realmente para saber que un plan funcionará cuando sea necesario.

Ya hemos visto esto antes

Lo curioso es que este problema no es nuevo; es algo que ya conocemos, solo que en un contexto diferente. Si nos remontamos a los inicios de la recuperación ante desastres, las organizaciones seguían un patrón similar. Los planes existían, pero las pruebas eran, en el mejor de los casos, irregulares. Jason compartió un ejemplo en el que pasó toda una noche ayudando a un cliente a superar una prueba de recuperación ante desastres para la que creían estar preparados. El plan parecía sólido. La ejecución contó una historia diferente.

Con el tiempo, las organizaciones se fueron adaptando. Empezaron a hacer pruebas con más frecuencia, introdujeron simulacros de conmutación por error y, en algunos casos, incluso ejecutaron operaciones de producción desde entornos secundarios para demostrar que estaban preparadas. Ese cambio de las suposiciones a la validación es precisamente lo que exige ahora la ciberresiliencia.

El primer problema: la comunicación

Si hay un tema que siempre sale a colación, ese es la comunicación. En muchas organizaciones, las responsabilidades están bien definidas: el equipo de seguridad se encarga de la prevención, el de infraestructura gestiona los sistemas y el de operaciones se ocupa de la recuperación. Por separado, puede que cada equipo esté haciendo exactamente lo que se supone que debe hacer. Pero la recuperación no se produce de forma aislada. Depende de lo bien que trabajen juntos esos equipos cuando algo sale mal.

Como describe Jason, con demasiada frecuencia se convierte en un modelo de traspaso de responsabilidades: «Ya hemos hecho nuestra parte, ahora le toca a otro». Ese enfoque genera retrasos, confusión y, en última instancia, riesgo. Durante un incidente cibernético, la coordinación es más importante que la atribución de responsabilidades.

El problema de «Left of Boom»

Otra tendencia que seguimos observando es el desequilibrio en cuanto a dónde centran sus esfuerzos las organizaciones. Se está invirtiendo mucho en prevención: herramientas de seguridad, plataformas de detección y estrategias defensivas diseñadas para detener un ataque antes de que se produzca. Esa inversión es necesaria y desempeña un papel fundamental. Pero se le presta mucha menos atención a lo que pasa después del evento.

Se parte de la base de que, si se dedica suficiente esfuerzo a la prevención, Recovery pasa a un segundo plano. En realidad, ocurre justo lo contrario. En algún momento, algo acaba colándose. Y cuando eso ocurre, Recovery se convierte en el factor determinante de cómo responde una organización.

De la esperanza a la evidencia

Aquí es donde hay que cambiar de mentalidad. No se trata de añadir más herramientas ni de reescribir la documentación. Se trata de pasar de un modelo basado en la esperanza a otro basado en la evidencia.

Jason destaca una observación clave: las organizaciones que gestionan bien las situaciones de crisis no son las que evitan los incidentes, sino las que sufren un menor impacto cuando estos se producen. Han puesto a prueba sus procesos. Han validado sus hipótesis. Saben dónde están sus carencias. Y lo más importante de todo es que se han ganado la confianza, no por creer que el plan va a funcionar, sino por demostrarlo.

Empieza poco a poco y ve cogiendo impulso

Para muchos equipos, el reto no es entender el problema, sino saber por dónde empezar. La clave no está en cambiarlo todo de golpe. Está en empezar poco a poco y seguir avanzando a partir de ahí.

Céntrate en uno o dos servicios críticos. Entiende qué se necesita para recuperarlos. Reúne a los equipos responsables de esos sistemas y prueba el proceso de principio a fin. A partir de ahí, amplía el alcance y sigue perfeccionándolo. Este enfoque no solo mejora la recuperación, sino que también fomenta la coordinación, refuerza la comunicación y sienta las bases para una resiliencia más amplia.

La realidad: ningún plan sobrevive al primer contacto

Uno de los momentos más sinceros de nuestra charla fue este: ni siquiera el mejor plan va a salir exactamente como está previsto. Eso no es un fallo, es lo que se espera. Jason lo explica de forma sencilla: si no tienes un plan, fracasarás. Pero, aunque lo tengas, no todo saldrá a la perfección en el momento.

Lo que importa es hasta qué punto tus equipos están preparados para adaptarse. Las pruebas fomentan esa adaptabilidad. Desarrollan la memoria muscular necesaria para responder con eficacia cuando las condiciones no se ajustan a las expectativas.

Mira el episodio completo

En esta charla de STRIVE hablamos de muchas más cosas, entre ellas:

• ¿Por qué los planes de recuperación suelen fracasar a pesar de estar bien documentados?
• ¿Qué diferencia a las organizaciones que se recuperan de forma eficaz?
• Cómo afectan las deficiencias en la comunicación a la ejecución.
• ¿Por dónde empezar a mejorar la preparación para la recuperación?
• Por qué las pruebas son la base de la resiliencia.

Ver ahora. Si alguna vez te has preguntado si tu plan de recuperación funcionaría de verdad, esta conversación te va a merecer la pena.

Preguntas frecuentes

P: ¿Por qué no basta con tener un plan de recuperación?

R: Porque la mayoría de los planes nunca se ponen a prueba en condiciones reales. Sin pruebas, no dejan de ser suposiciones en lugar de estrategias contrastadas.

P: ¿Qué hace que los planes de recuperación fallen?

R: Los problemas más habituales en los planes de recuperación son la falta de pruebas, la mala comunicación entre equipos y las discrepancias entre los procesos documentados y la ejecución real.

P: ¿Qué significa «a la izquierda de la pluma»?

R: «A la izquierda de la pluma» se refiere a centrarse en prevenir los incidentes antes de que se produzcan. Muchas organizaciones invierten mucho en esto, pero no lo suficiente en las capacidades de recuperación.

P: ¿Con qué frecuencia se deben probar los planes de recuperación?

R: Los planes de recuperación deben someterse a pruebas periódicas y en condiciones variadas. Las pruebas deben simular situaciones reales, no solo ejercicios controlados.

P: ¿Por dónde deberían empezar las organizaciones?

R: Empieza con un pequeño conjunto de servicios críticos, coordina a los equipos responsables y prueba la recuperación de principio a fin antes de ampliarla.

P: ¿Cuál es el cambio de mentalidad clave?

R: Pasar de una planificación basada en la esperanza a una validación basada en la evidencia.

Chris Mierzwa es director sénior de marketing de cartera en Commvault.

Llevamos años centrándonos en la seguridad de la identidad en el contexto de las personas: quién tiene acceso, qué pueden hacer y cómo controlarlo. Ese modelo tenía sentido cuando la mayor parte de la actividad en el entorno la realizaban usuarios humanos. Pero ya no es así.

Las identidades de máquina —aplicaciones, servicios, API y cargas de trabajo automatizadas— desempeñan ahora un papel fundamental en el funcionamiento de los sistemas modernos. Se autentican, se comunican y ejecutan tareas, a menudo sin supervisión directa. Y en muchos entornos, ya superan en número a las identidades humanas por un amplio margen.

En este episodio de STRIVE, hablo con Dan Conrad, tecnólogo principal y compañero director técnico de campo en Commvault. Analizamos más a fondo lo que significa ese cambio, no solo desde el punto de vista de la seguridad, sino también desde la perspectiva de la gobernanza. Y exploramos por qué tantas organizaciones siguen tratando esto como una cuestión secundaria. Mira el episodio completo.

Puntos clave: ¿Hacia dónde se está desplazando el riesgo?

• Las identidades de las máquinas están creciendo más rápido que las identidades humanas, a menudo en órdenes de magnitud.
• Los modelos de gobernanza no han avanzado al mismo ritmo, lo que ha generado lagunas en materia de acceso y control.
• La visibilidad es el principal reto. Muchos equipos no entienden del todo cómo se comportan las identidades de las máquinas.
• La proliferación de privilegios va más allá de los usuarios, ya que las identidades de las máquinas suelen tener acceso permanente.
• La resiliencia depende de que entendamos y gestionemos el ámbito de actuación de estas identidades de máquina antes de que se conviertan en un problema.

El modelo de identidad ha cambiado

Durante mucho tiempo, la gestión de identidades fue relativamente sencilla. Se podían asignar usuarios a roles, definir políticas de acceso y establecer controles en torno a un comportamiento predecible. A pesar de su complejidad, el modelo seguía basándose en la actividad humana. Las identidades de las máquinas han roto ese modelo. Se crean de forma dinámica, a menudo como parte de los procesos de desarrollo o implementación. Interactúan entre sistemas de formas que no siempre son visibles, están bien documentadas o se someten a auditoría. Y, a diferencia de los usuarios humanos, no siguen un ciclo de vida claro: no se incorporan ni se dan de baja de la misma forma estructurada.

Esto plantea un tipo de reto diferente. Ya no se trata solo de controlar el acceso. Se trata de comprender cómo se utiliza ese acceso, cómo evoluciona y cómo se conecta en todo el entorno.

Avance: No se puede suplantar una identidad no humana

En este fragmento del debate de STRIVE, Dan explica que los atacantes no se centran directamente en identidades no humanas mediante el phishing, sino que son actores maliciosos que utilizan cuentas humanas comprometidas —mediante ingeniería social— como trampolín para escalar privilegios y suplantar identidades de máquinas con gran poder. Una vez dentro, técnicas como «pass-the-hash» y las cuentas de servicio con privilegios excesivos permiten a los atacantes moverse lateralmente y verticalmente, incluso después de que se hayan restablecido las contraseñas.

La brecha en la gobernanza

El verdadero problema no es que existan las identidades de las máquinas, sino cómo se gestionan. En la mayoría de las organizaciones, hay un proceso claro para gestionar el acceso de las personas:

• Las solicitudes se aprueban.
• Se revisan los permisos.
• Se realiza un seguimiento de los cambios.

Existe un nivel de disciplina que proviene de años de atención a la identidad de los usuarios. Sin embargo, las identidades de las máquinas suelen quedar al margen de esa estructura. Se crean rápidamente para dar soporte a aplicaciones o a la automatización. Se les conceden los permisos necesarios para funcionar, a veces más de los necesarios. Y, con el tiempo, esos permisos persisten. Estos accesos con permisos excesivos rara vez se auditan, se revisan y, lo que es más importante, rara vez se reducen.

Ahí es donde se forma la brecha. Resulta difícil responder a preguntas básicas sobre el acceso. No porque la información no exista, sino porque no se ha organizado ni gestionado de forma que resulte útil.

La visibilidad antes que el control

Cuando las organizaciones empiezan a abordar este problema, lo primero que se les ocurre suele ser endurecer los controles.

• Limitar permisos
• Restringir el acceso
• Aplicar nuevas políticas

Pero el control sin visibilidad no sirve de mucho. Si no entiendes cómo se utilizan las identidades, ni el contexto empresarial en el que se enmarcan —es decir, dónde se conectan, con qué interactúan y cómo se mueven entre los sistemas—, cualquier intento de restringirlas se convertirá en una medida reactiva y podría ralentizar las operaciones de la empresa. Por eso la visibilidad tiene que ser lo primero.

Una vez que se puede observar cómo se comportan las identidades de las máquinas, empiezan a surgir patrones. Se puede empezar a comprender dónde el acceso es excesivo, dónde existen dependencias y dónde se concentra el Risk. A partir de ahí, la gobernanza puede volverse más precisa y eficaz.

Un problema de privilegios diferente

La proliferación de privilegios no es nada nuevo. La mayoría de las organizaciones llevan años intentando gestionar el exceso de accesos de los usuarios.

Las identidades de las máquinas plantean un problema similar, pero con una dinámica diferente. Su acceso suele estar integrado en los sistemas. Es persistente, automatizado y, una vez establecido, rara vez se cuestiona. Eso hace que sea más difícil de detectar y más fácil de pasar por alto. Y cuando algo sale mal, esas identidades pueden convertirse en una vía que los atacantes pueden aprovechar

Por dónde empezar

Para la mayoría de las organizaciones, el reto no es la concienciación, sino saber por dónde empezar. El primer paso no es una transformación a gran escala. Se trata de aportar claridad. Comprender cuántas identidades de máquina existen. Dónde se crean. Qué permisos tienen. Cómo se utilizan. Y, lo más importante, confirmar que a cada usuario humano le corresponde un conjunto de identidades no humanas a efectos de auditabilidad y rendición de cuentas.

Esas preguntas parecen sencillas, pero a menudo son difíciles de responder. Y precisamente por eso son importantes. Porque, una vez que seas capaz de responderlas, ya no estarás actuando a ciegas.

Mira el episodio completo

En esta entrega de STRIVE, profundizamos en cómo las identidades de las máquinas están cambiando la forma en que las organizaciones deben plantearse el acceso, la gobernanza y la resiliencia. Es una charla práctica sobre lo que está pasando ahora mismo y lo que hay que cambiar de cara al futuro. Ver ahora.

Recursos

Si te interesa saber más sobre este tema, échale un vistazo a este libro electrónico sobre identidades no humanas.

Preguntas frecuentes

P: ¿Qué es una identidad de máquina?

R: Una identidad de máquina es una identidad no humana que utilizan las aplicaciones, los servicios o los sistemas para autenticarse e interactuar con otros recursos.

P: ¿Por qué las identidades de las máquinas suponen cada vez un mayor riesgo?

R: Porque cada vez son más, suelen tener acceso permanente y no siempre se les controla con la misma rigurosidad que a los usuarios humanos.

P: ¿En qué se diferencian de las identidades de usuario?

R: Funcionan de forma continua, están integrados en flujos de trabajo automatizados y, a menudo, carecen de una gestión estructurada de su ciclo de vida.

P: ¿Cuál es el mayor reto al que se enfrentan las organizaciones a la hora de gestionar las identidades no humanas?

R: Visibilidad. Muchos equipos no tienen una idea clara de cuántas identidades de máquinas se crean, se utilizan o están interconectadas.

P: ¿Cómo afecta esto a la resiliencia?

R: Si se ven comprometidas, las identidades de los equipos pueden facilitar que un atacante se mueva rápidamente por los sistemas, lo que hace que sea más difícil contener los incidentes y recuperarse de ellos.

P: ¿Por dónde deberían empezar las organizaciones?

R: Identificando las identidades de las máquinas, entendiendo sus permisos y creando prácticas de gobernanza que se adapten a su escala y complejidad. Y lo más importante: asegurándonos de que a cada usuario humano le corresponda un conjunto de identidades no humanas, para garantizar la auditabilidad y la rendición de cuentas.

Vidya Shankaran es directora técnica de operaciones de Commvault.

Durante décadas, las operaciones de TI se centraron en el tiempo de actividad:

• Mantén la infraestructura en funcionamiento.
• Cumple tu objetivo de tiempo de recuperación (RTO).
• Cumple tu objetivo de punto de recuperación (RPO).

Pero las amenazas cibernéticas actuales no respetan los límites de la infraestructura, y la recuperación ya no consiste solo en restablecer los sistemas. Se trata de recuperar datos limpios y fiables, entre todos los equipos y bajo presión.

En este episodio de STRIVE, he hablado con Stephen Foskett, fundador y presidente del Tech Field Day de Futurum Group, para hablar de una disciplina emergente: las operaciones de resiliencia, o ResOps. Y es más que una simple palabra de moda. Es un cambio en la forma en que las organizaciones conciben la inteligencia de recuperación. Mira el episodio completo.

Puntos clave: Qué cambia en ResOps

• ResOps cambia el enfoque de la recuperación, pasando de centrarse en la infraestructura a centrarse en el negocio. No se trata solo de volver a poner en marcha los sistemas, sino de recuperar datos fiables y útiles.
• Las métricas tradicionales de RTO y RPO ya no son suficientes. El tiempo medio de recuperación completa (MTCR) se está imponiendo como una forma más significativa de medir la resiliencia.
• Romper las barreras entre departamentos es fundamental para la preparación cibernética. La seguridad, la infraestructura y DevOps deben funcionar de forma sincronizada, no en paralelo.
• La resiliencia es una disciplina operativa, no una herramienta. La cultura, la comunicación y la coordinación son tan importantes como la tecnología.
• La inteligencia en materia de recuperación se está convirtiendo en un factor diferenciador frente a la competencia. Las empresas que se recuperan de forma eficaz y rápida protegen sus ingresos, su reputación y la confianza de sus clientes. 

De las operaciones de TI a las operaciones de respuesta: ¿qué ha cambiado?

Stephen reflexiona sobre una época anterior de las tecnologías de la información en la que los equipos solían dar soporte a los sistemas sin entender del todo las aplicaciones empresariales que estos alimentaban. La recuperación consistía en restaurar la infraestructura. Hoy en día, ese modelo se queda corto. Los entornos modernos son:

• Distribuido
• Cloud
• Basado en DevOps
• Cuestiones sensibles en materia de seguridad
• Totalmente integrado con las fuentes de ingresos

ResOps reconoce que la recuperación ya no es una función aislada de TI. Es una disciplina multifuncional que ayuda a conectar la infraestructura, el desarrollo de software y la seguridad con resultados empresariales reales.

Por qué las métricas tradicionales no lo dicen todo

RTO. RPO. Estas métricas han servido de guía en la planificación de la recuperación ante desastres durante años. Pero, como explica Stephen, recuperar los datos rápidamente no basta si los datos que recuperas no están limpios. Introduce un indicador más significativo: MTCR. No se trata solo de lo rápido que te recuperas, sino de lo rápido que puedes volver a un estado verificado y fiable.

En un incidente de ransomware, esa diferencia es enorme. Restaurar datos comprometidos puede reiniciar un ciclo de ataque. ResOps se centra en restaurar la integridad operativa, no solo la funcionalidad.

Avance: Por qué es importante una recuperación «limpia»

En este fragmento de STRIVE, Stephen explica por qué los indicadores tradicionales de recuperación no dan en el clavo, y por qué la recuperación es una disciplina que abarca varias áreas.

La verdadera barrera: los silos organizativos

La tecnología no suele ser el mayor obstáculo para la resiliencia. Lo es la estructura. Los equipos de seguridad suelen depender de un ejecutivo. Los equipos de infraestructura, de otro. Los equipos de aplicaciones, de otro más. Cada uno con prioridades diferentes, incentivos distintos y definiciones diferentes del éxito.

ResOps se enfrenta a esa fragmentación. Stephen explica cómo los talleres colaborativos y la coordinación entre departamentos están ayudando a acabar con esos silos. Porque, durante un incidente cibernético, la falta de coordinación en la organización ralentiza la recuperación mucho más de lo que lo harían las carencias en herramientas.

¿Por qué Commvault se está sumando a este debate?

STRIVE no se centra en las características de los productos. Se centra en cómo está evolucionando la forma de pensar sobre la Recovery. ResOps se alinea estrechamente con lo que observamos sobre el terreno:

• Clientes que tienen dificultades para coordinarse durante los incidentes.
• Organizaciones que están restaurando las infraestructuras, pero que se preguntan por la integridad de los datos.
• La dirección pide indicadores que reflejen el impacto real en el negocio.

El concepto del MTCR replantea la inteligencia de recuperación en torno a la confianza empresarial, y ahí es hacia donde se dirige el sector. La recuperación ya no es un proceso de back-office. Es una cuestión que compete a la dirección.

El futuro de la inteligencia de recuperación

De cara al futuro, es probable que ResOps madure rápidamente. Se espera que, en los próximos 12 a 18 meses, las organizaciones:

• Integrar mejor los procesos de seguridad y recuperación.
• Adopta nuevos indicadores centrados en la recuperación.
• Incorpora la resiliencia en una fase más temprana del ciclo de vida de las aplicaciones.
• Invierte en una solución inteligente que distinga los datos limpios de los datos comprometidos.

Las ciberamenazas se están acelerando. Las estrategias de Recovery deben evolucionar al mismo ritmo. ResOps ayuda a proporcionar un marco para hacerlo.

Mira el episodio completo

En este episodio, hablamos de:

• En qué se diferencia ResOps de las operaciones de TI tradicionales.
• Por qué el MTCR está ayudando a redefinir los indicadores de recuperación.
• Cómo se ve la alineación organizativa en la práctica.
• Cómo influye la cultura DevOps en la resiliencia.
• Hacia dónde se prevé que avance la inteligencia de recuperación. te informo

Ver ahora. Si te encargas de la preparación cibernética, la continuidad o la estrategia de recuperación, no te puedes perder este debate.

Preguntas frecuentes

P: ¿Qué es ResOps?

R: ResOps (Operaciones de Resiliencia) es una disciplina emergente que integra las operaciones de TI, la seguridad, DevOps y las partes interesadas del negocio para ayudar a mejorar la inteligencia de recuperación y la resiliencia de la organización.

P: ¿En qué se diferencia ResOps de las operaciones de TI tradicionales?

R: Las operaciones de TI tradicionales se centran principalmente en el tiempo de actividad de la infraestructura. ResOps amplía ese enfoque para incluir la recuperación de datos limpios, la coordinación entre departamentos y la alineación con el negocio.

P: ¿Qué es el Tiempo Medio hasta la Recuperación tras una Limpieza (MTCR)?

R: El MTCR mide la rapidez con la que una organización puede restaurar datos verificados y limpios, y reanudar las operaciones de forma segura tras un incidente cibernético, no solo la rapidez con la que se vuelven a poner en marcha los sistemas.

P: ¿Por qué métricas como el RTO y el RPO no son suficientes en los entornos actuales?

R: Miden la velocidad y la actualidad de los datos, pero no su integridad. En casos de ransomware, restaurar los datos afectados puede alargar el tiempo de interrupción del servicio.

P: ¿Cómo pueden las organizaciones empezar a implementar ResOps?

R: Empezando por:

• • Coordinar los equipos de seguridad, infraestructura y DevOps.
  • Evaluar los indicadores de recuperación más allá del RTO y el RPO.
  • Probando los procesos de recuperación limpia.
  • Romper las barreras entre departamentos.
  • Incorporar el enfoque de la resiliencia en una fase más temprana del diseño de los sistemas.

P: ¿Por qué cada vez es más importante la inteligencia de recuperación?

R: A medida que las amenazas cibernéticas se vuelven cada vez más sofisticadas, la capacidad de recuperarse de forma limpia, rápida y segura repercute directamente en los ingresos, la confianza de los clientes y el cumplimiento normativo.

Darren Thomson es director técnico de campo en Commvault.

Hacer crecer una empresa basada en datos ya es complicado. ¿Y hacerlo cumpliendo con los requisitos del RGPD, gestionando miles de clientes, dando herramientas a los equipos de análisis y poniendo en marcha una nueva infraestructura en menos de dos semanas? Eso ya es otro nivel de complejidad.

En un episodio reciente de STRIVE, me reuní con Asif Dromi, de monday.com, y Ben Herzberg, de Commvault, para desentrañar lo que realmente se necesita para poner en práctica la seguridad de los datos a gran escala, no en teoría, sino en la práctica. No se trata de una conversación general sobre buenas prácticas, sino de una visión realista de cómo se entrecruzan las decisiones sobre seguridad, cumplimiento normativo, automatización e infraestructura cuando el tiempo apremia.

Mira el episodio completo. Si eres CISO, responsable de datos, arquitecto o responsable de cumplimiento normativo, este episodio te ofrece algo más valioso que la teoría. Te muestra cómo:

• Una empresa en rápido crecimiento supo hacer frente a las exigencias del RGPD sin frenar la innovación.
• La infraestructura como código puede simplificar las auditorías.
• La automatización reduce el riesgo en lugar de aumentar la complejidad.
• La seguridad y la agilidad empresarial no tienen por qué estar reñidas.

No es habitual escuchar directamente a los operadores que han llevado esto a cabo en condiciones reales. Eso es lo que hace que esta conversación de STRIVE sea diferente.

Puntos clave: Cómo poner en práctica la seguridad de los datos a gran escala

• El cumplimiento normativo y el crecimiento no tienen por qué estar reñidos. Monday.com demuestra cómo los requisitos del RGPD y la rápida expansión pueden coexistir cuando la seguridad se integra en la arquitectura desde el principio.
• Los permisos manuales no son escalables. La automatización sí lo es. La infraestructura como código y los controles de acceso basados en API pueden convertir la gobernanza de un cuello de botella en un multiplicador de fuerzas.
• El acceso basado en roles debe adaptarse a cómo se usan los datos. A medida que más equipos dependen de los análisis, la visibilidad y los controles detallados cobran importancia para evitar que los permisos se descontrolen.
• La seguridad operativa significa visibilidad. No se trata solo de establecer políticas, sino de supervisar, auditar y adaptar los controles de forma dinámica a medida que cambian los entornos.
• La rapidez es posible cuando la arquitectura está bien pensada. Se puso en marcha un almacén de datos que cumple con la normativa europea en menos de dos semanas porque la gobernanza, la automatización y las herramientas se diseñaron para poder escalar.
• La madurez en materia de seguridad permite la innovación. Cuando los permisos, la infraestructura y el cumplimiento normativo se pueden programar, las organizaciones pueden avanzar más rápido.

El verdadero reto: crecimiento + cumplimiento normativo + rapidez

Para monday.com, el reto no era solo almacenar los datos europeos en Europa. Era:

• Garantizar el cumplimiento del RGPD y la residencia de datos a nivel regional.
• Asegurarse de que los empleados solo accedieran a los datos relevantes.
• Mantener la transparencia y la auditabilidad.
• Ayudábamos a los analistas y desarrolladores que necesitaban un acceso rápido.
• Y todo ello bajo unos plazos de trabajo muy ajustados.

Como explica Asif en el episodio, convertirse en una organización basada en datos implica que el acceso interno se amplía rápidamente. Cuanto más recurren los equipos al análisis de datos, más complejos se vuelven los permisos. Y ahí es donde muchas organizaciones se topan con un obstáculo. La seguridad pasa a ser un proceso manual, los permisos se vuelven frágiles y el cumplimiento normativo se convierte en algo reactivo. Eso no es seguridad operativa. Es un castillo de naipes.

Incorporar la seguridad en la arquitectura desde el primer día 

Una de las partes más interesantes del episodio es cómo abordó monday.com el problema desde el punto de vista arquitectónico. En lugar de adaptar el sistema a posteriori para cumplir con la normativa, creó:

• Un almacén de datos europeo específico.
• Controles de acceso claros basados en roles.
• Modelos de permisos muy detallados.
• Capas de gobernanza automatizadas.

Ben describe lo que ocurre en muchas grandes organizaciones: con el tiempo, los permisos se acumulan en capas, a menudo sin una visibilidad centralizada. Al final, nadie sabe con certeza quién puede acceder a qué. Poner en práctica la seguridad significa evitar esa deriva. Significa crear sistemas en los que el control se adapte automáticamente a medida que crece el uso.

La automatización es el multiplicador de fuerzas

Si hay un tema que recorre todo este episodio, ese es la automatización. En lugar de tratar los permisos como «tickets» y actualizaciones manuales, monday.com envolvió su infraestructura en código. Las bases de datos, los roles y las políticas de acceso podían crearse y modificarse mediante programación.

¿El resultado? Se puso en marcha un entorno conforme a la normativa y escalable en menos de dos semanas. Eso no es suerte. Es arquitectura. Y es un poderoso recordatorio de que la seguridad no te frena cuando está bien implementada. De hecho, potencia la velocidad.

Qué significa realmente poner en práctica la seguridad de los datos

El término «poner en práctica» se usa mucho. En este episodio, se define como:

• Visibilidad constante de los datos confidenciales.
• Gestión centralizada y automatizada de permisos.
• Seguimiento de accesos.
• Integración con herramientas de colaboración.
• Políticas que se adaptan a medida que crecen los usuarios y los datos.

Los controles estáticos no son escalables. Los flujos de trabajo manuales no son escalables. La seguridad debe volverse dinámica, formar parte del tejido operativo de la organización. Y ese cambio es precisamente lo que hoy en día supone un reto para muchas empresas.

Mira el episodio completo de STRIVE

En el debate, te contarán más sobre:

• Cómo estructuró monday.com su almacén de datos europeo.
• Las principales lecciones aprendidas durante la implementación rápida.
• Por qué la automatización era imprescindible.
• Lo que las empresas suelen subestimar sobre la proliferación de permisos.
• Cómo plantearse la puesta en práctica de la gobernanza antes de que se amplíen las iniciativas de IA.

Ver ahora.

Preguntas frecuentes 

P: ¿Cómo pueden los equipos pequeños implementar una seguridad de datos escalable?

R: Empieza con un modelo de permisos claro y herramientas de «infraestructura como código». Automatiza la gestión de permisos desde el principio para evitar cuellos de botella manuales a medida que crezcas.

P: ¿Qué papel juega la automatización en el cumplimiento normativo?

R: La automatización ayuda a garantizar la coherencia, reducir los errores y simplificar las auditorías. Mediante el uso de API y scripts, puedes supervisar y ajustar los permisos de forma dinámica.

P: ¿Cuánto tiempo suele llevar crear un entorno de datos que cumpla con la normativa y sea escalable?

R: Con una buena planificación y las herramientas adecuadas, empresas como monday.com lo han conseguido en menos de dos semanas. La rapidez depende del alcance del proyecto y de la infraestructura existente.

P: ¿Cuáles son las mejores prácticas para poner en práctica la seguridad de los datos?

R: Implementa controles de acceso basados en roles, automatiza la gestión de permisos, supervisa los registros de acceso con regularidad e integra herramientas de seguridad con las plataformas de colaboración para tener una supervisión en tiempo real.

Chris Mierzwa es director sénior de marketing de cartera en Commvault.

Puntos clave

• Los marcos de cumplimiento recogen las lecciones aprendidas de los fallos que se han producido en la vida real y ayudan a las organizaciones a reforzar su resiliencia, su gobernanza y su estabilidad operativa.
• Las organizaciones que abordan el cumplimiento normativo como una iniciativa para fomentar la confianza pueden contribuir a reforzar la confianza de los clientes, las relaciones con los socios y la credibilidad de la marca.
• La armonización normativa y unos controles de riesgo sólidos pueden ayudar a mejorar los resultados de las aseguradoras, al demostrar una postura de seguridad madura y resistente.
• Relacionar los requisitos de cumplimiento con resultados empresariales cuantificables permite a las organizaciones vincular directamente las inversiones en resiliencia con la protección de los ingresos y la continuidad del negocio.
• Las capacidades de ciberresiliencia, como las copias de seguridad inmutables, la recuperación rápida y los marcos de gobernanza, ayudan a las organizaciones a convertir el cumplimiento normativo en una ventaja competitiva.

En las salas de juntas de toda Europa y más allá, el término «cumplimiento normativo» se ha convertido en una palabra con mucha carga. Evoca imágenes de papeleo interminable, una presión regulatoria cada vez mayor y la amenaza constante de multas.

RGPD. NIS2. DORA. Las siglas no dejan de aparecer y, para muchas organizaciones, puede parecer que se están ahogando entre tanta normativa. Pero, ¿y si nos hemos estado planteando el cumplimiento normativo de forma equivocada? ¿Y si el cumplimiento normativo no se trata solo de evitar sanciones, sino de construir una empresa mejor, más sólida y más resistente?

La analogía del seguro: las normas existen por algo

Hay un paralelismo muy útil entre el cumplimiento normativo y los seguros. Cuando aseguras tu coche, la aseguradora establece ciertas condiciones. Los frenos deben funcionar. Los neumáticos no deben estar lisos. Puede que se exija un sistema de alarma. Puedes quejarte de las molestias o del coste, pero, en el fondo, esas normas existen porque ayudan a reducir el riesgo. Contribuyen a que los accidentes sean menos probables. Ayudan a protegerte tanto a ti como a los demás.

Y aquí está lo importante: esos requisitos suelen ser una buena idea, tanto si contratas el seguro como si no. La regulación funciona de manera muy similar. Los gobiernos y los reguladores no crean marcos normativos porque les guste hacerlo. Las regulaciones son respuestas a fallos del mundo real: filtraciones de datos, interrupciones operativas, riesgo sistémico. Codifican lecciones aprendidas a base de errores.

Puede que te parezca una carga. Puede que te resulte frustrante. Pero cuando analizas con detenimiento lo que exigen estos marcos, es difícil argumentar que los principios fundamentales no sean sólidos.

• Protege los datos de los clientes.
• Fomenta la resiliencia operativa.
• Conoce los riesgos de tu cadena de suministro.
• Ser capaz de recuperarse de los incidentes cibernéticos.
• Demostrar buena gestión y responsabilidad.

Nada de eso es mala idea.

De evitar multas a generar confianza

Con demasiada frecuencia, el cumplimiento normativo se plantea desde un punto de vista defensivo: «Haz esto para que no te multen». «Haz esto para que no te metan en la cárcel». Eso es muy poco. Y es una oportunidad perdida. Cuando cambiamos de perspectiva, el cumplimiento normativo se convierte en algo mucho más potente. Se convierte en un motor de confianza.

Tomemos como ejemplo el RGPD. En esencia, se trata de proteger los datos personales. Si tu organización implementa prácticas sólidas de protección de datos —no solo para cumplir con los requisitos, sino porque tus sistemas protegen de verdad la información de los clientes—, eso genera confianza. Los clientes se sienten más seguros al hacer negocios contigo. Los socios están más dispuestos a integrarse contigo. Los reguladores te consideran un riesgo menor. La confianza no es un resultado de la normativa. Es una ventaja comercial.

Lo mismo se aplica a la Ley de Resiliencia Operativa Digital. No se trata solo de notificar incidentes, sino de ser capaz de resistir las interrupciones y recuperarse de ellas. En un mundo en el que los ciberataques son inevitables, la resiliencia no es opcional. Es fundamental para la continuidad, la reputación y el valor a largo plazo. Cuando el cumplimiento normativo impulsa la resiliencia, la resiliencia impulsa la estabilidad empresarial, y la estabilidad impulsa el crecimiento.

Regulación y seguros: un círculo vicioso

También existe una alineación natural entre la regulación y los mercados de seguros. Cuando los reguladores imponen ciertas normas, las aseguradoras las siguen rápidamente. Las organizaciones que demuestran cumplimiento normativo y sólidos controles de riesgo resultan más atractivas para las aseguradoras. Pueden beneficiarse de mejores condiciones, una cobertura más amplia o primas más favorables. Esto crea un círculo vicioso:

• La normativa establece unos requisitos mínimos.
• Las organizaciones refuerzan sus controles.
• Las aseguradoras premian las estrategias de gestión de riesgos más sólidas.
• Los mercados se vuelven más estables y resistentes.

El cumplimiento normativo, en este contexto, se convierte en una señal para el mercado: nos tomamos el riesgo muy en serio.

El eslabón perdido: cómo relacionar el cumplimiento normativo con los resultados empresariales

Una de las oportunidades más importantes para las organizaciones —sobre todo para los proveedores de tecnología— es dejar claro el vínculo entre el cumplimiento normativo y el valor empresarial. Por ejemplo:

• Si un producto crea copias de seguridad inmutables, eso ayuda a cumplir los requisitos normativos en materia de integridad de los datos.
• Si permite una recuperación rápida tras los incidentes cibernéticos, eso ayuda a cumplir con los requisitos de resiliencia operativa.
• Si ofrece registros de auditoría y informes claros, eso ayuda a cumplir con los requisitos de gobernanza y supervisión.

Pero no debería quedarse ahí. El siguiente paso es explicar las ventajas para la empresa:

• Las copias de seguridad inmutables ayudan a reducir el impacto del ransomware y a proteger los ingresos.
• Una recuperación más rápida ayuda a reducir al mínimo el tiempo de inactividad y a mantener la confianza de los clientes.
• Una buena gestión ayuda a reducir el escrutinio regulatorio y refuerza la credibilidad de la marca.

Esta correspondencia es fundamental. El cumplimiento normativo no es el objetivo final, sino el mecanismo que permite alcanzar los resultados que importan a las empresas: la continuidad, la reputación, la confianza de los clientes y la diferenciación competitiva.

El cumplimiento normativo como innovación, no como obligación

Se tiende a ver el cumplimiento normativo como algo que hay que «sacar adelante». Un centro de costes. Un mal necesario. Pero si echamos un vistazo a la historia, muchas de las buenas prácticas que ahora se consideran fundamentales para la informática y la seguridad modernas surgieron a raíz de requisitos normativos o de seguros. Con el tiempo, se han ido integrando en el funcionamiento de las organizaciones bien gestionadas. Cifrado. Control de accesos. Planificación de la respuesta ante incidentes. Pruebas de continuidad del negocio. Gestión de riesgos de terceros. En su momento, puede que se consideraran una carga normativa. Hoy en día, son requisitos imprescindibles para cualquier empresa que se precie. Las organizaciones que tratan el cumplimiento normativo como un catalizador de la innovación —en lugar de como un mero trámite burocrático— suelen ser las que se sitúan a la cabeza. Incorporan la resiliencia en su arquitectura. Diseñan teniendo en cuenta la gobernanza. Convierten los requisitos normativos en capacidades de producto y propuestas de valor para el cliente.

Ciberresiliencia: donde el cumplimiento normativo y la estrategia se unen

Aquí es donde la ciberresiliencia cobra un papel fundamental. Las normativas modernas reconocen cada vez más una simple verdad: la prevención no basta. Los incidentes ocurrirán. Lo que marca la diferencia es la capacidad de una organización para responder y recuperarse.

La ciberresiliencia —la capacidad de resistir, recuperarse y adaptarse a las perturbaciones cibernéticas— ya no es solo una cuestión de seguridad. Es un imperativo estratégico. Favorece el cumplimiento normativo, sí. Pero, lo que es más importante, sustenta la continuidad operativa y la confianza empresarial. Cuando las organizaciones invierten en arquitecturas resilientes, datos inmutables, capacidades de recuperación rápida y marcos de gobernanza sólidos, no solo cumplen con los requisitos de los organismos reguladores. Están construyendo empresas duraderas.

Una conversación diferente sobre el cumplimiento normativo

Quizá sea hora de cambiar la forma de ver las cosas. En lugar de preguntarnos: «¿Qué es lo mínimo que tenemos que hacer para cumplir con la normativa?», deberíamos preguntarnos:

• ¿Cómo nos hace más fuertes esta normativa?
• ¿Qué buena práctica se está codificando aquí?
• ¿Cómo podemos aprovechar esto para reforzar la confianza de los clientes y socios?
• ¿En qué sentido supone esto una ventaja competitiva?

Hacer bien el cumplimiento normativo no tiene que ver con el miedo. Tiene que ver con la previsión. Refleja las lecciones aprendidas en distintos sectores. Incorpora las mejores prácticas a las operaciones diarias. Y cuando se vincula claramente con las capacidades del producto y los resultados empresariales, se convierte en un argumento comercial muy convincente.

Sí, la normativa puede parecer una carga. Sí, no paran de aparecer acrónimos. Pero detrás de todo ese papeleo hay algo mucho más valioso: un marco para gestionar mejor tu negocio. El cumplimiento normativo no consiste solo en evitar sanciones. Se trata de fomentar la resiliencia. Y la resiliencia, en última instancia, es lo que impulsa el éxito sostenible. Descubre aquí cómo Commvault facilita la protección de datos para ayudar a tu organización a cumplir con los requisitos normativos.

Preguntas frecuentes

P: ¿Por qué las organizaciones deberían considerar el cumplimiento normativo como algo más que una simple obligación legal?

R: Los marcos de cumplimiento suelen reflejar las mejores prácticas desarrolladas en respuesta a incidentes cibernéticos reales, fallos operativos y retos de gobernanza. Las organizaciones que adoptan el cumplimiento de forma estratégica pueden contribuir a reforzar la resiliencia, mejorar la confianza y generar valor empresarial a largo plazo.

P: ¿Cómo contribuye el cumplimiento normativo a la confianza de los clientes?

R: Unas prácticas sólidas en materia de cumplimiento normativo demuestran que una organización se toma en serio la protección de datos, la gobernanza y la continuidad operativa. Esto puede ayudar a aumentar la confianza de los clientes, reforzar las relaciones con los socios y posicionar a la organización como una empresa de menor riesgo.

P: ¿Qué relación hay entre el cumplimiento normativo y la resiliencia cibernética?

R: La normativa actual se centra cada vez más en la capacidad de una organización para recuperarse de las interrupciones, en lugar de limitarse únicamente a prevenirlas. Las inversiones en infraestructuras resilientes, copias de seguridad inmutables y capacidades de recuperación rápida pueden ayudar a las organizaciones a mantener la continuidad durante los ciberincidentes.

P: ¿Cómo puede el cumplimiento normativo influir positivamente en los seguros y la gestión de riesgos?

R: Las aseguradoras suelen valorar mejor a las organizaciones que cuentan con programas de cumplimiento bien consolidados y controles de seguridad sólidos. Esto puede traducirse en mejores opciones de cobertura, condiciones de póliza más favorables y, posiblemente, primas más bajas.

P: ¿Por qué es importante vincular las iniciativas de cumplimiento normativo con los resultados empresariales?

R: Las iniciativas de cumplimiento normativo son más eficaces cuando las organizaciones demuestran claramente cómo los controles contribuyen a objetivos más amplios, como proteger los ingresos, reducir el tiempo de inactividad y mantener la confianza de los clientes. Esto ayuda a los directivos a ver el cumplimiento normativo como una inversión estratégica en lugar de como un centro de costes.

P6: ¿Cómo pueden las organizaciones convertir el cumplimiento normativo en una ventaja competitiva?

R: Las empresas que integran la resiliencia, la gobernanza y la seguridad en sus productos y operaciones pueden diferenciarse en el mercado. Al adaptarse de forma proactiva a las expectativas normativas, las organizaciones pueden reforzar su reputación y generar mayor confianza entre los clientes y las partes interesadas.

Darren Thomson es director técnico de campo en Commvault.

Puntos clave

• La soberanía operativa se centra en quién puede acceder a los sistemas y bajo qué jurisdicciones operan.
• El acceso de los proveedores, los flujos de telemetría y las vías de asistencia pueden generar lagunas ocultas en materia de soberanía.
• La soberanía operativa es más difícil de certificar porque requiere una visibilidad y una auditoría continuas.
• Las organizaciones deben poder demostrar y documentar todas las vías de acceso a los entornos soberanos.

Si se pregunta a la mayoría de las organizaciones en qué aspecto es más sólido su programa de soberanía, la respuesta suele ser una variante de los mismos dos aspectos: la localización de los datos y el cifrado. Saben dónde se almacenan sus datos principales. Han implementado acuerdos de «trae tu propia clave» o «conserva tu propia clave». Pueden presentar certificaciones.

Pregúntales quién ha accedido a su entorno soberano en los últimos noventa días, desde qué países y bajo qué jurisdicciones legales… y la confianza suele esfumarse. La soberanía operativa es el pilar más difícil de auditar, el que más se tiende a subestimar y el ámbito más habitual en el que una postura de soberanía que parece sólida sobre el papel se desmorona en la práctica. El Informe sobre la Readiness para la soberanía digital lo señala como uno de los cuatro pilares; este artículo va más allá. La pregunta que la mayoría de las organizaciones no saben responder: «¿Quién ha accedido a tu entorno soberano en los últimos 90 días, desde qué países y bajo qué jurisdicciones legales?»

Qué significa realmente la soberanía operativa

La soberanía operativa no tiene que ver con dónde se almacenan los datos. Se trata de quién gestiona el entorno y quién tiene acceso a él. Abarca tres aspectos que la mayoría de los programas de soberanía tratan como detalles de implementación en lugar de considerarlos cuestiones prioritarias:

• Acceso del personal y jurisdicción. Toda persona que pueda acceder a su entorno soberano —ya sea para ofrecer soporte, realizar tareas de mantenimiento, llevar a cabo la supervisión o responder a incidentes— opera bajo una jurisdicción legal definida. Si un ingeniero de soporte de un país sujeto a una ley extranjera de acceso a datos puede acceder a sus sistemas, la soberanía de su infraestructura dependerá en gran medida de la exposición legal de ese ingeniero.

La mayoría de las organizaciones, cuando hacen esta auditoría por primera vez, se encuentran con al menos una vía de asistencia que cruza un límite jurisdiccional que no habían tenido en cuenta.

• Acceso de terceros y proveedores. Tu límite de soberanía se extiende a todos los proveedores, proveedores de servicios gestionados y platform de software platform acceso a tu entorno soberano. Plataformas de ITSM, herramientas de monitorización, sistemas SIEM… Si estos se encuentran fuera de tu límite de soberanía pero tienen acceso a datos o metadatos dentro de él, tienes una brecha que los controles de localidad de datos no pueden cerrar.
• Tráfico de telemetría, facturación y plano de control. Los programas de soberanía de datos se centran en los datos primarios. La soberanía operativa requiere identificar adónde va todo lo demás: la telemetría que genera tu infraestructura, los metadatos que recopilan tus sistemas de monitorización, los datos de facturación que procesa tu proveedor. Estos flujos pueden cruzar las fronteras jurisdiccionales incluso cuando los datos primarios no lo hacen, y rara vez se mapean.

Por qué este pilar es más difícil de certificar… y por qué eso importa

La localidad de los datos es relativamente sencilla de documentar. Se puede hacer referencia a una región de almacenamiento, a un acuerdo de residencia de datos o a una auditoría de terceros. La soberanía operativa no cuenta con el mismo rastro documental. No existe ninguna certificación que garantice la situación jurisdiccional de cada ingeniero de soporte que pueda acceder a tu entorno.

Esto es precisamente lo que lo convierte tanto en el pilar más difícil de auditar como en el más importante a la hora de hacerlo bien. Además, está directamente relacionado con el reto de la soberanía mínima viable: aplicar los controles operativos adecuados a las cargas de trabajo adecuadas requiere saber cuáles son esos controles, y es precisamente en la soberanía operativa donde ese conocimiento suele faltar.

La dimensión de la cadena de suministro

La NIS2, que amplía las obligaciones en materia de ciberseguridad a los sectores de la energía, el transporte, la sanidad y las infraestructuras digitales, exige ahora a las organizaciones que evalúen las prácticas de ciberseguridad de sus proveedores de tecnología. Para los programas de soberanía, esto tiene una consecuencia directa: la postura de soberanía de los proveedores ya no es un simple detalle en la contratación pública. Es un requisito que se puede auditar.

Esto implica plantear nuevas preguntas a cada proveedor que se encuentre dentro de su perímetro de soberanía: ¿Dónde se encuentra su personal de soporte? ¿Bajo qué jurisdicción legal operan? ¿Qué ocurre con el acceso que tienen a mi entorno si su empresa es adquirida por una entidad no perteneciente a la UE?

Cómo es lo bueno

Un entorno operativamente soberano tiene cuatro características que se pueden demostrar, no solo documentar:

• Se ha realizado un mapa de todas las vías de acceso al entorno soberano: no solo el acceso principal, sino también el de los proveedores, el de soporte técnico y el de los sistemas de monitorización.
• El estatus jurisdiccional de cada persona o sistema que tiene ese acceso se documenta y se audita con una periodicidad definida.
• Se hace un inventario de los flujos de tráfico de telemetría, metadatos y del plano de control, y estos se mantienen dentro de los límites de soberanía o se evalúan y aceptan explícitamente como fuera del ámbito de aplicación.
• La organización puede responder a la pregunta sobre el acceso en un plazo de noventa días —y lo hace con precisión, aportando pruebas—.

Una cosa más: la soberanía operativa no se limita al control de acceso. Si la recuperación requiere personal que trabaje fuera de tus límites de soberanía, la estrategia falla en el momento en que se produce un incidente. Ese es el tema de la cuarta entrada de esta serie. El Informe sobre la preparación para la soberanía digital incluye una pregunta de evaluación directa sobre la soberanía operativa.

Preguntas frecuentes

P: ¿Qué es la soberanía operativa?

R: La soberanía operativa se refiere a quién gestiona y tiene acceso a un entorno, incluyendo al personal, a los proveedores y a los sistemas de soporte. Va más allá del lugar donde se almacenan los datos.

P: ¿Por qué se suele pasar por alto la soberanía operativa?

R: Muchas organizaciones se centran principalmente en la ubicación y el cifrado de los datos. A menudo, las vías de acceso, el personal de soporte y los flujos de telemetría no se auditan a fondo.

P: ¿Cómo influyen los proveedores en la postura de soberanía?

R: Los proveedores y los proveedores de servicios gestionados pueden tener acceso a sistemas sensibles o a metadatos. Sus jurisdicciones legales y prácticas operativas pueden afectar al cumplimiento general de las normas de soberanía.

P: ¿Por qué son importantes la telemetría y los metadatos?

R: Aunque los datos primarios se queden en el ámbito local, la telemetría y los metadatos pueden traspasar las fronteras jurisdiccionales. Estos flujos pueden suponer riesgos de cumplimiento normativo si no se gestionan adecuadamente.

P: ¿Qué incluye un modelo sólido de soberanía operativa?

R: Incluye rutas de acceso definidas, controles jurisdiccionales documentados, acceso de proveedores auditado y visibilidad de todos los flujos de telemetría y metadatos.

Alex Zinin es vicepresidente y director general del área de proveedores de servicios gestionados en Commvault.

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 de recuperación, backup y los modelos de custodia clave 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 recuperación está ubicado en otro país. Y lo que es peor, el propio entorno de recuperación (alojado en una cloud , 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 estamos. 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 entrada 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é pasa después de 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 operar en una jurisdicción diferente. Bajo presión, recurrir a ellos es la vía 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 copia 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 realizar 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 están 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 todo el conjunto de entornos. Las lagunas en los entornos secundarios se hacen evidentes justo 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 quiere decir que estos controles estén mal. 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 han sido comprometidos antes de restaurarlos en el entorno de producción —no solo que sean recientes, sino que no hayan sido 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 comprueban 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 pida. Las que no lo hagan tendrán que prepararlas bajo presión, delante de 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 backup carezca 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 tú mismo gestionas tu 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 de cara a la soberanía?

R: Deberían hacer 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.

Puntos clave

• La soberanía mínima viable (MVS) se centra en aplicar el nivel adecuado de control a las cargas de trabajo adecuadas.
• Tratar todas las cargas de trabajo por igual puede generar una complejidad y unos costes innecesarios, o una protección insuficiente.
• Las organizaciones suelen encajar en tres perfiles de soberanía: soberanía plena, empresa regulada y multicloud híbrido.
• La gobernanza coherente en entornos mixtos es uno de los mayores retos operativos.

Existe una versión del debate sobre la soberanía digital que lleva a las organizaciones a una situación costosa, operativamente onerosa y —si somos sinceros— que va más allá de lo que exigen sus obligaciones reales. La soberanía máxima suena responsable. En la práctica, a menudo se trata de un error de calibración.

Existe una versión igualmente común que conduce a una situación peligrosamente precaria: controles que cumplen una lista de requisitos, pero que no resistirían una auditoría, un incidente o un regulador que haya dejado de aceptar la intención documentada como prueba de un control demostrado.

Las organizaciones que gestionan correctamente la soberanía tienden a adoptar un enfoque más riguroso y práctico que cualquiera de los dos extremos: se preguntan qué deben realmente, a quién y para qué. A continuación, se estructuran según ese estándar: ni más ni menos.

Esta es la disciplina del MVS, presentada en el Informe sobre la Readiness para la soberanía digital y desarrollada en detalle aquí.

El MVS no es un atajo. Es el reconocimiento de que el objetivo es el nivel adecuado de control, aplicado de forma coherente en todas las cargas de trabajo que lo requieran.

No todas las cargas de trabajo son iguales

El punto de partida de un enfoque MVS es la clasificación de las cargas de trabajo, y la mayoría de las organizaciones se saltan este paso por completo.

Un sistema de negociación que procesa datos financieros regulados conlleva obligaciones de soberanía fundamentalmente diferentes a las de una herramienta interna de colaboración de RR. HH. Una base de datos que contiene datos personales de ciudadanos de la UE está sujeta a un régimen legal y normativo diferente al de un entorno de desarrollo que ejecuta datos de prueba anonimizados.

Tratar todos estos casos de forma idéntica —ya sea aplicando los máximos controles de soberanía de forma generalizada o asumiendo que un único modelo de implementación lo abarca todo— es lo que lleva a las organizaciones a acabar con soluciones excesivamente complejas o con una protección insuficiente.

La pregunta adecuada antes de cualquier decisión de implementación es: «¿Qué requiere esta carga de trabajo en cada uno de los cuatro pilares de soberanía?». El Informe de Readiness incluye una autoevaluación estructurada precisamente en torno a esa pregunta.

Los tres perfiles —y lo que realmente necesitan—

Las empresas reguladas se clasifican en tres perfiles reconocibles, cada uno con diferentes motivaciones principales y prioridades de inversión.

• El verdadero soberano. Organismos públicos, contratistas de defensa y operadores de infraestructuras nacionales críticas. Para estas organizaciones, la soberanía no es un requisito de cumplimiento, sino un mandato operativo. A menudo, la ley exige el máximo control sobre todas las dimensiones de la pila tecnológica, y se aceptan las compensaciones en términos de costes porque la alternativa no es viable.
• La organización regulada. Empresas de servicios financieros, organizaciones sanitarias y empresas energéticas. Estas organizaciones se enfrentan a requisitos vinculantes derivados de la DORA, la NIS2, el RGPD y marcos específicos de cada sector. Las obligaciones de cumplimiento también pueden corresponderse con esquemas de certificación de la UE —incluidos EUCS, EUCC, BSI C5 y SecNumCloud— en función del sector y del contexto de implementación.

En determinados ámbitos, esto no es negociable —especialmente en lo que se refiere a la residencia de datos, los controles de acceso operativo y la Recovery dentro de los límites jurisdiccionales—. Pero no todas las cargas de trabajo conllevan la misma obligación.

• La organización híbrida multicloud. Organizaciones con inversiones existentes en hiperescaladores que se enfrentan a una presión cada vez mayor en materia de soberanía por parte de clientes, reguladores o requisitos de contratación pública. Su reto no es la migración total, sino la incorporación de controles de soberanía en un entorno mixto y el mantenimiento de una gobernanza coherente en todo él.

El coste de un mal ajuste

Una sobredimensionación de la soberanía genera sus propios riesgos operativos. Las organizaciones que aplican controles de soberanía máximos a cargas de trabajo que no los requieren asumen costes y complejidad que no sirven a ningún propósito normativo ni empresarial.

La falta de ingeniería es el modo de fallo más habitual y el más peligroso. Por lo general, no se detecta hasta que llega la auditoría o, lo que es peor, hasta que se produce un incidente y la recuperación se convierte en un problema con implicaciones legales. (Ese modo de fallo es el tema de la cuarta entrada de esta serie).

Un punto de partida práctico

Un enfoque MVS sigue tres pasos:

1. Clasificar las cargas de trabajo según sus requisitos reales de soberanía en cada pilar; no empezar por los modelos de implementación.
2. Asignar cada clase de carga de trabajo al nivel de implementación que cumpla dichos requisitos, abarcando todo el espectro, desde las regiones de hiperescaladores públicos hasta la nube pública soberana y los entornos gestionados en las propias instalaciones.
3. Gobernar el entorno mixto resultante de forma coherente: los controles, las pruebas de auditoría y las capacidades de Recovery deben poder demostrarse en todo el entorno, no solo en el nivel más soberano.

El tercer paso es donde la mayoría de los programas encuentran dificultades. Mantener controles de soberanía coherentes en un entorno mixto supone un reto de gobernanza operativa —y, concretamente, el ámbito de la soberanía operativa—, tema del tercer artículo de esta serie, el pilar que la mayoría de las estrategias tratan como algo secundario.

Utiliza la autoevaluación del Informe de Readiness para la soberanía digital para determinar tu situación actual en los cuatro pilares.

Preguntas frecuentes

P: ¿Qué es la soberanía mínima viable (MVS)?

R: La MVS es la práctica de aplicar controles de soberanía basados en las necesidades reales del negocio y en los requisitos normativos. Su objetivo es ayudar a evitar tanto el exceso de ingeniería como la falta de protección.

P: ¿Por qué es importante la clasificación de las cargas de trabajo?

R: Las diferentes cargas de trabajo conllevan distintas obligaciones normativas y operativas. Clasificar las cargas de trabajo ayuda a las organizaciones a aplicar el nivel adecuado de controles de soberanía.

P: ¿Cuáles son los tres perfiles de soberanía más comunes?

R: Los tres perfiles son: organizaciones verdaderamente soberanas, organizaciones reguladas y organizaciones híbridas multinube. Cada uno de ellos tiene requisitos operativos y de cumplimiento específicos.

P: ¿Qué riesgos conlleva un exceso de complejidad en la soberanía?

R: Un exceso de controles puede aumentar la complejidad operativa y los costes sin aportar un valor significativo en materia de cumplimiento normativo o empresarial.

P: ¿Por qué los entornos mixtos plantean retos de gobernanza?

R: Las organizaciones suelen operar en múltiples modelos de nube e infraestructura. Resulta difícil mantener controles, pruebas de auditoría y estándares de Recovery coherentes en todos los entornos.

Ruben Renders es director de soluciones para MSP en Commvault.

Puntos clave

• La residencia de los datos se refiere al lugar donde se almacenan, pero la soberanía digital también exige tener control sobre el acceso y las operaciones, además de comprender bien las implicaciones jurisdiccionales.
• La soberanía operativa suele ser la parte más débil y menos supervisada de la mayoría de los programas de soberanía.
• Una estrategia de soberanía completa se basa en cuatro pilares: la localidad de los datos, la soberanía tecnológica, la soberanía operativa y la soberanía jurisdiccional. La información…
• La soberanía no es algo binario; las organizaciones deben definir una postura que se ajuste a sus obligaciones normativas y operativas.

Aquí va una pregunta sobre la que vale la pena reflexionar: cuando tu organización tomó esa decisión sobre la soberanía, ¿qué fue exactamente lo que decidió? Para la mayoría, la respuesta es una variante de lo mismo. Elegir una región. Trasladar las cargas de trabajo. Elegir un proveedor de nube con centros de datos en el país. Marcar la casilla. Se respondió a la pregunta de dónde residen los datos y se dio por zanjado el debate sobre la soberanía.

Pero no estaba cerrado. Apenas había empezado. La residencia de datos responde a una pregunta: ¿dónde? La soberanía digital plantea tres más: ¿quién, cómo y en qué condiciones? La confusión entre residencia y soberanía es comprensible. Los hiperescaladores han hecho que la selección de la región parezca una decisión de soberanía. Las listas de verificación de cumplimiento preguntan dónde se almacenan los datos. Las directrices normativas, al menos en sus primeras versiones, se centraban en gran medida en la geografía.

Elegir una cloud soberana es algo importante: tiene su importancia, conlleva implicaciones operativas y es un primer paso necesario. Pero solo es un primer paso. Y la mayoría de las organizaciones se han quedado ahí.

Lo que «Residency» no aclara

Piénsalo de esta manera: elegir una región de nube soberana es como comprar una caja fuerte. Te indica dónde se almacenan tus objetos de valor. No dice nada sobre quién tiene una copia de la combinación, quién fabricó la caja fuerte, qué legislación rige al fabricante ni si puedes abrirla si te ves obligado a ello.

La elección de la región responde a una pregunta. Quedan otras tres totalmente sin resolver, y son precisamente estas las que los reguladores, los comités de contratación y los auditores se están planteando ahora con cada vez más precisión:

• ¿Quién puede gestionar su entorno y desde dónde? El hecho de que el personal de soporte de su proveedor de nube esté sujeto a una jurisdicción extranjera es una cuestión de soberanía que la residencia de datos no puede resolver. Una ventana de mantenimiento rutinario realizada por un ingeniero de soporte en una jurisdicción jurídica diferente es una vía de acceso que su política de residencia no cubre. Este es el ámbito de la soberanía operativa: el pilar más difícil de auditar y el que más se suele pasar por alto.
• ¿Bajo qué régimen jurídico se puede acceder a sus datos? El hecho de que un proveedor de tecnología extranjero opere su infraestructura en el país no significa que quede automáticamente fuera del ámbito de aplicación de la legislación de su país de origen. El alcance extraterritorial de los regímenes jurídicos extranjeros es un riesgo que la geografía por sí sola no puede eliminar.
• ¿Puede recuperar sus datos si algo sale mal? La mayoría de los programas de soberanía se basan en el control de acceso. Muy pocos abordan la recuperación: si sus datos pueden restaurarse correctamente, dentro de unos límites definidos, por personal que opere dentro de sus límites de soberanía. Esa laguna es donde las estrategias de soberanía suelen fallar en condiciones reales.

El marco que cubre esa carencia

Una estrategia de soberanía completa se basa en cuatro pilares interdependientes. El Informe sobre la preparación para la soberanía digital —disponible en readiverse.com— los analiza en detalle. En resumen:

• La localidad de los datos se refiere a los lugares por donde se desplazan realmente los datos y los metadatos.
• La soberanía tecnológica abarca el control sobre el cifrado, la custodia de las claves y la portabilidad de la arquitectura.
• La soberanía operativa se refiere a quién controla el entorno y desde dónde.
• La soberanía jurisdiccional establece el marco jurídico que rige y afecta a todo lo anterior.

Ningún pilar por sí solo es suficiente. Una estrategia sólida de localidad de datos con controles operativos débiles no es soberanía: es residencia con riesgos no evaluados.

Lo que hace que este marco sea útil no es su complejidad, sino las preguntas que suscita. Cuando una organización analiza por primera vez su situación actual en relación con los cuatro pilares, casi siempre descubre lagunas que no sabía que existían, no porque falten controles, sino porque nunca se habían planteado esas preguntas.

La soberanía es una escala variable

Hay algo más que merece la pena mencionar: la soberanía no es un estado binario. No existe ninguna certificación que la otorgue ni ningún modelo de implementación único que la garantice. Es una postura: un conjunto de decisiones deliberadas y auditables. Y el nivel adecuado de esa postura varía según la organización, la carga de trabajo y lo que realmente se debe a los reguladores y a los clientes.

Esa calibración es precisamente en lo que consiste la soberanía mínima viable, el tema de la segunda entrada de esta serie. La confianza en la normativa se forja mucho antes de la propia auditoría, a través de requisitos claramente definidos, no de suposiciones ligadas a la ubicación geográfica. Descarga el Informe sobre la preparación para la soberanía digital para conocer el marco de cuatro pilares y una herramienta práctica de autoevaluación.

Preguntas frecuentes

P: ¿Cuál es la diferencia entre la residencia de datos y la soberanía digital?

R: La residencia de datos se centra en el lugar donde se almacenan físicamente los datos. La soberanía digital va más allá, ya que aborda quién puede acceder a los datos, cómo se gestionan los sistemas y qué jurisdicciones pueden suponer un riesgo legal.

P: ¿Por qué la selección de una región no basta para garantizar la soberanía?

R: Elegir una cloud solo tiene que ver con la ubicación geográfica. No resuelve los problemas relacionados con el acceso operativo, la exposición a riesgos legales ni las capacidades de recuperación.

P: ¿Cuáles son los cuatro pilares de la soberanía digital?

R: Los cuatro pilares son la localidad de los datos, la soberanía tecnológica, la soberanía operativa y la soberanía jurisdiccional. Juntos, conforman lo que creemos que es un marco más completo para evaluar el grado de preparación soberana.

P: ¿Por qué es tan difícil gestionar la soberanía operativa?

R: La soberanía operativa implica controlar quién puede acceder a los sistemas, desde dónde operan y bajo qué régimen jurídico. Estos controles son más difíciles de auditar que los simples requisitos sobre la ubicación de los datos.

P: ¿Es la soberanía digital una certificación fija?

R: No. La soberanía es una postura continua basada en decisiones deliberadas y verificables que varían según la organización, la carga de trabajo y el marco normativo.

Ruben Renders es director de soluciones para MSP en Commvault.

Puntos clave

• Los ataques de vishing han aumentado drásticamente, y hay grupos organizados que están industrializando la ingeniería social para obtener acceso inicial a través de los servicios de asistencia técnica.
• Los atacantes pasan rápidamente de las cuentas de usuarios comprometidas a identidades de máquina persistentes, como los tokens OAuth y las cuentas de servicio.
• La mayoría de las organizaciones carecen de gobernanza y visibilidad sobre las identidades no humanas (NHI), lo que crea un importante punto ciego de seguridad.
• Readiness eficaz depende de la correlación de las señales de identidad y de tratar las identidades de máquina como activos de alto riesgo.
• La verdadera resiliencia requiere la capacidad de detectar y revertir los cambios no autorizados en los privilegios antes de que los atacantes logren establecerse de forma persistente.

El personal de tu servicio de asistencia técnica acaba de recibir una llamada. La persona que llamaba sabía el nombre del empleado, quién era su jefe y los cuatro últimos dígitos de su número de identificación. Solicitó un restablecimiento de contraseña. Procedimiento estándar. El técnico de TI accedió.

Esa llamada era un fraude. Y el atacante ya está dentro.

El phishing por voz —vishing— se disparó un 449 % en 2025. Los grupos de atacantes han convertido la ingeniería social en una operación escalable: reclutan a personas para realizar llamadas, redactan guiones y pagan entre 500 y 1.000 dólares por cada suplantación de identidad exitosa en el servicio de asistencia técnica. No buscan tus datos. Buscan un punto de apoyo.

Una vez dentro, los atacantes no se detienen en la cuenta de un usuario. Se mueven lateralmente: roban tokens de OAuth, crean nuevas cuentas de servicio administrativas e incorporan el acceso en credenciales del nivel de máquina que nadie supervisa. A diferencia de las contraseñas de los usuarios, esas credenciales rara vez se renuevan. No activan alertas de inicio de sesión. Pueden sobrevivir a una corrección completa del usuario original comprometido.

Para cuando tu equipo de seguridad cierre el ticket del incidente del servicio de asistencia técnica, es posible que el atacante lleve semanas actuando de forma silenciosa y persistente en tu entorno. La falta de gobernanza empeora la situación.

Menos del 25 % de las organizaciones cuentan con políticas formales para la creación o la desactivación de las NHI —las cuentas de servicio, las claves API y los tokens OAuth que ahora superan en número a los usuarios humanos en una proporción de 144 a 1—. Casi todas ellas cuentan con permisos que superan con creces lo que requiere su función.

La mayoría de las organizaciones no confían prácticamente en su capacidad para detectar un ataque dirigido a esta capa. No se trata de un fallo de prevención, sino de un fallo en la planificación de la Recovery.

Cómo se manifiesta la Readiness

La prevención en el servicio de asistencia técnica es importante —formación, verificación de devolución de llamada, confirmación fuera de banda—. Pero por sí sola no es suficiente. Los atacantes se están industrializando más rápido de lo que los programas de concienciación pueden seguirles el ritmo.

Readiness significa correlacionar las señales: una interacción con el servicio de asistencia técnica seguida inmediatamente de un restablecimiento de la autenticación multifactorial (MFA) o de la creación de un nuevo token es un indicador de alta probabilidad de compromiso.

Significa tratar las identidades de las máquinas como activos de nivel 0: regular su creación, delimitar sus permisos y supervisar cualquier escalada no autorizada. Y significa tener la capacidad de detectar y revertir rápidamente los cambios maliciosos en los privilegios, antes de que se conviertan en la nueva normalidad.

Descubre cómo la resiliencia de identidades de Commvault permite la detección rápida, la reversión y la Recovery de tu entorno de identidades.

Preguntas frecuentes

P: ¿Qué es un ataque de «vishing» en el contexto de la seguridad empresarial?

R: El vishing (phishing por voz) utiliza llamadas telefónicas para suplantar la identidad de empleados y manipular a los servicios de asistencia de TI para que concedan acceso, normalmente mediante restablecimientos de contraseñas o de la autenticación multifactorial (MFA). Se trata de una práctica cada vez más industrializada, en la que grupos organizados reclutan a personas para realizar las llamadas y utilizan guiones preescritos para maximizar las tasas de éxito.

P: ¿Por qué los atacantes se centran en las identidades de máquina tras un acceso inicial mediante vishing?

R: Las cuentas de usuarios se corrigen. Las identidades de máquina (NHI) —tokens de OAuth, cuentas de servicio, claves de API— son más persistentes y rara vez se rotan, por lo que a menudo pasan desapercibidas para la supervisión tradicional. Migrar el acceso a la capa de las máquinas permite a los atacantes mantener esa persistencia mucho después de que se haya detectado y solucionado la filtración original de las credenciales de los usuarios.

P: ¿Qué significa en la práctica la «resiliencia de la identidad»?

R: Significa que su organización puede ayudar a detectar cambios no autorizados en los privilegios casi en tiempo real y contribuir a restaurar rápidamente el entorno de identidades a un estado fiable. La detección por sí sola no es suficiente: la capacidad de revertir la actividad maliciosa y verificar que las identidades de máquina no hayan sido manipuladas (o, si lo han sido, revertirlas a un punto anterior en el que estuvieran en buen estado) es lo que distingue la Readiness de la exposición.

Vidya Shankaran es directora técnica de operaciones de Commvault.

Puntos clave

• La ingeniería social a través del servicio de asistencia técnica se ha convertido en uno de los principales puntos de entrada, ya que los ataques de «vishing» (phishing por voz) están aumentando rápidamente y provocan el robo de credenciales.
• Las identidades no humanas, como las cuentas de servicio y los tokens, son un importante punto ciego en materia de seguridad; a menudo no se gestionan y se aprovechan mucho para el movimiento lateral.
• Active Directory (AD) es un objetivo muy atractivo debido a su control centralizado y a las posibles configuraciones erróneas.
• La prevención por sí sola no basta; las organizaciones necesitan sistemas sólidos de detección y una capacidad de recuperación rápida para limitar los daños.
• Las medidas operativas inmediatas —como auditar las cuentas y relacionar la actividad del servicio de asistencia con los cambios de identidad— pueden reducir considerablemente el riesgo.

AD sigue siendo uno de los principales objetivos de los atacantes porque es el núcleo de la identidad corporativa. Estudios recientes muestran que el 67 % de los incidentes implican ahora una violación de la identidad, y que los atacantes van a por sistemas críticos como AD a las pocas horas de conseguir el acceso inicial. Una vez comprometido, la recuperación puede llevar días o semanas, lo que provoca importantes trastornos en la actividad empresarial.

La pregunta que hay que hacerse no es si AD es un objetivo. Es cómo llegan los atacantes hasta allí, y por qué el camino es mucho más corto de lo que los equipos de seguridad podrían esperar.

3 pasos para llegar a un acuerdo total

Grupos de ciberdelincuentes como ShinyHunters y Scattered Spider han convertido la ingeniería social en una operación a gran escala. El phishing por voz —vishing— se disparó un 449 % en 2025. Se recluta a personas para realizar las llamadas, se les proporciona un guion y se les paga hasta 1 000 dólares en función del éxito y la tasa de acierto.

Eso significa que basta con un solo paso para lanzar un ataque: conseguir que te restablezcan la contraseña o que cambien la autenticación multifactorial (MFA). Y ya está.

A partir de esa única credencial, el atacante se desplaza lateralmente hacia entornos en la nube y virtualizados. Recogen tokens OAuth, crean nuevas cuentas de servicio administrativas e integran el acceso en credenciales a nivel de máquina. Estas identidades no humanas —cuentas de servicio, claves API, tokens— superan ahora en número a los usuarios humanos en una proporción de 144 a 1. La expansión y la sobrecarga operativa dificultan la rotación y la auditoría. Ese movimiento lateral tiene un destino: Active Directory.

La publicidad es el objetivo

AD es el sistema nervioso central de la identidad empresarial. Si lo controlas, lo controlas todo: cuentas de usuario, políticas de grupo y acceso a todos los sistemas de la red unidos al dominio. La razón por la que resulta tan atractivo para los atacantes —y tan difícil de defender— es estructural. Cualquier usuario autenticado puede leer todo el directorio. Todos los sistemas unidos al dominio heredan la confianza de este.

Los objetos de política de grupo vinculados al nodo raíz del dominio pueden utilizarse como arma para desactivar por completo los controles de seguridad. Los protocolos heredados que se mantienen habilitados por motivos de compatibilidad con las aplicaciones proporcionan un acceso directo. La propia documentación de Microsoft afirma que «la mayoría de los ataques a la identidad aprovechan errores comunes de configuración en Active Directory». Cuando un atacante llega al AD, no tiene que forzar la entrada. La puerta suele estar abierta.

La prevención es necesaria, pero no suficiente

La estructura de seguridad estándar —autenticación multifactorial (MFA), detección de endpoints y filtrado de correo electrónico— se basa en el comportamiento humano. No se diseñó para controlar la capa de identidades de máquina ni para detectar ese tipo de escalada de privilegios lenta y aparentemente legítima que caracteriza a los ataques modernos a Active Directory. Un atacante que pase de una cuenta de usuario comprometida a una cuenta de servicio y, de ahí, a una de administrador de dominio a lo largo de 72 horas puede que nunca active ni una sola alerta.

Por eso hay que cambiar el enfoque de «primero la prevención» a «primero la recuperación». La prevención sigue siendo importante. El acceso con privilegios mínimos, la auditoría de los cambios en Active Directory, el refuerzo de las configuraciones predeterminadas y la desactivación de cuentas inactivas: todas estas medidas pueden ayudar a reducir la superficie de ataque. Pero, teniendo en cuenta que la mitad de las organizaciones ya han sufrido un ataque a Active Directory, diseñar pensando solo en la prevención es sinónimo de diseñar para fracasar.

La verdadera resiliencia de las identidades requiere la capacidad de detectar escaladas de privilegios no autorizadas casi en tiempo real, revertir los cambios maliciosos antes de que se propaguen y restaurar rápidamente el entorno de identidades a un estado conocido y de confianza —no en días o semanas, sino lo suficientemente rápido como para contener el alcance del impacto—. Eso significa tratar Active Directory y la capa de identidades no humanas como activos de Nivel 0, con la misma inversión en gobernanza y recuperación que aplicarías a cualquier otro sistema crítico para la misión.

Qué hacer ahora mismo para reforzar tu identidad

La brecha entre la situación actual de la mayoría de las organizaciones y el nivel que deben alcanzar en materia de resiliencia de identidades es real. Pero se puede cerrar. Las prioridades inmediatas son poco glamurosas y de carácter operativo:

1. Revisa qué hay en tu AD.
2. Busca las cuentas que ya no deberían existir.
3. Cambia las credenciales que lleven años sin usarse.
4. Relaciona la actividad del servicio de asistencia con los eventos de creación de tokens y cuentas.

Una consulta al servicio de asistencia técnica seguida de un restablecimiento de la autenticación multifactorial (MFA) y, a continuación, la creación de una nueva cuenta de servicio es una señal de ataque muy fiable, y se puede detectar si estás atento.

El trabajo a largo plazo es de carácter estratégico: incorpora capacidad de recuperación en tu programa de identidad para que, cuando se produzca un ataque —y normalmente es cuestión de «cuándo», no de «si»—, puedas contenerlo, revertirlo e intentar restablecer la confianza antes de que el atacante consiga afianzar su posición.

Los atacantes cuentan con que tu AD no esté regulado, que tus identidades de máquina sean invisibles y que tu plan de recuperación sea meramente teórico. Cubre una de esas brechas este trimestre. Cubre las tres y habrás cambiado radicalmente la ecuación. Descubre cómo Commvault Cloud una protección integral para Active Directory: desde la evaluación de vulnerabilidades hasta la reversión con un solo clic y la recuperación completa del bosque.

Hace poco participé junto a Vidya Shankaran en el podcast STRIVE para hablar sobre la brecha de gobernanza en las identidades no humanas. Echa un vistazo a nuestro episodio aquí. Y no te pierdas el blog de Vidya: «El punto ciego de las identidades de máquina es ahora una superficie de ataque principal».

Preguntas frecuentes

P: ¿Por qué los servicios de asistencia técnica se están convirtiendo en un riesgo importante para la seguridad? R: A menudo se confía en los servicios de asistencia técnica para restablecer contraseñas y modificar la configuración de la autenticación multifactorial (MFA), lo que los convierte en objetivos atractivos para la ingeniería social. Los atacantes se aprovechan de esta confianza para conseguir acceso inicial con muy poca resistencia. P: ¿Qué papel desempeñan las identidades no humanas en los ataques?

R: La expansión desordenada y los gastos generales operativos dificultan la rotación y la auditoría de las identidades no humanas, como las cuentas de servicio y las claves API. Los atacantes las utilizan para mantener la persistencia y moverse sin ser detectados por los sistemas. P: ¿Por qué es AD un objetivo tan crítico? R: AD controla la autenticación y el acceso en toda la red. Si los atacantes logran hacerse con el control de este sistema, pueden gestionar usuarios, políticas y sistemas a gran escala. P: ¿No bastan la autenticación multifactorial (MFA) y la seguridad de los terminales para detener estos ataques? R: Estas herramientas se centran en el comportamiento humano y es posible que no detecten una escalada de privilegios lenta y que parezca legítima. Los atacantes pueden actuar siguiendo patrones normales y evitar así que se activen las alertas. P: ¿Qué significa un enfoque de seguridad que da prioridad a la recuperación? R: Significa prepararse para la realidad de que se producirán brechas de seguridad y dar prioridad a la capacidad de detectarlas, contenerlas y revertirlas rápidamente. Este enfoque ayuda a reducir el tiempo de inactividad y puede contribuir a limitar el impacto general. P: ¿Cuáles son las medidas más importantes que hay que tomar de inmediato? R: Empieza por hacer una auditoría de tu AD, eliminando las cuentas que no necesites, renovando las credenciales antiguas y vigilando si hay patrones sospechosos en las actividades relacionadas con el servicio de asistencia técnica y la gestión de identidades. Dan Conrad es tecnólogo principal y director técnico de operaciones en Commvault.