Más allá del perímetro: implementación de la gestión de identidades y accesos (IAM) de «confianza cero» en entornos híbridos y multinube

Los entornos modernos se basan en plataformas en la nube, aplicaciones SaaS e infraestructuras híbridas, lo que hace que los límites de la red queden obsoletos. La identidad constituye el punto de control más coherente en todos los servicios, aplicaciones y entornos. 

La dispersión de identidades se produce cuando las cuentas, las credenciales y los permisos se reparten entre plataformas inconexas, lo que genera puntos ciegos y una gobernanza deficiente. 

Las identidades de las máquinas crecen más rápido que las de las personas y, a menudo, carecen de gestión del ciclo de vida, rotación y supervisión., lo que dificulta su protección de forma manual. 

Mediante la unificación de los sistemas de identidad, la aplicación de una autenticación sólida, la verificación continua de los accesos yla eliminación de la confianza implícita entre sistemas. 

Realizar un inventario de todas las identidades, consolidar las plataformas, aplicar la autenticación multifactorial (MFA), automatizar la gobernanza, segmentar el acceso y aplicar políticas de verificación continua.

Por favor, mira el vídeoaquípara ver la transcripción con marcas de tiempo

Hola a todos, bienvenidos a «Beyond the Perimeter».

Creo que el título de esta sesión es genial.

Es un título estupendo para una película, pero… en esta sesión no vamos a hablar de
nada relacionado con el cine.

Vamos a hablar de vuestro sistema de IAM y de cómo el modelo Zero Trust puede ayudaros a
proteger vuestros sistemas de IAM y hacer que vuestras redes sean más seguras.

Estos son algunos de los objetivos clave que vamos a abordar durante esta presentación.

Vamos a hablar de por qué la identidad es ahora la nueva línea de defensa.

También vamos a abordar los principios fundamentales de la gestión de identidades y accesos (IAM) del modelo «Zero Trust» que consideramos más importantes para
vuestro sistema de gestión de identidades y accesos.

Y vamos a hablar de algunas estrategias que podemos implementar para unificar, reforzar
y comprobar el acceso en vuestro sistema de gestión de identidades y accesos.

Además, al final, os presentaré una hoja de ruta que, espero, os
ofrece consejos prácticos y pasos concretos que podéis seguir para implementar el modelo «Zero Trust» en vuestro

un sistema de IAM que os ayude de verdad a dar los primeros pasos y a obtener resultados positivos desde el principio, quizá incluso la semana que viene
, cuando penséis en vuestros proyectos de «Zero Trust».

Me llamo Ron Robbins y soy director sénior de producto aquí en Commvault; trabajo en
el ámbito de la resiliencia de la identidad y me dedico a ayudar a los clientes a

a abordar los retos relacionados con la resiliencia de las identidades en sus organizaciones.

Vamos a ponernos manos a la obra.

Lo que creo que más he aprendido al preparar esta presentación,
y lo que considero más importante recordar de ella es que

La identidad es el nuevo perímetro.

Antes, nuestra seguridad solo dependía del cortafuegos, ¿verdad?

Estábamos acostumbrados a los modelos de red tradicionales en los que

instalábamos cortafuegos, configurábamos VPN y dábamos por hecho que nuestra red o nuestro centro
de datos estaban protegidos por esos cortafuegos y VPN.

Ya no es así.

Ya sabes, hemos añadido nuevas cargas de trabajo y nuevas aplicaciones SaaS.

Hemos incorporado nuevas plataformas en la nube a nuestro entorno.

Y, tal y como dijo John Hawley en un artículo de la revista CSO Magazine de 2012, nuestros centros de datos
se están fragmentando cada vez más.

Se están saliendo del cómodo perímetro de seguridad de los cortafuegos y las VPN, lo cual me
Parece una imagen estupenda para reflexionar y pensar en la situación en la que nos encontramos.

en la que nos encontramos hoy en día, en la que ya no contamos con esa red tradicional en las instalaciones, donde estamos
protegidos por un cortafuegos y una VPN.

