A medida que más organizaciones ejecutan sus propios modelos de lenguaje grande (LLM), también implementan más servicios internos e interfaces de programación de aplicaciones (API) para respaldar esos modelos. Los riesgos de seguridad modernos provienen menos de los propios modelos y más de la infraestructura que sirve, conecta y automatiza el modelo. Cada nuevo punto final de la LLM amplía la superficie de ataque, a menudo de formas que son fáciles de pasar por alto durante un despliegue rápido, especialmente cuando se confía en los puntos finales de forma implícita. Cuando los terminales de LLM acumulan permisos excesivos y quedan expuestas las credenciales de larga duración, pueden proporcionar un acceso mucho mayor del previsto. Las organizaciones deben dar prioridad a la gestión de los privilegios de los terminales, ya que los terminales expuestos se han convertido en un vector de ataque cada vez más común para que los ciberdelincuentes accedan a los sistemas, las identidades y los secretos que impulsan las cargas de trabajo de la LLM.

¿Qué es un punto final en la infraestructura moderna de LLM?

En la infraestructura moderna de LLM, un punto final es cualquier interfaz en la que algo, ya sea un usuario, una aplicación o un servicio, puede comunicarse con un modelo. En pocas palabras, los terminales permiten enviar las solicitudes a un LLM y devolver las respuestas. Algunos ejemplos comunes son las API de inferencia que gestionan las solicitudes y generan resultados, las interfaces de administración de modelos que se utilizan para actualizar los modelos y los paneles administrativos que permiten a los equipos supervisar el rendimiento. Muchas implementaciones de LLM también se basan en puntos finales de ejecución de complementos o herramientas, que permiten a los modelos interactuar con servicios externos, como bases de datos, que pueden conectar el LLM con otros sistemas. En conjunto, estos puntos finales definen la forma en que el LLM se conecta con el resto de su entorno.

El principal desafío es que la mayoría de los puntos finales de LLM están diseñados para el uso y la velocidad internos, no para la seguridad a largo plazo. Por lo general, se crean para permitir la experimentación o las primeras implementaciones y luego se dejan en funcionamiento con una supervisión mínima. Como resultado, suelen estar mal supervisados y se les concede más acceso del necesario. En la práctica, el punto final se convierte en el límite de seguridad, lo que significa que sus controles de identidad, manejo de secretos y alcance de privilegios determinan hasta dónde puede llegar un ciberdelincuente.

Cómo quedan expuestos los puntos finales de LLM

Los LLM rara vez se exponen a una falla; más a menudo, la exposición ocurre gradualmente a través de pequeñas suposiciones y decisiones tomadas durante el desarrollo y la implementación. Con el tiempo, estos patrones transforman los servicios internos en superficies de ataque accesibles desde el exterior. Algunos de los patrones de exposición más comunes incluyen:

  • APIs de acceso público sin autenticación: Las API internas a veces se exponen públicamente para acelerar las pruebas o la integración. La autenticación se retrasa o se omite por completo, y el punto final permanece accesible mucho tiempo después de su intención de restringirlo.
  • Tokens débiles o estáticos: Muchos puntos finales de LLM se basan en tokens o claves de API que están codificados y nunca se rotan. Si estos secretos se filtran a través de sistemas o repositorios mal configurados, los usuarios no autorizados pueden acceder a un punto final de forma indefinida.
  • La suposición de que interno significa seguro: Los equipos suelen tratar los puntos finales internos como confiables de forma predeterminada, asumiendo que nunca serán alcanzados por usuarios no autorizados. Sin embargo, con frecuencia se puede acceder a las redes internas a través de VPN o controles mal configurados.
  • Puntos finales de prueba temporales que pasan a ser permanentes: Los terminales diseñados para la depuración o las demostraciones rara vez se limpian. Con el tiempo, estos puntos finales permanecen activos, pero no están supervisados y están mal protegidos mientras la infraestructura circundante evoluciona.
  • Errores de configuración en la nube que exponen los servicios: Las puertas de enlace API o las reglas de firewall mal configuradas pueden exponer involuntariamente los puntos finales internos de LLM a Internet. Estos errores de configuración suelen producirse de forma gradual y pasan desapercibidos hasta que el punto final ya está expuesto.

Por qué los puntos finales expuestos son peligrosos en toda la infraestructura de LLM

Los puntos finales expuestos son particularmente peligrosos en los entornos de LLM porque los LLM están diseñados para conectar varios sistemas dentro de una infraestructura técnica más amplia. Cuando los ciberdelincuentes ponen en peligro un único punto final de LLM, a menudo pueden acceder a mucho más que al modelo en sí. A diferencia de las API tradicionales que realizan una sola función, las terminales de LLM suelen integrarse con bases de datos, herramientas internas o servicios en la nube para respaldar los flujos de trabajo automatizados. Por lo tanto, un punto final comprometido puede permitir a los ciberdelincuentes moverse rápida y lateralmente entre sistemas que ya confían en el LLM de forma predeterminada.

El verdadero peligro no se deriva de que el LLM sea demasiado poderoso, sino de la confianza implícita depositada en el punto final desde el principio. Una vez que un punto final de LLM queda expuesto, puede actuar como un multiplicador de fuerza; los ciberdelincuentes pueden utilizar un punto final comprometido para realizar diversas tareas automatizadas en lugar de explorar los sistemas manualmente. Los terminales expuestos pueden poner en peligro los entornos de LLM a través de:

  • Exfiltración de datos rápida: Los ciberdelincuentes pueden crear instrucciones que hagan que el LLM resuma los datos confidenciales a los que tiene acceso, convirtiendo el modelo en una herramienta de extracción de datos automatizada.
  • Abuso de los permisos de llamada a herramientas: Cuando los LLM llaman a herramientas o servicios internos, los puntos finales expuestos pueden usarse para abusar de estas herramientas modificando los recursos o realizando acciones privilegiadas.
  • Inyección inmediata indirecta: Incluso cuando el acceso es limitado, los ciberdelincuentes pueden manipular las fuentes de datos o las entradas de LLM, lo que hace que el modelo ejecute acciones dañinas de forma indirecta.

