Azure Storage API’larında Entra ID ve RBAC Dönemi: Pratikte Ne Değişti?
Şifreli Kapılar Artık Daha Akıllı: Azure Storage API’ları Nereye Evriliyor?
Vallahi,
Hadi itiraf edelim, güvenlik denen şey çoğu zaman elimizi kolumuzu bağlıyor. Hele ki gününüz Azure Storage gibi kocaman veri depolarının anahtarlarını çevirmekle geçiyorsa… Yanı bir bakmışsın “şu best practice çıktı”, öbür gün başka uyarı! Ama geçtiğimiz hafta duyurulan yenilik var ya — işte o hakikaten farklı. Çünkü artık Microsoft Entra ID (eski adıyla Azure AD) desteğiyle beraber, can alıcı Storage API’larında RBAC kontrolleri sahada çalışıyor. Uzatmayacağım; OAuth ile erişim, üstelik rol bazlı yetkilendirme desteğiyle, hayal olmaktan çıkıp gerçeğe dönüşmüş durumda.
Diyorsanız ki “Zaten vardı bu işler?”, bi’ dakika… O kadar basit değil! Ben ilk duyduğumda “Oh be sonunda!” dedim; 2021 başında büyük finans kuruluşunda dosya servisleriyle çuvallayınca yaşadığım tatsızlık hâlâ aklımda mesela. Oraya ayrıca geleceğim.
Neleri Kapsıyor Bu Güncelleme?
Bence burası kritik çünkü değişiklik ‘her yerde OAuth geldi!’ gibi genelleyici bir şey değil; spesifik bazı veri seviyesi hareketlere dokunuyor:
- Get Account Information
- Get/Set Container ACL
- Get/Set Queue ACL
- Get/Set Table ACL
Buralar tam olarak şu sorulara cevap veriyor: “Kim hangi konteyneri görebilir?”, “Kim o queue’ya mesaj bırakabilir?” Bunların yanıtı bugüne kadar ya statik anahtarla ya da SAS token’la idare edildi. Eh, bu yöntemler de bana her zaman taş devrinden kalma geliyor zaten (kendi tecrübem). Sonunda dişe dokunur, adam akıllı ve merkezî alternatif resmî olarak önümüze kondu (kendi tecrübem)
Vallahi gerçek şu ki, yıllardır OAuth eksikliğinden dolayı müşterilerim ellerinde gereksiz SAS token patlatmak zorunda kaldı — resmen risk dağıtıyorduk!
Peki Ya Hata Kodları? Ufak Bir Tuzak Var!
Bunu gözden kaçırmayın sakın — yoksa kendinizi sabaha karşı projede saç baş yolarken bulursunuz! Önceden yanlışlıkla OAuth ile bu endpoint’lere dadandığınızda karşınıza pat diye 404 Not Found fırlardı ve insan zannediyor ki endpoint yok (!). Aslında oradasınız. Erişiminiz yokmuş; şimdi işe gerçekten izniniz olmazsa 403 Forbidden, anonim talepteyseniz de klasik şekilde 401 Unauthorized (yanlış duymadınız).
Eski kodlarda veya otomasyonlarınızda “404 dönerse şöyle davran” tarzı if koşulları varsa acilen tarayın derim – ters köşe olabilirsiniz.
Geçen ay Logosoft tarafında peş peşe üç uygulamada bunların tetiklendiğine şahit oldum, sabahlamalık debug seanslarımız öldü yanı…
Azure Storage API’larında Entra ID ile OAuth tabanlı RBAC kontrolleri devreye girerek, SAS/anahtar yerine rol bazlı yetkilendirmeyi veri seviyesinde uygulanabilir hâle getiriyor.
| Özellik | Konuya Etkisi |
|---|---|
| Kimlik Doğrulama | Entra ID (OAuth) üzerinden yetkilendirme |
| Yetkilendirme Modeli | Rol bazlı RBAC kontrolleriyle “kim neyi yapar” netleşiyor |
| Hangi Endpoint’ler | Account info, Container/Queue/Table ACL Get-Set işlemleri |
| Hata Davranışı | Yetki yoksa 403, anonimse 401; eski kodlar 404 kontrolü yapıyorsa revize gerekebilir |
Not: Desteklenen API listesini ve HTTP hata kodlarını kontrol ederek mevcut otomasyon/if koşullarını güncelleyin.
Neden Herkes Oauth’a Zorlanıyor?
İnanın, Bence bunu atlamak mümkün değil… Anahtar temelli veya SAS token bazlı giriş yöntemleri uzun yıllardır ortalarda dolaşıyor fakat çağ değişti — artık işleri çok büyüttük.
- SAS Token: Belli süre kullanılabilen özel link – kötü niyetlinin eline düşerse sonuç hüsran olabilir. Kontrolü zahmetlidir.
- Anahtar Bazlı Erişim: Bir kere kaptırdın mı tüm storage hesabını silip yeniden oluşturman gerekebilir.
- OAuth (Entra ID): Rolleri tek merkezden atayabiliyorsun, token süresi senin kontrolünde oluyor, audit tutması kolaylaşıyor ve izin yönetimi topluca çözümleniyor.
Kendi blogumda adlfs ile AI projelerinde blob bağlantısı üzerine yazarken (merak edenler baksın burada detaylar var), millet hep aynı şeyi sormuştu bana “Peki OAuth ne zaman oturacak?” – cevabı yeni geldi diyebilirim!
2019’da kendi sandbox ortamım anahtardan ötürü iki saat kilitlendi… O günden beri ağzım yandıysa yoğurdu üflerek yiyorum — OAuth savunucusuyum net.
Maliyet Tarafını Unutmayın!
Küçücük bir detay gibi dürüyor ama FinOps kafasında olan bilir – erişimleri düzgün yönetmek kimi zaman fazladan okuma-yazma trafiğini engelliyor ve direkt tasarrufa yarıyor. Geçen yıl bankacılık sektöründe yaptığımız işte permission escalation vakalarını törpüleyerek ilk yılda %15’e yakın storage maliyeti azaldığını bizzat gördüm (evet rakam doğru!). Tabiî burada asıl hüner RBAC kurgusunu düzgün yapmakta bitiyor.
.NET Uygulamalarında Gerçekten Kolay mı? Küçük Bir Örnek Yetmez…
.NET dünyasında işler güllük gülistanlık mı derseniz… hepten pamuk şekeri olmadı tabiî ama geçmişe göre ciddi ilerledik! Hele bir de Azure Identity paketindeki DefaultAzureCredential sihir gibi: Microsoft Veritabanlarında Yapay Zekâ Ajanı Devrimi: Hibritten Buluta Geçişte Gerçek Fırsatlar yazımızda da bu konuya değinmiştik.
using Azure.Identity;
using Azure.Storage.Blobs;
var credential = new DefaultAzureCredential();
var client = new BlobServiceClient(new Uri("https://hesapadi.blob.core.windows.net"), credential);
var info = client.GetAccountInfo(); // Sadece örnek
// Artık credential işi sizin sırtınızdan kalktı!
Ama burada tuzağa dikkat edin — local’de çalışan kod prod’daki managed identity’ye ya da service principal’e kendiliğinden geçiş yapamayabiliyor(!). Hybrid cloud tabanlı altyapılarda özellikle testte pas geçtiğimiz çok oluyor.
Haziran sonu Telekom sektöründen Fatih’in macerasına şahidim mesela… Local’de harika koştuğu hâlde staging’e koyunca authentication error verdi – meğer environment variable unutulmuş!
Koddan Fazlasına İhtiyaç Var mı?
Sadece kodu elle düzeltmek yeter mi sanıyorsunuz? Değil! Portal’dan RBAC rolünü layıkıyla atanmadıysa hiç uğraşmayın – canlıya indirmemeniz gereken izinleri geliştirmeye açarsanız ileride dönüp uğraştırır sizi.
Unutmadan ekleyeyim; App Service’inize Managed Identity vermeyi atlarsanız boşuna oyalanırsınız sonra… Demedi demeyin!
(ki bu çoğu kişinin gözünden kaçıyor)
Sahada Gördüğüm Sorular & Cevaplar — Aklınızda Kalmasın!
- Kullanıcı bazında audit log tutulabiliyor mu?
Tabiî ki mümkün! OAuth aktif olunca hem access hem action log’unuz doğrudan Entra portalından izlenebilir hâle geliyor – kim ne yaptı açık seçik ortada. - Tamamıyla SAS’tan vazgeçmeli mıyım peki?
Aniden bırakmaya gerek yok belki ama stratejinizi mutlaka evriltin derim. Public static hosting vb kısa vadeli paylaşım durumlarında hâlâ işe yarar fakat orta-uzun vadede güvenliği arttıracaksanız tek yol OAuth + RBAC’tan geçiyor. - Tüm client SDK’larda durum eşit mi dersiniz?
Ne yazık ki hayır… Python cephesinde son aylarda bazı feature eksikleri devam ediyor (Temmuz’da deneyip görmüştük),.NET işe yarışta biraz önde gidiyor şimdilik.
son değerlendirme yazımı mutlaka inceleyin!
Kapanış Notu ve Son Tavsiyelerim
Bana kalırsa herkesin masasına acilen gelmesi gereken konu öldü bu entegrasyon mevzuu… Eğer storage yöneticiliğinde çıtayı yukarı taşıyacaksanız beklemeyin.
Ama dürüst olayım; henüz %100 dört dörtlük diyemiyorum—özellikle eski sistemlerden göç ederken minnak sıkıntılar yaşanmaya devam ediyor (mesela custom uygulamalarda yeni hata kodlarına alışma sancısı).
Pratikte birebir denemişliğimle söylüyorum:
Bu upgrade sizi uzun vadede kurtaran cinsten olacak.
RBAC için harcadığınız zamandan daha fazlasını kesinlikle geri kazanacaksınız.
Son tavsiye? Hata kodlarına takılı kalıp küçük buglarla boğuşmayın…
Kaybettiğiniz zamanı sonra bana hatırlatırsınız!
Kaynak: Azure Storage APIs gain Entra ID and RBAC support
Sıkça Sorulan Sorular
Azure Storage API’larında Entra ID ve RBAC kullanımı ne avantaj sağlıyor?
Entra ID ve RBAC ile artık erişim kontrollerini çok daha merkezî ve güvenli şekilde yönetebiliyoruz. Eskiden SAS token gibi geçici ve riskli yöntemlere mahkumduk, şimdi işe roller bazında kim ne yapabilir net olarak belirleniyor. Kendi tecrübem, bu değişiklikle operasyonlar çok daha rahatladı.
OAuth ile erişim sağlanırken eski 404 hataları neden 403 veya 401 oluyor?
Önceden yetkisiz erişimde 404 Not Found dönmesi kafa karıştırıyordu çünkü endpoint gerçekten vardı ama erişim engellenmişti. Şimdi işe 403 Forbidden veya 401 Unauthorized dönerek erişim sorununu daha net anlıyoruz. Bu değişiklik, debug sürecini oldukça kolaylaştırıyor.
RBAC destekleyen Azure Storage API’ları hangileri?
Özellikle Get/Set Container, Queue ve Table ACL işlemleri ile Get Account Information gibi veri seviyesindeki hareketlerde RBAC devreye giriyor. Yanı kim hangi konteyneri veya kuyruğu görebilir, kim mesaj gönderebilir gibi yetkilendirmeler artık buradan kontrol ediliyor.
SAS token kullanmak yerine OAuth’a geçmek zor mu?
İlk başta alışmak zaman alabilir, özellikle eski sistemlerde otomasyonlar varsa dikkat etmek gerekiyor. Ama uzun vadede güvenlik ve yönetilebilirlik açısından kesinlikle daha iyi. Benim deneyimim, özellikle büyük ölçekli projelerde OAuth’a geçmek işleri bayağı kolaylaştırıyor.
Bu yeni RBAC ve Entra ID entegrasyonu hangi durumlarda kritik?
Büyük ve hassas veri depoları yönetirken, erişim yetkilerinin merkezî ve kontrollü olması gerektiğinde kritik öneme sahip. Özellikle finans, sağlık gibi sektörlerde veri ihlali riski minimuma indiriliyor. Dolayısıyla bu güncelleme, güvenlik politikalarını sıkılaştırmak isteyen herkes için önemli.
Kaynaklar ve İleri Okuma
Authenticate with Azure Active Directory and role-based access control (Azure Storage)
Authorize access to Azure Storage using Azure AD
Azure Storage Enhances Security with RBAC and Azure AD Integration
Azure SDK for.NET – Storage Blobs Samples
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