Una Perspectiva sobre la Comprensión de la Gobernanza de Identidades No Humanas

¿Puede existir una identidad sin ser referenciada por otra identidad? ¿Cómo podríamos saberlo?

Eso podría parecer un poco filosófico para un artículo técnico de seguridad, pero es un punto importante a tener en cuenta al abordar el tema de las identidades no humanas. Una mejor pregunta en torno a la seguridad sería, de hecho, “¿Debería existir una identidad si no se puede interactuar con ella?” Es posible que no podamos llegar a la respuesta a esa primera pregunta, ya que probar la naturaleza de la realidad está un poco fuera del alcance de la ciencia informática. Sin embargo, muchas personas han estado trabajando arduamente en la construcción de herramientas de gobernanza de las NHI para determinar si una identidad de máquina existe, por qué existe y responder a la pregunta de si debería existir. 

El futuro de la eliminación de la dispersión de secretos implica controlar los ciclos de vida y las interdependencias de las identidades no humanas que dependen de secretos. Pero ¿por qué ahora? Vamos a retroceder y reexaminar algunas de nuestras suposiciones sobre las NHIs y su existencia.

¿Qué son las Identidades No Humanas?

Antes de continuar, definamos NHI en el contexto de esta conversación.

In the simplest terms, a non-human identity, also commonly referred to as a machine identity or a workload identity, is any entity that is not human and can perform an action within your system, most commonly interacting exclusively with other non-humans.

Esto podría ser una cápsula de Kubernetes que necesita interactuar con una fuente de datos y enviar los datos procesados a un sistema de informes. Esto podría ser un sensor de Internet de las Cosas (IoT) que envía datos a un servidor central. Esto podría ser un chatbot basado en Slack. Si no se necesita entrada humana directamente después de la creación inicial para que la entidad realice su trabajo, entonces deberíamos considerar esa identidad como ‘no humana’.

La única cosa que todos estos ejemplos tienen en común es que interactúan con otro sistema. Si queremos que se comuniquen con el mundo entero, eso es fácil, ya que simplemente señalamos a las otras identidades no humanas y describimos programáticamente cómo deberían interactuar. Sin embargo, lo más probable es que queramos que estos sistemas se comuniquen de manera segura, autorizando solo identidades específicas bajo circunstancias específicas. Esto ha impulsado la evolución de secretos para la gestión de acceso, desde simples pares de nombre de usuario/contraseña hasta claves de API y certificados.

Es cierto que esa es una definición amplia de NHI. Sin embargo, podemos reducir lo que nos importa sobre las identidades de máquina al dar un paso atrás y considerar cómo estas entidades se relacionan entre sí a través de la lente de sus secretos, permitiendo el acceso y la comunicación.

Todos los NHI se conectan a otros sistemas

¿Puedes construir una aplicación independiente que no reciba ninguna entrada, no produzca ninguna salida y no tenga una interfaz direccionable? ¿Existe tal aplicación fuera de un experimento mental? Aunque es divertido pensarlo, la realidad es que todos los NHI que nos importan existen para comunicarse con otras identidades.

Los NHI requieren inherentemente conexiones a otros sistemas y servicios para cumplir su propósito. Esta interconectividad significa que cada NHI se convierte en un nodo en una red de interdependencias. Desde una perspectiva de gobernanza de NHI, esto requiere mantener un inventario preciso y dinámico de estas conexiones para gestionar los riesgos asociados. Por ejemplo, si un solo NHI es comprometido, ¿con qué se conecta y qué podría acceder un atacante para moverse lateralmente?

Una gobernanza adecuada de la NHI debe incluir herramientas para mapear y monitorear estas relaciones. Aunque hay muchas formas de hacer esto manualmente, lo que realmente queremos es una forma automatizada de identificar qué está conectado a qué, para qué se utiliza y por quién. Al pensar en términos de asegurar nuestros sistemas, podemos aprovechar otro hecho importante sobre todas las NHIs en una aplicación segura para construir ese mapa, todas tienen, necesariamente, secretos.

Todas las NHIs seguras deben tener un secreto

Para establecer una comunicación de confianza entre dos NHIs, debe existir un secreto único, como una clave API, un token o un certificado, para que esas entidades se autentiquen. Podemos utilizar el secreto para verificar la identidad de una NHI y mapearla en el ecosistema. La pregunta es, ¿dónde buscamos estos secretos?