Pero hemos ido mucho más allá de eso.

Por ejemplo, la mayoría de nosotros nos encontramos en esta situación híbrida en la que contamos con una solución local

y también utilizamos muchas plataformas en la nube.

Eh… Nuestras implementaciones de mensajería instantánea se enfrentan a un verdadero reto por ello, y Geoff Cairns lo menciona en un
artículo que escribió para dar a conocer el informe «Forrester Wave™».

Afirma que las aplicaciones actuales de mensajería instantánea se caracterizan por la proliferación de identidades y la existencia de múltiples cuentas de usuario
y las credenciales repartidas por sistemas aislados, lo que da lugar a una mala gestión de las identidades

consecuencia.

Y, la verdad, es algo que tenemos que controlar y que no deja de
crecer día a día.

Además, si añadimos a la ecuación el problema de la IA genética, se observa esta explosión
de lo que denominamos «identidad no humana» o NHI.

CyberArk, en un estudio de panorama realizado en 2025, descubrió que las identidades de máquina de sus clientes, según la encuesta que les
se dio cuenta de que,

Superan en número a las identidades humanas en una proporción asombrosa de 82 a uno, lo cual es alucinante si
lo pensamos bien.

El número de agentes que utilizan esas identidades y el número de cuentas de servicio que las utilizan
.

Antes teníamos la idea de una red en la que cada persona tenía una identidad.

Y solíamos gestionar solo ese pequeño número de identidades.

Ahora tenemos miles y miles de cuentas de servicio que tenemos que
gestionar

con nombres como «cuenta de servicio 01», «cuenta de servicio 02», y eso se convierte en un problema realmente enorme
Para nosotros: un problema realmente enorme gestionar esa explosión de identidades y mantener

la higiene en todo ese entorno.

Así que ahora más que nunca, creo de verdad que necesitamos algún tipo de estrategia de «confianza cero» para
nuestro entorno de IAM.

Pues bien, veamos con un poco más de detalle en qué consiste
El reto de los entornos híbridos y multicloud.

Me pregunto: ¿cuántos de vosotros tenéis una estrategia multinube?

Si solo utilizáis AWS, es posible que las noticias recientes os hayan demostrado que una estrategia
La multi-nube es algo que quizá deberíais adoptar, en la que es necesario tener aplicaciones ubicadas

en múltiples plataformas, en múltiples nubes, o al menos disponer de conmutación por error entre
nubes, si es posible.

Por eso hemos incorporado estas plataformas en la nube a nuestra organización para garantizar la resiliencia.

Y entonces descubrimos que cada una de estas plataformas en la nube que teníamos que incorporar a la organización
cuenta con sus propios sistemas de IAM.

Y cada uno de esos sistemas de IAM tiene su propio lenguaje.

Por ejemplo, si nos fijamos en Active Directory y queremos añadir un rol,
El proceso es totalmente diferente al de añadir un rol en AWS IAM.

Quiero decir, hay algunos conceptos que son parecidos, ¿no?

Pero el lenguaje y el proceso que se sigue en Active Directory y el que se sigue en
AWS IAM

son dos cosas totalmente diferentes.

Quiero decir que AWS IAM se parece más a un lenguaje de scripting para acceder a
un rol o añadirle uno a Active Directory.

Y, por eso, cuando vas más allá de la interfaz de usuario, resulta mucho más complejo y carece de coherencia
entre los distintos sistemas de IAM.

Y eso nos plantea un problema considerable cuando queremos hacer cumplir ciertas normas y aplicar
políticas coherentes en todas las plataformas y aplicaciones.

Además, las fusiones y adquisiciones agravan el problema.

Así que constantemente se producen fusiones y adquisiciones o surgen nuevas empresas que se incorporan a nuestra
de la organización y que pueden tener sus propias cuentas, así como

cuentas que tenemos que gestionar.

Y pueden acarrear problemas de «higiene de identidades» que ni siquiera habíamos tenido en cuenta
antes.

