Un posible caso cotidiano: el formulario sigue apareciendo, pero la interfaz posterior ya no acepta solicitudes. O una importación nocturna se detiene porque su autenticación ha dejado de ser válida. Estas dependencias suelen hacerse visibles cuando el proceso de negocio no ocurre.
Un acceso API necesita más que almacenamiento seguro. Responsabilidad, vigencia, sustitución y comprobación del funcionamiento real van juntos. Esto se aplica a claves API, credenciales de cliente OAuth, cuentas de servicio y certificados, cada uno con reglas distintas.
Caducidad, rotación y revocación son eventos diferentes
Una fecha fija de caducidad puede impedir técnicamente el uso posterior. Una regla de rotación establece cuándo sustituir un acceso. Puede imponerla el proveedor o acordarse operativamente. La revocación termina un permiso por un motivo concreto y puede afectar a una credencial aún vigente.
No todas las claves tienen automáticamente la misma duración. Google documenta, por ejemplo, que las claves de cuenta de servicio creadas por el usuario no caducan por defecto; las políticas organizativas pueden cambiarlo. Los secretos de cliente Microsoft Entra tienen una vigencia definida. Se registra la regla del emisor real en lugar de asumir el mismo intervalo para todos los servicios.
En OAuth, token de acceso, posible token de actualización y credenciales de aplicación son elementos distintos. Sus ciclos no deben agruparse en una sola «clave API» en el inventario. La identidad de una cuenta de servicio tampoco equivale a una de sus claves.
El inventario necesita responsables, sin secretos en texto claro
Para cada acceso de integración importante se registran al menos servicio, proyecto, proceso afectado, emisor y tipo de credencial. Se añaden responsable o rol, sustituto y vía de escalado accesible. Quien recibe una alerta debe saber qué proceso depende del acceso.
- Regla: Fecha de emisión, caducidad real o ausencia explícita de ella, rotación prevista y posibles cambios del proveedor.
- Dependencias: Aplicaciones, tareas, instalaciones y entornos separados que utilizan el acceso.
- Almacenamiento: Referencia al almacén de secretos autorizado y su administración; sin valores en bruto en el inventario.
- Sustitución: Procedimiento de prueba, antelación, autorización, reversión y fecha de la última prueba correcta.
La fecha del almacén y la vigencia técnicamente aplicada por el emisor se verifican por separado. Mantener un metadato no renueva automáticamente el acceso con el proveedor.
Avisar pronto y comprobar realmente la función
La alerta debe dejar tiempo suficiente para autorización, preparación y prueba. La antelación depende del proveedor, riesgo y esfuerzo organizativo. Un destinatario sin sustituto o un aviso que pasa por la integración afectada crea una dependencia innecesaria.
También se observa si el proceso esperado funciona: ¿llegan solicitudes? ¿Se ejecuta la importación? ¿Puede procesarse la petición al modelo prevista? Tasas de error, ejecuciones ausentes y pruebas reproducibles revelan anomalías incluso sin caducidad próxima. La comprobación debe generar los mínimos datos y costes adicionales.
Una llamada fallida no significa automáticamente una clave caducada. Permisos, cuotas, facturación o pago, cambios del proveedor y accesibilidad técnica se investigan aparte. El error concreto y su impacto determinan la siguiente acción.
| Evento | Significado | Preparación adecuada |
|---|---|---|
| Caducidad técnica | La credencial termina según la regla del emisor. | Comprobar fecha, sustituir a tiempo y probar la función. |
| Rotación prevista | Se sustituye un acceso existente según el plan. | Conocer todos los consumidores, probar transición y reversión. |
| Revocación o retirada | Se termina un permiso de forma deliberada. | Considerar motivo, accesos afectados y operaciones en curso. |
| Otro error de integración | Por ejemplo permisos, cuota, pago o accesibilidad. | Investigar por separado causa concreta y proceso de negocio. |
Planificar la sustitución como proceso completo
Si el proveedor admite varias credenciales válidas simultáneamente, puede prepararse la nueva mientras sigue funcionando la anterior. Microsoft describe este principio para recursos con dos claves, por ejemplo. Es una posibilidad específica del proveedor, no una promesa general para cualquier API.
- Preparar: Comprobar permisos y todos los consumidores, disponer el nuevo acceso en el almacén seguro previsto.
- Probar: Verificar las acciones realmente necesarias con la nueva credencial en un entorno adecuado o con alcance controlado.
- Cambiar: Actualizar ordenadamente aplicaciones y tareas; tener en cuenta cómo cargan los datos y las posibles cachés.
- Observar: Comprobar función y evolución de errores. Ver si algún consumidor olvidado todavía necesita el acceso antiguo.
- Finalizar: Revocar la credencial antigua tras confirmar el cambio y actualizar inventario y documentación operativa.
Si solo puede haber un acceso válido, el cambio requiere mayor coordinación. Una ventana de mantenimiento acordada puede ser útil. La reversión se define previamente; no se reactiva sin más una credencial antigua comprometida o revocada.
Reducir las claves permanentes cuando sea posible
Las plataformas adecuadas ofrecen identidades administradas o autenticación federada para aplicaciones. Pueden reducir la gestión de secretos duraderos distribuidos por cuenta propia. Idoneidad, permisos de destino, duración y recuperación siguen verificándose. Un certificado también necesita un ciclo de vida.
Un escáner de secretos complementa la protección detectando credenciales posiblemente expuestas. No mantiene el inventario operativo de dependencias ni ejecuta la sustitución completa de todos los consumidores. Detección de filtraciones y gestión de vigencias cumplen tareas distintas.
Empezar por las conexiones críticas para el negocio
DAXS registra interfaces importantes y responsabilidades, comprueba avisos y desarrolla una sustitución repetible. Un piloto puede comenzar con envío de formularios, importación de datos o conexión a un modelo. Son posibles pruebas, no incidentes atribuidos a clientes.
Los servicios de desarrollo e integración y la página técnica de MCP e interfaces explican la integración. El artículo sobre permisos MCP por proyecto complementa el acceso controlado. Puede solicitar un inventario de sus accesos de integración.
Preguntas frecuentes
¿Hay que regenerar periódicamente todas las claves API?
No existe una regla uniforme para todos los proveedores. Vigencia, reglas del emisor, riesgo y proceso operativo se comprueban en concreto. Una clave sin fecha fija también requiere gestión organizada.
¿Basta un correo poco antes de caducar?
Un aviso solo es útil con responsabilidad, sustitución y un proceso probado. Además debe verse si la función dependiente trabaja realmente.
¿La rotación siempre puede hacerse sin interrupción?
Depende del proveedor, credenciales utilizables en paralelo y comportamiento de carga de las aplicaciones. Si no cabe solapamiento, se planifica un proceso coordinado con una ventana de mantenimiento adecuada.
Fuentes: Google Cloud: claves de cuenta de servicio y caducidad (enlace externo) · Microsoft: credenciales de aplicación y rotación (enlace externo) · Microsoft: sustitución con dos credenciales (enlace externo) · Microsoft: rotación con una credencial (enlace externo) · IETF: tokens OAuth y autenticación de aplicaciones (enlace externo) · OWASP: ciclo de vida de secretos (enlace externo) · GitHub: alcance del análisis de secretos (enlace externo)
Escenarios posibles y procesos simplificados; las reglas y opciones concretas dependen de proveedor y aplicación. Diagrama e imagen ilustrativa no muestran una configuración cliente.
