Merhaba

Azure Storage Account’a Giriş
Günümüzde kurumların en değerli varlığı hiç kuşkusuz veri. Bu verinin güvenilir, ölçeklenebilir ve uygun maliyetlerle saklanması ise modern IT altyapılarının en kritik konularından biri haline geldi. İşte bu noktada Microsoft Azure Storage Account, farklı depolama ihtiyaçlarını tek bir çatı altında sunan güçlü bir servis olarak karşımıza çıkıyor. Azure Storage Account, kullanıcıya sadece basit bir disk alanı değil; farklı depolama türlerini (Blob, File Share, Queue, Table) aynı hesap üzerinden yönetme imkânı sağlar. Bu sayede hem uygulamalar hem de son kullanıcılar için veriye güvenli, hızlı ve esnek erişim sağlanır.

Neden Önemli?
Bir Storage Account oluşturduğunuzda aslında yalnızca dosya saklamıyorsunuz; uygulama performansı, veri güvenliği, iş sürekliliği ve maliyet optimizasyonu gibi pek çok faktörü doğrudan etkileyen bir karar alıyorsunuz. Çünkü:

• Blob Storage ile yedekleme, arşivleme, uygulama logları veya büyük boyutlu medya içerikleri saklanabilir.
• File Shares ile şirket içi dosya paylaşım yapıları Azure’a taşınabilir ve hibrit senaryolar desteklenir.
• Queue Storage ile uygulamalar arası mesajlaşma yönetilebilir.
• Table Storage ise NoSQL tabanlı hızlı ve esnek veri saklama imkânı sunar.

Güvenlik ve Dayanıklılık
Azure Storage Account sadece depolama sağlamakla kalmaz; güvenlik, yönetilebilirlik ve dayanıklılık tarafında da güçlü özelliklere sahiptir:

• Şifreleme (Encryption at rest & in transit) ile veriler hem saklanırken hem aktarılırken korunur.
• Erişim katmanları (Hot, Cool, Archive) ile veriler kullanım senaryosuna göre en uygun maliyetle saklanır.
• Yedeklilik seçenekleri (LRS, ZRS, GRS, GZRS) ile farklı bölgelerde veri kopyaları oluşturularak felaket senaryolarına karşı dayanıklılık sağlanır.
• Ağ güvenliği (Private Endpoint, Firewall, VNet entegrasyonu) ile sadece yetkili erişimlere izin verilir.
• Kimlik yönetimi (Microsoft Entra ID entegrasyonu, RBAC rolleri) sayesinde kullanıcı bazlı erişim kontrolü yapılabilir.

İş Sürekliliği ve Ölçeklenebilirlik
Bulut ortamında verinin sürekli erişilebilir olması, kritik uygulamaların kesintisiz çalışması için hayati önem taşır. Azure Storage Account, otomatik ölçeklenebilir mimarisi ile milyonlarca isteği aynı anda karşılayabilir ve ihtiyaç oldukça kapasiteyi artırabilir. Bu da kurumların veri hacimleri büyüdükçe yeni donanım yatırımları yapmadan depolama altyapısını genişletebilmesi anlamına gelir.

Azure Storage Account, yalnızca bir depolama hesabı değil; modern iş dünyasının veri stratejisinin temel taşıdır. Uygulamaların hızlı çalışmasını, kullanıcıların güvenle veriye ulaşmasını, verilerin ise uygun maliyetlerle saklanmasını sağlayan bu yapı, Azure ekosisteminin en kritik bileşenlerinden biridir.
Microsoft Azure Portal üzerine Login oluyoruz.

Microsoft Azure Portal’a giriş yaptıktan sonra Create a resource seçeneği ile yapılandırmayı başlatıyoruz.

Create a resource: Azure Portal üzerinde yeni bir kaynak (resource) oluşturmak için kullanılan seçenektir. Bu seçenek, Azure Marketplace üzerinden yüzlerce hazır servis ve çözüm arasından seçim yaparak hızlıca kurulum yapmanı sağlar. Örneğin sanal makine, DNS zone, veri tabanı, sanal ağ veya depolama hesabı gibi farklı kaynaklar bu menü aracılığıyla oluşturulabilir. Her kaynak bir resource group içinde barındırılır ve oluşturulurken bölge (region) seçimi yapılır. Bu sayede kullanıcılar, ihtiyaç duydukları hizmeti birkaç adımda devreye alarak Azure altyapısında kullanıma hazır hale getirebilir.

Create a resource ekranında Azure Marketplace menüsünde yüzlerce hazır servis ve çözüm arasından seçim yaparak hızlıca kurulum yapabilirsiniz.

Create a resource ekranında Azure Marketplace menüsünde arama bölümüne Storage account yazıyoruz ve Storage account seçeneğini seçiyoruz.

Storage account ekranı geliyor karşımıza.

Subscription: Azure’da kullandığın tüm hizmetler bir abonelik (subscription) altında toplanır. Abonelik, hem faturalandırmayı hem de erişim yetkilerini belirleyen en üst düzey kapsayıcıdır. DNS Zone oluştururken hangi abonelik altında bu kaynağın açılacağını seçmen gerekir. Bu sayede DNS Zone’un maliyeti, erişim yetkileri ve kaynak grupları doğru şekilde ilişkilendirilir.

Plan: Plan seçeneği, oluşturduğun kaynak için kullanılacak olan fiyatlandırma veya hizmet planını gösterir.

• Storage account özelinde Plan seçeneği çok sınırlıdır çünkü Storage account tek tip fiyatlandırma modeli ile çalışır.
• Plan alanı, daha çok farklı hizmetlerde (örneğin App Service, SQL Database, Kubernetes Service gibi) Basic, Standard, Premium gibi seviye ve kapasite seçeneklerini sunar.

Storage account seçeneğininde Create seçeneği ile yapılandırmaya başlatıyoruz.

Create a storage account ekranı geliyor karşımıza.

Create a storage account ekranında Basics sekmesinde Project details bölümü altında

