Pide el permiso, no la llave: conecta servicios sin el secreto
Copiar la variable de entorno al otro servidor cuesta una línea menos. Pedirle al servicio dueño un link firmado, que abre una sola pantalla y caduca, quita un lugar donde se puede filtrar la llave que abre todas. El criterio y las tres reglas que lo sostienen.
También en: English
Tienes dos servicios propios y uno necesita algo del otro. La salida más corta es copiar al segundo la variable de entorno con la que el primero firma sus accesos. Cuesta una línea menos y agrega un lugar más donde se puede filtrar la llave que abre la pantalla de todos.
El criterio: si el otro servicio necesita un acceso concreto, que lo pida y se le emita. La llave que firma todos los accesos se queda en un solo lugar.
Un link no es una llave
Un link firmado abre una sola pantalla y caduca. La llave que lo firma abre la de todos y no caduca. Si el servicio que la recibe se compromete, o la variable aparece en un log o en una copia de seguridad, el daño de un link es una pantalla durante un rato. El de la llave es cada pantalla, hasta que alguien la rote.
Tres reglas para la ruta que emite
Un servidor publica propuestas para clientes y necesita enlazar la pantalla de cada proyecto en un portal. En vez de llevarse el secreto del portal, le pide el link a una ruta de emisión.
- Solo firma lo que ya conoce. Sin ese filtro sería un firmador genérico: quien tuviera la credencial se fabricaría la entrada a cualquier pantalla.
- Credencial propia. Usa una credencial dedicada, distinta de la de consultas que tiene el asistente de cada proyecto. Con una sola, un asistente comprometido emitiría accesos a la pantalla de cualquier cliente.
- El vencimiento se acota, no se rechaza. Un link eterno dentro de un documento que se reenvía sería un acceso permanente; y rechazar el pedido dejaría al comercial sin nada que enviar.
Dejarlo fijado en pruebas
Una regla de seguridad que solo vive en la cabeza de quien la escribió se pierde en la siguiente refactorización. Dos pruebas importan más que el resto: el link emitido lo acepta el mismo verificador de la puerta, y el de un proyecto no abre el de al lado.
Antes de aplicarlo
Cuenta cuántas máquinas tienen hoy el token que piensas reutilizar y pregúntate si a todas les darías la capacidad nueva. Si no, esa capacidad necesita su propia credencial.
¿Tienes un caso donde quieras ver esto funcionando? Cuéntanos qué hace tu negocio y lo armamos sobre tu material.