AdAce AdsRota una clave de API de integración de IA con inventario y comprobación de revocación
Crear una clave de reemplazo es solo una parte de la rotación. El desafío operativo consiste en encontrar cada consumidor, reemplazar la credencial sin confundir identidades y confirmar que la anterior ya no funciona. Este runbook sugerido describe ese ciclo de vida en AdAce Ads sin repetir el tutorial de creación de claves, exponer un secreto ni asumir que hay algún cliente de IA externo conectado.
Inventaria los consumidores antes del reemplazo
Comienza con un inventario de credenciales que registre el ID de la clave o su prefijo seguro, propietario, espacio de trabajo, consumidor previsto, alcances, vencimiento, referencia a la ubicación de almacenamiento y contacto operativo. Registra la ubicación de un secreto, nunca su valor. Distingue una clave usada por una tarea de informes de una utilizada de forma interactiva. Una clave sin un consumidor identificado es un elemento no resuelto del inventario, no algo seguro de dejar activo por defecto. La evidencia de uso reciente puede ayudar, pero la falta de uso no constituye un mapa completo de dependencias.
AdAce Ads almacena un hash de la clave, muestra la clave completa únicamente al crearla y evalúa sus alcances junto con los permisos actuales del propietario. La rotación debe conservar o reducir el límite necesario, no agregar el alcance propose solo porque se emite una clave nueva. Para una tarea exclusivamente de informes, usa la capacidad de lectura prevista. Una clave de API y una concesión de OAuth son credenciales distintas; reemplazar una no reemplaza ni revoca la otra. Identifica la ruta de autenticación real antes de comenzar.
Un ejemplo didáctico tiene dos consumidores: un script de preparación de informes y una sesión temporal de un analista. El script necesita un reemplazo planificado; la sesión temporal ha finalizado y debe cerrarse en lugar de migrarse. El runbook registra una transición y una eliminación. No copia el mismo reemplazo en todos los dispositivos conocidos. Que un consumidor no identificado use la identidad anterior después de la transición es motivo de investigación, no para restaurar la clave anterior indefinidamente por comodidad.
La transición y la revocación requieren comprobaciones separadas
- Elige el modo de rotación según el motivo. Un reemplazo rutinario puede admitir una breve superposición controlada si es compatible; una sospecha de exposición puede requerir la revocación inmediata y una interrupción temporal del servicio. No asumas que la continuidad es más importante que la contención.
- Usa una matriz de verificación con la credencial anterior, la credencial de reemplazo y los consumidores afectados. Una lectura exitosa con el reemplazo solo demuestra esa ruta de lectura. No prueba que la credencial anterior esté revocada ni que se haya actualizado cada consumidor programado.
- Mantén identificadores y marcas de tiempo en el runbook, no capturas de pantalla de campos secretos ni cabeceras de autenticación. Un informe de rotación debe ser útil para otro operador sin convertirse en un nuevo canal de distribución de credenciales.
Reemplaza, verifica y cierra
- Identifica al propietario y a todos los consumidores documentados. Revisa los alcances requeridos y el acceso a clientes, y luego elige entre gestión rutinaria o de emergencia. Registra al responsable autorizado de la transición y la condición para poner fin a cualquier período de superposición.
- Aprovisiona un reemplazo mediante el flujo de trabajo de claves autorizado existente si se requiere un cambio. Verifica los límites y permisos actuales de la cuenta en lugar de codificarlos en el runbook. Guarda el nuevo valor directamente en la ubicación segura aprobada sin pegarlo en notas, chats ni registros.
- Actualiza un consumidor controlado y verifica una lectura permitida e inocua en el espacio de trabajo previsto. Confirma que lea el alcance adecuado y que no invoque propose_change ni ninguna herramienta de escritura. Repite la comprobación específica por consumidor cuando las credenciales o los entornos de ejecución difieran.
- Revoca la clave anterior a través del control autorizado y confirma que se rechace una lectura aislada con la credencial anterior. Usa herramientas seguras que oculten los encabezados de solicitud y el secreto. No coloques la credencial en un comando de shell, URL, captura de pantalla ni informe de pruebas exportado.
- Cierra la rotación con evidencia segura: ID de reemplazo, ID anterior, comprobaciones de consumidores, resultado de la revocación, verificador y hora. Presta atención a consumidores fallidos que intenten usar la credencial anterior y resuélvelos mediante la migración o el cierre adecuados. Un secreto revocado no debe convertirse en el mecanismo de recuperación.
Identifica qué límite de credenciales cambió
- Revocar una clave impide la autenticación futura a través de ella; no retracta datos ya leídos, no cancela cada autorización independiente ni retira una membresía directa en plataformas publicitarias. Revisa esos límites por separado al finalizar una relación.
- Este es un runbook operativo propuesto, no un informe de que se haya realizado una rotación en vivo. Las pruebas locales y la revisión de código pueden establecer el comportamiento esperado, pero las comprobaciones controladas deben verificarse en el entorno real. Ningún ejemplo requiere una escritura en la API publicitaria.
Fuentes y lecturas recomendadas
Pruébalo en tus propias cuentas
Crea un espacio de trabajo, conecta Google o Meta en un par de clics y visualiza tus cuentas con claridad. Los cambios siguen tus aprobaciones o la política que configures.
Crea tu espacio de trabajo