Deja de enviar archivos .env por correo: una guía práctica de bóvedas cifradas
Cada equipo pequeño tiene una historia sobre cómo sus secretos terminaron donde no debían. Casi nunca es malicioso — es un ingeniero senior onboardeando a un junior a las 5pm un viernes, pegando el DATABASE_URL de producción en un DM 'solo por ahora'. 'Solo por ahora' se convierte en 'indexado para siempre por Slack'.
El DATABASE_URL de tu equipo está en los DMs de Slack de alguien. Tu STRIPE_SECRET_KEY vive en una página de Notion. Así se filtran los secretos. Aquí está la higiene que deberías haber tenido desde el día uno — y cómo las bóvedas cifradas la hacen indolora.
Cómo se filtran los secretos en equipos pequeños
Las cuatro rutas de filtración más comunes:
• DMs de Slack — onboarding, entregas rápidas. El índice de búsqueda los guarda para siempre. • Páginas de Notion/Confluence — alguien hizo una página 'dev setup' en 2022 con valores de producción. • Colecciones Postman en texto plano — compartidas vía workspace, incluyendo tokens activos. • Archivos .env commiteados — `git rm` los quita de HEAD pero viven en el historial.
Ninguno involucra a un insider malicioso. Todos son atajos de workflow que se vuelven artefactos permanentes.
El modelo de amenaza: quién realmente obtiene acceso
Antes de elegir una herramienta, nombra las amenazas:
• Un junior que deja la empresa y aún tiene su export de Slack en su laptop. • Un contratista que tuvo un día de acceso a tu Notion y guardó un respaldo Markdown. • Una laptop de desarrollador comprometida donde un infostealer absorbió todos los secretos en texto plano.
Las bóvedas cifradas manejan todos estos igual: el secreto nunca está en reposo en texto plano, así que un ciphertext exfiltrado es inútil sin la llave de la bóveda.
Cifrado en reposo: por qué AES-128-CBC vía Fernet
EnvVault usa Fernet (AES-128-CBC con HMAC-SHA256) para cifrado de secretos. No es el cipher suite más exótico, y ese es el punto. Fernet está estandarizado, ampliamente auditado e imposible de mal usar en formas que produzcan salida insegura.
Crítico: la bóveda usa un `ENVVAULT_ENCRYPTION_KEY` dedicado, no el secreto de firma JWT de la aplicación. Compartirlos es un error común: si un atacante falsifica un JWT, también descifra cada secreto.
Bóvedas por entorno y separación estructural
Una bóveda para 'todo' es la forma equivocada. Un secreto de producción tiene necesidades de acceso fundamentalmente distintas a un secreto de desarrollo.
Estructura tus bóvedas como:
• Producción — leída solo por senior on-call, log de auditoría en cada acceso. • Staging — leída por cualquier ingeniero, escrita solo por el lead. • Desarrollo — todos pueden leer y escribir.
La separación no es solo de permisos — es de radio de explosión.
Flujo de rotación sin bloquear usuarios
La capacidad operativa más importante que una bóveda necesita es rotación de llave sin romper la aplicación en ejecución. El procedimiento:
1. Generar una nueva llave. Agregarla a la bóveda como `current`. 2. Mantener la llave vieja como `legacy`. 3. Correr un pase de re-cifrado: para cada secreto, descifrar con `legacy`, cifrar con `current`. 4. Una vez completo, quitar `legacy`.
Con una ventana de doble llave, ninguna petición falla por una rotación.
Guía de producto
Uptime Monitoring
AlertsDock gives teams uptime monitoring for websites, APIs, TCP checks, DNS checks, SSL expiry, and fast alert routing without enterprise overhead.
Leer guíaPágina alternativa
Better Stack Alternative
Compare AlertsDock with Better Stack for teams that want a more focused monitoring product covering uptime, cron jobs, status pages, and webhooks.
Ver comparaciónMore articles
Changelogs generados por IA: convierte commits de Git en notas de versión automáticamente
Escribir notas de versión es la tarea que nadie quiere. DeployLog lee tus commits en cada push y genera changelogs limpios y legibles agrupados por tipo — no se requiere Anthropic, funciona con Groq, Gemini, Cloudflare, OpenRouter u Ollama autohospedado.
Core Web Vitals: qué monitorear y cómo corregir regresiones
Google posiciona sitios según el rendimiento real de los usuarios. LCP, FCP, CLS, TTFB — no son números abstractos, son asesinos de conversiones cuando se desvían. Así se monitorean continuamente y se atrapan regresiones antes de que lleguen a los usuarios.
Playbooks de incidente que se auto-ejecutan: de runbook a runtime
Escribir un runbook que nadie lee a las 3am es desperdicio. Escribir uno que se auto-arranca el instante en que un monitor cae y registra cada paso es un multiplicador de fuerza.