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 falta de higiene do ponto de vista do controle de origem, mas também pode enfraquecer a segurança da sua aplicação. Vamos nos aprofundar para descobrir alguns dos principais riscos de armazenar segredos em seus repositórios de código e o que você, como engenheiro de segurança de aplicações, pode fazer para descobrir riscos desnecessários.
Primeiro precisamos definir o que é um Segredo: normalmente, os segredos podem ser…
- Chaves de API
- Senhas do sistema estático
- Chaves de criptografia
- Tokens OAuth
- Senhas do banco de dados
A Ameaça Externa:
Em julho, foi noticiado que a Binance (Crypto Exchange) sofreu o que é chamado de "Maior Violação de Dados da História". Estima-se que cerca de 1 bilhão de registros tenham sido roubados. Como essa violação de dados aconteceu? Tudo se resumiu a um simples trecho de código, contendo segredos – que foi então compartilhado em um blog chinês. Os invasores conseguiram, posteriormente, usar os segredos expostos para aumentar 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, colaborativo entre toda a 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 no mundo CI/CD, permitindo que as equipes de engenharia ajam rapidamente. Ter segredos em sua base de código só aumenta a probabilidade de que ela caia nas mãos erradas (potencialmente de um agente de ameaça) – e, em última análise, aumenta o risco de levar a uma violação de dados.
Uma vez violado, torna-se quase impossível para suas equipes de segurança detectar esse nível de acesso, porque a atividade parecerá normal (segredos legítimos são usados!). Até, é claro, seus dados serem publicados na dark web para venda…
A Ameaça Interna:
Os desenvolvedores não deveriam ter ou precisar de acesso aos sistemas de produção – e, em teoria, os engenheiros de suporte também não (problema diferente, rs). Quando segredos estáticos são definidos na sua base de código, contratantes terceirizados e desenvolvedores desonestos agora têm a capacidade de aumentar seus privilégios e obter acesso a áreas dos sistemas de produção às quais não deveriam ter acesso em primeiro lugar (princípios do acesso menos privilegiado).
É mais importante do que nunca que as equipes de segurança de produtos se concentrem na construção de mecanismos de autenticação, soluções de acesso just-in-time e tragam suas próprias soluções-chave. Se houver segredos desprotegidos nesse código, isso elimina os efeitos que essas soluções terão na mitigação geral de riscos do seu produto e aumenta a probabilidade de desenvolvedores desonestos (e terceiros contratados) explorarem esses segredos codificados 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ê pode começar a descobrir onde eles podem estar?
Começa conectando 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 eles. Quer você use ofuscação no código ou chamadas autenticadas para o cofre de chaves/certificações externo ao seu ambiente de produção, eliminar esse risco é uma vitória fácil para reduzir o risco geral para seus clientes e seu produto.
E nós temos você coberto: ambos BigID e ID pequeno conectar-se facilmente a GitHub, GitLab e BitBucket para escanear repositórios de código. Usamos ambos capacidades de aprendizagem de máquina e políticas de detecção de segredos prontas para uso para detectar 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
