Azure DevOps’ta Güvenlik Krizi ve Geçici Geri Alım: Build Kimlikleriyle Otomasyonun Geleceği
Son Gelişmeler: Güvenlik mi, Kolaylık mı? Karar Zamanı!
Hani bazen öyle bir şey olur ki, herkesin gündemi altüst olur ya… Azure DevOps ekibi arada sırada gerçekten tüm takımları şaşırtmayı başarıyor. Son bomba ise “build service identity” denilen otomasyon kimliklerinin Advanced Security API’daki “Read alerts” yetkisiyle yaşanan tablo karışıklığı oldu. Çok teknik gibi duruyor, biliyorum – ama inanın geçenlerde bir müşterimde taa gece yarısı çıkan sorunda kendi kendime, “Ya bari biri önceden söyleseydi şunu!” diye isyan ettim.
Kısaca anlatayım: CI/CD sürecini döndüren Azure DevOps’un meşhur “Proje Koleksiyonu Build Servisi” hesapları, güvenlik uyarılarını doğrudan API’den çekememeye başladı. Neden derseniz; zincirdeki potansiyel saldırganlara karşı tedbir alınıp build kimliği için erişim kısıtlanınca iş resmen birbirine girdi. Teoride mantıklı aslında — gelgelelim pratikte işler sarpa sardı ve olan oldu!
Geriye Dönüşün Sebebi ve Az Bilinen Ayrıntılar
Açıkçası çoğu ekip için build servislerinden alınan alarm verilerine bağlı kurulu düzen demek hayatın ta kendisi. O sebeple değişiklik olunca onlarca pipeline patladı; özellikle devasa yapılarda sorunlar domino taşı gibi hızla yayıldı.
Beni üç ayrı müşteri panikle aradı (abartmıyorum). Fabrikasındaki gecelik build’lere kod taraması eklemiş olan var – sabah bakıyor rapor yok! Başka biri uyum raporlarını tamamen bu alert akışına bağlamış, hop kontak kesildi. Kimse hazırlıklı değildi ki! Olay şu bence; Microsoft iyi niyetle ekstra güvenlik sağlamak isterken bildirim az yapınca ortalık yangın yerine döndü. Patır patır şikayetler artınca da — ne mi yaptılar? Nisan 2026’ya kadar koydukları yasak geri alındı. Tam rahatladık diye sevinmeyin hani… Çünkü sonrasında yine kapıyı kapatacaklarından eminim!
Her değişiklik fırsattır derler… Ama hazırlanmadan yakalanırsanız kriz kaçınılmaz olur!
Anahtar Uyarı! Ne Yapmalı?
Bana göre şimdilik kısa süreli nefes alma alanımız var hepsi bu! Yani demek istediğim; 15 Nisan 2026’dan sonra eski usül build kimliğiyle okuyamayacaksınız alert’leri… Şimdi upuzun listeler yapmak uzun vadede vakit kazandırabilir de:
- Önce bir Service Principal oluşturun hemen şimdi.
- Sadece gereken yerde (yani repo özelinde) Advanced Security: Read alerts yetkisi verin.
- Eğer yazdığınız service principal kod commit etmeyecekse ekstradan lisans istemiyor – sevindirici yanı burası!
- Tüm eski pipeline’larda build identity kullandığınız noktaları yavaş yavaş migrate edin gitsin.
- Status Check özelliğini yakın takibe alın çünkü native güvenlik kontrolleri yakında direkt pipeline’a entegre olacak.
Mantar gibi türeyen sorunlara pratik çözümler
Şöyle söyleyeyim, Dobra olayım mı? Eğer her köşe başında “default” build identity ile erişim açtıysanız geçmiş olsun :) Eski pipeline şablonlarında veya ortak YAML dosyalarında bunu gözden kaçırmak aşırı kolay.
Bizzat örneği yaşadık — deploy sonrası test job’una default erişimin bırakıldığı bir projede günlerce insanlar neden alarm gelmedi anlamadı… küçük detay sanmayın yani!
Kod örneğiyle özetlemek gerekirse…
# Kötü yaklaşım:
uses: $(System.AccessToken)
# Doğru yaklaşım:
serviceConnection: $(servicePrincipalConnectionName)
permissions:
— 'Advanced Security.Read'
scopes:
— repository
Peki sizde durum nasıl? Böyle beklenmedik breaking change yüzünden tat almak zorlaştığı oldu mu hiç?
Status Checks vs API Tabanlı Akışlar – Hangisi Hayat Kurtarır?
Sözü uzatmama gerek yok aslında; Sprint 272 ile native Status Check özelliği geliyor — pull request açıldığında repoda yüksek ya da kritik düzey security alert varsa merge işlemi otomatikman bloklanacak.
Ve en güzeli bunun için fazladan kod yazmanıza gerek kalmıyor! Ben açıkçası bu gelişmeye bayıldım diyebilirim fakat…
Pürüz nerde biliyor musunuz? Bazı karmaşık yerlerde (mesela raporlama sistemleri ya da dashboard’lardaki anlık görseller) hâlâ API tabanlı entegrasyona ihtiyacımız devam edecek.
Yani kısaca hepimiz rahat uyuyacağız demek biraz hayal olur.
Neyse – neticeyi görmek zaman işi zaten.
Sürprizler ve Dikkat Edilmesi Gerekenler
- Miras kalan pipeline kaosu: Yıllanmış projelerde hangi task nereden veri okuyor kestirmek çoğu zaman mümkün değil — dependency analizi yapmadan ilerlemeyin derim kesinlikle.
- Lisans işi kafa karıştırabiliyor: Sadece okuma hakkıyla kalan service principal’lar Advanced Security committer lisansı gerektirmiyor.
Ama ileride bir yerde update/generate gibi fonksiyon lazım olacaksa bütçeyi de gözden geçirin çünkü masraf çıkarabilir! - Kısacası: Herkes duyuruları fotoğraf gibi incelese bile sahaya indiğinde şok olabiliyor.
Deneyimlerime göre en iyisi mevcut CI/CD altyapınızda tüm build identity bağımlılıklarını ilk elden tespit etmek—sonra sürpriz yaşamazsınız! - Dökümantasyonu unutmayın: Son dakika yönetmelikleri peşi sıra gelebilir; iç dokümanlarda yeni adımları erkenden anlatmak global dağıtık ekiplerde ciddi zaman ve stres kazancı sağlıyor—tecrübeyle sabit!
Kapanış – Şimdi Başlamak Hayat Kurtarır!
Hani, Peki ben nasıl hareket ediyorum? Kurumsal projelerde uyguladığım rota basit ve epey işe yarıyor şahsen:
- Tüm aktif pipeline’larda kim nereden alarm çekiyor tek tek listele (küçük görme!)
- Kritik noktaları yeni Service Principal’a geçir (özellikle “Read alerts” erişimi şart)
- Status check roadmap’e girsin — devreye aldığında verification süreçlerini peşine ekle
(bazen ikinci tur insan hatasından daha çok kaybettiriyor inan bana!) - Ekipleri sürekli güncel tut ve iletişim kanallarında uyarıları öne çıkar,
sanki ilk defa böyle şey görüyormuş gibi haberdar et :) - Dökümantasyonu ihmal etme;
bugün yazdığın not haftalar sonraki krizi önleyebilir.
Bunu unutmayın lütfen!
Azure DevOps Servera Şubat Yaması Geldi
yazımda da böylesi ani politika değişikliklerinin etkilerine detaylıca değindim—orada farklı bir perspektifle görebilirsiniz bence.
Uğramayı unutmayın.
Biliyoruz artık — teknoloji diyince akla gelen belirsizlik. Değişimdir neticede.
Bugün eski usül çözümünüz tıkırdayabilir fakat yarına hazır olmamak affedilmiyor.
Sonrası pişmanlık olmasın ;)
Siz neler deneyimlediniz?
Sizce bu tip kısıtlamalar gerçekten kontrol mü getiriyor
yoksa bürokrasi yaratıp işi mi uzatıyor?
Kaynak:
Temporary rollback:
build identities can access Advanced Security:
read alerts again
İçeriği paylaş:
Yorum gönder