Azure Blob Storage Yanlış Yapılandırması: Genel Erişim, SAS ve Denetim

Merhaba,

Azure Blob'da yanlışlıkla public container bırakmak hâlâ klasik bulgu. Bu yazıda genel erişim seviyeleri, SAS riskleri ve denetim için pratik kontrolleri anlatıyorum. Örnekler kendi lab aboneliğim üzerinden.

Erişim katmanları

• Private: anonim erişim yok
  
• Blob: anonim kullanıcı blob bilgisini URL ile okuyabilir
  
• Container: listeleme de açık (daha kötü)
  

Depolama hesabında "Allow blob public access" kapalıysa container public yapsanız bile engellenir. İkisini birden kontrol edin.



SAS token tuzakları
Shared Access Signature geçici yetki verir; fakat:

• Çok uzun expiry (yıllarca) = fiilen anahtar
  
• İzinlerin fazla olması (write+delete+list)
  
• HTTPS zorunluluğu olmaması
  
• SAS'ın GitHub'a / mobil uygulamaya gömülmesi
  

Tercihen user delegation SAS (Azure AD kimliğiyle) kullanın; hesap anahtarıyla üretilen SAS sızıntısında rotasyon daha acı olur.

Denetim ve tespit

• Azure Resource Graph / Policy ile public container taraması
  
• Diagnostic settings: StorageRead/Write loglarını Log Analytics'e
  
• Microsoft Defender for Storage (ortamınızda varsa) anomali uyarısı
  
• CI'da Terraform plan: public_access != null ise fail
  

Örnek Resource Graph düşüncesi: storage container'larında publicAccess alanı boş olmayanlar.

Sıkılaştırma adımları

1. Hesapta public access'i kapat
   
2. Gerekli anonim dağıtım varsa Azure CDN + kontrollü origin kullan
   
3. Firewall: selected networks + private endpoint
   
4. Shared key access'i mümkünse kapatıp AAD'ye geç
   
5. SAS için kısa TTL + minimum permission
   

Olay senaryosu
Public container'da müşteri verisi bulunduysa: hemen private yap, SAS/account key rotate et, logdan kim indirmiş bak, KVKK sürecini tetikle. "URL'yi gizledik" yetmez; URL zaten indekslenmiş olabilir.

Kaynaklar

• Microsoft Learn: Azure Storage security guide
  
• Azure Security Benchmark - Storage
  
• SAS best practices (Microsoft Docs)
  

Siz storage hesaplarında shared key'i kapatabildiniz mi, yoksa eski uygulamalar mı engelliyor?

Private endpoint ve DNS
Storage'ı private endpoint arkasına alınca eski public URL'ler kırılır; uygulamaları güncelleyin. DNS zone'ları (privatelink) doğru değilse geliştirici "Azure bozuldu" diye public'i geri açar — en sık regressiyon.

Lifecycle ve soft delete
Yanlışlıkla silinen kanıt / yedek için soft delete ve versioning açın. Fidye senaryosunda immutable storage (WORM) politikaları ayrı başlıktır; en azından kritik konteynerlerde versioning açık olsun.


Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Uygulama notu
Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.
Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.