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 ofrece el punto de control más coherente en todos los servicios, aplicaciones y entornos. 

La proliferación de identidades se produce cuando las cuentas, las credenciales y los permisos se distribuyen entre plataformas desconectadas entre sí, lo que genera puntos ciegos y una gobernanza deficiente. 

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

Unificando los sistemas de identidad, imponiendo una autenticación sólida, verificando continuamente el acceso y eliminando 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ídeo aquí para consultar 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 a hacer que vuestras redes sean más seguras.

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

Vamos a hablar de por qué la identidad es ahora el nuevo perímetro de seguridad.

También vamos a abordar los principios fundamentales de IAM de «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 verificar 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
proporcione consejos prácticos y pasos concretos que podáis seguir para implementar el modelo «Zero Trust» en vuestro

sistema de IAM y que os ayude realmente a dar los primeros pasos y a lograr algunos éxitos iniciales, quizá incluso la semana que viene
, mientras 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 área de resiliencia de la identidad y me dedico a ayudar a los clientes

a resolver los retos de resiliencia de la identidad 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 existía en el 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 desbordando más allá 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 todos

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 nos hemos extendido 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 anunciar el informe «Forrester Wave™».

Afirma que las implementaciones actuales de mensajería instantánea se caracterizan por la proliferación de identidades, la existencia de múltiples cuentas de usuario
y credenciales repartidas por sistemas aislados, y que el resultado es 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 que recopilaron de sus
clientes

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 emplean
.

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

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

Ahora, en cambio, tenemos miles y miles de cuentas de servicio que debemos
gestionar

con nombres como «cuenta de servicio 01», «cuenta de servicio 02», y esto 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.

Así que definamos un poco más 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 quizá debáis adoptar una estrategia
multinube, en la que es necesario tener aplicaciones ubicadas

en múltiples plataformas, en múltiples nubes, o al menos contar con una conmutación por error entre
nubes, si fuera posible.

Así que incorporamos 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 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 similares, ¿verdad?

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 scripts para acceder a un rol o añadir uno que a
Active Directory.

Y, por eso, cuando vas más allá de la interfaz de usuario, resulta mucho más complejo y no es coherente
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 tenemos fusiones y adquisiciones o nuevas empresas que se incorporan a nuestra
organización y que pueden tener sus propias cuentas y sus propias

cuentas que tenemos que gestionar.

Y pueden traer consigo 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 al número

de 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 que eran 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 huérfanas.

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

la cantidad de plataformas en la nube que se incorporan a la ecuación, así como la cantidad de aplicaciones SaaS
que se añaden 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 verifica siempre».

Cada usuario, cada dispositivo,

cada elemento que acceda a tu red, debes asegurarte de que demuestre 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.

Así pues, a los usuarios solo se les debe conceder el acceso suficiente 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 realizar acciones que no debería hacer 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 en este momento no puedes aplicar los tres 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 accede a la red, tiene un portátil y ha
iniciado sesión en algún lugar de la zona de Nueva Jersey.

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

la dirección IP de su ordenador cambia a una que quizá se encuentre
en California, y empieza a realizar acciones en la red desde California.

Pues bien, es imposible que esa persona haya cruzado todo 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 a solicitar una nueva autenticación para asegurarte de que sigue siendo la 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
mentalidad de «brecha asumida», ¿verdad?

Debes diseñar tu red como si ya hubiera actores maliciosos en su interior.

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

vuestra red cada día.

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

averiguar si alguien está haciendo algo malicioso en vuestra red cada día e intentar pillar
a los actores maliciosos mientras lo están haciendo.

Si siempre das por hecho que hay una intrusión, siempre serás cauteloso, siempre tomarás
precauciones y siempre supervisarás lo que ocurre en tu red

y en tus sistemas de identidad.

Entonces, ¿qué estrategias podemos utilizar para implementar 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 los silos o
las barreras entre todas estas «islas de identidad» y unificarlas.

Establece una única fuente de verdad para tu identidad.

A veces, en la mayoría de las organizaciones, eso puede ser un 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 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, es más sencillo federar esa identidad a través de 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 anterior en la que trabajé.

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 de federación habitual.

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

También contaba con su propio componente de autenticación multifactorial (MFA).

En aquel momento no se nos daba muy bien establecer la federació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 utilizando una cuenta de usuario y un nombre de usuario, y luego 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.

Y, 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, no podíamos saber de cuál se trataba.

Básicamente,

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

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

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

Además, disponer de una identidad única facilita enormemente 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 del 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 tratar a los administradores como las 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 brecha de seguridad.

Son las más valiosas para los atacantes, ¿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 imponer algún tipo de elevació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 esto se combina con el principio de «confianza cero», se obtendrá una
cuenta de administrador que solo tendrá acceso durante un periodo de tiempo para hacer lo que tenga que hacer.

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

De este modo, las cuentas de administrador resultan mucho más seguras.

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

Tengo una historia estupenda al respecto.

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 fuera 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íais 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 eliminar a personas como 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 gran
impacto.

