Un desarrollador presiona ".env.production" "temporalmente" para desbloquear a un colega. Repositorio privado: luego bifurcación del consultor, filtración en los registros de GitHub Actions o repositorio hecho público por error. Las claves de AWS y Stripe están activas en el historial de git para siempre. Revertir la confirmación no revoca lo que los rastreadores ya han indexado.
Los secretos de implementación (claves API, contraseñas de bases de datos, tokens de mensajería) no residen en el repositorio. Punto. La cuestión operativa es dónde viven y cómo giran sin pánico.
Reglas no negociables
Coloque .env* en .gitignore y verifique en la integración continua que una confirmación falla si se detecta un patrón secreto. Mantenga un .env.example sin valores: solo documentación de las claves requeridas. Planifique la rotación después de la salida, fuga sospechosa o fin del servicio. Aplicar privilegio mínimo: clave de AWS limitada a una acción, no a un administrador global. Nunca envíe secretos en URL, Sentry o tickets de seguimiento.
| Antipatrón | Reemplazo |
|---|---|
.env en git | Forjar secretos + archivo de servidor |
| Prod clave en la puesta en escena | Cuentas de prueba dedicadas |
| Secreto en la imagen de Docker | Inyección en tiempo de ejecución |
| Compartir claves por mensajería | Bóveda compartida del equipo |
Por entorno
En local, cada desarrollador mantiene un .env personal, que nunca se confirma. En integración continua, utilice secretos cifrados de GitHub o GitLab; inyectar en la implementación mediante SSH o API de plataforma. En producción del servidor, un archivo /var/www/.env con permisos reservados para la cuenta de implementación, o un archivo de entorno systemd fuera de la raíz web. En plataforma administrada, variables de entorno de panel cifradas con seguimiento de auditoría. Emparéjelo con proyecto pequeño de CI/CD sin registrar el entorno en modo detallado.
Detección proactiva
Escanee con gitleaks o trufflehog en precompromiso o CI. Habilite la detección de secretos de GitHub si el repositorio se vuelve público. Auditar trimestralmente quién tiene acceso a las claves de producción.
Rotación sin interrupción
Utilice claves API de activación dual cuando el proveedor lo permita (Stripe por ejemplo). Para la base: usuario secundario, alternancia de cadena de conexión, revocación del anterior. Documente el pedido: pruebe primero en preproducción.
La cumbre: el depósito privado no es una caja fuerte
Consulte Administración de claves KMS para cargas sensibles más allá de .env.
Decide y avanza sin puntos ciegos
Primero escanee el historial de git con gitleaks o equivalente. Revocar y rotar cualquier clave expuesta o cuestionable, no solo la última confirmación. Centralice los secretos de integración continua y mantenga un .env.example actualizado. Separe estrictamente las identificaciones de preproducción y producción. Forma el equipo: nunca guardes secretos en un ticket o chat. Compare los hosts de la plataforma con la gestión de secretos documentada a través del directorio.
Preguntas frecuentes
.env cometido por error?
Revocar y girar inmediatamente: deshacer el compromiso de git no es suficiente, el historial se mantiene en secreto.
¿Secretos en CI?
Secretos cifrados de la forja, nunca mostrados en los registros, ni siquiera durante la depuración.
¿La misma puesta en escena y producción de .env?
No: claves de prueba separadas y claves activas, cuentas en la nube separadas si es posible.
¿Se requiere bóveda?
No para un equipo pequeño; Los secretos de Forge más el servidor .env suelen ser suficientes para hasta diez secretos compartidos.
Ya no ocultar claves en el repositorio significa aceptar que git no es una bóveda y que la rotación es una característica, no un castigo.