Əvvəlki paylaşımımızda bu barədə CI/CD Pipelines, Biz gördük necə hack etmək olar CI/CD ssenari ki ehtimal ki qorunurdu.
Əvvəlki yazıdakı fikrimizi xatırlayaq: bəziləri ilə başladıq pipeline həssas idi Dolayı yolla zəhərlənib Pipeline Icra (I-Fərdi Mühafizə Vasitələri) və bunu düzəltmək üçün bölməyə qərar verdik pipeline ikiyə bölünür:
- 1st pipeline (Build CI), D-PPE və I-PPE üçün təhlükəsizdir, PR kodunu yoxlayacaq, quruluşu yaradacaq və artefakt yaradacaq
- 2nd pipeline (Test CI), həmçinin D-PPE və I-PPE üçün təhlükəsizdirsə, baza kodunu yoxlayar (qabıq skriptinin dəyişdirilməsinin qarşısını almaq üçün) və orijinal skriptləri artefaktla birlikdə icra edərdi.
- Test CI-ni sinxronlaşdırmaq üçün pipeline Build CI-dən sonra işə salmaq pipeline, istifadə etdik iş axını_qaçması tetikleyici.
Biz buna Ssenari #3 adını verdik.
Həmin yazıda qeyd etdiyimiz kimi, başqa həllər də olsa, pedaqoji səbəblərdən bu "həlli" tətbiq etməyə qərar verdik ki, zəiflikləri dərindən araşdıra bilək. CI/CD pipelines.
Daha sonra, bu ssenarini necə sındırmağı gördük artefaktı zəhərləməkBiz buna belə deyirik Artefakt Zəhərlənməsi, yəni dəyişdirmək (hack etmək) imkanı pipeline a-nı dəyişdirərək məntiq pipeline artefakt.
Bu yanaşmanın problemi nədir? Problemin hər hansı bir istifadəçi yeni bir şey "yaratdıqda" ortaya çıxdığını gördük. pipeline.
Əgər istifadəçi yeni bir məzmunlu PR açarsa pipeline, GitHub bunu icra edəcək pipeline (gördüyümüz kimi, bəzi şərtlər nəzərə alınmaqla) postda).
İstifadəçi daha sonra yeni bir fayl yarada bilər pipeline Build CI ilə eyni adla!! Bəli, təəccüblüdür, amma GitHub sizə iki yaratmağa imkan verir pipelineeyni adlı s!!
İstifadəçi bu dəyişikliklərlə PR açdıqda, yeni" pipeline edam ediləcək (zəhərlənmiş bir artefakt yüklənəcək) və Yerləşdirmə CI pipeline bundan sonra icra ediləcək və nəticədə "dəyişdirilmiş" shell skripti, yerləşən "orijinal" shell skriptinin üzərinə yazılacaq. pipeline iş sahəsi. Beləliklə, bu "həll yolu" I-PPE zəifliyindən qaçınmır (aşağıda görə biləcəyimiz kimi)
Problemlər nələrdir? Ən azı bir neçə problem var:
- Birincisi, Quraşdırma prosesinin dəyişdirilmədiyinə necə əmin olmaq olar? Bu ssenaridə, zərərli istifadəçi öz proqramlarından istifadə edərək nəzərdə tutulan qurma prosesini dəyişdirə bilib pipeline zəhərlənmiş bir artefakt yaratmaq.
- İkincisi, Bir artefaktin mənşəyini necə qiymətləndirə bilərik?
Bu suallar bizi qucağına atır Proqram Təminatı Sertifikatları domen!!
Proqram Təminatı Sertifikatları
An attestasiya bir parçadır məlumat təmsil bir hadisənin sübutuReal dünyada biz ümumiyyətlə bunları adlandırırıq sertifikatlar.
Məsələn, laboratoriya qanınızı yoxladıqda, test haqqında məlumatlar qeydə alınır və təsdiqlənir. Qan testinin nəticələri aşağıdakılardır: doğrulanabilir və izlənilə bilən.
İT sahəmizə daha yaxından baxsaq, bu prosesin, məsələn, tərtib prosesinə necə tərcümə olunacağını təxmin edə bilərsiniz.
Kompilyasiya server mühiti və alətləri, materiallar (mənbə kodu) və məhsullar/artefaktlar (ikili kod) haqqında məlumat belə təsdiqləmənin bir hissəsi olardı.
Aydındır ki, etibarlılığı təmin etmək üçün təsdiqləmə səlahiyyətli bir təsdiqləyici (təsdiqlənmiş və təkzib edilə bilməyən) tərəfindən aparılmalıdır.
Yəqin ki, bəziləriniz düşünürsünüz... və nədir? imzalar və təsdiqlər arasındakı fərq?
Kod imzaları və sertifikatlar
Yüksək səviyyədə, bir imza açar cütü və artefakt istifadə edilərək yaradılır. Açar cütü açıq açardan və gizli açardan ibarətdir.
İstifadəçi gizli açardan istifadə edərək artefaktı imzalayır və digərləri daha sonra açıq açardan istifadə edərək imzanı yoxlaya bilərlər. Şəxsi açar gizli saxlanılmalıdır, lakin açıq açar geniş şəkildə yayılır.
İmzalardan istifadə etmək olar gizli açarın sahibinin artefaktı imzalamaq üçün gizli açardan istifadə etdiyini sübut etmək üçün.
İmzalar sübut etmə
- İstifadəçinin niyyət artefaktı imzalamaq (onlar aldadıla bilər), və ya
- İstifadəçinin hər hansı bir şeyi etmək niyyəti artefakt haqqında konkret iddia
ilə Sertifikatlar, istifadəçilər artefaktı birbaşa imzalamaq əvəzinə, bir növ yaradırlar sənəd O onların niyyətini ələ keçirir artefaktın imzalanmasının arxasında və hər hansı birində xüsusi iddialar bu imzanın bir hissəsi kimi hazırlanır.
Daxili Attestasiya Çərçivəsi
Ən çox yayılmış çərçivədir Tam Attestasiya Çərçivəsi
- bir müəyyən standard sertifikatlaşdırma üçün format təsvir edilən artefaktları artefakt haqqında təsdiqlənmiş metaməlumatlara bağlayan subyektlər
- bir sıra təmin edir əvvəlcədən təyin olunmuş predikatlar proqram təminatı təchizatı zəncirləri boyunca və arasında təsdiqlənmiş metaməlumatların ötürülməsi üçün
Gəlin təsdiqləmə formatı haqqında bir az daha ətraflı məlumat verək.
An Attestasiya birdir rəqəmsal imzalı sənəd ehtiva edir Bəyanatlar.
The Bəyanat sertifikatlaşdırmanın orta təbəqəsidir və onu müəyyən bir şeyə bağlayır mövzu və növlərini birmənalı şəkildə müəyyən edir Əvvəlcədən:
- mövzu: Bu artefakt üçün kriptoqrafik cəhətdən təhlükəsiz istinad (adətən heş vasitəsilə) və
- Predikatlar: spesifik bir sıra iddialar Həmin artefakt haqqında Bəyanat deyilir. Bu iddialar ağlınıza gələn hər şeyi ifadə etmək (və sonradan sübut etmək) üçün istifadə edilə bilər! Onlar əl ilə təsdiq, artefaktın mənşəyi, avtomatlaşdırılmış test nəticələri, audit izi və ya daha çoxunu təmsil edə bilər!
Bu Bəyanat kriptoqrafik şəkildə imzalandıqda, o, daha sonra a adlanır Attestasiya
Bu şəkildə, nümunə olaraq, Alis bir artefakt haqqında bir Bəyanat yaradır və onu öz şəxsi açarından istifadə edərək imzalayır və Təsdiq yaradır.
- Bob sonra edə bilər imzanı təsdiqləyin həmin Attestasiyada ona icazə verir iddialara etibar etmək içəri.
Bob daha sonra həmin iddialardan istifadə edə bilər qərar bu artefaktın istifadəsinə icazə verilib-verilməməsi.
Sertifikatlar artefakt zəhərlənməsinin həllinə kömək edə bilərmi?
Təsdiqlərə girişdən sonra problemimizə qayıdaq. Sertifikatlaşdırmalar problemimizi həll etməyə, yəni artefakt zəhərlənməsinin qarşısını almağa necə kömək edə bilər?
Zərərli istifadəçi "rəsmi" mexanizmi keçərək, yəni öz mexanizmindən istifadə edərək artefakt yarada bilmişdir pipeline artefaktı yaratmaq üçün.
Yüklənilən əsərlərin rəsmi olaraq yaradıldığını sübut edə bilsək, inanılmaz olardı pipelines. Bu, "Saxtakarlıq nöqtələri" adlandıra biləcəyimiz şeylərdən yalnız bir nümunədir, lakin bir çox başqa nümunələr də ola bilər.
Yuxarıdakı şəkildə gördüyünüz kimi, müdaxilə nöqtələri çoxdur. Bu şəkildə istehlakçı pipeline (Bizim nümunəmizdə CI testi) qiymətləndirməlidir tikinti prosesinin bütövlüyü kimi artefaktın özünün bütövlüyü.
Bizim nümunəmizdə, zəhərlənmiş artefakt yeni (zəhərlənmiş) bir maddənin daxil edilməsi ilə yaradılmışdır. pipeline qurma prosesinə müdaxilə edir. Lakin zərərli istifadəçi aşağıdakıları edə bilərdi:
- yoxlanıldıqdan sonra kodu dəyişdirin SCM zərərli ikili fayl yaratmaq üçün
- kompilyasiya tərəfindən yaradılan düzgün binar faylı istənilən digər zərərli binar faylla əvəz edin
- Artefakt Reyestrini pozun və başqa bir şəkildə qurulmuş zəhərli bir artefaktı yükləyin
- s.
Gördüyünüz kimi, bir çox "təhrif" nöqtəsi ola bilər.
Burada vacib olan nədir? Aydındır ki, bütün bu “müdaxilə” məqamlarını qorumaq üçün. Amma sonda ən vacib olan budur artefaktın "istehlakçısı" artefaktın bütövlüyünü qiymətləndirə və onunla davam edib-etməmək barədə qərar verə bilər.
Biz bir artefaktın bütövlüyünü qiymətləndirmək iki yolla.
Biri qiymətləndirməklə provenance artefaktın.
Yaratmaqla Mənşə Təsdiqi, artefakt haqqında faydalı metaməlumatlar (düzgün şəkildə təsdiqlənmiş və təkzib olunmamış) təqdim edirik. Aşağıdakı nümunələrdə istifadə edəcəyik Xygen Duzu (Etibar üçün Proqram Təsdiqləmələri Layer), proqram təminatı təsdiqləmələrini yaratmaq, qeydiyyata almaq və yoxlamaq üçün komponent.
Yuxarıdakı kodda, müharibə faylını quran bir addım və yaradan ikinci bir addım olduğunu görə bilərsiniz Mənşə TəsdiqiBunu etmək üçün, pipeline şəxsi açardan istifadə edir və həmçinin təsdiqləmədə açıq açarı da daxil edir.
Pərdəarxası, Xygeninin duz əmri attestasiyanı a-da saxlayır ledger (yəni attestasiya reyestri, rekord bizim vəziyyətimizdə, ancaq başqa birindən istifadə edə bilərsiniz). Bunu etdikdən sonra istehlakçı pipeline Xygeni-ləri də əhatə edə bilər Doğrulama Mühərriki artefaktın mənşəyini yoxlamaq və artefaktın bütövlüyünü qiymətləndirmək.
Doğrulama prosesi aşağıdakıları qiymətləndirir:
- The artefakt sha256sum etibarlıdır (yəni, həmin “mövzu” haqqında bir təsdiq var) və
- The təsdiqləmə düzgün şəkildə təsdiqlənib (müvafiq gizli açardan istifadə etməklə yaradılıb)
Bu yoxlama prosesi həm artefaktın, həm də təsdiqin etibarlı olduğunu qiymətləndirə bilər.
Amma, yadınızdadırsa, bizim vəziyyətimizdə artefakt "zərərli" bir şəxs tərəfindən yaradılıb pipeline (yəni dəyişdirilmiş orijinal deyil pipeline). Onda biz başqa bir aspekti yoxlamalıyıq: ki artefakt "orijinal" tərəfindən yaradılıb pipeline, başqa heç biri yox.
Bunu etmək üçün sadəcə həmin vəziyyəti yoxlamaq üçün sadə bir sətir daxil edin, məsələn:
Əgər artefakt "təhlükəsiz" tərəfimizdən yaradılmayıbsa, bu əlavə yoxlama uğursuz olacaq. pipeline.
Əgər artefakt orijinalımız tərəfindən yaradılıbsa pipeline (cicd_top10_3_salt/.github/workflows/build.yml), grep əmri uğur qazanacaq, əks halda uğursuz olacaq və pipeline və sonrakı addımları ləğv edir.
"Tikintiçi" pipeline yoxlanılmalı olan yalnız bir müdaxilə nöqtəsidir, lakin əvvəllər qeyd edildiyi kimi, yoxlamalı olduğumuz digər müdaxilə nöqtələri də var.
Misal üçün, Repo yoxlamasından sonra və build əmrindən əvvəl mənbə kodu dəyişdirilibsə, nə etməli? Bu halda, qurulacaq kod saxlanılan kodla eyni deyil SCM.
Bu müdaxilə nöqtəsini yoxlamaq, materialın hər addımda heşlərini yoxlamaq qədər asandır.
Nəticələr
Xülasə, bir Proqram Təminatı proqram təminatı parçası haqqında verilən bir iddiadır, yəni proqram təminatı artefaktı və ya proqram təminatı artefaktları toplusu haqqında təsdiqlənmiş bir ifadədir (metadata).
Proqram təminatı təsdiqləri xam artefakt/kod imzalamasının ümumiləşdirilməsidir. Təsdiqləmə, metaməlumatları artefaktla əlaqələndirən imzalanmış sənəddir (adətən JSON-a əsaslanan müəyyən bir formatda). Onlar hər bir qurma mərhələsində girişləri (materialları) və çıxışları (istehsal edilən artefaktları) əlaqələndirən dəlilləri təmsil edirlər.
Təsdiqlər, hər addım üçün giriş materialları və icra edilən qurma əmrləri daxil olmaqla, son proqram təminatı artefaktlarının qurulması üçün görülən addımların təsdiqlənə bilən qeydini təmin edir.
Nəticə olaraq, Proqram Təminatı Təsdiqləri, qurma prosesimizin bir çox fərqli bütövlük aspektlərini yoxlamaq üçün əla bir mexanizmdir.
Seriyanı bitirdiniz? Narahat olmayın! 'a geri qayıtmaqdan çəkinməyinZəhərli Pipeline İcra (Fərdi Mühafizə)və ya yenidən marağınızı cəlb edən hər hansı digər yazı!
Bizi izləməyə davam edin, proqram təminatı sertifikatlarını dərindən araşdıracağıq və build security əlavə blog yazılarında.
