ჩვენს წინა პოსტში, რომელიც ეხებოდა CI/CD Pipelines, ჩვენ ვნახეთ როგორ გავტეხოთ CI/CD სცენარი, რომელიც სავარაუდოდ დაცული იყო.
გავიხსენოთ წინა პოსტში ჩვენი აზრი: ჩვენ დავიწყეთ რამდენიმეთი pipeline რომელიც დაუცველი იყო არაპირდაპირი მოწამვლა Pipeline შესრულების (I-PPE) და, ამის გამოსასწორებლად, ჩვენ გადავწყვიტეთ გაგვეყო pipeline ორად:
- 1-ლი pipeline (CI-ის აწყობა), რომელიც უსაფრთხოა D-PPE-სა და I-PPE-სთვის, შეამოწმებს PR კოდს, შექმნის აწყობას და წარმოქმნის არტეფაქტს.
- 2 pipeline (CI ტესტი), ასევე უსაფრთხოა D-PPE-სთვის და I-PPE შეამოწმებს საბაზისო კოდს (shell სკრიპტის მოდიფიკაციის თავიდან ასაცილებლად) და შეასრულებს ორიგინალ სკრიპტებს არტეფაქტის წინააღმდეგ.
- ტესტის CI-ის სინქრონიზაციისთვის pipeline გასაშვებად Build CI-ის შემდეგ pipeline, გამოვიყენეთ სამუშაოს_გაშვება ტრიგერი.
ჩვენ ამას მესამე სცენარი დავარქვით.
მიუხედავად იმისა, რომ, როგორც ამ პოსტში აღვნიშნეთ, არსებობს სხვა გადაწყვეტილებები, ჩვენ გადავწყვიტეთ, ეს „გადაწყვეტილება“ პედაგოგიური მიზეზების გამო დაგვენერგა, რათა ღრმად ჩავუღრმავდეთ დაუცველობებს. CI/CD pipelines.
შემდეგ, ჩვენ ვნახეთ, თუ როგორ გაგვეტეხა ეს სცენარი არტეფაქტის მოწამვლა. ამას ჩვენ ვუწოდებთ არტეფაქტებით მოწამვლა, ანუ შეცვლის (გატეხვის) შესაძლებლობა pipeline ლოგიკა შეცვლით pipeline არტეფაქტი.
რა პრობლემაა ამ მიდგომასთან დაკავშირებით? ჩვენ ვნახეთ, რომ პრობლემა მაშინ ჩნდება, როდესაც ნებისმიერი მომხმარებელი „ქმნის“ ახალ pipeline.
თუ მომხმარებელი ხსნის PR-ს, რომელიც შეიცავს ახალს pipeline, GitHub შეასრულებს ამას pipeline (გარკვეული პირობების გათვალისწინებით, როგორც ვნახეთ პოსტში).
შემდეგ მომხმარებელს შეუძლია შექმნას ახალი pipeline იგივე სახელით, რაც Build CI!! დიახ, გასაკვირია, მაგრამ GitHub საშუალებას გაძლევთ შექმნათ ორი pipelineიგივე სახელით!!
როდესაც მომხმარებელი ხსნის PR-ს ამ ცვლილებებით, ახალი" pipeline შესრულდება (მოწამლული არტეფაქტის ატვირთვა) და განლაგების CI pipeline ამის შემდეგ შესრულდება, რის შედეგადაც „მოდიფიცირებული“ shell სკრიპტი გადაწერს „ორიგინალურ“ shell სკრიპტს, რომელიც მდებარეობს pipeline სამუშაო სივრცე. ამგვარად, ეს „გადაწყვეტა“ არ გამორიცხავს I-PPE დაუცველობას (როგორც ქვემოთ ვხედავთ)
რა პრობლემებია? სულ მცირე, რამდენიმე საკითხია:
- პირველი, როგორ დავრწმუნდეთ, რომ შექმნის პროცესი არ არის დაზიანებული? ამ სცენარში, მავნე მომხმარებელს შეეძლო დაგეგმილი შექმნის პროცესის შეცვლა მათი გამოყენებით. pipeline მოწამლული არტეფაქტის შესაქმნელად.
- მეორე, როგორ შეგვიძლია შევაფასოთ არტეფაქტის წარმომავლობა?
ეს კითხვები გვაიძულებს, მკლავებში ჩავვარდეთ პროგრამული უზრუნველყოფის ატესტაციები დომენი!!
პროგრამული უზრუნველყოფის ატესტაციები
An სერტიფიკატი არის ნაჭერი მონაცემები წარმოადგენს მოვლენის დამადასტურებელი საბუთირეალურ სამყაროში, ჩვენ ზოგადად მათ ვუწოდებთ სერთიფიკატები.
მაგალითად, როდესაც ლაბორატორია თქვენს სისხლს ამოწმებს, ტესტის შესახებ მონაცემები აღირიცხება და დამოწმებულია. სისხლის ანალიზის შედეგები მოწმდება მდე კვალი.
ჩვენს IT სფეროსთან უფრო ახლოს, შეგიძლიათ გამოიცნოთ, როგორი იქნებოდა ამ პროცესის თარგმნა, მაგალითად, კომპილაციის პროცესად.
ინფორმაცია კომპილაციის სერვერის გარემოსა და ხელსაწყოების, მასალების (წყაროს კოდი) და პროდუქტების/არტეფაქტების (ბინარული კოდი) შესახებ ასეთი დამოწმების ნაწილი იქნება.
ცხადია, სანდოობის უზრუნველსაყოფად, დამოწმება უნდა იყოს გენერირებული უფლებამოსილი (ავტორიზებული და არაუარყოფითი) ატესტატის მიერ.
შესაძლოა, ზოგიერთ თქვენგანს გაუჩნდეს კითხვა... და რა არის... განსხვავება ხელმოწერებსა და დოკუმენტებს შორის?
კოდის ხელმოწერები და ატესტაციები
მაღალ დონეზე, ა. ხელმოწერა იქმნება გასაღებების წყვილისა და არტეფაქტის გამოყენებით. გასაღებების წყვილი შედგება საჯარო და კერძო გასაღებისგან.
მომხმარებელი არტეფაქტს ხელს აწერს პირადი გასაღების გამოყენებით, რის შემდეგაც სხვებს შეუძლიათ ხელმოწერის დადასტურება საჯარო გასაღების გამოყენებით. პირადი გასაღები საიდუმლოდ უნდა იყოს შენახული, თუმცა საჯარო გასაღები ფართოდ არის გავრცელებული.
ხელმოწერების გამოყენება შესაძლებელია იმის დასამტკიცებლად, რომ კერძო გასაღების მფლობელმა გამოიყენა კერძო გასაღები არტეფაქტის ხელმოწერისთვის.
ხელმოწერები არ დაამტკიცო
- მომხმარებლის განზრახვა არტეფაქტზე ხელის მოსაწერად (შესაძლოა, მოტყუებულები იყვნენ), ან
- მომხმარებლის განზრახვა, გააკეთოს ნებისმიერი კონკრეტული პრეტენზია არტეფაქტთან დაკავშირებით
ერთად ატესტაციებიარტეფაქტზე პირდაპირ ხელმოწერის ნაცვლად, მომხმარებლები ქმნიან რაიმე სახის დოკუმენტი ეს იპყრობს მათ განზრახვას არტეფაქტის ხელმოწერის უკან და ნებისმიერი კონკრეტული პრეტენზიები ამ ხელმოწერის ნაწილად კეთდება.
ინ-ტოტო ატესტაციის ჩარჩო
ყველაზე გავრცელებული ჩარჩო არის ტოტალური ატესტაციის ჩარჩო
- განსაზღვრავს standard ატესტაციების ფორმატი რომლებიც სუბიექტებს, აღწერილ არტეფაქტებს, არტეფაქტის შესახებ ავთენტიფიკაციაზე დადასტურებულ მეტამონაცემებს აკავშირებენ
- უზრუნველყოფს კომპლექტს წინასწარ განსაზღვრული პრედიკატები ავთენტიფიცირებული მეტამონაცემების პროგრამული უზრუნველყოფის მიწოდების ჯაჭვებში და მათ შორის გადაცემისთვის
მოდით, უფრო დეტალურად განვიხილოთ დამოწმების ფორმა.
An ატესტაცია არის ციფრულად ხელმოწერილი დოკუმენტი რომელიც შეიცავს განცხადებები.
ის განცხადება არის დამოწმების შუა ფენა, რომელიც მას კონკრეტულთან აკავშირებს თემატიკა და ცალსახად განსაზღვრავს ტიპებს პრედიკატი:
- თემატიკა: არტეფაქტზე კრიპტოგრაფიულად უსაფრთხო მითითება (ჩვეულებრივ, ჰეშის საშუალებით) და
- პრედიკატები: კონკრეტული კომპლექტი პრეტენზიები ამ არტეფაქტის შესახებ განცხადებას განცხადება ეწოდება. ეს მტკიცებები შეიძლება გამოყენებულ იქნას ნებისმიერი რამის გამოსახატავად (და მოგვიანებით დასამტკიცებლად), რაც კი შეიძლება წარმოიდგინოთ! მათ შეუძლიათ წარმოადგინონ ხელით დამტკიცება, არტეფაქტის წარმომავლობა, ავტომატური ტესტის შედეგები, აუდიტის კვალი ან სხვა!
როდესაც ეს განცხადება კრიპტოგრაფიულად არის ხელმოწერილი, მას შემდეგ მოიხსენიებენ, როგორც ატესტაცია
ამ გზით, მაგალითად, ალისა ქმნის განცხადებას არტეფაქტის შესახებ და ხელს აწერს მას თავისი პირადი გასაღების გამოყენებით, რითაც ქმნის ატესტაციას.
- ბობს შემდეგ შეუძლია ხელმოწერის დადასტურება ამ დამოწმებაში, რაც მას საშუალებას აძლევს პრეტენზიების ნდობა შიგნით.
შემდეგ ბობს შეუძლია გამოიყენოს ეს პრეტენზიები გადაწყვიტოს დაუშვებენ თუ არა ამ არტეფაქტის გამოყენებას.
შეუძლია თუ არა ატესტაციებს არტეფაქტებით მოწამვლის პრობლემის მოგვარებაში დახმარება?
ატესტაციების ამ შესავლის შემდეგ, დავუბრუნდეთ ჩვენს პრობლემას. როგორ შეიძლება დაგვეხმაროს ატესტაციები ჩვენი პრობლემის გადაჭრაში, ანუ არტეფაქტებით მოწამვლის თავიდან აცილებაში?
მავნე მომხმარებელს შეეძლო არტეფაქტის შექმნა „ოფიციალური“ მექანიზმის გვერდის ავლით, ანუ მისი გამოყენებით. pipeline არტეფაქტის შესაქმნელად.
საოცარი იქნებოდა, თუ დავამტკიცებდით, რომ გადმოწერილი არტეფაქტები ოფიციალური წყაროებით არის შექმნილი. pipelineს. ეს მხოლოდ ერთი მაგალითია იმისა, რასაც შეგვიძლია „გაყალბების წერტილები“ ვუწოდოთ, თუმცა შეიძლება სხვა მრავალიც არსებობდეს.
როგორც ზემოთ მოცემულ სურათზე ხედავთ, ხელყოფის წერტილები მრავალრიცხოვანია. ამ გზით, მომხმარებელი pipeline (ტესტი CI ჩვენს მაგალითში) უნდა შეაფასოს მშენებლობის პროცესის მთლიანობა ასევე თავად არტეფაქტის მთლიანობა.
ჩვენს მაგალითში, მოწამლული არტეფაქტი შეიქმნა ახალი (მოწამლული) არტეფაქტის შემოღებით. pipeline რომელიც აწყობის პროცესს არღვევს. თუმცა, მავნე მომხმარებელს შეეძლო:
- კოდის შეცვლა შემოწმების შემდეგ SCM მავნე ორობითი ფაილის გენერირებისთვის
- კომპილაციის მიერ წარმოებული სწორი ორობითი ფაილის შეცვლა ნებისმიერი სხვა მავნე ორობითი ფაილით
- არტეფაქტების რეესტრის კომპრომეტირება და სხვა გზით შექმნილი მოწამლული არტეფაქტის ატვირთვა
- ა.შ.
როგორც ხედავთ, შეიძლება არსებობდეს რამდენიმე „გაყალბების“ წერტილი.
რა არის აქ მნიშვნელოვანი? ცხადია, ყველა იმ „გაყალბების“ წერტილის დაცვა. მაგრამ, საბოლოო ჯამში, ყველაზე მნიშვნელოვანი ის არის, რომ რომ არტეფაქტის „მომხმარებელს“ შეეძლოს არტეფაქტის მთლიანობის შეფასება და გადაწყვიტოს, გააგრძელოს თუ არა მისი გამოყენება.
ჩვენ შეგვიძლია არტეფაქტის მთლიანობის შეფასება ორი გზით.
ერთ-ერთი მათგანია იმის შეფასება, ადგილწარმოშობის არტეფაქტის.
გენერირებით წარმომავლობის დადასტურება, ჩვენ გთავაზობთ სასარგებლო მეტამონაცემებს (სათანადოდ ავტორიზებული და არაუარყოფილი) არტეფაქტის შესახებ. შემდეგ მაგალითებში ჩვენ გამოვიყენებთ ქსიგენი SALT (სანდობი პროგრამული უზრუნველყოფის ატესტაციების ფენა), კომპონენტი პროგრამული უზრუნველყოფის ატესტაციების გენერირების, რეგისტრაციისა და დადასტურებისთვის.
- 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
ზემოთ მოცემულ კოდში ხედავთ, რომ არსებობს ნაბიჯი, რომელიც ქმნის war ფაილს და მეორე ნაბიჯი, რომელიც წარმოქმნის წარმომავლობის დადასტურება. ამის გასაკეთებლად, pipeline იყენებს კერძო გასაღებს და ასევე მოიცავს საჯარო გასაღებს ატესტაციაში.
კულისებში, Xygeni-ს მარილი ბრძანება ინახავს დადასტურებას ledger (ასევე ცნობილია, როგორც ატესტაციის რეესტრი, ჩანაწერი ჩვენს შემთხვევაში, მაგრამ შეგიძლიათ გამოიყენოთ ნებისმიერი სხვა). ამის შემდეგ, მომხმარებელმა 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 ეს მხოლოდ ერთი შემოწმების პუნქტია, თუმცა, როგორც ადრე აღვნიშნეთ, არსებობს სხვა შემოწმების პუნქტებიც.
მაგალითად, რა მოხდება, თუ საწყისი კოდი შეცვლილია რეპო შემოწმების შემდეგ და build ბრძანების შესრულებამდე? ამ შემთხვევაში, ასაშენებელი კოდი არ არის იგივე, რაც შენახულია 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 შესრულება (PPE)“ ან ნებისმიერი სხვა პოსტი, რომელიც კვლავ გამოიწვევს თქვენს ინტერესს!
დარჩით ჩვენთან, ჩვენ დეტალურად განვიხილავთ პროგრამული უზრუნველყოფის ატესტაციებს და build security შემდგომ ბლოგ პოსტებში.
