Làm cách nào tôi có thể lưu khóa bí mật và mật khẩu của mình một cách an toàn trong hệ thống kiểm soát phiên bản của mình?

Tôi giữ các cài đặt quan trọng như tên máy chủ và cổng của máy chủ phát triển và sản xuất trong hệ thống kiểm soát phiên bản của mình. Nhưng tôi biết rằng đó là cách thực hành tồi để giữ bí mật (như khóa riêng và mật khẩu cơ sở dữ liệu) trong kho lưu trữ VCS.

Nhưng mật khẩu - giống như bất kỳ cài đặt nào khác - có vẻ như chúng phải được phiên bản. Vì vậy, những gì là cách thích hợp để giữ mật khẩu phiên bản kiểm soát?

Tôi tưởng tượng nó sẽ liên quan đến việc giữ bí mật trong tệp "cài đặt bí mật" của riêng họ và để tệp đó được mã hóa và kiểm soát phiên bản. Nhưng công nghệ gì? Và làm thế nào để làm điều này đúng? Có cách nào tốt hơn hoàn toàn để đi về nó?

Tôi thường đặt câu hỏi, nhưng trong trường hợp cụ thể của tôi, tôi muốn lưu trữ các khóa và mật khẩu bí mật cho trang web Django / Python bằng git và github .

Ngoài ra, một giải pháp lý tưởng sẽ làm điều gì đó kỳ diệu khi tôi đẩy / kéo bằng git - ví dụ: nếu tệp mật khẩu được mã hóa thay đổi tập lệnh được chạy sẽ yêu cầu mật khẩu và giải mã nó vào vị trí.

Bạn hoàn toàn đúng khi muốn mã hóa tệp cài đặt nhạy cảm của mình trong khi vẫn duy trì tệp trong kiểm soát phiên bản. Như bạn đã đề cập, giải pháp tốt nhất sẽ là một giải pháp trong đó Git sẽ mã hóa trong suốt các tệp nhạy cảm nhất định khi bạn đẩy chúng sao cho cục bộ (tức là trên bất kỳ máy nào có chứng chỉ của bạn), bạn có thể sử dụng tệp cài đặt, nhưng Git hoặc Dropbox hoặc bất cứ ai lưu trữ các tệp của bạn dưới VC không có khả năng đọc thông tin trong bản rõ.

Hướng dẫn về mã hóa / giải mã trong suốt trong quá trình đẩy / kéo

Gist này https://gist.github.com/873637 hiển thị một hướng dẫn về cách sử dụng trình điều khiển bộ lọc smudge / clean của Git với openssl để mã hóa trong suốt các tệp được đẩy. Bạn chỉ cần làm một số thiết lập ban đầu.

Tóm tắt về cách thức hoạt động

Về cơ bản bạn sẽ tạo một .gitencryptthư mục chứa 3 tập lệnh bash,

clean_filter_openssl 
smudge_filter_openssl 
diff_filter_openssl 

được Git sử dụng để giải mã, mã hóa và hỗ trợ Git diff. Một cụm mật khẩu chính và muối (cố định!) Được xác định trong các tập lệnh này và bạn PHẢI đảm bảo rằng .gitencrypt không bao giờ thực sự được đẩy. clean_filter_opensslKịch bản ví dụ :

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

Tương tự cho smudge_filter_open_sslvà diff_filter_oepnssl. Xem ý chính.

Repo của bạn với thông tin nhạy cảm nên có tệp .gitattribution (không được mã hóa và bao gồm trong repo) tham chiếu thư mục .gitencrypt (chứa mọi thứ Git cần để mã hóa / giải mã dự án một cách trong suốt) và hiện diện trên máy cục bộ của bạn.

.gitattribute nội dung:

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

Cuối cùng, bạn cũng sẽ cần thêm nội dung sau vào .git/configtệp của mình

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