• Subscription: Azure’da kullandığınız tüm hizmetler bir abonelik (subscription) altında toplanır. Abonelik, hem faturalandırmayı hem de erişim yetkilerini belirleyen en üst düzey kapsayıcıdır. DNS Zone oluştururken hangi abonelik altında bu kaynağın açılacağını yapılandırmanız gerekir. Bu sayede DNS Zone’un maliyeti, erişim yetkileri ve kaynak grupları doğru şekilde ilişkilendirilmiş olur.
• Resource group: Kaynakları klasör benzeri mantıkla gruplamanı sağlayan kapsayıcıdır. Storage Account bu resource group içinde barındırılır. İstenirse mevcut bir grup seçilir veya Create new seçeneği ile yeni bir resource group oluşturulur.

Create a storage account ekranında Basics sekmesinde Instance details bölümü altında

• Name: Oluşturulacak Storage Account için verilen ve Azure genelinde benzersiz olması gereken addır. Bu isim, yalnızca küçük harfler ve rakamlardan oluşmalı, uzunluğu ise 3 ile 24 karakter arasında olmalıdır. Büyük harf, boşluk veya özel karakterler kullanılamaz. Bu nedenle seçilen ismin hem benzersiz hem de anlamlı olması önemlidir. Üretim, test veya yedekleme gibi ortamları ayırt etmek için isimlendirme standartları kullanılabilir.
• Resource: Seçilen resource group’un bulunduğu Azure bölgesini gösterir. Storage Account global bir hizmettir, bu nedenle zone verileri Azure’un global DNS altyapısında barındırılır; ancak yönetimsel olarak resource group hangi bölgede oluşturulduysa burada görüntülecektir.

Instance details bölümü altında Preferred storage type bölümünde üç farklı seçenek bulunmaktadır.

• Azure Data Lake Storage Gen2: Blob Storage altyapısı üzerinde çalışan ve büyük veri analizi için optimize edilmiş gelişmiş bir depolama çözümüdür. HDFS (Hadoop Distributed File System) uyumluluğu sayesinde Azure Synapse, Databricks veya HDInsight gibi büyük veri analitik platformları ile sorunsuz entegre olur. IoT verileri, telemetri kayıtları ve yapay zeka için işlenecek veri kümeleri bu yapıda saklanabilir.
• Azure Files: SMB ve NFS protokolleri ile erişilebilen bulut tabanlı dosya paylaşım hizmetidir. Geleneksel dosya sunucularına alternatif olarak kullanılabilir ve farklı işletim sistemlerinden kolayca bağlanılabilir. Azure File Sync özelliği ile şirket içi dosya sunucuları ile hibrit bir senaryo oluşturulabilir. Paylaşımlı klasörler, uygulama konfigürasyonları ve dosya tabanlı iş yükleri için uygundur.
• Azure Tables ve Queues: Daha çok uygulama geliştirme ihtiyaçlarına yönelik hafif hizmetlerdir. Table Storage, key-value yapısında NoSQL veri depolama imkanı sunarken, Queue Storage ise uygulama bileşenleri arasında asenkron mesajlaşmayı sağlar. Table Storage, basit yapılandırılmış verilerin düşük maliyetle saklanmasına, Queue Storage ise sipariş işleme veya task dağıtımı gibi senaryolara çözüm getirir.

Instance details bölümü altında Preferred storage type bölümünde Azure Data Lake Storage Gen2 seçeneğini seçiyoruz.

Instance details bölümü altında Performance bölümünde iki farklı seçenek bulunmaktadır.

• Standard: Genel kullanım için sunulan ve düşük maliyetli depolama planıdır. HDD veya standart SSD tabanlı diskleri kullanarak çalışır. Blob, File, Queue ve Table gibi tüm depolama servislerini destekler. Hot, Cool ve Archive erişim katmanları sayesinde verilerin erişim sıklığına göre maliyet optimizasyonu yapılabilir. Orta düzey performans sunar ve genellikle yedekleme, arşivleme, loglama veya genel amaçlı veri depolama senaryolarında tercih edilir.
• Premium: Yüksek performans gerektiren iş yükleri için tasarlanmıştır. SSD tabanlı depolama yapısı ile düşük gecikme süreleri ve yüksek IOPS sağlar. Özellikle veritabanları, SAP, ERP, CRM sistemleri veya yüksek işlem hacmine sahip finansal uygulamalar gibi kritik sistemlerde kullanılır. Sabit ve öngörülebilir performans sunması en önemli avantajıdır. Ancak maliyet açısından Standard seçeneğe göre daha yüksektir.

Instance details bölümü altında Performance bölümünü Standard olarak seçiyoruz.

Instance details bölümü altında Redundancy bölümünde dört farklı seçenek bulunmaktadır.

• Locally Redundant Storage (LRS): LRS, verilerin aynı Azure veri merkezi içinde üç kopya halinde saklanmasını sağlar. Bu yöntem, disk veya sunucu bazlı donanım arızalarına karşı koruma sunar. Ancak tüm veri merkezini etkileyen bir kesinti veya felaket durumunda veriler risk altında olabilir. Düşük maliyetli bir seçenek olduğundan, yüksek erişilebilirlik gerektirmeyen ve bölgesel felaket toleransı ihtiyacı olmayan iş yüklerinde tercih edilir.
• Zone-Redundant Storage (ZRS): ZRS, verilerin aynı Azure bölgesi içerisindeki farklı Availability Zone’larda üç kopya olarak senkron şekilde tutulmasını sağlar. Bu sayede tek bir zone veya veri merkezinde meydana gelebilecek kesintilere karşı dayanıklılık sağlanır. Yüksek erişilebilirlik gerektiren ve iş sürekliliği kritik olan senaryolar için uygun bir çözümdür.
• Geo-Redundant Storage (GRS): GRS, verilerin birincil bölgedeki kopyalarına ek olarak coğrafi olarak uzak bir ikincil bölgeye de çoğaltılmasını sağlar. Veriler, birincil bölgede üç kopya halinde saklanırken aynı zamanda asenkron olarak ikincil bölgeye aktarılır. Böylece bölgesel felaketler karşısında ek koruma sunulur. Ancak asenkron çoğaltma nedeniyle olası bir felakette son yazılan verilerin kaybolma riski bulunabilir.
• Geo-Zone-Redundant Storage (GZRS): GZRS, ZRS ve GRS özelliklerini birleştiren en kapsamlı yedeklilik seçeneğidir. Veriler, birincil bölgede farklı zone’lar arasında senkron olarak çoğaltılırken aynı zamanda coğrafi olarak uzak ikincil bölgeye de asenkron olarak kopyalanır. Böylece hem zone seviyesinde hem de bölgesel felaketlere karşı en yüksek dayanıklılık sağlanır. Kritik iş yükleri için önerilen en güvenli fakat maliyeti en yüksek seçenektir.

