Azure DevOps’ta Güvenlik Krizi: Build Kimlikleri
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 işe “build service identity” denilen otomasyon kimliklerinin Advanced Security API’daki “Read alerts” yetkisiyle yaşanan tablo karışıklığı öldü. Çok teknik gibi dürüyor, 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 öldü!
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 bildirım 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!
Azure DevOps’ta build service identity (otomasyon kimlikleri) için Advanced Security API “Read alerts” yetkisindeki değişiklik, CI/CD alarm akışını etkileyip çok sayıda pipeline’ı bozdu. Ekipler için kritik konu: güvenlik artırımı ile operasyonel süreklilik arasındaki dengeyi doğru kurmak.
| Özellik | Konuya Etkisi (Özet) |
|---|---|
| Build service identity | Alertleri API’den çekememeye başladı |
| Advanced Security API yetkisi | “Read alerts” kısıtlamasıyla erişim değişti |
| CI/CD ve pipeline sürekliliği | Alarm akışına bağlı pipeline’lar domino gibi patladı |
| Geri dönüş / zaman çizelgesi | Yasak Nisan 2026’ya kadar geri alındı; sonra tekrar kısıt bekleniyor |
| Önerilen aksiyon | Service principal oluştur, sadece gerekli yere “Read alerts” ver, pipeline’ları migrate et |
Not: “Default” build kimlikleriyle aşırı geniş erişim açtıysanız, güvenlik değişiklikleri ilk önce sizi vurabilir.
Anahtar Uyarı! Ne Yapmalı?
Bana göre şimdilik kısa süreli nefes alma alanımız var hepsi bu! Yanı 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 (yanı 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 yanı!
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ığı öldü 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.
Yanı 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 tür 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 Server Şubat Yaması: Güvenlik ve Performans
yazımda da böylesi anı 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;)
Sız 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
Sıkça Sorulan Sorular
Azure DevOps’ta build kimlikleri nedir ve neden önemlidir?
Build kimlikleri, Azure DevOps’ta otomatikleştirilmiş CI/CD süreçlerinde kullanılan servis hesaplarıdır. Bu kimlikler, pipeline’ların kaynaklara erişimini sağlar ve güvenlik açısından kritik rol oynar. Son güncellemelerle bu kimliklerin erişim yetkilerinde değişiklikler öldü, bu yüzden dikkat etmek gerekiyor.
Build kimliklerinin Advanced Security API’deki “Read alerts” yetkisi neden sınırlandı?
Microsoft, potansiyel saldırılara karşı ekstra güvenlik önlemleri almak için build kimliklerinin bazı API yetkilerini kısıtladı. Özellikle “Read alerts” yetkisi, güvenlik uyarılarına erişimi sınırlandırarak riskleri azaltmayı hedefliyor. Ancak bu değişiklik birçok pipeline’ın kırılmasına neden öldü.
Bu erişim kısıtlaması pipeline’ları nasıl etkiledi?
Birçok ekip, build kimlikleri üzerinden alert verisi çekerek raporlama ve uyum süreçlerini yürütüyordu. Yetki kısıtlaması sonrası bu veri akışı kesildi, pipeline’lar hata vermeye başladı. Benzer sorunları yaşayan müşterilerle konuşunca, hazırlıksız yakalanmanın ne kadar zor olduğunu gördüm.
Bu duruma karşı ne yapmalıyım, acil çözüm öneriniz nedir?
En hızlı çözüm, yeni bir Service Principal oluşturup sadece gerekli yetkilerle (örneğin “Read alerts”) donatmaktır. Böylece kontrol sizde olur ve gereksiz erişim riskini azaltırsınız. Eski build kimliklerini yavaş yavaş bu yeni yapıya taşımanız gerekiyor, yoksa 15 Nisan 2026’dan sonra sorun yaşarsınız.
Service Principal kullanmak gerçekten lisans gerektirir mi?
Genellikle hayır, eğer bu Service Principal sadece alert okumak gibi kod commit etmeyen işlemler için kullanılıyorsa ekstra lisans gerekmez. Bu da küçük bir rahatlama sağlıyor. Kendi deneyimime göre, dar yetkili Service Principal kullanmak hem güvenlik hem de yönetim açısından en mantıklısı.
Kaynaklar ve İleri Okuma
Azure DevOps’ta Service Principal ile Bağlantı Kurma
Azure DevOps Güvenlik ve İzinler
Azure DevOps Güvenlik Uyarıları Duyurusu
Azure Pipelines YAML Şablonları ve Best Practices
İçeriği paylaş:
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder