A medida que más organizaciones ejecutan sus propios modelos de lenguaje a gran escala (LLM), también están introduciendo más servicios internos e interfaces de programación de aplicaciones (API) para respaldar esos modelos. Los riesgos de seguridad modernos no provienen cada vez más de los modelos en sí, sino de la infraestructura que los sirve, los conecta y los automatiza. Cada nuevo punto final de LLM amplía la superficie de ataque de maneras que fácilmente se pasan por alto durante una implementación rápida, especialmente si el punto final es implícitamente confiable. Si un punto final de LLM acumula permisos excesivos y expone credenciales de larga duración, potencialmente puede proporcionar mucho más acceso del previsto. A medida que los puntos finales expuestos se convierten en un vector de ataque cada vez más popular para que los ciberdelincuentes obtengan acceso a los sistemas, identidades y secretos que impulsan las cargas de trabajo de LLM, las organizaciones deben priorizar la gestión de privilegios de los puntos finales.
¿Qué es un punto final en una infraestructura LLM moderna?
En una infraestructura LLM moderna, un punto final es una interfaz a través de la cual algo, como un usuario, una aplicación o un servicio, puede comunicarse con un modelo. En pocas palabras, los puntos finales le permiten enviar solicitudes a LLM y devolver respuestas. Los ejemplos comunes incluyen API de inferencia que procesan solicitudes y producen resultados, interfaces de administración de modelos que se utilizan para actualizar modelos y paneles administrativos que permiten a los equipos monitorear el desempeño. Muchas implementaciones de LLM también dependen de puntos finales de ejecución de herramientas o complementos que permiten que el modelo interactúe con servicios externos, como bases de datos, que conectan LLM a otros sistemas. Estos puntos finales definen cómo 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 uso interno y velocidad en lugar de seguridad a largo plazo. Por lo general, se crean para respaldar la experimentación o la implementación temprana y se dejan funcionando con una supervisión mínima. Como resultado, la supervisión tiende a ser inadecuada y se concede más acceso del necesario. En realidad, el punto final se convierte en el perímetro de seguridad, y su alcance de control de identidad, manejo de secretos y privilegios determina hasta dónde pueden atacar los ciberdelincuentes.
Cómo se exponen los puntos finales de LLM
Los LLM rara vez se ven expuestos a una sola falla. A menudo, con el tiempo, se ponen en riesgo debido a 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:
API a las que se puede acceder públicamente sin autenticación: las API internas pueden exponerse públicamente para acelerar las pruebas y la integración. La autenticación se retrasa o se omite por completo, lo que deja accesibles los puntos finales después de que deberían haber sido restringidos. Tokens débiles o estáticos: muchos puntos finales de LLM dependen de tokens o claves API que están codificadas y nunca rotan. Si estos secretos se filtran a través de un sistema o repositorio mal configurado, los usuarios no autorizados pueden obtener acceso sin restricciones a sus puntos finales. Suposición de que lo que hay dentro es seguro: los equipos a menudo asumen que usuarios no autorizados no pueden acceder a los puntos finales internos y los tratan como confiables de forma predeterminada. Sin embargo, a menudo se puede acceder a las redes internas a través de VPN o controles mal configurados. Puntos finales de prueba temporales que persisten: los puntos finales diseñados para fines de depuración o demostración rara vez se limpian. Con el tiempo, estos puntos finales permanecen activos pero no monitoreados y mal protegidos mientras la infraestructura circundante evoluciona. Configuración incorrecta de la nube que expone su servicio: una configuración incorrecta de su puerta de enlace API o reglas de firewall puede exponer involuntariamente sus puntos finales internos de LLM a Internet. Estas configuraciones erróneas a menudo ocurren gradualmente y pasan desapercibidas hasta que se expone el punto final.
Por qué los puntos finales expuestos son peligrosos en las infraestructuras LLM
Los puntos finales expuestos son particularmente peligrosos en entornos LLM, ya que LLM está diseñado para conectar múltiples sistemas dentro de una infraestructura tecnológica más amplia. Cuando los ciberdelincuentes comprometen un único punto final de LLM, a menudo obtienen acceso a algo más que el modelo en sí. A diferencia de las API tradicionales que realizan una única función, los puntos finales de LLM normalmente se integran con bases de datos, herramientas internas o servicios en la nube para admitir flujos de trabajo automatizados. Por lo tanto, una vez que un único punto final se ve comprometido, los ciberdelincuentes pueden potencialmente moverse rápida y lateralmente entre sistemas que ya confían en LLM de forma predeterminada.
El verdadero peligro no proviene de que LLM sea demasiado poderoso, sino de la confianza implícita depositada en el punto final desde el principio. Una vez expuesto, el punto final LLM actúa como un multiplicador de energía. En lugar de explorar sistemas manualmente, los ciberdelincuentes pueden utilizar puntos finales comprometidos para diversas tareas automatizadas. Los puntos finales expuestos pueden poner en riesgo su entorno LLM al:
Extracción de datos basada en indicaciones: los ciberdelincuentes pueden crear indicaciones que resumen los datos confidenciales a los que tiene acceso el LLM, convirtiendo el modelo en una herramienta de extracción de datos automatizada. Abuso de privilegios de invocación de herramientas: cuando LLM llama a herramientas o servicios internos, estas herramientas pueden explotarse utilizando los puntos finales expuestos para modificar recursos o realizar acciones privilegiadas. Inyección inmediata indirecta: incluso con acceso restringido, los ciberdelincuentes pueden manipular fuentes de datos y entradas de LLM para provocar indirectamente que el modelo realice acciones dañinas.
Por qué NHI es especialmente peligroso en un entorno de LLM
La identidad no humana (NHI) es una credencial utilizada por un sistema en nombre de un usuario humano. En un entorno LLM, se utilizan cuentas de servicio, claves API y otras credenciales no humanas para permitir que los modelos accedan a datos, interactúen con servicios en la nube y realicen tareas automatizadas. NHI plantea un riesgo de seguridad significativo en entornos LLM debido a la dependencia continua del modelo de NHI. Por conveniencia, los equipos otorgan amplios permisos a los NHI, pero a menudo no revisan ni refuerzan los controles de acceso más adelante. Una vez que un terminal LLM se ve comprometido, los ciberdelincuentes pueden heredar el acceso al NHI detrás del terminal y operar utilizando credenciales confiables. Varios problemas comunes exacerban este riesgo de seguridad.
Proliferación secreta: las claves API y las credenciales de cuentas de servicio a menudo se encuentran dispersas en archivos de configuración y canalizaciones, lo que dificulta su seguimiento y protección. Credenciales estáticas: muchos NHI utilizan credenciales de larga duración que rara vez se actualizan. Una vez publicadas estas credenciales, permanecen disponibles durante mucho tiempo. Sobreautorización: A menudo se concede un amplio acceso al seguro médico nacional para evitar retrasos, pero inevitablemente se olvida. Con el tiempo, el NHI acumula más autoridad de la que realmente necesita para su trabajo. Expansión de identidad: los crecientes sistemas LLM generan una gran cantidad de NHI en todo el entorno. Sin una supervisión y gestión adecuadas, esta expansión de la identidad reduce la visibilidad y aumenta la superficie de ataque.
Cómo reducir el riesgo de los puntos finales expuestos
Mitigar el riesgo de los puntos finales expuestos comienza con asumir que los ciberdelincuentes eventualmente llegarán a los servicios expuestos. Los equipos de seguridad deben apuntar no solo a impedir el acceso, sino también a limitar lo que puede suceder una vez que llega al punto final. Una forma sencilla de hacerlo es aplicar los principios de seguridad Zero Trust a todos los puntos finales. El acceso debe ser verificado explícitamente, evaluado continuamente y monitoreado estrictamente en todos los casos. Los equipos de seguridad también deben:
Imponer acceso con privilegios mínimos para usuarios humanos y de máquinas: los puntos finales deben permitir a los usuarios, humanos o no humanos, acceder solo a lo que necesitan para realizar una tarea específica. La reducción de privilegios limita la cantidad de daño que los ciberdelincuentes pueden causar a los puntos finales comprometidos. Utilice acceso justo a tiempo (JIT): el acceso privilegiado no debe estar disponible para ningún terminal todo el tiempo. Con el acceso JIT, los privilegios se otorgan solo cuando son necesarios y se revocan automáticamente una vez completada la tarea. Monitoreo y registro de sesiones privilegiadas: el monitoreo y registro de la actividad privilegiada ayuda a los equipos de seguridad a detectar abusos de privilegios, investigar incidentes de seguridad y comprender cómo se utilizan realmente los puntos finales. Rotar secretos automáticamente: los tokens, las claves API y las credenciales de la cuenta de servicio deben rotarse periódicamente. La rotación de secretos automatizada reduce el riesgo de uso indebido de credenciales a largo plazo si los secretos se ven comprometidos. Si es posible, elimine las credenciales de larga duración. Las credenciales estáticas son uno de los mayores riesgos de seguridad en los entornos LLM. Reemplazarlas con credenciales de corta duración limita la cantidad de tiempo que un secreto comprometido puede usarse en las manos equivocadas.
Estas medidas de seguridad son especialmente importantes en un entorno LLM porque LLM depende en gran medida de la automatización. Debido a que los modelos operan continuamente sin supervisión humana, las organizaciones deben proteger el acceso limitándolo en el tiempo y monitoreándolo intensamente.
Priorice la gestión de privilegios de endpoints para mejorar la seguridad
En entornos LLM donde los modelos están profundamente integrados con herramientas internas y datos confidenciales, el riesgo se amplifica rápidamente cuando los puntos finales quedan expuestos. Los modelos de acceso tradicionales son insuficientes para sistemas que operan de forma autónoma y a escala. Como resultado, las organizaciones deben repensar cómo otorgan y administran el acceso a su infraestructura de IA. La gestión de privilegios de endpoints cambia el enfoque de tratar de evitar el compromiso del endpoint a limitar el impacto eliminando el acceso persistente y controlando lo que los usuarios humanos y no humanos pueden hacer una vez que llegan al endpoint. Soluciones como Keeper respaldan este modelo de seguridad de confianza cero al permitir a las organizaciones eliminar el acceso innecesario y proteger mejor los sistemas LLM críticos.
Nota: Este artículo fue escrito cuidadosamente y contribuido por la redactora de contenido de Keeper Security, Ashley D’Andrea, para nuestros lectores.
Source link
