Las credenciales pasan de un equipo a otro constantemente. El equipo de plataforma da una clave de despliegue a un equipo de producto, soporte recibe el acceso de administrador al portal de un proveedor, finanzas pasa a ingeniería el token de la API del banco para una integración. Cada entrega es rutinaria, y es en ellas donde una credencial acaba con más frecuencia, y para siempre, en un hilo de Slack.
Una forma segura de entregar credenciales entre equipos depende menos de una herramienta ingeniosa que de una regla clara para elegir entre dos herramientas, más unos cuantos hábitos alrededor. Esta guía expone esa regla y esos hábitos: limitar el alcance de la credencial, entregarla sin meterla en un mensaje, nombrar a una persona responsable y retirarla a tiempo.
La única decisión que importa: bóveda o enlace de un solo uso
Todo lo demás depende de cómo vaya a usar la credencial el equipo que la recibe.
| El equipo que la recibe va a | Usa | Por qué |
|---|---|---|
| Seguir usándola, varias personas, sin fecha de fin | Una bóveda compartida en tu gestor de contraseñas o de secretos | Acceso nominal, revocación y rotación en un solo sitio |
| Usarla una vez, o una persona la necesita poco tiempo | Un enlace secreto de un solo uso | El mensaje solo lleva un enlace y la copia se destruye la primera vez que se abre |
| Usarla desde código o CI | Un gestor de secretos con identidades de máquina | Ninguna persona llega a ver el valor |
La bóveda es el sistema de referencia. Si la credencial va a seguir en uso después de la entrega, su sitio es una bóveda compartida que pertenezca al equipo que la recibe, con los miembros añadidos por nombre. La mayoría de los gestores de contraseñas para empresas, y herramientas como Vault o AWS Secrets Manager, lo hacen bien.
El enlace de un solo uso es para el momento de la transferencia cuando la bóveda no encaja: el destinatario no está en tu bóveda, la credencial es temporal o tienes que pasar un valor a una persona ahora mismo. El secreto se cifra en tu navegador, la copia almacenada se destruye la primera vez que se abre el enlace y el propio enlace deja de funcionar al llegar su fecha de expiración si nadie lo abre. Enlaces secretos frente a gestores de contraseñas repasa los casos límite.
Nunca el correo, el chat, los documentos compartidos ni los tickets. Todos guardan copias, todos se sincronizan con dispositivos que no controlas y en todos puede buscar la próxima persona que entre en la cuenta.
Limita el alcance de la credencial antes de moverla
Un buen canal no arregla una credencial con demasiados permisos.
- Crea una cuenta aparte para el equipo o la persona que la recibe, en lugar de prestar una vinculada a alguien concreto. Las identidades compartidas no se pueden auditar ni se pueden retirar limpiamente.
- Concede los permisos que la tarea necesita. Un equipo que lee informes no necesita permiso de escritura. Un equipo que despliega no necesita acceso a la facturación.
- Rota primero si el valor ya ha circulado. Si la clave actual se ha pegado en varios sitios, emite una nueva para la entrega en lugar de seguir difundiendo la antigua.
- Revisa el material que la acompaña. Los tickets, los manuales de operaciones, las configuraciones de ejemplo y los scripts adjuntos al trabajo contienen a menudo la misma credencial que estás a punto de entregar. Quítala antes de la entrega; si no, la entrega será la menor de tus exposiciones.
La entrega
- Verifica al destinatario por un canal en el que tu organización ya confía: el ticket, un responsable conocido, una videollamada. Las direcciones parecidas y los nombres autocompletados son la forma habitual en que un secreto acaba donde no debe.
- Entrégala con la herramienta elegida. Bóveda: añade a la persona a la colección compartida. Enlace: pega el valor en la herramienta de enlaces secretos de un solo uso, ajusta la expiración al plazo real (una hora si la persona está esperando, un día si hay husos horarios de por medio), pon el límite de vistas en uno, añade una frase de contraseña con una cuenta Pro para todo lo que sea delicado y envía el enlace.
- Envía el contexto por separado. El nombre de usuario, el host y lo que la credencial permite abrir van en un mensaje normal, nunca junto al enlace. Un solo mensaje filtrado nunca debe contener las dos mitades.
- Registra la entrega en tu sistema de referencia, sin el secreto: destinatario, finalidad, sistema, responsable y fecha de fin.
- Pide confirmación del acceso, no del valor. «¿Puedes iniciar sesión?» es la pregunta correcta. «Devuélveme la clave para comprobarla» no lo es.
Para un equipo que hace esto a menudo, la app de LinkPilot para Slack convierte una contraseña pegada en un enlace de un solo uso sin salir del canal, así que el hábito no depende de que todo el mundo se acuerde de abrir otra herramienta.
Nombra a un responsable y revisa de forma periódica
Las credenciales sin responsable nunca se rotan ni se retiran. El equipo que la recibe debe nombrar a una persona que responda del valor: quién lo tiene, quién más lo necesita y cuándo deja de usarse.
- Mínimo privilegio por rol, con roles o grupos donde simplifiquen la administración, para que una baja no suponga un restablecimiento en cada sistema.
- Autenticación multifactor en la bóveda, porque ahora la bóveda es lo que merece la pena atacar.
- Un ritmo de revisión acorde con la sensibilidad: trimestral para la mayoría de las credenciales compartidas y en cada cambio de equipo para el acceso a producción.
- Audita las entregas. Una bóveda muestra quién accedió a qué. Una cuenta Pro de LinkPilot muestra un historial de auditoría de cada enlace secreto, para que veas cuándo se mostró un secreto de un solo uso y lo cotejes con la confirmación del destinatario.
Expiración, rotación y exposición
Decide cuándo termina la vida de la credencial antes de que empiece.
- El acceso temporal termina en la fecha acordada. Elimina la cuenta o el acceso a la bóveda y revoca cualquier enlace de un solo uso que no se haya abierto.
- La rotación depende del riesgo, no solo del calendario: después de una baja, después de un cambio de proveedor, después de cualquier sospecha de exposición y de forma periódica para todo lo que tenga una vida larga.
- Una sospecha de filtración es una filtración hasta que se demuestre lo contrario. Rota la credencial en el sistema que la acepta, avisa al responsable y actualiza los procesos y servicios que dependían del valor antiguo. La guía de claves de API tiene una lista de comprobación de rotación que sirve para la mayoría de los tipos de credenciales.
Dos herramientas, una regla para elegir entre ellas y un responsable para cada valor. Ese es todo el sistema, y aguanta muchas más entregas que cualquier documento de políticas que la gente deja de leer.