Mitigando o risco cibernético de terceiros através da gestão de contas de serviço, tokens, shared secrets e agentes

Em 2025 e 2026, vários incidentes na cadeia de fornecimento (supply chain) de software comprometeram pacotes e repositórios em plataformas relevantes, incluindo GitHub, npm e o Python Package Index (PyPI). Essas campanhas começaram com modificações em pacotes populares, que foram então distribuídos junto dos softwares que os tinham como dependência.

Em muitos casos, especialmente quando os invasores utilizaram códigos baseados em worms como o "Shai-Hulud", o código malicioso trazia um mecanismo de propagação para se infiltrar em outros pacotes aos quais as vítimas tinham acesso. Até a campanha de ataque ser contida peloas plataformas, centenas de pacotes foram adulterados em cada incidente.

Embora a carga maliciosa varie de um caso para outro, os hackers normalmente miram o que chamamos de secrets. Esses secrets são tokens de autenticação presentes no sistema do usuário, capazes de conceder acesso aos repositórios e outros ativos ou sistemas.

Como os principais alvos dessas campanhas são engenheiros de software, os atacantes frequentemente usam os secrets coletados em duas atividades desse contexto. A primeira delas é a adulteração de repositórios para começar novas campanhas. A segunda é a realização de varreduras em repositórios privados para obter um número ainda maior de secrets, incluindo possíveis detalhes de contas de serviço (service accounts) e tokens de APIs.

Esses tokens usados pelas aplicações abrem as portas para sistemas corporativos e buckets de armazenamento em nuvem, viabilizando ataques de ransomware. Mesmo quando os hackers não obtêm acesso de escrita, o que impede a característica cifragem de dados do ataque de ransomware, o acesso de leitura é suficiente para extorquir a empresa atacada com um vazamento de dados.

Infelizmente, as adulterações em pacotes não são a única fonte de exposição desses secrets. O abandono de projetos, erros operacionais e descuidos podem fazer com que chaves de autenticação e tokens de API apareçam em repositórios públicos e outros locais similares. Um relatório detalhando exatamente esse fenômeno foi publicado há algumas semanas, após pesquisadores encontrarem cerca de 9 mil chaves ligadas ao AWS (Amazon Web Services) expostas em repositórios públicos, com 526 delas dando acesso root ao respectivo ambiente.

Outros terceiros podem inesperadamente estar envolvidos nesses vazamentos também. Em 2023, a Okta sofreu um ataque no sistema de gestão de suporte técnico, e o invasor conseguiu baixar logs contendo tokens de sessão. Ainda que esses tokens de sessão estejam vinculados a identidades de usuário (e não a identidades de máquina), eles funcionam da mesma forma que tokens de API, uma vez que são usados diretamente pelas aplicações para autenticar o usuário.

Cabe explicar essa diferença. Credenciais destinadas ao usuário são formadas por um login, uma senha e um código único ou outro fator secundário de autenticação quando o recurso de 2FA/MFA estiver habilitado. Já tokens e chaves são sequências destinadas para autenticação direta por meio de aplicações.

Ao contrário da senha, o token geralmente não exigirá outra etapa de autenticação. Quem tem esse token tem tudo para acessar a conta.

Aplicações nunca esquecem suas credenciais nem erram a "senha", então fazer a troca periódica desses secrets e torná-los impossíveis de adivinhar não é um problema neste caso. Porém, senhas vazadas contam com a proteção de fatores extras de autenticação que não existem para chaves ou tokens adquiridos de forma limpa. É isso que torna esses secrets tão valiosos para os invasores.

Embora seja fácil trocar um token, o problema é que eles podem ser numerosos ou estarem sujeitos a certas condições complexas que restringem a troca e impedem que ela aconteça no ritmo desejado. Além disso, um mesmo secret pode ser compartilhado por dois sistemas que estão conectados por meio de uma aplicação (são os shared secrets), o que cria mais de um ponto de vazamento. 

Apesar desses desafios, os shared secrets aparecem na espinha dorsal das infraestruturas de TI, conectando as aplicações de empresas em todo o mundo.

