Explore o novo chatbot do Developer Center! O MongoDB AI chatbot pode ser acessado na parte superior da sua navegação para responder a todas as suas perguntas sobre o MongoDB .

Saiba por que o MongoDB foi selecionado como um líder no 2024 Gartner_Magic Quadrupnt()
Desenvolvedor do MongoDB
Centro de desenvolvedores do MongoDB
chevron-right
Idiomas
chevron-right
Python
chevron-right

Você consegue guardar segredo?

Aaron Bassett17 min read • Published Feb 03, 2022 • Updated May 12, 2022
MongoDBPython
Ícone do FacebookÍcone do Twitterícone do linkedin
Avalie esse Artigo
star-empty
star-empty
star-empty
star-empty
star-empty
A mediana de tempo para a descoberta de uma chave secreta vazada para o GitHub é 20 segundos. Quando você perceber seu erro e girar seus segredos, pode ser tarde demais. Nesta conversa, vamos ver algumas técnicas de gerenciamento de segredos que não interromperão seu fluxo de trabalho, mantendo seus serviços seguros.
Esta é uma transcrição completa da conferência2020 da PyCon Austrália "Você consegue manter um segredo?"Os gráficos também estão disponíveis para download noNotist.
Olá a todos. Obrigado por se juntar a mim hoje.
Antes de começarmos, gostaria apenas de dedicar um momento para Express meus profundos graças, Gratidão e Admiração a todos os envolvidos na PyCon Austrália deste ano. Eles fizeram um trabalho ótimo, em um momento realmente muito difícil.
Teria sido muito fácil para eles terem deixado de organizar uma conferência este ano, e ninguém os culparia se o fizessem, mas não o fizeram, e o que eles conquistaram deveria realmente ser comemorado. Então, um grande obrigado a eles.
Com isso dito, vamos começar!
Então, meu nome é Aaron Bassset.
Você pode me encontrar praticamente em todos os lugares como Aaron Bassett, porque eu não tenho imaginação. Twitter, GitHub, LinkedIn, provavelmente há uma conta antiga no MySpace e no Bebo em algum lugar também. Você pode me encontrar em todos eles como Aaron Bassett.
É consultor de programadores sênior no MongoDB.
Para qualquer um que nunca tenha lido do MongoDB antes, ele é um banco de dados distribuído, baseado em documentos e de uso geral, frequentemente chamado de banco de dados No-SQL. Temos um serviço de banco de dados em nuvem totalmente gerenciado chamado Atlas, um Enterprise Server on-premise, um banco de dados em dispositivos chamado Realm, mas provavelmente somos mais conhecidos por nosso Community Server gratuito e de código aberto.
Na verdade, muito do que fazem no MongoDB é open source e, como advogado do desenvolvedor, quase tudo o que produzo é open source e está disponível publicamente. Quer se trate de um tutorial, aplicativo de demonstração, conversa em conferência, fluxo do Twitch e assim por diante. Está tudo lá fora para usar.
Aqui está um exemplo do tipo de código que escrevo regularmente. Este é um pequeno trecho para executar uma query geoespacial.
1import pprint
2from pymongo import MongoClient
3
4client = MongoClient(
5 "C01.5tsil.mongodb.net",
6 username="admin", password="hunter2"
7)
8db = client.geo_example
9
10query = {"loc": {"$within": {"$center": [[0, 0], 6]}}}
11for doc in db.places.find(query).sort("_id"):
12 pprint.pprint(doc)
Primeiro, importamos nosso driver Python do MongoDB. Em seguida, instanciamos nosso cliente de banco de dados. E, finalmente, executamos nossa query. Aqui, estamos tentando encontrar todos os documentos cuja localização está dentro de um raio definido de um ponto escolhido.
Mas, mesmo neste pequeno exemplo, temos alguns segredos que realmente não devemos compartilhar. A primeira linha destacada aqui é o URI. Isto não é tanto um segredo, mas uma variável de configuração.
Algo que provavelmente mudará entre seus ambientes de desenvolvimento, encenação e produção. Então, você provavelmente também não quer que isso seja codificado. A próxima linha, no entanto, são os segredos reais. Nosso nome de usuário e senha do banco de dados. Esses são os tipos de segredos que você nunca quer codificar em seus scripts, nem por um momento.
1import pprint
2from pymongo import MongoClient
3
4DB_HOST = "C01.5tsil.mongodb.net"
5DB_USERNAME = "admin"
6DB_PASSWORD = "hunter2"
7
8client = MongoClient(DB_HOST, username=DB_USERNAME, password=DB_PASSWORD)
9db = client.geo_example
10
11query = {"loc": {"$within": {"$center": [[0, 0], 6]}}}
12for doc in db.places.find(query).sort("_id"):
13 pprint.pprint(doc)
Muitas vezes, vejo alguém colocando seus segredos em variáveis, seja na parte superior do script§ ou, às vezes, codificando-os em um settings.py ou similar. Também já me fez isso.
Você tem toda a intenção de remover os segredos antes de publicar seu código, mas, alguns dias depois, as crianças estão tentando chamar sua atenção, você precisa ir fazer seu café da manhã, ou há um dos milhões de outras coisas que acontecer no nosso dia a dia distraí-lo e, à medida que você se levanta, decide salvar seu rascunho de trabalho, a memória motora entra em ação...
1git add .
2git commit -m "wip"
3git push
E... bem... é só isso.
Basta um intervalo momentâneo e agora seus segredos são públicos, e assim que esses segredos atingirem o GitHub ou outro repositório público, você deverá presumir que eles foram imediatamente violados.
Michal Meli, Matthe R. MacNiece e Bradlei Reaves, da Universidade do estado da Carolina do Norte, publicaram um trabalho de pesquisa intitulado "Como pode ser ruim o Git? Caracterizar o vazamento secreto em repositórios públicos do GitHub".
Essa pesquisa mostrou que o tempo médio de descoberta de um segredo publicado no GitHub era de 20 segundos e poderia ser tão baixo quanto meio segundo. Pareceu-lhes que o único fator limitante sobre a rapidez com que você poderia descobrir segredos no GitHub era a rapidez com que o GitHub era capaz de indexar um novo código à medida que ele era enviado.
O tempo mais longo em seus testes, desde o envio de segredos até que eles possam ser comprometidos, foi de quatro minutos. Não houve correlação entre a hora do dia etc. Provavelmente dependeria apenas de quantas outras pessoas estavam enviando código ao mesmo tempo. Mas depois que o código foi indexado, eles foram capazes de localizar os segredos usando algumas queries de pesquisa bem criadas.
Mas isso provavelmente não é novidade para a maioria dos desenvolvedores. Ok, a velocidade com que os segredos podem ser comprometidos pode ser surpreendente, mas a maioria dos desenvolvedores conhece os perigos de publicar seus segredos publicamente.
Muitos de nós provavelmente já ouvimos ou lemos histórias de terror de desenvolvedores que acidentalmente comprometeram suas chaves da AWS e acordaram com uma grande fatura quando alguém estava criando instâncias EC2 em sua conta. Então, por que nós, e estou me incluindo nisso, por que continuamos fazendo isso?
Porque é fácil. Sabemos que não é seguro. Sabemos que isso provavelmente nos prejudicará em algum momento. Mas é muito, muito fácil. E esse é o caso da maioria dos softwares.
Este é o triângulo de segurança. Representa o equilíbrio entre segurança, funcionalidade e usabilidade. É uma troca. À medida que dois pontos aumentam, um sempre diminuirá. Se tivermos um aplicativo que seja muito, muito seguro e tenha muitas funcionalidades, provavelmente parecerá bastante restritivo de usar. Se nosso aplicativo for muito seguro e muito utilizável, provavelmente não precisará fazer muita coisa.
Um bom exemplo de onde uma empresa trocou alguma segurança por funcionalidade e usabilidade adicionais é o botão One Click Buy da Amazon.
Funciona muito como o nome implica. Quando você quiser encomendar um produto, você pode clicar em um único botão e a Amazon fará seu pedido usando seu cartão de crédito e endereço de entrega padrão de seus registros. O que você pode não saber é que a Amazon não pode enviar o CVV com esse pedido. O CVV normalmente são os três números no verso do seu cartão, acima da faixa de assinatura.
Os emissores de cartões informam que você deve enviar o CVV para cada transação com cartão não presente. Cartão não presente significa que o varejista não pode ver que você tem o cartão físico em sua posse, portanto, toda transação on-line é uma transação com cartão não presente.
Ok, então os emissores dizem que você deve enviar o CVV todas as vezes, mas também dizem que você não DEVE armazená-lo. É por isso que, para quase todos os revendedores, mesmo que tenham seu cartão de crédito armazenado, você ainda precisará inserir o CVV durante o checkout, mas não a Amazon. A Amazon simplesmente não envia o CVV. Eles sabem que isso diminui sua segurança, mas para eles vale a pena compensar por funcionalidades adicionais e facilidade de uso.
Um exemplo ruim de onde uma empresa trocou a sanidade - me perdoe, quer dizer, segurança - por usabilidade aconteceu em uma agencia, ainda bem que agora extinta, em que trabalhei muitos, muitos anos atrás. Eles concluíram que, embora o armazenamento das senhas dos clientes em texto simples reduzisse sua segurança, valeu a pena em termos de usabilidade Dizer ao cliente sua senha pelo telefone quando eles ligaram.
Realmente era o oeste selvagem da web naquela época...
Portanto, um inquilino fundamental de tudo o que estou sugerindo aqui é que ele deve ter o menor atrito possível. Se for muito difícil, ou se reduzir muito o lado da usabilidade do nosso triângulo, as pessoas não o adotarão.
Também tem que ser fácil de implementar. Quero que essas sejam técnicas que você possa começar a usar pessoalmente hoje e implementá-las em sua equipe na próxima semana.
Não pode ter custos altos ou infraestrutura difícil de configurar e gerenciar. Porque, novamente, estamos competindo com variáveis de código rígido, sem dúvida o método mais fácil de armazenar segredos.
Então, como sabemos quando terminamos? Como medimos o sucesso deste projeto? Bem, para isso, vou pegar emprestado a metodologia12 factor apps.
A metodologia 12 factor apps foi projetada para permitir que aplicativos da web sejam criados com portabilidade e resiliência quando implantados na web. E abrange 12 fatores diferentes.
Codebase, dependências, configuração, serviços de backup, compilação, versão, execução e assim por diante. Estamos interessados apenas no número 3: Config.
Veja o que os aplicativos de fator 12 têm a dizer sobre configuração;
"Um teste decisivo para saber se um aplicativo tem todas as configurações corretamente excluídas do código é se a base de código pode ser transformada em código aberto a qualquer momento, sem comprometer nenhuma credencial"
E isso é superimportante mesmo para aqueles que nunca publicarão seu código publicamente. O que aconteceria se o seu código fonte vazasse agora mesmo? Em 2015, pesquisas da internetwache concluíram que 9700 sites no top um milhão do Alexa tinham sua pasta .git disponível publicamente na raiz do site. Isso incluiu sites do governo, ONGs, bancos, trocas de criptomoedas, grandes comunidades online, alguns sites pornográficos, oh e tv.
A distribuição de sites por meio de pulls do Git não é tão incomum quanto você pode pensar e, para esses sites, eles estão a apenas uma configuração incorreta do servidor de vazar seu código-fonte. Portanto, mesmo que seu aplicativo seja de código fechado, com código que nunca será intencionalmente publicado publicamente, ainda é obrigatório que você não grave segredos de código.
Vazar seu código-fonte seria horrível. Vazar todas as chaves do seu reino seria devastador.
Então, se não podemos armazenar nossos segredos em nosso código, onde os colocamos? As variáveis de ambiente são provavelmente o lugar mais comum.
Agora lembre-se de que estamos focados na facilidade de uso e na baixa restrição à entrada. Existem maneiras melhores de gerenciar segredos na produção. E eu o encorajaria altamente a procurar produtos como o Vault da HashiCorp. Ele fornecerá a você acesso baseado em identidade, registros de auditoria, rotação automática de chaves, criptografia e muito mais. Mas para a maioria das pessoas, isso vai ser um excesso para o desenvolvimento, então vamos nos limitar às variáveis de ambiente.
Mas o que é uma variável de ambiente? É uma variável cujo valor é definido fora do seu script, normalmente por meio da funcionalidade incorporada em seu sistema operacional e faz parte do ambiente no qual um processo é executado. E temos algumas maneiras diferentes de acessá-las no Python.
1import os
2import pprint
3from pymongo import MongoClient
4
5client = MongoClient(
6 os.environ["DB_HOST"],
7 username=os.environ["DB_USERNAME"],
8 password=os.environ["DB_PASSWORD"],
9)
10db = client.geo_example
11
12query = {"loc": {"$within": {"$center": [[0, 0], 6]}}}
13for doc in db.places.find(query).sort("_id"):
14 pprint.pprint(doc)
Aqui temos o mesmo código de antes, mas agora removemos nossos valores codificados e, em vez disso, estamos usando variáveis de ambiente em seu lugar. Environ é um objeto de mapeamento que representa as variáveis de ambiente. Vale ressaltar que esse mapeamento é capturado na primeira vez que o módulo os é importado, e as alterações feitas no ambiente após esse período não serão refletidas no ambiente. Environ se comporta como um Python dita. Podemos referenciar um valor fornecendo a chave correspondente. Ou podemos usar get.
1import os
2import pprint
3from pymongo import MongoClient
4
5client = MongoClient(
6 os.environ.get("DB_HOST"),
7 username=os.environ.get("DB_USERNAME"),
8 password=os.environ.get("DB_PASSWORD"),
9)
10db = client.geo_example
11
12query = {"loc": {"$within": {"$center": [[0, 0], 6]}}}
13for doc in db.places.find(query).sort("_id"):
14 pprint.pprint(doc)
A principal diferença entre as duas abordagens é ao usar get, se uma variável de ambiente não existir, ela retornará none, enquanto se você estiver tentando acessá-la por meio de sua chave, ela aumentará uma exceção KeyError . Além disso, get permite que você forneça um segundo argumento para ser usado como valor padrão se a chave não existir. Há uma terceira maneira de acessar variáveis de ambiente: getenv.
1import os
2import pprint
3from pymongo import MongoClient
4
5client = MongoClient(
6 os.getenv("DB_HOST"),
7 username=os.getenv("DB_USERNAME"),
8 password=os.getenv("DB_PASSWORD"),
9)
10db = client.geo_example
11
12query = {"loc": {"$within": {"$center": [[0, 0], 6]}}}
13for doc in db.places.find(query).sort("_id"):
14 pprint.pprint(doc)
getenv se comporta apenas como environ.get. Na verdade, ele se comporta tanto quanto escavei a fonte para tentar descobrir qual era a diferença entre os dois e os benefícios de cada um. Mas o que verifiquei é que não faz diferença. Nenhum.
1def getenv(key, default=None):
2 """Get an environment variable, return None if it doesn't exist.
3 The optional second argument can specify an alternate default.
4 key, default and the result are str."""
5 return environ.get(key, default)
getenv é simplesmente um wrapper de environ.get. Tenho certeza de que há um motivo para isso, além de economizar alguns toques de tecla, mas não o descobri durante minha pesquisa. Se você souber o motivo pelo qual o getenv existe, gostaria de ouvir.
Joe Drumgoole forneceu um motivo potencial para a existênciagetenv: "Acho que existe porque a biblioteca C tem uma função idêntica chamada getenv() e removeu alguns problemas para os programadores C (como eu, em no dia) que estavam mudando para Python."
Agora sabemos como acessar as variáveis de ambiente, como as criamos? Eles devem estar disponíveis no ambiente sempre que executarmos nosso script; portanto, na maioria das vezes, isso significará dentro do nosso terminal. Poderemos criá-los manualmente cada vez que abrirmos uma nova janela do terminal, mas isso parece muito trabalhoso e muito sujeito a erros. Então, onde mais podemos colocá-los?
Se você estiver usando o virtualenv, poderá gerenciar suas variáveis de ambiente dentro do script de ativação.
1# This file must be used with "source bin/activate" *from bash*
2# you cannot run it directly
3
4deactivate () {
5    ...
6
7    # Unset variables
8    unset NEXMO_KEY
9    unset NEXMO_SECRET
10    unset MY_NUMBER
11}
12
13...
14
15export NEXMO_KEY="a925db1ar392"
16export NEXMO_SECRET="01nd637fn29oe31mc721"
17export MY_NUMBER="447700900981"
É um pouco diferente, pois você encontrará a função de desativação na parte superior, mas é aqui que você pode desinstalar as variáveis de ambiente e fazer a limpeza. Então, na parte inferior do script é onde você pode definir suas variáveis. Dessa forma, ao ativar seu ambiente virtual, suas variáveis serão automaticamente definidas e disponíveis para seus scripts. E quando você desativar seu ambiente virtual, ele limpará depois de você e desativará essas mesmas variáveis.
Pessoalmente, não curto essa abordagem.
Nunca altero manualmente arquivos em meu ambiente virtual. Eu não os mantenho sob controle de origem. Trato-os como totalmente descartáveis. A qualquer momento, devo ser capaz de excluir todo o meu ambiente e criar um novo sem medo de perder nada. Então, modificar o script de ativação não é uma opção desejável para você.
Em vez disso, uso direnv. direnv é uma extensão para o seu shell. Ele aumenta os shells existentes com um novo recurso que pode carregar e descarregar variáveis de ambiente dependendo do diretório atual. O que isso significa é que, quando eu cd em um diretório contendo um .envrc arquivo, o direnv definirá automaticamente as variáveis de ambiente contidas para nós.
Vejamos um fluxo de trabalho típico do direnv. Primeiro, criamos um arquivo .envrc arquivo e adicionamos algumas declarações de exportação, e obtemos um erro. Por motivos de segurança, o direnv não carregará um arquivo .envrc até que você o tenha permitido. Caso contrário, você pode acabar executando código malicioso simplesmente fazendo cd em um diretório. Então, vamos dizer ao direnv para permitir esse diretório.
Agora que permitimos o .envrc , Direnv o carregou automaticamente para nós e definiu a variável de ambiente DB_PASSWORD. Então, se sairmos do diretório, o direnv será descarregado e limpará depois de nós, desconfigurando todas as variáveis de ambiente definidas.
Agora, você NUNCA deve confirmar seu arquivo envrc. Aconselho adicioná-lo ao arquivo gitignore de seus projetos e ao arquivo gitignore global. Não deve haver razão para que você deva confirmar um arquivo .envrc Migrator.
No entanto, você desejará compartilhar uma lista de quais variáveis de ambiente são necessárias com sua equipe. A convenção para isso é criar um arquivo .envrc.example que inclua apenas os nomes das variáveis, mas nenhum valor. Você pode até automatizar esse grep ou similar.
Abordamos como manter segredos simples fora do seu código-fonte, mas e se você precisar compartilhar arquivos secretos com colegas de trabalho? Vamos dar um exemplo de quando você pode precisar compartilhar um arquivo em seu repositório, mas certifique-se de que, mesmo que seu repositório se torne público, somente aqueles autorizados a acessar o arquivo possam fazê-lo.
Com a criptografia em repouso, a criptografia ocorre de forma transparente na camada de armazenamento, ou seja, todos os arquivos de dados são totalmente criptografados a partir de uma perspectiva do sistema de arquivos, e os dados só existem em um estado não criptografado na memória e durante a transmissão.
Com a criptografia de campo no nível do cliente, os aplicativos podem criptografar campos em documentos antes de transmitir dados pela rede para o servidor.
Somente aplicativos com acesso às chaves de criptografia corretas podem descriptografar e ler os dados protegidos. Excluir uma chave de criptografia torna todos os dados criptografados com essa chave permanentemente ilegíveis. Então. com Encryption at Rest. cada banco de dados tem sua própria chave de criptografia e, em seguida, há uma chave mestre para o servidor. Mas com criptografia de nível de campo no lado do cliente. Você pode criptografar campos individuais em documentos com chaves de cliente.
Devo apontar que, em produção, você realmente deve usar um KMS para qualquer um deles. Tipo, realmente use um KMS. Mas para desenvolvimento, você pode usar uma chave local.
Esses comandos geram um arquivo de chave a ser usado para criptografia em repouso, definem as permissões e, em seguida, ativam a criptografia em meu servidor. Agora, se vários desenvolvedores precisassem acessar esse servidor criptografado, precisaríamos compartilhar esse arquivo de chaves com eles.
E, na verdade, ninguém está pensando: " Eh... basta enviar um Slack para eles... " Vamos armazenar o arquivo chave em nosso repositório, mas vamos criptografá-lo primeiro.
git-secret criptografa arquivos e os armazena dentro do repositório git. Ideal. Exatamente o que precisamos. Com uma pequena ressalva...
Lembre-se de que todos esses processos precisam ser seguros e FÁCIL. Bem, git-secret é fácil... ish.
O Git-secret em si é muito simples de usar. Mas depende do PGP. O PGP, ou Pretty Good Privacy, é um programa de criptografia que fornece privacidade criptográfica e autenticação por meio de pares de chaves públicas e privadas. E é notoriamente difícil de configurar.
Há também o problema de validar uma chave pública pertence a quem você acha que faz. Depois, há as partes signatárias das chaves, a rede de confiança e muitas outras coisas que estão fora do escopo desta palestra.
Felizmente, existem guias bastante abrangentes para configurar o PGP em todos os sistemas operacionais que você possa imaginar, então, para esta palestra, vou supor que você já tenha o PGP instalado e as chaves públicas de seus colegas.
Então, vamos mergulhar de cabeça no git-secret. Primeiro nós o iniciamos, da mesma forma que faria com um repositório git. Isso criará uma pasta oculta .gitsecret. Agora precisamos adicionar alguns usuários que devem saber nossos segredos. Isso é feito com git secret count seguido pelo endereço de e-mail associado à chave pública.
Quando adicionamos um arquivo ao git-secret, ele cria um novo arquivo. Isso não altera o arquivo no local. Então, nosso arquivo não criptografado ainda está dentro do nosso repositório! Devemos garantir que não seja cometido acidentalmente. O Git-secret tenta nos ajudar com isso. Se você adicionar um arquivo ao git-secret, ele será adicionado automaticamente ao seu .gitignore, se ainda não estiver lá.
Se dermos uma olhada em nosso arquivo gitignore depois de adicionar nosso arquivo-chave à nossa lista de segredos, podemos ver que ele foi adicionado, junto com alguns arquivos que .gitsecret precisa para funcionar, mas que não devem ser compartilhados.
Neste ponto, se olharmos para o conteúdo do nosso diretório, podemos ver nosso arquivo não criptografado, mas nenhuma versão criptografada. Primeiro, temos que contar ao git secret para ocultar todos os arquivos que adicionamos. Ls de novo e agora podemos ver que a versão criptografada do arquivo foi criada. Agora podemos adicionar com segurança essa versão criptografada ao nosso repositório e atualizá-la.
Quando um de nossos colegas puxa nosso arquivo criptografado, ele executa o reveal e ele usará sua chave privada para descriptografá-lo.
O Git-secret vem com alguns comandos para facilitar o gerenciamento e o acesso a segredos.
  • Whoknows listará todos os usuários capazes de descriptografar segredos em um repositório. Útil se alguém sair da sua equipe e você precisar descobrir quais segredos precisam ser alternados.
  • A lista dirá quais arquivos em um repositório são secretos.
  • E se alguém sair e você precisar remover o acesso dela, existe o killperson bastante mórbido.
