Cosmos DB Azure RBAC Entegrasyonu: İki Dünya Birleşiyor
Bakın şimdi, Azure tarafında uzun zamandır beni en çok yoran şeylerden biri neydi biliyor musunuz? Cosmos DB’nın şu ikili izin düzeni. Bir tarafta management plane, öbür tarafta data plane; müşteriye bunu anlatırken bile insan biraz afallıyor. “Evet, kullanıcı Contributor ama veriyi okuyamaz” demek zorunda kalıyorduk. Açıkçası yüz kızartan bir işti.
Bence, Geçtiğimiz günlerde Microsoft, Cosmos DB için Integrated Azure RBAC özelliğinin private preview’ünü duyurdu. Ben buna yıllardır bakıyordum, öyle diyeyim. Lafı uzatmadan söyleyeyim: bu duyuru, kurumsal Cosmos DB kullanan ekipler için küçük bir gelişme değil. Yerine oturursa governance tarafındaki bir sürü baş ağrısını baya hafifletecek.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Önce şu ikili model neden sıkıntıydı, ona bakalım
2022’de bir finans kuruluşunda Cosmos DB tabanlı mikroservis mimarisi kurarken yaşadığım şey hâlâ aklımda. Güvenlik ekibi “RBAC’ten kim neye erişiyor görelim” dedi. Açtık, baktık; yönetimsel rolleri görüyoruz — kim Contributor, kim Reader, kim Owner, hepsi orada. Tamam.
Şahsen, Sonra iş data plane’e geldi. Yanı konteyner içindeki belgelere kim erişiyor? Orası ayrı bir dünya. Microsoft.DocumentDB/databaseAccounts/sqlRoleDefinitions diye bir kaynak var, önü da bambaşka bir CLI komutuyla yönetiyorsunuz; portal’da bile uzun süre düzgün görünmedi, hani insan “bu niye böyle?” diye soruyor.
Neticede audit raporu hazırlamak iki kat iş oluyordu. Uygulama hesabı geçişlerini takip etmek zordu. Yeni gelen developer’a “şu rolü al” derken iki ayrı yere bakmanız gerekiyordu. Hatta şunu da itiraf edeyim: bir keresinde bir uygulamaya data plane’de fazla yetki vermiştim. Fark etmem haftalar sürdü, çünkü merkezî bir yerden görünmüyordu. Yanı sadece karmaşık değildi, aynı zamanda riskliydi.
Çok konuştum, örnekle göstereyim.
Peki yeni model ne getiriyor?
Şimdi asıl meseleye gelelim. Integrated Azure RBAC ile Cosmos DB’nın data plane rolleri doğrudan Azure’ın merkezî RBAC sistemine taşınıyor. Yanı artık “Access Control (IAM)” sekmesinden — bildiğimiz o ekrandan — veri erişimini de yönetebiliyorsunuz. İşte kritik nokta bu.
Yeni built-in roller
İki yeni rol geliyor (duyuruda üç gibi konuşulsa da pratikte iki tanesi öne çıkıyor):
- Cosmos DB Data Reader — Sadece okuma. Raporlama servisleri, BI tool’ları ve analitik iş yükleri için baya iş görüyor.
- Cosmos DB Data Contributor — Okuma ve yazma. Uygulamanın çoğu zaman istediği rol zaten bu oluyor.
Bence buradaki en önemli detay şu: Bu roller artık az role assignment komutuyla atanabiliyor. Yanı Terraform, Bicep ya da ARM; neyle altyapıyı yönetiyorsanız aynı dili kullanıyorsunuz. Ayrı API çağrısı falan yok, ayrı provider derdi de çıkmıyor.
Entra ID ile daha tutarlı kimlik deneyimi
Eğer uygulamanız. Managed Identity ile Entra ID üzerinden authenticate oluyorsa — ki 2025’te başka türlüsü biraz tuhaf kaçar — kod tarafında değişiklik yapmanız gerekmiyor. Aynı token, aynı kimlik; sadece arkadaki yetki — en azından ben öyle düşünüyorum — kontrolü daha düzenli çalışıyor. Şey gibi düşünün: görünüşte küçük ama operasyon tarafında hissedilir fark yaratıyor.
“Tek bir yetkilendirme modeli. Tek bir audit log. Tek bir governance dili. Bu, benim yıllardır beklediğim şeylerden biri.”
Eski modelle yenisini yan yana koyunca ne görünüyor?
Size bir şey söyleyeyim, Açık konuşayım, slogan satmak istemiyorum. O yüzden tabloyu direkt koyayım; kafada netleşsin daha iyi:
| Özellik | Eski Model (SQL RBAC) | Integrated Azure RBAC |
|---|---|---|
| Rol tanımlama yeri | Cosmos DB hesabı içinde, ayrı API | Merkezî Azure RBAC |
| Portal görünürlüğü | Cosmos DB → Data Explorer → ayrı sekme | Access Control (IAM) — tek yer |
| Audit log | Activity Log + ayrı sorgu | Tek Activity Log akışı |
| IaC desteği | Özel resource tipleri | Standart role assignment |
| Custom rol | Var | Henüz yok (preview kısıtı) |
| Production hazırlığı | GA, stabil | Private preview, henüz değil |
Bunu pratikte nasıl kullanacaksınız?
Diyelim ki preview’a kabul aldınız ve Function App’inize Cosmos DB Data Contributor rolü vermek istiyorsunuz (en azından benim deneyimim böyle). Eskiden buna benzer bir yol izliyordunuz:
Bir dakika — bununla bitmedi. Bu konuyla ilgili Teams Agent Kurulumu Artık Tek Komutla Tamam yazımıza da göz atmanızı tavsiye ederim.
# ESKİ YÖNTEM — ayrı bir dünya
az cosmosdb sql role assignment create \
--account-name mycosmosacc \
--resource-group myrg \
--scope "/" \
--principal-id $PRINCIPAL_ID \
--role-definition-id 00000000-0000-0000-0000-000000000002
Yeni modelde işe tanıdık komutla ilerliyorsunuz: Gateway API v1.5: Altı Özellik Stable Oldu, Ne Değişiyor? yazımızda bu konuya da değinmiştik.
# YENİ YÖNTEM — standart Azure RBAC
az role assignment create \
--assignee $PRINCIPAL_ID \
--role "Cosmos DB Data Contributor" \
--scope "/subscriptions/$SUB/resourceGroups/myrg/providers/Microsoft.DocumentDB/databaseAccounts/mycosmosacc"
Şöyle söyleyeyim, Baktığınızda fark hemen çıkıyor ortaya değil mi? İkinci yöntem, Storage Account’a Blob Contributor vermekle aynı dilde konuşuyor. Ekip içi eğitim açısından bu baya önemli; yeni gelen birine “Azure’da yetki nasıl verilir?” sorusunu tek kalıpla anlatabileceksiniz artık.
Peki Türkiye’de kurumsal müşteriler için anlamı ne?
Burada biraz durmak lazım çünkü Türkiye’de işin rengi biraz farklı oluyor. Logosoft’ta danıştığımız müşterilerin önemli kısmı — özellikle bankalar, sigorta şirketleri ve kamu kurumları — KVKK ve BDDK denetimleri için kim, hangi veriye, ne zaman erişti? sorusuna net cevap vermek zorunda kalıyor. Bu konuyla ilgili GPT-5.5 ve Microsoft Foundry: Kurumsal AI Artık Ciddi yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için Service Bus Batch İşlemede Mesaj Bazlı Settlement Devrimi yazımıza bakabilirsiniz.
Daha önce bu raporu çıkarmak için iki ayrı sorgu yazmanız gerekiyordu; compliance ekibinin yarısı buna söylenirdi desem yeridir. Şimdi tek bir Activity Log üzerinden ve tek bir Azure Resource Graph sorgusuyla işler görünür hâle geliyor. Bu sadece teknik rahatlık değil; denetim süreçlerini gerçekten hızlandıran bir değişiklik.
Bir de şu taraf var: Türkiye’de Cosmos DB’nın benimsenmesi batı pazarlarına göre biraz daha yavaş gidiyor. Sebeplerden biri de bu karmaşıklık bence (şaşırtıcı ama gerçek). “Bizim DBA ekibi alışsın, sonra bakarız” cümlesini çok duydum; hani klasik savunma hattı gibi dürüyor. İzin modelinin sadeleşmesi bu ilgisizliği biraz kırabilir diye düşünüyorum. Mesela de Cosmos DB’de AI Maliyet Optimizasyonu: 7 Pratik İpucu yazımda anlattığım AI iş yüklerinde Cosmos DB tercih ediliyor son dönemde; bu senaryolarda Entra ID tabanlı Managed Identity. Standart olduğu için yeni RBAC modeli doğal şekilde oturacak gibi dürüyor.
Şimdi gelelim işin can alıcı noktasına.
Küçük ekip mi büyük ekip mi? Tavsiye aynı değil tabiî.
Eğer 5-10 kişilik startup ekibindeyseniz açıkçası eski modelin sıkıntısını çok hissetmiyor olabilirsiniz; sonuçta bir kişi her şeyi yönetiyordur ve kafasında tutuyordur. Ama yine de yeni modele geçin derim — çünkü ekip büyüdüğünde teknik borç ödemeye başlamıyorsunuz en azından.
Eğer 50+ kişilik kurumsal yapıdaysanız durun bir saniye diyorum burada. Production’a geçmeden önce private preview içinde iyice test edin; custom rol desteği henüz yok. Bu ciddi bir kısıt gibi dürüyor açıkçası. Eğer ihtiyacınız “sadece belirli container’da read olsun” seviyesindeyse, GA gelene kadar beklemek daha mantıklı olabilir.
Dikkat edilmesi gerekenler — ben olsam nerelere bakarım?
Birkaç pratik uyarıyı da bırakayım: A2A v1 ile.NET’te Çapraz Platform Agent İletişimi yazımızda bu konuya da değinmiştik.
- Mevcut SQL RBAC atamalarınız çalışmaya devam edecek. Bu güzel haber — geriye dönük uyumluluk var yanı acele edip her şeyi taşımak zorunda değilsiniz. — bunu es geçmeyin
- Custom rol yok. “Sadece şu container’da read ama şu partition key’de write” gibi ince ayarları şimdilik yapamıyorsunuz.
- Scope desteği gelişiyor. Şu anda account-level atamalar net çalışıyor; database ve container seviyesindeki davranışlar değişebilir yanı dikkat etmek gerekiyor.
- UX değişebilir. Microsoft açık açık söylüyor: feedback’e göre arayüz güncellenebilir. Dokümantasyon yazıyorsanız ekran görüntülerini koymadan önce iki kere düşünün derim.
Kendi ortamımda ilk denememde ben de hata aldım — role assignment yapıldı ama uygulama tarafında erişim 401 döndü. Sebebi token cache çıktı. Yeni rol atandıktan sonra Managed Identity’nın token’ını yenilemek gerekiyor; eski token hâlâ eski yetkileri bellekte tutuyordu. Çözüm basit: uygulamayı restart etmek ya da token lifetime dolana kadar beklemek. Ufak detay ama valla saatimi yedi.
Evet.
Daha büyük resmin bir parçası — peki nereye doğru?
Dürüst olayım: bu duyuru tek başına devrim falan değil. Ama Microsoft’un son 1-2 yılda Entra ID merkezli güvenlik mimarisini bütün servislere yayma stratejisinin önemli parçalarından biri. Entra External ID Native Auth SSO: Tam Entegre Deneyim tarafında da benzer bir konsolidasyon var. Kubelet API Yetkilendirmesi GA Öldü: Güvenlik Devrimi yazımda anlattığım Kubernetes tarafındaki yetkilendirme dönüşümü de aynı çizgide gidiyor aslında;
“Tek kimlik, tek yetkilendirme, tek audit.” mottosu boşuna seçilmemiş gibi dürüyor. Ben bu yaklaşıma yakın hissediyorum kendimi. Yıllardır AZ-500 sınavına hazırlanırken anlattığım least privilege prensibinin sahada uygulanabilir hâle gelmesi için böyle entegrasyonlar şart oluyor.
Tam da öyle.
Maliyet tarafına kısa bir bakış atalım mı?
Kısaca değineyim: RBAC entegrasyonunun kendisi ekstra ücret getirmiyor. Cosmos DB’nizin RU/s tüketimi neyse o devam ediyor. Ama dolaylı tasarruf var — operasyonel yük azalıyor, audit hazırlığı kısalıyor, yapılan hata sayısı düşüyor. Türkiye’de orta ölçekli bir müşteride compliance hazırlık maliyetinin yıllık altı haneli rakamlara çıkabildiğini düşünürsek, burası işe yarayan bir kazanım gibi dürüyor.
Peki neden?
Peki ilk adım olarak ne yapmalısınız?
Eğer Cosmos DB kullanıyorsanız şöyle ilerlemenizi öneririm:
- Mevcut data plane RBAC atamalarınızı listeleyin.
az cosmosdb sql role assignment listkomutuyla dökümünü çıkarın. - Hangi uygulamanın hangi yetkiye ihtiyacı olduğunu sade bir tabloya yazın. Çoğu zaman bazı uygulamaların gereğinden fazla yetkili olduğunu fark ediyorsunuz.
Sıkça Sorulan Sorular
Mevcut SQL RBAC atamalarım bozulur mu?
Hayır, bozulmuyor. Microsoft geriye dönük uyumluluğu koruyacağını net bir şekilde söyledi. Yanı eski data plane atamalarınız sorunsuz çalışmaya devam ediyor. Yeni modele geçişi de aslında incremental yapabilirsiniz — mesela yeni uygulamaları yeni modelle kurarsınız, eskilere hiç dokunmazsınız.
Custom rol oluşturabilir miyim?
Şu an yok maalesef. Private preview’da sadece iki built-in rol var: Data Reader ve Data Contributor. Açıkçası ince ayarlı yetki ihtiyacınız varsa bence GA olana kadar mevcut SQL RBAC modelinde kalmak daha mantıklı.
Ekstra ücret çıkar mı?
Hayır, RBAC entegrasyonunun kendisi ücretsiz. Cosmos DB’nın standart RU/s ve storage maliyetlerinin dışında herhangi bir ek fatura kalemi gelmiyor. Hatta tecrübeme göre operasyonel maliyetleri bir miktar düşürmesi de oldukça muhtemel.
Production’da kullanabilir miyim?
Şu an için hayır. Microsoft zaten açıkça “private preview, production önerilmez” diyor. Önce test ve geliştirme ortamlarında deneyin, geri bildirimlerinizi verin, sonra GA duyurusunu bekleyin. Bence 2026’nın ilk yarısında GA gelir — ama bu tamamen benim öngörüm, resmî bir bilgi değil.
Terraform ile yönetebilir miyim?
Şunu fark ettim: Evet! Bence en güzel taraflarından biri de bu zaten. Standart azurerm_role_assignment kaynağıyla yönetiliyor,. Ayrı bir provider ya da kaynak tipi öğrenmek zorunda değilsiniz. IaC tarafında ciddi bir sadeleşme demek bu.
Kaynaklar ve İleri Okuma
Resmî Duyuru: Private Preview of Cosmos DB Azure RBAC Integration (Microsoft DevBlogs)
Azure Cosmos DB Role-Based Access Control Dokümantasyonu
Azure RBAC Genel Bakış (Microsoft Learn)
Tuhaf ama, Managed Identities for Azure Resources
İç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.
1 yorum