Instance details bölümü altında Performance bölümünü Premium olarak seçiyoruz.

Instance details bölümü altında Premium account type bölümününde üç farklı seçenek bulunmaktadır.

• Block Blobs: Block Blob, büyük miktarda metin veya ikili veriyi (binary data) saklamak için kullanılan depolama türüdür. Veriler bloklar halinde yüklenir, her blok ayrı ayrı yönetilebilir ve sonrasında birleştirilerek tek bir blob haline gelir. Bu yöntem sayesinde büyük dosyalar parça parça yüklendiğinden yükleme işlemi kesilse bile kaldığı yerden devam edebilir. Log dosyaları, yedeklemeler, resimler ve videolar gibi büyük veriler için en uygun çözümdür.
• File Shares (Azure Files): Azure File Shares, bulut üzerinde dosya paylaşımı yapmayı sağlayan depolama hizmetidir. SMB (Server Message Block) veya NFS protokolleri üzerinden erişilebilir ve tıpkı bir ağ sürücüsü gibi kullanılabilir. Bu seçenek sayesinde şirket içindeki kullanıcılar veya uygulamalar, paylaşımlı dosya alanına aynı anda erişebilir. Dosya paylaşımlarının bulutta barındırılması, hem merkezi yönetim hem de yüksek erişilebilirlik avantajı sağlar.
• Page Blobs: Page Blob, sık okuma ve yazma işlemleri gerektiren senaryolar için tasarlanmıştır. Veriler 512 baytlık sayfalardan (pages) oluşur ve belirli bir sayfaya rastgele erişim yapılabilir. Bu yapı sayesinde sanal makineler için Azure Virtual Machine diskleri (VHD dosyaları) Page Blob üzerinde depolanır. Yani sanal makine işletim sistemi ve veri disklerinin temel depolama modeli Page Blob’dur.

Instance details bölümü altında Redundancy bölümünde iki farklı seçenek bulunmaktadır.

• Locally Redundant Storage (LRS): LRS, verilerin aynı Azure veri merkezi içinde üç kopya halinde saklanmasını sağlar. Bu yöntem, disk veya sunucu bazlı donanım arızalarına karşı koruma sunar. Ancak tüm veri merkezini etkileyen bir kesinti veya felaket durumunda veriler risk altında olabilir. Düşük maliyetli bir seçenek olduğundan, yüksek erişilebilirlik gerektirmeyen ve bölgesel felaket toleransı ihtiyacı olmayan iş yüklerinde tercih edilir.
• Zone-Redundant Storage (ZRS): ZRS, verilerin aynı Azure bölgesi içerisindeki farklı Availability Zone’larda üç kopya olarak senkron şekilde tutulmasını sağlar. Bu sayede tek bir zone veya veri merkezinde meydana gelebilecek kesintilere karşı dayanıklılık sağlanır. Yüksek erişilebilirlik gerektiren ve iş sürekliliği kritik olan senaryolar için uygun bir çözümdür.

Create a storage account ekranında Basics sekmesinde gerekli yapılandırma tamamladıktan sonra Next seçeneği ile Advanced sekmesindeki yapılandırma ile devam ediyoruz.

Create a storage account ekranında Advanced sekmesinde Security bölümü altında

• Require secure transfer for REST API operations: Bu seçenek, Azure Storage hesabına yapılan tüm REST API isteklerinin yalnızca HTTPS (TLS) üzerinden yapılmasını zorunlu kılar. HTTP üzerinden gelen istekler reddedilir. Bu seçenek etkinleştirildiğinde, istemci ile Azure Storage arasındaki veri akışı şifrelenir ve aktarım sırasında verilerin üçüncü kişilerce izlenmesi veya değiştirilmesi engellenir. Bu seçenek özellikle Blob, Queue ve Table hizmetleri için geçerlidir. Azure Files için SMB trafiğinde doğrudan bir etkisi yoktur; ancak SMB bağlantılarında zaten şifreleme desteği (SMB 3.0) kullanılmaktadır. NFS protokolü de bu kapsamın dışındadır. Bu seçenek aktif hale getirildiğinde Shared Access Signature (SAS) linklerinin de HTTPS üzerinden kullanılması gerekir. HTTP ile oluşturulmuş bağlantılar çalışmaz. Ayrıca bu seçenek sadece şifreli bağlantıyı zorunlu kılar, kullanılacak TLS sürümünü belirlemez. TLS sürümü ayrıca “Minimum TLS Version” ayarıyla sınırlandırılmalıdır. Genel olarak bu seçeneğin etkinleştirilmesi, güvenlik, uyumluluk ve en iyi uygulamalar açısından tavsiye edilir. Böylece hem uygulamalarınız hem de üçüncü taraf araçlar, yalnızca güvenli kanal üzerinden storage hesabına erişmiş olur.
• Allow enabling anonymous access on individual containers: Bu seçenek, bir Azure Storage hesabındaki Blob service (container) düzeyinde anonim erişim izni verilip verilmeyeceğini kontrol eder. Varsayılan olarak yeni bir storage hesabında anonim erişim engellenmiştir. Ancak Allow enabling anonymous access on individual containers seçeneği Enabled durumuna getirilirse, yetkili yöneticiler belirli container’lar üzerinde public erişim açabilir.
• Enable Storage account key access: Bu seçenek, bir Azure Storage hesabına erişim sağlamak için hesap anahtarlarının (account keys) kullanılmasına izin verilip verilmeyeceğini belirler. Her Storage hesabı, iki adet erişim anahtarı (key1 ve key2) ile oluşturulur. Bu anahtarlar kullanılarak; uygulamalar, istemciler veya araçlar doğrudan tüm storage hizmetlerine (Blob, File, Queue, Table) erişebilir.
• Default to Microsoft Entra authorization in the Azure Portal: Bu seçenek, Azure Portal üzerinden bir Storage Account’a erişim yapılırken varsayılan olarak Microsoft Entra ID (Azure AD) tabanlı kimlik doğrulamasının kullanılmasını sağlar. Böylece kullanıcılar Portal’daki Storage Explorer (preview) veya diğer yönetim araçları üzerinden blob ve dosya paylaşımlarına erişmek istediklerinde, sistem otomatik olarak Entra kimliği ile oturum açar. Bu seçenek etkinleştirildiğinde kullanıcıların hesap anahtarlarını veya SAS (Shared Access Signature) bağlantılarını manuel olarak kullanmasına gerek kalmaz. Erişimler tamamen Microsoft Entra kimliği ve atanan RBAC (role-based access control) izinleri üzerinden yönetilir. Bu sayede hem güvenlik hem de erişim yönetimi merkezi bir noktadan kontrol edilmiş olur.

