Como posso salvar minhas chaves secretas e senha com segurança no meu sistema de controle de versão?

Eu mantenho configurações importantes como os nomes de host e as portas dos servidores de desenvolvimento e produção no meu sistema de controle de versão. Mas eu sei que é uma má prática manter segredos (como chaves privadas e senhas de banco de dados) em um repositório VCS.

Mas as senhas - como qualquer outra configuração - parecem que devem ser versionadas. Então, qual é a maneira correta de manter a versão das senhas controlada?

Eu imagino que isso envolveria manter os segredos em seu próprio arquivo "configurações de segredos" e ter esse arquivo criptografado e controlado por versão. Mas quais tecnologias? E como fazer isso corretamente? Existe uma maneira melhor de fazer isso?

Eu faço a pergunta geralmente, mas no meu exemplo específico eu gostaria de armazenar chaves e senhas secretas para um site Django / Python usando git e github .

Além disso, uma solução ideal faria algo mágico quando eu empurra / puxa com o git - por exemplo, se o arquivo de senhas criptografadas muda, um script é executado, solicitando uma senha e descriptografando-a no lugar.

Você está certo em criptografar seu arquivo de configurações confidenciais enquanto ainda mantém o arquivo no controle de versão. Como você mencionou, a melhor solução seria aquela em que o Git criptografaria transparentemente certos arquivos confidenciais quando você os enviar para que localmente (ou seja, em qualquer máquina que possua seu certificado) você possa usar o arquivo de configurações, mas Git ou Dropbox ou quem quer que seja armazenar seus arquivos no VC não tem a capacidade de ler as informações em texto sem formatação.

Tutorial sobre criptografia / descriptografia transparente durante push / pull

Esta lista https://gist.github.com/873637 mostra um tutorial sobre como usar o driver de filtro de manchas / limpeza do Git com o openssl para criptografar transparentemente os arquivos enviados. Você só precisa fazer algumas configurações iniciais.

Resumo de como funciona

Basicamente, você criará uma .gitencryptpasta contendo 3 scripts bash,

clean_filter_openssl 
smudge_filter_openssl 
diff_filter_openssl 

que são usados ​​pelo Git para descriptografia, criptografia e suporte ao Git diff. Uma senha mestre e salt (fixos!) São definidos dentro desses scripts e você DEVE garantir que o .gitencrypt nunca seja realmente enviado. clean_filter_opensslScript de exemplo :

#!/bin/bash

SALT_FIXED=<your-salt> # 24 or less hex characters
PASS_FIXED=<your-passphrase>

openssl enc -base64 -aes-256-ecb -S $SALT_FIXED -k $PASS_FIXED

Semelhante para smudge_filter_open_ssle diff_filter_oepnssl. Veja Gist.

Seu repositório com informações confidenciais deve ter um arquivo .gitattribute (não criptografado e incluído no repositório) que faça referência ao diretório .gitencrypt (que contém tudo o que o Git precisa para criptografar / descriptografar o projeto de forma transparente) e que esteja presente na sua máquina local.

.gitattribute conteúdo:

* filter=openssl diff=openssl
[merge]
    renormalize = true

Por fim, você também precisará adicionar o seguinte conteúdo ao seu .git/configarquivo

[filter "openssl"]
    smudge = ~/.gitencrypt/smudge_filter_openssl
    clean = ~/.gitencrypt/clean_filter_openssl
[diff "openssl"]
    textconv = ~/.gitencrypt/diff_filter_openssl

Agora, quando você envia o repositório que contém suas informações confidenciais para um repositório remoto, os arquivos serão criptografados de forma transparente. Quando você puxa de uma máquina local que possui o diretório .gitencrypt (que contém sua senha), os arquivos são descriptografados de forma transparente.

Notas

