في مقالتنا السابقة حول CI/CD Pipelines, رأينا كيفية اختراق CI/CD السيناريو ذلك محتمل كان محميا.
ولنتذكر وجهة نظرنا في المشاركة السابقة: لقد بدأنا مع بعض pipeline التي كانت عرضة ل التسمم غير المباشر Pipeline التنفيذ (I-PPE)، ولإصلاح هذه المشكلة، قررنا تقسيم pipeline إلى قسمين:
- و1st pipeline (Build CI)، الآمن لـ D-PPE وI-PPE، سوف يقوم بمراجعة رمز PR، وإجراء البناء، وإنشاء قطعة أثرية
- و 2nd pipeline (اختبار CI)، الآمن أيضًا لـ D-PPE وI-PPE سوف يقوم بفحص الكود الأساسي (لتجنب تعديل البرنامج النصي للصدفة) وتنفيذ البرامج النصية الأصلية مقابل القطعة الأثرية.
- لمزامنة اختبار CI pipeline للتشغيل بعد Build CI pipeline، كنا Workflow_run اثار.
لقد أطلقنا على هذا اسم السيناريو رقم 3.
على الرغم من وجود حلول أخرى، كما ذكرنا في تلك التدوينة، فقد قررنا تنفيذ هذا "الحل" لأسباب تربوية، حتى نتمكن من التعمق في نقاط الضعف CI/CD pipelines.
بعد ذلك، رأينا كيفية اختراق هذا السيناريو تسمم قطعة أثرية. هذا ما نسميه التسمم بالقطع الأثرية، أي القدرة على تعديل (الإختراق) pipeline المنطق عن طريق تعديل أ pipeline الأداة.
ما هي المشكلة في هذا النهج؟ لقد رأينا أن المشكلة تنشأ عندما يقوم أي مستخدم "بإنشاء" ملف جديد pipeline.
إذا قام المستخدم بفتح PR يحتوي على ملف جديد pipelineسيقوم GitHub بتنفيذ ذلك pipeline (مع مراعاة بعض الشروط، كما رأينا في المنشور).
يصبح المستخدم بعد ذلك قادرًا على إنشاء ملف جديد pipeline بنفس اسم Build CI !! نعم، إنه أمر مفاجئ، لكن GitHub يسمح لك بإنشاء اثنين pipelineس بنفس الاسم!!
عندما يفتح المستخدم PR مع هذه التغييرات، الجديد" pipeline سيتم إعدامه (تحميل قطعة أثرية مسمومة) ونشر CI pipeline سيتم تنفيذه بعد ذلك، مما يؤدي إلى استبدال نص الصدفة "المعدل" فوق نص الصدفة "الأصلي" الموجود في pipeline مساحة العمل. لذلك، فإن هذا "الحل" لا يتجنب ثغرة I-PPE (كما نرى أدناه)
ما هي المشاكل؟ على الأقل، هناك مسألتان:
- أولا، كيف يمكن التأكد من عدم العبث بعملية البناء؟ في هذا السيناريو، تمكن المستخدم الضار من تعديل عملية الإنشاء المقصودة باستخدام pipeline لإنشاء قطعة أثرية مسمومة.
- ثانيا، كيف يمكننا تقييم مصدر قطعة أثرية؟
هذه الأسئلة تضعنا في أحضان شهادات البرمجيات اِختِصاص!!
شهادات البرمجيات
An شهادة قطعة البيانات تمثل دليل على الحدث. في العالم الحقيقي، نسميها عمومًا الشهادات.
على سبيل المثال، عندما يقوم أحد المختبرات بفحص دمك، يتم تسجيل البيانات المتعلقة بالاختبار واعتمادها. نتائج فحص الدم هي يمكن التحقق منها و تعقبها.
وبالقرب من مجال تكنولوجيا المعلومات لدينا، يمكنك تخمين ما يمكن أن يكون ترجمة لهذه العملية، على سبيل المثال، إلى عملية تجميع.
ستكون المعلومات حول بيئة خادم الترجمة وأدواته والمواد (كود المصدر) والمنتجات/المنتجات (الكود الثنائي) جزءًا من هذه الشهادة.
من الواضح أن الشهادة يجب أن يتم إنشاؤها من قبل مصدق معتمد (موثق وغير قابل للإنكار) لتوفير المصداقية.
من المحتمل أن البعض منكم قد يفكر.. وما هو الفرق بين التوقيعات والشهادات?
توقيعات الرمز والشهادات
وعلى مستوى عال أ توقيع يتم إنشاؤه باستخدام زوج المفاتيح وقطعة أثرية. يتكون زوج المفاتيح من مفتاح عام ومفتاح خاص.
يقوم المستخدم بتوقيع قطعة أثرية باستخدام المفتاح الخاص، ويمكن للآخرين بعد ذلك التحقق من التوقيع باستخدام المفتاح العام. يجب أن يظل المفتاح الخاص سريًا، ولكن يتم توزيع المفتاح العام على نطاق واسع.
يمكن استخدام التوقيعات لإثبات أن صاحب المفتاح الخاص استخدم المفتاح الخاص للتوقيع على القطعة الأثرية.
التواقيع لا تثبت
- المستخدمين نية للتوقيع على القطعة الأثرية (ربما تم خداعهم)، أو
- نية المستخدم لجعل أي مطالبة محددة حول قطعة أثرية
مع شهادات، فبدلاً من التوقيع على قطعة أثرية مباشرةً، يقوم المستخدمون بإنشاء نوع من وثيقة أن يلتقط نيتهم وراء التوقيع على قطعة أثرية وأي مطالبات محددة يتم إجراؤها كجزء من هذا التوقيع.
إطار التصديق الشامل
الإطار الأكثر شيوعًا هو إطار التصديق الشامل
- يعرف standard نموذج للشهادات التي تربط الموضوعات، والقطع الأثرية الموصوفة، بالبيانات الوصفية الموثقة حول القطعة الأثرية
- يوفر مجموعة من المسندات المحددة مسبقا لتوصيل بيانات التعريف المصادق عليها عبر سلاسل توريد البرامج وعبرها
دعنا نتناول بعض التفاصيل حول تنسيق الشهادة.
An شهادة هو وثيقة موقعة رقميا يحتوي على صياغات.
استخدم ملخص الحساب هي الطبقة الوسطى من الشهادة، وربطها بمعين الموضوع وتحديد أنواعها بشكل لا لبس فيه فاعل:
- الموضوع: و مرجع آمن تشفيريًا للقطعة الأثرية (عادة عن طريق التجزئة)، و
- المسندات: مجموعة محددة مطالبات حول تلك القطعة الأثرية يشار إليها بالبيان. يمكن استخدام هذه الادعاءات للتعبير (وإثبات لاحقًا) عن أي شيء يخطر ببالك! يمكن أن تمثل الموافقة اليدوية، أو مصدر القطعة الأثرية، أو نتائج الاختبار الآلي، أو مسار التدقيق، أو أكثر!
عندما يتم توقيع هذا البيان بشكل مشفر، تتم الإشارة إليه بعد ذلك باسم شهادة
بهذه الطريقة، على سبيل المثال، تقوم أليس بإنشاء بيان حول قطعة أثرية وتوقيعه باستخدام مفتاحها الخاص، مما يؤدي إلى إنشاء شهادة.
- يمكن لبوب بعد ذلك التحقق من التوقيع في تلك الشهادة، جوازاً له للثقة في المطالبات في الداخل.
يمكن لبوب بعد ذلك استخدام تلك الادعاءات كي تقرر ما إذا كان سيتم السماح باستخدام هذه القطعة الأثرية أم لا.
هل يمكن أن تساعد الشهادات في حل مشكلة التسمم بالقطع الأثرية؟
بعد هذه المقدمة إلى الشهادات، دعونا نعود إلى مشكلتنا. كيف يمكن أن تساعدنا الشهادات في حل مشكلتنا، أي تجنب التسمم بالقطع الأثرية؟
تمكن المستخدم الضار من إنشاء قطعة أثرية تتجاوز الآلية "الرسمية"، أي باستخدام جهازه pipeline لتوليد قطعة أثرية.
سيكون من المدهش أن نتمكن من إثبات أن القطع الأثرية التي يتم تنزيلها قد تم بناؤها بالتعاون مع المسؤول pipelineس. وهذا مجرد مثال واحد لما يمكن أن نطلق عليه "نقاط التلاعب"، ولكن قد يكون هناك العديد من الأمثلة الأخرى.
وكما ترون في الصورة أعلاه فإن نقاط التلاعب متعددة. بهذه الطريقة المستهلك pipeline (اختبار CI في مثالنا) يجب تقييم سلامة عملية البناء فضلا عن سلامة القطعة الأثرية نفسها.
في مثالنا، تم إنشاء القطعة الأثرية المسمومة عن طريق إدخال (مسمومة) جديدة pipeline الذي يعبث بعملية البناء ولكن كان من الممكن أن يتمكن المستخدم الضار من القيام بما يلي:
- تعديل الكود بعد الخروج من SCM لتوليد ملف ثنائي ضار
- استبدل الثنائي الصحيح الناتج عن التجميع بأي ثنائي ضار آخر
- اختراق سجل القطع الأثرية وتحميل قطعة أثرية مسمومة تم إنشاؤها بأي طريقة أخرى
- وما إلى ذلك.
كما ترون، قد تكون هناك نقاط "تلاعب" متعددة.
ما هو المهم هنا؟ من الواضح أن حماية كل نقاط "العبث" تلك. لكن في النهاية الأهم هو أن "مستهلك" القطعة الأثرية يمكنه تقييم سلامة القطعة الأثرية، ويقرر ما إذا كان سيمضي قدمًا أم لا.
يمكننا تقييم سلامة قطعة أثرية بطريقتين.
واحد هو من خلال تقييم مصدر من القطعة الأثرية.
من خلال توليد أ شهادة المصدر، نحن نقدم بيانات وصفية مفيدة (موثقة بشكل صحيح وغير مرفوضة) حول القطعة الأثرية. وفي الأمثلة التالية سوف نستخدم ملح زيجيني (طبقة شهادات البرامج من أجل الثقة)، المكون الخاص بإنشاء شهادات البرامج وتسجيلها والتحقق منها.
- name: Building ...
run: |
# mvn will compile and create target/MyApp.war
mvn clean package
- name: Generating provenance
run: |
#!/usr/bin/env bash
shopt -s expand_aliases
alias salt=$PWD/salt_pro/xygeni_salt/salt
echo " "
echo "-----------"
echo "Generating Provenance with CLI ..."
salt at slsa \
--basedir ${GITHUB_WORKSPACE}/target \
--key="${PRIVATE_KEY}" \
--public-key=${GITHUB_WORKSPACE}/Test1_public.pem \
--key-password=${KEY_PASSWD} \
--output-unsigned=${GITHUB_WORKSPACE}/cli_provenance_${PIPELINE}_unsigned.json \
--pipeline ${PIPELINE} --pretty-print \
--file ./MyApp.war
في الكود أعلاه، يمكنك أن ترى أن هناك خطوة لإنشاء ملف الحرب وخطوة ثانية لإنشاء ملف شهادة المصدر. للقيام بذلك، pipeline يستخدم المفتاح الخاص ويتضمن أيضًا المفتاح العام في التصديق.
خلف الكواليس، زيجيني ملح يقوم الأمر بتخزين الشهادة في ملف دفتر الحسابات (ويعرف أيضًا باسم سجل الشهادات، سجل في حالتنا ولكن يمكنك استخدام أي دولة أخرى). افعل ذلك أيها المستهلك pipeline يمكن أن تشمل Xygeni محرك التحقق للتحقق من مصدر القطعة الأثرية وتقييم سلامتها.
- name: 'Verifying the attestation'
run: |
#!/usr/bin/bash
echo " "
echo "-------"
# Calculate sha256sum for the artifact
SHA_SUM=$(sha256sum ./MyApp.war | cut -f1 -d ' ')
# Recover the attestation Id from the sha256sum
ATT_ID=$(echo $(salt -q registry search --digest sha256:$SHA_SUM --format json) | jq -r .[-1].gitoidSha256)
echo " "
echo "-------"
# Download the provenance attestation
echo "Downloading the provenance attestation ..."
salt -q reg get --id=$ATT_ID --format=json > ${GITHUB_WORKSPACE}/provenance_kk.signed.json
echo " "
echo "-------"
echo "Verifying provenance ..."
salt verify \
--basedir ${GITHUB_WORKSPACE} \
--attestation=${GITHUB_WORKSPACE}/provenance_kk.signed.json \
--public-key=${GITHUB_WORKSPACE}/Test1_public.pem \
--file ./MyApp.war
تقوم عملية التحقق بتقييم:
- استخدم قطعة أثرية sha256sum صالحة (أي أن هناك شهادة حول ذلك "الموضوع")، و
- استخدم يتم التصديق على الشهادة بشكل صحيح (تم إنشاؤه باستخدام المفتاح الخاص المناسب)
يمكن لعملية التحقق هذه تقييم صحة كل من القطعة الأثرية والشهادة.
ولكن، كما تتذكر، في حالتنا، تم إنشاء القطعة الأثرية بواسطة برنامج "خبيث" pipeline (أي ليس الأصلي عن طريق تعديل pipeline). ثم يجب علينا المضي قدمًا والتحقق من جانب آخر: ذلك تم إنشاء القطعة الأثرية بواسطة "الأصلي" pipeline، وليس أي واحد آخر.
للقيام بذلك، ما عليك سوى تضمين سطر بسيط للتحقق من هذا الشرط، على سبيل المثال:
echo " "
echo "-------"
# Download the provenance attestation
echo "Downloading the provenance attestation ..."
salt -q reg get --id=$ATT_ID --format=json > ${GITHUB_WORKSPACE}/provenance_kk.signed.json
WFR=$(jq -r .payload ${GITHUB_WORKSPACE}/provenance_kk.signed.json |base64 -d | jq -r .predicate.buildDefinition.internalParameters.environment.GITHUB_WORKFLOW_REF)
echo $WFR | grep cicd_top10_3_salt\/.github\/workflows\/build.yml
سوف يفشل هذا الفحص الإضافي إذا لم يتم إنشاء القطعة الأثرية بواسطة "الخزنة" الخاصة بنا. pipeline.
إذا تم إنشاء قطعة أثرية من أصلنا pipeline (cicd_top10_3_salt/.github/workflows/build.yml)، سينجح أمر grep، وإلا فسوف يفشل، مما يؤدي إلى كسر pipeline وإجهاض أي خطوات أخرى.
البناء" pipeline هي مجرد نقطة تلاعب واحدة يجب التحقق منها، ولكن، كما ذكرنا من قبل، هناك بعض نقاط التلاعب الأخرى التي يجب علينا التحقق منها.
على سبيل المثال، ماذا لو تم التلاعب بالكود المصدري بعد الخروج من الريبو وقبل أمر الإنشاء؟ في هذه الحالة، الكود الذي سيتم بناؤه ليس هو نفسه المخزن في SCM.
يعد التحقق من نقطة التلاعب هذه أمرًا سهلاً للغاية حيث يتم التحقق من تجزئات المادة في كل خطوة.
SHA_ATT_MATERIAL=$(jq -r .payload ${GITHUB_WORKSPACE}/provenance_kk.signed.json | base64 -d | jq -r .predicate.attestations[0].predicate.materials[].digest[])
SHA_STEP_MATERIAL=$(jq -r .payload ${GITHUB_WORKSPACE}/provenance_kk.signed.json | base64 -d | jq -r .predicate.attestations[3].predicate.materials[0].digest[])
استنتاجات
باختصار، أ التصديق على البرمجيات هو تأكيد يتم إجراؤه بشأن جزء من البرنامج، أي بيان موثق (بيانات وصفية) حول قطعة أثرية من البرنامج أو مجموعة من عناصر البرنامج.
شهادات البرامج هي تعميم للتوقيع الخام/الكود. الشهادة عبارة عن مستند موقع (بتنسيق معين، يعتمد عادةً على JSON) يربط البيانات التعريفية بالمنتج. وهي تمثل دليلاً يربط بين المدخلات (المواد) والمخرجات (المنتجات المنتجة) في كل خطوة بناء.
توفر الشهادات سجلاً يمكن التحقق منه للخطوات التي تم إجراؤها لبناء منتجات البرنامج النهائية، بما في ذلك مواد الإدخال لكل خطوة وتشغيل أوامر البناء.
في الختام، تعد شهادات البرامج آلية رائعة للتحقق من العديد من جوانب السلامة المختلفة لعملية البناء لدينا.
انتهيت من السلسلة؟ لا تقلق! لا تتردد في العودة إلى "تسمم Pipeline التنفيذ (معدات الوقاية الشخصية)أو أي مشاركة أخرى تثير اهتمامك مرة أخرى!
ترقبوا المزيد، حيث سنتعمق في شهادات البرامج و build security في منشورات المدونة القادمة.
