Aprende a gestionar secretos de forma segura y evita la fuga de datos en tus aplicaciones. Descubre las mejores prácticas, herramientas como HashiCorp Vault y cómo proteger tus repositorios de GitHub. ¡No repitas el error de Uber!
En septiembre de 2022, un atacante utilizó ingeniería social para engañar a un empleado, eludir el MFA y acceder a la red interna de Uber. Aunque el incidente fue contenido, expuso prácticas heredadas como secretos en el código y controles insuficientes sobre accesos privilegiados, que hoy sirven como lección para toda la industria según confirman análisis del incidente de Uber.
En este artículo, explico cómo organizar correctamente el almacenamiento de secretos para evitar una fuga de datos, qué herramientas permiten automatizar los procesos y cómo integrar la gestión de secretos en el desarrollo de aplicaciones.
¿Qué son los secretos?
Los secretos son credenciales digitales confidenciales, como contraseñas, claves API, tokens o certificados, que otorgan acceso a sistemas, aplicaciones y datos. Su función es proteger recursos, cifrar información y definir permisos. Una gestión de secretos inadecuada es una de las principales causas de fugas de datos en las organizaciones.
En aplicaciones web, los secretos pueden ser:
- Contraseñas de usuario o generadas automáticamente.
- API keys, claves y otras credenciales para proteger claves API de aplicaciones, incluso dentro de contenedores.
- Claves SSH.
- Contraseñas de bases de datos.
- Contraseñas para microservicios.
- Claves privadas para sistemas de cifrado asimétrico.
Un secreto comprometido abre el acceso a datos cifrados o a la infraestructura y permite a los atacantes obtener el control sobre los sistemas y datos de la organización. Para proteger las aplicaciones, es necesario realizar un almacenamiento seguro de credenciales en un lugar protegido y entregarlos únicamente a los usuarios y servicios que los necesitan para su funcionamiento.
Principales Problemas en la Gestión de Secretos
La principal fuente de problemas con los secretos es su almacenamiento en el código.
Según análisis recientes, las fugas más comunes incluyen claves genéricas (sin patrones fijos), tokens de GitHub con permisos de escritura y credenciales de bases de datos, que representan una porción significativa de los secretos expuestos y siguen siendo explotables durante años si no se rotan.
La gran mayoría de las fugas ocurren a través de repositorios con un solo propietario.
Estas son algunas de las razones por las que las empresas tienen problemas con la gestión de secretos:
1. Desconocimiento sobre el manejo seguro de secretos
Con frecuencia, los desarrolladores prueban rápidamente variantes de algoritmos añadiendo contraseñas, claves de cifrado u otros secretos directamente en el código, scripts o configuraciones sin cifrado.
Estas vulnerabilidades en el código fuente pueden terminar en un repositorio público junto con los secretos de los recursos de producción de la empresa. Cuando esta parte de la aplicación comienza a funcionar, pasan a otra tarea y se olvidan de la solución temporal insegura.
Los secretos nunca deben almacenarse en texto plano. Las contraseñas deben protegerse mediante hashing fuerte, mientras que los tokens, API keys y credenciales de servicio deben almacenarse cifrados y entregarse dinámicamente en tiempo de ejecución, una práctica fundamental dentro del marco de OWASP Top 10.
Este ejemplo (en C#) aplica exclusivamente al almacenamiento seguro de contraseñas de usuarios finales. No debe utilizarse para API keys, tokens o credenciales de infraestructura, que requieren cifrado y gestión centralizada de secretos.
{
var hashedPassword = HashPassword(password);
await using var command = connection.CreateCommand();
command.CommandText = "INSERT INTO users (username, password) VALUES (@username, @password);";
command.Parameters.AddWithValue("username", username);
command.Parameters.AddWithValue("password", hashedPassword);
await command.ExecuteScalarAsync();
}
async Task<bool> VerifyPasswordAsync(string username, string password, SQLiteConnection connection)
{
await using var command = connection.CreateCommand();
command.CommandText = "SELECT password FROM users WHERE username = @username";
command.Parameters.AddWithValue("username", username);
var reader = await command.ExecuteReaderAsync();
if (!reader.Read())
return false;
var hashPassword = reader.GetString(0);
return BCrypt.Net.BCrypt.Verify(password, hashPassword);
}
string HashPassword(string password)
{
var salt = BCrypt.Net.BCrypt.GenerateSalt();
var hashedPassword = BCrypt.Net.BCrypt.HashPassword(password, salt);
return hashedPassword;
}2. Falta de una política y sistema centralizado
Si en una empresa no existe una política común de gestión de secretos ni un sistema centralizado para su almacenamiento, cada departamento o incluso cada empleado puede desarrollar sus propias formas de manejarlos. Esto es inconveniente: si otros equipos o departamentos necesitan acceso urgente a algún secreto, pueden tardar mucho tiempo en encontrar al responsable.
Además, la falta de un enfoque unificado a menudo conduce al almacenamiento de secretos en lugares inseguros y a un manejo incorrecto de los mismos. Por ejemplo, los desarrolladores pueden guardar secretos en repositorios personales durante la depuración del código o utilizar sus propios métodos para acceder a los recursos de la empresa. Como resultado, es difícil determinar dónde se almacenan exactamente los secretos, quién tiene acceso a ellos y cómo se utilizan.
3. Secretos almacenados en texto plano en el código
Los desarrolladores necesitan lanzar actualizaciones rápidamente, por lo que a menudo no tienen tiempo para procesar grandes volúmenes de información confidencial. Aprenden superficialmente nuevas tecnologías y métodos de seguridad y, para acelerar el proceso de desarrollo, añaden credenciales y otros secretos en el código, olvidando eliminarlos antes de guardarlos en el repositorio.
Eliminar los secretos del código y volver a guardar los cambios en el repositorio no soluciona el problema, ya que el historial de cambios en plataformas como GitHub puede conservar estos datos. Con frecuencia, esta es la causa principal de las fugas.
Es posible eliminar una clave secreta y otros datos del repositorio, reescribir su historial y eliminar el archivo de commits anteriores. Sin embargo, limpiar el historial de versiones es peligroso: si la aplicación comienza a fallar, será difícil encontrar una forma de revertir a una versión anterior.
4. Ausencia de rotación regular de claves
El tiempo de vida de las claves, tokens y cualquier otro secreto debe ser mínimo. Una vez que expira su período de validez, el secreto debe ser eliminado automáticamente y reemplazado por uno nuevo. Si los secretos no se cambian o se hace con poca frecuencia, existe el riesgo de que puedan ser explotados por atacantes. La rotación de claves es un pilar fundamental de la seguridad.
5. Automatización insuficiente del proceso
Gestionar los secretos manualmente es complejo: los desarrolladores pueden olvidar eliminar un token obsoleto, dejar accidentalmente una clave en el código o configurar incorrectamente los accesos.
Al trabajar con microservicios, donde los secretos se crean y transfieren frecuentemente entre contenedores, la falta de automatización conduce al caos, ya que los equipos se centran primero en la funcionalidad y no en la seguridad.
Estos problemas son especialmente comunes en entornos modernos con Docker, Kubernetes y pipelines de CI/CD, donde los secretos se crean, rotan y consumen constantemente, un desafío clave en DevSecOps.
Otro canal potencial para las fugas son las conversaciones en aplicaciones de mensajería. En muchos casos, a los desarrolladores les resulta más fácil enviar un secreto o un enlace público a este en un chat que transferirlo de forma segura.
6. Permisos de acceso excesivos
Uno de los problemas más comunes es que los secretos otorgan acceso a todo el sistema, en lugar de a componentes o servicios específicos. Por ejemplo, un token utilizado para acceder a una API con permisos de administrador puede ser comprometido y utilizado para realizar cualquier otra operación. La compromiso de tokens de desarrolladores ya ha llevado a que atacantes suban versiones maliciosas de paquetes populares a PyPi, suplantando los originales.
Principales escenarios de ataque a los almacenes de secretos
Los atacantes emplean diversos métodos para atacar los almacenes de secretos: roban claves de acceso, explotan vulnerabilidades de la infraestructura o aprovechan errores en las configuraciones de seguridad.
Robo de claves de acceso
Es el vector de ataque más popular. Los atacantes escanean sistemáticamente repositorios públicos para identificar secretos dejados por los desarrolladores en el código fuente. Ni siquiera los repositorios privados garantizan la seguridad si existe la posibilidad de acceder al historial de commits.
Explotación de vulnerabilidades de la infraestructura
Los propios almacenes de secretos pueden ser objeto de ataques. Una configuración incorrecta del almacén puede permitir a un atacante acceder a los secretos. Por ejemplo, esto puede ocurrir si no se han definido restricciones en las listas de control de acceso o si se han expuesto accidentalmente tokens privilegiados en objetos pod de Kubernetes. Las vulnerabilidades en las configuraciones de los almacenes o los errores en las actualizaciones pueden proporcionar acceso directo a toda la base de datos de secretos.
Errores en las configuraciones de seguridad
Permisos de acceso excesivos, falta de segmentación por roles y otras deficiencias en las políticas de IAM permiten a los usuarios ver secretos que no necesitan. Una configuración incorrecta de las políticas de red puede hacer que el almacén de secretos sea accesible desde una red externa.
Ataques por configuraciones inseguras
Los permisos de acceso excesivos permiten que usuarios o servicios accedan a secretos que no les corresponden. Es mejor seguir el principio de privilegios mínimos y otorgar acceso solo a las acciones que son estrictamente necesarias.
Otro problema común son los archivos de configuración accesibles públicamente. Si almacenas secretos en archivos .env o YAML, corres el riesgo de añadirlos accidentalmente a los repositorios o dejarlos en servidores de acceso público, como los buckets de S3. Si un atacante obtiene acceso a estos datos a través de un bucket S3 público, podría extraer credenciales de bases de datos o APIs.
Para enviar a un repositorio, lo ideal es preparar un archivo de plantilla .env.example con marcadores de posición para los datos confidenciales. Al mismo tiempo, el archivo .env real debe ser excluido del control de versiones mediante .gitignore. Esto garantiza que cada desarrollador pueda crear un archivo .env con sus propias configuraciones sin exponer información sensible a otros.
Ejemplo de uso de un archivo .env con Python:
# Crea un archivo .env en el directorio raíz de tu proyecto
# y añade los secretos en formato "CLAVE=VALOR"
from dotenv import load_dotenv
import os
# Carga las variables de entorno desde el archivo .env
load_dotenv()
# Obtiene el valor del secreto desde la variable de entorno
SECRET_KEY = os.getenv("SECRET_KEY")
# Usa el secreto en la aplicación
print("Clave secreta:", SECRET_KEY)Cómo usar el archivo .gitignore:
Crea un archivo .gitignore para tu repositorio:
touch .gitignoreAbre el archivo .gitignore en un editor de texto y añade las entradas para los archivos o directorios que contienen contraseñas y claves de API. Por ejemplo:
# archivo que contiene secretos
api_keys.txt
# directorio con secretos
keys/
# se permite el uso de wildcards
*key
# Ignorar archivos de variables de entorno
.env*Guarda los cambios en el archivo .gitignore y súbelo al repositorio:
git add .gitignore
git commit -m "Add .gitignore to exclude sensitive information"
git push origin mainLa ausencia de restricciones de red aumenta los riesgos. Si el almacén de secretos es accesible desde una red externa y no está protegido por un firewall, un atacante podría infiltrarse a través de vulnerabilidades conocidas.
Para proteger el almacén de secretos de tales ataques, es necesario configurar correctamente las políticas de acceso, cifrar los datos en las configuraciones, utilizar tokens temporales y realizar auditorías regulares de la infraestructura.
Estadísticas de Fugas en Repositorios GitHub
El análisis de repositorios públicos en GitHub confirma la fuga regular de secretos. Durante seis meses, los expertos escanearon miles de millones de archivos, lo que representa el 13% de todos los repositorios de GitHub, y descubrieron que las fugas afectan a más de cien mil repositorios.
Según el reporte State of Secrets Sprawl 2025 de GitGuardian, basado en el análisis de 1.4 mil millones de commits, la exposición de secretos en GitHub sigue creciendo año tras año y la mayoría de los secretos filtrados continúan activos durante años, lo que subraya la importancia de una buena seguridad en repositorios GitHub.
Cómo Realizar una Gestión de Secretos Segura
A continuación, mis recomendaciones de secrets management best practices para una gestión de secretos segura:
Aplica el principio de privilegios mínimos
Cada usuario, proceso o servicio debe tener acceso únicamente a los secretos necesarios para realizar sus tareas. Todos los permisos y accesos “extra” deben ser eliminados.
Implementa la rotación regular de secretos
Esto reduce la amenaza de acceso no autorizado a los recursos internos de la empresa. Intenta no utilizar contraseñas o claves estáticas. La frecuencia de rotación de claves es siempre individual, por lo que es importante encontrar un equilibrio entre los requisitos de seguridad y la comodidad de los empleados.
Usa herramientas para la gestión automatizada
La automatización de la gestión de secretos reduce el riesgo de errores humanos, aumenta la seguridad, simplifica el cumplimiento de estándares, proporciona una integración fluida con herramientas de CI/CD y minimiza la intervención de los desarrolladores en los procesos de seguridad.
Las herramientas de gestión de secretos más populares y recomendadas son: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Cloud Secret Manager, Infisical (open-source y en fuerte crecimiento), Doppler, Akeyless, CyberArk Conjur y 1Password Secrets Automation. Elige según tu stack (cloud-native, on-prem o híbrido), pero prioriza las que soporten rotación automática, auditoría y least-privilege por defecto.
Registra y analiza el acceso
Utiliza sistemas SIEM para detectar actividades sospechosas, como múltiples intentos de acceso o el uso de secretos en lugares inesperados.
Evita registrar secretos en los logs
Es mejor no guardar secretos en los registros; configura los logs para que las contraseñas, claves de API u otros datos personales no queden registrados. Aplica enmascaramiento, por ejemplo, para números de tarjetas, y tokenización conservando la estructura.
Fomenta una cultura de seguridad en el desarrollo
Una cultura de seguridad es la defensa más fuerte. Realiza formaciones periódicas para que los equipos de producto aprendan a prevenir vulnerabilidades y a escribir código seguro desde el principio.
Preguntas Frecuentes (FAQ)
¿Es seguro usar archivos .env para almacenar secretos?
No es inherentemente seguro, pero es una práctica común para desarrollo local. La clave es NUNCA subir el archivo .env a un repositorio público o privado. Utiliza siempre un archivo .gitignore para excluirlo. En producción, usar archivos .env no es aceptable.
¿Qué es la rotación de claves y por qué es importante?
La rotación de claves es el proceso de reemplazar periódicamente las claves criptográficas, contraseñas o tokens. Es crucial porque limita el tiempo que un atacante tiene para usar una clave robada. Si una clave se compromete pero se rota (cambia) rápidamente, el acceso no autorizado se revoca automáticamente.
¿Cómo puedo escanear mi repositorio de GitHub en busca de secretos expuestos?
Existen varias herramientas automatizadas para esto. GitHub tiene su propio “Secret Scanning” para repositorios públicos (y para privados en planes avanzados). Herramientas de terceros como GitGuardian o TruffleHog también son muy efectivas.
Si esta guía te ha resultado útil, suscríbete a nuestro boletín semanal para recibir más análisis y consejos prácticos directamente en tu bandeja de entrada. ¡Mantente seguro!