Devo observar que este tutorial não descreve uma maneira de criptografar apenas seu arquivo de configurações confidenciais. Isso criptografa de forma transparente todo o repositório enviado ao host remoto do VC e descriptografa o repositório inteiro para que seja totalmente descriptografado localmente. Para alcançar o comportamento desejado, você pode colocar arquivos confidenciais para um ou vários projetos em um sensitive_settings_repo. Você pode investigar como essa técnica de criptografia transparente funciona com os submódulos Git http://git-scm.com/book/en/Git-Tools-Submodules se você realmente precisa que os arquivos confidenciais estejam no mesmo repositório.

O uso de uma senha fixa pode teoricamente levar a vulnerabilidades de força bruta se os invasores tiverem acesso a muitos repositórios / arquivos criptografados. IMO, a probabilidade disso é muito baixa. Como menciona uma observação na parte inferior deste tutorial, o não uso de uma senha fixa resultará em versões locais de um repositório em máquinas diferentes, sempre mostrando que ocorreram alterações com o 'status git'.

O Heroku aprimora o uso de variáveis ​​de ambiente para configurações e chaves secretas:

A abordagem tradicional para lidar com esses vars de configuração é colocá-los na fonte - em um arquivo de propriedades de algum tipo. Esse é um processo propenso a erros e é especialmente complicado para aplicativos de código aberto que geralmente precisam manter ramificações separadas (e privadas) com configurações específicas do aplicativo.

Uma solução melhor é usar variáveis ​​de ambiente e manter as chaves fora do código. Em um host tradicional ou trabalhando localmente, você pode definir vários ambientes no seu bashrc. No Heroku, você usa vars de configuração.

Com o Foreman e os .envarquivos, o Heroku fornece uma cadeia de ferramentas invejável para exportar, importar e sincronizar variáveis ​​de ambiente.

Pessoalmente, acredito que é errado salvar chaves secretas ao lado do código. É fundamentalmente inconsistente com o controle de origem, porque as chaves são para serviços extrínsecos ao código . O único benefício seria que um desenvolvedor pode clonar HEAD e executar o aplicativo sem nenhuma configuração. No entanto, suponha que um desenvolvedor verifique uma revisão histórica do código. A cópia deles incluirá a senha do banco de dados do ano passado, para que o aplicativo falhe no banco de dados atual.

Com o método Heroku acima, um desenvolvedor pode fazer check-out do aplicativo do ano passado, configurá-lo com as chaves de hoje e executá-lo com sucesso no banco de dados de hoje.

A maneira mais limpa, na minha opinião, é usar variáveis ​​de ambiente. Você não precisará lidar com arquivos .dist, por exemplo, e o estado do projeto no ambiente de produção seria o mesmo que o da sua máquina local.

Eu recomendo ler o capítulo de configuração do Twelve-Factor App , os outros também, se você estiver interessado.

Uma opção seria colocar credenciais vinculadas ao projeto em um contêiner criptografado (TrueCrypt ou Keepass) e enviá-lo por push.

Atualize como resposta do meu comentário abaixo:

Pergunta interessante btw. Acabei de encontrar o seguinte: github.com/shadowhand/git-encrypt que parece muito promissor para criptografia automática

Sugiro usar arquivos de configuração para isso e não os versão.

No entanto, você pode exemplos de versão dos arquivos.

Não vejo problema em compartilhar configurações de desenvolvimento. Por definição, ele não deve conter dados valiosos.

O BlackBox foi lançado recentemente pelo StackExchange e, embora eu ainda precise usá-lo, parece abordar exatamente os problemas e dar suporte aos recursos solicitados nesta pergunta.

Na descrição em https://github.com/StackExchange/blackbox :

Armazene com segurança segredos em um repositório VCS (ou seja, Git ou Mercurial). Esses comandos facilitam a criptografia GPG de arquivos específicos em um repositório, para que eles sejam "criptografados em repouso" no seu repositório. No entanto, os scripts facilitam descriptografá-los quando você precisar visualizá-los ou editá-los e descriptografá-los para uso na produção.

