버전 관리 시스템에서 비밀 키와 비밀번호를 안전하게 저장하려면 어떻게해야합니까?

버전 관리 시스템에서 개발 및 프로덕션 서버의 호스트 이름 및 포트와 같은 중요한 설정을 유지합니다. 그러나 나는 그것의 알고 나쁜 관행을 유지하는 비밀을 VCS는 저장소 (개인 키와 데이터베이스 암호처럼).

그러나 다른 설정과 마찬가지로 암호는 버전이 지정된 것처럼 보입니다. 암호 버전을 제어하는 ​​올바른 방법 은 무엇 입니까?

나는 그것이 유지 포함 상상이 비밀을 자신의 "비밀 설정"파일과 가진 그 파일이 암호화 및 버전 제어. 그러나 어떤 기술? 그리고 이것을 올바르게하는 방법? 전적으로 더 좋은 방법이 있습니까?

나는 일반적으로 질문을하지만 특정 인스턴스에서는 git 및 github을 사용하여 Django / Python 사이트의 비밀 키와 암호를 저장하고 싶습니다 .

또한 이상적인 솔루션은 git을 사용하여 푸시 / 풀 할 때 마술 같은 작업을 수행합니다. 예를 들어 암호화 된 비밀번호 파일이 변경되면 비밀번호를 요청하고 암호를 해독하는 스크립트가 실행됩니다.

버전 제어에서 파일을 유지하면서 민감한 설정 파일을 암호화하는 것이 옳습니다. 언급했듯이 최상의 해결책은 Git이 특정 민감한 파일을 푸시 할 때 투명하게 암호화하여 로컬로 (즉, 인증서가있는 시스템에서) 설정 파일을 사용할 수는 있지만 Git 또는 Dropbox 또는 VC에 파일을 저장하면 정보를 일반 텍스트로 읽을 수 없습니다.

푸시 / 풀 동안 투명한 암호화 / 암호 해독에 대한 자습서

이 요점 https://gist.github.com/873637 은 openssl과 함께 Git의 얼룩 / 청소 필터 드라이버를 사용하여 푸시 된 파일을 투명하게 암호화하는 방법에 대한 자습서를 보여줍니다. 초기 설정 만하면됩니다.

작동 방식 요약

기본적으로 .gitencrypt3 개의 bash 스크립트가 포함 된 폴더를 작성합니다 .

clean_filter_openssl 
smudge_filter_openssl 
diff_filter_openssl 

암호 해독, 암호화 및 Git diff 지원을 위해 Git에서 사용합니다. 마스터 스크립트와 솔트 (고정!)가이 스크립트 내에 정의되어 있으므로 .gitencrypt가 실제로 푸시되지 않도록해야합니다. clean_filter_openssl스크립트 예 :

#!/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

비슷 smudge_filter_open_ssl하고 diff_filter_oepnssl. 요점을 참조하십시오.

민감한 정보가 포함 된 리포지토리에는 .gitentribute 디렉토리 (Git이 프로젝트를 투명하게 암호화 / 암호 해독하는 데 필요한 모든 것을 포함)와 로컬 시스템에있는 .gitattribute 파일 (암호화되지 않고 리포에 포함)이 있어야합니다.

.gitattribute 내용:

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

마지막으로 .git/config파일에 다음 내용을 추가해야 합니다.

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

이제 중요한 정보가 포함 된 저장소를 원격 저장소로 푸시하면 파일이 투명하게 암호화됩니다. .gitencrypt 디렉토리 (패스 프레이즈 포함)가있는 로컬 시스템에서 가져 오면 파일이 투명하게 해독됩니다.

노트

이 자습서에서는 중요한 설정 파일 만 암호화하는 방법에 대해서는 설명하지 않습니다. 이렇게하면 원격 VC 호스트로 푸시 된 전체 리포지토리가 투명하게 암호화되고 전체 리포지토리의 암호가 해독되므로 로컬로 완전히 해독됩니다. 원하는 동작을 달성하기 위해 하나 이상의 sensitive_settings_repo에 하나 이상의 프로젝트에 민감한 파일을 배치 할 수 있습니다. 민감한 파일이 동일한 저장소에 있어야 하는 경우이 투명한 암호화 기술이 Git 서브 모듈 http://git-scm.com/book/en/Git-Tools-Submodules에서 어떻게 작동하는지 조사 할 수 있습니다.

