Otomasyonu ve kişisel yönetimi ayırın
Bir raporlama API ardışık düzeni onaylanmış bir yapı seçmeli ve kontrollü bir sürüm eylemi başlatmalıdır. Bu, otomatik olarak kullanıcı oluşturmayı, faturalandırmayı değiştirmeyi veya her uygulama sırrını okumayı gerektirmez. Bir izin envanteri ve korumalı bir test ortamıyla başlayın; kimlik bilgilerini belgelerden, depolarandan ve örnek günlüklerden uzak tutun.
İnsan kurtarma erişimi ayrı kalmalıdır, böylece bir dağıtım kimlik bilgisini iptal etmek tek inceleme yolunu ortadan kaldırmaz. Yetkili bir bakımcı ve bağımsız ana bilgisayar doğrulaması belirleyin. İkinci bir kısıtlanmamış anahtar, daha dar bir rol değil, başka bir kimlik bilgisidir.
İzin verilen işlemi kesin olarak tanımlayın
| Yetenek | Gerekli mi? | Sınır |
|---|---|---|
| Onaylanmış yapıyı oku | Evet | Belirli depo/sürüm |
| Sürüm eylemini başlat | Evet | Sabit uygulama ve ortam |
| Her çalışma zamanı sırrını oku | Kaçın | Kontrollü çalışma zamanı kimliği |
| Kullanıcıları veya SSH politikasını değiştir | Hayır | Yönetimi ayırın |
| İş akışı yapılandırmasını değiştir | Çalışma zamanı kimliği için hayır | Korumalı depo incelemesi |
| Yedekleri sil | Hayır | Kurtarma izinlerini ayırın |
Sürüm eyleminin girdilerini doğrulayın. Rastgele metni ayrıcalıklı bir kabuğa birleştiren kısıtlı bir komut yine de istenmeyen işlere izin verir. Sarmalayıcı davranışını, yazılabilir yolları ve yapı güvenini birlikte inceleyin. Geniş sudo ayrıcalıkları veya Docker soketine erişim, amaçlanan sınırı bozabilir.
İş akışı düzenlemelerini kimlik bilgisi erişimi olarak ele alın
Güvenilen iş akışı adımlarını değiştirebilen biri, kimlik bilgilerini kullanabilir veya açığa çıkarabilir. Depo izinlerini, korumalı dağıtım ortamlarını ve hangi olayların ayrıcalıklı işleri çalıştırdığını inceleyin. Üretim kimlik bilgilerini güvenilmeyen çekme isteği kodundan uzak tutun. Bir iş akışı belirtecine yalnızca işinin ihtiyaç duyduğu izinleri verin.
GitHub, değişmez eylem seçimi için tam uzunlukta commit SHA sabitlemesini önerir. Seçilen eylemi ve sonraki güncellemeleri inceleyin; bir sürüm etiketi hareket edebilir. Güvenilmeyen olay verilerini doğrudan satır içi kabuk koduna eklemekten kaçının. Bilinen sır değerlerini maskelemek, dönüşümler, günlükler veya yapılar yoluyla açığa çıkmaya karşı bir garanti değildir.
Teknik referans: GitHub Actions güvenli kullanım.
Hedef destekliyorsa kısa ömür kullanın
OpenID Connect, desteklenen bir hedefin iş akışı kimliğini kısa ömürlü bir kimlik bilgisiyle değiştirmesine olanak tanıyabilir. Amaçlanan depo, dal veya ortam ve hedef kitle için güven kontrollerini yapılandırın. Bu ne evrensel bir SSH yerine geçer ne de mevcut PrivacyNodes ön ucu tarafından sağlanan bir özelliktir.
Dağıtımınız SSH kullanıyorsa, yüklü paketin yetkili anahtar seçeneklerini inceleyin. Tek başına zorunlu bir komut yönlendirmeyi yasaklamaz; kısıtlamalar amaçlanan erişim yollarını kapsamalı ve yine de güvenli bir sürüm işlemini çağırmalıdır. Ayrı bir ortamda test edin. Kimlik doğrulamayı değiştirirken çalışan yönetim ve kurtarma erişimini koruyun ve eski yöntemi kaldırmadan önce yeni bir bağımsız bağlantıyı doğrulayın.
Teknik referans: GitHub Actions OpenID Connect · OpenSSH authorized_keys biçimi.
İzin verilen ve yasaklanan işleri test edin
Kimliğin amaçlanan yapıyı seçebildiğini, sürümü başlatabildiğini ve yararlı bir sonuç alabildiğini doğrulayın. Ardından sınırlarını test edin: başka bir uygulamanın sırları, ilgisiz dosya değişiklikleri ve rastgele yönetim kullanılamaz olmalıdır. Sarmalayıcının reddetmesi gereken yapı yollarını ve argümanları dahil edin.
Kimliği, kapsamı, varsa son kullanma tarihini, onaylayan bakımcıyı ve denetim kanıtı konumunu kaydedin. Kimlik bilgisi değerleri yerine depolama referanslarını saklayın. Bir test yalnızca geniş yönetim izni verildikten sonra çalışıyorsa, bunu sessizce kalıcı rol haline getirmek yerine sürüm görevini yeniden gözden geçirin.
İptali ve bozuk ardışık düzen sürümünü prova edin
İncelenmiş kapsamla bir yedek hazırlayın, bir test dağıtımını doğrulayın, ardışık düzeni değiştirin ve eski kimliği iptal edin. Yerine geçen kimlik bilgisinin başarısız olduğunu ve başka bir iş akışında kopya kalmadığını doğrulayın. Tek başına yeni bir anahtar eklemek önceki erişimi kaldırmaz.
Yetkili bir bakımcının dağıtımı nasıl durduracağını ve CI kullanılamadığında nasıl kurtaracağını belgeleyin. Bu prosedürü şuna bağlayın: sürüm kaydıyla başlayın ve kurtarma envanteri. Dar bir kimlik bilgisi amaçlanan yetkiyi sınırlar; kötü niyetli bir yapıyı zararsız hale getirmez.
Resmî referanslar
Bu makale için belgeler incelendi. Örnekler, bir PrivacyNodes sunucusunda test edilmiş komutlar değil, planlama alıştırmalarıdır. Yüklü sürümünüz için belgeleri kontrol edin.