Muchos proyectos empiezan con una clave API en un archivo local y terminan con credenciales copiadas en CI, paneles de hosting, notas y logs. El riesgo no es solo dónde se guarda el secreto: importa su alcance, quién puede obtenerlo, cómo llega al proceso y cuánto se tarda en revocarlo. Un equipo pequeño puede controlar el ciclo sin montar un departamento de seguridad.
| Credencial | Limita el acceso a | Opción preferible |
|---|---|---|
| Base de datos | Una aplicación, base y operaciones necesarias | Identidad de workload o acceso temporal |
| Clave API externa | Una integración y endpoints mínimos | Clave restringida del proveedor |
| Despliegue CI | Repositorio, entorno y rol concretos | Federación OIDC y credencial temporal |
| Clave de firma | Servicio y propósito específicos | Firma protegida por KMS/HSM cuando sea viable |
Mantén un inventario sin valores secretos: identificador, responsable, consumidor, entorno, fecha de creación, última rotación, vencimiento y procedimiento urgente de revocación. Separa desarrollo, pruebas y producción; un job de test no debería heredar permisos de producción por comodidad.
Para el desarrollo local, usa un archivo ignorado y un ejemplo con nombres de variables pero sin valores. En producción, inyecta credenciales desde la plataforma o recupéralas mediante identidad autenticada en runtime. No las incluyas en imágenes, bundles frontend, logs de build, informes de errores ni URLs.
El enmascaramiento de CI es una protección visual de último recurso, no evita que un workflow pueda exfiltrar el valor. Revisa quién puede modificar workflows y entornos. Prefiere OIDC entre CI y la nube para no guardar claves duraderas en la configuración del repositorio.
Prepara una segunda credencial o un método con período de solapamiento. Crea la nueva, entrégala al consumidor, verifica la autenticación y luego revoca la anterior. Vigila los fallos y conserva una ventana limitada de rollback si el proveedor lo admite. Si no permite solapamiento, documenta el riesgo y ensaya el mantenimiento; no supongas que el cambio es atómico.
Rota de inmediato si sospechas exposición y aplica un calendario proporcional al riesgo. Sin inventario de consumidores ni comprobación de revocación, las credenciales antiguas pueden seguir activas para siempre.
Conoce el método para desactivar una clave, qué servicios fallarán y cómo emitir otra. Practica sin mostrar el valor real. Si aparece en un repositorio público, revoca primero: borrar el commit no elimina clones, cachés ni notificaciones. Después revisa accesos y logs, cambia credenciales dependientes y documenta cómo mejorar la detección.
Gestionar secretos consiste en diseñar el acceso, la entrega, la rotación y la revocación. Registra responsables y consumidores, separa entornos, usa identidades temporales cuando puedas, evita que los valores aparezcan en código y telemetría y prueba la sustitución antes de una emergencia. Un inventario pequeño y actualizado vale más que una bóveda llena de claves olvidadas.