Según una investigación de GitGuardian y CyberArk, el 79% de los responsables de la toma de decisiones de TI informaron haber experimentado una filtración de secretos, frente al 75% del informe del año anterior. Al mismo tiempo, la cantidad de credenciales filtradas nunca ha sido tan alta: más de 12,7 millones de credenciales codificadas solo en repositorios públicos de GitHub. Uno de los aspectos más preocupantes de este informe es que más del 90% de los secretos válidos encontrados y reportados permanecieron válidos durante más de cinco días.
Según la misma investigación, en promedio, las organizaciones tardan 27 días en remediar las credenciales filtradas. Combine eso con el hecho de que las identidades no humanas superan en número a las identidades humanas en al menos 45:1, y es fácil ver por qué muchas organizaciones se están dando cuenta de que detener la expansión de los secretos significa encontrar una manera de lidiar con esta crisis de identidad de las máquinas. Desafortunadamente, la investigación también muestra que muchos equipos están confundidos acerca de quién es el propietario de la seguridad de estas identidades. Es una tormenta perfecta de riesgo.
¿Por qué la rotación tarda tanto?
Entonces, ¿por qué tardamos tanto en rotar las credenciales si sabemos que son una de las rutas de ataque más fáciles para los adversarios? Un factor importante que contribuye es la falta de claridad sobre cómo se autorizan nuestras credenciales. Los permisos son los que autorizan qué cosas específicas una entidad, como una carga de trabajo de Kubernetes o un microservicio, puede solicitar con éxito de otro servicio o fuente de datos.
Recordemos lo que significa la remediación de un incidente de expansión descontrolada de secretos: es necesario reemplazar de forma segura un secreto sin romper nada ni otorgar permisos nuevos y demasiado amplios, lo que potencialmente introduciría más riesgos de seguridad para su empresa. Si ya tiene una visión completa del ciclo de vida de sus identidades no humanas y sus secretos asociados, este es un proceso bastante sencillo para reemplazarlos con nuevos secretos con los mismos permisos. Esto puede llevar un tiempo considerable si aún no tiene esa información, ya que debe esperar que el desarrollador que lo creó originalmente todavía esté allí y haya documentado lo que se hizo.
Veamos por qué la gestión de permisos es especialmente desafiante en entornos dominados por NHI, examinemos los desafíos que enfrentan los desarrolladores y los equipos de seguridad para equilibrar el control de acceso y la productividad, y analicemos cómo un modelo de responsabilidad compartida podría ayudar.
¿A quién pertenece realmente la expansión de los secretos?
La expansión de secretos generalmente se refiere a la proliferación de claves de acceso, contraseñas y otras credenciales confidenciales en entornos de desarrollo, repositorios y servicios como Slack o Jira. El último informe Voice of the Practitioners de GitGuardian destaca que el 65% de los encuestados atribuyen la responsabilidad de la remediación directamente a los equipos de seguridad de TI. Al mismo tiempo, el 44% de los líderes de TI informaron que los desarrolladores no siguen las mejores prácticas para la gestión de secretos.
La proliferación de secretos y los problemas subyacentes de las credenciales de larga duración con exceso de permisos seguirán cayendo en esta brecha hasta que descubramos cómo trabajar mejor juntos en un modelo de responsabilidad compartida.
La perspectiva del desarrollador sobre los permisos
Los desarrolladores enfrentan una enorme presión para crear e implementar funciones rápidamente. Sin embargo, administrar los permisos cuidadosamente, con las mejores prácticas de seguridad, puede resultar laborioso. Cada proyecto o aplicación a menudo tiene sus propios requisitos de acceso únicos, que requieren tiempo para investigarse y configurarse adecuadamente, casi como si fuera un trabajo de tiempo completo además del trabajo de creación e implementación de sus aplicaciones. Con demasiada frecuencia, las mejores prácticas para crear y administrar permisos no se aplican de manera uniforme en todos los equipos, rara vez se documentan adecuadamente o se olvidan por completo una vez que el desarrollador hace que la aplicación funcione.
Para agravar el problema, en demasiados casos los desarrolladores simplemente otorgan permisos demasiado amplios a estas identidades de máquinas. Un informe encontró que sólo el 2% de los permisos concedidos se utilizan realmente. Si observamos más de cerca a qué se enfrentan, es fácil ver por qué.
Por ejemplo, piense en administrar permisos dentro de Amazon Web Services. Las políticas de administración de acceso e identidad (IAM) de AWS son conocidas por su flexibilidad, pero también son complejas y confusas de navegar. IAM admite varios tipos de políticas (basadas en identidad, basadas en recursos y límites de permisos), todas las cuales requieren configuraciones precisas. AWS también ofrece múltiples rutas de acceso para credenciales, incluidas funciones de IAM y concesiones de KMS (servicio de administración de claves), cada una de las cuales viene con sus propias configuraciones de acceso únicas. Aprender este sistema no es tarea fácil.
Otro ejemplo común de un servicio donde los permisos pueden resultar difíciles de gestionar es GitHub. Las claves API pueden otorgar permisos a repositorios en varias organizaciones, lo que dificulta garantizar límites de acceso adecuados. Una única clave puede proporcionar involuntariamente un acceso excesivo entre entornos cuando los desarrolladores son miembros de varias organizaciones. Hay presión para hacerlo bien, mientras el tiempo siempre corre y el trabajo atrasado sigue aumentando.
Por qué los equipos de seguridad por sí solos no pueden solucionar este problema
Puede parecer lógico asignar a los equipos de seguridad la responsabilidad de monitorear y rotar los secretos; después de todo, se trata de un problema de seguridad. La realidad es que estos equipos a menudo carecen del conocimiento granular a nivel de proyecto necesario para realizar cambios de forma segura. Los equipos de seguridad no siempre tienen el contexto para comprender qué permisos específicos son esenciales para mantener las aplicaciones en ejecución. Por ejemplo, un cambio de permiso aparentemente menor podría interrumpir una canalización de CI/CD, interrumpir la producción o incluso causar una falla en cascada en toda la empresa si desaparece el servicio incorrecto.
La naturaleza dispersa de la gestión de secretos entre equipos y entornos también aumenta la superficie de ataque. Sin nadie realmente a cargo, resulta mucho más difícil mantener la coherencia en los controles de acceso y las pistas de auditoría. Esta fragmentación a menudo da como resultado que las credenciales excesivas u obsoletas y sus permisos asociados permanezcan activos durante demasiado tiempo, posiblemente para siempre. Puede dificultar saber quién tiene acceso legítimo o ilegítimo a qué secretos en un momento dado.
Un modelo de responsabilidad compartida para una rotación más rápida
Los desarrolladores y los equipos de seguridad podrían ayudar a abordar estos problemas reuniéndose en el medio y construyendo un modelo de responsabilidad compartida. En tal modelo, los desarrolladores son más responsables de administrar consistentemente sus permisos a través de herramientas adecuadas, como Conjur Secrets Manager de CyberArk o Vault de HashiCorp, al mismo tiempo que documentan mejor los permisos y el alcance de los permisos necesarios a nivel de proyecto. Los equipos de seguridad deberían ayudar a los desarrolladores trabajando para automatizar la rotación de secretos, invirtiendo en herramientas de observabilidad adecuadas para obtener claridad sobre el estado de los secretos y trabajando con TI para eliminar por completo las credenciales de larga duración.
Si los desarrolladores documentan claramente qué permisos son necesarios en sus requisitos, podría ayudar a los equipos de seguridad a realizar auditorías más rápidas y precisas y acelerar la remediación. Si los equipos de seguridad trabajan para garantizar que la ruta general más fácil y rápida hacia la implementación de un nuevo secreto de identidad no humana sea también la ruta más segura y escalable, entonces habrá muchos menos incidentes que requieran una rotación de emergencia y todos ganarán.
El objetivo de los desarrolladores debe ser garantizar que el equipo de seguridad pueda rotar o actualizar las credenciales en sus aplicaciones con confianza, por sí solos, sabiendo que no están poniendo en peligro la producción.
Preguntas clave a abordar sobre permisos
Al pensar en lo que se debe documentar, aquí hay algunos puntos de datos específicos para ayudar a que este esfuerzo entre equipos fluya mejor:
- ¿Quién creó la credencial? – A muchas organizaciones les resulta difícil realizar un seguimiento de la propiedad de las credenciales, especialmente cuando una clave se comparte o rota. Este conocimiento es esencial para comprender quién es responsable de rotar o revocar las credenciales.
- ¿A qué recursos accede? – Las claves API a menudo pueden acceder a una variedad de servicios, desde bases de datos hasta integraciones de terceros, por lo que es esencial limitar los permisos al mínimo necesario.
- ¿Qué permisos otorga? – Los permisos varían ampliamente según los roles, las políticas basadas en recursos y las condiciones de las políticas. Por ejemplo, en Jenkins, un usuario con permiso “General/Lectura” puede ver información general, mientras que “General/Administrar” otorga control total sobre el sistema.
- ¿Cómo lo revocamos o rotamos? – La facilidad de revocación varía según la plataforma y, en muchos casos, los equipos deben rastrear manualmente las claves y los permisos en todos los sistemas, lo que complica la remediación y prolonga la exposición a las amenazas.
- ¿Está activa la credencial? – Es fundamental saber si una credencial todavía está en uso. Cuando los NHI utilizan claves API de larga duración, estas credenciales pueden permanecer activas indefinidamente a menos que se administren adecuadamente, lo que crea riesgos de acceso persistentes.
Los permisos son desafiantes, pero podemos administrarlos juntos como un solo equipo
Según el informe de GitGuardian, si bien el 75% de los encuestados expresaron confianza en sus capacidades de gestión de secretos, la realidad suele ser muy diferente. El tiempo promedio de remediación de 27 días refleja esta brecha entre confianza y práctica. Es hora de repensar cómo implementamos y comunicamos secretos y sus permisos como organización.
Si bien los desarrolladores trabajan diligentemente para equilibrar la seguridad y la funcionalidad, la falta de procesos de permisos optimizados y rutas de documentación no centralizadas o no estandarizadas solo amplifican los riesgos. Los equipos de seguridad por sí solos no pueden resolver estos problemas de forma eficaz debido a su conocimiento limitado de las necesidades específicas del proyecto. Necesitan trabajar mano a mano con los desarrolladores en cada paso del camino.
GitGuardian está creando la próxima generación de herramientas de seguridad de secretos, ayudando a los equipos de seguridad y de TI a controlar la expansión de los secretos. Saber qué credenciales de texto sin formato y de larga duración están expuestas en su código y en otros entornos es un primer paso necesario para eliminar esta amenaza. Comience hoy con GitGuardian.