공격자가 많은 암호화 된 저장소 / 파일에 액세스 할 수있는 경우 고정 암호를 사용하면 이론적으로 무차별 취약성이 발생할 수 있습니다. IMO,이 확률은 매우 낮습니다. 이 튜토리얼에서 언급 한 것처럼 고정 암호를 사용하지 않으면 다른 머신에서 로컬 버전의 리포지토리가 항상 'git status'로 변경이 발생했음을 표시합니다.

Heroku는 설정 및 비밀 키 에 환경 변수 사용을 푸시 합니다 .

이러한 구성 변수를 처리하는 전통적인 방법은 일종의 속성 파일에서 소스 아래에 배치하는 것입니다. 이는 오류가 발생하기 쉬운 프로세스이며 특히 앱별 구성으로 별도 (및 개인) 브랜치를 유지해야하는 오픈 소스 앱의 경우 복잡합니다.

더 나은 솔루션은 환경 변수를 사용하고 키를 코드에서 제외시키는 것입니다. 전통적인 호스트에서 또는 로컬에서 작업하면 bashrc에서 환경 변수를 설정할 수 있습니다. Heroku에서는 config vars를 사용합니다.

Foreman과 .env파일을 통해 Heroku는 환경 변수를 내보내고 가져오고 동기화 할 수있는 유용한 툴체인을 제공합니다.

개인적으로, 비밀 키를 코드와 함께 저장하는 것은 잘못이라고 생각합니다. 키는 코드에 고유 한 서비스를위한 것이기 때문에 소스 제어와 근본적으로 일치하지 않습니다 . 한 가지 장점은 개발자가 HEAD를 복제하고 설정없이 응용 프로그램을 실행할 수 있다는 것입니다. 그러나 개발자가 코드의 히스토리 개정을 확인한다고 가정하십시오. 사본에는 작년의 데이터베이스 비밀번호가 포함되므로 오늘의 데이터베이스에 대해 애플리케이션이 실패합니다.

위의 Heroku 방법을 사용하면 개발자는 작년의 앱을 체크 아웃하고 오늘의 키로 구성하고 오늘의 데이터베이스에 대해 성공적으로 실행할 수 있습니다.

내 생각에 가장 깨끗한 방법은 환경 변수를 사용하는 것입니다. 예를 들어 .dist 파일 을 처리 할 필요가 없으며 프로덕션 환경의 프로젝트 상태는 로컬 컴퓨터와 동일합니다.

내가 읽어 보시기 바랍니다 열두 팩터 앱 의 설정 장을, 다른 당신은 관심이 너무합니다.

옵션은 프로젝트 바인딩 자격 증명을 암호화 된 컨테이너 (TrueCrypt 또는 Keepass)에 넣고 푸시하는 것입니다.

아래 내 의견에서 답변으로 업데이트하십시오.

흥미로운 질문 btw. 방금 이것을 발견했습니다 : 자동 암호화에 매우 유망한 github.com/shadowhand/git-encrypt

이를 위해 구성 파일을 사용하고 버전을 지정하지 않는 것이 좋습니다.

그러나 파일의 버전 예는 가능합니다.

개발 설정을 공유하는 데 아무런 문제가 없습니다. 정의에 따라 중요한 데이터를 포함해서는 안됩니다.

BlackBox 는 최근 StackExchange에 의해 릴리스되었으며 아직 사용하지는 않았지만 문제를 정확하게 해결 하고이 질문에서 요청한 기능을 지원하는 것으로 보입니다.

https://github.com/StackExchange/blackbox 의 설명에서 :

VCS 저장소 (예 : Git 또는 Mercurial)에 비밀을 안전하게 저장하십시오. 이 명령을 사용하면 리포지토리의 특정 파일을 쉽게 GPG 암호화하여 리포지토리에서 "휴식 상태에서 암호화"할 수 있습니다. 그러나 스크립트를 사용하여 보거나 편집해야 할 때 쉽게 해독하고 프로덕션 환경에서 사용하기 위해 해독 할 수 있습니다.

이 질문을 한 후 소규모 팀으로 작은 응용 프로그램을 개발할 때 사용하는 솔루션을 설정했습니다.

