Em um mundo baseado em código, é conveniente para os desenvolvedores armazenar segredos estáticos e arquivos de configuração contendo senhas junto com o código que desenvolvem. Isso não só é uma má prática do ponto de vista do controle de versão, como também enfraquece a segurança da sua aplicação. Vamos explorar alguns dos principais riscos de armazenar segredos em repositórios de código e o que você, como engenheiro de segurança de aplicações, pode fazer para eliminar riscos desnecessários.
Primeiramente, precisamos definir o que é um segredo: tipicamente, segredos podem ser…
- Chaves de API
- Senhas estáticas do sistema
- Chaves de criptografia
- Tokens OAuth
- Senhas do banco de dados
A ameaça externa:
Em julho, foi noticiado que a Binance (corretora de criptomoedas) sofreu o que foi considerado o "Maior Vazamento de Dados da História". Estima-se que cerca de 1 bilhão de registros foram roubados. Como esse vazamento de dados aconteceu? Tudo começou com um simples trecho de código, contendo informações confidenciais, que foi compartilhado em um blog chinês. Os invasores conseguiram usar essas informações para escalar privilégios e se movimentar lateralmente sem serem detectados no ambiente do produto.
A engenharia deve ser um esforço colaborativo entre equipes — e, em alguns casos, em toda uma comunidade. Trechos de código são frequentemente compartilhados para fins de solução de problemas, e o software de código aberto tornou-se essencial em um mundo de CI/CD, para permitir que as equipes de engenharia trabalhem com rapidez. Ter segredos em sua base de código apenas aumenta a probabilidade de que ela caia em mãos erradas (potencialmente de um agente malicioso) — e, em última análise, aumenta o risco de levar a uma violação de dados.
Uma vez invadido, torna-se quase impossível para suas equipes de segurança detectarem esse nível de acesso, pois a atividade parecerá normal (segredos legítimos são usados!). Até, é claro, que seus dados sejam publicados na dark web para venda…
A Ameaça Interna:
Os desenvolvedores não deveriam ter, nem precisar ter, acesso aos sistemas de produção — e, em teoria, os engenheiros de suporte também não (problema diferente, rsrs). Quando segredos estáticos são definidos na sua base de código, terceirizados e desenvolvedores desonestos passam a ter a capacidade de escalar seus privilégios e obter acesso a áreas dos sistemas de produção às quais não deveriam ter acesso em primeiro lugar (princípio do menor privilégio).
É mais importante do que nunca que as equipes de segurança de produtos se concentrem na criação de mecanismos de autenticação, soluções de acesso just-in-time e soluções de chave própria (WIK). Se houver segredos desprotegidos nesse código, isso anula os efeitos que essas soluções teriam na mitigação geral de riscos do seu produto e aumenta a probabilidade de desenvolvedores mal-intencionados (e contratados terceirizados) explorarem esses segredos embutidos no código para obter acesso não autorizado ao seu produto e/ou dados.
O que devo fazer?
Armazenar segredos e senhas em sua base de código (ou repositórios de código) nunca é uma boa ideia, mas como você começa a descobrir onde eles podem estar?
Tudo começa com a conexão do seu código. repositórios para uma ferramenta que escaneia e identifica segredos e senhas. O objetivo final é Descubra 100% dos seus segredos e senhas no seu código. e rapidamente remediar Seja utilizando ofuscação no código ou chamadas autenticadas para um cofre de chaves/certificados externo ao seu ambiente de produção, eliminar esse risco é uma maneira fácil de reduzir o risco geral para seus clientes e seu produto.
E nós temos a solução para você: ambos BigID e ID pequeno conectar-se facilmente a GitHub, GitLab e BitBucket para analisar repositórios de código. Usamos ambos capacidades de aprendizado de máquina e políticas de detecção de segredos prontas para uso, que detectam segredos e senhas em sua base de código para melhorar sua postura de risco de dados... onde quer que você esteja armazenando esses segredos, intencionalmente ou não.
Autor
