Skip to content
NeuralSkills
Seguridad

Gestor de Secretos

Gestiona secretos, API keys y credenciales de forma segura — variables de entorno, vaults, estrategias de rotacion y prevencion de fugas.

Principiante Gratis Publicado: 15 de abril de 2026
Herramientas Compatibles claude-codechatgptgeminicopilotcursorwindsurfuniversal

El Problema

Los secretos terminan en los lugares equivocados constantemente — API keys hardcodeadas en el codigo fuente, contrasenas de base de datos en archivos docker-compose commiteados a Git, credenciales de AWS en archivos .env que no estan en gitignore. Una vez que un secreto esta en el historial de versiones, esta comprometido para siempre, incluso si lo borras en el siguiente commit. Las credenciales filtradas son la causa numero uno de brechas de seguridad en la nube.

El Prompt

Eres un especialista en gestion de secretos. Audita mi proyecto en busca de exposicion de credenciales y disena una estrategia segura de gestion de secretos.

TIPO DE PROYECTO: [ej. app Node.js, deployment Docker, pipeline CI/CD, monorepo]
DEPLOYMENT: [ej. Vercel, AWS, Docker, Netlify, self-hosted]
ALMACENAMIENTO ACTUAL DE SECRETOS: [ej. archivos .env, hardcoded, Docker env, variables CI]

TAREA 1 — AUDITORIA: Escanear los siguientes archivos en busca de secretos expuestos:
[pega: .env, .env.example, docker-compose.yml, archivos de config, configs CI/CD]

Buscar:
- API keys, tokens, contrasenas, connection strings hardcodeados
- Secretos en archivos commiteados (no en .gitignore)
- Secretos en imagenes Docker o logs de build
- Credenciales por defecto que nunca se cambiaron
- Permisos de API key demasiado amplios

TAREA 2 — DISENO: Crear estrategia de gestion de secretos incluyendo:
1. **Almacenamiento**: Donde debe vivir cada tipo de secreto (env vars, vault, CI secrets)
2. **Acceso**: Acceso de minimo privilegio por entorno (dev, staging, prod)
3. **Rotacion**: Calendario de rotacion y rotacion automatizada donde sea posible
4. **Deteccion**: Hooks de pre-commit y checks de CI para detectar fugas
5. **Template .gitignore**: Template completo para mi tipo de proyecto
6. **.env.example**: Template seguro con valores placeholder

Proporcionar pasos de implementacion para mi plataforma de deployment especifica.

Ejemplo de Salida

## Auditoria de Secretos: 3 exposiciones encontradas

### CRITICA: Contrasena de base de datos en docker-compose.yml (commiteado)
Linea 12: POSTGRES_PASSWORD=prodpass123
Este archivo esta trackeado en Git. La contrasena esta en el historial de versiones permanentemente.
Solucion: Mover a .env (gitignored), referenciar como ${POSTGRES_PASSWORD} en compose.

### Estrategia de Gestion de Secretos:
| Tipo de Secreto | Dev | Staging | Produccion |
|-----------------|-----|---------|------------|
| Contrasena DB | .env.local | Vercel env vars | Vault + rotacion |
| API keys | .env.local | CI secrets | Vault + scoped |
| JWT secret | .env.local | CI secrets | Vault + rotacion 90 dias |

Cuando Usar

Ejecutar la auditoria de secretos al inicio de cada proyecto, despues de incorporar nuevos desarrolladores y antes de hacer open-source cualquier repositorio. Disenar la estrategia de gestion durante el setup inicial del proyecto. Revisar cuando agregues nuevas integraciones de terceros, cambies plataformas de deployment o despues de cualquier incidente de seguridad con exposicion de credenciales.

Tips Pro

  • Escanea el historial de Git — usa git log -p | grep -i "password\|secret\|api_key" o herramientas como truffleHog. Eliminar del HEAD no es suficiente.
  • Usa .env.local para secretos reales — commitea .env.example con valores placeholder y agrega .env.local al .gitignore. Este patron funciona en todos los frameworks.
  • Rota inmediatamente despues de la exposicion — si un secreto estuvo alguna vez en un commit publico, rotalo en minutos, no dias. Los bots escanean GitHub en tiempo real.
  • Alcance minimo para API keys — nunca uses una API key root/admin cuando una key scoped de solo lectura seria suficiente. Crea keys separadas por servicio y entorno.