Secretos en las URL: por qué la rotación es el segundo paso
Un secreto compartido que autentica un servicio ante otro tiene que viajar de algún modo. Un número sorprendente de sistemas lo envían como parámetro de consulta, normalmente porque el ejemplo del marco lo hacía así.
La consecuencia es fácil de enunciar y fácil de subestimar: un secreto en una URL se escribe en cada registro de acceso, registro de proxy y traza que maneja la solicitud. No en riesgo de escribirse: escrito. En una integración con mucho tráfico, eso son miles de copias en un mes, a través de sistemas que nunca fueron diseñados para custodiar credenciales, algunos de los cuales se retienen durante un año y se copian a las copias de seguridad cada noche.
Cuando un equipo descubre esto, el instinto es rotar el secreto. Eso es necesario. También es el segundo paso, y hacerlo primero desperdicia la rotación.
Por qué la rotación por sí sola falla
La rotación reemplaza un valor que puede estar comprometido. No hace nada con el mecanismo que lo expuso. Si el transporte no cambia, el nuevo secreto comienza a acumularse en los mismos registros el mismo día, y ahora hay dos credenciales expuestas en la ventana de retención en lugar de una.
El mismo razonamiento se aplica a la redacción de registros. Filtrar el secreto de su propio registro de acceso vale la pena, pero es una mitigación de una elección de transporte, no una corrección. Protege el único punto de recolección que usted controla. No hace nada respecto de los proxies ascendentes, los sistemas de trazas, los registros de la CDN, el historial del navegador, los encabezados de referencia ni cualquier componente que agregue después alguien que no conoce la regla.
Un encabezado nunca entra en el URI. Nada aguas abajo tiene que acordarse de redactarlo, lo que significa que la propiedad se mantiene para componentes que todavía no existen.
Así que el orden es: cambie el transporte y luego rote. Hecho así, el nuevo secreto nunca ha aparecido en una URL en ningún momento de su vida, y el antiguo está muerto antes de que alguien tenga que razonar sobre cuántas copias existen.
Confirme qué código lo está enviando realmente
Antes de aplicar el parche, establezca qué ruta de código está activa. Esto suena obvio y se omite constantemente.
Los sistemas de larga vida acumulan capas. Un marco incluye una integración predeterminada; un equipo escribe después la suya porque la predeterminada no encajaba; la predeterminada sigue instalada pero deshabilitada en la configuración. La documentación describe la predeterminada, así que eso es lo que se parchea (correctamente, con pruebas, mediante revisión) y no cambia nada, porque las solicitudes activas provienen de otro lugar.
La verificación es barata. Lea la configuración que selecciona el manejador, o agregue una línea de registro y observe cuál la emite. Ambas toman minutos. Descubrir el error después de una versión cuesta considerablemente más, y la falla es silenciosa: un parche a código inactivo no produce ningún error, ningún cambio de comportamiento y una canalización en verde.
Cambiar un protocolo sin un corte sincronizado
Mover un secreto de un parámetro de consulta a un encabezado cambia el contrato entre dos sistemas, normalmente en dos repositorios distintos con ciclos de publicación independientes.
El enfoque ingenuo despliega ambos a la vez. Si se pierde la ventana, cada llamada es rechazada. Peor aún, para una integración de webhook o de invalidación de caché, el rechazo suele ser invisible: nada da error, el contenido simplemente deja de actualizarse, y el problema aparece días después como "el sitio parece desactualizado".
La alternativa elimina el acoplamiento por completo:
- Enseñe al receptor a aceptar ambas formas, prefiriendo la nueva. Despliéguelo solo. El comportamiento no cambia, porque nada está enviando la nueva forma todavía.
- Cambie el emisor en su propia versión, según su propio calendario.
- Elimine la forma antigua una vez que los registros confirmen que nada la usa.
En ningún momento las dos partes necesitan ponerse de acuerdo, y ningún despliegue parcial puede romper la ruta. La ventana de transición cuesta una versión adicional y elimina toda la clase de fallas de corte.
Ordene los pasos al revés (el emisor primero) y habrá un período en el que el emisor emite algo que el receptor no entiende.
Verifique usando el sistema
Las verificaciones a nivel de configuración son necesarias y no suficientes. Un despliegue que reporta éxito, un estado de configuración sin diferencias y un ajuste que se lee como habilitado pueden ser todos ciertos mientras la funcionalidad no hace nada.
Eso no es hipotético. Un valor de configuración puede escribirse, validarse contra su esquema y luego descartarse en silencio al importar porque la propiedad no estaba registrada como exportable: todos los indicadores permanecen sanos y la funcionalidad está inerte.
La verificación que distingue lo que funciona de lo que está roto es realizar la operación para la que existe el sistema y confirmar el efecto. Para una integración de invalidación de caché, eso significa editar contenido y observar si el frontend se actualiza.
Una propiedad útil para la que conviene diseñar: haga que el modo de falla sea cerrado. Si un nombre de encabezado incorrecto o un secreto que no coincide produce un rechazo en lugar de silencio, una sola llamada exitosa descarta ambos a la vez. Las integraciones que fallan abiertas, o que fallan en silencio, requieren mucha más evidencia para confiar en ellas.
Limpieza posterior
Una vez corregido el transporte y rotado el secreto, el valor antiguo no vale nada, pero sigue estando en los registros retenidos. Elimine esos archivos en lugar de esperar a que la rotación los envejezca, y verifique después que no quede ninguna ocurrencia sin redactar en ningún lugar.
Una salvedad que conviene planificar: si esos registros se incluyeron en copias de seguridad antes de la eliminación, las copias persisten dentro de los archivos de respaldo hasta que pase la ventana de retención. Eso es de bajo riesgo una vez revocada la credencial, pero es la diferencia entre "resuelto" y "resuelto en todas partes", y vale la pena saber cuál de los dos puede afirmar.
La versión corta
- Trate un secreto en una URL como ya registrado. La única pregunta es cuántos sistemas guardan una copia.
- Corrija el transporte antes de rotar, o rotará dos veces.
- Confirme qué ruta de código está activa antes de parcharla.
- Haga que el receptor acepte ambas formas durante un cambio de protocolo, para que las dos partes se desplieguen de forma independiente.
- Verifique ejercitando el comportamiento. Un despliegue en verde le dice que el despliegue se ejecutó.