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:
Para resolver isso, podemos utilizar Variáveis de Ambiente
...
Ou Cofre de Senhas
:
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.
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.
Links Úteis
Tutorials
Vídeos
Last updated