Por qué los NHIs son especialmente peligrosos en los entornos de LLM

Identidades no humanas (NHI) son credenciales que utilizan los sistemas en lugar de los usuarios humanos. En los entornos de LLM, las cuentas de servicio, las claves de API y otras credenciales no humanas permiten a los modelos acceder a los datos, interactuar con los servicios en la nube y realizar tareas automatizadas. Las NIH representan un riesgo de seguridad importante en los entornos de LLM porque los modelos se basan en ellas de forma continua. Por conveniencia, los equipos suelen conceder a los NHIs amplios permisos, pero más adelante no revisan ni refuerzan los controles de acceso. Cuando un terminal de LLM se ve comprometido, los ciberdelincuentes heredan el acceso del NHI desde ese punto final, lo que les permite operar con credenciales confiables. Hay varios problemas comunes que agravan este riesgo de seguridad:

  • Los secretos se extienden: Las claves de API y las credenciales de las cuentas de servicio suelen estar repartidas entre los archivos de configuración y las canalizaciones, lo que dificulta su seguimiento y protección.
  • Credenciales estáticas: Muchos NHIs utilizan credenciales de larga duración que rara vez, o nunca, rotan. Una vez que esas credenciales quedan expuestas, se pueden utilizar durante largos períodos de tiempo.
  • Permisos excesivos: A menudo se concede un amplio acceso a los NHIs para evitar demoras, pero inevitablemente se olvida de ello. Con el tiempo, los NHIs acumulan más permisos de los que realmente son necesarios para sus tareas.
  • Expansión de identidades: Los sistemas LLM en crecimiento producen una gran cantidad de NHIs en todos los entornos. Sin una supervisión y una gestión adecuadas, esta expansión de las identidades reduce la visibilidad y aumenta la superficie de ataque.

Cómo reducir el riesgo de los puntos finales expuestos

La reducción del riesgo de los terminales expuestos comienza asumiendo que los ciberdelincuentes acabarán por llegar a los servicios expuestos. Los equipos de seguridad deben tratar no solo de impedir el acceso, sino también de limitar lo que puede suceder una vez que se llega a un punto final. Una forma sencilla de hacerlo es aplicar los principios de seguridad de confianza cero a todos los puntos finales: el acceso debe verificarse de forma explícita, evaluarse continuamente y supervisarse estrictamente en todos los casos. Los equipos de seguridad también deben hacer lo siguiente:

  • Imponga el acceso con privilegios mínimos para los usuarios humanos y de máquinas: Los terminales solo deben tener acceso a lo necesario para realizar una tarea específica, independientemente de si el usuario es humano o no humano. La reducción de los permisos limita el daño que un ciberdelincuente puede causar a un terminal comprometido.
  • Utilice el acceso justo a tiempo (JIT): El acceso privilegiado no debe estar disponible todo el tiempo en ningún punto final. Con el acceso JIT, los privilegios solo se otorgan cuando es necesario y se revocan automáticamente una vez finalizada la tarea.
  • Supervise y grabe las sesiones privilegiadas: La supervisión y el registro de la actividad privilegiada ayudan a los equipos de seguridad a detectar el uso indebido de privilegios, investigar los incidentes de seguridad y comprender cómo se utilizan realmente los puntos finales.
  • Rota los secretos automáticamente: Los tokens, las claves de API y las credenciales de las cuentas de servicio deben rotarse de forma regular. La rotación automatizada de los secretos reduce el riesgo de abuso de credenciales a largo plazo si se revelan los secretos.
  • Elimine las credenciales de larga duración siempre que sea posible: Las credenciales estáticas son uno de los mayores riesgos de seguridad en los entornos LLM. Su sustitución por credenciales de corta duración limita el tiempo que los secretos comprometidos permanecen útiles en las manos equivocadas.

Estas medidas de seguridad son especialmente importantes en los entornos de LLM porque los LLM dependen en gran medida de la automatización. Dado que los modelos funcionan de forma continua sin supervisión humana, las organizaciones deben proteger el acceso manteniéndolo limitado en el tiempo y supervisándolo de cerca.

Priorice la administración de privilegios de terminales para mejorar la seguridad

Los puntos finales expuestos amplifican el riesgo rápidamente en los entornos de LLM, donde los modelos están profundamente integrados con las herramientas internas y los datos confidenciales. Los modelos de acceso tradicionales son insuficientes para los sistemas que actúan de forma autónoma y a escala, por lo que las organizaciones deben replantearse la forma en que conceden y administran el acceso a la infraestructura de inteligencia artificial. La gestión de privilegios en los terminales pasa de centrarse en tratar de evitar las infracciones en los terminales a limitar el impacto eliminando el acceso permanente y controlando lo que pueden hacer los usuarios, tanto humanos como no humanos, una vez que se llega a un punto final. Soluciones como Guardián respalden este modelo de seguridad de confianza cero al ayudar a las organizaciones a eliminar el acceso innecesario y proteger mejor los sistemas de LLM críticos.

Nota : Ashley D'Andrea, redactora de contenido de Keeper Security, ha escrito cuidadosamente y ha contribuido a este artículo para nuestra audiencia.

¿Te ha parecido interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en Noticias de Google , Twitter y LinkedIn para leer más contenido exclusivo que publicamos.