Gelişmiş güvenlik yönetimi

  • Makale

Bu güncelleştirmeyle, artık tüm projeniz veya kuruluşunuz için Gelişmiş Güvenlik'i etkinleştirme veya devre dışı bırakma seçeneğiniz vardır. Ayrıca, yeni oluşturulan tüm depolar veya projeler için Gelişmiş Güvenlik'i otomatik olarak etkinleştirebilirsiniz.

Azure Pipelines'da, çatallanmış GitHub depolarından oluşturulan çekme isteklerinin güvenliğini geliştirmek için merkezi bir denetim ekledik.

Bu özellikler hakkında daha fazla bilgi edinmek için sürüm notlarına göz atın.

Genel

Azure Pipelines

Azure Repos

Azure Artifacts

Genel

Gelişmiş Güvenlik için proje ve kuruluş düzeyinde etkinleştirme

Artık tüm projeniz veya kuruluşunuz için Gelişmiş Güvenlik'i etkinleştirebilir veya devre dışı bırakabilirsiniz. Etkinleştirmeden önce işleme sayısını görüntülemeye yeni ek olarak, proje veya kuruluş düzeyinde "Tümünü etkinleştir" seçeneğinin seçilmesi, kaç yeni etkin committer için faturalanabileceğinize ilişkin bir tahmin sağlar. Ayrıca, ilgili projeniz veya kuruluşunuz altında yeni oluşturulan depolar veya projeler için Gelişmiş Güvenlik'i otomatik olarak etkinleştirmeyi de tercih edebilirsiniz. Bu ayar aracılığıyla etkinleştirilen tüm depolarda gizli depo taraması ve anında iletme koruması etkin olur.

Proje düzeyinde etkinleştirme:

Proje düzeyinde etkinleştirmenin ekran görüntüsü.

Kuruluş düzeyinde etkinleştirme:

Kuruluş düzeyinde etkinleştirmenin ekran görüntüsü.

Gelişmiş Güvenlik etkinleştirmesi sırasında tahmini işleme sayısı

Gelişmiş Güvenlik ekleme deneyiminizin bir parçası olarak, artık belirli bir depo, proje veya kuruluş için Gelişmiş Güvenlik'i etkinleştirmenin sonucu olarak kaç etkin işlemenin eklendiğini tahmin edebilirsiniz. Bu sayı yaklaşık bir değerdir ve sağlanan tahmin ile etkinleştirme sonrasında faturalama için bildirilenler arasında küçük tutarsızlıklar görebilirsiniz. Bu tahmin, yakında bu süreci açıklayan ek belgelerle API aracılığıyla da elde edilebilir.

Gelişmiş Güvenlik etkinleştirmesinin ekran görüntüsü.

Azure Pipelines

Onaylar ve denetimler zaman aşımına uğradıktan sonra aşamayı yeniden deneme

Onaylar ve denetimler zaman aşımına uğradıklarında, ait oldukları aşama atlanır. Atlanan aşamaya bağımlılığı olan aşamalar da atlanır.

Artık onaylar ve denetimler zaman aşımına uğradıktan sonra bir aşamayı yeniden deneyebilirsiniz. Daha önce bu yalnızca onay zaman aşımına uğradıysa mümkündü.

Aşama yeniden denemesinin ekran görüntüsü.

Tüm Ortamlar için yönetici rolü

YAML işlem hatlarındaki ortamlar, uygulamanızı dağıttığınız bir işlem kaynağını temsil eder; örneğin AKS kümesi veya vm kümesi. Dağıtımlarınız için güvenlik denetimleri ve izlenebilirlik sağlar.

Ortamları yönetmek oldukça zor olabilir. Bunun nedeni, bir ortam oluşturulduğunda, ortamı oluşturan kişinin otomatik olarak tek yönetici olmasıdır. Örneğin, tüm ortamların onaylarını ve denetimlerini merkezi bir şekilde yönetmek istiyorsanız, her ortam yöneticisinden belirli bir kullanıcıyı veya grubu yönetici olarak eklemesini ve ardından denetimleri yapılandırmak için REST API'yi kullanmasını istemeniz gerekir. Bu yaklaşım yorucu, hataya açık ve yeni ortamlar eklendiğinde ölçeklendirilmiyor.

