O DeployBot recebe um token de longa duração para publicar artefatos a partir do pipeline de build. Um job registra o token nos logs de CI, um atacante obtém a saída do log e o mesmo token publica com sucesso um pacote interno a partir de um novo endereço IP. O atacante não precisou de senha de funcionário, página de phishing ou sessão de usuário. O atacante precisou apenas de uma credencial que representasse uma entidade (principal) automatizada.
Uma identidade não humana é a entidade (principal) por trás de uma carga de trabalho, serviço, pipeline, dispositivo ou agente automatizado. Nesse ambiente, o DeployBot possui autoridade porque serviços subsequentes aceitam seu token, e não porque um humano realiza a MFA (autenticação multifator) a cada solicitação. A questão para a equipe de defesa é, portanto, operacional: como emitir autoridade com escopo restrito, rotacioná-la sem interromper a produção e reconhecer o uso indevido quando a credencial sai de seu ambiente de execução pretendido?
A falha mais simples envolve uma entrada e um resultado. O DeployBot apresenta um token do tipo bearer copiado ao registro de artefatos, e o registro publica um artefato porque o token permanece válido e contém a permissão necessária. Um token comprova a posse, não a localização ou o processo legítimo que o obteve, a menos que o design de identidade subjacente inclua essas verificações.
Regra de limite Uma credencial não humana deve identificar uma entidade (principal), limitar sua autoridade e permanecer observável após a emissão.
O vazamento do token é relevante porque o DeployBot é apenas um dos caminhos de identidade em prod-gke-1. O cluster Kubernetes executa a Orders API, a Billing API e a Inventory API. Paralelamente a esses serviços, o SupportAgent chama ferramentas de suporte aprovadas, o ETLBot importa dados e o DeployBot compila e publica artefatos. Cada entidade gera uma decisão de autorização, um ciclo de vida de credencial e evidências que as equipes de defesa devem preservar.
A superfície de ataque não se limita ao cluster. As solicitações cruzam o limite do cluster, o limite da service mesh entre cargas de trabalho, o registro de artefatos, o armazenamento de segredos, o provedor de identidade e servidor de autorização, e as APIs de provedores SaaS externos. Uma credencial copiada de um limite pode ser aceita em outro quando as políticas tratam a credencial como prova suficiente, sem considerar seu emissor, público-alvo, carga de trabalho, origem ou ação permitida. O ambiente descrito abaixo fornece um alvo consistente para os controles subsequentes.
Vamos rastrear onde as credenciais e os tokens cruzam esses limites:
Este diagrama mostra que a autoridade se desloca com os tokens entre vários sistemas, enquanto cada sistema registra apenas parte do rastro da solicitação.
Como o inventário nomeia cada caminho de autoridade, podemos modelar a falha antes de escolher um controle. Uma chave de API vazada de um repositório ou log de CI permite que um invasor se passe pela identidade (principal) até que ocorra a revogação. Um segredo de cliente OAuth roubado pode gerar novos tokens de acesso. Um token de acesso reutilizado (replay) pode funcionar a partir de uma rede ou ambiente de execução inesperado. Esses são caminhos de roubo diferentes, mas cada um cruza a mesma fronteira: um agente externo apresenta credenciais destinadas a uma carga de trabalho controlada.
Um escopo excessivamente amplo altera o impacto após o roubo. Se o SupportAgent puder ler registros de faturamento e invocar uma ferramenta de reembolso sob uma permissão ampla, uma solicitação de ferramenta orientada por prompt ou um componente de agente comprometido pode causar uma ação fora da autoridade pretendida pelo solicitante. Esse é um problema de representante confuso (confused deputy): um serviço com autoridade legítima executa uma ação para um solicitante não confiável ou insuficientemente autorizado. O controle não é apenas uma autenticação mais forte. A chamada da ferramenta requer uma política explícita que vincule a identidade solicitante, o recurso de destino e a operação permitida.
A rotação introduz uma falha mais silenciosa. Um armazenamento de segredos pode conter uma credencial de substituição enquanto o ETLBot continua usando um segredo antigo armazenado em cache, ou um provedor SaaS a jusante pode continuar aceitando ambas as versões por mais tempo do que o planejado. A rotação só é concluída quando a credencial antiga não consegue mais autorizar solicitações e a carga de trabalho provou que pode usar a substituição.
A estrutura a seguir associa cada ameaça a medidas de prevenção e evidências:
A comparação abaixo mantém a fronteira, a medida de prevenção e a fonte de evidência associadas a cada falha de credencial.