Desde que fiz essa pergunta, decidi por uma solução, que uso no desenvolvimento de aplicativos pequenos com uma pequena equipe de pessoas.

git-cripta

O git-crypt usa GPG para criptografar arquivos de forma transparente quando seus nomes correspondem a determinados padrões. Por exemplo, se você adicionar ao seu .gitattributesarquivo ...

*.secret.* filter=git-crypt diff=git-crypt

... então um arquivo como config.secret.json sempre será enviado para repositórios remotos com criptografia, mas permanecerá sem criptografia no sistema de arquivos local.

Se eu quiser adicionar uma nova chave GPG (uma pessoa) ao seu repositório, que pode descriptografar os arquivos protegidos, execute git-crypt add-gpg-user <gpg_user_key>. Isso cria um novo commit. O novo usuário poderá descriptografar confirmações subsequentes.

Eu faço a pergunta geralmente, mas no meu exemplo específico eu gostaria de armazenar chaves e senhas secretas para um site Django / Python usando git e github.

Não, apenas não, mesmo que seja seu repositório particular e você nunca pretenda compartilhá-lo, não faça.

Você deve criar um local_settings.py colocá-lo em VCS ignore e em seu settings.py fazer algo como

from local_settings import DATABASES, SECRET_KEY
DATABASES = DATABASES

SECRET_KEY = SECRET_KEY

Se suas configurações de segredos são tão versáteis, estou ansioso para dizer que você está fazendo algo errado

EDIT: Suponho que você deseja acompanhar as versões anteriores de suas senhas - por exemplo, para um script que evite a reutilização de senhas etc.

Eu acho que o GnuPG é o melhor caminho a percorrer - ele já é usado em um projeto relacionado ao git (git-anexo) para criptografar o conteúdo do repositório armazenado nos serviços em nuvem. O GnuPG (gnu pgp) fornece uma criptografia baseada em chave muito forte.

1. Você mantém uma chave na sua máquina local.
2. Você adiciona 'minha senha' aos arquivos ignorados.
3. No gancho de pré-confirmação, você criptografa o arquivo mypassword no arquivo mypassword.gpg rastreado pelo git e o adiciona ao commit.
4. No gancho pós-mesclagem, basta descriptografar mypassword.gpg em mypassword.

Agora, se o arquivo 'minha senha' não foi alterado, a criptografia resultará no mesmo texto cifrado e não será adicionado ao índice (sem redundância). A modificação mais leve do mypassword resulta em texto cifrado radicalmente diferente e mypassword.gpg na área de teste diferem muito da do repositório, portanto serão adicionados ao commit. Mesmo que o invasor segure sua chave gpg, ele ainda precisará aplicar força à senha. Se o invasor obtiver acesso ao repositório remoto com texto cifrado, ele poderá comparar um monte de textos cifrados, mas o número deles não será suficiente para lhe proporcionar uma vantagem não negligenciável.

Posteriormente, você pode usar .gitattributes para fornecer uma descriptografia imediata para sair do git diff da sua senha.

Além disso, você pode ter chaves separadas para diferentes tipos de senhas, etc.

Normalmente, separo a senha como um arquivo de configuração. e distingui-los.

/yourapp
    main.py
    default.cfg.dist

E quando eu corro main.py, coloque a senha real na default.cfgcópia.

ps. quando você trabalha com git ou hg. você pode ignorar *.cfgarquivos para criar .gitignoreou.hgignore

Forneça uma maneira de substituir a configuração

Essa é a melhor maneira de gerenciar um conjunto de padrões sãos para a configuração que você fez check-in sem exigir que a configuração seja concluída ou conter itens como nomes de host e credenciais. Existem algumas maneiras de substituir as configurações padrão.

Variáveis ​​de ambiente (como outros já mencionaram) são uma maneira de fazê-lo.