En la empresa moderna, especialmente en las más grandes, hay básicamente solo dos lugares donde un secreto puede residir. La primera opción es la mejor práctica y la opción más segura: un sistema de gestión de secretos, como Conjur de CyberArk, Vault de HashiCorp o AWS Secrets Manager. La otra opción es mucho menos segura pero, desafortunadamente, demasiado común: fuera de un almacén, en el código o la configuración en texto plano.

Las plataformas de gestión de secretos empresariales, a menudo denominadas bóvedas, son críticas para almacenar y proteger los secretos utilizados por las NHI. Las bóvedas pueden proporcionar una única fuente de verdad para todos los secretos, asegurando que estén cifrados en reposo, con un control de acceso estricto y monitoreados para detectar intentos de acceso no autorizados. Esto asume que se ha estandarizado en una única plataforma de gestión de secretos empresariales. La mayoría de las organizaciones, de hecho, tienen muchas bóvedas en uso al mismo tiempo, lo que hace que la sincronización entre todas las bóvedas sea un desafío adicional.

Los equipos pueden mapear todas las identidades de máquina existentes en función de la existencia de esos secretos. Para las empresas con múltiples soluciones de gestión de secretos implementadas, es necesario saber qué bóvedas contienen y no contienen un secreto y reducir la sobrecarga de almacenar la misma clave de forma redundante en varias bóvedas.

Todos los secretos de NHI tienen una historia de origen

Las máquinas no pueden otorgarse permisos y acceso a sí mismas. Cada identidad de máquina fue creada por o representa una identidad humana. La gobernanza de las NHI debe incluir el seguimiento de la creación de secretos para garantizar que cada secreto sea rastreable hasta su origen, distribuido de forma segura y vinculado a una identidad legítima. Si bien este aspecto podría tenerse en cuenta con el uso adecuado de una plataforma de gestión de secretos, nuestros datos continúan informándonos que un cierto porcentaje de secretos se filtran año tras año porque no estamos utilizando de manera consistente estas soluciones de bóveda.

Sabemos por años de experiencia ayudando a equipos a remediar incidentes que el creador de un secreto casi siempre será la persona que introduce la credencial en un ecosistema por primera vez. También podemos determinar por el historial de código u otra información de marca de tiempo del sistema cuándo fue visto por primera vez, lo cual es el momento más probable para que se haya creado o al menos haya entrado en existencia de manera significativa.

Este es un detalle crítico que quizás nunca haya sido registrado o documentado adecuadamente en ningún otro lugar. Una vez que comprendes quién creó un secreto para poder aprovechar un NHI, entonces realmente comprendes el comienzo de nuestro ciclo de vida de NHI.

Todos los Secretos de NHI Deben Otorgar un Conjunto de Permisos

Cuando se crea, cada secreto de NHI debe otorgarse un cierto conjunto de permisos. El alcance determina qué acciones puede realizar una identidad y en qué sistemas. Esto hace que la delimitación y aplicación de permisos sean componentes cruciales de la gobernanza.

Esencialmente, dos riesgos hacen que comprender el alcance de un secreto sea crítico para la seguridad empresarial. El primero es que los secretos mal configurados o con privilegios excesivos pueden otorgar acceso por error a datos sensibles o sistemas críticos, aumentando significativamente la superficie de ataque. Imagina dar accidentalmente privilegios de escritura a un sistema que puede acceder a la información personal identificable de tus clientes. Eso es como un reloj esperando a que un actor malicioso lo encuentre y lo explote.

Además, igual de preocupante es que cuando se filtra o compromete un secreto, un equipo no puede reemplazarlo hasta que primero entienda cómo se configuraron esos permisos. Por ejemplo, supongamos que sabes que el secreto de un microservicio crítico para la misión se publicó accidentalmente en un repositorio público de GitHub. En ese caso, es solo cuestión de tiempo antes de que sea descubierto y utilizado por alguien fuera de tu organización. En nuestro reciente informe Voz del Practicante, los tomadores de decisiones de TI admitieron que les llevó, en promedio, 27 días rotar estos secretos críticos. Los equipos deberían poder actuar en segundos o minutos, no en días.

Se necesitan herramientas que proporcionen contexto adicional sobre los secretos detectados, incluidos sus roles y permisos. Comprender rápidamente qué activos están expuestos cuando ocurre una filtración y qué daño potencial puede infligir un actor amenazante es crucial al responder a un incidente. Saber exactamente cómo reemplazarlo desde una vista de panel o una llamada de API puede significar la diferencia entre una violación y un atacante frustrado al descubrir que la clave que tienen es inválida.