Create a storage account ekranında Advanced sekmesinde Security bölümü altında

Minumum TLS version : Bu seçenek, bir Azure Storage hesabına yapılacak tüm istemci bağlantılarında kullanılmasına izin verilen en düşük TLS (Transport Layer Security) sürümünü belirler. TLS, istemci ile Azure Storage arasında geçen verilerin şifrelenmesini ve güvenli aktarımını sağlayan protokoldür. Bu seçenek sayesinde, eski ve güvenlik açıkları bulunan TLS sürümleri (örneğin TLS 1.0 veya 1.1) kullanım dışı bırakılabilir. İstemciler, belirlenen sürümden daha düşük bir TLS sürümü ile bağlanmaya çalıştığında bağlantı otomatik olarak reddedilir. Minumum TLS sürümünü olarak Version 1.0 , Version 1.1 ve Version 1.2 yapılandırabilirsiniz. Ortamınızdaki güvenliği ve Azure Storage Account’unuza ait verileri kullanan uygulamanızın uyumluluk durumu açısından TLS 1.2 şeklinde yapılandırabilirsiniz.

Create a storage account ekranında Advanced sekmesinde Security bölümü altında

Permitted scope for copy operations (Preview): Bu seçenek, bir Azure Storage account üzerinde yapılan kopyalama işlemlerinde (copy operations) kaynak olarak hangi storage hesaplarının kullanılabileceğini belirler. Özellikle Blob copy veya AzCopy / Data Movement senaryolarında güvenlik sınırlarını daraltmak için tasarlanmıştır.

• From any storage accounts (default value): Varsayılan değerdir. Kopyalama işlemleri, herhangi bir Azure Storage hesabından yapılabilir. Kaynak storage hesabı farklı abonelikte, farklı Azure AD tenant’ında veya farklı bölgede olabilir. Esnek kullanım sağlar ancak güvenlik açısından en geniş kapsamdır.
• From storage accounts in the same Azure AD tenant: Kopyalama işlemleri sadece aynı Microsoft Entra ID (Azure AD) tenant’ı içindeki storage hesaplarından yapılabilir. Farklı bir tenant’a bağlı storage hesabı kaynak olarak kullanılamaz. Bu seçenek, kurumsal sınırlar içinde kalmayı sağlayarak dış tenant’lardan gelen riskleri engeller.
• From storage accounts that have a private endpoint to the same virtual network: Kopyalama işlemleri yalnızca aynı sanal ağ (VNet) içerisinde Private Endpoint ile bağlanmış storage hesaplarından yapılabilir. Bu, en katı güvenlik seviyesidir; yalnızca belirli bir VNet içindeki private endpoint bağlantıları üzerinden kopyalamaya izin verir. Ağ izolasyonu sağlandığı için, hem tenant dışı hem de tenant içindeki ama VNet dışında kalan storage hesaplarından kopyalama engellenir.

Create a storage account ekranında Advanced sekmesinde Hierarchical Namespace bölümü altında

Hierarchical Namespace: Hierarchical Namespace (HNS), Azure üzerinde özellikle Azure Data Lake Storage Gen2 hizmeti ile kullanılan bir özelliktir. HNS etkinleştirildiğinde, depolama alanı düz bir blob listesi şeklinde değil, klasör ve alt klasör mantığında hiyerarşik bir yapıya kavuşur. Bu sayede veriler dosya sistemi benzeri bir şekilde organize edilebilir ve yönetilebilir. HNS, veri yönetimini kolaylaştırdığı gibi güvenlik ve performans avantajı da sağlar. Dosya ve klasör düzeyinde ayrıntılı erişim kontrolleri (ACL ve RBAC) uygulanabilir. Örneğin, sadece belirli bir klasöre okuma ya da yazma yetkisi verilebilir. Ayrıca, toplu taşıma veya silme işlemleri klasör bazında yapılabildiği için işlem süreleri kısalır. Bunun yanı sıra, HDFS API uyumluluğu sayesinde Spark, Hive, Databricks gibi büyük veri ve analitik platformlarıyla doğrudan entegrasyon sağlanır. Bu seçenek, büyük hacimli verilerin işlendiği Big Data, makine öğrenmesi ve veri gölü (Data Lake) senaryoları için kritik bir avantaj sunar.

Create a storage account ekranında Advanced sekmesinde Access protocols bölümü altında

• Enable SFTP: Azure Storage üzerinde Secure File Transfer Protocol (SFTP) seçeneğinin etkinleştirmeyi ifade eder. Bu seçenek sayesinde, kullanıcılar verilerini Azure Blob Storage üzerinde güvenli bir şekilde SFTP protokolü aracılığıyla aktarabilir.
• Enable network file system v3: Enable Network File System v3 (NFS v3), Azure Storage üzerinde Linux ve Unix tabanlı istemcilerin Azure Blob verilerine doğrudan erişebilmesi için kullanılan bir seçenektir. Bu seçenek etkinleştirildiğinde, Azure Blob Storage üzerindeki veriler, sistemlerde yerel bir disk ya da dosya sistemi gibi mount edilerek kullanılabilir. NFS v3 sayesinde uygulamalar veya sunucular, herhangi bir ek SDK veya API entegrasyonuna gerek duymadan Azure Blob’a dosya sistemi tabanlı erişim sağlayabilir. Bu yaklaşım, özellikle büyük veri analizi, yüksek performanslı hesaplama (HPC) ve Linux uygulamaları için büyük kolaylık sunar. Ayrıca NFS v3, Azure Virtual Network üzerinden erişim kısıtlamaları yapılmasına imkan tanır ve güvenli bir dosya paylaşım ortamı sağlar. Bu sayede hem performans hem de güvenlik açısından verimli bir kullanım elde edilir.

