DeployBot recibe un token de larga duración para publicar artefactos desde la canalización de compilación (build pipeline). Un trabajo registra el token en los logs de CI, un atacante obtiene la salida del log y ese mismo token publica con éxito un paquete interno desde una nueva dirección IP. El atacante no necesitó la contraseña de un empleado, una página de phishing ni una sesión de usuario; solo requirió una credencial que representara a una entidad automatizada (principal).
Una identidad no humana es la entidad (principal) que respalda una carga de trabajo automatizada, un servicio, una canalización, un dispositivo o un agente. En este entorno, DeployBot tiene autoridad porque los servicios posteriores aceptan su token, no porque un humano complete la autenticación multifactor (MFA) en cada solicitud. Por tanto, la pregunta para el equipo de defensa es operativa: ¿cómo emitimos permisos de alcance limitado, los rotamos sin interrumpir la producción y detectamos el uso indebido cuando la credencial sale de su entorno de ejecución previsto?
El fallo más simple consta de una entrada y un resultado. DeployBot presenta un token de portador (bearer token) copiado al registro de artefactos, y este publica un artefacto porque el token sigue siendo válido y contiene el permiso necesario. Un token demuestra posesión, no la ubicación o el proceso legítimo que lo obtuvo, a menos que el diseño de identidad subyacente incorpore dichas comprobaciones.
Regla de límites Una credencial no humana debe identificar a la entidad (principal), limitar su autoridad y permitir su supervisión tras la emisión.
La filtración del token es relevante porque DeployBot representa solo una de las rutas de identidad en prod-gke-1. El clúster de Kubernetes ejecuta Orders API, Billing API e Inventory API. Junto a estos servicios, SupportAgent invoca herramientas de soporte aprobadas, ETLBot importa datos y DeployBot compila y publica artefactos. Cada entidad genera una decisión de autorización, un ciclo de vida de credencial y evidencias que los defensores deben conservar.
La superficie de ataque no se limita al clúster. Las solicitudes atraviesan el límite del clúster, el límite de la malla de servicios (service mesh) entre cargas de trabajo, el registro de artefactos, el almacén de secretos, el proveedor de identidad y servidor de autorización, así como las API de proveedores SaaS externos. Una credencial copiada de un límite puede ser aceptada en otro cuando las políticas la consideran prueba suficiente, sin tener en cuenta su emisor, destinatario, carga de trabajo, origen o acción permitida. El entorno descrito a continuación proporciona un objetivo coherente para los controles posteriores.
Rastreemos dónde cruzan las credenciales y los tokens dichos límites:
Este diagrama muestra cómo la autoridad se desplaza mediante tokens a través de varios sistemas, mientras que cada sistema registra solo una parte del rastro de la solicitud.
Dado que el inventario identifica cada ruta de autoridad, podemos modelar el fallo antes de seleccionar un control. Una clave de API filtrada desde un repositorio o un registro de CI permite a un atacante suplantar al principal hasta que se revoque dicha clave. Un secreto de cliente OAuth robado puede servir para generar nuevos tokens de acceso. Un token de acceso reutilizado (ataque de replay) podría funcionar desde una red o un entorno de ejecución inesperados. Aunque se trata de rutas de robo distintas, todas cruzan el mismo límite: un actor externo presenta credenciales destinadas a una carga de trabajo controlada.
Un alcance excesivamente amplio altera el impacto tras el robo. Si SupportAgent tiene permisos para leer registros de facturación e invocar una herramienta de reembolsos bajo una única autorización general, una solicitud de herramienta iniciada mediante un prompt o un componente del agente comprometido podrían desencadenar una acción que exceda la autoridad prevista para quien realiza la solicitud. Este es un problema de delegado confundido (confused deputy): un servicio con autoridad legítima realiza una acción para un solicitante no confiable o insuficientemente autorizado. La solución no consiste simplemente en una autenticación más robusta; la llamada a la herramienta requiere una política explícita que vincule al principal solicitante, al recurso de destino y a la operación permitida.
La rotación introduce un tipo de fallo más silencioso. Es posible que un almacén de secretos contenga una credencial de reemplazo mientras ETLBot sigue utilizando un secreto antiguo almacenado en caché, o que un proveedor SaaS aguas abajo continúe aceptando ambas versiones durante más tiempo del previsto. La rotación solo se considera completa cuando la credencial antigua ya no permite autorizar solicitudes y la carga de trabajo ha demostrado que puede utilizar la nueva.
La siguiente sección asocia cada amenaza con sus medidas de prevención y evidencias:
La siguiente comparativa vincula el límite, la medida de prevención y la fuente de evidencia con cada tipo de fallo relacionado con las credenciales.