Yo solía trabajar para una organización y, por cierto, no voy a mencionar nombres para
proteger a los culpables.

Pero solía trabajar para una organización que tenía mucha actividad en el ámbito de las fusiones y adquisiciones.

Nos sometimos a una auditoría de «confianza cero» y descubrimos que había muchas cuentas en la nube
que simplemente no se gestionaban, de las que no teníamos constancia debido a su número

de las adquisiciones que se habían producido durante el último año.

Descubrimos que teníamos 12 cuentas en la nube de las que ni siquiera sabíamos que existían.

Y dentro de cada una de esas 12 cuentas en la nube, teníamos cuentas de administrador exclusivas

a un único usuario.

Así pues, un solo usuario podía tener 12 cuentas de administrador diferentes repartidas por todas estas 12
plataformas en la nube.

Esto nos planteó un problema considerable.

Además, cuando estos usuarios se marchaban, se creaban muchas cuentas abandonadas.

Así que había cuentas de administrador huérfanas, algo que realmente no quieres tener en
tu organización.

Así pues, la gestión de identidades se convierte en un problema considerable cuando empiezas a tener en cuenta

el número de plataformas en la nube que se suman a la ecuación, y el número de aplicaciones SaaS
que se incorporan a la ecuación.

Por eso, ahora más que nunca, necesitamos algún tipo de estrategia en torno a nuestros sistemas de identidad.

Y creo que hay ciertos principios del modelo «Zero Trust» que podemos aplicar a nuestros sistemas de IAM
para que todo sea más seguro.

El primero es «nunca confíes y comprueba siempre».

Cada usuario, cada dispositivo,

Cada elemento que acceda a tu red debe demostrar quién es.

Debes asegurarte de que demuestre su identidad y de que sea un elemento
de confianza que pueda acceder y realizar funciones en tu red.

Además, hay que aplicar este concepto de «privilegio mínimo» a las identidades.

Por lo tanto, a los usuarios solo se les debe conceder el acceso necesario para realizar una tarea o sus funciones laborales, y
nada más.

Por lo tanto, si tienen acceso a algo más que quede fuera de sus funciones laborales,

se trata de una cuenta con privilegios excesivos.

Imagina lo que podría pasar si un atacante se hiciera con esa cuenta y pudiera iniciar sesión
y llevar a cabo acciones que no debería realizar en tu organización.

Además, necesitas una autenticación sólida y una autenticación multifactorial (MFA) en todas partes si aún no las tienes.

La autenticación consta de tres elementos.

Consiste en algo que sabes, algo que tienes y algo que eres.

Por eso es importante que la autenticación fuerte incluya esos tres elementos o, al menos
, dos de ellos si no puedes implementar los tres en este momento en tu red.

Es muy importante.

Las decisiones de acceso deben basarse en el contexto y la postura de seguridad.

¿Qué significa esto?

Supongamos que tenemos a una persona que se conecta a la red con un ordenador portátil y que
Ha iniciado sesión en algún lugar de la zona de Nueva Jersey.

Y entonces empieza a hacer cosas en la red y, de repente, cinco minutos después,

la dirección IP de su ordenador cambia a otra que quizá se encuentre
en California, y empieza a llevar a cabo acciones en la red desde allí.

Pues bien, es imposible que esa persona haya cruzado el país en cinco
minutos.

Es un viaje imposible.

Y es algo que, si lo detectas en esa sesión, te llevaría a querer cerrarla
o solicitar una nueva autenticación para asegurarte de que sigues siendo la misma persona

que dijo ser al autenticarse.

Por eso, comprobar el estado del dispositivo

y el contexto es extremadamente importante.

Y, además, la verificación continua va de la mano de ello.

Asegurarse de que la persona a la que has autenticado una vez siga demostrando ser de confianza
a lo largo de toda la sesión.

Así que, si empieza a mostrar comportamientos de riesgo, si empieza a acceder a cuentas para las que no
tiene permiso, si empieza a borrar datos o a realizar acciones destructivas, debes

volver a verificarla o