O comando killperson garantirá que a pessoa não possa descriptografar nenhum novo segredo criado, mas não criptografa novamente nenhum segredo existente; portanto, mesmo que a pessoa tenha sido removida, ela ainda poderá descriptografar todos os segredos existentes.
Não faz sentido criptografar novamente os arquivos existentes, pois eles precisarão ser girados de qualquer maneira. Então, depois que o segredo for girado, quando você executar hide on the new secret, o usuário removido não poderá acessar a nova versão.
Outra ferramenta que quero examinar é chamada de forma confusa git secrets, porque os desenvolvedores por trás das ferramentas git aparentemente têm ainda menos imaginação do que eu.
git-secrets verifica commits, mensagens de commit e --no-ff merges para evitar a adição de segredos aos seus repositórios git
Todas as ferramentas e processos que analisamos até agora tentaram facilitar o gerenciamento seguro de segredos. Esta ferramenta, no entanto, aborda o problema de uma maneira diferente. Agora vamos dificultar a codificação de segredos em seus scripts.
O Git-secrets usa regexes para tentar detectar segredos em seus commits. Ele faz isso usando ganchos git. A instalação de segredos do Git gerará alguns modelos Git com ganchos já configurados para verificar cada commit. Em seguida, podemos especificar esses modelos como os padrões para todos os novos repositórios git.
1$ git secrets --register-aws --global
2OK
3
4$ git secrets --install ~/.git-templates/git-secrets
5✓ Installed commit-msg hook to /Users/aaronbassett/.git-templates/git-secrets/hooks/commit-msg
6✓ Installed pre-commit hook to /Users/aaronbassett/.git-templates/git-secrets/hooks/pre-commit
7✓ Installed prepare-commit-msg hook to /Users/aaronbassett/.git-templates/git-secrets/hooks/prepare-commit-msg
8
9$ git config --global init.templateDir ~/.git-templates/git-secrets
O Git-secrets é dos laboratórios da AWS, então ele vem com provedores para detectar chaves de acesso da AWS, mas você também pode adicionar suas próprias. Um provedor é simplesmente uma lista de regexes, um por linha. O método recomendado é armazenar todos eles em um arquivo e, em seguida, eliminá-los. Mas isso tem algumas desvantagens.
1$ git secrets --add-provider -- cat /secret/file/patterns
Então, alguns regexes são fáceis de reconhecer. Este é o regex para uma chave RSA. Direto ao ponto. Mas e quanto a este? Eu gostaria de saber se alguém reconhece isso imediatamente. É um regex para detectar tokens de acesso oAuth do Google. Este aqui? Tokens de acesso do Facebook.
Então, como você pode ver, ter um único arquivo grande com regexes não documentados pode rapidamente se tornar muito difícil de manter. Em vez disso, coloque o meu em um diretório, bem organizado. Separe os arquivos dependendo do tipo de segredo que pretendo detectar. Então, em cada arquivo, eu tenho comentários e espaços em branco para me ajudar a agrupar regexes e documentar qual segredo eles vão detectar.
Mas o git-secrets não os aceitará como fornecedor, então precisamos ser um pouco Criativos com o egrep.
1git secrets --add-provider -- egrep -rhv "(^#|^$)" /secret/file/patterns
Coletamos todos os arquivos em nosso diretório, removemos todas as linhas que comecem com um hash ou que estejam vazias e, em seguida, retornamos o resultado dessa transformação para o git-secrets. Que é exatamente a entrada que tivemos antes, mas agora muito mais fácil de manter do que uma longa lista não documentada!
Com o git-secrets e nossos provedores personalizados instalados, se tentarmos confirmar uma chave privada, ocorrerá um erro. Agora, git-secrets pode produzir falsos positivos. A mensagem de erro fornece alguns exemplos de como você pode forçar sua confirmação. Então, se você está totalmente comprometido em dar um gatilho no gatilho, você ainda pode. Mas, esperançosamente, ele introduz conflito suficiente para tornar os segredos de codificação mais trabalhosos do que apenas usar variáveis de ambiente.
Finalmente, vamos analisar uma ferramenta para quando tudo mais falhar. Gitleaks
Auditar repositórios git em busca de segredos. O Gileaks oferece uma maneira de você encontrar segredos não criptografados e outros tipos de dados indesejados em repositórios de código-fonte git. Os vazamentos de Git são para quando, mesmo com todas as suas melhores intenções, um segredo consegue entrar em seu repositório. Porque a única coisa pior do que vazar um segredo é não saber que você vazou um segredo.
Ele funciona da mesma forma que o git-secrets, mas em vez de inspecionar commits individuais, você pode inspecionar uma variedade de coisas.
  • Um único repositório
  • Todos os repositórios de um único usuário
  • Todos os repositórios em uma organização
  • Todo o código em um GitHub PR
  • E também inspecionará usuários e grupos do GitLab