Bu sprint ile environments-hub düzeyinde bir Yönetici rolü ekledik. Bu, ortamları hizmet bağlantılarıyla veya aracı havuzlarıyla eşit olacak şekilde getirir. Yönetici rolünü bir kullanıcı veya gruba atamak için zaten ortam hub'ı yöneticisi veya kuruluş sahibi olmanız gerekir.

Yönetici rolünün ekran görüntüsü.

Bu Yönetici rolüne sahip bir kullanıcı izinleri yönetebilir, yönetebilir, görüntüleyebilir ve herhangi bir ortamı kullanabilir. Bu, ortamları tüm işlem hatlarına açmayı içerir.

Bir kullanıcıya ortam hub'ı düzeyinde Yönetici rolü verdiğinizde, bunlar tüm mevcut ortamlar ve gelecekteki ortamlar için yönetici olur.

Çatallanmış GitHub depolarından ÇEKME isteği oluşturmak için merkezi denetim

GitHub'dan genel depolar oluşturuyorsanız, çatal derlemeleri hakkındaki duruşunuzu göz önünde bulundurmanız gerekir. Çatallar özellikle kuruluşunuzun dışından geldiğinden tehlikelidir.

GitHub depoları ve Depo koruması oluşturma önerilerimizi gözden geçirerek GitHub genel depoları oluşturan işlem hatlarının güvenliğini geliştirebilirsiniz. Ne yazık ki, çok sayıda işlem hattını yönetmek ve bunların en iyi yöntemlere bağlı kalmasını sağlamak için çok fazla çaba gerektirebilir.

İşlem hatlarınızın güvenliğini artırmak için, işlem hatlarının çatallanmış GitHub depolarından nasıl PR oluşturduğunu tanımlamaya yönelik kuruluş düzeyinde bir denetim ekledik. Yeni ayar, Çatallanmış GitHub depolarından çekme isteklerini derlemeyi sınırla olarak adlandırılır ve kuruluş ve proje düzeyinde çalışır.

Kuruluş düzeyi ayarı projelerin sahip olabileceği ayarları kısıtlar ve proje düzeyi ayarı işlem hatlarının sahip olabileceği ayarları kısıtlar.

Şimdi iki durumlu düğmenin kuruluş düzeyinde nasıl çalıştığına bakalım. Yeni denetim varsayılan olarak kapalıdır, dolayısıyla hiçbir ayar evrensel olarak uygulanmaz.

Kuruluş düzeyini değiştirme ekran görüntüsü.

İki durumlu düğmeyi açtığınızda, çatallanmış GitHub depolarından çekme isteği derlemeyi devre dışı bırakabilirsiniz. Bu, böyle bir çekme isteği oluşturulduğunda hiçbir işlem hattının çalıştırılacağı anlamına gelir.

İki durumlu düğmeyi gösterme ekran görüntüsü.

Çatallanmış depolardan çekme isteklerini güvenli bir şekilde derleyin seçeneğini belirlediğinizde, kuruluş genelindeki tüm işlem hatları, çatallanmış depolardaki PR derlemeleri için gizli dizileri kullanılabilir hale getiremez, bu derlemelerin normal derlemelerle aynı izinlere sahip olmasını sağlayamaz ve çekme isteği açıklaması tarafından tetiklenmesi gerekir. Projeler yine de işlem hatlarının bu tür PR'ler oluşturmasına izin vermemeye karar verebilir.

Güvenli bir şekilde derleme PR'sinin ekran görüntüsü.

Özelleştir seçeneğini belirlediğinizde işlem hattı ayarlarını kısıtlamayı tanımlayabilirsiniz. Örneğin, çekme isteği ekip üyesi olmayanlara ve katkıda bulunan olmayanlara ait olduğunda çatallanmış github deposundan çekme isteği oluşturmak için tüm işlem hatlarının açıklama gerektirdiğinden emin olabilirsiniz. Ancak, gizli dizileri bu tür derlemelerde kullanılabilir hale getirmelerine izin vermeyi seçebilirsiniz. Projeler, işlem hatlarının bu tür PR'ler oluşturmasına veya güvenli bir şekilde oluşturulmasına izin vermemeye veya kuruluş düzeyinde belirtilen daha kısıtlayıcı ayarlara sahip olmasına karar verebilir.

