Önceki yazımızda bahsettiğimiz konu hakkında CI/CD Pipelines, gördük nasıl hacklenir CI/CD senaryo şu muhtemelen korunuyordu.
Önceki yazımızda vurguladığımız noktayı hatırlayalım: bazılarıyla başladık pipeline bu, savunmasızdı Dolaylı Zehirlenme Pipeline infaz (I-PPE) ve bunu düzeltmek için, bölmeye karar verdik. pipeline ikiye ayır:
- 1st pipeline (Derleme Sürekli Entegrasyonu), D-PPE ve I-PPE için güvenli olup, PR kodunu kontrol eder, derlemeyi yapar ve bir yapıt oluşturur.
- 2nd pipeline (Test CI), D-PPE ve I-PPE için de güvenlidir; bu durumda temel kod kontrol edilir (kabuk betiği değişikliğinden kaçınmak için) ve orijinal betikler yapıt üzerinde çalıştırılır.
- Test CI'yı senkronize etmek için pipeline Build CI'dan SONRA çalıştırılacak pipeline, Kullandığımız iş akışı_çalıştırması tetik.
Bunu 3. Senaryo olarak adlandırdık.
Daha önceki yazımızda da belirttiğimiz gibi başka çözümler de mevcut olsa da, pedagojik nedenlerle bu "çözümü" uygulamaya karar verdik, böylece güvenlik açıklarını derinlemesine inceleyebilelim. CI/CD pipelines.
Sonrasında, bu senaryoyu nasıl alt edebileceğimizi gördük. eseri zehirlemekİşte biz buna diyoruz Eser Zehirlenmesiyani, değiştirme (hackleme) yeteneği pipeline mantığı değiştirerek pipeline eser.
Bu yaklaşımın sorunu nedir? Sorunun, herhangi bir kullanıcının yeni bir "oluşturması" durumunda ortaya çıktığını gördük. pipeline.
Bir kullanıcı yeni bir içerik içeren bir çekme isteği açarsa pipelineGitHub bunu çalıştıracak. pipeline (bazı koşullar altında, gördüğümüz gibi) gönderide).
Kullanıcı daha sonra yeni bir tane oluşturabilir. pipeline Build CI ile aynı isimde!! Evet, şaşırtıcı ama GitHub iki tane oluşturmanıza izin veriyor. pipelineAynı isimde olanlar!!
Kullanıcı bu değişikliklerle bir çekme isteği (PR) açtığında, yeni" pipeline (Zehirli bir eserin yüklenmesi) gerçekleştirilecektir. ve Dağıtım CI pipeline Bundan sonra çalıştırılacak ve sonuç olarak "değiştirilmiş" kabuk betiği, konumunda bulunan "orijinal" kabuk betiğinin üzerine yazılacaktır. pipeline çalışma alanı. Dolayısıyla, bu "çözüm" I-PPE güvenlik açığını ortadan kaldırmıyor (aşağıda görebileceğimiz gibi).
Sorunlar neler? En azından birkaç sorun var:
- İlk olarak, Derleme sürecine müdahale edilmediğinden nasıl emin olabiliriz? Bu senaryoda, kötü niyetli kullanıcı, kendi yöntemlerini kullanarak amaçlanan derleme sürecini değiştirmeyi başarmıştır. pipeline Zehirli bir eser yaratmak.
- İkinci olarak, Bir eserin kökenini nasıl değerlendirebiliriz?
Bu sorular bizi şuraya bırakıyor: Yazılım Onayları ihtisas!!
Yazılım Onayları
An tasdik bir parçası veri temsil bir olayın kanıtıGerçek dünyada bunlara genellikle şu adları veriyoruz: sertifikalar.
Örneğin, bir laboratuvar kanınızı test ettiğinde, testle ilgili veriler kaydedilir ve onaylanır. Kan testi sonuçları ise... doğrulanabilir hem de izlenebilir.
Bilişim teknolojileri alanımıza daha yakın bir örnek vermek gerekirse, bu sürecin örneğin bir derleme sürecine nasıl çevrilebileceğini tahmin edebilirsiniz.
Derleme sunucusu ortamı ve araçları, materyaller (kaynak kod) ve ürünler/yapıtlar (ikili kod) hakkındaki bilgiler bu tür bir onayın parçası olacaktır.
Açıkçası, güvenilirliği sağlamak için tasdik belgesinin yetkili bir tasdikçi (kimliği doğrulanmış ve reddedilemez) tarafından oluşturulması gerekir.
Muhtemelen bazılarınız şöyle düşünüyor olabilir: "Peki bu nedir?" İmzalar ve tasdikler arasındaki fark?
Kod İmzaları ve Onayları
Genel olarak, bir imza Bir anahtar çifti ve bir yapıt kullanılarak oluşturulur. Anahtar çifti, bir açık anahtar ve bir özel anahtardan oluşur.
Kullanıcı, özel anahtarını kullanarak bir yapıyı imzalar ve diğerleri daha sonra açık anahtarı kullanarak imzayı doğrulayabilir. Özel anahtar gizli tutulmalıdır, ancak açık anahtar geniş çapta dağıtılır.
İmzalar kullanılabilir. Özel anahtarın sahibinin, söz konusu belgeyi imzalamak için özel anahtarı kullandığını kanıtlamak..
İmzalar ispatlama
- Kullanıcının niyet Eseri imzalamak için (aldatılmış olabilirler) veya
- Kullanıcının herhangi bir şey yapma niyeti esere ilişkin belirli bir iddia
İle tasdikleriKullanıcılar, bir yapıtı doğrudan imzalamak yerine, bir tür belge oluştururlar. belge o niyetlerini yakalıyor Eseri imzalamanın ve herhangi bir şeyin ardındaki süreç özel iddialar Bu imzanın bir parçası olarak yapılıyor.
In-toto Onay Çerçevesi
En yaygın çerçeve şudur: in-toto Onay Çerçevesi
- Bir tanımlar standard tasdiknameler için format Bu, tanımlanan nesneleri, nesne hakkındaki doğrulanmış meta verilerle ilişkilendirir.
- bir dizi sağlar önceden tanımlanmış yüklemler Yazılım tedarik zincirleri boyunca ve zincirler arası doğrulanmış meta verilerin iletilmesi için
Şimdi tasdik formatı hakkında biraz daha detaylı bilgi verelim.
An Tasdik bir dijital olarak imzalanmış belge içeren İfadeler.
MKS Açıklama Bu, tasdik belgesinin orta katmanıdır ve onu belirli bir şeye bağlar. Konu ve türlerini net bir şekilde tanımlayarak yüklem:
- Konu: esere kriptografik olarak güvenli referans (genellikle bir karma fonksiyonu aracılığıyla) ve
- yüklemler: belirli bir küme iddia Bu eserle ilgili olarak yapılan açıklamaya "Bildirim" adı verilir. Bu iddialar, aklınıza gelebilecek her şeyi ifade etmek (ve daha sonra kanıtlamak) için kullanılabilir! Manuel onayı, eserin menşeini, otomatik test sonuçlarını, denetim izini veya daha fazlasını temsil edebilirler!
Bu ifade kriptografik olarak imzalandığında, o zaman şu şekilde anılır: Tasdik
Bu şekilde, örneğin, Alice bir eser hakkında bir Beyan oluşturur ve bunu özel anahtarını kullanarak imzalar, böylece bir Onaylama belgesi oluşturur.
- Bob daha sonra İmzayı doğrulayın Bu tasdiknamede ona izin vererek iddialara güvenmek içeride.
Bob daha sonra bu hak iddialarını kullanabilir. karar vermek Bu eserin kullanılmasına izin verilip verilmeyeceği.
Onaylama işlemleri, eser zehirlenmesi sorununu çözmeye yardımcı olabilir mi?
Onaylama işlemlerine dair bu girişten sonra, problemimize geri dönelim. Onaylama işlemleri, sorunumuzu çözmemize, yani yapay zeka kaynaklı kirlenmeyi önlememize nasıl yardımcı olabilir?
Kötü niyetli kullanıcı, "resmi" mekanizmayı atlayarak, yani kendi yetkisini kullanarak bir yapay nesne oluşturmayı başardı. pipeline Eseri oluşturmak için.
İndirilen dosyaların resmi kaynaklar kullanılarak oluşturulduğunu kanıtlayabilsek harika olurdu. pipelineBu, "kurcalama noktaları" olarak adlandırabileceğimiz şeylerden sadece bir örnektir, ancak daha birçok örnek olabilir.
Yukarıdaki resimde de görebileceğiniz gibi, kurcalama noktaları çok sayıda. Bu şekilde tüketici pipeline (Örneğimizde CI testi) şunu değerlendirmelidir: yapım sürecinin bütünlüğü yanısıra eserin bütünlüğü.
Örneğimizde, zehirli eser yeni bir (zehirli) madde eklenerek oluşturulmuştur. pipeline Bu, derleme sürecine müdahale eder. Ancak kötü niyetli kullanıcı şunları yapabilirdi:
- Kod, dosyadan çıkarıldıktan sonra değiştirilecektir. SCM kötü amaçlı bir ikili dosya oluşturmak
- Derleme sonucu oluşan sağ ikili dosyayı, başka herhangi bir kötü amaçlı ikili dosyayla değiştirin.
- Yapıt Kayıt Defterini tehlikeye atın ve başka herhangi bir şekilde oluşturulmuş zehirli bir yapıtı yükleyin.
- vb.
Gördüğünüz gibi, birden fazla "kurcalama" noktası olabilir.
Burada önemli olan nedir? Elbette tüm bu "kurcalama" noktalarını korumak. Ama sonuçta en önemli olan şudur: Eserin "tüketicisi", eserin bütünlüğünü değerlendirebilir ve onu kullanmaya devam edip etmeme konusunda karar verebilir.
Yapabiliriz bir eserin bütünlüğünü değerlendirmek iki şekilde.
Bunlardan biri değerlendirme yoluyla yapılır. kaynak eserin.
Bir oluşturarak Menşei BelgesiBu sayede, eser hakkında (doğru şekilde doğrulanmış ve reddedilemeyen) faydalı meta veriler sağlıyoruz. Aşağıdaki örneklerde kullanacağız. Xygeni TUZ (Güven için Yazılım Onay Katmanı), yazılım onaylarını oluşturma, kaydetme ve doğrulama bileşenidir.
Yukarıdaki kodda, war dosyasını oluşturan bir adım ve bunu üreten ikinci bir adım olduğunu görebilirsiniz. Menşei BelgesiBunu yapmak için, pipeline Onay işleminde özel anahtarın yanı sıra genel anahtar da kullanılır.
Xygeni'nin perde arkasında... tuz Bu komut, onay bilgisini bir yere kaydeder. defteri kebir (diğer adıyla tasdik sicili, Kayıt Bizim durumumuzda bu şekildeydi ama başka herhangi birini de kullanabilirsiniz). Bu yapıldı, tüketici pipeline Xygeni'ninkini içerebilir. Doğrulama Motoru Eserin menşeini doğrulamak ve eserin bütünlüğünü değerlendirmek.
Doğrulama süreci şu hususları değerlendirir:
- MKS yapıtın sha256 toplamı geçerlidir. (yani o "konu" hakkında bir tasdikname var) ve
- MKS tasdik usulüne uygun olarak doğrulanmıştır. (Uygun özel anahtar kullanılarak oluşturulmuştur)
Bu doğrulama süreci, hem belgenin hem de onay belgesinin geçerli olup olmadığını değerlendirebilir.
Ama hatırlayacağınız gibi, bizim durumumuzda, eser "kötü niyetli" bir kişi tarafından üretilmişti. pipeline (yani orijinali değil, değiştirilmiş hali) pipelineO halde bir başka hususu daha kontrol etmeliyiz: Bu eser "orijinal" tarafından üretilmiştir. pipelineBaşka bir tane değil.
Bunu yapmak için, söz konusu koşulu kontrol eden basit bir satır eklemeniz yeterlidir, örneğin:
Bu ek kontrol, yapıt "güvenli" sistemimiz tarafından oluşturulmamışsa başarısız olacaktır. pipeline.
Eğer eser bizim orijinalimiz tarafından üretildiyse pipeline (cicd_top10_3_salt/.github/workflows/build.yml) dosyasında grep komutu başarılı olur, aksi takdirde başarısız olur ve çalışmayı bozar. pipeline ve daha sonraki adımların durdurulması.
“İnşaatçı” pipeline Bu, kontrol edilmesi gereken kurcalama noktalarından sadece biri; ancak daha önce de belirtildiği gibi, kontrol etmemiz gereken başka kurcalama noktaları da var.
Örneğin, Depo oluşturulduktan sonra ve derleme komutu verilmeden önce kaynak kodda değişiklik yapılmışsa ne olur? Bu durumda, derlenecek kod, depoda saklanan kodla aynı değildir. SCM.
Bu müdahale noktasını kontrol etmek, malzemenin her aşamasındaki hash değerlerini kontrol etmek kadar kolaydır.
Sonuç
Özetle, bir Yazılım Onaylama Bir yazılım parçası hakkında yapılan bir iddiadır, yani bir yazılım bileşeni veya yazılım bileşenleri koleksiyonu hakkında doğrulanmış bir ifadedir (meta veri).
Yazılım onayları, ham yapıt/kod imzalama işleminin genelleştirilmiş bir halidir. Onay, meta verileri bir yapıtla ilişkilendiren imzalı bir belgedir (genellikle JSON tabanlı belirli bir formatta). Her derleme adımında girdileri (malzemeleri) ve çıktıları (üretilen yapıtları) birbirine bağlayan kanıtları temsil ederler.
Onay belgeleri, her adım için kullanılan girdi malzemeleri ve çalıştırılan derleme komutları da dahil olmak üzere, nihai yazılım ürünlerinin oluşturulması için yapılan adımların doğrulanabilir bir kaydını sağlar.
Sonuç olarak, yazılım doğrulama işlemleri, derleme sürecimizin birçok farklı bütünlük yönünü kontrol etmek için harika bir mekanizmadır.
Seriyi bitirdiniz mi? Merak etmeyin! Dilediğinizce ' bölümüne geri dönebilirsiniz.Zehirli Pipeline Yürütme (PPE)' veya ilginizi tekrar çeken herhangi bir başka gönderi!
Takipte kalın, yazılım onaylamaları konusuna derinlemesine dalacağız ve build security İlerleyen blog yazılarında.