Bây giờ, khi bạn đẩy kho chứa thông tin nhạy cảm của mình sang kho lưu trữ từ xa, các tệp sẽ được mã hóa trong suốt. Khi bạn lấy từ một máy cục bộ có thư mục .gitencrypt (chứa cụm mật khẩu của bạn), các tệp sẽ được giải mã trong suốt.

Ghi chú

Tôi nên lưu ý rằng hướng dẫn này không mô tả cách chỉ mã hóa tệp cài đặt nhạy cảm của bạn. Điều này sẽ mã hóa toàn bộ kho lưu trữ được đẩy đến máy chủ VC từ xa và giải mã toàn bộ kho lưu trữ để nó được giải mã hoàn toàn cục bộ. Để đạt được hành vi bạn muốn, bạn có thể đặt các tệp nhạy cảm cho một hoặc nhiều dự án trong một nhạy cảm. Bạn có thể điều tra cách thức kỹ thuật mã hóa trong suốt này hoạt động với các mô đun con Git http://git-scm.com/book/en/Git-Tools-Submodules nếu bạn thực sự cần các tệp nhạy cảm trong cùng một kho lưu trữ.

Về mặt lý thuyết, việc sử dụng cụm mật khẩu có thể dẫn đến các lỗ hổng vũ lực nếu kẻ tấn công có quyền truy cập vào nhiều tệp / mã được mã hóa. IMO, xác suất của điều này là rất thấp. Như một lưu ý ở cuối hướng dẫn này đề cập, việc không sử dụng cụm mật khẩu cố định sẽ dẫn đến các phiên bản cục bộ của một repo trên các máy khác nhau luôn cho thấy những thay đổi đã xảy ra với 'trạng thái git'.

Heroku đẩy mạnh việc sử dụng các biến môi trường cho các cài đặt và khóa bí mật:

Cách tiếp cận truyền thống để xử lý các vars cấu hình như vậy là đặt chúng dưới nguồn - trong một tệp thuộc tính nào đó. Đây là một quy trình dễ bị lỗi và đặc biệt phức tạp đối với các ứng dụng nguồn mở thường phải duy trì các nhánh riêng biệt (và riêng tư) với các cấu hình dành riêng cho ứng dụng.

Một giải pháp tốt hơn là sử dụng các biến môi trường và giữ các khóa ra khỏi mã. Trên máy chủ truyền thống hoặc làm việc cục bộ, bạn có thể đặt các vars môi trường trong bashrc của mình. Trên Heroku, bạn sử dụng vars config.

Với Foreman và .envcác tệp, Heroku cung cấp một chuỗi công cụ tuyệt vời để xuất, nhập và đồng bộ hóa các biến môi trường.

Cá nhân, tôi tin rằng việc lưu các khóa bí mật bên cạnh mã là sai. Về cơ bản, nó không phù hợp với kiểm soát nguồn, bởi vì các khóa dành cho các dịch vụ nằm ngoài mã . Một lợi ích sẽ là nhà phát triển có thể sao chép CHÍNH và chạy ứng dụng mà không cần bất kỳ thiết lập nào. Tuy nhiên, giả sử một nhà phát triển kiểm tra bản sửa đổi lịch sử của mã. Bản sao của họ sẽ bao gồm mật khẩu cơ sở dữ liệu năm ngoái, vì vậy ứng dụng sẽ thất bại với cơ sở dữ liệu ngày nay.

Với phương pháp Heroku ở trên, nhà phát triển có thể kiểm tra ứng dụng của năm ngoái, định cấu hình nó bằng các khóa ngày nay và chạy thành công với cơ sở dữ liệu ngày nay.

Cách sạch nhất theo ý kiến ​​của tôi là sử dụng các biến môi trường. Ví dụ, bạn sẽ không phải xử lý các tệp .dist và trạng thái dự án trên môi trường sản xuất sẽ giống như máy cục bộ của bạn.

Tôi khuyên bạn nên đọc chương cấu hình của Ứng dụng mười hai yếu tố , những chương khác cũng vậy nếu bạn quan tâm.