¿A qué me refiero con esto?

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

Normalmente nunca hace eso, pero, ya sabes, es una acción de gran impacto.

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

Lo ideal es contar con algún tipo de mecanismo que exija una doble autenticación o
una doble aprobación para esa acción específica, de modo que, cuando Bob realice ese cambio,

tenga que obtener la aprobación de otra persona; tal vez alguien de un nivel jerárquico superior en la organización
también tendría que aprobar esa acción.

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
estoy poniendo a Bob como ejemplo—, necesitaría disponer de una segunda cuenta para poder llevar a cabo esas

acciones destructivas o de gran impacto.

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

Asegúrate de que todas ellas se supervisen y se auditen.

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 el acceso con privilegios.

Añadamos ahora la verificación continua.

La verificación continua es algo parecido al modelo «zero trust», pero es 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 autentiquemos
a un usuario por primera vez no significa que sea de confianza durante todo el tiempo que esté

en línea o durante toda la 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 validar continuamente 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 corporativo o si se trata de un
dispositivo personal que podría introducir malware en tu

red, es muy importante llevar un control de ello.

Es necesario contar con algún tipo de autenticación reforzada para las acciones de 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 entras en
la página de tu banco e inicias sesión con tu nombre de usuario y contraseña, y posiblemente con autenticación multifactorial (MFA) si estás en un

buen banco, y vas simplemente a consultar tu cuenta o a ver tus transacciones,

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

El banco podría solicitarte una autenticación multifactorial (MFA) adicional o enviarte un correo electrónico diciéndote: «Oye,
introduce el código que acabamos de enviarte 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 implementar en tu organización y fácil de aplicar a
las acciones de riesgo.

Debes supervisar las sesiones en busca de anomalías.

Asegúrate de que, si se produce alguna anomalía en una sesión, se vuelva a autenticar
al usuario.

Así que, si un usuario no suele acceder a datos financieros en SharePoint y empieza a hacerlo
o a solicitar acceso a ellos, quizá sea el momento de volver a autenticarlo o examinar esa

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 en función de lo que esté 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 ha 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 llevar a cabo acciones maliciosas dentro de tu red.

Necesitas detectar, o disponer de un método o una forma de detectar y cortar las sesiones
comprometidas 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 puedes reflexionar y espero que te den ideas sobre cómo
puedes tener éxito en tu organización e implementar algunas de las políticas de «zero trust» en tu

organización.

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

Si aún no contáis con 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 solicite a los usuarios un
código, o si ya dispones de autenticación multifactorial en todos los ámbitos, quizá sea el momento de

dar el salto a una autenticación multifactorial resistente al phishing, como el estándar FIDO2 o algo
similar.

Eso también es una idea estupenda, una medida fácil de implementar en tu organización y que
hace que tus cuentas sean mucho más seguras.

Empieza también a identificar tus silos de identidad.

Determina dónde se encuentran todas tus identidades, en qué «islas» están ubicadas, dónde
están tus aplicaciones en la nube, qué plataformas en la nube utilizas y qué silos de identidades se encuentran

dentro de ellas.

Intenta averiguar dónde está todo y realiza 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, sea como sea, aunque sea de forma mínima.

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

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

Es importante justificar

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

Durante los siguientes 90 días, trabaja en crear coherencia.

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

Empieza a llevar a cabo la consolidación de identidades.

Combina todas tus «islas de identidad» y tus silos.

Asegúrate de que puedas llegar a una 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 definir todo esto desde el principio para que, a medida que la organización madure, puedas implementar
la automatización.

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

Si aún no lo tienes, es importante examinar tus dispositivos y asegurarte 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 determinado de la empresa, y marcar esos dispositivos como de riesgo si no cumplen

dicho estándar.

Y, a continuación, establece esas cuentas de tipo de interrupción.

No queremos que Bob fallezca, 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 algún tipo
de sistema IDAS.

Pasa a una forma más avanzada de autenticación.

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 aporta 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 acceder a la red a las 2 de la madrugada

cuando normalmente trabajas de 9 a 5.

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

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

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, aplica tus políticas como código para garantizar una aplicación coherente.

Trate sus políticas como código.

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

Asegúrate de probar 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 del repositorio cuando se modifiquen.

Espero que esto te haya proporcionado información suficiente para saber cómo implementar una política de «confianza
cero» en tus sistemas de IAM y hacer 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 limpieza de esos silos o

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

Intentad siempre implementar algo que os dé ventaja en caso de que un malintencionado
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 autentifica.

Es algo que debe verificarse continuamente a través de sus acciones y
de, ya sabéis, lo que hacen en vuestra 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, dos 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 resiliencia cibernética y cómo Commvault te ayuda a conseguirla inscribiéndote en un taller de resiliencia cibernética
o realizando una

Readiness para la ciberresiliencia; los enlaces aparecen en la pantalla para que puedas acceder a ellos.

Quiero daros las gracias de todo corazón por vuestro tiempo 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 asistencia hoy y muchas gracias por haber venido.