Recomendamos usá-lo de algumas maneiras diferentes.
  1. Configure-o para ser executado como parte do seu processo de relações públicas. Qualquer vazamento bloqueia a fusão.
  2. Execute-o em toda a sua organização a cada hora/dia/semana, ou com a frequência que achar suficiente. Sempre que ele detectar um vazamento, você receberá um bom relatório mostrando qual regra foi acionada, por qual commit, em qual arquivo e quem foi o autor.
Para encerrar...
  • Mantenha segredos e código separados.
  • Se você precisar compartilhar segredos, criptografe-os primeiro. Sim, o PGP pode ser complicado, mas vale a pena a longo prazo.
  • Automatize, automatize, automatize. Se o seu gerenciamento de segredos exigir muito trabalho manual para os desenvolvedores, eles o ignorarão. Eu saberia que sim. É tão fácil justificar para si mesmo. É só desta vez. É apenas uma pequena prova de conceito. Você se lembrará totalmente de removê-los antes de empurrar. Eu também dei as mesmas desculpas para mim mesmo. Então, mantenha-o fácil. Automatize sempre que possível.
  • E atrasado é melhor do que nunca. Descubra que você vazou acidentalmente um segredo é uma experiência de cair o frio, de pular o acelerador e de tirar o fólego. Mas vazar um segredo e não saber até que ele tenha sido comprometido é ainda pior. Então, execute suas varreduras de gitleak. Execute-os sempre que possível. E tenha um plano em vigor para quando você fatalmente vazar um segredo, para que possa lidar com isso rapidamente.