Một tùy chọn sẽ là đặt thông tin xác thực ràng buộc dự án vào một thùng chứa được mã hóa (TrueCrypt hoặc Keepass) và đẩy nó.

Cập nhật như câu trả lời từ bình luận của tôi dưới đây:

Câu hỏi thú vị btw. Tôi vừa tìm thấy cái này: github.com/shadowhand/git-encrypt trông rất hứa hẹn cho việc mã hóa tự động

Tôi đề nghị sử dụng các tệp cấu hình cho điều đó và không phiên bản chúng.

Tuy nhiên, bạn có thể phiên bản ví dụ của các tập tin.

Tôi không thấy bất kỳ vấn đề chia sẻ cài đặt phát triển. Theo định nghĩa, nó sẽ không chứa dữ liệu có giá trị.

BlackBox được StackExchange phát hành gần đây và trong khi tôi chưa sử dụng nó, nó dường như giải quyết chính xác các vấn đề và hỗ trợ các tính năng được yêu cầu trong câu hỏi này.

Từ mô tả trên https://github.com/StackExchange/blackbox :

Lưu trữ an toàn các bí mật trong repo VCS (ví dụ Git hoặc Mercurial). Các lệnh này giúp bạn dễ dàng mã hóa GPG các tệp cụ thể trong một repo để chúng được "mã hóa ở phần còn lại" trong kho lưu trữ của bạn. Tuy nhiên, các tập lệnh giúp dễ dàng giải mã chúng khi bạn cần xem hoặc chỉnh sửa chúng, và giải mã chúng để sử dụng trong sản xuất.

Kể từ khi hỏi câu hỏi này, tôi đã giải quyết một giải pháp mà tôi sử dụng khi phát triển ứng dụng nhỏ với một nhóm nhỏ người.

mật mã

git-crypt sử dụng GPG để mã hóa trong suốt các tệp khi tên của chúng khớp với các mẫu nhất định. Đối với intance, nếu bạn thêm vào .gitattributestập tin của bạn ...

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

... sau đó một tập tin như config.secret.json sẽ luôn được đẩy sang repos từ xa bằng mã hóa, nhưng vẫn không được mã hóa trên hệ thống tệp cục bộ của bạn.

Nếu tôi muốn thêm khóa GPG mới (một người) vào repo của bạn để có thể giải mã các tệp được bảo vệ thì hãy chạy git-crypt add-gpg-user <gpg_user_key>. Điều này tạo ra một cam kết mới. Người dùng mới sẽ có thể giải mã các cam kết tiếp theo.

Tôi thường đặt câu hỏi, nhưng trong trường hợp cụ thể của tôi, tôi muốn lưu trữ các khóa và mật khẩu bí mật cho trang web Django / Python bằng git và github.

Không, chỉ là không, ngay cả khi đó là repo riêng của bạn và bạn không bao giờ có ý định chia sẻ nó, đừng.

Bạn nên tạo một local_sinstall.py đặt nó vào VCS bỏ qua và trong cài đặt của bạn, hãy làm một cái gì đó như

from local_settings import DATABASES, SECRET_KEY
DATABASES = DATABASES

SECRET_KEY = SECRET_KEY

Nếu cài đặt bí mật của bạn linh hoạt, tôi rất muốn nói rằng bạn đang làm gì đó sai

EDIT: Tôi giả sử bạn muốn theo dõi các phiên bản mật khẩu trước đây của mình - giả sử, đối với một tập lệnh sẽ ngăn chặn việc sử dụng lại mật khẩu, v.v.

Tôi nghĩ GnuPG là cách tốt nhất để sử dụng - nó đã được sử dụng trong một dự án liên quan đến git (git-annex) để mã hóa nội dung kho lưu trữ trên các dịch vụ đám mây. GnuPG (gnu pgp) cung cấp một mã hóa dựa trên khóa rất mạnh.