Özelleştir'in ekran görüntüsü.

Azure Repos

Kullanıcıların kendi değişikliklerini onaylamasını engelleyen yeni "Dal ilkesi"

Kullanıcının hangi değişiklikleri onaylayıp daha katı mevzuat/uyumluluk gereksinimlerini karşılıyor olduğu konusunda denetimi geliştirmek için, açıkça izin verilmediği sürece kullanıcının kendi değişikliklerini onaylamasını önlemeye yönelik bir seçenek sunuyoruz.

Dal ilkelerini yönetebilen kullanıcı artık "Yeni değişiklikler gönderildiğinde" altında yeni eklenen "Her yinelemede en az bir onay iste" seçeneğini değiştirebilir. Bu seçenek belirlendiğinde, son kaynak dal değişikliği için en az bir onay oyu gerekir. Kullanıcının onayı, o kullanıcı tarafından gönderilen önceki onaylanmamış yinelemelere karşı sayılmaz. Sonuç olarak, başka bir kullanıcı tarafından son yinelemede ek onay yapılması gerekir.

Aşağıdaki görüntüde A kullanıcısı tarafından oluşturulan çekme isteği ve B, C, A tekrar ve C kullanıcıları tarafından bu çekme isteğine yapılan ek 4 işleme (yineleme) gösterilmektedir. İkinci yineleme (işleme B kullanıcısı tarafından yapıldı) tamamlandıktan sonra, C kullanıcısı bunu onayladı. O sırada, A kullanıcısının ilk işlemesinin onayını (çekme isteği oluşturulduğunda) ve yeni eklenen ilkenin başarılı olacağını ima etti. Beşinci yinelemeden (C kullanıcısının son işlemesi) sonra onay A kullanıcısı tarafından yapıldı. Bu, C kullanıcısı tarafından yapılan önceki işleme için onay anlamına gelir, ancak dördüncü yinelemede A kullanıcısı tarafından yapılan ikinci işleme için onay anlamına gelmez. Yeni tanıtılan ilkenin başarılı olması için onaylanmamış yineleme dört, B, C kullanıcısının veya çekme isteğinde herhangi bir değişiklik yapmayan başka bir kullanıcının onayıyla onaylanmalıdır.

İzin yönetimi görüntüsü.

Azure Artifacts

Cargo Crates için Azure Artifacts desteğine giriş (genel önizleme)

Azure Artifacts'in artık Kargo kasaları için yerel destek sunduğunu duyurmaktan heyecan duyuyoruz. Bu destek, mevcut protokollerimizle ilgili özellik eşliğini ve yukarı akış kaynağı olarak kullanılabilen crates.io içerir. Rust geliştiricileri ve ekipleri artık Azure'ın sağlam altyapısını kullanırken ve tanıdık Azure DevOps ortamında kalırken Kargo kasalarını sorunsuz bir şekilde kullanabilir, yayımlayabilir, yönetebilir ve paylaşabilir.

Önizleme için kaydolma gerekmez; Azure DevOps projenize gidip Yapıtlar'ı seçerek ve Rust projenizi Azure Artifacts akışınıza bağlama yönergelerini izleyerek başlayabilirsiniz.

Sonraki adımlar

Not

Bu özellikler önümüzdeki iki-üç hafta içinde kullanıma sunulacaktır.

Azure DevOps'a gidin ve bir göz atın.

Azure DevOps'a gidin

Geri bildirim sağlama

Bu özellikler hakkında düşüncelerinizi duymak isteriz. Bir sorunu bildirmek veya öneri sağlamak için yardım menüsünü kullanın.

Öneride bulunma ekran görüntüsü.

Stack Overflow'da topluluk tarafından yanıtlanmış öneriler ve sorularınıza da ulaşabilirsiniz.

Teşekkürler,

Silviu Andrica