que se cierre la sesión si se trata de algo que suponga un riesgo.

Otra gran ventaja del modelo «zero trust» es que siempre debes dar por hecho que se ha producido una brecha de seguridad o tener esa
esa mentalidad de «brecha asumida», ¿no?

Debes diseñar tu red como si ya hubiera actores malintencionados en ella.

Y creo que sería un ejercicio que supondría un reto, o quizá divertido para algunos de vosotros
Para los que os gusta jugar a los investigadores, lo mejor sería salir ahí fuera y dar por hecho que alguien ya ha violado

vuestra red todos los días.

Salid a auditar sesiones, salid a observar las acciones de los usuarios, salid a

Averiguad si alguien está realizando alguna actividad maliciosa en vuestra red cada día e intentad pillarlo
a los atacantes mientras están en ello.

Si siempre das por hecho que hay una intrusión, siempre serás precavido, siempre tomarás
toma las precauciones necesarias y supervisa siempre lo que ocurre en tu red

y en tus sistemas de identidad.

Entonces, ¿qué estrategias podemos utilizar para poner en práctica algunas de estas políticas de «confianza cero»?

Bueno, lo primero que creo que podemos hacer es unificar la identidad, la autenticación y
el acceso.

¿Y a qué me refiero con eso?

Bueno, eh…

con todas estas plataformas en la nube, con todas estas aplicaciones SaaS que hemos implementado,
tenemos estos silos de identidad.

Me gusta llamarlas «islas de identidad», simplemente esas islas de identidad que existen ahí fuera.

Y lo más sencillo que podemos hacer para tenerlas todas bajo control es romper esos compartimentos estancos o
eliminar las barreras entre todas esas «islas de identidad» y unificarlas.

Establece una única fuente de verdad para tu identidad.

A veces, en la mayoría de las organizaciones, esa fuente puede ser el sistema de RR. HH., cuando las
personas se incorporan e introducen sus datos en dicho sistema.

Esa podría ser la única fuente de verdad y podría ser el lugar desde donde se crean las cuentas.

También podría ser un sistema de identidad como servicio, como, por ejemplo, Entra AD, Ping u Octa
, algo por el estilo.

La clave aquí es reducirlo a una única identidad por usuario.

Es mucho más fácil gestionar a los usuarios y sus identidades si se dispone de una única identidad por usuario.

Además, resulta más sencillo federar esa identidad en múltiples sistemas y
servicios si se dispone de una identidad por usuario.

Y ese es el siguiente paso.

Lo que hay que hacer es federar esa identidad.

Tengo un buen ejemplo de una organización en la que trabajé anteriormente.

Te prometo que no será la misma organización, pero, de nuevo, se trata de una organización anónima.

Pero implementamos un servicio FTP.

Ese servicio FTP no se podía federar

con nuestra estrategia habitual de federación.

Por eso, tenía su propio almacén de identidades.

Además, contaba con su propio sistema de autenticación multifactorial (MFA).

En aquel momento no se nos daba muy bien establecer la relación entre nuestro entorno
corporativo y nuestro entorno en la nube.

Así que una persona que quisiera acceder a este servicio FTP en la nube tenía que iniciar sesión primero en la
VPN corporativa mediante una cuenta de usuario y una contraseña, y a continuación superar una verificación de autenticación multifactorial (MFA).

A continuación, tenía que iniciar sesión en nuestra plataforma en la nube

utilizando una cuenta de usuario corporativa, un nombre de usuario y una contraseña, además de superar una verificación MFA.

A continuación, tenía que iniciar sesión en el servicio FTP utilizando un nombre de usuario, una contraseña y una
verificación MFA.

Y es que todos esos elementos tenían el mismo nombre.

Así que, cada vez que llamaban al servicio de asistencia técnica y tenían un problema con su identidad o con
una de sus cuentas de autenticación multifactorial, pero no podíamos saber cuál era.

Básicamente,

teníamos que adivinar y averiguar con qué tenían problemas, y ellos no eran capaces de
explicarnos con claridad cuál era.

