Uma empresa de tecnologia logística havia emitido chaves de API para quarenta e três parceiros de integração e aplicações internas ao longo de quatro anos. Uma revisão de segurança constatou que onze das quarenta e três chaves haviam sido emitidas para aplicações ou integrações que não estavam mais ativas: a aplicação havia sido desativada, a relação com o parceiro de integração havia terminado ou o caso de uso havia sido substituído por outra implementação. Todas as onze chaves continuavam ativas. Três das onze ainda geravam chamadas de API, chamadas que não vinham das aplicações desativadas nem das integrações encerradas, mas de origens não identificadas que haviam obtido as chaves. Uma chave havia sido exposta em um commit público no GitHub, e as chamadas vinham de mais de quarenta endereços IP distintos. A empresa de logística não tinha nenhum processo de gestão do ciclo de vida das chaves de API. As chaves eram emitidas por meio de um sistema de solicitações e revogadas somente quando alguém solicitava especificamente a revogação. Ninguém havia solicitado especificamente a revogação das chaves de aplicações que foram simplesmente desativadas sem alarde nem de integrações que simplesmente terminaram sem alarde. Onze chaves inativas. Três exploradas ativamente. Uma exposta na internet pública durante quatro semanas antes que o repositório do GitHub fosse tornado privado.
O que é, de fato, o uso indevido de identidades de API?
Identidades de API são as credenciais (chaves de API, segredos de cliente, tokens OAuth e tokens de autenticação semelhantes, legíveis por máquina) usadas por aplicações, integrações e processos automatizados para se autenticar em APIs e plataformas. Elas são o equivalente, para máquinas, das senhas de usuários: um segredo compartilhado que comprova que a parte que o apresenta tem direito de acessar a API. Como as senhas de usuários, elas podem ser roubadas, compartilhadas, fixadas no código, expostas em repositórios públicos e usadas além do escopo pretendido. Diferentemente das senhas de usuários, elas são emitidas em escala enorme (a maioria das organizações tem muito mais chaves de API em circulação do que contas de usuário) e são governadas com muito menos rigor de ciclo de vida do que as credenciais de usuários.
O problema do abandono do ciclo de vida é a raiz estrutural do uso indevido de identidades de API. Contas de usuário são criadas para pessoas específicas e, quando essas pessoas saem ou mudam de função, os processos de desligamento e de revisão de acessos criam pressão para revisar e atualizar seus acessos. Chaves de API são criadas para aplicações específicas e, quando essas aplicações são desativadas ou as integrações terminam, não há nenhum evento equivalente que crie pressão organizacional para revisar e revogar as chaves associadas. A aplicação deixa de rodar. A chave continua existindo, válida e ativa, à espera de quem a encontrar.
O problema da exposição em repositórios de código tornou-se, na última década, um dos vetores mais comuns de comprometimento de chaves de API. Desenvolvedores que fixam chaves de API no código das aplicações durante o desenvolvimento e os testes (uma prática disseminada, explicitamente proibida por todas as normas de segurança, mas extremamente comum na prática) criam um risco de exposição persistente toda vez que esse código é enviado a um repositório. Se o repositório ficar público, ainda que brevemente (um repositório público do GitHub que depois foi tornado privado), a chave fica exposta a ferramentas automatizadas que coletam continuamente credenciais de repositórios públicos. Chaves de API encontradas em repositórios públicos costumam ser exploradas poucos minutos após a exposição. Tornar o repositório privado não remove a chave das ferramentas que já a coletaram.
- Chaves de aplicações desativadas que continuam ativas: chaves de API não revogadas quando a aplicação para a qual foram emitidas sai de operação
- Chaves de integrações encerradas que persistem: chaves emitidas para parceiros de integração cuja relação terminou continuam ativas e válidas
- Chaves fixas em repositórios de código: chaves de API incorporadas ao código-fonte enviado a repositórios de controle de versão
- Sem detecção de anomalias de uso: uso de chaves de API não monitorado quanto a atividade de origens inesperadas
- Nenhum processo de gestão do ciclo de vida das chaves: chaves revogadas apenas mediante solicitação específica, e não por revisão sistemática do ciclo de vida
Por que isso importa
O uso indevido de identidades de API é relevante para TPRM porque as chaves de API são o principal mecanismo pelo qual aplicações de fornecedores e parceiros de integração acessam as plataformas dos clientes, e a gestão do ciclo de vida dessas chaves determina se o acesso que elas concedem permanece dentro do escopo pretendido ou se ultrapassa esse escopo no tempo e na abrangência. Uma plataforma de cliente que emite chaves de API para fornecedores e parceiros de integração sem gestão do ciclo de vida acumula credenciais inativas e potencialmente comprometidas que representam acesso válido à plataforma muito depois de a finalidade do acesso ter terminado.
A dimensão da cadeia de suprimentos tem consequências especialmente graves. Chaves de API emitidas para fornecedores de integração com acesso a plataformas específicas podem estar fixas no código da aplicação do fornecedor, armazenadas em seus repositórios de código-fonte ou passar por seus ambientes de desenvolvimento e teste. Cada um desses caminhos representa um vetor de exposição pelo qual a chave pode ser coletada sem uma violação direta do cliente ou do fornecedor: a exposição de um repositório público, o comprometimento da estação de trabalho de um desenvolvedor ou um pipeline de CI/CD que registra variáveis de ambiente em log. A chave dá acesso à plataforma do cliente, independentemente de como foi obtida.
Para profissionais de TPRM, avaliar a governança de chaves de API exige perguntar sobre os processos de gestão do ciclo de vida, o monitoramento de uso e a detecção de exposição, e não apenas se as chaves são documentadas na emissão. A documentação de emissão descreve o uso pretendido. A gestão do ciclo de vida, o monitoramento de uso e a detecção de exposição governam o que de fato acontece com a chave ao longo da sua vida operacional.
Onde a maioria das equipes erra
A falha mais recorrente é tratar a documentação de emissão de chaves de API como governança de chaves de API. Documentar para qual aplicação uma chave foi emitida não impede que a chave sobreviva à aplicação, não detecta o uso a partir de origens inesperadas e não monitora a exposição em repositórios. A documentação de emissão é o registro. A gestão do ciclo de vida é a governança.
- Tratar a documentação de emissão de chaves como governança de chaves
- Nenhum gatilho de ciclo de vida para a desativação de aplicações: chaves não revisadas quando as aplicações são aposentadas
- Nenhum monitoramento de uso a partir de origens inesperadas: chaves usadas por origens não autorizadas não são detectadas
- Nenhuma varredura de repositórios em busca de chaves fixas no código
- Revogação de chaves dependente de solicitação explícita, e não de revisão sistemática
Como é uma boa prática
Programas maduros de governança de chaves de API tratam o ciclo de vida das chaves como vinculado ao ciclo de vida das aplicações: chaves emitidas para aplicações específicas são revisadas quando essas aplicações mudam de estado, a varredura automatizada detecta chaves fixas em repositórios de código antes da exposição e o monitoramento de uso sinaliza chaves que estão sendo usadas a partir de origens inesperadas.
- Desativação de aplicações motiva revisão de chaves: chaves associadas a aplicações em desativação são sinalizadas automaticamente para revogação
- Varredura de repositórios em busca de chaves fixas no código: varredura automatizada de repositórios de código em busca de padrões de chaves de API
- Detecção de anomalias de uso: uso de chaves de API monitorado quanto a chamadas de origens inesperadas, volumes incomuns ou padrões suspeitos
- Política de expiração e rotação de chaves: chaves de API emitidas com data de expiração definida, e não com validade indefinida
- Inventário de chaves com data do último uso: todas as chaves ativas documentadas com data de emissão, aplicação associada e registro de data e hora do último uso
Ferramentas
Varredura de segredos: GitHub Advanced Security, GitLab Secret Detection, Trufflehog, Gitleaks
Ferramentas de varredura de segredos analisam repositórios de código, tanto os commits quanto o histórico de commits, em busca de chaves de API, credenciais e outros segredos enviados ao controle de versão. O GitHub Advanced Security oferece varredura nativa de segredos que gera alertas quando credenciais que correspondem a padrões conhecidos de chaves de API são encontradas em commits. Para profissionais de TPRM, perguntar se o fornecedor usa varredura automatizada de repositórios em busca de chaves de API fixas no código é uma pergunta específica sobre a detecção de exposição no código.
Segurança de API: Salt Security, 42Crunch, Noname Security
Plataformas de segurança de API monitoram o tráfego de API em busca de padrões de uso anômalos, detectando chaves usadas a partir de origens inesperadas, volumes de chamadas incomuns, padrões incomuns de acesso a endpoints e outros indicadores de que uma chave pode estar comprometida. Para profissionais de TPRM, perguntar se o fornecedor monitora o uso de chaves de API em busca de padrões anômalos é uma pergunta específica sobre a detecção do uso indevido de chaves.
Gestão de segredos: HashiCorp Vault, AWS Secrets Manager
Plataformas de gestão de segredos oferecem gestão do ciclo de vida das chaves de API, armazenando as chaves com segurança, permitindo a rotação automática e fornecendo logs de acesso que permitem detectar o uso inesperado de chaves. Substituir chaves de API fixas no código ou de segredo compartilhado por chaves gerenciadas por um gerenciador de segredos elimina o risco de chaves fixas no código e oferece gestão centralizada do ciclo de vida. Para profissionais de TPRM, perguntar se as integrações do fornecedor com as plataformas do cliente usam gestão de segredos para armazenar as chaves é a pergunta mais direta para prevenir chaves fixas no código.
Desafios de governança
O desafio de governança do ciclo de vida das chaves de API é o problema de escala somado ao desafio de atribuição. A maioria dos ambientes tem muito mais chaves de API do que contas de usuário, e as chaves são criadas por equipes de desenvolvimento, de integração e de operações sem registro central. Construir o programa de gestão do ciclo de vida exige primeiro construir o inventário (identificar todas as chaves ativas, as aplicações associadas e as datas do último uso) antes que os processos de ciclo de vida possam ser aplicados.
- Construa o inventário de chaves de API: todas as chaves ativas, com associação à aplicação, data de emissão e data do último uso
- Vincule o ciclo de vida das chaves ao ciclo de vida das aplicações: a desativação de uma aplicação motiva a revisão das chaves
- Implemente a varredura de repositórios: detecção automatizada de chaves fixas no código
- Adicione monitoramento de uso: chaves usadas a partir de origens inesperadas geram alertas
- Implemente a expiração de chaves: chaves emitidas com validade definida, exigindo renovação explícita
Se você faz parte de uma equipe pequena
Faça aos seus fornecedores integrados via API duas perguntas que revelam, ao mesmo tempo, o risco de ciclo de vida e o de exposição. Primeira: vocês podem fornecer um inventário de todas as chaves de API atualmente ativas do seu lado para integrações com a nossa plataforma, incluindo a última data de uso de cada chave e a aplicação ou o serviço que a utiliza? Segunda: vocês usam varredura automatizada de repositórios para detectar chaves de API que possam ter sido fixadas no código em commits de desenvolvedores? A pergunta sobre o inventário revela chaves inativas e órfãs. A pergunta sobre a varredura revela o risco de exposição que termina em 847 chamadas de API de origens desconhecidas.
- Solicite o inventário das chaves de API mantidas pelo fornecedor, com datas do último uso
- Pergunte sobre a varredura automatizada de repositórios em busca de chaves de API fixas no código
- Pergunte sobre o monitoramento de anomalias de uso para detectar o uso indevido de chaves de API
- Implemente a expiração de chaves como requisito padrão para chaves de integração
O que exigir
Pergunte diretamente:
“Vocês podem fornecer um inventário de todas as chaves de API que mantêm atualmente para integrações com a nossa plataforma, incluindo data de emissão, aplicação associada e data do último uso, e confirmar que todas estão em uso por aplicações ativas e autorizadas?”
“Vocês usam varredura automatizada para detectar chaves de API fixas no código dos seus repositórios de desenvolvimento? Alguma chave associada à nossa plataforma já apareceu em um achado de varredura de repositório?”
O que esperar como evidência
- Inventário de chaves de API com datas do último uso e associação a aplicações
- Confirmação da varredura de repositórios com os resultados da última varredura
- Descrição do monitoramento de uso: como o uso inesperado de chaves é detectado
- Política de expiração e rotação de chaves
Um fornecedor cuja chave de API apareceu 847 vezes no último mês a partir de origens que não são a sua aplicação desativada tem um problema ativo de uso indevido de chaves. A documentação sobre a aplicação para a qual a chave foi emitida descreve com precisão a intenção da emissão. O log de uso descreve com precisão a realidade atual. A questão de governança é se algo liga os dois, ou seja, se alguém monitora a lacuna entre o uso pretendido e o uso real que as 847 chamadas representam.
Como comprovar
- Registros do inventário de chaves de API com verificação do último uso
- Evidências da implementação da varredura de repositórios
- Documentação da política de expiração de chaves
- Confirmação do monitoramento de anomalias de uso
Principal conclusão
A chave de API sobreviveu oito meses à aplicação para a qual foi criada. Ficou em um repositório público do GitHub durante quatro semanas. Foi usada 847 vezes este mês por origens que não são a aplicação desativada. A documentação de emissão registra com precisão a finalidade da chave. A gestão do ciclo de vida que deveria ter aposentado a chave quando a aplicação foi desativada não existe. O monitoramento de uso que deveria ter detectado chamadores inesperados está ausente. A varredura de repositórios que deveria ter sinalizado o commit com a chave fixa no código nunca foi executada. As três lacunas estavam presentes ao mesmo tempo. A chave está sendo usada indevidamente neste exato momento. A identidade de API é o tipo de credencial mais abundante na maioria dos ambientes e o menos governado. A documentação de emissão é o começo da governança. O ciclo de vida, o monitoramento e a varredura são o restante.