En el lenguaje cotidiano, un secreto puede ser cualquier dato sensible que se desea mantener en privado. Cuando se habla de secretos en el contexto del desarrollo de software, los secretos generalmente se refieren a credenciales de autenticación digital que otorgan acceso a sistemas o datos. Por lo general, se trata de claves API, nombres de usuario y contraseñas, o certificados de seguridad.
Los secretos existen en el contexto de aplicaciones que ya no son monolitos independientes. Hoy en día, las aplicaciones se basan en miles de componentes básicos independientes: infraestructura en la nube, bases de datos, componentes SaaS como Stripe, Slack, HubSpot…
Los secretos son los que unen estos diferentes componentes básicos de una única aplicación mediante la creación de una conexión segura entre cada componente.
Los secretos suelen ser cadenas de alta entropía, lo que significa que son cadenas o texto con un valor muy aleatorio. La mayoría de los secretos son solo un valor altamente aleatorio que contiene diferentes tipos de caracteres.
¿Qué es la expansión de los secretos (secret sprawl)?
A diferencia de las credenciales tradicionales, los secretos están destinados a distribuirse a desarrolladores, aplicaciones y sistemas de infraestructura. Agregar más de estos factores inevitablemente hará que aumente la cantidad de secretos utilizados en un ciclo de desarrollo, lo que conducirá a un fenómeno natural de expansión: los secretos comienzan a aparecer codificados en el código fuente. Desde el punto de vista de una organización, la visibilidad y el control sobre su distribución comienzan a degradarse. De esto se trata la expansión de los secretos.
Cuando los secretos se distribuyen en múltiples sistemas, aumenta lo que se conoce como la "superficie de ataque". Esta es la cantidad de puntos donde un usuario no autorizado podría obtener acceso a los sistemas o datos. En el caso de la proliferación de secretos, cada vez que un secreto ingresa a otro sistema, es otro punto donde un atacante podría obtener acceso a sus secretos.
La mayoría de los sistemas internos no son un lugar apropiado para almacenar información confidencial, incluso si esos sistemas son privados. Ninguna empresa quiere números de tarjetas de crédito en texto plano en bases de datos, PII en registros de aplicaciones o credenciales de cuentas bancarias en un documento "secreto" de Google debe beneficiarse del mismo tipo de medidas de protección.
Como principio general de seguridad, cuando sea factible, los datos deben permanecer seguros incluso si salen de los dispositivos, sistemas, infraestructura o redes que están bajo el control de las organizaciones, o si se ven comprometidos.
Esto ayuda a prevenir el robo de credenciales, que es una técnica de adversarios bien conocida descrita en el marco MITRE ATT&CK: "Los adversarios pueden buscar en sistemas de archivos locales y recursos compartidos de archivos remotos archivos que contengan contraseñas. Estos pueden ser archivos creados por usuarios para almacenar sus propias credenciales, almacenes de credenciales compartidos para un grupo de personas, archivos de configuración que contienen contraseñas para un sistema o servicio, o archivos de código fuente/binarios que contienen contraseñas integradas."
Los secretos a los que acceden los actores de amenazas maliciosos pueden provocar una fuga de información y permitir un movimiento lateral o un escalamiento de privilegios, ya que los secretos muy a menudo conducen a otros secretos. Además, una vez que un atacante tiene las credenciales para operar como un usuario válido, es extremadamente difícil detectar el abuso y la amenaza puede volverse persistente.
Desafíos de la gestión de secretos
El desafío de la expansión de secretos debe considerar varios aspectos:
- El primer desafío es que en realidad ni siquiera sabemos qué es y dónde. No es que estemos realizando un seguimiento de lo que hay en el código fuente, lo que hay en un repositorio, lo que hay en GitHub. Ni siquiera lo sabemos. Hay un nivel de desconocimiento general y en todas partes. Entonces, un nivel es que no sabemos qué credenciales están y dónde.
- El segundo desafío es que generalmente tenemos un control de acceso limitado sobre esto. Estos no son sistemas diseñados para la gestión de secretos. No mantienen registros de auditoría detallados de quién hace qué y qué credenciales leyeron. Por lo tanto, nos brinda muy poca auditabilidad y muy poco control de acceso.
- La tercera es, ¿qué hacemos cuando hay una infracción? Algo malo sucede y encontramos que el nombre de usuario y la contraseña de nuestra base de datos están en Internet. ¿Y ahora qué? En este mundo, ni siquiera sabemos de dónde provienen ese nombre de usuario y contraseña. ¿Estaba en el código fuente? ¿Codificado o con hardcoding? ¿Estaba en algún archivo de configuración en alguna parte? Ni siquiera sabemos dónde está esta cosa. Y dos, no sabemos realmente cómo remediamos esta infracción. ¿Fue un informante quien lo filtró? No necesariamente tenemos los registros de acceso que nos ayuden a realizar esos análisis forenses. Realmente no tenemos una buena historia sobre cómo rotarlo y cambiarlo. Si está codificado en el código fuente de la aplicación, ¿y ahora qué? Tenemos que cambiar el código fuente, recompilar la aplicación y volver a implementarla. Ahora es un proceso complejo orquestar el cambio en términos de implementar esa configuración.
Entonces, la divulgación de secretos conlleva varios problemas diferentes, pero en realidad es una falta de visibilidad y una falta de control, por lo que esto no nos da buenas respuestas cuando sucede algo. Cuando hablamos de gestión de secretos, el objetivo es solucionar eso.
La solución...
La respuesta de primer nivel es la centralización. Necesitamos pasar de cosas que viven en todas partes (en diferentes sistemas) a vivir en un solo lugar donde el acceso esté estrictamente controlado, auditado y cifrado para que nadie tenga acceso al control de versiones.
Sistemas y aplicaciones como Dotenv, Hashicorp Vault, Kubernetes Secrets, Ansible Vault, Azure Key Vault, AWS Secrets Manager tienen controles de acceso detallados que restringen los secretos a los que tiene acceso según sea necesario. En este sentido, ahora tenemos buenas respuestas: si hay una infracción, tenemos registros de auditoría de quién tuvo acceso y cuándo tuvo acceso. Podemos cambiarlo en un lugar central y distribuirlo a nuestra infraestructura. Simplifica gran parte del ciclo de vida en torno a esta gestión de credenciales.
Búsquedas de secretos
Para combatir la expansión del secreto es esencial tener visibilidad dentro de los sistemas donde se pueden ubicar los secretos. Los repositorios .git pueden contener un tesoro de secretos enterrados en el historial, incluidas versiones antiguas de código fuente, registros de aplicaciones y archivos de configuración. Es importante tener en cuenta también que incluso los mejores sistemas y políticas de gestión de secretos no impiden que los secretos recién generados entren en la base del código o que los secretos antiguos se extraigan e incluyan nuevamente, por lo que todas las organizaciones deben implementar el escaneo de secretos en su flujo de trabajo.
GitGuardian ofrece una herramienta gratuita de escaneo de secretos para repositorios .git que escanea, en tiempo real, cada archivo para identificar de inmediato si sus secretos se han extendido. GitGuardian también tiene una API para que todos los sistemas de oficina, como Slack o el correo electrónico, también puedan escanearse en busca de secretos.
Cifrado de secretos
Los repositorios de Git ofrecen características de colaboración incomparables para los desarrolladores; git no solo actúa como un registro histórico completo de un proyecto, sino que también ofrece un único punto de verdad para la última versión y los archivos, de ahí que sea tan común que se almacenen secretos dentro de ellos.
Git-secret es una herramienta gratuita de código abierto que cifra secretos dentro de los repositorios de git, haciéndolos seguros para distribuirlos.
Fuente: Dev.to