İş açısından kritik blob verilerini bir kez yazma, okuma (WORM) durumunda sabit depolama ile depolama
Azure Blob Depolama için sabit depolama özelliği kullanıcıların iş açısından kritik verileri WORM (Bir Kez Yazma Çok Kez Okuma) durumunda depolamasını 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 sabit depolama iki tür değiştirilemezlik ilkesi 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.
Yasal tutma ilkeleri: Yasal tutma, yasal tutma açıkça temizlenene kadar sabit verileri depolar. Yasal tutma ayarlandığında, nesneler oluşturulabilir ve okunabilir, ancak değiştirilemez veya silinemez.
Bu ilkeler birbiriyle aynı anda ayarlanabilir. Örneğin, bir kullanıcının hem zamana dayalı saklama ilkesi hem de aynı düzeyde ve aynı anda ayarlanmış bir yasal saklama ilkesi olabilir. Yazma işleminin başarılı olması için sürüm oluşturma özelliğinin etkin olması veya veriler üzerinde yasal saklama veya zamana bağlı saklama ilkesine sahip olmanız gerekir. Silme işleminin başarılı olması için veriler üzerinde yasal saklama veya zamana bağlı saklama ilkesi de bulunmamalıdır.
Aşağıdaki diyagramda, zamana bağlı saklama ilkelerinin ve yasal tutmaların etkin oldukları sırada yazma ve silme işlemlerini nasıl önlediği gösterilmektedir.
Sabit depolama şemsiyesinin altında iki özellik vardır: kapsayıcı düzeyinde WORM ve sürüm düzeyinde WORM. Kapsayıcı düzeyinde WORM ilkelerin yalnızca kapsayıcı düzeyinde ayarlanmasına izin verirken, sürüm düzeyi WORM ilkelerin hesap, kapsayıcı veya sürüm düzeyinde ayarlanmasına izin verir.
Bloblar için sabit depolama hakkında
Sabit depolama, sağlık kuruluşlarının, finans kurumlarının ve ilgili sektörlerin (özellikle aracı bayi kuruluşları) 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 sabit depolama, kullanıcıların dava veya iş kullanımı açısından kritik öneme sahip hassas bilgileri, ayrı tutma kaldırılana kadar istenen süre boyunca kurcalamaya karşı dayanıklı bir durumda depolamasına olanak tanır. 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 lütfen 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. Zamana bağlı saklama ilkesi ayarlandığında, istemciler blob oluşturabilir ve okuyabilir, ancak bunları değiştiremez veya silemez. Bekletme aralığının süresi dolduktan sonra bloblar silinebilir ancak üzerine yazılamaz.
Kapsam
Zamana bağlı saklama ilkesi aşağıdaki kapsamlarda yapılandırılabilir:
- Sürüm düzeyinde WORM ilkesi: Hesap, kapsayıcı veya sürüm düzeyinde zamana bağlı saklama ilkesi yapılandırılabilir. Hesap veya kapsayıcı düzeyinde yapılandırılmışsa ilgili hesap veya kapsayıcıdaki tüm bloblar tarafından devralınır. Bir kapsayıcıda yasal bir saklama varsa, aynı kapsayıcı için Sürüm düzeyinde WORM oluşturulamaz. Bunun nedeni sürümlerin yasal tutma nedeniyle oluşturulamamadır.
- 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. Tek tek bloblar kendi değiştirilemezlik ilkeleriyle yapılandırılamaz.
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 kilidi açılmış ilkeler
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 kilitleyip SEC 17a-4(f) ve diğer mevzuat uyumluluğuyla tamamen uyumlu hale getirmesini 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 kilidi açılmış bir ilkeyi 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. Kapsayıcı düzeyinde tanımlanan kilitli bir ilkenin ömrü boyunca etkin saklama süresine en fazla beş artışa 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
BLOBun SEC 17a-4(f) ve diğer mevzuat uyumluluğu için uyumlu sabit (yazma ve silme korumalı) durumda olması için zamana bağlı saklama ilkesi kilitlenmelidir. Microsoft, ilkeyi genellikle 24 saatten kısa bir süre içinde kilitlemenizi önerir. Kilidi açılmış durum değişmezlik koruması sağlarken, kilidi açılmış durumun kısa süreli test dışında herhangi bir amaçla kullanılması önerilmez.
Bekletme ilkesi denetim günlüğü
Zamana bağlı saklama ilkesi etkinleştirilmiş her kapsayıcı bir ilke denetim günlüğü sağlar. Denetim günlüğü, kilitli zamana bağlı saklama ilkeleri için yedi adede kadar zaman tabanlı bekletme komutu içerir. Günlük kaydı genellikle ilkeyi 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. Yasal düzenlemeler veya başka amaçlar için gerekli olabileceğinden, bu günlükleri kalıcı olarak depolamak kullanıcının sorumluluğundadır.
Sürüm düzeyinde zamana bağlı saklama ilkelerinde yapılan değişiklikler denetlenmiyor.
Yasal tutma
Yasal tutma, yasal araştırma amaçları veya genel koruma ilkeleri için uygulanabilen geçici bir değişmezlik ilkesidir. Yasal tutma, ayrı tutma açıkça temizlenene kadar blob verilerini Bir Kez Yazma, Çok Okuma (WORM) biçiminde depolar. Yasal tutma etkin olduğunda bloblar oluşturulabilir ve okunabilir, ancak değiştirilemez veya silinemez. Verilerin WORM durumunda tutulması gereken süre bilinmediğinde yasal tutma kullanın.
Kapsam
Yasal tutma ilkesi aşağıdaki kapsamlardan birinde yapılandırılabilir:
Sürüm düzeyinde WORM ilkesi: Hassas verilerin ayrıntılı yönetimi için tek bir blob sürümü düzeyinde yasal tutma yapılandırılabilir.
Kapsayıcı düzeyinde WORM ilkesi: Kapsayıcı düzeyinde yapılandırılan yasal tutma, bu kapsayıcıdaki tüm bloblar için geçerlidir. Tek tek bloblar kendi değiştirilemezlik ilkeleriyle yapılandırılamaz.
Etiketler
Kapsayıcı düzeyinde yasal tutma, tanımlayıcı dizeleri olarak hizmet veren bir veya daha fazla kullanıcı tanımlı alfasayısal etiketle ilişkilendirilmelidir. Örneğin, bir etiket bir servis talebi kimliği veya olay adı içerebilir.
Denetim günlüğü
Yasal tutma etkin olan her kapsayıcı bir ilke denetim günlüğü sağlar. Günlük kullanıcı kimliğini, komut türünü, zaman damgalarını ve yasal tutma etiketlerini 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. Yasal düzenlemeler veya başka amaçlar için gerekli olabileceğinden, bu günlükleri kalıcı olarak depolamak kullanıcının sorumluluğundadır.
Sürüm düzeyinde yasal tutmalarda 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 | İlkeler yalnızca kapsayıcı düzeyinde yapılandırılabilir. Kapsayıcıya yüklenen her nesne sabit ilke kümesini devralır. | İlkeler hesap, kapsayıcı veya blob düzeyinde yapılandırılabilir. Bir ilke hesap düzeyinde ayarlanırsa, bu hesaba yüklenen tüm bloblar ilkeyi devralır. Kapsayıcılarla aynı mantık izlenir. İlke birden çok düzeyde ayarlanırsa öncelik sırası her zaman Blob -> Kapsayıcı -> Hesap'tır. |
| Kullanılabilir ilke türleri | Kapsayıcı düzeyinde iki farklı tür ilke ayarlanabilir: Zamana bağlı saklama ilkeleri ve yasal tutmalar. | Hesap ve kapsayıcı düzeyinde yalnızca zamana bağlı saklama ilkeleri ayarlanabilir. Blob düzeyinde hem zamana bağlı saklama ilkeleri hem de yasal tutmalar ayarlanabilir. |
| Ö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/kapsayıcılar için etkinleştirme | Bu özellik mevcut kapsayıcılar için istediğiniz zaman etkinleştirilebilir. | Ayrıntı düzeyine bağlı olarak, bu özellik tüm mevcut hesaplar/kapsayıcılar için etkinleştirilmemiş olabilir. |
| Hesap/kapsayıcı silme | Zaman tabanlı saklama ilkesi bir kapsayıcıda kilitlendiğinde kapsayıcılar yalnızca boşsa silinebilir. | Sürüm düzeyi WORM bir hesap veya kapsayıcı düzeyinde etkinleştirildikten sonra, yalnızca boşsa silinebilir. |
| Azure Data Lake Storage desteği (hiyerarşik ad alanı etkinleştirilmiş depolama hesapları) | Kapsayıcı düzeyinde WORM ilkeleri, hiyerarşik ad alanına sahip hesaplarda desteklenir. | Sürüm düzeyi WORM ilkeleri henüz hiyerarşik ad alanına sahip hesaplarda desteklenmemektedir. |
Kapsayıcı düzeyinde WORM hakkında daha fazla bilgi edinmek için bkz . Kapsayıcı Düzeyinde WORM ilkeleri. Sürüm düzeyi WORM hakkında daha fazla bilgi edinmek için lütfen sürüm Düzeyi WORM ilkeleri'ne gidin.
Kapsayıcı düzeyi ile sürüm düzeyi WORM karşılaştırması
Aşağıdaki tablo, hangi worm ilkesi türünü kullanacağınıza 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 | Kapsayıcıya göre kategorilere ayırabileceğiniz belirli veri kümeleri için ilkeler ayarlamak istiyorsunuz. 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. Bazı veri gruplarının kapsayıcılar halinde kümelenebilmesi için, tüm blobların bu blobun senaryolarına göre ayrı bir saklama süresiyle depolanması gerekir veya kullanıcının karışık bir iş yükü vardır. 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 ilke ayarlamanız gerekmez. | Tüm verilerde veya hesaba göre çizilebilen büyük miktarda veri üzerinde ilkeler ayarlamak istiyorsunuz. Kapsayıcı düzeyinde WORM kullanıyorsanız 10.000 kapsayıcı sınırını aşmanız gerekecektir. |
| Sürüm oluşturmanın etkinleştirilmesi ilgi alanı | Hem maliyet nedeniyle hem de iş yükü başa çıkmak için çok sayıda ek sürüm oluşturacağından sürüm oluşturmayı etkinleştirmek istemezsiniz. | Ya sürüm oluşturma kullanmak istersiniz ya da kullanmak sizin için sorun olmaz. Sürüm oluşturmayı etkinleştirmezse, ayrı sürümler olarak sabit blobların düzenlemelerini veya üzerine yazmaları tutamazsınız. |
| 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'dadır ve artık sürüm düzeyinde WORM kullanabilir veya hiyerarşik ad alanı etkinleştirilmiş (Azure Data Lake Storage) hesaplarda sürüm oluşturmanın kullanılabilir olmasını beklemeyi tercih edersiniz. |
Erişim katmanları
Tüm blob erişim katmanları sabit depolamayı destekler. Blob KatmanıNı Ayarla işlemiyle blobun erişim katmanını 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. Etkin bir sanal makine için VHD diski depolayan bir sayfa blobu için değiştirilemezlik ilkesinin yapılandırılması, diske yazma engellendiği veya sürüm oluşturma etkinleştirildiğinde her yazma işleminin yeni bir sürüm olarak depolandığı için önerilmez. Microsoft, zaman tabanlı ilkeleri kilitlemeden önce belgeleri ayrıntılı bir şekilde incelemenizi ve senaryolarınızı test etmenizi önerir.
Blob geçici silme ile sabit depolama
Depolama hesabı için blob geçici silme yapılandırıldığında, yasal saklama veya zamana bağlı saklama ilkesinin geçerli olup olmadığına bakılmaksızın hesaptaki 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 geçici silmeyi etkinleştirir ve sonra bir değişmezlik ilkesi yapılandırırsanız, geçici silme bekletme ilkesi sona erdikten sonra geçici silme işlemi yapılmış olan tüm bloblar kalıcı olarak silinir. Geçici olarak silinen bloblar geçici silme saklama süresi boyunca geri yüklenebilir. Geçici olarak silinmemiş bir blob veya sürüm değiştirilemezlik ilkesi tarafından korunur ve zamana bağlı saklama ilkesinin süresi dolana veya yasal saklama 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 bkz . Azure Depolama blob envanteri.
Not
Bu hesapta sürüm düzeyi değişmezlik desteği etkinleştirildiyse veya stok ilkesinde tanımlanan hedef kapsayıcıda sürüm düzeyi değişmezlik desteği etkinleştirildiyse hesapta bir stok ilkesi yapılandıramazsınız.
İlkeleri büyük ölçekte yapılandırma
Bir depolama görevini, tanımladığınız bir dizi koşula göre birden çok depolama hesabında uygun ölçekte bir değişmezlik ilkesi yapılandırmak için kullanabilirsiniz. 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 düzeyinde WORM kullanıyorsanız, sürüm oluşturmayı etkinleştirdiğiniz ve ek sürümlerin depolanmasıyla ilişkili bir maliyet olduğundan fatura daha yüksek olabilir. 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 Bkz. Azure Depolama fiyatlandırma sayfası.
Blob sürümünde zamana bağlı saklama ilkesi veya yasal saklama oluşturma, değiştirme veya silme işlemleri yazma işlemi ücretine neden olur.
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
Bu özellik belirli bir noktaya geri yükleme ve son erişim izleme ile uyumsuzdur. Bu özellik müşteri tarafından yönetilen plansız yük devretme ile uyumludur, ancak son eşitleme zamanından sonra sabit ilkede yapılan değişiklikler (zamana dayalı bekletme ilkesini kilitleme, genişletme vb.) ikincil bölgeyle eşitlenmez. Yük devretme tamamlandıktan sonra, değişmezlik gereksinimlerinizle güncel olduğundan emin olmak için ikincil bölgede yapılan değişiklikleri yineleyebilirsiniz. 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. Kapsayıcıda etkin bir zamana bağlı saklama ilkesi veya yasal saklama varsa, bu düzen başarılı olmaz. Daha fazla ayrıntı 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.