Así que a veces se resolvían sus problemas y otras no, y la verdad es que no
No teníamos ni idea de dónde estaban los problemas de identidad en ese sistema concreto.

Por eso es muy importante conseguir de alguna manera esa identidad única para cada usuario.

Además, disponer de una identidad única facilita mucho la unificación de las políticas y los modelos de acceso basados en roles en
todas las plataformas.

Y, además, cuando se trata de automatizar el aprovisionamiento, el ciclo de vida y la gobernanza de los
usuarios, resulta mucho, mucho más fácil con una identidad única y un panorama de identidades consolidado.

Hablemos ahora del refuerzo de la seguridad del acceso privilegiado.

Esto también es muy importante.

Una de las cosas que hay que hacer es considerar a los administradores como identidades
de mayor riesgo de la organización.

Son las cuentas más peligrosas y las más

más solicitadas en caso de una filtración.

Son las más valiosas para los delanteros, ¿verdad?

Ningún miembro de tu organización debería tener permisos elevados en todo momento.

Ningún administrador debería tener permisos elevados en todo momento.

Simplemente no los necesitan.

No los necesitan para navegar por Internet ni para leer las noticias sobre lo que ocurre en el mundo.

Hay que aplicar algún tipo de ampliación de privilegios «justo a tiempo»

en la que los administradores solo dispongan de cuentas con privilegios elevados durante el tiempo que necesiten para
realizar la acción que deseen llevar a cabo.

Si se combina esto con el principio de «confianza cero», se obtendrá una
una cuenta de administrador a la que solo tendrá acceso durante el tiempo necesario para realizar las tareas que le corresponden.

Y solo tendrá acceso para realizar esa función específica a la que la hayamos limitado
.

De este modo, tus cuentas de administrador serán mucho más seguras.

También deberías crear algún tipo de cuentas de emergencia supervisadas.

Tengo una historia estupenda sobre esto.

Me pregunto, pregúntate a ti mismo: ¿cuántos de vosotros tenéis a un Bob en vuestro entorno?

Ya sabéis a qué tipo de persona me refiero, ya conocéis a Bob.

Bob es ese tipo que es la única persona que puede acceder a ese servidor polvoriento que está
guardado en un viejo armario de cableado en algún lugar de las instalaciones de vuestra organización

y es el único que puede iniciar sesión en él.

Y si Bob se marchara alguna vez de la organización o si, Dios no lo quiera, llegara a fallecer, perderíais
el acceso a ese servidor.

Ya no podréis iniciar sesión en él.

Ya no podríais hacer copias de seguridad ni restauraciones.

Ya no podríais actualizarlo.

Y Bob lo sabe, y Bob sabe que es muy valioso.

Por eso, debes asegurarte de alejar a los «Bob» de tu entorno.

Quieres disponer de cuentas de emergencia que puedas activar, a las que puedas recurrir cuando
sea necesario, en caso de que ocurra lo impensable, en caso de que se produzca un desastre, y cuentas que estén

supervisadas y controladas, cuentas a las que puedas acceder y de las que puedas salir para realizar
las acciones de mayor nivel, como, por ejemplo, el acceso de root en una cuenta en la nube de la que seas propietario.

Otro aspecto importante para restringir el acceso a los privilegios es exigir una doble aprobación para las acciones de alto
impacto.

¿A qué me refiero con esto?

Supongamos que tienes un administrador que necesita iniciar sesión y modificar 50 cuentas.

Normalmente nunca lo hace, pero, ya sabes, se trata de una acción de gran repercusión.

Sería una medida muy perjudicial si supervisara a 50, ya sabes, si gestionara a 50
asuntos a la vez y llevar a cabo un cambio que tuviera un gran impacto en tu organización.

Lo ideal es disponer de algún tipo de mecanismo que exija una doble autenticación o
una doble aprobación para esa acción concreta, de modo que, cuando Bob realice ese cambio,

tenga que obtener la autorización de otra persona; quizá alguien de un nivel jerárquico superior en la organización
también tenga que aprobar esa medida.

