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… Yani 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 merkezi alternatif resmi 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 ise 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 oldu yani…
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 duruyor 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:
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 halde 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?
Tabii ki mümkün! OAuth aktif olunca hem access hem action log’unuz doğrudan Entra portalından izlenebilir hale geliyor – kim ne yaptı açık seçik ortada. - Tamamıyla SAS’tan vazgeçmeli miyim peki?
Aniden bırakmaya gerek yok belki ama stratejinizi mutlaka evriltin derim. Public static hosting vb kısa vadeli paylaşım durumlarında hala 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 ise 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 oldu 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
İçeriği paylaş:
Yorum gönder