Create a storage account ekranında Advanced sekmesinde Blob storage bölümü altında

Allow cross tenant replication: Azure Storage üzerinde bir depolama hesabındaki verilerin, farklı bir Microsoft Entra (Azure AD) tenant’ına ait depolama hesabına çoğaltılmasına (replication) izin veren bir seçenektir. Varsayılan olarak çoğaltma yalnızca aynı tenant içerisindeki depolama hesapları arasında yapılabilirken, bu seçenek etkinleştirildiğinde farklı tenant’lar arasında da veri replikasyonu mümkün hale gelir. Bu sayede farklı şirketler, bağlı ortaklıklar veya iş ortakları arasında güvenli bir şekilde veri paylaşımı yapılabilir. Ayrıca iş sürekliliği (BCDR) senaryolarında farklı tenant’lar üzerinde yedekleme veya felaket kurtarma çözümleri oluşturmak için de kullanılabilir.

Access Tier: Azure Blob Storage üzerinde verilerin kullanım sıklığına göre farklı maliyet ve erişim katmanlarında saklanmasını sağlar. Bu katmanlar, veriye erişim ihtiyaçlarına göre Hot, Cool ve Cold olarak üçe ayrılır.

• Hot Tier: Hot katman, sık erişilen (frequently accessed) veriler için tasarlanmıştır. Bu katmanda depolama maliyeti diğer katmanlara göre daha yüksekken, veriye erişim maliyeti düşüktür. Örneğin, aktif uygulama verileri, günlük raporlar veya sürekli kullanılan dosyalar için uygundur. Sık kullanılan veriler için (düşük erişim maliyeti, yüksek depolama maliyeti).
• Cool Tier: Cool katman, verilerin daha az sıklıkla erişildiği (infrequently accessed) senaryolarda tercih edilir. Depolama maliyeti Hot’a göre daha düşük, ancak erişim maliyeti daha yüksektir. 30 gün ve üzeri süreyle saklanacak verilere uygundur. Örneğin, yedekleme dosyaları veya arşivlenmiş raporlar için idealdir. Orta vadeli, nadir erişilen veriler için (düşük depolama, daha yüksek erişim maliyeti).
• Cold Tier: Cold katman, en düşük maliyetli depolama seçeneğidir ve çok nadiren erişilen veriler için uygundur. Erişim maliyeti en yüksek olan katmandır. 90 gün ve üzeri süreyle saklanacak verilerde kullanılır. Örneğin, uzun vadeli arşivler, yasal saklama zorunluluğu olan veriler veya nadiren ihtiyaç duyulan eski log dosyaları için tercih edilir. Uzun süre saklanan, çok nadiren erişilen veriler için (en düşük depolama, en yüksek erişim maliyeti).

Create a storage account ekranında Advanced sekmesinde Azure Files bölümü altında

Enable large files shares: Azure Storage üzerinde dosya paylaşım hizmetinin (Azure File Shares) kapasitesini genişletmeye yarayan bir seçenektir. Varsayılan olarak dosya paylaşımları belirli bir boyut ile sınırlıdır. Bu seçenek etkinleştirildiğinde ise tek bir dosya paylaşımının kapasitesi 100 TiB’e kadar artırılabilir. Büyük dosya paylaşımlarının etkinleştirilmesi, özellikle kurumsal uygulamalar, yedekleme senaryoları, yüksek hacimli veri depolama ve dosya tabanlı iş yükleri için avantaj sağlar. Kullanıcılar daha geniş ölçekli verilerini tek bir dosya paylaşımı üzerinde yönetebilir ve kapasite sınırlamalarına takılmadan çalışabilirler.

Create a storage account ekranında Advanced sekmesinde gerekli yapılandırma tamamladıktan sonra Next seçeneği ile Networking sekmesindeki yapılandırma ile devam ediyoruz.

Create a storage account ekranında Networking sekmesinde Public Access bölümü altında

Public network access seçeneği, Azure Storage üzerinde bulunan verilerin (özellikle Blob konteynerleri) internet üzerinden nasıl erişilebileceğini belirler. Bu seçenek, güvenlik politikalarına göre üç farklı şekilde yapılandırılabilir.

• Enable: Bu seçenek açık olduğunda, blob veya container bazında anonim erişim mümkündür. Yani kullanıcılar herhangi bir kimlik doğrulama olmadan blob içeriğine erişebilir. Genellikle halka açık içerikler (örneğin; web sitelerinde kullanılan görseller, belgeler) için tercih edilir. Ancak güvenlik riskleri taşıdığı için dikkatli kullanılmalıdır.
• Disable: Bu seçenek seçildiğinde, depolama hesabı veya blob container üzerinde anonim erişim tamamen kapatılır. Kullanıcıların verilere erişebilmesi için mutlaka kimlik doğrulama (örneğin Microsoft Entra ID, SAS token, Storage Account Key) gereklidir. Kritik verilerin korunması için varsayılan ve önerilen ayardır.
• Secure by Perimeter: Bu seçenek, ağ tabanlı erişim kısıtlamaları ile birlikte çalışır. Yani anonim erişim yalnızca belirli güvenli ağ sınırları (örneğin; Virtual Network, Private Endpoint veya belirlenmiş IP aralıkları) içinde mümkündür. Böylece halka tamamen açılmadan, sadece güvenli tanımlı çevrelerde anonim erişim sağlanabilir.

