Las credenciales estáticas siguen siendo la forma más fácil para que la IA acceda

La IA no inventó la credencial con privilegios excesivos, solo encontró la forma más rápida de usar una. Cada agente, script e integración que se ejecuta en tu entorno se autentica con algo, y en la mayoría de los entornos, ese algo es una contraseña, una clave API o un token emitido una vez y nunca más tocado. Una persona olvida una contraseña y eventualmente queda bloqueada. Una identidad de máquina simplemente sigue usando lo que se le dio, mientras nadie esté mirando.

Más identidades, más brechas

Encuestamos a 2,317 líderes de seguridad y TI este año, y el número más claro en los resultados fue este: las organizaciones donde la IA ha incrementado significativamente el número de identidades en su entorno reportaron una tasa de brechas del 43% en los últimos 12 meses. Las organizaciones donde la IA no cambió mucho su conteo de identidades reportaron un 11%. Esa es una diferencia de 4 veces, y no es porque el grupo con mucha IA tuviera una seguridad más débil en general. Nuestros datos muestran que estaban adelantados en la mayoría de los aspectos básicos.

Donde no estaban adelantados era identidad no humana gobernanza. El setenta y seis por ciento de las organizaciones nos dijo que no gobiernan ni monitorean completamente sus identidades no humanas, y solo el 19% dijo que sí. Esa es la población por la que la IA está pasando: un conjunto creciente de identidades de máquinas, la mayoría de ellas autenticándose con una credencial que nadie ha verificado desde el día en que se emitió.

Credenciales estáticas

Una credencial estática no caduca por sí sola, no se rota por sí sola y no le importa cuántas veces se use. Eso es lo que la hace peligrosa una vez que está dentro de algo automatizado. Una persona que usa una contraseña robada eventualmente es detectada. Un agente de IA o script que usa una credencial robada simplemente sigue funcionando, a la velocidad que permita el flujo de trabajo, hasta que alguien lo descubra.

Pasos para asegurar las credenciales NHI

1. Bóveda

El primer paso es sacar las credenciales de scripts, archivos de configuración, hojas de cálculo y código fuente y llevarlas a un sistema diseñado para almacenarlas. Esto parece sencillo y rara vez lo es. Un bóveda debe funcionar en aplicaciones estratégicas y heredadas, cubrir diferentes patrones de acceso según cómo cada aplicación accede a una credencial, y soportar tanto la incorporación centralizada como la realidad de que algunos equipos siempre añadirán credenciales manualmente. En la práctica, esto significa una arquitectura multinivel: una capa de presentación para los usuarios, un servidor de aplicaciones que aplica la lógica de negocio y permisos, y una capa de base de datos que realmente almacena los secretos, con la opción de escalar múltiples servidores de aplicaciones para distribuir la carga entre equipos geográficamente distribuidos. La gestión de bóvedas también es el paso que más rápido da resultados, ya que es la diferencia entre una credencial que cualquiera puede encontrar y una que está realmente controlada.

2. Cifrado

Una vez que una credencial está en una bóveda, debe permanecer cifrada, con las claves de cifrado gestionadas con el mismo cuidado que las propias credenciales. Eso significa más que simplemente activar AES y darlo por terminado. Una bóveda correctamente construida debe usar cifrado autenticado (AES-GCM 256) para las credenciales, funciones fuertes de derivación de claves con un alto número de iteraciones para el hash de usuarios y claves, y criptografía de curva elíptica para el intercambio de claves públicas y privadas. Cada contenedor secreto debe tener su propia sal generada aleatoriamente, y cada contraseña, usuario y rol debe tener su propio par de claves, de modo que el acceso esté cifrado jerárquicamente en lugar de estar protegido por una única clave compartida. Para entornos que sincronizan con Active Directory, debería estar disponible un modo de cifrado de extremo a extremo, donde el servidor nunca tenga acceso al texto plano, como la opción más segura, junto con un modo de clave maestra para organizaciones que necesitan recuperación centralizada. La clave maestra debe estar en hardware, no en un archivo de configuración, protegida por un HSM. Mover una contraseña de texto plano a una bóveda cifrada construida de esta manera es la forma más común en que las organizaciones reducen el riesgo de credenciales, y es el paso más al alcance para los equipos que no han abordado la seguridad NHI antes.

3. Ciclismo y rotación

Rotar las credenciales regularmente reduce el riesgo relacionado con empleados que se han ido, limpia la exposición que queda en código y scripts antiguos, y a menudo revela dependencias que nadie sabía que existían. También es el paso más difícil de ejecutar. Si no conoces cada script e integración que depende de una credencial dada, rotarla puede romper la producción en lugar de reducir el riesgo.

La rotación solo funciona como un proceso continuo y automatizado vinculado estrechamente a la bóveda que contiene la credencial, no como una tarea manual que alguien recuerde hacer. Eso significa restablecimientos basados en disparadores, no recordatorios en el calendario: restablecer una credencial un número determinado de minutos después de haber sido vista, después de que haya permanecido sin cambios durante un número definido de días, o una vez que haya expirado. También significa que el proceso debe protegerse a sí mismo. Si un restablecimiento automatizado falla a mitad de camino, en una cuenta de Active Directory, un usuario local de Windows o Linux, o una cuenta de servicio, el sistema debería revertir automáticamente la credencial a su último valor conocido bueno y registrar la falla, en lugar de dejar una cuenta de servicio en un estado roto y parcialmente cambiado. Cada restablecimiento, reversión y bloqueo se registra, por lo que una rotación fallida es visible inmediatamente en lugar de aparecer tres semanas después como una interrupción que nadie puede explicar.

La mayoría de las organizaciones que logran un progreso real dominan primero el almacenamiento seguro y la encriptación, luego avanzan hacia la rotación automatizada basada en desencadenantes una vez que entienden lo suficiente sus dependencias para configurarla de manera segura.

Conoce Password Secure

Cada cuenta de servicio y cuenta de aplicación vinculada a Active Directory pasa por el mismo motor de políticas que sus empleados, ya sea que alguien lo esté aplicando o no. Netwrix Password Secure cubre los tres pasos directamente.

Te ofrece una única bóveda cifrada para credenciales de usuario, administrador y servicio, con criptografía compatible con FIPS (AES-GCM 256, derivación de clave reforzada con PBKDF2 e intercambio de claves con curva elíptica NIST P-521) que protege cada secreto. El acceso basado en roles significa que solo las personas y procesos que necesitan una credencial pueden recuperarla, y un registro completo documenta cada extracción, reinicio y reversión, para que puedas saber quién accedió a una credencial y cuándo. Además, el restablecimiento de contraseña configurable y basado en disparadores maneja la rotación: las credenciales se restablecen automáticamente según un calendario o una condición definida, con protección contra reversión si un sistema destino rechaza el cambio.

Esa es la diferencia entre una contraseña de cuenta de servicio que permanece indefinidamente en una hoja de cálculo, nunca rotada porque nadie quiere arriesgarse a romper algo, y vivir en un lugar donde está cifrada, con control de acceso, registrada y rotada según un calendario que la organización realmente controla.