Dalam postingan kami sebelumnya tentang CI/CD Pipelines, kami melihat cara meretas CI/CD skenario yang agaknya terlindungi.
Mari kita ingat kembali poin yang telah kita bahas di postingan sebelumnya: kami mulai dengan beberapa pipeline yang rentan terhadap Keracunan Tidak Langsung Pipeline Execution (I-PPE) dan, untuk memperbaikinya, kami memutuskan untuk memisahkan pipeline menjadi dua:
- Tanggal 1 pipeline (Build CI), aman untuk D-PPE dan I-PPE, akan melakukan checkout kode PR, membuat build, dan menghasilkan artefak.
- 2nd pipeline (Pengujian CI), juga aman untuk D-PPE dan I-PPE akan melakukan checkout kode dasar (untuk menghindari modifikasi skrip shell) dan mengeksekusi skrip asli terhadap artefak.
- Untuk menyinkronkan CI Pengujian pipeline untuk dijalankan SETELAH Build CI pipeline, kami menggunakan alur kerja_jalankan pelatuk.
Kami menamakan ini sebagai Skenario #3.
Meskipun, seperti yang kami sebutkan dalam postingan tersebut, ada solusi lain, kami memutuskan untuk menerapkan "solusi" ini karena alasan pedagogis, sehingga kami dapat mempelajari lebih dalam kerentanan yang ada. CI/CD pipelines.
Setelah itu, kita melihat bagaimana cara meretas skenario ini dengan meracuni artefakIni yang kami sebut Keracunan Artefakyaitu kemampuan untuk memodifikasi (meretas) pipeline logika dengan memodifikasi pipeline artefak.
Apa masalah dengan pendekatan ini? Kita melihat bahwa masalah muncul ketika pengguna mana pun "membuat" yang baru. pipeline.
Jika pengguna membuka PR yang berisi hal baru pipelineGitHub akan mengeksekusi itu. pipeline (dengan beberapa kondisi tertentu, seperti yang telah kita lihat) di pos).
Pengguna kemudian dapat membuat yang baru. pipeline dengan nama yang sama dengan Build CI!! Ya, memang mengejutkan, tetapi GitHub memungkinkan Anda untuk membuat dua pipelinedengan nama yang sama!!
Saat pengguna membuka permintaan perubahan (PR) dengan perubahan ini, yang baru" pipeline akan dieksekusi (mengunggah artefak yang diracuni) dan Deploy CI pipeline akan dieksekusi setelah itu, sehingga skrip shell yang "dimodifikasi" akan menimpa skrip shell "asli" yang terletak di pipeline ruang kerja. Jadi, "solusi" ini tidak menghindari kerentanan I-PPE (seperti yang dapat kita lihat di bawah).
Apa saja masalahnya? Setidaknya, ada beberapa masalah:
- Pertama, Bagaimana cara memastikan bahwa proses pembuatan tidak dimanipulasi? Dalam skenario ini, pengguna jahat telah mampu memodifikasi proses pembuatan yang dimaksudkan dengan menggunakan pipeline untuk membuat artefak beracun.
- Kedua, Bagaimana kita dapat menilai asal usul suatu artefak?
Pertanyaan-pertanyaan ini menjerumuskan kita ke dalam pelukan Pengesahan Perangkat Lunak domain!!
Pengesahan Perangkat Lunak
An pengesahan adalah sepotong data mewakili bukti suatu peristiwaDalam dunia nyata, kita umumnya menyebut ini sertifikasi.
Sebagai contoh, ketika laboratorium menguji darah Anda, data tentang tes tersebut dicatat dan disertifikasi. Hasil tes darah tersebut adalah... diverifikasi ke dapat dilacak.
Jika kita lebih dekat dengan ranah TI, Anda bisa menebak seperti apa terjemahan dari proses ini, misalnya, proses kompilasi.
Informasi tentang lingkungan dan alat server kompilasi, materi (kode sumber), dan produk/artefak (kode biner) akan menjadi bagian dari pengesahan tersebut.
Jelas, pengesahan harus dibuat oleh pengesah yang berwenang (terautentikasi dan tidak dapat disangkal) untuk memberikan kredibilitas.
Mungkin sebagian dari Anda berpikir... lalu apa itu? perbedaan antara tanda tangan dan pengesahan?
Tanda Tangan Kode dan Pengesahan
Secara garis besar, sebuah tanda tangan Dibuat menggunakan pasangan kunci dan sebuah artefak. Pasangan kunci tersebut terdiri dari kunci publik dan kunci privat.
Pengguna menandatangani artefak menggunakan kunci privat, dan orang lain kemudian dapat memverifikasi tanda tangan tersebut menggunakan kunci publik. Kunci privat harus dirahasiakan, tetapi kunci publik didistribusikan secara luas.
Tanda tangan dapat digunakan untuk membuktikan bahwa pemegang kunci privat menggunakan kunci privat tersebut untuk menandatangani artefak..
Tanda tangan jangan buktikan
- Pengguna niat untuk menandatangani artefak tersebut (mereka mungkin telah ditipu), atau
- Niat pengguna untuk membuat apa pun klaim spesifik tentang artefak
Dengan PengesahanAlih-alih menandatangani artefak secara langsung, pengguna membuat semacam... dokumen bahwa menangkap maksud mereka di balik penandatanganan artefak dan apa pun klaim spesifik dibuat sebagai bagian dari tanda tangan ini.
Kerangka Kerja Pengesahan In-toto
Kerangka kerja yang paling umum adalah Kerangka Kerja Pengesahan in-toto
- mendefinisikan standard format untuk pengesahan yang mengikat subjek, artefak yang sedang dijelaskan, dengan metadata terautentikasi tentang artefak tersebut.
- menyediakan seperangkat predikat yang telah ditentukan sebelumnya untuk mengkomunikasikan metadata terautentikasi di seluruh rantai pasokan perangkat lunak
Mari kita bahas lebih detail tentang format pengesahan.
An Pengesahan adalah dokumen yang ditandatangani secara digital itu mengandung Pernyataan.
The Pernyataan merupakan lapisan tengah dari surat keterangan, yang mengikatnya pada hal tertentu. Subjek dan secara jelas mengidentifikasi jenis-jenisnya Predikat:
- Subjek: The referensi yang aman secara kriptografis terhadap artefak (biasanya melalui hash), dan
- Predikat: sekumpulan hal spesifik klaim Informasi mengenai artefak tersebut disebut sebagai Pernyataan. Klaim ini dapat digunakan untuk menyatakan (dan kemudian membuktikan) apa pun yang Anda pikirkan! Klaim ini dapat mewakili persetujuan manual, asal usul artefak, hasil pengujian otomatis, jejak audit, atau banyak lagi!
Ketika Pernyataan ini ditandatangani secara kriptografis, maka pernyataan tersebut disebut sebagai sebuah Pengesahan
Dengan cara ini, sebagai contoh, Alice membuat Pernyataan tentang sebuah artefak dan menandatanganinya menggunakan kunci pribadinya, sehingga tercipta sebuah Pengesahan.
- Bob kemudian bisa verifikasi tanda tangan dalam Surat Keterangan itu, mengizinkannya untuk mempercayai klaim tersebut dalam.
Bob kemudian dapat menggunakan klaim tersebut. untuk memutuskan Apakah artefak ini boleh digunakan atau tidak.
Bisakah pengesahan membantu menyelesaikan kasus keracunan artefak?
Setelah pengantar mengenai Attestasi ini, mari kita kembali ke permasalahan kita. Bagaimana pengesahan dapat membantu kita memecahkan masalah kita, yaitu untuk menghindari keracunan artefak?
Pengguna jahat tersebut mampu membuat artefak dengan melewati mekanisme "resmi", yaitu dengan menggunakan miliknya. pipeline untuk menghasilkan artefak.
Akan sangat luar biasa jika kita bisa membuktikan bahwa artefak yang diunduh telah dibuat dengan menggunakan perangkat lunak resmi. pipelineIni hanya satu contoh dari apa yang bisa kita sebut sebagai "titik manipulasi", tetapi mungkin masih banyak contoh lainnya.
Seperti yang Anda lihat pada gambar di atas, titik-titik pemalsuan sangat banyak. Dengan cara ini, konsumen pipeline (Tes CI dalam contoh kita) harus menilai integritas proses pembangunan serta integritas artefak itu sendiri.
Dalam contoh kita, artefak beracun telah dibuat dengan memasukkan yang baru (beracun). pipeline yang mengganggu proses pembuatan. Namun, pengguna jahat tersebut bisa saja melakukan hal berikut:
- memodifikasi kode setelah diambil dari SCM untuk menghasilkan biner berbahaya
- Gantikan file biner yang benar yang dihasilkan oleh kompilasi dengan file biner berbahaya lainnya.
- membahayakan Registri Artefak dan mengunggah artefak yang telah dirusak yang dibuat dengan cara lain.
- dan sebagainya
Seperti yang Anda lihat, mungkin ada beberapa titik "pengubahan data".
Apa yang penting di sini? Jelas, untuk melindungi semua titik "perusakan" tersebut. Tetapi, pada akhirnya, yang terpenting adalah... bahwa “konsumen” artefak dapat menilai integritas artefak tersebut, dan memutuskan apakah akan melanjutkan atau tidak.
Kita bisa menilai integritas suatu artefak dalam dua cara.
Salah satunya dengan menilai asal dari artefak tersebut.
Dengan menghasilkan Pengesahan Asal Usul, kami menyediakan metadata yang berguna (yang telah diautentikasi dengan benar dan tidak dapat disangkal) tentang artefak tersebut. Dalam contoh-contoh berikut, kita akan menggunakan Garam Xygeni (Lapisan Pengesahan Perangkat Lunak untuk Kepercayaan), komponen untuk menghasilkan, mendaftarkan, dan memverifikasi pengesahan perangkat lunak.
Pada kode di atas, Anda dapat melihat ada langkah yang membangun file war dan langkah kedua yang menghasilkan Pengesahan Asal UsulUntuk melakukannya, pipeline menggunakan kunci privat dan juga menyertakan kunci publik dalam pengesahan.
Di balik layar, Xygeni's garam perintah menyimpan pengesahan di dalam buku besar (alias registri pengesahan, rekor (dalam kasus kami, tetapi Anda dapat menggunakan yang lain). Setelah itu, konsumen pipeline dapat mencakup Xygeni's Mesin Verifikasi untuk memverifikasi asal usul artefak dan menilai integritas artefak tersebut.
Proses verifikasi menilai:
- The artefak sha256sum valid (yaitu terdapat pernyataan mengenai “subjek” tersebut), dan
- The pengesahan telah diautentikasi dengan benar. (telah dihasilkan dengan menggunakan kunci privat yang sesuai)
Proses verifikasi ini kemudian dapat menilai apakah artefak dan pengesahan tersebut valid.
Namun, seperti yang Anda ingat, dalam kasus kami, artefak tersebut dihasilkan oleh tindakan "berbahaya". pipeline (yaitu bukan versi asli tetapi versi yang dimodifikasi) pipeline). Kemudian kita harus melanjutkan dan memeriksa aspek lain: yaitu Artefak tersebut telah dihasilkan oleh "aslinya". pipeline, bukan yang lain.
Untuk melakukan itu, cukup sertakan baris sederhana untuk memeriksa kondisi tersebut, misalnya:
Pemeriksaan tambahan ini akan gagal jika artefak tersebut belum dihasilkan oleh "tempat aman" kami. pipeline.
Jika artefak tersebut dihasilkan oleh versi asli kami pipeline (cicd_top10_3_salt/.github/workflows/build.yml), perintah grep akan berhasil, jika tidak, akan gagal, sehingga menyebabkan kerusakan. pipeline dan menghentikan langkah-langkah selanjutnya.
“Si pembangun” pipeline Ini hanyalah salah satu titik pemalsuan yang perlu diperiksa, tetapi, seperti yang disebutkan sebelumnya, ada beberapa titik pemalsuan lain yang harus kita periksa.
Sebagai contoh, Bagaimana jika kode sumber telah diubah setelah checkout repositori dan sebelum perintah build dijalankan? Dalam hal ini, kode yang akan dibangun tidak sama dengan yang tersimpan di SCM.
Untuk memeriksa titik kecurangan ini sangat mudah, cukup dengan memeriksa hash material di setiap langkahnya.
Kesimpulan
Singkatnya, sebuah Sertifikasi Perangkat Lunak adalah pernyataan yang dibuat tentang suatu bagian perangkat lunak, yaitu pernyataan terautentikasi (metadata) tentang artefak perangkat lunak atau kumpulan artefak perangkat lunak.
Pengesahan perangkat lunak adalah generalisasi dari penandatanganan artefak/kode mentah. Pengesahan adalah dokumen yang ditandatangani (dalam format tertentu, biasanya berbasis JSON) yang mengaitkan metadata dengan artefak. Dokumen ini mewakili bukti yang menghubungkan input (materi) dan output (artefak yang dihasilkan) pada setiap langkah pembuatan.
Attestasi menyediakan catatan yang dapat diverifikasi tentang langkah-langkah yang dilakukan untuk membangun artefak perangkat lunak akhir, termasuk bahan masukan untuk setiap langkah dan perintah pembangunan yang dijalankan.
Kesimpulannya, Attestasi Perangkat Lunak adalah mekanisme yang bagus untuk memeriksa berbagai aspek integritas dari proses pembuatan perangkat lunak kita.
Sudah selesai menonton serialnya? Jangan khawatir! Silakan kembali ke 'Keracunan Pipeline Eksekusi (APD)atau postingan lain apa pun yang kembali menarik minat Anda!
Tetaplah bersama kami, kami akan membahas secara mendalam tentang pengesahan perangkat lunak dan build security dalam postingan blog selanjutnya.