Y eso es muy importante.

Si alguien con malas intenciones se hiciera con la cuenta de Bob o con la de cualquier otra persona —oye, solo
Voy a poner a Bob como ejemplo, necesitaría tener una segunda cuenta para poder llevar a cabo esas

acciones destructivas o de gran impacto.

Y además, en cada sesión con privilegios, en cada sesión de administrador, hay que asegurarse de que todas
ellas queden registradas.

Asegúrate de que todas ellas sean supervisadas y auditadas.

Y luego, haz saber a tu personal que se auditan y se graban.

Me parece que los administradores son mucho más cuidadosos si saben que sus acciones están siendo vigiladas.

Tienen mucho más cuidado de no cometer errores y de no incurrir en
comportamientos indebidos si saben que sus sesiones están siendo

supervisadas y auditadas.

Así que creo que esas son medidas importantes para reforzar la seguridad del acceso con privilegios.

Añadamos ahora la verificación continua.

La verificación continua es algo parecido al modelo «zero trust», pero se trata de un «zero trust» en tiempo real.

Lo que hacemos es validar continuamente a los usuarios y comprobar si tienen o no acceso
para hacer lo que necesitan hacer.

Ya sabes, es muy importante recordar que el hecho de que nos identifiquemos
El hecho de que un usuario acceda por primera vez no significa que sea de fiar durante todo el tiempo que permanezca

en línea o mientras dure su sesión.

Los tokens de sesión

pueden ser robados y las sesiones pueden ser secuestradas; además, los atacantes pueden hacerse con el control y llevar a cabo acciones
peligrosas.

Por eso es importante comprobar constantemente lo que el usuario está haciendo durante su sesión y analizar
el estado del dispositivo.

Si el dispositivo que accede a la sesión es un dispositivo de la empresa o si se trata de un
un dispositivo personal que podría introducir malware en tu

rojo, es muy importante hacer un seguimiento.

Es necesario disponer de algún tipo de autenticación reforzada para las acciones que entrañan riesgo.

Así pues, si alguien accede y quiere elevar sus permisos o crear una
cuenta de administrador, debería exigirse algún tipo de autenticación reforzada.

Un buen ejemplo de esto es cuando inicias sesión en tu banco; por ejemplo, cuando accedes a
Inicia sesión con tu nombre de usuario y contraseña y, posiblemente, con la autenticación multifactorial (MFA) si te encuentras en un

Es un buen banco, y solo vas a consultar tu cuenta o a ver tus movimientos

, pero de repente quieres transferir una gran suma de dinero a otra cuenta, algo que nunca sueles
hacer.

El banco podría pedirte una autenticación multifactorial (MFA) adicional o enviarte un correo electrónico diciéndote: «Oye,
«Introduce el código que te acabamos de enviar por correo electrónico para que puedas confirmar esta transacción».

Ese es un ejemplo de autenticación reforzada.

Y es algo fácil de poner en práctica en tu organización y fácil de aplicar a
las acciones de riesgo.

Debes supervisar las sesiones para detectar posibles anomalías.

Asegúrate de que, si se produce alguna anomalía durante una sesión, se vuelva a realizar la autenticación.
al usuario.

Así que, si un usuario no suele acceder a datos financieros en SharePoint y empieza a hacerlo
Si no puedes acceder a ellos, quizá sea el momento de volver a autenticarte o de revisar eso

sesión y asegurarte de que sigue siendo válida para el usuario.

Además, debe ajustar el nivel de riesgo de forma dinámica en función del riesgo

o dependiendo de lo que estés haciendo.

Por ejemplo, hemos hablado de, eh, viajes imposibles.

Bueno, supongamos, por ejemplo, que alguien, durante su sesión, empieza a realizar acciones de riesgo a las 2
de la madrugada

de la madrugada, cuando su horario laboral habitual es de nueve a cinco.

Pues bien, quizá quieras asegurarte de que la sesión de esa persona no haya sido secuestrada o
de que su token no ha sido robado y reutilizado en otro lugar por alguien en el extranjero o por alguien