Se você já sabe como isso aconteceu, você pode pular para as nossas recomendações na última seção. Se você não está tão familiarizado com identidades de máquina e (machine identities) e conceitos relacionados, a seção a seguir explica como a maneira com que construímos e conectamos sistemas de TI foi redefinida ao longo das últimas duas décadas, em grande parte como consequência da computação em nuvem e da adoção do software como serviço (Software-as-a-Service, SaaS).

O deslocamento do perímetro para a identidade

Em certo sentido, os padrões do setor de TI hoje esperam uma infraestrutura mais restritiva do que nunca. As boas práticas de cibersegurança recomendam arquiteturas de Zero Trust, nas quais não há uma rede "segura" nem confiança implícita, tal como existia no passado (e ainda encontramos por aí). Por padrão, um sistema destinado a uso restrito não deve olhar para a origem de uma conexão. Afinal, ninguém pode ter acesso sem estar autenticado.

A antiga visão do perímetro evoluiu nessa direção para ampliar a flexibilidade sem impor requisitos complexos de segurança e de infraestrutura. Pudemos migrar sistemas para a nuvem e compartilhar dados com facilidade, independentemente de onde estivessem armazenados, e as APIs se encarregaram de padronizar os formatos. Com essa mudança de paradigma, os sistemas corporativos tinham uma saída segura para deixar o perímetro e a confiança implícita atrelada à origem da requisição.

Ainda que as identidades de usuário funcionem bem para as interações entre humanos e software, elas não são muito práticas para que computadores conversem entre si. É aí que entram as contas de serviço (service accounts), chaves de API, certificados e outros tokens de autenticação voltados para aplicações. Esses tokens concedem uma permissão silenciosa e eficiente para que os sistemas acessem recursos relevantes, redefinindo o significado de "confiança" para aplicações e sistemas. Como consequência, redefiniu-se também o significado de estar conectado.

Estar "conectado" hoje é ter uma conta de serviço ou credencial que autorize solicitações a um sistema ou aplicação. A amplitude e o alcance da conectividade são determinados pelos privilégios da credencial e pelo número de sistemas de terceiro aos quais ela concede acesso.

Com o avanço dos agentes de IA, a ideia de "identidades de máquina" também vem ganhando atenção. Esse conceito é interessante por enfatizar a verdadeira natureza desses mecanismos de autenticação: sendo credenciais, eles podem ser entendidos como identidades para controle de acesso e monitoramento de atividades.

São essas identidades que devemos enxergar como uma "conexão" hoje. Associar a conectividade aos gateways de VPNs, links MPLS ou cabos enterrados pela cidade não nos ajuda mais a entender a interconectividade da infraestrutura moderna de TI.

Essa conectividade de alto nível é robusta, mas temos que manter em mente seus efeitos, especialmente quando sistemas estão em ambientes de nuvem ou em plataformas de SaaS. Agora, a infraestrutura de TI existe para acessar dados, não importa onde estejam.

Os dados que estão em risco de serem expostos é a soma de tudo que é acessível com os privilégios de uma credencial, incluindo secrets e contas de serviço. O local onde os dados estão armazenados é bem menos relevante em um cenário no qual as barreiras da rede deram lugar às identidades.

Gerenciando contas de serviço e chaves de API

Via de regra, empresas e terceiros devem buscar o meio mais seguro para integrar suas aplicações. O CTO da Tenchi Security, Alexandre Sieira, falou sobre os benefícios do cross-account access (ou "acesso entre contas") em uma palestra de 2020, e os benefícios que ele comentou à época continuam valendo.

A configuração de acesso pela via de shared secrets tende a ser mais fácil, mas a complexidade aparece na gestão desses segredos. Durante o tratamento de incidentes, provedores de serviços muitas vezes têm de obrigar seus clientes a trocarem as chaves utilizadas. Se chaves e tokens forem invalidados unilateralmente, o sistema ficará temporariamente inoperante.

Também não é incomum que secrets não sejam rotacionados corretamente, seja porque algum deles não foi documentado ou porque um token antigo não foi invalidado após uma troca de sistema que o descartou.

Se secrets desse tipo forem a única opção, é imprescindível adotar trocas automáticas (automatic rotation) e armazenar as chaves na infraestrutura adequada, como o Key Management Service da Amazon ou Secret Manager do Google.

Detectando contas de serviço

O primeiro desafio na gestão de contas de serviço é detectá-las. Em um mundo ideal, toda conta que não foi destinada a um ser humano estaria marcada como tal e seria tratada da forma adequada.