Public network access scope seçeneği, Azure Storage hesabına hangi ağlardan erişim sağlanabileceğini kontrol eden bir güvenlik ayarıdır. Bu seçenek, depolama hesabının internet üzerindeki erişim sınırlarını belirlemek için kullanılır ve iki temel seçenek sunar.

• Enable from all networks: Bu seçenek seçildiğinde, depolama hesabına herhangi bir kısıtlama olmadan tüm ağlardan (internet dahil) erişim sağlanabilir. Yönetim kolaylığı sunsa da, güvenlik açısından risklidir çünkü herkese açık bir erişim yolu bırakır. Yalnızca düşük güvenlik gerektiren test ortamları veya herkese açık veriler için önerilir.
• Enable from selected virtual networks and IP addresses: Bu seçenek etkinleştirildiğinde, depolama hesabına yalnızca tanımlanmış sanal ağlardan (VNet) ve izin verilen IP adreslerinden veya IP aralıklarından erişim sağlanabilir. Bu yöntem, erişimi sınırlandırarak güvenliği artırır. Genellikle üretim ortamlarında, kurumsal uygulamalarda ve kritik verilerin bulunduğu senaryolarda tercih edilir.

Create a storage account ekranında Networking sekmesinde Private endpoint bölümü altında

Private Endpoint: Azure Storage hesabına internet üzerinden değil, yalnızca Azure Virtual Network (VNet) içindeki özel IP adresi üzerinden erişim sağlanmasına imkan tanır. Bu sayede depolama hesabına yapılan tüm erişimler, genel internet yerine Azure’ın güvenli özel ağı üzerinden gerçekleştirilir. Bu seçenek, verilerin dış dünyaya kapatılarak yalnızca güvenilir ağlardan erişilmesini sağlar. Aynı zamanda güvenlik, izolasyon ve uyumluluk gereksinimlerini karşılamak için kritik bir çözümdür. Özellikle regülasyonlara tabi sektörlerde, hibrit bulut mimarilerinde ve kurumsal üretim ortamlarında tercih edilir.

Create a storage account ekranında Networking sekmesinde Network Routing bölümü altında

Network Routing, Azure Storage hesabına giden trafiğin hangi ağ yolunu kullanacağını belirleyen bir ayardır. Bu seçenek altında iki farklı yöntem bulunur:

• Microsoft Network Routing: Trafik, Microsoft’un global backbone ağı üzerinden yönlendirilir. Bu sayede daha düşük gecikme, daha kararlı performans ve daha güvenli bir bağlantı elde edilir. Özellikle üretim ortamlarında ve performansın kritik olduğu senaryolarda tercih edilir.
• Internet Routing: Trafik, genel internet üzerinden yönlendirilir. Bu yöntem bazı durumlarda maliyet avantajı sağlayabilir ancak gecikme süresi daha yüksek olabilir ve güvenlik açısından Microsoft ağı kadar güçlü değildir.

Create a storage account ekranında Networking sekmesinde gerekli yapılandırma tamamladıktan sonra Next seçeneği ile Data protection sekmesindeki yapılandırma ile devam ediyoruz.

Create a storage account ekranında Data protection sekmesinde Recovery bölümü altında

• Enable Point-in-Time Restore for Containers: Azure Storage üzerinde bir container içindeki verilerin belirli bir zamandaki durumuna geri döndürülmesini sağlayan bir seçenektir. Bu seçenek etkinleştirildiğinde, kullanıcılar yanlışlıkla yapılan silme, üzerine yazma veya istenmeyen değişiklikler gibi durumlarda container’ı geçmişte seçilen güvenli bir noktaya geri yükleyebilir. Bu sayede veriler beklenmedik hatalara, kullanıcı kaynaklı sorunlara veya uygulama tarafındaki toplu değişikliklere karşı korunur. Özellikle felaket kurtarma ve iş sürekliliği senaryolarında önemli bir güvenlik katmanı sunar.

Maximum restore point (days ago): Bu ayar, blob kapsayıcıları (containers) için Enable Point-in-Time Restore for Containers seçeneği etkinleştirildiğinde kullanılabilir. Bir kapsayıcı içindeki veriler, belirlenen maksimum gün sayısına kadar geçmişteki bir zamana geri yüklenebilir. Örneğin değer 6 gün olarak ayarlanırsa, kapsayıcıyı son 6 gün içerisindeki herhangi bir zamana geri döndürmek mümkündür. Bu seçenek, kullanıcı hataları, toplu silme işlemleri veya istenmeyen değişiklikler sonrası verileri geçmiş bir noktadan kurtarmak için kullanılır.

• Enable Soft Delete for Blobs: Azure Storage üzerinde silinen blob verilerinin belirli bir süre boyunca geri getirilebilmesini sağlayan bir veri koruma özelliğidir. Bu seçenek etkinleştirildiğinde, bir blob yanlışlıkla silinse veya üzerine yazılsa bile, sistem bu veriyi belirlenen saklama süresi boyunca tutmaya devam eder. Kullanıcılar bu süre içinde silinen veya değiştirilen blob’u kolayca geri yükleyebilir. Bu sayede veri kayıpları önlenir, kullanıcı hatalarına veya uygulama sorunlarına karşı ek güvenlik sağlanır. Özellikle üretim ortamlarında, kritik dosyaların korunması ve iş sürekliliğinin sağlanması için önerilen bir seçenektir.

Days to retain deleted blobs: Bu seçenek, Azure Storage üzerinde etkinleştirilen Soft Delete for Blobs seçeneğinin süresini belirler. Bir blob silindiğinde, tanımlanan gün sayısı boyunca kurtarılabilir durumda kalır. Bu süre zarfında istenirse geri yükleme yapılabilir, süre sona erdiğinde ise blob kalıcı olarak silinir. İş sürekliliği, kullanıcı hatalarına karşı veri koruma ve fidye yazılımlarına karşı ek güvenlik sağlamak amacıyla kullanılır.

• Enable soft delete for file shares: Bu seçenek etkinleştirildiğinde, Azure Storage üzerindeki bir dosya paylaşımı (file share) veya içindeki dosyalar silinse bile belirli bir süre boyunca kurtarılabilir. Tanımlanan gün sayısı içinde istenirse silinen veriler geri yüklenebilir. Bu seçenek, yanlışlıkla silme işlemlerine karşı koruma sağlar ve dosya paylaşım ortamlarında iş sürekliliği ile veri güvenliğini artırır.

