Migrar una automatización de Zapier o Make a un nuevo host de geocodificación
Las automatizaciones sin código basadas en un paso de geocodificación necesitan un enfoque de migración distinto al del código propio. Así puedes gestionar ese cambio.
Retirar de forma segura las claves de API antiguas después de una migración
Retirar la clave de API de un proveedor anterior parece un paso pequeño, casi administrativo, al final de una migración, pero equivocarse con el momento en cualquiera de los dos sentidos tiene un coste real. Si la retiras demasiado pronto, antes de que todos los sistemas dependientes se hayan migrado de verdad, algo que todavía llama a la clave antigua falla de forma inesperada. Si la retiras demasiado tarde, o nunca, una credencial sin uso pero todavía válida se queda ahí como un riesgo de seguridad que nadie vigila activamente.
El proceso más seguro trata la retirada de claves como un pequeño proyecto propio con una secuencia definida, no como algo secundario añadido al final del trabajo principal de migración:
- Confirma primero que la clave antigua no tiene tráfico, no te limites a creer que la migración está completa. La mayoría de los proveedores ofrecen cierta visibilidad del uso de una clave; compruébalo directamente en lugar de suponer que, porque la lista de tareas de la migración esté marcada como terminada, la clave antigua ha dejado realmente de usarse en la práctica.
- Deja la clave antigua válida pero sin uso durante un periodo de observación definido después de creer que la migración está completa, en lugar de desactivarla en cuanto el nuevo proveedor entre en funcionamiento. Este periodo, normalmente de unas semanas según tus patrones de tráfico y tus ciclos de publicación, detecta cualquier punto de llamada olvidado, actualización retrasada de una app móvil o proceso por lotes que se ejecuta con poca frecuencia y que todavía hace referencia a la credencial antigua.
- Desactiva primero la clave antigua en lugar de eliminarla, si tu proveedor admite esa distinción. Una clave desactivada que sigue existiendo como registro es más fácil de reactivar brevemente si surge algo inesperado que una eliminada por completo, lo que te da un margen de seguridad durante el periodo de observación sin alargarlo indefinidamente.
- Elimina o revoca por completo la clave antigua en una fecha concreta ya decidida, y deja constancia de que se hizo. Una clave desactivada indefinidamente sigue siendo una superficie de ataque que alguien podría llegar a reactivar si la propia cuenta se viera comprometida alguna vez; una credencial realmente retirada debería eliminarse definitivamente en algún momento, no quedarse en un limbo permanente.
- Revisa dónde estaba guardada la clave antigua, incluidos los sistemas de gestión de configuración, los gestores de secretos, los archivos de variables de entorno y cualquier documentación o material de incorporación que pueda hacer referencia a ella, ya que una clave retirada que sigue anotada en algún sitio como "la clave de API" crea confusión a quien lea esa documentación después, mucho tiempo después de que la propia clave haya dejado de funcionar.
En una migración a My Geocode, la nueva clave puede acotarse y supervisarse desde el primer día con las cabeceras de cuota presentes en cada respuesta, X-Quota-Used, X-Key-IPs-Used y otras documentadas en /docs/rate-limits/, lo que facilita confirmar que la nueva clave está soportando realmente el tráfico que esperas antes de poner en marcha la cuenta atrás para retirar la antigua. Tratar la retirada de credenciales con este grado de rigor supone un poco más de proceso a cambio de una reducción significativa tanto del riesgo operativo como de la exposición de seguridad residual.