A melhor maneira é procurar um arquivo de configuração externo que substitua os valores de configuração padrão. Isso permite gerenciar as configurações externas por meio de um sistema de gerenciamento de configurações como Chef, Puppet ou Cfengine. O gerenciamento de configuração é a resposta padrão para o gerenciamento de configurações, separado da base de código, para que você não precise fazer uma liberação para atualizar a configuração em um único host ou grupo de hosts.

FYI: Criptografar creds nem sempre é uma prática recomendada, especialmente em um local com recursos limitados. Pode ser que as criptografadas creds não ofereçam mais mitigação de riscos e simplesmente adicionem uma camada desnecessária de complexidade. Certifique-se de fazer a análise adequada antes de tomar uma decisão.

Criptografe o arquivo de senhas, usando, por exemplo, GPG. Adicione as chaves na sua máquina local e no seu servidor. Descriptografe o arquivo e coloque-o fora de suas pastas de recompra.

Eu uso um passwords.conf, localizado na minha pasta inicial. Em cada implantação, esse arquivo é atualizado.

Não, chaves privadas e senhas não se enquadram no controle de revisão. Não há razão para sobrecarregar todos os que têm acesso de leitura ao seu repositório ao conhecerem as credenciais de serviço confidenciais usadas na produção, quando é provável que nem todas elas tenham acesso a esses serviços.

A partir do Django 1.4, seus projetos do Django agora são enviados com um project.wsgimódulo que define o applicationobjeto e é um local perfeito para começar a impor o uso de um project.localmódulo de configurações que contém configurações específicas do site.

Esse módulo de configurações é ignorado do controle de revisão, mas é necessária presença ao executar a instância do projeto como um aplicativo WSGI, típico para ambientes de produção. É assim que deve ser:

import os

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "project.local")

# This application object is used by the development server
# as well as any WSGI server configured to use this file.
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

Agora você pode ter um local.pymódulo cujo proprietário e grupo podem ser configurados para que somente pessoal autorizado e os processos do Django possam ler o conteúdo do arquivo.

Se você precisar de VCS para seus segredos, pelo menos mantenha-os em um segundo repositório separado do seu código real. Assim, você pode dar aos membros da sua equipe acesso ao repositório de código-fonte e eles não verão suas credenciais. Além disso, hospede este repositório em outro lugar (por exemplo, no seu próprio servidor com um sistema de arquivos criptografado, não no github) e, para fazer o check-out no sistema de produção, você pode usar algo como o git-submódulo .

Outra abordagem seria evitar completamente salvar segredos nos sistemas de controle de versão e usar uma ferramenta como o vault da hashicorp , um armazenamento secreto com rolagem e auditoria de chaves, com uma API e criptografia incorporada.

Isto é o que eu faço:

• Mantenha todos os segredos como envs em $ HOME / .secrets (go-r perms) que as fontes $ HOME / .bashrc (desta forma, se você abrir .bashrc na frente de alguém, eles não verão os segredos)
• Os arquivos de configuração são armazenados no VCS como modelos, como config.properties armazenados como config.properties.tmpl

• Os arquivos de modelo contêm um espaço reservado para o segredo, como:

  my.password = ## MY_PASSWORD ##

• Na implantação do aplicativo, é executado um script que transforma o arquivo de modelo no arquivo de destino, substituindo espaços reservados por valores de variáveis ​​de ambiente, como alterar ## MY_PASSWORD ## pelo valor de $ MY_PASSWORD.

Você poderia usar o EncFS se o seu sistema fornecer isso. Assim, você pode manter seus dados criptografados como uma subpasta do seu repositório, fornecendo ao seu aplicativo uma visualização descriptografada para os dados montados de lado. Como a criptografia é transparente, nenhuma operação especial é necessária em pull ou push.

No entanto, seria necessário montar as pastas EncFS, o que poderia ser feito pelo seu aplicativo com base em uma senha armazenada em outro local fora das pastas com versão (por exemplo, variáveis ​​de ambiente).