Days to retain deleted file shares: Bu seçenek, Enable soft delete for file shares seçeneği etkinleştirildiğinde geçerlidir. Bir dosya paylaşımı (file share) veya içindeki dosyalar silindiğinde, tanımlanan gün sayısı boyunca kurtarılabilir durumda tutulur. Bu süre boyunca veriler geri yüklenebilir, süre sona erdiğinde ise kalıcı olarak silinir. Böylece kullanıcı hatalarına, fidye yazılım saldırılarına veya beklenmedik silme işlemlerine karşı ek koruma sağlanır.

Create a storage account ekranında Data protection sekmesinde Tracking bölümü altında

• Enable versioning for blobs: Bu seçenek etkinleştirildiğinde, Azure Storage üzerindeki her blob için yapılan değişiklikler veya üzerine yazma işlemleri otomatik olarak yeni bir sürüm (version) olarak saklanır. Böylece bir blobun önceki sürümlerine erişmek, eski bir versiyonu geri yüklemek veya farklı sürümler arasında karşılaştırma yapmak mümkün olur. Bu mekanizma, kullanıcı hataları veya istenmeyen güncellemeler karşısında veri koruması sağlar ve iş sürekliliğini destekler.
• Enable blob change feed: Bu seçenek etkinleştirildiğinde, Azure Storage hesabındaki bloblar üzerinde gerçekleşen tüm değişiklikler (oluşturma, güncelleme, silme gibi) bir değişiklik akışına (change feed) kaydedilir. Change feed sayesinde zaman içinde yapılan işlemler izlenebilir, geçmiş değişiklikler analiz edilebilir ve olay bazlı uygulamalar geliştirilebilir. Bu seçenek, denetim (audit), uyumluluk, hata ayıklama ve büyük veri analizi senaryolarında önemli bir avantaj sağlar.

• Keep all logs: Bu seçenek seçildiğinde, blob change feed tarafından oluşturulan tüm günlükler süresiz olarak saklanır. Böylece geçmişte yapılan her değişikliğe erişmek ve uzun dönemli analiz veya denetim (audit) senaryolarını desteklemek mümkün olur. Ancak bu yöntem depolama maliyetlerini artırabilir.
• Delete change feed logs after (in days): Bu seçenekte ise günlüklerin ne kadar süreyle tutulacağı gün cinsinden belirlenir. Örneğin 90 gün olarak ayarlanırsa, change feed günlükleri yalnızca 90 gün saklanır ve bu sürenin sonunda otomatik olarak silinir. Bu yöntem, maliyet optimizasyonu ve sadece yakın geçmişe odaklanan senaryolar için tercih edilir.

Create a storage account ekranında Data protection sekmesinde Access control bölümü altında

Enable version-level immutability support: Bu seçenek etkinleştirildiğinde, Azure Blob Storage üzerinde saklanan her bir blob sürümü (version) için değiştirilemezlik (immutability) politikaları uygulanabilir. Böylece belirlenen süre boyunca ilgili sürüm üzerinde silme, değiştirme veya üzerine yazma işlemleri engellenir. Version-level immutability sayesinde, yalnızca kapsayıcı (container) düzeyinde değil, tekil blob sürümleri düzeyinde de veri koruması sağlanır. Bu seçenek özellikle regülasyonlara uyumluluk, fidye yazılımına karşı koruma ve uzun süreli arşivleme senaryolarında kritik öneme sahiptir.

Create a storage account ekranında Data protection sekmesinde gerekli yapılandırma tamamladıktan sonra Next seçeneği ile Encryption sekmesindeki yapılandırma ile devam ediyoruz.

Create a storage account ekranında Encryption sekmesinde

Encryption type: Bu seçenek, Azure Storage üzerindeki verilerin nasıl şifreleneceğini (encrypt edileceğini) belirler. Varsayılan olarak, tüm veriler Microsoft tarafından yönetilen anahtarlarla (Microsoft-managed keys) otomatik olarak şifrelenir. Ancak ihtiyaç duyulursa, müşteri tarafından yönetilen anahtarlar (Customer-managed keys – CMK) da kullanılabilir. CMK seçeneğinde şifreleme anahtarları, Azure Key Vault veya Azure Key Vault Managed HSM üzerinde tutulur ve kurumun kontrolüne bırakılır. Böylece güvenlik, regülasyonlara uyumluluk ve şifreleme süreçlerinde daha fazla denetim sağlanır.

• Microsoft-managed keys: Varsayılan seçenektir. Verilerin şifrelenmesi için gerekli anahtarlar tamamen Microsoft tarafından oluşturulur, yönetilir ve saklanır. Kullanıcı herhangi bir ek yapılandırma yapmadan güvenli şifreleme sağlanır. Yönetim kolaylığı sunar fakat anahtar yönetimi üzerinde kontrol sınırlıdır.
• Customer-managed keys (CMK): Bu seçenekte şifreleme anahtarları kullanıcı tarafından yönetilir. Anahtarlar Azure Key Vault veya Azure Key Vault Managed HSM üzerinde saklanır. Böylece anahtarların oluşturulması, döndürülmesi (rotation), silinmesi gibi işlemler tamamen müşterinin kontrolündedir. Bu yöntem, regülasyonlara uyumluluk, kurumsal güvenlik politikaları ve özel güvenlik gereksinimleri için tercih edilir.

Enable support for customer-managed key: Bu seçenek etkinleştirildiğinde, Azure Storage hesabındaki verilerin şifrelenmesi için Microsoft’un varsayılan anahtarları yerine, müşteri tarafından yönetilen anahtarlar (Customer-managed keys – CMK) kullanılabilir. CMK anahtarları Azure Key Vault veya Azure Key Vault Managed HSM üzerinde tutulur ve anahtarların oluşturulması, döndürülmesi (rotation) ve silinmesi gibi işlemler tamamen müşteri kontrolündedir. Böylece güvenlik ve regülasyon uyumluluğu açısından daha fazla denetim sağlanır.

