Los equipos pequeños se mueven rápido, publican a menudo y manejan un número sorprendente de secretos. API keys, contraseñas de bases de datos, claves SSH, claves de firma JWT, secretos de clientes OAuth y claves de encriptación mantienen todo funcionando. También atraen a los atacantes. Los informes de brechas públicas muestran consistentemente que las credenciales robadas impulsan una gran parte de las intrusiones, por lo que un enfoque ligero y disciplinado para la gestión de claves vale la pena rápidamente para las organizaciones pequeñas. Si has estado posponiendo un programa formal porque suena a "gran empresa", esta guía te ofrece un manual práctico adaptado a equipos de 5 a 50 personas.
Qué cuenta como una "clave secreta" y por qué importa
No todos los secretos son iguales. Clasifícalos por radio de explosión y por cómo se usan. Esto te ayuda a establecer valores predeterminados sensatos para el almacenamiento, la distribución y la rotación.
| Tipo de secreto | Dueño típico | Radio de explosión si se filtra | Almacenamiento recomendado | Entrega a una persona | Mentalidad base de rotación |
|---|---|---|---|---|---|
| API keys para terceros (Stripe, SendGrid) | Equipo de App | Abuso del servicio, exposición de datos | Gestor de secretos en la nube o gestor de contraseñas de equipo para uso humano | Enlace de un solo uso que se autodestruye al destinatario | Rotar al comprometerse, revisar trimestralmente, preferir claves con alcance limitado |
| Contraseñas de bases de datos | Plataforma o DevOps | Exposición y manipulación de datos | Gestor de secretos, nunca en código | Enlace de un solo uso que se autodestruye, luego rotar tras la entrega | Rotar en cambios de rol, al menos dos veces al año, imponer únicas por entorno |
| Claves privadas SSH | Ingenieros individuales | Movimiento lateral, control total del host | Hardware o gestor de contraseñas con frase de contraseña fuerte | Nunca enviar claves privadas, aprovisionar acceso vía authorized_keys o SSO | Reemplazar al partir inmediatamente, imponer claves por usuario |
| Claves de firma JWT o claves privadas TLS | Seguridad o plataforma | Toma de control de cuentas a escala, pérdida de integridad | KMS o HSM, con administradores restringidos | Sin entrega humana, automatizar despliegue vía KMS | Rotaciones planificadas, probadas, con rollback, programar al menos anualmente |
| Secretos de cliente OAuth, secretos de firma de webhooks | Equipo de App | Suplantación, fraude | Gestor de secretos | Enlace de un solo uso que se autodestruye durante la configuración | Rotar cuando cambian los roles o el tercero se compromete |
| Códigos de recuperación MFA y semillas TOTP | TI o RRHH durante onboarding | Toma de control de cuentas | Gestor de contraseñas una vez entregado, sin correo persistente | Enlace de un solo uso que se autodestruye, instruir almacenamiento en bóveda del usuario | Entrega de un solo uso, luego destruir, tratar como contraseñas |
Referencias que vale la pena guardar: La guía de gestión de claves de NIST es el estándar de oro para controles de ciclo de vida, rotación y roles. Consulta la Recomendación para la Gestión de Claves Parte 1 de NIST y la Hoja de Trucos de Gestión de Secretos de OWASP para pautas amigables para desarrolladores.
- NIST SP 800-57 Parte 1: Recomendación para la Gestión de Claves, Guía General: https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final
- Hoja de Trucos de Gestión de Secretos de OWASP: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
- Resumen de Verizon DBIR: https://www.verizon.com/business/resources/reports/dbir/
Principios básicos que mantienen seguros a los equipos pequeños
- Mínimo privilegio y alcance: crea claves que puedan hacer lo mínimo, para el conjunto más pequeño de recursos y entornos. Prefiere credenciales por servicio y por entorno.
- Una sola fuente de verdad: almacena secretos en un gestor dedicado. Evita dispersarlos en documentos, tickets, wikis y chats.
- Listo para rotación por diseño: elige proveedores y patrones que hagan la rotación indolora. Si la rotación es dolorosa, no sucederá.
- Distribución efímera: nunca envíes secretos en texto plano por correo o chat. Usa un enlace de un solo uso, que se autodestruye y con encriptación del lado del cliente para que nada persista en los registros.
- Auditar sin acumular: mantén evidencia de que un secreto fue entregado o rotado, pero no retengas el secreto mismo en tus sistemas.
- Automatizar detección y revocación: escaneo de secretos en repositorios y CI, alertas sobre fugas y un manual de rotación claro.
Si necesitas profundizar en el modelo de privacidad detrás de la distribución efímera, consulta Encriptación del lado del cliente vs. del lado del servidor y nuestra explicación sencilla de AES 256.
- Encriptación del lado del cliente vs. del lado del servidor: https://nurbak.com/es/blog/client-side-vs-server-side-encryption-zero-knowledge/
- Encriptación AES 256 explicada para no ingenieros: https://nurbak.com/es/blog/aes-256-encryption-explained-for-non-engineers/
El programa de gestión de claves mínimo viable, en 30 días
Día 1 a 5, inventario y dueños
- Construye una hoja de cálculo o documento único que liste cada secreto. Captura nombre, sistema, entorno, alcance, dueño, dónde se almacena, fecha de última rotación, cómo se entrega y cómo revocarlo.
- Asigna un dueño humano para cada secreto. Los dueños aprueban el acceso, inician la rotación y manejan la revocación.
Día 6 a 10, consolidar almacenamiento
- Elige un hogar de almacenamiento. Para secretos de máquinas o aplicaciones, usa el gestor de secretos de tu proveedor de nube o una bóveda gestionada. Para ítems de credenciales humanas, usa un gestor de contraseñas empresarial.
- Elimina texto plano de wikis, tickets e historial de chat. Reemplaza con punteros al gestor de secretos.
Día 11 a 15, establecer bases de rotación
- Decide qué parece "bueno" por clase de secreto. Bases de ejemplo: API keys revisadas trimestralmente, contraseñas de bases de datos dos veces al año, claves de firma JWT anualmente con pruebas previas.
- Documenta un manual de rotación que los ingenieros puedan seguir sin adivinar.
Día 16 a 20, hacer la distribución efímera
- Estandariza las entregas de secretos con enlaces de un solo uso que se autodestruyen y encriptan en el navegador. Esto elimina residuos de correo y chat y apoya la minimización de datos.
- Con Nurbak, pegas el secreto, configuras acceso de un solo uso y envías el enlace. El contenido se encripta localmente usando AES-256 y el servidor almacena solo texto cifrado. Puedes auditar que el enlace fue accedido sin almacenar el secreto mismo.
- Envía contexto por un canal diferente. Por ejemplo, envía el enlace por chat y la pista de la contraseña por SMS, o viceversa.
Día 21 a 25, automatizar detección y respuesta
- Activa el escaneo de secretos en tus repositorios y CI. GitHub proporciona detección integrada. Establece alertas a un canal compartido.
- Escribe un breve manual de incidentes: si un secreto aparece en un repositorio o ticket, quién lo rota, cómo confirmas que la nueva versión está activa y cómo invalidas la filtrada.
Día 26 a 30, medir y mejorar
- Rastrea tres métricas: porcentaje de secretos con un dueño, tiempo medio para rotar después de un evento de fuga y número de secretos fuera del gestor.
- Revisa una muestra de entregas para probar que se usó el intercambio efímero.
Referencias útiles para controles y escaneo
- NIST SP 800-53 Rev. 5, SC-12 y SC-13 para establecimiento y gestión de claves: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
- Escaneo de Secretos de GitHub: https://docs.github.com/es/code-security/secret-scanning/about-secret-scanning
Procedimientos operativos estándar que puedes copiar
Incorporar a un nuevo desarrollador sin dejar rastros
- Crea API keys por entorno y con mínimo privilegio para los servicios que necesitan.
- Almacena claves en tu gestor de secretos y otorga acceso al desarrollador por grupo.
- Para ítems de entrega inicial que deben escribirse, como una contraseña temporal de base de datos o códigos de recuperación, envía vía un enlace de un solo uso que se autodestruye. Nurbak usa encriptación del lado del cliente y acceso de una sola vez para prevenir que logs o copias de seguridad contengan el secreto.
- Confirma recepción, luego rota o revoca cualquier secreto temporal de onboarding.
Para guía detallada de envío, ver Cómo compartir un secreto con enlaces de un solo uso y La forma más segura de compartir una API key.
- Cómo compartir un secreto con enlaces de un solo uso: https://nurbak.com/es/blog/how-to-share-secret-one-time-links/
- La forma más segura de compartir una API key: https://nurbak.com/es/blog/the-safest-way-to-share-an-api-key/
Rotar una contraseña de base de datos con mínimo tiempo de inactividad
- Crea un nuevo usuario o contraseña en la base de datos con los mismos privilegios que el anterior.
- Actualiza la configuración de la aplicación para usar la nueva credencial a través de tu gestor de secretos, luego despliega.
- Verifica que las conexiones tengan éxito con la nueva credencial.
- Revoca el usuario o contraseña anterior.
- Registra la rotación en tu inventario y crea un ticket para trazabilidad.
Dar acceso temporal a un proveedor sin el riesgo zombi
- Crea una credencial con alcance limitado y tiempo definido específica para el proveedor.
- Compártela vía un enlace de un solo uso que se autodestruye. Pide al proveedor confirmar acceso en un canal separado.
- Monitorea el uso y revoca inmediatamente al final del compromiso.
Lista de verificación de endurecimiento para equipos pequeños
- Secretos únicos por servicio y por entorno. Nunca reutilices la misma clave entre staging y producción.
- Sin cuentas humanas compartidas. Usa identidades individuales con SSO donde sea posible.
- Denegar secretos en repositorios de código. Añade hooks de pre-commit y verificaciones CI para fallar builds al detectar secretos.
- Proteger logs de build. Redacta variables de entorno y rota credenciales usadas por runners de CI.
- Eliminar capturas de pantalla y tickets con secretos. Reemplaza con enlaces de un solo uso y elimina el contenido anterior.
- Preferir encriptación autenticada para tu propia criptografía, por ejemplo AES con modo GCM, y nunca crees tus propias primitivas. Ver NIST SP 800-38D para detalles si implementas criptografía tú mismo.
- Deshabilitar previsualizaciones de enlaces en canales que puedan obtener enlaces de un solo uso automáticamente, o comparte enlaces en bloques de código. Prueba tus herramientas de colaboración para estar seguro.
Cumplimiento sin la burocracia
Puedes satisfacer las expectativas comunes de compradores y auditores mostrando que minimizas la retención, encriptas de extremo a extremo, rotas predeciblemente y mantienes evidencia básica de tu proceso. El enfoque en esta guía se mapea limpiamente a principios de SOC 2, ISO 27001 y GDPR como limitación de almacenamiento y minimización de datos. La transmisión efímera y de conocimiento cero es un control fuerte porque elimina datos de sistemas persistentes por defecto, así que hay poco que borrar después.
Plantilla de política que puedes adaptar hoy
- Los secretos nunca deben enviarse en texto plano por correo, tickets o chat. Usa enlaces de un solo uso que se autodestruyen para todas las transferencias de humano a humano.
- Todos los secretos deben tener un dueño, ser almacenados en un gestor de secretos aprobado y tener pasos definidos de rotación y revocación.
- Las claves deben tener el alcance de permisos y entornos mínimos requeridos.
- La respuesta a incidentes requiere rotación inmediata de cualquier secreto encontrado en código, logs, docs o tickets, con confirmación de que el nuevo secreto está en uso.
- Los usuarios que parten activan la revocación de sus credenciales y cualquier credencial que crearon para otros.
Errores comunes a evitar
- Copiar secretos en wikis o runbooks por conveniencia. Reemplaza con punteros a tu gestor y enlaces de un solo uso para distribución.
- Reutilizar la misma API key en múltiples servicios. El compromiso en un lugar se convierte en compromiso en todas partes.
- Hardcodear secretos en código o infraestructura como código. Usa referencias a tu gestor de secretos en tiempo de ejecución.
- Tratar la rotación como un evento especial. Hazlo rutinario y programable para que sea rápido.
- Asumir que los gestores de contraseñas resuelven todo. Son geniales para secretos humanos pero no reemplazan a KMS o gestores de secretos para aplicaciones.
Cómo encaja Nurbak en un programa de equipo pequeño
Nurbak resuelve una parte específica y dolorosa de la gestión de claves, la entrega de humano a humano. Usa encriptación AES-256 del lado del cliente y un diseño de conocimiento cero para que tu secreto nunca exista en el servidor en texto plano. Creas un enlace de un solo uso que se autodestruye, lo entregas al destinatario y el contenido se elimina permanentemente después de que lo leen. Los logs de acceso de auditoría amigables para el administrador te dan prueba de que el enlace fue abierto, sin almacenar el secreto mismo. Esto reduce datos residuales en correo, chat, tickets y copias de seguridad, y se alinea con los principios de limitación de almacenamiento y minimización.
Si ya usas un gestor de secretos para almacenamiento, Nurbak lo complementa haciendo la distribución efímera, de corta vida y auditable, que es exactamente lo que buscan la mayoría de las auditorías y revisiones de seguridad.
Preguntas frecuentes
¿Necesitamos un HSM completo para estar seguros? La mayoría de los equipos pequeños no. Usa tu KMS en la nube o un gestor de secretos gestionado para secretos de aplicación y claves de firma. Los HSM son geniales para necesidades de alta seguridad, pero añaden costo y complejidad. Empieza con KMS y manuales de rotación claros.
¿Con qué frecuencia debemos rotar claves? Usa una cadencia basada en riesgo. Secretos de alto valor o amplio alcance merecen rotaciones más frecuentes y pruebas previas exhaustivas. Muchos equipos revisan API keys trimestralmente, contraseñas de bases de datos al menos dos veces al año y claves de firma anualmente con un ensayo. Rota inmediatamente ante fugas o cambios de rol.
¿Cuál es la forma más segura de entregar una contraseña a un nuevo empleado? Usa un enlace de un solo uso que se autodestruye con encriptación del lado del cliente, luego confirma recepción en un canal separado. Pídeles que lo almacenen en el gestor de contraseñas del equipo y rota cualquier credencial temporal después.
¿Cómo prevenimos que los secretos entren a git? Habilita hooks de pre-commit y escaneo de secretos en CI, bloquea merges con hallazgos y educa a los desarrolladores de que las variables de entorno y referencias a secretos deben venir de tu gestor en tiempo de ejecución. Si un secreto se desliza, rótalo inmediatamente y elimínalo del historial.
¿Podemos auditar entregas sin almacenar secretos? Sí. Herramientas como Nurbak proporcionan logs de acceso de auditoría que muestran cuándo se accedió a un enlace, y el contenido mismo nunca se almacena en texto plano porque la encriptación ocurre en el navegador.
¿Qué pasa con las previsualizaciones de enlaces que pueden consumir enlaces de un solo uso? Deshabilita previsualizaciones en canales usados para entrega de secretos o envía el enlace en un formato que prevenga la obtención automática. También puedes coordinar con el destinatario para abrir el enlace solo después de que lo envíes y confirmes ventanas de tiempo.
Haz que compartir secretos sea la parte más segura de tu flujo de trabajo
Deja de permitir que el correo o el chat se conviertan en un archivo permanente de tus claves más sensibles. Crea un enlace de conocimiento cero y un solo uso con Nurbak, compártelo y ten confianza de que no queda nada que limpiar.
Empieza en minutos: https://nurbak.com/es/