1. Bạn giữ một phím trên máy cục bộ của bạn.
2. Bạn thêm 'mypassword' vào các tệp bị bỏ qua.
3. Trên hook pre-commit, bạn mã hóa tệp mypassword thành tệp mypassword.gpg được theo dõi bởi git và thêm nó vào cam kết.
4. Trên hook sau hợp nhất, bạn chỉ cần giải mã mypassword.gpg thành mypassword.

Bây giờ nếu tệp 'mypassword' của bạn không thay đổi thì việc mã hóa nó sẽ dẫn đến cùng một bản mã và nó sẽ không được thêm vào chỉ mục (không có dự phòng). Sửa đổi một chút về kết quả của mật khẩu trong mật mã hoàn toàn khác nhau và mypassword.gpg trong khu vực tổ chức khác rất nhiều so với một trong kho lưu trữ, do đó sẽ được thêm vào cam kết. Ngay cả khi kẻ tấn công nắm giữ khóa gpg của bạn, anh ta vẫn cần phải xác nhận lại mật khẩu. Nếu kẻ tấn công có quyền truy cập vào kho lưu trữ từ xa bằng bản mã, anh ta có thể so sánh một loạt các bản mã, nhưng số lượng của chúng sẽ không đủ để cung cấp cho anh ta bất kỳ lợi thế không đáng kể nào.

Sau này, bạn có thể sử dụng .gitattote để cung cấp giải mã nhanh chóng để thoát khỏi mật khẩu của bạn.

Ngoài ra, bạn có thể có các khóa riêng cho các loại mật khẩu khác nhau, v.v.

Thông thường, tôi tách mật khẩu như một tập tin cấu hình. và làm cho họ xa

/yourapp
    main.py
    default.cfg.dist

Và khi tôi chạy main.py, hãy đặt mật khẩu thật vào default.cfgbản sao đó.

ps. khi bạn làm việc với git hoặc hg. bạn có thể bỏ qua *.cfgcác tập tin để thực hiện .gitignorehoặc.hgignore

Cung cấp một cách để ghi đè cấu hình

Đây là cách tốt nhất để quản lý một tập hợp mặc định lành mạnh cho cấu hình bạn đăng ký mà không yêu cầu cấu hình được hoàn thành hoặc chứa những thứ như tên máy chủ và thông tin đăng nhập. Có một số cách để ghi đè cấu hình mặc định.

Biến môi trường (như những người khác đã đề cập) là một cách để làm điều đó.

Cách tốt nhất là tìm kiếm một tệp cấu hình bên ngoài ghi đè các giá trị cấu hình mặc định. Điều này cho phép bạn quản lý các cấu hình bên ngoài thông qua hệ thống quản lý cấu hình như Chef, Puppet hoặc Cfengine. Quản lý cấu hình là câu trả lời chuẩn cho việc quản lý các cấu hình tách biệt với cơ sở mã, do đó bạn không phải thực hiện một bản phát hành để cập nhật cấu hình trên một máy chủ hoặc một nhóm máy chủ.

FYI: Mã hóa tín dụng không phải lúc nào cũng là một thực tiễn tốt nhất, đặc biệt là ở một nơi có nguồn lực hạn chế. Nó có thể là trường hợp mã hóa tín dụng sẽ giúp bạn không có giảm thiểu rủi ro bổ sung và chỉ cần thêm một lớp phức tạp không cần thiết. Hãy chắc chắn rằng bạn làm phân tích thích hợp trước khi đưa ra quyết định.

Mã hóa tệp mật khẩu, sử dụng ví dụ GPG. Thêm các phím trên máy cục bộ của bạn và trên máy chủ của bạn. Giải mã tập tin và đặt nó bên ngoài các thư mục repo của bạn.

Tôi sử dụng một mật khẩu. Thông tin, nằm trong nhà của tôi. Trên mỗi triển khai, tập tin này được cập nhật.