que, eh, esté intentando hacer cosas malas dentro de tu red.

Necesitas detectar, o disponer de un método o una forma de detectar e interrumpir las sesiones
toma medidas de inmediato en cuanto detectes que existe un riesgo o que hay

actores malintencionados implicados.

Bien, ahora que ya hemos dejado clara la estrategia, hablemos de algunas medidas
prácticas que podrías poner en marcha de inmediato en tu organización para implementar el modelo «zero trust» en tus sistemas de IAM.

Sé que esto no se va a aplicar a todas y cada una de las organizaciones.

He intentado que esto sea general y práctico.

Pero estas son algunas cuestiones sobre las que podéis reflexionar y espero que os den ideas sobre cómo
podéis tener éxito en vuestra organización e implementar algunas de las políticas de «zero trust» en vuestra

organización.

Así pues, durante los primeros 30 días, creo que algunas de las mejores medidas en las que centrarse son, por ejemplo, implementar la autenticación multifactorial (MFA)
) en todos los ámbitos.

Si aún no disponéis de la autenticación multifactorial (MFA), esta es una medida que da resultados muy rápidamente.

Si puedes implantar un sistema de autenticación multifactorial en tu organización, algo que requiera un
código a los usuarios, o si ya tienes la autenticación multifactorial en todos los ámbitos, quizá sea el momento de

quieras dar el salto a una autenticación de dos factores (MFA) resistente al phishing, como la basada en el estándar FIDO2 o algo
similar.

Eso también es algo estupendo que supone un logro fácil de conseguir en tu organización y que
hace que tus cuentas sean mucho más seguras.

Empieza también a identificar tus «silos» de identidad.

Averigua dónde se encuentran todas tus identidades, en qué «islas» están ubicadas, dónde
¿Dónde están tus aplicaciones en la nube?, ¿qué plataformas en la nube utilizas y qué silos de identidad hay?

dentro de ellas.

Intenta averiguar dónde está todo y haz un análisis muy exhaustivo.

A continuación, debes bloquear tus cuentas de administrador y tus cuentas de servicio.

Esto es algo que se puede hacer desde el primer día.

Haz que sean más seguras, como sea, aunque sea solo un poco.

Ya sabes, empieza con pequeños pasos para que esas cuentas de administrador sean más seguras y no permitas
que alguien tenga privilegios en todo momento para actuar dentro de tu organización.

Durante los primeros 30 días, es importante lograr avances.

Es importante justificar

Por qué es importante este proyecto de «Zero Trust».

Durante los próximos 90 días, dedícate a crear coherencia.

Pon en marcha tu plan de consolidación de identidades.

Empieza a llevar a cabo el proceso de consolidación de las identidades.

Combina todas tus «islas de identidad», une tus silos.

Asegúrate de que haya una sola identidad por persona.

Define cómo será tu marco normativo.

Aunque todavía no lo pongas en práctica, es importante empezar a definirlo, junto con la gestión del
ciclo de vida.

¿Cómo va a ser tu proceso de ciclo de vida?

¿Cómo se incorporan los usuarios a tu organización?

¿Cómo se dan de baja?

¿Cómo gestionas las bajas que se producen en tu organización?

¿Cómo se eliminan sus cuentas?

Es importante definirlo desde el principio para que, a medida que la organización madure, puedas poner en práctica
la automatización.

Además, se encarga de la gestión de la seguridad de los dispositivos.

Si aún no lo tienes, es importante que revises tus dispositivos y te asegures de
que sean fiables, así como de que las personas que los utilizan

dispongan de dispositivos fiables, que quizá tengan una imagen corporativa o cumplan con un
estándar establecido por la empresa, y marcar esos dispositivos como de riesgo si no cumplen

dicho estándar.

Y, a continuación, crea esas cuentas de tipo «interrupción».

No queremos que Bob muera, no queremos que Bob abandone la organización y no queremos
perder el acceso a ese servidor que está en el armario polvoriento al que solo Bob tiene acceso.

