Gestão de Segredos

Quando estamos desenvolvendo nossas soluções, é comum precisarmos conectar diferentes serviços.

Comumente estes serviços exigem algum tipo de credencial, apikey, token ou qualquer informação de acesso.

Como exemplo temos credenciais de acesso ao banco de dados, chaves de api do google, certificados digitais, credenciais da AWS, etc.

Mas o que aconteceria se estas informações caíssem em mãos erradas?

Por este motivo precisamos ter certos cuidados com algumas informações...

Checklist

Segredos no Código

Não devemos deixar qualquer segredo fixo no código:

Secret Hardcoded
// 🚫 BAD
const db = new DB({
  user: 'DbUser',
  pass: 'DbP@ss0rd!'
})

Para resolver isso, podemos utilizar Variáveis de Ambiente...

Variáveis de Ambiente
// ✅ GOOD
const db = new DB({
  user: process.env.DB_USER,
  pass: process.env.DB_PASS
})

Ou Cofre de Senhas:

Hashicorp Vault
const vault = require("node-vault")({
  apiVersion: process.env.VAULT_VERSION,
  endpoint: process.env.VAULT_URL,
});

const roleId = process.env.ROLE_ID;
const secretId = process.env.SECRET_ID;

const run = async () => {
  const result = await vault.approleLogin({
    role_id: roleId,
    secret_id: secretId,
  });

  vault.token = result.auth.client_token;

  const { data } = await vault.read("secret/data/mysql/webapp");

  const databaseName = data.data.db_name;
  const username = data.data.username;
  const password = data.data.password;

  console.log({
    databaseName,
    username,
    password,
  });
};

run();

Este tipo de informação podem estar em vários lugares:

  • Código

  • Arquivos de Configurações (web.config, .env, application.properties, etc)

  • READMEs

Gestão de Acessos

Ok, já removemos os segredos chumbados no código, wikis, e etc. Mas e as informações de acesso que as pessoas precisam ter, como uma credencial de consulta ao banco ou painel de logs, como fica? Como o time de desenvolvimento vai realizar a correção de um problema ou ter acesso às plataformas?

É comum que os membros dos times tenham senhas, certificados ou chaves para acessar ambientes e ferramentas. O cuidado com esta informação também é importante.

Para isso, alguns cuidados precisam ser tomados:

Credenciais Nominais

Cada membro do time que tiver acesso à uma ferramenta ou plataforma deve ter sua própria credencial, com o perfil específico para suas necessidades.

Escopo de Acesso

Quando acontecem problemas em produção ou alguma nova funcionalidade exigir uma análise do ambiente para evitar breaking changes, o time precisa de informações.

Em vez de ficarmos restringindo o acesso à tudo, criando atrito e atrasando as demandas do trabalho, foquemos em uma pergunta:

O que precisa ser protegido?

Talvez você chegue na conclusão de:

  • Não podem realizar operações de escrita.

  • Não podem acessar dados pessoais, sensíveis e sigilosos.

Ótimo, é aqui que está o trabalho.

Chegar para o time e dizer:

"E ai pessoas, estamos dando liberdade para vocês, só não vamos habilitar o acesso aos dados das pessoas e operações de escrita para não comprometer o ambiente, beleza?"

É MUITO melhor que perguntar:

"O que vocês precisam?"

Pelo simples motivo que na c#r@lh4 de um WAR ROOM ninguém sabe o que precisa (além do café e uma aspirina, é claro) e no fim você precisar dar acesso a tudo por causa da pressão.

Riscos

CWE-798: Use of Hard-coded Credentials

  • Alguém não autorizado ter acesso à credenciais de produção pelo simples fato de ter acesso ao código fonte ou documentação.

  • Alguém colocar o código em ambiente público (github pessoal público, pastebin, etc) e as secrets vazarem.

Guias

Tools

Gerenciador de senhas (pessoal / teams).

Para uso pessoal, é free, open source e pode ser utilizado em múltiplos dispositivos.

Para empresas, pode ser utilizado como vault.

Recomendamos o bitwarden para uso de gerenciador de senhas pessoal =).

Open source password manager for teams.

Pode ser instalado de diversas formas, mas o principal: tem um docker-compose =).

Vault para armazenamento de senhas, certificados ou qualquer outra informação sensível.

Tem opção free e self-hosted.

Tool de linha de comando para detecção de secrets hardcoded.

Roda a partir de docker e é capaz de detectar mais de 700 tipos de credenciais.

Pode realizar o scan em Github, Gitlab, FileSystem, Logs e Buckets S3.

Executar o trufflehog com docker
docker run -it -v "$PWD:/pwd" \
    trufflesecurity/trufflehog:latest \
    github \
    --org=trufflesecurity

O Gitlab (em todas as suas versões) possui nativamente um scan para segredos hard-coded.

A versão free é limitada com relação à ultimate, mas é uma ótima opção caso a corporação não queira adotar uma ferramenta externa ou deseja usar 100% da plataforma que já paga.

O Github tem um scan de secrets embarcado também.

Sua execução é automática em todos os repositórios, mas existem opções extras caso o Advanced Security seja adquirido.

Tutorials

Vídeos

Last updated