Todos los Secretos NHI Necesitan ser Rotados

Una identidad de máquina puede, y probablemente debería, tener muchos secretos a lo largo de su vida útil. Si las credenciales se dejan vivir durante meses o años, o en el peor de los casos, para siempre, la exposición o compromiso de secretos de NHI se vuelve cada vez más probable. La rotación manual es propensa a errores y operativamente exigente, especialmente en entornos con miles de NHIs. Automatizar el proceso de rotación de secretos es una piedra angular de la gobernanza de NHI, asegurando que los secretos se actualicen antes de que expiren o se filtren.

Para cualquiera de los secretos en sus bóvedas, la rotación debería ser una cuestión simple de script. La mayoría de las plataformas de gestión de secretos proporcionan scripts u otro mecanismo para manejar el delicado baile de reemplazar y revocar de manera segura el antiguo secreto.

Pero, ¿qué sucede con los secretos de NHI que viven fuera de estas bóvedas, o tal vez el mismo secreto que se encuentra disperso en múltiples bóvedas? Una buena plataforma de escaneo de secretos necesita integración perfecta con estas bóvedas para que su equipo pueda encontrar y almacenar de manera segura estos secretos en el gestor de secretos y preparar el camino para la rotación automatizada. La implementación de referencia de GitGuardian con Conjur de CyberArk profundiza en cómo puede automatizar completamente todo el proceso de almacenamiento y rotación.

Al identificar todos los NHIs y saber cuándo fueron creados, también podemos predecir cuándo necesitan ser rotados. Si bien cada equipo juzgará exactamente cuánto tiempo debe vivir cada secreto, cualquier secreto que nunca haya sido rotado después de su creación está maduro para ser reemplazado. Cualquier secreto que tenga más de un año, o para algunos sistemas críticos, unos pocos días, también debe ser priorizado para su rotación lo antes posible.

Todos los NHIs Tendrán un Fin de Vida

Los NHIs, al igual que sus contrapartes humanas, tienen ciclos de vida finitos. Pueden ser desactivados cuando un servicio es retirado, reemplazado o ya no es necesario. Sin abordar la desactivación y limpieza de los NHIs para prevenir la persistencia de secretos no utilizados o conexiones obsoletas, estamos creando puntos ciegos de seguridad. Pero, ¿cómo sabemos cuándo estamos al final del camino para un NHI, especialmente si su secreto sigue siendo válido?

Una respuesta es que ya no debería existir cuando un NHI ya no se conecta a otro sistema activo. Esto asegura que los atacantes no puedan explotar secretos de NHI obsoletos para obtener un punto de apoyo en su entorno. Recuerde que a los atacantes no les importa cómo debería usarse un secreto; solo les importa lo que pueden hacer con él.

Al mapear todas las relaciones que los secretos de un NHI permiten, puede identificar cuándo un sistema ya no está conectado a ninguna otra identidad. Una vez que no hay más formas para que una identidad se comunique, entonces ésta y sus secretos ya no deberían existir. También significa que el secreto ya no necesita ser almacenado en sus gestores de secretos, dándole una cosa menos que almacenar y gestionar.

Entender el Mundo que Rodea Sus NHIs es Crítico para la Seguridad

En 2022, la investigación de CyberArk mostró que por cada identidad humana en un entorno, al menos 45 identidades no humanas deben ser gestionadas. Esa proporción hoy en día probablemente esté más cerca de 1 a 100 y sigue aumentando. El mejor momento para aceptar la gobernanza y la gestión del ciclo de vida de tus NHI fue hace años. El siguiente mejor momento es ahora mismo.

Es hora de adoptar un enfoque de ciclo completo para la seguridad de la identidad no humana, mapeando no solo dónde están tus secretos NHI, sino, igual de importante, qué otras NHI están conectadas. Estamos retrasados, en todas las industrias, para implementar la gobernanza de NHI a gran escala. Encontrar y almacenar correctamente tus secretos es solo el comienzo de la historia. Debemos documentar y entender mejor el alcance de los secretos NHI, su antigüedad, quién los implementó y otra información contextual, como cuándo deben ser rotados.

A pesar de que las identidades de máquina superan en número a los seres humanos, no hay razón para trabajar solo para resolver este problema; todos estamos en esto juntos.