Embora infelizmente não estejamos nesse mundo ideal, há algumas pistas que podemos usar para deduzir que uma conta é de serviço. Por exemplo, se todos os usuários estão obrigados a ativar a autenticação multifator, isso significa que contas sem este recurso estarão irregulares ou estão em uso por aplicações.

Com as permissões adequadas, provedores de nuvem oferecem sinais que nos ajudam a coletar informações como essa. É assim que o Zanshin pode realizar varreduras privativas e seguras nos diretórios de usuários e serviços de gestão de identidades para detectar contas sem MFA habilitado.

Usuários com senhas muito antigas ou usuários que possuem simultaneamente chaves de acesso e senhas também podem ser conta de serviço disfarçadas. O Zanshin pode alertar sobre estes casos, permitindo que uma empresa e seus terceiros realizem o mapeamento das contas e apliquem configurações corretas.

O Zanshin também pode detectar contas e chaves de acesso que estão sem uso, indicando usuários inativos que devem ser desativados. Isso pode acontecer quando aplicações foram atualizadas para utilizar uma outra chave ou quando usuários não estão mais trabalhando para a empresa.

Controle de acesso

Uma das vantagens do uso de contas de serviço e identidades de máquina é que as permissões configuradas podem ser específicas e restritas às tarefas que a aplicação realizará.

Às vezes, contudo, as aplicações estão usando uma conta de serviço que não foi dedicada a ela. Nesses casos, muitas vezes o que está em uso é uma conta de serviço padrão com permissões excessivas. O Zanshin pode alertar sobre esse comportamento em alguns ambientes (como no Google Cloud), além de detectar quando as contas têm permissões genéricas (wildcard) e outras configurações inseguras.

No caso de tokens e chaves, o Zanshin pode detectar problemas como a ausência de trocas automáticas ou chaves que não seguem uma política de menor privilégio. Isso também é possível graças às APIs disponibilizadas por cada plataforma.

Como o Zanshin realiza essas checagens diariamente, ele garante continuamente a conformidade com as normas de segurança, ao contrário de avaliações pontuais, como questionários e auditorias isoladas. Já falamos em detalhes sobre os benefícios do monitoramento contínuo inside-out em um artigo anterior.

Resguardando repositórios para proteger secrets

O código-fonte de um software não deve conter chaves e tokens, mas há muitas circunstâncias que fazem com que isso aconteça. As empresas podem pedir que seus terceiros evitem essa prática, mas exigir o compartilhamento do código-fonte para uma auditoria traz uma série de riscos.

Por exemplo, um terceiro pode se incomodar com o risco de que um incidente em qualquer um de seus clientes provoque um vazamento do código-fonte compartilhado para fins de auditoria. Aliás, geralmente nenhuma empresa quer que seus terceiros fiquem expostos a riscos derivados dos terceiros deles desta forma. 

Mas isso não significa que nada pode ser feito para impedir ou mitigar o vazamento desses secrets e do próprio código-fonte. Plataformas de desenvolvimento como GitHub, GitLab e Bitbucket expõem dados sobre as configurações dos repositórios sem expor o código em si, permitindo validar se os terceiros estão fazendo o possível para proteger o código.

Permissões para criar forks de repositórios, webhooks inseguros e até a existência de repositórios públicos em ambientes nos quais eles não deveriam existir são ótimos sinais para avaliar a diligência de um terceiro quanto à segurança do processo de desenvolvimento. O Zanshin tem visibilidade sobre esses e muitos outros pontos.

Assim como no caso de contas de serviço e tokens, é importante conferir a segurança dos usuários que têm acesso ao repositório, o que o Zanshin também é capaz de fazer.

Ainda que isso não previna todos os incidentes, o Zanshin conta com muitas outras regras para estratégias de defesa em profundidade, incluindo questões como a habilitação de registros (logs) que vão permitir detectar e investigar incidentes.

Você pode aplicar essas ideias e coletar esses sinais pessoalmente ou pedir que os terceiros o façam por você, mas o Zanshin oferece automação, robustez, relatórios de gestão e orientação para você e seus terceiros. É possível solicitar uma demonstração para ver na prática o que o Zanshin pode encontrar em seu ambiente e no ambiente dos seus terceiros.

‍