Um engenheiro envia um agente para a produção. Ele precisa chamar uma API interna, por isso usa a chave que já está no ambiente do engenheiro. O agente é executado. Agora também detém todas as permissões que o engenheiro possui.
Esse é o estado padrão da maioria das implantações de agentes atualmente. O agente não tem identidade própria, então ele pega uma emprestada. Geralmente ele pega emprestado um humano, por meio de uma chave de API. O agente trabalha no primeiro dia, e é exatamente por isso que o problema chega à produção despercebido.
Quanto a herança realmente custa para você
Quatro falhas decorrem desse único atalho, e elas se agravam.
Você obtém escalonamento de privilégios. Um processo não humano agora oferece acesso complete a um ser humano. Pode atingir todos os sistemas que o ser humano pode alcançar, quer a tarefa necessite ou não.
Você não tem escopo. O agente deve tocar uma fatia estreita dos seus sistemas. Em vez disso, obtém tudo, porque a chave nunca foi concebida para expressar “apenas isto”.
Você não recebe nenhuma atribuição. Quando o agente atua, o log de auditoria mostra o humano. Não é possível separar o que o agente fez do que a pessoa fez. A resposta a incidentes fica cada vez mais lenta, assim como qualquer história de conformidade que você exact contar mais tarde.
Você não recebe nenhuma revogação limpa. Para desligar o agente, você gira a chave humana. Agora você quebrou o acesso do próprio humano e todos os outros processos que dependiam dessa chave. Não há botão de desligamento apenas para o agente.
Um leitor experiente encontrará as soluções óbvias aqui. Gire a chave de acordo com uma programação. Em vez disso, entregue ao agente uma conta de serviço. Ambos perdem o problema actual.
Um passaporte é o modelo psychological errado
O instinto é tratar a identidade como um passaporte. Um passaporte autentica quem você é e o mapeia para um conjunto fixo de permissões. Mostre na fronteira, tenha o acesso que vem junto. Esse modelo funciona quando o comportamento é previsível dentro dessas permissões. Um ser humano com acesso de leitura a um conjunto de dados lê o conjunto de dados. Uma conta de serviço que posta em uma fila posta na fila, sempre na mesma cadência.
Os agentes quebram a suposição subjacente ao passaporte. A pergunta certa não é “quem é esse ator”. É “o que este ator está autorizado a fazer agora, para esta tarefa”. Isso é autoridade, não identidade no sentido de passaporte, e a diferença é a questão principal.
Aqui está por que isso é importante. Um agente é não determinístico. Dê a dois agentes as mesmas permissões e o mesmo objetivo, e eles poderão realizar ações diferentes, porque cada um escolhe sua cadeia de ferramentas em tempo de execução com base em seu immediate, seu contexto e a saída de tudo o que o chamou. O conjunto de ações que um agente realmente realizará não pode ser conhecido quando você concede suas permissões.
Isso transforma o menor privilégio em tempo de design em uma resposta em tempo de design para um problema de tempo de execução. Você está decidindo, antecipadamente, o que um ator pode fazer, quando o próprio ator resolve o que fazer apenas quando estiver em execução. Uma concessão estática não consegue acompanhar um ator cujo comportamento muda a cada interação.
Por que sua pilha IAM faz isso com você
Este não é um erro de configuração. É uma suposição estrutural incorporada ao gerenciamento de identidade e acesso. Os sistemas que você executa assumem que um ator é uma de duas coisas: uma pessoa ou uma conta de serviço de longa duração com um conjunto de permissões estáticas. Ambos são estáveis. Ambos fazem aproximadamente a mesma coisa todos os dias. Seus controles, seu modelo de auditoria e seus fluxos de provisionamento são todos construídos com base nessa estabilidade.
Os agentes não são nenhum dos dois. Eles agem em nome de pessoas, portanto não são contas de serviço. Eles são softwares que funcionam e desmontam de acordo com sua própria programação, portanto não são pessoas. Eles ficam na lacuna para a qual sua pilha IAM não tem uma categoria, e a lacuna é onde a credencial é emprestada.
O take-away
Se seus agentes forem autenticados como os humanos que os implantaram, você terá um problema de herança de privilégios em produção no momento. Encontre-o antes que um auditor ou um incidente o faça: procure chaves de API humanas usadas por processos não humanos e registros de auditoria nos quais você não consegue diferenciar as ações do agente das ações humanas.
A solução superficial é parar de compartilhar chaves. A verdadeira solução é mais difícil. Um ator não determinístico não pode ser governado por uma concessão estática em tempo de design, o que significa que o agente precisa de uma identidade construída para autoridade que é decidida em tempo de execução, e não de um passaporte carimbado uma vez na fronteira.
Isso levanta a questão óbvia. Se o agente precisa de sua própria identidade, do que essa identidade é realmente feita e é algo mais do que a identidade da carga de trabalho que você já executa? Essa é a próxima postagem.