İşlem hattının ve CI/CD iş akışının güvenliğini sağlama
Bu makalede CI/CD işlem hatlarınızın ve iş akışınızın güvenliğini sağlama açıklanmaktadır.
Otomasyon ve Çevik metodolojisi ekiplerin daha hızlı teslim etmelerine olanak tanır, ancak iş akışı geliştirici ekiplerine de genişlediğinden güvenliğe karmaşıklık ekler.
Aşağıdaki diyagramda temel CI/CD iş akışı gösterilmektedir. Kırmızı yapılandırma simgesi 
, müşteri tarafından yapılandırılması gereken güvenlik izinlerini gösterir. Bu, Azure ve diğer satıcıların izin sağladığı ve müşteri tarafından idare modeline ve iş gereksinimlerine göre yapılandırılması gereken paylaşılan sorumluluk modelini izler.
Yapılandırmaların genellikle birbirine nasıl bağlı olduğunu anlamanıza yardımcı olması için bu tipik iş akışının her aşamasını inceleyelim. İş akışınızın daha fazla aşaması olabilir. Aşağıdaki kavramlar CI/CD'yi anlamanıza ve iş akışınızı güvenlik için tasarlamanıza yardımcı olur.
1. Aşama: Git iş akışı
Kod değişiklikleri, yalnızca yazılıma değil, kod olarak işlem hattına ve kod olarak altyapıya da kaydedilir ve Git'te yönetilir. Git, dağıtılmış bir kaynak kodu yönetim yazılımıdır. Yerel bilgisayarlardan merkezi Git sunucusuna kod gönderildiğinde, iş kuralları kabul edilmeden önce uygulanabilir.
Çekme istekleri ve işbirliği
Hizmet olarak yazılım yapılandırma yönetimi (SCM) yazılımı (SaaS) satıcınızdan bağımsız olarak endüstri standardı iş akışı, kaynak kodu kabul etmeden önce hem otomatik kaliteli bir ağ geçidi denetleyicisi hem de el ile onay adımı görevi yapabilen çekme isteklerini kullanmaktır.
Çekme isteği iş akışı, iyi durumdaki uyuşmalara neden olacak şekilde tasarlanmıştır. Bu nedenle yalnızca belirli Git dallarının güvenliğini sağlamak için uygulanmalıdır. Özellikle dağıtabilen, yapılandırabilen veya başka bir yolla bulut kaynaklarınızı etkileyebilecek otomatik iş akışlarını tetikleyecek dallar. Bu dallar korumalı dallar olarak adlandırılır ve genellikle veya releases/*gibi production adlandırma kurallarına uyar.
Çekme isteklerinin şunları gerektirmesi yaygın olarak görülür:
- Eş gözden geçirmeleri
- Sürekli tümleştirme (CI) derlemelerini geçirme
- El ile onay
Gereksinimler karşılanırsa kod değişiklikleri kabul edilir ve birleştirilebilir.
Korumalı dallara erişimi kısıtlama
Çekme isteği iş akışı kısıtlı erişim denetimleriyle birlikte kullanılır. Ancak sunucu korumalı dallardaki doğrudan değişiklikleri reddedecek şekilde yapılandırılmadığı sürece çekme isteği iş akışı zorunlu kılınamaz.
Geliştirici doğrudan dala production gönderemez, ancak bunun yerine korumalı dalı hedefleyen bir çekme isteği oluşturması gerekir. Her SCM satıcısı, korumalı dallara kısıtlı erişim elde etmek için farklı bir özelliğe sahiptir. Örneğin, GitHub ile bu özellik yalnızca GitHub ekibi veya GitHub Enterprise bulutu kullanan kuruluşlar tarafından kullanılabilir .
Git erişim modelinizi belgeleyin
İşbirliği modeli karmaşık olduğundan ve birçok hareketli parçaya sahip olduğundan, kod değişikliklerinin dağıtımları tetikleyebileceği tüm olası yolları belgeleyen bir tablo oluşturmak yararlı olur. Örneğin:
| Dal adı | Çekme isteği gerekiyor mu? | Dağı -tır? | Geliştirici erişimi | Yönetici erişimi |
|---|---|---|---|---|
feat/* |
Hayır | Hayır | Okuma/yazma | Okuma/yazma |
main |
Yes | Hazırlama | Okundu | Okuma/yazma |
production |
Evet, main yalnızca |
Üretim | Okundu | Okuma/yazma |
Bu Git erişim tablosu örneği, amacını göstermek için fazlasıyla basitleştirilmiştir. Uygulamada genellikle farklı kullanım örnekleri için çalışan daha fazla aktör, daha fazla dağıtım hedefi ve birden çok işlem hattı vardır. Tablo yapınız kuruluşunuzun gereksinimlerine ve iş yüklerinize bağlı olarak farklı olabilir.
Tablo aşağıdaki gibi soruları yanıtlamanıza yardımcı olmalıdır:
- Bir geliştirici kod değişikliklerini X dalı için gönderiyorsa dağıtılacak mı? Öyleyse, hangi ortama?
- Uygulama kodu yaşam döngüsünün hangi noktasında bir güvenlik açığı taraması yapılır?
- Bir güvenlik açığı bulunursa, üretime girmeden önce kaç tane kod göndermesi ve onayı gerekir?
Bu tablo yalnızca hata ayıklama ve statik belgeler için değil, aynı zamanda ekip işbirliği için de yararlıdır. Kod kalitesini ve güvenliğini önceliklendirmek için iş akışında sağlıklı uyuşmaların ortaya çıktığı geliştiriciler için şeffaftır. Daha da önemlisi, geliştiriciye kod değişikliklerinin üretime ulaşması için beklenen yolu gösterir.
DevOps bir yolculuk olduğundan Git erişim modeliniz statik değildir. Takımlar kendi ritimlerini bulduklarında ve olgunlaştıkça değişecek ve gelişecek. Bu nedenle, bu belgeleri koda mümkün olduğunca yakın, örneğin Git depolarında depolamak önemlidir.
Çekme istekleri ve korumalı dallar hakkında daha fazla bilgi edinmek için bkz:
- Dal izinlerini ayarlama
- Çekme isteklerini oluşturma, görüntüleme ve yönetme
- Dal ilkeleriyle kod kalitesini geliştirme
- Çekme istekleri hakkında
- Korumalı dallar hakkında
2. Aşama: Kod olarak işlem hatları
Kod olarak işlem hattı hareketi, işlem hattı tanımlarını ve yapılandırmalarını CI satıcısından geliştiricilere taşıyarak otomasyon benimsemesini ve dağıtımlarını hızlandırarak derleme ve dağıtım mantığını ilgili uygulama mantığına yaklaştırdı. Burada daha fazla esneklik daha fazla sorumluluk da getirir.
Kullanıcı arabirimi tabanlı işlem hattındaki RBAC denetimleri, tek tek kullanıcıların yıkıcı değişiklikler yapmasını engelleyebilir. Öte yandan kod olarak işlem hatları genellikle ayrıcalıklı kimliklerle çalışır ve istenirse iş yüklerinizi yok edebilir.
3. Aşama: Dağıtım kimlik bilgilerinizin güvenliğini sağlama
İşlem hatları ve kod depoları sabit kodlanmış kimlik bilgileri ve gizli diziler içermemelidir. Kimlik bilgileri ve gizli diziler başka bir yerde depolanmalı ve güvenlik için CI satıcı özelliklerini kullanmalıdır. İşlem hatları başsız aracılar olarak çalıştığından hiçbir zaman bir kişinin parolasını kullanmamalıdır. İşlem hatları bunun yerine hizmet sorumluları veya yönetilen kimlikler gibi başsız güvenlik sorumluları kullanılarak çalıştırılmalıdır. Bu güvenlik sorumlusunun kimlik bilgilerine, veritabanı bağlantı dizesi ve üçüncü taraf API anahtarlarına erişim de CI platformunda güvenli bir şekilde yönetilmelidir.
Kimlik bilgilerinin güvenliği , geçitler ve onaylar satıcıya özgü özelliklerdir. Ci platformu seçerken, ihtiyacınız olan tüm özellikleri desteklediğinden emin olun.
Azure Pipelines, kimlik bilgilerinin hizmet bağlantıları olarak depolandığı ve üzerinde onayları ve denetimleri yapılandırabileceğiniz kurumsal ölçekli bir sürekli tümleştirme çözümüdür. Bu yapılandırma el ile onay ve belirli dal veya işlem hattı yetkilendirmelerini içerir.
Azure Key Vault
CI platformunuz destekliyorsa kimlik bilgilerini ayrılmış bir gizli dizi deposunda (örneğin Azure Key Vault) depolamayı göz önünde bulundurun. Kimlik bilgileri derleme aracısı tarafından çalışma zamanında getirilir ve saldırı yüzeyiniz azalır.
4. Aşama: Azure kaynaklarınızın güvenliğini sağlama
Azure kaynaklarınız hem izinlere hem de kapsama uygulanan en düşük ayrıcalık ilkesine göre güvenli hale getirilmelidir.
Daha fazla bilgi için bkz.
Derleme aracıları için özel roller oluşturma
CI/CD otomasyonu yalnızca uygulamalar için değil altyapı için de geçerlidir. Kod olarak altyapı (IaC) şablonları tutarlı dağıtımlar sağlar ve merkezi bulut platformu ekiplerinin ölçeklendirilmesine yardımcı olur.
IaC otomasyonlarının yanlış gidebileceğini anlamak önemlidir. Yanlış yapılandırılabilir ve en kötü senaryolarda altyapıyı kalıcı olarak silebilir. Bulut yolculuğunuzu planlarken, iş açısından kritik olan ve insan müdahalesi gerektiren işlemleri önceden belirleyin.
Örneğin, yönetim kilitleri silinemiyor, veri gibi iş açısından kritik kaynaklara uygulanabilir. Bunun olmasını önlemek için, CI otomasyonunda kullanılan bir hizmet sorumlusundan izinleri kaldırabilirsiniz Microsoft.Authorization/*/Delete. Bu örnekte ve kullanım örneğinde hizmet sorumlusu yönetim kilidini oluşturabilir , ancak silemez.
CI aracılarınız için özel bir rol oluşturmanız önerilir. Unutmayın, derleme aracıları başsız çalışır ve başsız ajanlar beyinsizdir. İzinlerinizi dikkatle seçin.
Daha fazla bilgi edinmek için şu makalelere bakın:
Kaynaklar
- Platform otomasyonu ve DevOps
- İşlem hatları güvenlik kılavuzu
- Şablonlar aracılığıyla güvenlik
- GitHub'da DevSecOps
Sonraki adımlar
DevOps'un güvenliğini sağlamayı öğrendiğinize göre, DevOps'tan Azure'a uçtan uca idare hakkında daha fazla bilgi edinin.