Muito obrigado por sua atenção.
Por favor, me adicione no Twitter em aaron bassett. Eu adoraria ouvir qualquer feedback ou pergunta que você possa ter! Se você quiser revisitar algum dos meus slides mais tarde, todos eles serão publicados no Notist logo após esta palestra.
Não tenho certeza de quanto tempo ainda temos para perguntas, mas estarei disponível no chat do corredor se alguém quiser falar comigo lá. Eu sei que tenho sentido muita falta de ver todos nas conferências este ano, então será bom me atualizar.
Graças novamente a todos que assistiram à minha apresentação e aos organizadores da PyCon Austrália.

Ícone do FacebookÍcone do Twitterícone do linkedin
Avalie esse Artigo
star-empty
star-empty
star-empty
star-empty
star-empty
Relacionado
Tutorial

Planejador de partes favoritas do operador Joe com Playwright, LlamaIndex e MongoDB Atlas Vector Search


Nov 12, 2024 | 11 min read
Tutorial

Avaliação RAG: detectando alucinações com Patronus AI e MongoDB


Aug 15, 2024 | 11 min read
Tutorial

Adicionando cache semântico e memória ao seu aplicativo RAG usando MongoDB e LangChain


Aug 13, 2024 | 16 min read
Tutorial

Construa uma plataforma de boletim de notícias com Flask e MongoDB


Sep 04, 2024 | 11 min read