El problema de la proliferación de secretos

La proliferación de secretos es la expansión descontrolada de credenciales sensibles por toda una organización. Un secreto es cualquier elemento que concede acceso: claves de API, contraseñas de bases de datos, tokens de OAuth, claves privadas de TLS, claves SSH y claves de cifrado.

La proliferación ocurre cuando estos secretos terminan dispersos en lugares donde nunca deberían estar:

• Código fuente y archivos de configuración
• Canalizaciones de CI/CD y variables de entorno
• Imágenes de contenedor e infraestructura como código
• Mensajes de chat, wikis y sistemas de gestión de tickets

Una vez que un secreto existe en muchos lugares, se pierde la capacidad de rastrearlo, rotarlo o revocarlo de forma fiable.

La causa raíz más común es el secreto hardcodeado: una credencial escrita directamente en el código fuente. Durante el desarrollo puede parecer práctico, pero se convierte en un riesgo permanente.

Así se ve una contraseña de base de datos hardcodeada en el código de una aplicación:

Cualquiera que tenga acceso de lectura a este archivo ahora tiene la contraseña de producción. Eso incluye a cada desarrollador, cada ejecutor de CI y cualquier persona que clone el repositorio más adelante.

Un peligro crítico de los secretos hardcodeados es el historial del control de versiones. Aunque elimine un secreto en un commit posterior, permanece para siempre en el historial de Git de cada clon.

Puede recuperar un secreto filtrado del historial en cualquier momento:

Por este motivo, eliminar un secreto del commit más reciente no remedia la filtración. Debe considerar que el secreto está comprometido y rotarlo de inmediato.

Cuando un repositorio con secretos hardcodeados se sube a un host público como GitHub, bots automatizados lo rastrean en cuestión de segundos o minutos.

Entre las consecuencias reales se incluyen:

• Facturas desorbitadas de la nube: claves de AWS filtradas utilizadas para poner en marcha flotas de minería de criptomonedas, lo que genera decenas de miles de dólares en cargos durante la noche.
• Filtraciones de datos: credenciales de bases de datos expuestas que provocan la exfiltración completa de los datos.
• Movimiento lateral: un token filtrado utilizado para avanzar hacia zonas más profundas de la infraestructura.

Los proveedores de servicios en la nube y GitHub ejecutan ahora escaneo de secretos que detecta automáticamente y, en ocasiones, revoca automáticamente las claves filtradas, pero no puede depender de esto como red de seguridad.

Los contenedores introducen una vía sutil de proliferación. Los secretos incorporados a una imagen durante la compilación se almacenan en capas de imagen y se envían a cada registro y host que extrae la imagen.

Un error común es copiar un archivo de secretos y luego eliminarlo en una capa posterior: el secreto sigue existiendo en la capa anterior:

Cualquiera que extraiga la imagen puede extraer esa capa y leer la clave. En su lugar, utilice secretos de compilación o inyección en tiempo de ejecución.

Pasar los secretos del código a las variables de entorno supone una mejora, pero no es una solución completa. Las variables de entorno resuelven el hardcoding, pero introducen nuevas vías de exposición:

• Se filtran en volcados de memoria y trazas de pila de errores
• Son visibles para otros procesos mediante /proc/<pid>/environ en Linux
• Las herramientas de depuración que imprimen todo el entorno pueden registrarlas
• Se almacenan en archivos .env de texto plano que pueden confirmarse por accidente

Las variables de entorno son aceptables para configuraciones de baja sensibilidad, pero los secretos de alto valor deben almacenarse en un gestor de secretos dedicado con control de acceso y auditoría.

La proliferación hace que la respuesta ante incidentes sea casi imposible. Cuando un secreto está en todas partes, dos preguntas quedan sin respuesta:

• ¿Dónde está? No puede rotar lo que no puede encontrar.
• ¿Quién lo utilizó? Sin registros de acceso centralizados, no puede determinar el alcance de una brecha.

El radio de impacto de una sola credencial filtrada crece con la proliferación. Una contraseña compartida y reutilizada en diez servicios implica que una sola filtración compromete los diez. La centralización y los secretos únicos y de corta duración reducen drásticamente este radio.

El punto más barato para detener una filtración es antes de que entre en el control de versiones. Los escáneres de secretos de pre-commit inspeccionan los cambios preparados y bloquean los commits que contienen patrones de credenciales.

Entre las herramientas populares de código abierto se incluyen gitleaks, trufflehog y detect-secrets. Un hook pre-commit típico se ejecuta localmente:

Combínelo con un escaneo en el servidor dentro de CI para que un desarrollador que omita el hook local siga siendo detectado.

Si un secreto llega a un lugar donde no debería estar, siga este orden. La rotación es lo primero; limpiar el historial es secundario, porque es posible que ya existan copias.

• 1. Rotar: revoque el secreto filtrado y emita uno nuevo de inmediato.
• 2. Auditar: revise los registros de acceso para detectar cualquier uso no autorizado durante el periodo de exposición.
• 3. Purgar: elimine el secreto del historial (por ejemplo, con git filter-repo) y haga force-push.
• 4. Prevenir: añada escaneos y mueva el secreto a un gestor para evitar que vuelva a ocurrir.

No se salte nunca el paso 1. Un secreto que ha llegado a una superficie pública está comprometido, sin excepción.

La proliferación empeora cuando los secretos tienen demasiados privilegios y se comparten en exceso. Aplicar el principio de mínimo privilegio limita los daños cuando se produce una filtración:

• Proporcione a cada servicio su propia credencial; nunca una compartida.
• Limite cada secreto a los permisos mínimos que necesita (solo lectura frente a administrador).
• Prefiera credenciales de corta duración que caduquen automáticamente.
• Separe los secretos por entorno: las claves de desarrollo nunca deben conceder acceso a producción.

Estos hábitos convierten una brecha catastrófica en un incidente contenido y recuperable.

Las herramientas por sí solas no resuelven la proliferación; la cultura sí. Una organización madura considera la gestión de secretos una disciplina continua:

• Regla predeterminada: ningún secreto debe estar nunca en el código fuente.
• Centralice el almacenamiento en un almacén seguro gestionado, con control de acceso y registros de auditoría.
• Automatice el escaneo en cada etapa: pre-commit, CI y registro.
• Convierta la rotación en una práctica rutinaria, no en algo exclusivo de las emergencias.
• Forme a cada ingeniero para reconocer y notificar exposiciones sin buscar culpables.

El objetivo es un sistema en el que sea difícil filtrar un secreto y fácil recuperarse de ello.

Compruebe si entiende por qué eliminar un secreto filtrado no es suficiente.

Ha aprendido por qué los secretos dispersos y hardcodeados son una de las debilidades de seguridad más comunes y dañinas.

• La proliferación de secretos es la propagación descontrolada de credenciales por el código, las canalizaciones, las imágenes y los chats.
• Los secretos hardcodeados persisten para siempre en el historial de Git; eliminarlos no remedia una filtración.
• Los repositorios públicos se rastrean en cuestión de minutos, lo que provoca facturas desorbitadas de la nube y brechas.
• Las variables de entorno y las capas de imagen son medios propensos a filtraciones, no un almacenamiento seguro.
• La proliferación aumenta el radio de impacto y hace imposibles la rotación y la respuesta ante incidentes.
• La solución: escanear antes del commit, rotar primero cuando se filtra un secreto, centralizarlo en un almacén seguro y aplicar el principio de mínimo privilegio.

A continuación, centralizamos correctamente los secretos mediante vaults y almacenes de secretos.