자식 암호

git-crypt는 GPG를 사용하여 파일 이름이 특정 패턴과 일치 할 때 파일을 투명하게 암호화합니다. .gitattributes파일에 추가하면 intance를 위해 ...

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

... 다음과 같은 파일 config.secret.json은 항상 암호화를 사용하여 원격 저장소로 푸시되지만 로컬 파일 시스템에서는 암호화되지 않은 상태로 유지됩니다.

보호 된 파일을 해독 할 수있는 새로운 GPG 키 (사람)를 리포지토리에 추가하려면 다음을 실행하십시오 git-crypt add-gpg-user <gpg_user_key>. 이것은 새로운 커밋을 만듭니다. 새로운 사용자는 후속 커밋을 해독 할 수 있습니다.

나는 일반적으로 질문을하지만 특정 인스턴스에서는 git 및 github을 사용하여 Django / Python 사이트의 비밀 키와 암호를 저장하고 싶습니다.

아니요, 비공개 리포지토리 인 경우에도 공유하지 않더라도 공유하지 마십시오.

local_settings.py를 작성하여 VCS 무시하고 settings.py에 배치하십시오.

from local_settings import DATABASES, SECRET_KEY
DATABASES = DATABASES

SECRET_KEY = SECRET_KEY

당신의 비밀 설정이 다목적이라면, 나는 당신이 잘못하고 있다고 말하고 싶습니다.

편집 : 나는 당신이 이전 비밀번호 버전을 추적하고 싶다고 가정합니다-예를 들어 비밀번호 재사용을 방해하는 스크립트 등

GnuPG가 가장 좋은 방법이라고 생각합니다. 이미 클라우드 서비스에 저장된 저장소 내용을 암호화하기 위해 하나의 git 관련 프로젝트 (git-annex)에서 사용되었습니다. GnuPG (gnu pgp)는 매우 강력한 키 기반 암호화를 제공합니다.

1. 로컬 컴퓨터의 키를 유지합니다.
2. 무시 된 파일에 'mypassword'를 추가하십시오.
3. 커밋 전 후크에서는 mypassword 파일을 git에서 추적 한 mypassword.gpg 파일로 암호화하여 커밋에 추가합니다.
4. 병합 후 후크에서 mypassword.gpg를 mypassword로 해독하십시오.

이제 'mypassword'파일이 변경되지 않은 경우 암호화하면 동일한 암호문이 생성되고 색인에 추가되지 않습니다 (중복 없음). mypassword를 약간만 수정하면 스테이징 영역의 암호문과 mypassword.gpg가 저장소의 항목과 크게 다르므로 커밋에 추가됩니다. 공격자가 gpg 키를 잡고 있어도 여전히 암호를 무차별 처리해야합니다. 공격자가 암호문을 사용하여 원격 저장소에 액세스하면 많은 암호문을 비교할 수 있지만 그 숫자로도 무시할 수없는 이점을 제공 할 수는 없습니다.

나중에 .gitattributes를 사용하여 암호를 종료하기 위해 즉시 암호 해독을 제공 할 수 있습니다.

또한 다른 유형의 암호 등에 대해 별도의 키를 가질 수 있습니다.

일반적으로 암호는 구성 파일로 분리합니다. 그리고 그들을 dist.

/yourapp
    main.py
    default.cfg.dist

그리고 내가 실행할 때 main.py실제 비밀번호 default.cfg를 복사하십시오.

추신. git 또는 hg로 작업 할 때. *.cfg만들 파일을 무시 .gitignore하거나.hgignore

구성을 재정의하는 방법을 제공하십시오.

이것은 구성을 완료하거나 호스트 이름 및 자격 증명과 같은 항목을 포함하지 않고 체크인 한 구성의 정상 기본값 세트를 관리하는 가장 좋은 방법입니다. 기본 구성을 재정의하는 몇 가지 방법이 있습니다.

환경 변수 (다른 사람들이 이미 언급했듯이)는 환경 변수를 수행하는 한 가지 방법입니다.

