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,
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