Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Azure Blob Depolama için değişmez depolama özelliği, iş açısından kritik verileri WORM (Write Once, Read Many) durumunda depolamanızı sağlar. WORM durumundayken, kullanıcı tarafından belirtilen bir aralık için veriler değiştirilemez veya silinemez. Blob verileri için değişmezlik ilkelerini yapılandırarak verilerinizi üzerine yazma ve silme işlemlerine karşı koruyabilirsiniz.
Azure Blob Depolama için değişmez depolama, iki tür değişmezlik ilkesini destekler:
Zamana dayalı saklama ilkeleri: Kullanıcılar zamana bağlı saklama ilkesiyle, belirli bir aralıkta verileri depolamak için ilkeler ayarlayabilir. Zamana bağlı saklama ilkesi ayarlandığında, nesneler oluşturulabilir ve okunabilir, ancak değiştirilemez veya silinemez. Bekletme süresi dolduktan sonra nesneler silinebilir ancak üzerine yazılamaz.
Hukuki bekletme politikaları: Hukuki bekletme, hukuki bekletme kaldırılana kadar değiştirilemez verileri saklar. Yasal tutma ayarlandığında, nesneler oluşturulabilir ve okunabilir, ancak değiştirilemez veya silinemez.
Bu poliçeleri bir arada ayarlayabilirsiniz. Örneğin, hem zaman bazlı tutma politikası hem de yasal bir tutma politikası aynı seviyede ve aynı zamanda ayarlanabilir. Bir yazma işleminin başarılı olması için, ya sürümlendirme etkin olmalı ya da veriler üzerinde ne yasal saklama ne de zamana dayalı bir saklama politikası bulunmalıdır. Silme işleminin başarılı olması için, veriler üzerinde yasal bir tutma veya zaman bazlı saklama politikası olmamalıdır.
Aşağıdaki diyagram, zaman bazlı saklama politikaları ve yasal tutmaların yazma ve silme işlemlerini yürürlükteyken nasıl engellediğini göstermektedir.
Sabit depolama şemsiyesinin altında iki özellik vardır: kapsayıcı düzeyinde WORM ve sürüm düzeyinde WORM. Konteyner düzeyinde WORM, politikaları yalnızca konteyner seviyesinde ayarlamanıza izin verirken, sürüm düzeyindeki WORM politikaları hesap, konteyner veya sürüm seviyesinde ayarlamanıza olanak tanır.
Bloblar için sabit depolama hakkında
Değişmez depolama, sağlık kuruluşları, finans kurumları ve ilgili sektörlerin (özellikle aracı kurum-bayi organizasyonları) verileri güvenli bir şekilde depolamasına yardımcı olur. Sabit depolama, kritik verileri değişiklik veya silmeye karşı korumak için herhangi bir senaryoda kullanılabilir.
Tipik kullanım alanları şunlardır:
Mevzuat uyumluluğu: Azure Blob Depolama için sabit depolama, kuruluşların SEC 17a-4(f), CFTC 1.31(d), FINRA ve diğer düzenlemeleri ele alınmasına yardımcı olur.
Güvenli belge saklama: Bloblar için sabit depolama alanı, hesap yönetim ayrıcalıklarına sahip kullanıcılar tarafından bile verilerin herhangi bir kullanıcı tarafından değiştirilmemesini veya silinemediğini güvence altına alır.
Yasal tutma: Bloblar için değişmez depolama, dava veya iş kullanımı için kritik olan hassas bilgileri istediğiniz süre boyunca müdahaleye dayanıklı bir durumda saklamanızı sağlar, ta ki tutma kaldırılana kadar. Bu özellik yalnızca yasal kullanım örnekleriyle sınırlı değildir, aynı zamanda olay tetikleyicilerine veya şirket ilkesine göre verileri koruma gereksiniminin gerekli olduğu olay tabanlı ayrı tutma veya kurumsal kilit olarak da düşünülebilir.
Mevzuata uyumluluk
Microsoft, bloblar için sabit depolamayı değerlendirmek ve finansal hizmetler sektörüne özgü gereksinimlerle uyumluluğunu değerlendirmek için kayıt yönetimi ve bilgi idaresi konusunda uzmanlaşmış önde gelen bir bağımsız değerlendirme firması olan Cohasset Associates'i elinde tutmaktadır. Cohasset, blobları WORM durumunda tutmak için kullanıldığında sabit depolamanın CFTC Kuralı 1.31(c)-(d), FINRA Kuralı 4511 ve SEC Kuralı 17a-4(f) ile ilgili depolama gereksinimlerini karşıladığını doğrulamıştır. Microsoft, finansal kurumlar için kayıt saklama konusunda küresel olarak en açıklayıcı kılavuzu temsil ettiğinden bu kurallar kümesini hedeflemektedir.
Cohasset raporu Microsoft Hizmet Güven Merkezi'nde kullanılabilir. Azure Güven Merkezi, Microsoft'un uyumluluk sertifikaları hakkında ayrıntılı bilgiler içerir. MICROSOFT'tan WORM değişmezliği uyumluluğuyla ilgili bir kanıtlama mektubu istemek için Azure Desteği'ne başvurun.
Zamana bağlı saklama ilkeleri
Zamana bağlı saklama ilkesi blob verilerini belirtilen bir aralık için WORM biçiminde depolar. Zaman bazlı bir saklama politikası kurduğunuzda, müşteriler bloblar oluşturabilir ve okuyabilir, ancak onları değiştirebilir veya silemez. Saklama aralığı dolduğunda, lekeler silinebilir ancak üzerine yazılamaz.
Kapsam
Zaman bazlı bir saklama politikasını aşağıdaki alanlarda yapılandırabilirsiniz:
- Sürüm düzeyinde WORM politikası: Hesap, konteyner veya sürüm seviyesinde zaman bazlı bir saklama politikası yapılandırın (hesapta sürüm etkinleştirilmelidir). Bunu hesap veya konteyner düzeyinde yapılandırırsanız, ilgili hesapta veya konteynerdeki tüm blob'lar ilkeyi devralır. Bir konteyner üzerinde yasal bir tutma varsa, aynı konteyner için sürüm seviyesinde WORM oluşturamazsınız. Bu kısıtlama, yasal tutma nedeniyle versiyonların oluşturulmasını engellemektedir.
- Kapsayıcı düzeyinde WORM ilkesi: Kapsayıcı düzeyinde yapılandırılan zamana bağlı saklama ilkesi, bu kapsayıcıdaki tüm bloblar için geçerlidir. Bireysel blobları kendi değişmezlik politikalarıyla yapılandırmak mümkün değil.
Zamana bağlı bir ilke için bekletme aralığı
Zamana bağlı saklama ilkesi için en düşük saklama aralığı bir gündür ve en fazla 146.000 gündür (400 yıl). Zamana bağlı saklama ilkesi yapılandırdığınızda, etkilenen nesneler etkin saklama süresi boyunca sabit durumda kalır. Nesneler için geçerli saklama süresi, blob oluşturma süresi ile kullanıcı tarafından belirtilen bekletme aralığı arasındaki farka eşittir. İlkenin bekletme aralığı uzatılabildiğinden sabit depolama, etkin saklama süresini hesaplamak için kullanıcı tarafından belirtilen saklama aralığının en son değerini kullanır.
Örneğin, bir kullanıcının beş yıllık saklama aralığına sahip zamana dayalı bir bekletme ilkesi oluşturduğunu varsayalım. Testblob1 kapsayıcısında mevcut bir blob bir yıl önce oluşturulduğundan testblob1 için geçerli saklama süresi dört yıldır. Kapsayıcıya testblob2 adlı yeni bir blob yüklendiğinde, testblob2 için etkin saklama süresi oluşturulduğu zamandan beş yıl sonra olur.
Kilitli ve açık politikalar
Zamana bağlı saklama ilkesini ilk kez yapılandırdığınızda, ilkenin kilidi test amacıyla açılır. Testi tamamladığınızda, ilkeyi kilitleyerek SEC 17a-4(f) ve diğer düzenlemelerle tam uyumluluk sağlayabilirsiniz.
Hem kilitli hem de kilitsiz ilkeler silme ve üzerine yazma işlemlerine karşı koruma sağlar. Ancak, bekletme süresini kısaltarak veya genişleterek kilitli olmayan bir politikayı değiştirebilirsiniz. Kilidi açılmış bir ilkeyi de silebilirsiniz. Kilitli zamana bağlı saklama ilkesini silemezsiniz. Saklama süresini uzatabilirsiniz, ancak azaltamazsınız. Konteyner düzeyinde tanımlanan kilitli bir politikanın ömrü boyunca etkin saklama süresine en fazla beş artış yapılmasına izin verilir. Blob sürümü için yapılandırılmış bir ilke için geçerlilik süresine yapılan artışların sayısıyla ilgili bir sınır yoktur.
Önemli
Blob'un SEC 17a-4(f) ve diğer mevzuat uyumluluğu için değiştirilemez (yazma ve silme korumalı) durumda olması için zamana bağlı saklama ilkesi kilitlenmelidir. Microsoft, politikayı makul bir süre içinde, genellikle 24 saatten kısa bir sürede kilitlemenizi önerir. Kilitsiz durum değişmezlik koruması sağlarken, kilitsiz durumu kısa süreli test dışında kullanmanızı önermiyoruz.
Saklama politikası denetim kaydı
Zaman bazlı saklama ilkesi için etkinleştirilmiş her kap bir ilke denetim günlüğü sağlar. Denetim günlüğü, kilitli zamana dayalı saklama ilkeleri için yedi adede kadar zaman tabanlı saklama komutu içerir. Günlük kaydı genellikle politikayı kilitledikten sonra başlar. Günlük girişleri kullanıcı kimliğini, komut türünü, zaman damgalarını ve bekletme aralığını içerir. Denetim günlüğü, SEC 17a-4(f) mevzuat yönergelerine uygun olarak ilkenin kullanım ömrü boyunca saklanır.
Azure Etkinlik günlüğü, tüm yönetim hizmeti etkinliklerinin daha kapsamlı bir günlüğünü sağlar. Azure kaynak günlükleri veri işlemleri hakkındaki bilgileri korur. Bu kayıtları düzenleyici veya diğer amaçlar için gerekli olabilecek şekilde sürekli saklamakla sorumlusunuz.
Sürüm düzeyinde zamana bağlı saklama ilkelerinde yapılan değişiklikler denetlenmiyor.
Yasal saklama emirleri
Yasal tutma, yasal araştırma amaçları veya genel koruma ilkeleri için uygulanabilen geçici bir değişmezlik ilkesidir. Yasal bekletme, blob verisini, bekletme açıkça kaldırılana kadar Write Once, Read Many (WORM) biçiminde saklar. Yasal tutma etkin olduğunda bloblar oluşturulabilir ve okunabilir, ancak değiştirilemez veya silinemez. Verilerin WORM durumunda ne kadar süreyle tutulması gerektiği bilinmediğinde yasal bekletme kullanın.
Kapsam
Yasal tutma ilkesi aşağıdaki kapsamlardan birinde yapılandırılabilir:
Sürüm düzeyinde WORM politikası: Hassas verilerin ayrıntılı yönetimi için bireysel bir blob sürüm seviyesinde yasal bir tutma yapılandırılabilir (hesapta sürüm etkinleştirilmelidir).
Kapsayıcı düzeyinde WORM ilkesi: Kapsayıcı düzeyinde yapılandırılan hukuki bekletme, bu kapsayıcıdaki tüm bloblar için geçerlidir. Tek tek bloblar kendi değiştirilemezlik ilkeleriyle yapılandırılamaz.
Etiketler
Konteyner düzeyindeki bir yasal saklamayı, tanımlayıcı dizeler olarak işlev gören, kullanıcı tarafından tanımlanmış bir veya daha fazla alfasayısal etiketle ilişkilendirmelisiniz. Örneğin, bir etikette bir vaka kimliği veya olay adı bulunabilir.
Denetim günlüğü
Yasal tutma altında olan her kapsayıcı, bir politika denetim günlüğü sağlar. Günlük, kullanıcı kimliğini, komut türünü, zaman belirteçlerini ve yasal etiketleri içerir. Denetim günlüğü, SEC 17a-4(f) mevzuat yönergelerine uygun olarak ilkenin kullanım ömrü boyunca saklanır.
Azure Etkinlik günlüğü, tüm yönetim hizmeti etkinliklerinin daha kapsamlı bir günlüğünü sağlar. Azure kaynak günlükleri veri işlemleri hakkındaki bilgileri korur. Bu kayıtları düzenleyici veya diğer amaçlar için gerekli olabilecek şekilde sürekli saklamakla sorumlusunuz.
Sürüm düzeyinde yasal saklamalarda yapılan değişiklikler denetlenmiyor.
Sabit depolama özelliği seçenekleri
Aşağıdaki tabloda kapsayıcı düzeyi WORM ile sürüm düzeyi WORM arasındaki farkların dökümü gösterilmektedir:
| Kategori | Kapsayıcı düzeyinde WORM | Sürüm düzeyi WORM |
|---|---|---|
| İlke ayrıntı düzeyi | Politikaları yalnızca konteyner seviyesinde yapılandırın. Konteynere yüklediğiniz her nesne, değişmez politika setini devralır. | Politikaları hesap, konteyner veya blob seviyesinde yapılandırın. Hesap düzeyinde bir ilke ayarlarsanız, bu hesaba yüklediğiniz tüm bloblar bu ilkeyi devralır. Kapsayıcılarla aynı mantık izlenir. Bir politikayı birden fazla seviyede belirlerseniz, öncelik sırası her zaman Blob -> Konteyner -> Hesap olur. |
| Kullanılabilir ilke türleri | Konteyner seviyesinde iki farklı politika türü belirleyin: Zaman bazlı saklama politikaları ve yasal tutmalar. | Hesap ve konteyner düzeyinde sadece zaman bazlı saklama politikaları belirleyin. Blob düzeyinde, hem zaman bazlı tutma politikaları hem de yasal tutma önlemleri belirleyin. |
| Özellik bağımlılıkları | Bu özelliğin çalışması için başka hiçbir özellik önkoşul veya gereksinim değildir. | Sürüm oluşturma, bu özelliğin kullanılması için bir önkoşuldur. |
| Mevcut hesaplar ve konteynerler için etkinleştirme | Bu özelliği mevcut konteynerler için istediğiniz zaman etkinleştirin. | Detaylılık seviyesine bağlı olarak, bu özellik mevcut tüm hesaplar ve konteynerler için etkinleştirilmeyebilir. |
| Hesap/kapsayıcı silme | Bir konteynere zaman bazlı saklama politikası kilitledikten sonra, konteynerler sadece boş ise silebilirsiniz. | Hesap veya konteyner seviyesinde sürüm seviyesindeki WORM'u etkinleştirdikten sonra, sadece boş olsalar silebilirsiniz. |
| Azure Data Lake Storage desteği (hiyerarşik ad alanı etkinleştirilmiş depolama hesapları) | Hiyerarşik isim alanı olan hesaplarda konteyner düzeyinde WORM politikalarını destekliyor. | Sürüm düzeyindeki WORM politikaları, hiyerarşik bir isim alanı olan hesaplarda henüz desteklenmemektedir. |
Konteyner düzeyinde WORM hakkında daha fazla bilgi edinmek için Konteyner düzeyinde WORM politikalarına bakınız. Sürüm düzeyindeki WORM hakkında daha fazla bilgi edinmek için sürüm düzeyindeki WORM politikalarına bakınız.
Konteyner seviyesi vs. sürüm seviyesi WORM
Aşağıdaki tablo, hangi tür WORM politikasını kullanmanız gerektiğine karar vermenize yardımcı olur.
| Ölçütler | Kapsayıcı düzeyinde WORM Kullanımı | Sürüm düzeyinde WORM Kullanımı |
|---|---|---|
| Veri düzenleme | Belirli veri setleri için politikalar ayarlamak istersiniz, bunları konteynere göre kategorize edebilirsiniz. Bu kapsayıcıdaki tüm verilerin aynı süre boyunca WORM durumunda tutulması gerekir. | Nesneleri bekletme sürelerine göre gruplandıramazsınız. Tüm bloblar, o blobun senaryolarına göre ayrı bir saklama süresiyle saklanmalıdır, aksi takdirde karışık bir iş yükü olur, böylece bazı veri grupları konteynerlere kümelenebilirken, diğerleri kümelemez. Aynı hesap içinde kapsayıcı düzeyi ilkeleri ve blob düzeyi ilkeleri de ayarlamak isteyebilirsiniz. |
| Sabit ilke gerektiren veri miktarı | Hesap başına 10.000'den fazla kapsayıcıda politika belirlemeniz gerekmez. | Tüm veriler veya hesap bazında ayırabileceğiniz büyük miktarda veri için politikalar belirlemek istersiniz. Biliyorsunuz ki, kapsayıcı düzeyinde WORM kullanıyorsanız 10.000 kapsayıcı sınırını aşmanız gerekecektir. |
| Sürüm oluşturmayı etkinleştirmeye ilgi | Ya maliyet nedeniyle ya da iş yükü çok sayıda ekstra sürüm yaratacağı için bunlarla uğraşmamak adına sürüm oluşturmayı etkinleştirmek istemezsiniz. | Ya sürüm oluşturmayı kullanmak istersiniz ya da kullanmayı umursamazsınız. Biliyorsun ki sürüm etkinleştirmezsen, değişmez bloblara yapılan düzenlemeleri veya üzerine yazmaları ayrı sürümler olarak tutamazsın. |
| Depolama konumu (Blob Depolama ile Data Lake Storage karşılaştırması) | İş yükünüz tamamen Azure Data Lake Storage'a odaklanmıştır. Hiyerarşik ad alanı özelliği etkin olmayan bir hesabı kullanmaya hemen ilginiz veya planınız yok. | İş yükünüz, hiyerarşik ad alanı özelliği etkinleştirilmiş olmayan bir hesaptaki Blob Depolama'da bulunuyorsa şu anda sürüm düzeyinde WORM kullanabilir, veya hiyerarşik ad alanının etkin olduğu (Azure Data Lake Storage) hesaplar için sürümlemenin kullanılabilir olmasını beklemek isteyebilirsiniz. |
Erişim katmanları
Tüm blob erişim katmanları değişmez depolamayı destekler. Bir blobun erişim seviyesini Set Blob Tier işlemiyle değiştirebilirsiniz. Daha fazla bilgi için bkz Blob verileri için erişim katmanları.
Yedeklilik yapılandırmaları
Tüm yedeklilik yapılandırmaları sabit depolamayı destekler. Yedeklilik yapılandırmaları hakkında daha fazla bilgi için bkz . Azure Depolama yedekliliği.
Önerilen blob türleri
Microsoft, çoğunlukla blok blobları ve ekleme blobları için değişmezlik ilkeleri yapılandırmanızı önerir. Aktif bir sanal makine için VHD disk depolayan bir sayfa blobu için değişmezlik politikası yapılandırmak önerilmez; çünkü diske yazmalar engelleniyor veya sürüm etkinleştirildiğinde her yazma yeni bir sürüm olarak saklanıyor. Microsoft, zaman tabanlı ilkeleri kilitlemeden önce belgeleri ayrıntılı bir şekilde incelemenizi ve senaryolarınızı test etmenizi önerir.
Değiştirilemez depolama ve blob yumuşak silme
Bir depolama hesabı için blob soft dele'yi yapılandırdığınızda, bu durum yasal bir tutma veya zaman bazlı saklama politikası olup olmamasından bağımsız olarak hesap içindeki tüm bloblar için geçerlidir. Microsoft, herhangi bir değişmezlik ilkesi uygulanmadan önce ek koruma için geçici silmenin etkinleştirilmesini önerir.
Blob için geçici silmeyi etkinleştirir ve ardından bir değiştirilemezlik ilkesi yapılandırırsanız, daha önce geçici olarak sildiğiniz blob’lar, geçici silme için tanımlanan saklama süresi dolduğunda kalıcı olarak silinir. Geçici olarak silinmiş blob'ları geçici silme saklama süresi boyunca geri yükleyebilirsiniz. Henüz geçici olarak silmediğiniz bir blob veya sürüm, değişmezlik ilkesinin koruması altındadır ve süre tabanlı saklama ilkesinin süresi dolana ya da yasal bekletme kaldırılana kadar geçici olarak silinemez.
Değişmezlik ilkelerini izlemek için blob envanteri kullanma
Azure Depolama blob envanteri, depolama hesaplarınızdaki kapsayıcılara ve bunların içindeki bloblara, anlık görüntülere ve blob sürümlerine genel bir bakış sağlar. Bir kaynağın bir değişmezlik ilkesi yapılandırılmış olup olmadığı dahil olmak üzere blobların ve kapsayıcıların özniteliklerini anlamak için blob envanter raporunu kullanabilirsiniz.
Blob envanteri etkinleştirdiğinizde Azure Depolama günlük olarak bir envanter raporu oluşturur. Rapor, iş ve uyumluluk gereksinimleri için verilerinize genel bir bakış sağlar.
Blob envanteri hakkında daha fazla bilgi için Azure Depolama blob envanteri'ne bakınız.
Not almak
Bir hesapta sürüm düzeyinde değişmezlik desteği etkinleştirilmişse veya envanter politikasında tanımladığınız hedef konteynerde sürüm düzeyinde değişmezlik desteği etkinleştiriliyorsa, bir hesapta envanter politikası yapılandıramazsınız.
İlkeleri büyük ölçekte yapılandırma
Bir depolama görevi olarak, belirlediğiniz bir dizi koşula göre birden fazla depolama hesabında ölçekli olarak değişmezlik politikalarını yapılandırmak için kullanılabilir. Depolama görevi, Azure Depolama Eylemleri'nde kullanılabilen bir kaynaktır; birden çok depolama hesabında milyonlarca nesne üzerinde ortak veri işlemleri gerçekleştirmek için kullanabileceğiniz sunucusuz bir çerçevedir. Daha fazla bilgi edinmek için bkz. Azure Depolama Eylemleri nedir?
Fiyatlandırma
Sabit depolama alanı kullanmak için ek kapasite ücreti yoktur. Sabit veriler, değişebilir verilerde olduğu gibi fiyatlanır. Sürüm seviyesinde WORM kullanıyorsanız, fatura daha yüksek olabilir çünkü sürüm etkinleştirdiniz ve ekstra sürümlerin depolanması için bir maliyet vardır. Daha fazla bilgi için sürüm oluşturma fiyatlandırma ilkesini gözden geçirin. Azure Blob Depolama fiyatlandırma ayrıntıları için Azure Depolama fiyatlandırma sayfasına bakın.
Blob sürümünde zamana bağlı saklama ilkesi veya yasal saklama oluşturma veya silme işlemi, yazma işlemi ücretine neden olur. Zaman bazlı bir saklama politikasını değiştirmek (ya kilitlemek ya da uzatmak) Diğer işlemler ücreti ile sonuçlanır. İşlem ücretleri hakkında daha fazla bilgi için Operasyonlar ve Veri Transferi bölümünü inceleyebilirsiniz.
Faturanızı ödemezseniz ve hesabınızda etkin bir zamana bağlı saklama ilkesi varsa, normal veri saklama ilkeleri Microsoft ile yaptığınız sözleşmenin hüküm ve koşullarında belirtildiği şekilde uygulanır. Genel bilgi için bkz . Microsoft'ta veri yönetimi.
Özellik desteği
Önemli
Bu özellik anlık geri yükleme ve son erişim takibi ile uyumlu değildir.
Bu özellik, müşteri tarafından yönetilen plansız yedekleme ile uyumludur. Ancak, son senkronizasyon zamanından sonra değişmez politikada yaptığınız değişiklikler (örneğin zamana dayalı bir saklama politikasını kilitlemek veya uzatmak) ikincil bölgeye senkronize edilmez. Yük devretme tamamlandıktan sonra, ikincil bölgede değişiklikleri yeniden uygulayabilir ve bölgenin değişmezlik gereksinimlerinizi karşılayacak şekilde güncel olduğundan emin olabilirsiniz. Ağ Dosya Sistemi (NFS) 3.0 protokolü veya SSH Dosya Aktarım Protokolü (SFTP) etkinleştirilmiş hesaplarda değişmezlik ilkeleri desteklenmez.
URL'ye SQL Yedekleme gibi bazı iş yükleri bir blob oluşturur ve sonra buna ekler. Bir konteynerin aktif zaman bazlı tutma politikası veya yasal bir tutma politikası varsa, bu model başarılı olmaz. Daha fazla bilgi için bkz Korumalı ekleme blob yazmalarına izin ver.
Daha fazla bilgi için bkz. Azure Depolama hesaplarında Blob Depolama özelliği desteği.