Así que asegúrate de crear esas cuentas de clase «break» lo antes posible.

Y, a continuación, trabajad para alcanzar la madurez a largo plazo.

Amplía tu consolidación.

Asegúrate de llegar a esa única fuente de verdad, ya sea el sistema ER o cualquier otro tipo
de sistema IDAS.

Pasa a un método de autenticación más avanzado.

En tu caso, podría tratarse de una autenticación sin contraseña basada en algo como FIDO2.

Me encanta la autenticación.

Podría hablar durante 30 minutos solo de eso.

Pero la autenticación sin contraseña es algo que tus usuarios disfrutarán de verdad y que
, en mi opinión, te da mucha más seguridad.

Las contraseñas, sencillamente, no son un método seguro para autenticar al usuario.

Asegúrate de incluir la supervisión del comportamiento en tu proceso de verificación o en tu verificación continua.
.

Como ya he mencionado, comportamientos como conectarse a la red a las 2 de la madrugada,

cuando normalmente trabajas de 9 a 5.

Este es un ejemplo de supervisión del comportamiento que puedes incorporar a tus sesiones y que te aporta
mayor seguridad.

Incorpora la automatización a la gestión de tu ciclo de vida y al

ciclo de vida de la identidad.

De este modo, cuando un usuario se incorpora a la organización, se le concede de inmediato el acceso que necesita.

Y cuando abandona la organización, pierde por completo el acceso que tenía, de
modo que puedes asegurarte de que no haya cuentas huérfanas y de que puedas proteger tu

red.

A continuación, implementa tus políticas en forma de código para garantizar una aplicación coherente.

Trate sus políticas como si fueran código.

Disponga de un repositorio de políticas, por así decirlo.

Asegúrate de comprobar tus políticas de vez en cuando.

Asegúrate de que tus políticas cuenten con control de versiones y de que se traten como si fueran
código, registrándolas y extrayéndolas cuando se modifiquen.

Espero que esto te haya proporcionado suficiente información para saber cómo implementar una política de confianza
eliminar las vulnerabilidades de tus sistemas de IAM y conseguir que tu red sea realmente más segura.

Hay un par de cosas que quiero que recordéis de esta sesión.

Quiero que recordéis que es importante mejorar vuestra «higiene de identidades».

Las identidades se están multiplicando,

las identidades en el Nuevo Perímetro, y asegúrate de contar con un plan que introduzca
algunas mejoras, ya sea mediante la consolidación, la eliminación de esos silos y esas

o simplemente aplicando políticas y prácticas coherentes en toda vuestra
organización.

Intentad siempre implementar algo que os dé ventaja, por si acaso alguien con malas intenciones
se haga con una de vuestras identidades.

Y algo que es realmente importante recordar de toda esta presentación es que

La confianza no es algo que se conceda una sola vez cuando el usuario se autentica.

Es algo que debe comprobarse continuamente a través de sus acciones y
de, ya sabes, lo que hacen en tu organización.

Por lo tanto, debe ser algo que se supervise de forma continua.

Espero que esto te haya resultado útil.

Si hay algunos pasos siguientes que os pueda recomendar, un par de ellos serían
ver un podcast bajo demanda.

Tenemos un podcast o un webcast que trata sobre la resiliencia de la identidad en Active Directory.

Es un webcast estupendo y te recomiendo que lo veas.

Además, puedes informarte sobre la ciberresiliencia y cómo Commvault te ayuda en este sentido
Participa inscribiéndote en un taller de ciberresiliencia o realizando una

«Readiness», y los enlaces para acceder a ellos aparecen en la pantalla.

Quiero daros las gracias de todo corazón por el tiempo que me habéis dedicado hoy y por vuestra
Atención.

Espero de verdad que esto os ayude en vuestro camino hacia el modelo «zero trust» para vuestros sistemas de mensajería instantánea
en el futuro.

Muchísimas gracias por su participación hoy y muchas gracias por haber asistido.