Una empresa de tecnología logística había emitido claves de API a cuarenta y tres socios de integración y aplicaciones internas a lo largo de cuatro años. Una revisión de seguridad determinó que once de las cuarenta y tres claves se habían emitido para aplicaciones o integraciones que ya no estaban activas: la aplicación se había retirado, la relación con el socio de integración había terminado o el caso de uso se había sustituido por otra implementación. Las once claves seguían activas. Tres de las once seguían generando llamadas a la API, llamadas que no procedían de las aplicaciones retiradas ni de las integraciones terminadas, sino de orígenes no identificados que habían obtenido las claves. Una clave había quedado expuesta en una confirmación pública en GitHub y las llamadas procedían de más de cuarenta direcciones IP distintas. La empresa logística no tenía ningún proceso de gestión del ciclo de vida de las claves de API. Las claves se emitían mediante un sistema de solicitudes y solo se revocaban cuando alguien solicitaba expresamente la revocación. Nadie había solicitado expresamente la revocación de las claves de aplicaciones que simplemente se retiraron sin hacer ruido o de integraciones que simplemente terminaron sin hacer ruido. Once claves inactivas. Tres explotadas activamente. Una expuesta a la internet pública durante cuatro semanas antes de que el repositorio de GitHub se hiciera privado.
¿Qué es realmente el uso indebido de identidades de API?
Las identidades de API son las credenciales (claves de API, secretos de cliente, tokens OAuth y tokens de autenticación similares legibles por máquinas) que usan las aplicaciones, las integraciones y los procesos automatizados para autenticarse ante API y plataformas. Son el equivalente para máquinas de las contraseñas de usuario: un secreto compartido que demuestra que la parte que lo presenta tiene derecho a acceder a la API. Al igual que las contraseñas de usuario, pueden robarse, compartirse, codificarse en el código, exponerse en repositorios públicos y usarse más allá de su alcance previsto. A diferencia de las contraseñas de usuario, se emiten a una escala enorme (la mayoría de las organizaciones tienen muchas más claves de API en circulación que cuentas de usuario) y se gobiernan con mucho menos rigor en su ciclo de vida que las credenciales de usuario.
El descuido del ciclo de vida es la raíz estructural del uso indebido de identidades de API. Las cuentas de usuario se crean para personas concretas, y cuando esas personas se van o cambian de función, los procesos de baja y de revisión de accesos generan presión para revisar y actualizar su acceso. Las claves de API se crean para aplicaciones concretas, y cuando esas aplicaciones se retiran o las integraciones terminan, no existe un evento análogo que genere presión organizativa para revisar y revocar las claves asociadas. La aplicación deja de funcionar. La clave sigue existiendo, válida y activa, a la espera de quien la encuentre.
El problema de la exposición en repositorios de código se ha convertido en uno de los vectores de compromiso de claves de API más comunes de la última década. Los desarrolladores que codifican claves de API en el código de las aplicaciones durante el desarrollo y las pruebas (una práctica generalizada, prohibida expresamente por todas las normas de seguridad, pero extremadamente común en la práctica) crean un riesgo de exposición persistente cada vez que ese código se confirma en un repositorio. Si el repositorio es público aunque sea brevemente, como un repositorio público de GitHub que luego se hizo privado, la clave queda expuesta a herramientas de análisis automatizado que recopilan continuamente credenciales de los repositorios públicos. Las claves de API encontradas en repositorios públicos suelen explotarse a los pocos minutos de quedar expuestas. Hacer privado el repositorio no elimina la clave de las herramientas que ya la recopilaron.
- Claves de aplicaciones retiradas que siguen activas: claves de API no revocadas cuando se pone fuera de servicio la aplicación para la que se emitieron
- Persistencia de claves de integraciones terminadas: claves emitidas a socios de integración cuya relación ha terminado que siguen activas y válidas
- Claves codificadas en repositorios de código: claves de API incrustadas en código fuente confirmado en repositorios de control de versiones
- Sin detección de anomalías de uso: el uso de las claves de API no se supervisa para detectar actividad desde orígenes inesperados
- Sin proceso de gestión del ciclo de vida de las claves: las claves se revocan solo cuando se solicita expresamente, no mediante una revisión sistemática del ciclo de vida
Por qué es importante
El uso indebido de identidades de API es importante para TPRM porque las claves de API son el principal mecanismo a través del cual las aplicaciones de los proveedores y los socios de integración acceden a las plataformas de los clientes, y la gestión del ciclo de vida de esas claves determina si el acceso que proporcionan se mantiene dentro de su alcance previsto o lo sobrepasa en el tiempo y en extensión. Una plataforma de cliente que emite claves de API a proveedores y socios de integración sin gestión del ciclo de vida está acumulando credenciales inactivas y potencialmente comprometidas que representan un acceso válido a la plataforma mucho después de que haya terminado la finalidad del acceso.
La dimensión de la cadena de suministro tiene consecuencias especialmente graves. Las claves de API emitidas a proveedores de integración para acceder a una plataforma concreta pueden estar codificadas en el código de la aplicación del proveedor, almacenadas en sus repositorios de código fuente o pasar por sus entornos de desarrollo y pruebas. Cada una de estas vías representa un vector de exposición por el que la clave podría obtenerse sin una vulneración directa del cliente ni del proveedor: mediante la exposición de un repositorio público, el compromiso de la estación de trabajo de un desarrollador o una canalización de CI/CD que registra variables de entorno. La clave da acceso a la plataforma del cliente, independientemente de cómo se haya obtenido.
Para los profesionales de TPRM, evaluar la gobernanza de las claves de API exige preguntar por los procesos de gestión del ciclo de vida, la supervisión del uso y la detección de la exposición, no solo si las claves se documentan al emitirse. La documentación de emisión describe el uso previsto. La gestión del ciclo de vida, la supervisión del uso y la detección de la exposición rigen lo que realmente ocurre con la clave durante su vida operativa.
Dónde se equivocan la mayoría de los equipos
El fallo más habitual es tratar la documentación de emisión de claves de API como gobernanza de las claves de API. Documentar para qué aplicación se emitió una clave no impide que la clave sobreviva a la aplicación, no detecta el uso desde orígenes inesperados y no supervisa la exposición en repositorios. La documentación de emisión es el registro. La gestión del ciclo de vida es la gobernanza.
- Tratar la documentación de emisión de claves como gobernanza de las claves
- Sin desencadenante del ciclo de vida para la retirada de aplicaciones: las claves no se revisan cuando se retiran las aplicaciones
- Sin supervisión del uso desde orígenes inesperados: no se detectan las claves usadas por orígenes no autorizados
- Sin análisis de repositorios en busca de claves codificadas
- Revocación de claves supeditada a una solicitud expresa en lugar de a una revisión sistemática
Cómo se ve una buena práctica
Los programas maduros de gobernanza de claves de API tratan el ciclo de vida de las claves como vinculado al ciclo de vida de las aplicaciones: las claves emitidas para aplicaciones concretas se revisan cuando esas aplicaciones cambian de estado, el análisis automatizado detecta claves codificadas en los repositorios de código antes de que queden expuestas y la supervisión del uso señala las claves que se están usando desde orígenes inesperados.
- La retirada de aplicaciones desencadena la revisión de claves: las claves asociadas a aplicaciones que se retiran se marcan automáticamente para su revocación
- Análisis de repositorios en busca de claves codificadas: análisis automatizado de los repositorios de código en busca de patrones de claves de API
- Detección de anomalías de uso: el uso de las claves de API se supervisa en busca de llamadas desde orígenes inesperados, volúmenes inusuales o patrones sospechosos
- Política de caducidad y rotación de claves: claves de API emitidas con fechas de caducidad definidas en lugar de una validez indefinida
- Inventario de claves con fecha de último uso: todas las claves activas documentadas con fecha de emisión, aplicación asociada y marca de tiempo del último uso
Herramientas
Análisis de secretos: GitHub Advanced Security, GitLab Secret Detection, Trufflehog, Gitleaks
Las herramientas de análisis de secretos examinan los repositorios de código, tanto las confirmaciones como su historial, en busca de claves de API, credenciales y otros secretos que se hayan confirmado en el control de versiones. GitHub Advanced Security ofrece análisis de secretos nativo que genera alertas cuando se encuentran en las confirmaciones credenciales que coinciden con patrones conocidos de claves de API. Para los profesionales de TPRM, preguntar si el proveedor usa análisis automatizado de repositorios en busca de claves de API codificadas es una pregunta concreta sobre la detección de la exposición en el código.
Seguridad de API: Salt Security, 42Crunch, Noname Security
Las plataformas de seguridad de API supervisan el tráfico de API en busca de patrones de uso anómalos: detectan claves que se usan desde orígenes inesperados, volúmenes de llamadas inusuales, patrones inusuales de acceso a puntos de conexión y otros indicadores de que una clave puede estar comprometida. Para los profesionales de TPRM, preguntar si el proveedor supervisa el uso de las claves de API en busca de patrones anómalos es una pregunta concreta sobre la detección del uso indebido de claves.
Gestión de secretos: HashiCorp Vault, AWS Secrets Manager
Las plataformas de gestión de secretos ofrecen gestión del ciclo de vida de las claves de API: almacenan las claves de forma segura, permiten la rotación automática y proporcionan registros de acceso que permiten detectar usos inesperados de las claves. Sustituir las claves de API codificadas o de secreto compartido por claves gestionadas mediante un gestor de secretos elimina el riesgo de codificación y proporciona una gestión centralizada del ciclo de vida. Para los profesionales de TPRM, preguntar si las integraciones del proveedor con las plataformas del cliente usan gestión de secretos para almacenar las claves es la pregunta más directa para prevenir la codificación de claves.
Desafíos de gobernanza
El reto de gobernanza del ciclo de vida de las claves de API es el problema de la escala combinado con el reto de la atribución. La mayoría de los entornos tienen muchas más claves de API que cuentas de usuario, y las claves las crean los equipos de desarrollo, de integración y de operaciones sin un registro central. Para construir el programa de gestión del ciclo de vida hay que construir primero el inventario (identificar todas las claves activas, sus aplicaciones asociadas y sus fechas de último uso) antes de poder aplicar los procesos de ciclo de vida.
- Construya un inventario de claves de API: todas las claves activas con su aplicación asociada, fecha de emisión y fecha de último uso
- Vincule el ciclo de vida de las claves al ciclo de vida de las aplicaciones: la retirada de una aplicación desencadena la revisión de sus claves
- Implemente el análisis de repositorios: detección automatizada de claves codificadas
- Añada supervisión del uso: las claves usadas desde orígenes inesperados generan alertas
- Implemente la caducidad de las claves: claves emitidas con una caducidad definida que exige una renovación expresa
Si usted forma parte de un equipo pequeño
Haga a sus proveedores integrados mediante API dos preguntas que sacan a la luz a la vez el riesgo del ciclo de vida y el de exposición. Primera: ¿puede proporcionar un inventario de todas las claves de API activas actualmente en su organización para integraciones con nuestra plataforma, con la última fecha de uso de cada clave y la aplicación o el servicio que la usa? Segunda: ¿usa análisis automatizado de repositorios para detectar claves de API que puedan haberse codificado en confirmaciones de desarrolladores? La pregunta del inventario saca a la luz las claves inactivas y huérfanas. La pregunta del análisis saca a la luz el riesgo de exposición que termina en llamadas a la 847 API desde orígenes desconocidos.
- Solicite un inventario de claves de API con fechas de último uso para las claves en poder del proveedor
- Pregunte por el análisis automatizado de repositorios en busca de claves de API codificadas
- Pregunte por la supervisión de anomalías de uso para detectar el uso indebido de claves de API
- Implemente la caducidad de las claves como requisito estándar para las claves de integración
Qué exigir
Pregunte directamente:
“¿Puede proporcionar un inventario de todas las claves de API que tiene actualmente su organización para integraciones con nuestra plataforma, con la fecha de emisión, la aplicación asociada y la fecha del último uso, y confirmar que todas las usan actualmente aplicaciones activas y autorizadas?”
“¿Usa análisis automatizado para detectar claves de API codificadas en sus repositorios de desarrollo? ¿Alguna vez ha aparecido alguna clave asociada a nuestra plataforma en un hallazgo del análisis de repositorios?”
Evidencia que debe esperar
- Inventario de claves de API con fechas de último uso y asociaciones con aplicaciones
- Confirmación del análisis de repositorios con los resultados del último análisis
- Descripción de la supervisión del uso: cómo se detecta el uso inesperado de las claves
- Política de caducidad y rotación de claves
Un proveedor cuya clave de API apareció 847 veces en el último mes desde orígenes que no son su aplicación retirada tiene un problema activo de uso indebido de claves. La documentación sobre la aplicación para la que se emitió la clave describe con precisión la intención de la emisión. El registro de uso describe con precisión la realidad actual. La cuestión de gobernanza es si algo conecta ambas cosas, si alguien supervisa la brecha entre el uso previsto y el uso real que representan las llamadas a la 847.
Cómo demostrarlo
- Registros del inventario de claves de API con verificación del último uso
- Pruebas de la implementación del análisis de repositorios
- Documentación de la política de caducidad de claves
- Confirmación de la supervisión de anomalías de uso
Conclusión clave
La clave de API sobrevivió ocho meses a la aplicación para la que se creó. Estuvo en un repositorio público de GitHub durante cuatro semanas. Este mes se ha usado 847 veces desde orígenes que no son la aplicación retirada. La documentación de emisión registra con precisión para qué era la clave. No existe la gestión del ciclo de vida que debería haber retirado la clave cuando se retiró la aplicación. Falta la supervisión del uso que debería haber detectado a los llamantes inesperados. Nunca se ejecutó el análisis de repositorios que debería haber señalado la confirmación con la clave codificada. Las tres brechas estaban presentes a la vez. La clave se está usando indebidamente en este mismo momento. La identidad de API es el tipo de credencial más abundante en la mayoría de los entornos y el menos gobernado. La documentación de emisión es el comienzo de la gobernanza. El ciclo de vida, la supervisión y el análisis son el resto.