• Blobs and files only: Bu seçenek seçildiğinde, müşteri tarafından yönetilen anahtar desteği yalnızca Blob Storage ve Azure Files için etkinleştirilir. Tablo (tables) ve kuyruk (queues) servisleri bu kapsamın dışında kalır. Daha çok dosya tabanlı veri depolama ve paylaşım senaryoları için tercih edilir.
• All service types (blobs, files, tables and queues): Bu seçenekte müşteri tarafından yönetilen anahtar desteği, yalnızca blob ve dosyalarla sınırlı kalmaz; aynı zamanda tables ve queues servisleri için de etkinleşir. Böylece storage hesabındaki tüm hizmetler CMK ile şifrelenir ve kurumsal güvenlik politikaları açısından daha kapsamlı bir çözüm elde edilir.

Enable infrastructure encryption: Bu seçenek etkinleştirildiğinde, Azure Storage üzerindeki veriler için ek bir şifreleme katmanı devreye girer. Normalde tüm veriler Microsoft tarafından yönetilen veya müşteri tarafından yönetilen anahtarlarla şifrelenir. Ancak altyapı şifrelemesi (infrastructure encryption) etkinleştirildiğinde, veriler çift katmanlı (double encryption) ile korunur. İlk katman varsayılan şifreleme, ikinci katman ise altyapı düzeyinde ek bir şifreleme sağlar. Bu seçenek, özellikle regülasyonlara uyumluluk (örneğin finans veya sağlık sektörü gibi sıkı güvenlik standartlarına sahip alanlarda) ve yüksek güvenlik gerektiren senaryolar için tercih edilir. Çift şifreleme sayesinde, olası bir anahtar veya sistem açığının verilerin güvenliğini riske atması önlenmiş olur.

Create a storage account ekranında Encryption sekmesinde gerekli yapılandırma tamamladıktan sonra Next seçeneği ile Tags sekmesindeki yapılandırma ile devam ediyoruz.

Create a storage account ekranında Tags sekmesinde

Tags: Azure üzerinde Tags, kaynaklara eklenen anahtar–değer çiftleridir. Kaynakların sınıflandırılması, yönetilmesi ve maliyet takibi için kullanılır.

• Name: Tag’in anahtar kısmıdır; etikete neyi kategorize edeceğinizi söyler: Department, Environment, CostCenter, Project gibi. Anlamlı ve tekil olması önemlidir. Dept yerine Department, Env yerine Environment gibi kurum genelinde standart bir sözlük belirleyin. Büyük/küçük harf korunur, ancak arama/raporlama tarafında tutarlılık için tek stil (Örneğin. PascalCase ya da Title Case) kullanın. Kısa tutun; rapor ve filtrelerde kolay okunmalı (Örneğin. Owner, BackupTier, DRTier gibi).
• Value: Name ile eşleşen değeri taşır: Department = IT, Environment = Production, CostCenter = CC-1042, Project = CRM-Migration gibi. Mümkünse kontrollü sözlükler kullanın: Prod / Test / Dev ya da Production / Staging / Development gibi net ve sınırlı kümeler kullanın. Raporlamada gruplanabilirliği artırmak için tarih, bölge, iş birimi, sorumlu kişi/e-posta gibi alanları standartlaştırın (Örneğin. Region = WEU, Owner = [email protected]). Kişisel veriyi ve çok uzun serbest metni kaçının; değerleri kısa, makine-dostu ve raporlanabilir bırakın.
• Resource: Etiketin hangi kaynağa uygulanacağını belirtir: tekil bir kaynak (VM/Storage Account), bir Resource Group veya Subscription. Önemli not: Resource Group’a eklediğiniz tag’ler otomatik olarak içindeki kaynaklara geçmez. Kalıtım gerekirse Azure Policy (Append/Modify/Inherited tags) ile zorunlu kılın. Toplu atama yaparken portal, CLI veya Policy ile çoklu kaynak seçebilir; aynı Name–Value çifti birden fazla resource’a aynı anda uygulanabilir. Yaşam döngüsü düşünün: Kaynak taşınır/isim değiştirirse tag’ler güncel kalmalı; otomasyonda (bicep/ARM/Terraform) deklaratif olarak tanımlamak en temiz yöntemdir.

Create a storage account ekranında Tags sekmesinde gerekli yapılandırma tamamladıktan sonra Next seçeneği ile Review + create sekmesindeki yapılandırma ile devam ediyoruz.

Create a storage account ekranın da Review sekmesinde gerekli yapılandırma özeti bilgisini görüyoruz.

Create a storage account ekranında Review sekmesin de gerekli yapılandırma özeti bilgisini görüyoruz.

Create a storage account ekranında Review sekmesinde gerekli yapılandırma özeti bilgisini kontrol ettikten sonra Create diyerek Storage Account’ı oluşturma işlemini başlatıyoruz.

Create a storage account ekranında Review sekmesinde Initializing deployment uyarısını görüyoruz. Storage Account oluşturma süreci başlatıldı, kaynaklar hazırlanıyor.

Create a storage account ekranında Review sekmesinde Initializing deployment uyarısını görüyoruz. Storage Account için yapılandırmalar Azure’a gönderildi, kaynak oluşturma işlemi başlatılıyor.

Your deployment is complete ekranında Deployment succeeded uyarısını görüyoruz. Storage Account için yapılandırmaları (subscription, resource group, bölge, ağ ve güvenlik yapılandırmaları vb.) başarılı şekilde uygulanarak dağıtımın tamamlandığını gösterir. Bu aşamadan sonra kaynak (örneğin Storage Account) kullanıma hazır hale gelmiştir.

Your deployment is complete ekranında Next steps bölümü altında Go to resource seçeneği ya da uyarı bölümünde Go to resource seçeneği ile yapılandırmayı kontrol ediyoruz.

Your deployment is complete ekranında Next steps bölümü altında Go to resource seçeneğine tıklayarak yapılandırmayı kontrol ediyoruz.

bakicubukblobstorage isimli Storage Account yapılandırması görüyoruz.

 

Başka bir yazımızda görüşmek dileğiyle…