Không, khóa riêng và mật khẩu không thuộc quyền kiểm soát sửa đổi. Không có lý do gì để gây gánh nặng cho mọi người với quyền truy cập đọc vào kho lưu trữ của bạn khi biết thông tin xác thực dịch vụ nhạy cảm được sử dụng trong sản xuất, khi đó hầu như không phải tất cả trong số họ nên có quyền truy cập vào các dịch vụ đó.

Bắt đầu với Django 1.4, các dự án Django của bạn hiện có một project.wsgimô-đun xác định applicationđối tượng và đó là một nơi hoàn hảo để bắt đầu sử dụng mộtproject.local mô-đun cài đặt có chứa cấu hình dành riêng cho trang web.

Mô-đun cài đặt này bị bỏ qua khỏi kiểm soát sửa đổi, nhưng sự hiện diện của nó là bắt buộc khi chạy phiên bản dự án của bạn dưới dạng ứng dụng WSGI, điển hình cho môi trường sản xuất. Đây là cách nó sẽ trông như thế nào:

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

Bây giờ bạn có thể có một local.py mô-đun mà chủ sở hữu và nhóm có thể được cấu hình để chỉ những người được ủy quyền và các quy trình Django có thể đọc nội dung của tệp.

Nếu bạn cần VCS cho các bí mật của mình, ít nhất bạn nên giữ chúng trong kho lưu trữ thứ hai tách biệt với mã thực tế của bạn. Vì vậy, bạn có thể cấp cho các thành viên trong nhóm của mình quyền truy cập vào kho lưu trữ mã nguồn và họ sẽ không thấy thông tin đăng nhập của bạn. Hơn nữa, lưu trữ kho lưu trữ này ở một nơi khác (ví dụ: trên máy chủ của riêng bạn với hệ thống tệp được mã hóa, không phải trên github) và để kiểm tra nó ra hệ thống sản xuất, bạn có thể sử dụng một cái gì đó như mô đun con git .

Một cách tiếp cận khác có thể là tránh hoàn toàn việc lưu bí mật trong các hệ thống kiểm soát phiên bản và thay vào đó sử dụng một công cụ như vault từ hashicorp , một bộ lưu trữ bí mật với cán và kiểm tra khóa, với API và mã hóa nhúng.

Đây là những gì tôi làm:

• Giữ tất cả các bí mật dưới dạng env vars trong $ HOME / .secrets (perm-r perms) mà $ HOME / .bashrc nguồn (theo cách này nếu bạn mở .bashrc trước mặt ai đó, họ sẽ không thấy bí mật)
• Các tệp cấu hình được lưu trữ trong VCS dưới dạng mẫu, chẳng hạn như config.properIES được lưu dưới dạng config.properIES.tmpl

• Các tệp mẫu chứa một giữ chỗ cho bí mật, chẳng hạn như:

  my.password = ## MY_PASSWORD ##

• Khi triển khai ứng dụng, tập lệnh được chạy để chuyển đổi tệp mẫu thành tệp đích, thay thế các trình giữ chỗ bằng các giá trị của các biến môi trường, chẳng hạn như thay đổi ## MY_PASSWORD ## thành giá trị của $ MY_PASSWORD.

Bạn có thể sử dụng EncFS nếu hệ thống của bạn cung cấp điều đó. Do đó, bạn có thể giữ dữ liệu được mã hóa của mình dưới dạng thư mục con của kho lưu trữ, đồng thời cung cấp cho ứng dụng của bạn chế độ xem được giải mã cho dữ liệu được đặt sang một bên. Vì mã hóa là trong suốt, không cần thao tác đặc biệt khi kéo hoặc đẩy.

Tuy nhiên, cần phải gắn các thư mục EncFS, ứng dụng của bạn có thể được thực hiện dựa trên mật khẩu được lưu trữ ở nơi khác bên ngoài các thư mục được phiên bản (ví dụ: biến môi trường).