Secretos y credenciales de clientes: accesos seguros sin compartir contraseñas
Publicado el 2026-11-14 por frfrand
Key management, rotation, permissions, and revocation across teams and projects.
El problema no es recordar contraseñas: es controlar quién accede a qué
Una agencia o equipo técnico suele administrar claves SSH, tokens de API, accesos DNS, credenciales de base de datos y cuentas de pago de clientes diferentes. Compartir todo por chat o reutilizar una contraseña de administrador convierte un error aislado en un problema para varios proyectos.
Un inventario por cliente y por finalidad
Registra cada secreto con su responsable, sistema, propósito, fecha de creación, fecha de revisión y procedimiento de revocación. No copies su valor al inventario: guarda ese valor en una bóveda con cifrado, auditoría y control de acceso.
La distinción esencial es entre identidad humana y credencial de servicio. Una persona debe tener una cuenta nominativa que pueda desactivarse; una integración debe tener su propia identidad técnica, permisos mínimos y ciclo de vida independiente. Evita cuentas compartidas de administrador cuando el proveedor permita delegación.
Principio de mínimo privilegio
Un técnico que mantiene una web no necesita acceso al facturador ni a todos los servidores de la empresa. Un pipeline que despliega una API no necesita permisos para eliminar la base de datos. Segmenta permisos por entorno, cliente y tarea; exige MFA donde sea posible y revisa el acceso al terminar cada proyecto.
Para despliegues automatizados, prioriza identidades de duración corta o federación compatible con OIDC. Si utilizas secretos almacenados en GitHub Actions, comprueba el alcance de cada entorno y qué workflows pueden ejecutarlos. Nunca coloques claves en un repositorio, en el frontend, en una imagen Docker publicada o en logs.
Proceso de alta, rotación y salida
Cuando un colaborador entra, solicita permisos nominativos y documenta su alcance. Cuando cambia una clave, identifica primero los consumidores, crea la nueva, actualiza las dependencias, valida su funcionamiento y revoca la anterior. Cuando termina la colaboración, deshabilita identidades, tokens, SSH y sesiones activas según el sistema.
La rotación no es simplemente cambiar el texto en un fichero. Un secreto de cifrado o firma puede afectar sesiones o datos históricos. Diseña compatibilidad temporal cuando sea necesario y documenta el plan de recuperación.
Respuesta ante una filtración
Trata una credencial expuesta como potencialmente comprometida. Revócala, investiga dónde se utilizó, revisa logs y permisos, reemplaza secretos derivados si corresponde y analiza el alcance. Eliminarla del último commit no la borra del historial ni garantiza que terceros no la hayan copiado.
Modelo mínimo para una pequeña agencia
Utiliza una bóveda corporativa con carpetas por cliente, grupos de permisos, MFA, auditoría de accesos y recuperación. Reserva las credenciales de emergencia bajo procedimientos controlados. En entornos Linux, combina cuentas no privilegiadas, llaves SSH por persona y políticas de sudo ajustadas.
Puedes complementar esta guía con GitHub Actions secrets y cómo evitar subir secretos a GitHub. ArduMaker ofrece infraestructura y herramientas de despliegue; evalúa las capacidades de permisos necesarias antes de centralizar credenciales de clientes.
Preguntas frecuentes
### ¿Puedo guardar claves en variables de entorno? Son útiles para inyección de configuración, pero no sustituyen un almacén de secretos ni garantizan protección frente a procesos privilegiados. ### ¿Cada cliente necesita su propia clave? Sí, siempre que la integración lo permita, para limitar incidentes. ### ¿Cada cuánto rotarlas? Según sensibilidad, duración, proveedor y exposición; rota de inmediato ante sospecha de filtración.
Referencia técnica: OWASP Secrets Management Cheat Sheet.