blackbox
v1.20220610
تخزين الأسرار بأمان في repo VCS (أي git ، الزئبق ، التخريب أو perforce). تجعل هذه الأوامر من السهل عليك أن تشفر GNU Privacy Guard (GPG) ملفات محددة في ريبو بحيث يتم "تشفيرها في الراحة" في مستودعك. ومع ذلك ، فإن البرامج النصية تجعل من السهل فك تشفيرها عندما تحتاج إلى عرضها أو تحريرها ، وفك تشفيرها للاستخدام في الإنتاج. تم كتابة Blackbox في الأصل من أجل Puppet ، ويعمل الآن مع أي مستودع بالجيت أو الزئبق.
تحذير: الهدف من هذا المشروع هو أن تكون غلافًا بسيطًا حول gpg لذا لا يجب أن تتذكر أنت وزملائك في العمل كل تلك الأعلام الغامضة والمربكة. ليس المقصود أن يكون نظام تشفير متطور يحل جميع المشكلات أو يدعم أعدادًا كبيرة من الملفات. تتمثل حالة الاستخدام المثالية في الحفاظ على الأسرار في خدمة آمنة مثل Conjur أو AWS KMS أو Azure Key Vault أو GCP KMS ؛ ثم استخدم Blackbox لتخزين مفاتيح API بأمان اللازمة للوصول إلى هذا النظام. وبهذه الطريقة ، تقوم بتشفير ملف واحد صغير. سيتم رفض عمليات الاسترداد للميزات لأي شيء آخر ؛ لا تتوقع أو حتى تطلب "ميزات المؤسسة". إذا كان هذا يخيب ظنك ، فيرجى التفكير في مشروع تنافس مثل https://www.agwa.name/projects/git-crypt
عرض شرائح (حول إصدار أقدم) في الشرائح.
انضم إلى قائمتنا البريدية: https://groups.google.com/d/forum/blackbox-project
لنفترض أن لديك مستودع VCS (أي ريبو غيت أو ميركوريال) ويحتوي بعض الملفات على أسرار مثل كلمات المرور أو مفاتيح SSL الخاصة. غالبًا ما يقوم الأشخاص بتخزين مثل هذه الملفات "وآمل ألا يجدها أحد في الريبو". هذا ليس آمنًا.
مع Blackbox ، يتم تخزين هذه الملفات مشفرة باستخدام GPG. إن الوصول إلى REPO VCS دون وجود مفاتيح GPG المناسبة يجعل من لا قيمة لها في الحصول على الملفات. طالما أنك تبقي مفاتيح GPG الخاصة بك آمنة ، فلا داعي للقلق بشأن تخزين repo VCS على خادم غير موثوق به. هيك ، حتى لو كنت تثق في الخادم الخاص بك ، فلا يتعين عليك الآن الوثوق بالأشخاص الذين يقومون بنسخ احتياطية لهذا الخادم ، أو الأشخاص الذين يتعاملون مع أشرطة النسخ الاحتياطي!
بدلاً من عبارة Passphrase GPG لجميع الملفات ، يحتوي كل شخص لديه إمكانية على مفاتيح GPG الخاصة به في النظام. يمكن فك تشفير أي ملف من قبل أي شخص مع مفتاح GPG الخاص بهم. وبهذه الطريقة ، إذا غادر شخص ما الشركة ، فلن تضطر إلى توصيل كلمة مرور جديدة للجميع الذين يتمتعون بالوصول. ما عليك سوى تعطيل المفتاح الوحيد الذي لم يعد بإمكانه الوصول. عملية القيام بذلك سهلة مثل تشغيل أوامر 2 (1 لتعطيل مفتاحها ، 1 لإعادة شطب جميع الملفات.)
غالبًا ما تحتاج العمليات الآلية إلى الوصول إلى جميع الملفات التي تم فك تشفيرها. هذا سهل أيضًا. على سبيل المثال ، لنفترض استخدام GIT لملفات الدمية. يحتاج Master إلى الوصول إلى الإصدار الذي تم فك تشفيره لجميع الملفات. ما عليك سوى إعداد مفتاح GPG لـ Puppet Master (أو حساب الدور الذي يدفع ملفات جديدة إلى Master Buppet) وجعل المستخدم يقوم بتشغيل blackbox_postdeploy بعد تحديث أي ملفات.
إذا لم يكن لديك مفتاح GPG ، فقم بإعداده باستخدام تعليمات مثل: إعداد مفتاح GPG.
أنت الآن مستعد للذهاب.
cd في مستودع GIT أو Mercurial أو Subversion أو Perforce وتشغيل blackbox_initialize .
إذا تم تشفير ملف ما ، قم بتشغيل blackbox_register_new_file وأنك قد انتهيت.
أضف وإزالة المفاتيح مع blackbox_addadmin و blackbox_removeadmin .
لعرض و/أو تحرير ملف ، قم بتشغيل blackbox_edit ؛ سيؤدي ذلك إلى فك تشفير الملف ويفتح بكل ما يحدده متغير بيئة المحرر $.
عند إغلاق المحرر ، سيتم تشفير الملف تلقائيًا مرة أخرى وسيتم تمزيق ملف النص العادي المؤقت.
إذا كنت بحاجة إلى مغادرة الملف فك تشفيره أثناء التحديث ، يمكنك استخدام blackbox_edit_start لفك تشفير الملف و blackbox_edit_end عندما تريد "وضعه مرة أخرى في المربع".
من الواضح أننا لا نريد أن يتم تسريب أشياء سرية مثل مفاتيح SSL الخاصة وكلمات المرور.
ليس من الواضح عندما نقوم بتخزين "أسرار" في إعادة الريبو VCS مثل Git أو Mercurial ، فجأة نحن أقل قدرة على مشاركة الكود لدينا مع أشخاص آخرين. التواصل بين الحالات الفرعية للمؤسسة يتأذى. لا يمكنك التعاون أيضًا. إما أن تجد نفسك إرسال ملفات فردية عبر البريد الإلكتروني حولها (Yuck!) ، أو صنع ريبو خاص مع الملفات فقط التي يحتاجها المتعاونون (Yuck !!) ، أو مجرد تحديد هذا التعاون لا يستحق كل هذا الجهد (Yuck !!!).
إن القدرة على الانفتاح والشفافية حول الكود لدينا ، باستثناء بعض الملفات المحددة ، هي مفتاح هذا النوع من التعاون الذي يتعين على ممارسيه الحديثة والممارسين في تكنولوجيا المعلومات القيام به.
make copy-install بتنسخ ملفات bin إلى بادئة/صندوق $ ، الافتراضي هو/usr/local (إلغاء تثبيت مع make copy-uninstall ).make symlinks-install ستجعل ارتباطات من ملفات bin في بادئة/صندوق $ ، الافتراضي هو/usr/محلي (إلغاء التثبيت مع make copy-uninstall ) (مفيد عند القيام بالتطوير)sudo port install vcs_blackboxbrew install blackboxmake packages-rpm ؛ الآن يمكنك توزيع RPM عبر الأساليب المحلية. (يتطلب FPM.)make packages-deb ؛ الآن يمكنك توزيع DEB عبر الأساليب المحلية. (يتطلب FPM.)antigen bundle StackExchange/blackbox إلى .zshrczgenom load StackExchange/blackbox إلى .zshrc حيث تقوم بتحميل المكونات الإضافية الأخرى.nix-shell -p blackboxpkgin in scm-blackbox| اسم: | وصف: |
|---|---|
blackbox_edit <file> | Decrypt ، Run $ editor ، أعد إدراك ملف |
blackbox_edit_start <file> | فك تشفير ملف حتى يمكن تحديثه |
blackbox_edit_end <file> | تشفير ملف بعد استخدام Blackbox_edit_start |
blackbox_cat <file> | فك التشفير وعرض محتويات ملف |
blackbox_view <file> | مثل Blackbox_cat ولكن الأنابيب إلى less أو $ pager |
blackbox_diff | قام Diff فك التشفير مقابل نسختهم المشفرة الأصلية |
blackbox_initialize | تمكين Blackbox لليغات أو زئبق ريبو |
blackbox_register_new_file <file> | تشفير ملف لأول مرة |
blackbox_deregister_file <file> | قم بإزالة ملف من Blackbox |
blackbox_list_files | اذكر الملفات التي تحتفظ بها BlackBox |
blackbox_list_admins | قائمة مدراء قائمة على BlackBox حاليًا |
blackbox_decrypt_file <file> | فك تشفير ملف |
blackbox_decrypt_all_files | فك تشفير جميع الملفات المدارة (التفاعلية) |
blackbox_postdeploy | فك تشفير جميع الملفات المدارة (دفعة) |
blackbox_addadmin <gpg-key> | أضف شخصًا ما إلى قائمة الأشخاص الذين يمكنهم تشفير/فك تشفير الأسرار |
blackbox_removeadmin <gpg-key> | قم بإزالة شخص من قائمة الأشخاص الذين يمكنهم تشفير/فك تشفير الأسرار |
blackbox_shred_all_files | حذف أي ملفات فك تشفيرها بأمان |
blackbox_update_all_files | فك تشفير ثم إعادة تشفير جميع الملفات. مفيد بعد تغيير المفاتيح |
blackbox_whatsnew <file> | أظهر ما الذي تغير في الالتزام الأخير لملف معين |
يحدد Blackbox تلقائيًا VCs الذي تستخدمه ويفعل الشيء الصحيح. إنه يحتوي على بنية مكون من ذلك لتسهيل تمديد العمل مع أنظمة أخرى. تم اختباره للعمل مع العديد من أنظمة التشغيل.
git - githg - الزئبقsvn - Subversion (شكرًا ، بن دراسين!)p4 - Perforce.blackbox سليما لإضافة أو إصلاح الدعم لنظام VCS ، ابحث عن رمز في نهاية bin/_blackbox_common.sh
لإضافة أو إصلاح الدعم لنظام تشغيل جديد ، ابحث عن عبارات الحالة في bin/_blackbox_common.sh و bin/_stack_lib.sh وربما tools/confidence_test.sh
يمكن استخدام Blackbox مع Cygwin أو Mingw أو WSL2.
يفترض Blackbox أن blackbox-admins.txt و blackbox-files.txt سيكون له نهايات LF. يجب أن يكون مستخدمو Windows حريصين على تكوين GIT أو الأنظمة الأخرى لعدم تحويل هذه الملفات أو "إصلاحها".
إذا كنت تستخدم git ، فأضف الأسطر التالية إلى ملف .gitattributes الخاص بك:
**/blackbox-admins.txt text eol=lf
**/blackbox-files.txt text eol=lf
سيقوم أحدث إصدار من blackbox_initialize بإنشاء ملف .gitattributes في دليل $BLACKBOXDATA (عادة .blackbox ) لك.
يتطلب دعم Cygwin الحزم التالية:
العملية العادية:
التطوير (إذا كنت ستضيف رمزًا وتريد إجراء اختبار الثقة)
يتطلب دعم Mingw (يأتي مع GIT للنوافذ) ما يلي:
العملية العادية:
MINTTY بدلاً من وحدة التحكم Windows. ستقوم بتنفيذ Blackbox من موجه Git Bash.download.bat بمجرد الانتهاء من تشغيل install.bat ثم أضف المسار لتلك الأدوات إلى مسارك (على سبيل المثال: PATH=%PATH%;c:GnuWin32bin )تطوير:
make test )إذا حصلت على الخطأ التالي في WSL2 ، فيمكنك محاولة إعداد بيئتك مع الإرشادات التالية (تم اختبارها مع Ubuntu 22.04 على WSL2):
~/.gnupg/gpg-agent.conf على WSL وأضف السطر التالي: pinentry-program "/mnt/c/Program Files (x86)/GnuPG/bin/pinentry-basic.exe"gpg-connect-agent reloadagent /byeلدى GPG العديد من الطرق المختلفة لتشفير ملف. يستخدم Blackbox الوضع الذي يتيح لك تحديد قائمة بالمفاتيح التي يمكنها فك تشفير الرسالة.
إذا كان لديك 5 أشخاص ("مدراء") يجب أن يكونوا قادرين على الوصول إلى الأسرار ، يقوم كل منهم بإنشاء مفتاح GPG ويضيف مفتاحهم العام إلى سلسلة المفاتيح. يسرد أمر GPG المستخدم لتشفير الملف جميع أسماء المفاتيح الخمسة ، وبالتالي يمكن لأي مفتاح واحد فك تشفير الملف.
لإزالة وصول شخص ما ، قم بإزالة الاسم الرئيسي لهذا المسؤول (أي عنوان البريد الإلكتروني) من قائمة المدراء وإعادة إدراك جميع الملفات. لا يزال بإمكانهم قراءة ملف .gpg (على افتراض أن لديهم إمكانية الوصول إلى المستودع) لكنهم لا يستطيعون فك تشفيره بعد الآن.
ماذا لو احتفظوا بنسخة من الريبو القديم قبل إزالة الوصول؟ نعم ، يمكنهم فك تشفير الإصدارات القديمة من الملف. لهذا السبب عندما يغادر المسؤول الفريق ، يجب عليك تغيير جميع كلمات المرور الخاصة بك ، و CERTS SSL ، وما إلى ذلك. كان يجب أن تفعل ذلك قبل Blackbox ، أليس كذلك؟
لماذا لا تستخدم المفاتيح المتماثلة؟ بمعنى آخر ، لماذا العبث مع كل الأشياء الرئيسية GPG هذه وبدلاً من ذلك ، لماذا لا نشفر جميع الملفات فقط باستخدام عبارة تمريرة واحدة. نعم ، يدعم GPG ذلك ، ولكن بعد ذلك ندير كلمة مرور مشتركة ، وهي محفوفة بالمشاكل. إذا كان شخص ما "يترك الفريق" ، فسيتعين علينا التواصل مع الجميع كلمة مرور جديدة. الآن علينا فقط إزالة مفتاحهم. هذا المقاييس أفضل.
كيف تقوم العمليات الآلية بفك تشفيرها دون طلب كلمة مرور؟ يتطلب GPG عبارة عن عبارة مرور على مفتاح خاص. ومع ذلك ، فإنه يسمح بإنشاء مفاتيح فرعية لا تحتوي على عبارة. بالنسبة للعمليات الآلية ، قم بإنشاء مفتاح فرعي يتم تخزينه فقط على الجهاز الذي يحتاج إلى فك تشفير الملفات. على سبيل المثال ، في Stack Exchange ، عندما يدفع نظام التكامل المستمر (CI) تغيير رمز إلى أساتذة العرائس ، يقومون بتشغيل blackbox_postdeploy لفك تشفير جميع الملفات. يحتوي المستخدم الذي يقوم بتشغيل هذا الرمز على مفتاح فرعي لا يتطلب عبارة مرور. نظرًا لأن لدينا العديد من الأساتذة ، لكل منها مفتاحه الخاص. ونعم ، هذا يعني أن أسياد العرائس يجب أن يكونوا آمنين للغاية. ومع ذلك ، فقد كانوا آمنين بالفعل لأنه ، مثل ، المتأنق ... إذا كان بإمكانك اقتحام سيد دمية شخص ما ، فأنت تمتلك شبكته.
إذا كنت تستخدم Puppet ، فلماذا لم تستخدم Hiera-Eyaml فقط؟ هناك 4 أسباب:
eval $(gpg-agent --daemon)blackbox_edit_start FILENAMEvim FILENAMEblackbox_edit_end FILENAMEgit commit -a hg commit انتظر ... يمكن أن يكون أسهل من ذلك! قم بتشغيل blackbox_edit FILENAME ، وسيقوم بإلغاء فك تشفير الملف في ملف temp واتصل $EDITOR عليه ، وإعادة التجميع مرة أخرى بعد إغلاق المحرر.
يوفر Ansible Vault وظيفة لتشفير كل من الملفات والسلاسل بالكامل المخزنة داخل الملفات ؛ ومع ذلك ، فإن تتبع كلمة المرور (كلمة المرور) المطلوبة لفك تشفير لا يتم التعامل معها بواسطة هذه الوحدة.
بدلاً من ذلك ، يجب على المرء تحديد ملف كلمة المرور عند تشغيل كتاب اللعب.
مثال ANSIBLE على ملف كلمة المرور: my_secret_password.txt.gpg
ansible-playbook --vault-password-file my_secret_password.txt site.yml
بدلاً من ذلك ، يمكن للمرء تحديد ذلك في متغير بيئة ANSIBLE_VAULT_PASSWORD_FILE .
يتم التعامل مع الملفات بأكملها ، مثل SSL Certs والمفاتيح الخاصة ، تمامًا مثل الملفات العادية. يمكنك فك تشفيرهم في أي وقت تدفع فيه إصدارًا جديدًا إلى Master Puppet.
مثال للدمى لملف مشفر: secret_file.key.gpg
file { '/etc/my_little_secret.key':
ensure => 'file',
owner => 'root',
group => 'puppet',
mode => '0760',
source => "puppet:///modules/${module_name}/secret_file.key",
}
يتم تخزين الأوتار الصغيرة ، مثل كلمات المرور ومفاتيح API ، في ملف Hiera Yaml ، والتي تشفرها مع blackbox_register_new_file . على سبيل المثال ، نستخدم ملفًا يسمى blackbox.yaml . يمكنك الوصول إليها باستخدام وظيفة Hiera ().
الإعداد: تكوين hiera.yaml بإضافة "Blackbox" إلى التسلسل الهرمي للبحث:
:hierarchy:
- ...
- blackbox
- ...
في Blackbox.yaml حدد:
---
module::test_password: "my secret password"
في رمز الدمى الخاص بك ، قم بالوصول إلى كلمة المرور كما تفعل مع أي بيانات Hiera:
$the_password = hiera('module::test_password', 'fail')
file {'/tmp/debug-blackbox.txt':
content => $the_password,
owner => 'root',
group => 'root',
mode => '0600',
}
سيحتوي المتغير $the_password على "كلمة المرور السرية الخاصة بي" ويمكن استخدامها في أي مكان يتم استخدام السلاسل.
eval $(gpg-agent --daemon) blackbox_register_new_file path/to/file.name.key
يمكن تحديد أسماء الملفات المتعددة على سطر الأوامر:
مثال 1: سجل 2 ملفات:
blackbox_register_new_file file1.txt file2.txt
مثال 2: سجل جميع الملفات في $DIR :
find $DIR -type f -not -name '*.gpg' -print0 | xargs -0 blackbox_register_new_file
نادرًا ما يحدث هذا ، لكننا قمنا بتغطيته:
blackbox_deregister_file path/to/file.name.key
FYI: قد يستخدم Repo الخاص بك keyrings/live بدلاً من .blackbox . انظر "أين يتم تخزين التكوين؟"
.blackbox/blackbox-admins.txt هو ملف يسرد المستخدمين الذين يستطيعون فك تشفير الملفات. (بشكل أكثر تبرزًا ، إنها قائمة بأسماء مفاتيح GNUPG التي تم تشفيرها للملف.)
للانضمام إلى قائمة الأشخاص الذين يمكنهم تحرير الملف يتطلب ثلاث خطوات ؛ يمكنك إنشاء مفتاح GPG وإضافته إلى حلقة المفاتيح. بعد ذلك ، يضيفك شخص لديه وصول بالفعل إلى النظام. أخيرًا ، يجب عليك اختبار وصولك.
إذا لم يكن لديك بالفعل مفتاح GPG ، فإليك كيفية إنشاء مفتاح:
gpg --gen-key
تحذير: تولد إصدارات جديدة من GPG مفاتيح لا يفهمها الإصدارات القديمة من GPG. إذا قمت بإنشاء مفتاح مع إصدار جديد من GPG ، فإن هذا سيؤدي إلى مشاكل لمستخدمي الإصدارات القديمة من GPG. لذلك ، يوصى بأن تتأكد من أن كل شخص يستخدم Blackbox لديه نفس الإصدار الدقيق من GPG ، أو إنشاء مفاتيح GPG باستخدام إصدار من GPG كإصدار أقدم من GPG المستخدم من قبل كل شخص باستخدام BlackBox.
اختر الإعدادات الافتراضية لإعدادات التشفير ، 0 انتهاء الصلاحية. اختر عبارة ممر جيد جدًا. تخزين نسخة احتياطية للمفتاح الخاص في مكان آمن. على سبيل المثال ، احتفظ بنسخة النسخ الاحتياطي على محرك أقراص USB مغلق بشكل آمن. أو على الأقل ضعها على جهاز آمن مع إمكانية الوصول إلى الإنترنت قليلاً أو معدومة ، أو تدمير الخرق الكامل ، وما إلى ذلك. ربما يكون لدى صاحب العمل قواعد حول كيفية تخزين مثل هذه الأشياء.
لمعلوماتك: إذا كان توليد المفتاح بطيئًا ، فهذا عادةً ما يكون النظام لا يولد ما يكفي من الانتروبيا. نصيحة: افتح نافذة أخرى على هذا الجهاز وقم بتشغيل هذا الأمر: ls -R /
الآن بعد أن أصبح لديك مفتاح GPG ، أضف نفسك كمسؤول:
blackbox_addadmin KEYNAME
... حيث "keyname" هو عنوان البريد الإلكتروني المدرج في مفتاح GPG الذي أنشأته مسبقًا. على سبيل المثال:
blackbox_addadmin [email protected]
عندما يكمل الأمر بنجاح ، سيتم إخراج التعليمات حول كيفية ارتكاب هذه التغييرات. قم بتشغيل الأمر على النحو الممنوح لارتكاب التغييرات. سيبدو هكذا:
git commit -m'NEW ADMIN: [email protected]' .blackbox/pubring.gpg .blackbox/trustdb.gpg .blackbox/blackbox-admins.txt
ثم ادفعه إلى الريبو:
git push
or
ht push
(or whatever is appropriate)
ملاحظة: إنشاء حساب دور؟ إذا كنت تقوم بإضافة pubring.gpg لحساب الدور ، فيمكنك تحديد الدليل حيث يمكن العثور على ملف pubring.gpg كمعلمة ثانية: blackbox_addadmin [email protected] /path/to/the/dir
اطلب من شخص لديه بالفعل إمكانية إعادة إدراك ملفات البيانات. هذا يمنحك الوصول. إنهم ببساطة فك تشفير البيانات وإعادة إدراكها دون إجراء أي تغييرات.
قبل الاختيار: تحقق من أن المفاتيح الجديدة تبدو جيدة.
git pull # Or whatever is required for your system
gpg --homedir=.blackbox --list-keys
على سبيل المثال ، فحص الاسم الرئيسي (عنوان البريد الإلكتروني) للتأكد من أنه يتوافق مع معايير الشركات.
استيراد سلسلة المفاتيح إلى سلسلة المفاتيح الشخصية وإعادة التنفيذ:
gpg --import .blackbox/pubring.gpg
blackbox_update_all_files
ادفع الملفات المعاد تشجيعها:
git commit -a
git push
or
hg commit
hg push
تأكد من أنه يمكنك فك تشفير ملف. (اقتراح: احتفظ بملف وهمية في VCs فقط لأشخاص جدد لممارسة.)
ما عليك سوى تشغيل blackbox_removeadmin مع اسمها الرئيسي ثم إعادة الشجرة:
مثال:
blackbox_removeadmin [email protected]
blackbox_update_all_files
عند اكتمال الأمر ، ستحصل على تذكير للتحقق من التغيير ودفعه.
لاحظ أن مفاتيحهم ستظل في الحلقة الرئيسية ، لكنها ستستخدم. إذا كنت ترغب في تنظيف المفاتيح ، فاستخدم أوامر GPG العادية وتحقق من الملف.
FYI: قد يستخدم Repo الخاص بك keyrings/live بدلاً من .blackbox . انظر "أين يتم تخزين التكوين؟"
gpg --homedir=.blackbox --list-keys
gpg --homedir=.blackbox --delete-key [email protected]
git commit -m'Cleaned [email protected] from keyring' .blackbox/*
FYI: قد يستخدم Repo الخاص بك keyrings/live بدلاً من .blackbox . انظر "أين يتم تخزين التكوين؟"
الحلقة الرئيسية فقط مفاتيح عامة. لا توجد مفاتيح سرية للحذف.
تذكر أن هذا الشخص لديه إمكانية الوصول إلى جميع الأسرار في وقت واحد. كان يمكن أن يكونوا نسخة. لذلك ، لكي تكون آمنًا تمامًا ، يجب عليك تغيير جميع كلمات المرور ، وإنشاء مفاتيح SSL جديدة ، وهكذا تمامًا عندما يترك أي شخص لديه وصول متميز منظمة.
التحقق من صحة جدارة المفاتيح هي مهمة لا يمكن تحقيقها بواسطة Blackbox ؛ هذا موضوع خارجي تمامًا يجب التعامل معه يدويًا (بنفس الطريقة التي يتم بها توليد/إدارة مفتاحك ، على سبيل المثال) أو عن طريق آلية مخصصة (شركة CA مع سير العمل المقابلة على سبيل المثال). بصرف النظر عن الفوائد "الشائعة" لشبكة الثقة (انظر هنا أو هنا على سبيل المثال) ، فإنه يمنع العديد من الأخطاء أيضًا.
تاريخيا كان Blackbox يستخدم وإنفاذ نموذج "ثقة كل مفتاح" ولكن هذا قد تغير! الآن يتم ترك قرار ما إذا كان يتم استخدام نماذج ثقة PGP/GPG وكيفية استخدامها للمستخدم عن طريق التكوين (أو عن طريق الافتراضات PGP/GPG).
عند تحديث Blackbox ، قد يواجه الأشخاص مشكلات وظيفية إذا لم يتعاملوا بعد مع قابلية الثقة في المفاتيح التي يستخدمونها. إنه الوقت المناسب للقيام بذلك وبناء شبكة الثقة الخاصة بك الآن!
إذا كان لديك سير عمل خارجي في مكان يضمن سلامة استخدام Keys Blackbox ، فقد ترغب في تعطيل نماذج PGP/GPG Trust والاعتماد على سير العمل هذا.
يمكن تحقيق ذلك من خلال إعلان "نموذج الثقة دائمًا" ، إما عن طريق تمرير معلمة سطر الأوامر --trust-model=always إلى ثنائي PGP/GPG عند استخدام blackbox (عن طريق تحديد الاسم المستعار أو استخدام متغير البيئة (eg GPG="gpg2 --trust-model=always" ) أو مزيج من كليهما) أو عن طريق ضبط trust-model always في gpg.conf الخاص بك (لاحظ أن هذا يعطل شبكة الثقة في كل مكان ، وليس فقط لـ Blackbox).
تحذير: من المعتاد بشدة عدم استخدام أي التحقق من صحة المفتاح على الإطلاق! هذا يفتح طرقًا مختلفة لتجاوز سرية أسرارك المشفرة!
تقوم Blackbox بتخزين بيانات التكوين الخاصة بها في .blackbox subdirectory. repos الأقدم تستخدم keyrings/live . لتوافق للخلف إما سيعمل.
تشير جميع الوثائق إلى .blackbox .
يمكنك تحويل إعادة الريبو القديم عن طريق إعادة تسمية الدليل:
mv keyrings/live .blackbox
rmdir keyrings
لا يوجد سبب فني لتحويل إعادة الشراء القديمة إلا أنه أقل إرباكًا للمستخدمين.
تم إجراء هذا التغيير في الالتزام 60e782a0 ، الإصدار v1.20180615.
التفاصيل:
$BLACKBOXDATA . إذا تم تعيين متغير البيئة هذا ، فهذا هو الدليل الذي سيتم استخدامه. إذا كان يسرد دليلًا غير موجود ، فسيقوم Blackbox بطباعة خطأ وخروج.$BLACKBOXDATA : (وهي حالة الاستخدام النموذجية)keyrings/live واستخدامه إذا كان موجودًا..blackbox . إذا لم يكن .blackbox موجودًا ، فسيقوم Blackbox بطباعة خطأ وخروج.ملخص:
لإضافة "blackbox" إلى ريبو غيت أو ميركوريال ، ستحتاج إلى القيام بما يلي:
FYI: قد يستخدم Repo الخاص بك keyrings/live بدلاً من .blackbox . انظر "أين يتم تخزين التكوين؟"
ستحتاج إلى تضمين دليل "بن" في Blackbox في طريقك:
export PATH=$PATH:/the/path/to/blackbox/bin
blackbox_initialize
إذا كنت تستخدم المستضد ، فستضيف إضافة antigen bundle StackExchange/blackbox إلى .zshrc هذا المستودع وإضافته إلى مسار $ الخاص بك.
اتبع التعليمات الخاصة بـ "كيفية تعزيز مستخدم جديد في النظام؟". فقط هل الخطوة 1.
بمجرد الانتهاء من ذلك ، من الجيد اختبار النظام عن طريق التأكد من إضافة ملف إلى النظام (انظر "كيفية تسجيل ملف جديد في النظام؟") ، ويمكن للمستخدم المختلف فك تشفير الملف.
قم بعمل ملف جديد وقم بتسجيله:
rm -f foo.txt.gpg foo.txt
echo This is a test. >foo.txt
blackbox_register_new_file foo.txt
فك تشفيره:
blackbox_edit_start foo.txt.gpg
cat foo.txt
echo This is the new file contents. >foo.txt
أعد إدراكه:
blackbox_edit_end foo.txt.gpg
ls -l foo.txt*
يجب أن ترى فقط foo.txt.gpg كما يجب أن تختفي foo.txt .
الخطوة التالية هي ارتكاب foo.txt.gpg والتأكد من أنه يمكن للمستخدم الآخر التحقق من محتويات الملف وعرضه وتغييره. يتم ترك ذلك كتمرين للقارئ. إذا كنت تشعر برغبة في المخاطرة ، فلا ترتكب foo.txt.gpg وحذفه بدلاً من ذلك.
أي هذه هي الطريقة التي يمكن أن يحصل بها سيد الدمية على البيانات غير المشفرة.
FYI: قد يستخدم Repo الخاص بك keyrings/live بدلاً من .blackbox . انظر "أين يتم تخزين التكوين؟"
المستخدم الآلي ("حساب الدور") هو الذي يجب أن يكون قادرًا على فك التشفير بدون عبارة تمريرية. بشكل عام ، سترغب في القيام بذلك للمستخدم الذي يسحب الملفات من الريبو إلى السيد. قد يكون هذا مؤتمراً مع Jenkins CI أو نظام CI الآخر.
مفاتيح GPG يجب أن يكون لها عبارة تمريرة. ومع ذلك ، فإن عبارات المرور اختيارية على المفاتيح الفرعية. لذلك ، سنقوم بإنشاء مفتاح مع عبارة مرور ثم إنشاء مفتاح فرعي بدون عبارة تمريرية. نظرًا لأن المفتاح الفرعي قوي للغاية ، يجب إنشاءه على آلة آمنة للغاية.
هناك صيد آخر. ربما لا يمكن لحساب الدور التحقق من الملفات في git/mercurial. من المحتمل أن يكون لديه وصول للقراءة فقط إلى الريبو. هذه سياسة أمنية جيدة. هذا يعني أنه لا يمكن استخدام حساب الدور لتحميل البتات العامة الفرعية في الريبو.
لذلك ، سنقوم بإنشاء المفتاح/المفتاح الفرعي على آلة آمنة بنفسك. من هناك يمكننا ارتكاب الأجزاء العامة في الريبو. أيضًا من هذا الحساب ، سنقوم بتصدير الأجزاء التي يحتاجها حساب الدور ، ونسخها إلى حيث يمكن لحساب الدور الوصول إليها ، واستيرادها كحساب الدور.
protip: إذا طُلب منه إنشاء إنتروبيا ، فكر في تشغيل هذا على نفس الجهاز في نافذة أخرى: sudo dd if=/dev/sda of=/dev/null
لبقية هذا المستند ، ستحتاج إلى إجراء البدائل التالية:
ملاحظة: يجب أن يكون هذا أكثر تلقائية/نصية. بقع مرحب به.
على Securehost ، قم بإنشاء مفاتيح Master Puppet:
$ mkdir /tmp/NEWMASTER
$ cd /tmp/NEWMASTER
$ gpg --homedir . --gen-key
Your selection?
(1) RSA and RSA (default)
What keysize do you want? (2048) DEFAULT
Key is valid for? (0) DEFAULT
# Real name: Puppet CI Deploy Account
# Email address: [email protected]
ملاحظة: بدلاً من عنوان بريد إلكتروني حقيقي ، استخدم اسم المستخدم@fqdn من المضيف سيتم استخدام المفتاح عليه. إذا كنت تستخدم حساب الدور هذا على العديد من الآلات ، فيجب أن يكون لكل منها مفتاح خاص به. باستخدام FQDN للمضيف ، ستتمكن من معرفة المفتاح الذي. في هذا المستند ، سنشير إلى اسم المستخدم@fqdn باسم $ keyname
احفظ عبارة الممر في مكان آمن!
قم بإنشاء مفتاح فرعي لا يحتوي على كلمة مرور:
$ gpg --homedir . --edit-key svc_deployacct
gpg> addkey
(enter passphrase)
Please select what kind of key you want:
(3) DSA (sign only)
(4) RSA (sign only)
(5) Elgamal (encrypt only)
(6) RSA (encrypt only)
Your selection? 6
What keysize do you want? (2048)
Key is valid for? (0)
Command> key 2
(the new subkey has a "*" next to it)
Command> passwd
(enter the main key's passphrase)
(enter an empty passphrase for the subkey... confirm you want to do this)
Command> save
الآن تصدير هذا الدليل بشكل آمن إلى Newmaster:
gpg --homedir . --export -a svc_sadeploy >/tmp/NEWMASTER/pubkey.txt
tar cvf /tmp/keys.tar .
rsync -avP /tmp/keys.tar NEWMASTER:/tmp/.
على Newmaster ، تلقي تكوين GNUPG الجديد:
sudo -u svc_deployacct bash
mkdir -m 0700 -p ~/.gnupg
cd ~/.gnupg && tar xpvf /tmp/keys.tar
مرة أخرى على Securehost ، أضف عنوان البريد الإلكتروني الجديد إلى .blackbox/Blackbox-admins.txt:
cd /path/to/the/repo
blackbox_addadmin $KEYNAME /tmp/NEWMASTER
تحقق من أن secring.gpg هو ملف بطول صفرية. إذا لم يكن الأمر كذلك ، فقد أضفت بطريقة أو بأخرى مفتاحًا خاصًا إلى المفاتيح. ابدأ من جديد.
cd .blackbox
ls -l secring.gpg
ارتكاب التغييرات الأخيرة:
cd .blackbox
git commit -m"Adding key for KEYNAME" pubring.gpg trustdb.gpg blackbox-admins.txt
تجديد جميع الملفات المشفرة بالمفتاح الجديد:
blackbox_update_all_files
git status
git commit -m"updated encryption" -a
git push
على Newmaster ، استيراد المفاتيح وفك تشفير الملفات:
sudo -u svc_sadeploy bash # Become the role account.
gpg --import /etc/puppet/.blackbox/pubring.gpg
export PATH=$PATH:/path/to/blackbox/bin
blackbox_postdeploy
sudo -u puppet cat /etc/puppet/hieradata/blackbox.yaml # or any encrypted file.
Protip: إذا حصلت على "GPG: Decryption فشل: لا يوجد مفتاح سري" ثم نسيت إعادة تشفير Blackbox.yaml بالمفتاح الجديد.
على Securehost ، حذف ملفاتك بشكل آمن:
cd /tmp/NEWMASTER
# On machines with the "shred" command:
shred -u /tmp/keys.tar
find . -type f -print0 | xargs -0 shred -u
# All else:
rm -rf /tmp/NEWMASTER
كما تمزيق أي ملفات مؤقتة أخرى قد تكون قد قمت بها.
إذا انتهت صلاحية مفتاح شخص ما بالفعل ، فسيتوقف Blackbox عن التشفير. ترى هذا الخطأ:
$ blackbox_edit_end modified_file.txt
--> Error: can't re-encrypt because a key has expired.
FYI: قد يستخدم Repo الخاص بك keyrings/live بدلاً من .blackbox . انظر "أين يتم تخزين التكوين؟"
يمكنك أيضًا اكتشاف المفاتيح التي تنتهي صلاحيتها عن طريق إصدار هذا الأمر ومراجعة "انتهاء الصلاحية:": التواريخ:
gpg --homedir=.blackbox --list-keys
أو ... قائمة uids التي ستنتهي في غضون شهر واحد من اليوم: (تحذير: هذا يسرد أيضًا مفاتيح دون تاريخ انتهاء الصلاحية)
gpg --homedir=.blackbox --list-keys --with-colons --fixed-list-mode | grep ^uid | awk -F: '$6 < '$(( $(date +%s) + 2592000))
إليك كيفية استبدال المفتاح:
تحذير: سوف تمحو هذه العملية أي ملفات غير مشفرة كنت بصدد التحرير. انسخها في مكان آخر واستعادة التغييرات عند الانتهاء.
blackbox_removeadmin [email protected]
# This next command overwrites any changed unencrypted files. See warning above.
blackbox_update_all_files
git commit -m "Re-encrypt all files"
gpg --homedir=.blackbox --delete-key [email protected]
git commit -m 'Cleaned [email protected] from keyring' .blackbox/*
git push
git pull
blackbox_addadmin [email protected]
git commit -m'NEW ADMIN: [email protected] .blackbox/pubring.gpg .blackbox/trustdb.gpg .blackbox/blackbox-admins.txt
git push
git pull
gpg --import .blackbox/pubring.gpg
blackbox_update_all_files
git commit -m "Re-encrypt all files"
git push
يمكن الآن نسخ أي ملفات تم نسخها مؤقتًا في الخطوة الأولى حتى لا يتم الكتابة فوقها وإعادة تجفيفها باستخدام أمر blackbox_edit_end .
(بفضل Chishaku لإيجاد حل لهذه المشكلة!)
من الممكن إخبار Git بفك تشفير إصدارات الملف قبل تشغيلها من خلال git diff أو git log . لتحقيق ذلك:
.gitattributes في الجزء العلوي من مستودع GIT: *.gpg diff=blackbox
.git/config : [diff "blackbox"]
textconv = gpg --use-agent -q --batch --decrypt
والآن ، ستعرض أوامر مثل git log -p file.gpg سجلًا رائعًا للتغييرات في الملف المشفر.
gpg: filename: skipped: No public key -عادةً ما يعني أن هناك عنصرًا في .blackbox/blackbox-admins.txt هذا ليس اسم المفتاح. إما تم إدخال شيء غير صالح (مثل اسم الملف بدلاً من اسم المستخدم) أو ترك المستخدم المؤسسة وتمت إزالة مفتاحه من سلسلة المفاتيح ، ولكن لم تتم إزالة اسمه من ملف Blackbox-admins.txt.
gpg: decryption failed: No secret key -يعني عادة أنك نسيت إعادة تدوير الملف بالمفتاح الجديد.
Error: can't re-encrypt because a key has expired. - انتهت صلاحية مفتاح المستخدم ولا يمكن استخدامه لتشفير المزيد. اتبع نصيحة المفاتيح منتهية الصلاحية.
FYI: قد يستخدم Repo الخاص بك keyrings/live بدلاً من .blackbox . انظر "أين يتم تخزين التكوين؟"
إذا تم نسخ الملفات من ريبو ، فلا يزال من الممكن فك تشفير وتحرير. من الواضح أن التعديلات والتغييرات على المفاتيح ، وسيتم فقدها إذا تم إجراؤها خارج الريبو. لاحظ أيضًا أن الأوامر من المرجح أن تعمل فقط إذا تم تشغيلها من الدليل الأساسي (أي الوالد إلى دليل .blackbox).
تم اختبار الأوامر التالية خارج ريبو:
blackbox_postdeployblackbox_edit_startblackbox_edit_end سيقوم التنفيذ الحالي بتخزين Blackbox In /keyrings بجذر الريبو بأكمله. سيؤدي ذلك إلى إنشاء مشكلة بين البيئات التي لها جذور مختلفة (أي فحص / على التطوير مقابل /releases/foo في الإنتاج). للتغلب على هذا ، يمكنك export BLACKBOX_REPOBASE=/path/to/repo وتعيين قاعدة محددة لإعادة الريبو.
تمت كتابة هذا في الأصل لـ GIT ويدعم التزامًا على مرحلتين ، حيث يعد commit بمثابة التزام محلي و "دفع" يرسل التغيير إلى خادم التحكم في الإصدار عندما يتم تسجيل شيء ما أو تم إلغاء تحديده مع النظام. commit التطبيق الحالي على الفور ملفًا (إلى خادم Subversion Optream) عند تنفيذ أمر blackbox_* .
في بعض المواقف ، يحتاج أعضاء الفريق أو الأدوار الآلية إلى تثبيت GPG 2.x إلى جانب إصدار GPG System الإصدار 1.x للحاق بإصدار GPG للفريق. على Ubuntu 16 ، يمكنك apt-get install gnupg2 الذي يقوم بتثبيت GPG2 الثنائي. إذا كنت ترغب في استخدام ثنائي GPG2 ، فتشغيل كل أمر Blackbox مع GPG = GPG2.
على سبيل المثال:
GPG=gpg2 blackbox_postdeploy
نرحب بالأسئلة وتقارير الأخطاء والتعليقات!
أفضل مكان للبدء هو الانضمام إلى القائمة البريدية Blackbox-Project واطلب هناك.
يتم تتبع الأخطاء هنا في جيثب. لا تتردد في الإبلاغ عن الحشرات بنفسك.
يتم الترحيب بتقديمات الرمز بكل سرور! الرمز سهل القراءة إلى حد ما.
احصل على الرمز:
git clone [email protected]:StackExchange/blackbox.git
اختبر تغييراتك:
make confidence
هذا يمر عبر عدد من اختبارات النظام. إنه ينشئ ريبو ، ويشفير الملفات ، وفك تشفير الملفات ، وما إلى ذلك. يمكنك إجراء هذه الاختبارات للتحقق من أن التغييرات التي أجريتها لم تكسر أي شيء. يمكنك أيضًا استخدام هذه الاختبارات للتحقق من أن النظام يعمل مع نظام تشغيل جديد.
يرجى إرسال الاختبارات مع تغييرات الكود:
أفضل طريقة لتغيير Blackbox هي عن طريق التطوير الذي يحركه الاختبار. أضف أولاً اختبارًا إلى tools/confidence.sh . يجب أن يفشل هذا الاختبار ، ويوضح الحاجة إلى التغيير الذي توشك على إجراءه. ثم إصلاح الخلل أو أضف الميزة التي تريدها. عند الانتهاء ، يجب أن تجتاز make confidence جميع الاختبارات. يجب أن يتضمن العلاقات العامة التي ترسلها الرمز الخاص بك وكذلك الاختبار الجديد. وبهذه الطريقة ، تتراكم اختبارات الثقة مع نمو النظام لأننا نعلم أن التغييرات المستقبلية لا تكسر الميزات القديمة.
ملاحظة: تفترض الاختبارات حاليًا "git" وتم اختبارها فقط على CentOS و Mac OS X و Cygwin. بقع مرحب به!
فيما يلي حزم مصادر مفتوحة أخرى تفعل شيئًا مشابهًا لـ Blackbox. إذا كنت تحبهم أفضل من Blackbox ، فيرجى استخدامها.
GIT-Crypt لديه أفضل تكامل GIT. بمجرد إعداده ، يكون ذلك شفافًا تقريبًا للمستخدمين. ومع ذلك فهو يعمل فقط مع git.
يتم إصدار هذا المحتوى تحت رخصة معهد ماساتشوستس للتكنولوجيا. انظر ملف الترخيص.
