El mejor secreto intercambiado es el que nunca se intercambia

Cada proyecto empieza con el mismo ritual: «¿me pasas los accesos?». Y cada equipo improvisa una respuesta, a menudo la equivocada. Una contraseña en un correo, una clave de API en un canal de Slack, un archivo .env adjunto: el secreto acaba de salir de todo perímetro de control, para siempre.

Antes de buscar un canal mejor, hagamos la pregunta de fondo: ¿este secreto necesita existir en esta forma? Los mecanismos de identidad federada (OIDC entre una CI y una nube, roles IAM, identidades de carga de trabajo) sustituyen el secreto estático por una prueba de identidad efímera. Ninguna clave que transmitir, ninguna que filtrar, ninguna que rotar. Cuando esa opción existe, gana: el resto de este artículo solo trata de los secretos que realmente deben circular entre personas.

Los canales que se descalifican solos

Algunos canales quedan descartados de oficio, sin debate posible:

• el correo electrónico, replicado en servidores que nadie controla, indexado, archivado, reenviado;
• la mensajería de equipo, cuyo historial pueden leer los administradores, se exporta en las migraciones y se conserva mucho después de las salidas;
• el ticket o el documento compartido, que sobrevivirá al proyecto y reaparecerá en una búsqueda de texto tres años después;
• el SMS y las mensajerías personales, que mezclan el perímetro privado y el profesional.

El punto común: la persistencia no controlada. Un canal aceptable garantiza exactamente lo contrario, es decir, cifrado de extremo a extremo y desaparición.

Lo que funciona, de lo más simple a lo más equipado

Para un intercambio puntual, un enlace de un solo uso y corta vida, generado por una herramienta auditable, cumple: el destinatario lo abre, el secreto se borra. Se confirma la recepción por un segundo canal (una llamada, un mensaje), lo que además confirma que el enlace lo consumió la persona correcta.

Para una colaboración duradera, el intercambio puntual ya no basta: hace falta un espacio compartido. Un gestor de contraseñas de equipo con cofres por perímetro sigue siendo la opción más accesible; un gestor de secretos centralizado (con registro de accesos y políticas por rol) se vuelve pertinente en cuanto la infraestructura lo justifica. El criterio de elección es el mismo: ¿podemos saber quién accedió a qué, y retirar un acceso con una sola acción?

El esquema merece repetirse: el mensaje de notificación nunca contiene el secreto. Solo dice dónde recuperarlo, con derechos propios.

El mínimo privilegio no es paranoia, es un presupuesto

Cada secreto transmitido es una deuda: alguien tendrá que recordarlo, rotarlo, revocarlo. Esa deuda se reduce en origen:

• secretos por entorno, nunca el mismo token en preproducción y en producción;
• secretos por persona o por servicio, nunca una cuenta compartida «team» de la que ya nadie responde;
• alcances mínimos: una clave de solo lectura para una necesidad de solo lectura;
• vidas cortas por defecto: la expiración es la mejor de las rotaciones.

El historial de Git nunca olvida

La fuga más frecuente no pasa por ningún canal de intercambio: se comitea. Un .env añadido «temporalmente», una URL de conexión en un archivo de configuración, una clave en un test. El historial es una memoria eterna y distribuida: cada clon lleva una copia.

La defensa es por capas. Un .gitignore estricto sobre los archivos de entorno. Un escáner de secretos en pre-commit y en la CI, que bloquea antes de publicar. Y una regla absoluta el día en que un secreto llega igualmente al historial: purgar nunca basta, el secreto se considera comprometido y se rota de inmediato. Reescribir el historial limita la exposición futura, no anula la fuga.

La salida forma parte del intercambio

Un proceso de intercambio de secretos se juzga por su offboarding. La salida de un miembro, el fin de una misión o la rescisión de un proveedor disparan la misma mecánica: revocar los accesos nominativos, rotar los secretos compartidos a los que la persona tuvo acceso, verificar el registro. Si esa lista es dolorosa de establecer, es que los secretos se distribuyeron sin inventariar, y el inventario es precisamente lo que un cofre proporciona gratis.

La checklist que aplicamos

• ¿Puede sustituirse este secreto por una identidad efímera? Si sí, hacerlo.
• Ningún secreto en claro en un correo, un chat, un ticket o un documento.
• Intercambio puntual: enlace de un solo uso, notificación fuera de banda.
• Colaboración duradera: cofre compartido, acceso por rol, registro.
• Un secreto por entorno, por persona, con alcance y vida mínimos.
• Escáner de secretos en pre-commit y CI.
• Secreto en el historial = secreto comprometido: rotación inmediata.
• Offboarding guionizado: revocar, rotar, verificar el registro.

Nada de esto es caro. Lo caro es el token olvidado en un canal de Slack que sigue dando acceso a producción dos años después de terminar el proyecto.