가장 좋은 방법은 기본 구성 값을 재정의하는 외부 구성 파일을 찾는 것입니다. 이를 통해 Chef, Puppet 또는 Cfengine과 같은 구성 관리 시스템을 통해 외부 구성을 관리 할 수 ​​있습니다. 구성 관리는 코드베이스와 별도로 구성 관리에 대한 표준 답변이므로 단일 호스트 또는 호스트 그룹에서 구성을 업데이트하기 위해 릴리스를 수행 할 필요가 없습니다.

참고 : creds 암호화는 항상 리소스가 제한된 장소에서 항상 가장 좋은 방법은 아닙니다. 자격 증명을 암호화하면 추가적인 위험 완화가 필요하지 않고 불필요한 복잡성 계층을 추가 할 수 있습니다. 결정을 내리기 전에 적절한 분석을 수행하십시오.

예를 들어 GPG를 사용하여 비밀번호 파일을 암호화하십시오. 로컬 컴퓨터와 서버에 키를 추가하십시오. 파일을 해독하여 repo 폴더 외부에 두십시오.

내 홈 폴더에있는 passwords.conf를 사용합니다. 모든 배포에서이 파일이 업데이트됩니다.

개인 키와 암호는 개정 관리 대상이 아닙니다. 프로덕션에 사용되는 민감한 서비스 자격 증명을 알고 저장소에 대한 읽기 액세스 권한을 가진 모든 사람에게 부담을 줄 이유가 없습니다.

Django 1.4부터 Django 프로젝트는 이제 객체project.wsgi 를 정의 하는 모듈 과 함께 제공되며 사이트 별 구성이 포함 된 설정 모듈 의 사용을 시작하기에 완벽한 장소 입니다.applicationproject.local

이 설정 모듈은 수정본 제어에서 무시되지만 프로젝트 인스턴스를 프로덕션 환경에 일반적인 WSGI 애플리케이션으로 실행할 때 필요합니다. 이것이 다음과 같이 보일 것입니다 :

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()

이제 local.py권한있는 담당자와 Django 프로세스 만 파일의 내용을 읽을 수 있도록 소유자 및 그룹의 모듈을 구성 할 수 있습니다.

비밀에 VCS가 필요한 경우 최소한 실제 코드와 분리 된 두 번째 저장소에 VCS를 유지해야합니다. 따라서 팀원에게 소스 코드 저장소에 대한 액세스 권한을 부여하면 자격 증명이 표시되지 않습니다. 또한이 저장소를 다른 곳 (예 : github가 아닌 암호화 된 파일 시스템이있는 자체 서버)에서 호스팅하고 프로덕션 시스템으로 체크 아웃하려면 git-submodule 과 같은 것을 사용할 수 있습니다 .

또 다른 방법은 버전 제어 시스템에서 비밀을 완전히 저장하지 않고 대신 키 롤링 및 감사 기능이있는 비밀 스토리지 인 hashicorp의 볼트 와 같은 도구를 API 및 내장 암호화와 함께 사용하는 것입니다.

이것이 제가하는 것입니다:

• $ HOME / .bashrc가 소스로하는 $ HOME / .secrets (go-r perms)에서 모든 비밀을 env vars로 유지하십시오 (이 방법으로 누군가 앞에서 .bashrc를 열면 비밀이 보이지 않습니다)
• 구성 파일은 config.properties.tmpl로 저장된 config.properties와 같은 템플리트로 VCS에 저장됩니다.

• 템플릿 파일에는 다음과 같은 비밀을위한 자리 표시자가 포함됩니다.

  my.password = ## MY_PASSWORD ##

• 응용 프로그램 배포시 템플릿 파일을 대상 파일로 변환하는 스크립트가 실행되어 자리 표시자를 ## MY_PASSWORD ##을 $ MY_PASSWORD 값으로 변경하는 등의 환경 변수 값으로 대체합니다.

시스템에서 제공하는 경우 EncFS를 사용할 수 있습니다. 따라서 암호화 된 데이터를 리포지토리의 하위 폴더로 유지하면서 응용 프로그램에 마운트 된 데이터에 대한 해독 된보기를 제공 할 수 있습니다. 암호화는 투명하므로 풀이나 푸시에 특별한 작업이 필요하지 않습니다.

그러나 버전이 지정된 폴더 외부의 다른 곳에 저장된 비밀번호 (예 : 환경 변수)를 기반으로 응용 프로그램에서 수행 할 수있는 EncFS 폴더를 마운트해야합니다.