Azure Data Lake Storage'da erişim denetimi modeli

Data Lake Storage aşağıdaki yetkilendirme mekanizmalarını destekler:

• Paylaşılan Anahtar yetkilendirmesi
• Paylaşılan erişim imzası (SAS) yetkilendirmesi
• Rol tabanlı erişim denetimi (Azure RBAC)
• Öznitelik tabanlı erişim denetimi (Azure ABAC)
• Erişim denetim listeleri (ACL)

Paylaşılan Anahtar ve SAS yetkilendirmesi , bir kullanıcıya (veya uygulamaya) Microsoft Entra Kimliği'nde bir kimliğe sahip olmasını gerektirmeden erişim verir. Bu iki kimlik doğrulama biçimiyle Azure RBAC, Azure ABAC ve ACL'lerin hiçbir etkisi yoktur.

Hem Azure RBAC hem de ACL, kullanıcının (veya uygulamanın) Microsoft Entra ID'de bir kimliğe sahip olmasını gerektirir. Azure RBAC, depolama hesabındaki tüm verilere okuma veya yazma erişimi gibi depolama hesabı verilerine "kaba" erişim vermenizi sağlar. Azure ABAC, koşullar ekleyerek RBAC rol atamalarını iyileştirmenize olanak tanır. Örneğin, belirli bir etikete sahip bir depolama hesabındaki tüm veri nesnelerine okuma veya yazma erişimi vekleyebilirsiniz. ACL'ler, belirli bir dizine veya dosyaya yazma erişimi gibi "ayrıntılı" erişim vermenizi sağlar.

Bu makalede Azure RBAC, ABAC ve ACL'ler ile sistemin depolama hesabı kaynakları için yetkilendirme kararları almak üzere bunları nasıl değerlendirdiğinden bahsedildi.

Rol tabanlı erişim denetimi (Azure RBAC)

Azure RBAC, güvenlik sorumlularına izin kümeleri uygulamak için rol atamalarını kullanır. Güvenlik sorumlusu, Microsoft Entra Kimliği'nde tanımlanan bir kullanıcı, grup, hizmet sorumlusu veya yönetilen kimliği temsil eden bir nesnedir. İzin kümesi, bir güvenlik sorumlusuna bir depolama hesabındaki tüm verilere veya kapsayıcıdaki tüm verilere okuma veya yazma erişimi gibi "ayrıntılı" bir erişim düzeyi verebilir.

Aşağıdaki roller, bir güvenlik sorumlusunun depolama hesabındaki verilere erişmesine izin verir.

Rol	Açıklama
Depolama Blob Verileri Sahibi	Blob depolama kapsayıcılarına ve verilerine tam erişim. Bu erişim, güvenlik sorumlusunun sahibine bir öğe ayarlamasına ve tüm öğelerin ACL'lerini değiştirmesine izin verir.
Depolama Blobu Veri Katılımcısı	Blob depolama kapsayıcılarına ve bloblarına erişimi okuma, yazma ve silme. Bu erişim, güvenlik sorumlusunun bir öğenin sahipliğini ayarlamasına izin vermez, ancak güvenlik sorumlusuna ait öğelerin ACL'sini değiştirebilir.
Depolama Blob Verileri Okuyucusu	Blob depolama kapsayıcılarını ve bloblarını okuma ve listeleme.

Sahip, Katkıda Bulunan, Okuyucu ve Depolama Hesabı Katkıda Bulunanı gibi roller, bir güvenlik sorumlusunun depolama hesabını yönetmesine izin verir, ancak bu hesaptaki verilere erişim sağlamaz. Ancak, bu roller (Okuyucu hariç) verilere erişmek için çeşitli istemci araçlarında kullanılabilen depolama anahtarlarına erişim elde edebilir.

Öznitelik tabanlı erişim denetimi (Azure ABAC)

Azure ABAC, belirli eylemler bağlamındaki öznitelikleri temel alan rol atama koşulları ekleyerek Azure RBAC üzerinde derleme yapar. Rol atama koşulu, daha iyi erişim denetimi sağlamak için isteğe bağlı olarak rol atamanıza ekleyebileceğiniz ek bir denetimdir. Koşulları kullanarak belirli kaynaklara erişimi açıkça reddedemezsiniz.

Azure Depolama'ya erişimi denetlemek için Azure ABAC kullanma hakkında daha fazla bilgi için bkz. Azure rol atama koşullarını kullanarak Azure Blob Depolama erişimi yetkilendirme.

Erişim denetim listeleri (ACL’ler)

ACL'ler, dizinlere ve dosyalara "daha ayrıntılı" erişim düzeyi uygulamanıza olanak sağlar. ACL, bir dizi ACL girdisi içeren bir izin yapısıdır. Her ACL girişi, güvenlik sorumlusunu bir erişim düzeyiyle ilişkilendirir. Daha fazla bilgi edinmek için bkz . Azure Data Lake Storage'da erişim denetim listeleri (ACL'ler).

İzinler nasıl değerlendirilir?

Güvenlik sorumlusu tabanlı yetkilendirme sırasında izinler aşağıdaki diyagramda gösterildiği gibi değerlendirilir.

1. Azure, sorumlu için bir rol ataması olup olmadığını belirler.
   • Rol ataması varsa, rol atama koşulları (2) daha sonra değerlendirilir.
   • Aksi takdirde, ACL'ler (4) daha sonra değerlendirilir.
2. Azure, herhangi bir ABAC rol atama koşulu olup olmadığını belirler.
   • Koşul yoksa erişim verilir.
   • Koşullar varsa, istekle eşleşip eşleşmediğini görmek için değerlendirilir (3).
3. Azure, tüm ABAC rol atama koşullarının isteğin öznitelikleriyle eşleşip eşleşmediğini belirler.
   • Bunların tümü eşleşirse erişim verilir.
   • Bunlardan en az biri eşleşmezse, ACL'ler (4) daha sonra değerlendirilir.
4. Rol atamaları ve koşulları değerlendirildikten sonra erişim açıkça verilmediyse, ACL'ler değerlendirilir.
   • ACL'ler istenen erişim düzeyine izin verirse erişim verilir.
   • Aksi takdirde erişim reddedilir.

Önemli

Erişim izinlerinin sistem tarafından değerlendirilme şekli nedeniyle, bir rol ataması ve koşulları tarafından zaten verilmiş olan erişimi kısıtlamak için ACL kullanamazsınız. Bunun nedeni sistemin önce Azure rol atamalarını ve koşullarını değerlendirmesi ve atamanın yeterli erişim izni vermesi durumunda ACL'lerin yoksayılmış olmasıdır.

Aşağıdaki diyagramda üç yaygın işlem için izin akışı gösterilmektedir: dizin içeriğini listeleme, bir dosyayı okuma ve dosya yazma.

İzinler tablosu: Azure RBAC, ABAC ve ACL'leri birleştirme

Aşağıdaki tabloda, güvenlik sorumlusunun İşlem sütununda listelenen işlemleri gerçekleştirebilmesi için Azure rollerini, koşullarını ve ACL girdilerini nasıl birleştirebileceğiniz gösterilmektedir. Bu tabloda, kurgusal dizin hiyerarşisinin her düzeyini temsil eden bir sütun gösterilir. Kapsayıcının kök dizini ()/ için bir sütun, Oregon adlı bir alt dizin, Oregon dizininin Portland adlı alt dizini ve Portland dizininde Data.txt adlı bir metin dosyası vardır. Bu sütunlarda gösterilmesi, izin vermek için gereken ACL girişinin kısa biçimli gösterimleridir. İşlemi gerçekleştirmek için bir ACL girişi gerekli değilse sütunda Yok (Geçerli değil) görüntülenir.

İşlem	Atanan Azure rolü (koşullu veya koşulsuz)	/	Oregon/	Portland/	Data.txt
Okuma Data.txt	Depolama Blobu Veri Sahibi	Yok	Yok	Yok	Yok
	Depolama Blobu Veri Katılımcısı	Yok	Yok	Yok	Yok
	Depolama Blob Verileri Okuyucusu	Yok	Yok	Yok	Yok
	Hiçbiri	--X	--X	--X	R--
Data.txt ekle	Depolama Blobu Veri Sahibi	Yok	Yok	Yok	Yok
	Depolama Blobu Veri Katılımcısı	Yok	Yok	Yok	Yok
	Depolama Blob Verileri Okuyucusu	--X	--X	--X	-W-
	Hiçbiri	--X	--X	--X	RW-
Data.txt sil	Depolama Blobu Veri Sahibi	Yok	Yok	Yok	Yok
	Depolama Blobu Veri Katılımcısı	Yok	Yok	Yok	Yok
	Depolama Blob Verileri Okuyucusu	--X	--X	-WX	Yok
	Hiçbiri	--X	--X	-WX	Yok
Data.txt oluşturma	Depolama Blobu Veri Sahibi	Yok	Yok	Yok	Yok
	Depolama Blobu Veri Katılımcısı	Yok	Yok	Yok	Yok
	Depolama Blob Verileri Okuyucusu	--X	--X	-WX	Yok
	Hiçbiri	--X	--X	-WX	Yok
Liste/	Depolama Blobu Veri Sahibi	Yok	Yok	Yok	Yok
	Depolama Blobu Veri Katılımcısı	Yok	Yok	Yok	Yok
	Depolama Blob Verileri Okuyucusu	Yok	Yok	Yok	Yok
	Hiçbiri	R-X	Yok	Yok	Yok
Liste /Oregon/	Depolama Blobu Veri Sahibi	Yok	Yok	Yok	Yok
	Depolama Blobu Veri Katılımcısı	Yok	Yok	Yok	Yok
	Depolama Blob Verileri Okuyucusu	Yok	Yok	Yok	Yok
	Hiçbiri	--X	R-X	Yok	Yok
Liste /Oregon/Portland/	Depolama Blobu Veri Sahibi	Yok	Yok	Yok	Yok
	Depolama Blobu Veri Katılımcısı	Yok	Yok	Yok	Yok
	Depolama Blob Verileri Okuyucusu	Yok	Yok	Yok	Yok
	Hiçbiri	--X	--X	R-X	Yok

Not

Azure Depolama Gezgini bir kapsayıcının içeriğini görüntülemek için güvenlik sorumlularının Microsoft Entra Id kullanarak Depolama Gezgini oturum açması ve (en azından) kapsayıcının kök klasörüne (R--) okuma erişimine (\R)sahip olması gerekir. Bu izin düzeyi, kök klasörün içeriğini listeleme olanağı sağlar. Kök klasörün içeriğinin görünür olmasını istemiyorsanız, onlara Okuyucu rolü atayabilirsiniz. Bu rolle, hesaptaki kapsayıcıları listeleyebilecek, ancak kapsayıcı içeriğini listeleyemezler. Daha sonra ACL'leri kullanarak belirli dizinlere ve dosyalara erişim vekleyebilirsiniz.

Güvenlik grupları

ACL girişinde atanan sorumlu olarak her zaman Microsoft Entra güvenlik gruplarını kullanın. Tek kullanıcıları veya hizmet sorumlularını doğrudan atama fırsatını kullanmamayı tercih edin. Bu yapıyı kullanmak, ACL'leri dizin yapısının tamamına yeniden uygulamanıza gerek kalmadan kullanıcı veya hizmet sorumluları eklemenize ve kaldırmanıza olanak tanır. Bunun yerine, kullanıcıları ve hizmet sorumlularını uygun Microsoft Entra güvenlik grubuna ekleyebilir veya kaldırabilirsiniz.

Grupları ayarlamanın birçok farklı yolu vardır. Örneğin, sunucunuz tarafından oluşturulan günlük verilerini tutan /LogData adlı bir dizininiz olduğunu düşünün. Azure Data Factory (ADF) verileri bu klasöre alır. Hizmet mühendisliği ekibinden belirli kullanıcılar günlükleri karşıya yükler ve bu klasörün diğer kullanıcılarını yönetir ve çeşitli Databricks kümeleri bu klasördeki günlükleri analiz eder.

Bu etkinlikleri etkinleştirmek için bir LogsWriter grup ve LogsReader grup oluşturabilirsiniz. Ardından, izinleri aşağıdaki gibi atayabilirsiniz:

• LogsWriter Grubu izinlerle rwx /LogData dizininin ACL'sine ekleyin.
• LogsReader Grubu izinlerle r-x /LogData dizininin ACL'sine ekleyin.
• ADF LogsWriters için hizmet sorumlusu nesnesini veya Yönetilen Hizmet Kimliği'ni (MSI) gruba ekleyin.
• Hizmet mühendisliği ekibindeki LogsWriter kullanıcıları gruba ekleyin.
• Databricks için hizmet sorumlusu nesnesini veya MSI'sini LogsReader gruba ekleyin.

Hizmet mühendisliği ekibindeki bir kullanıcı şirketten ayrılırsa, yalnızca gruptan LogsWriter kaldırabilirsiniz. Bu kullanıcıyı bir gruba eklemediyseniz, bunun yerine o kullanıcı için ayrılmış bir ACL girdisi eklediyseniz, bu ACL girdisini /LogData dizininden kaldırmanız gerekir. Girdiyi /LogData dizininin tüm dizin hiyerarşisindeki tüm alt dizinlerden ve dosyalardan da kaldırmanız gerekir.

Grup oluşturmak ve üye eklemek için bkz . Temel grup oluşturma ve Microsoft Entra Id kullanarak üye ekleme.

Önemli

Azure Data Lake Storage 2. Nesil, güvenlik gruplarını yönetmek için Microsoft Entra Id'ye bağlıdır. Microsoft Entra Id, belirli bir güvenlik sorumlusu için grup üyeliğini 200'den azla sınırlamanızı önerir. Bu öneri, Microsoft Entra uygulamaları içinde bir güvenlik sorumlusunun grup üyeliği bilgilerini sağlayan JSON Web Belirteçlerinin (JWT) sınırlandırılmasından kaynaklanır. Bu sınırın aşılması, Data Lake Storage 2. Nesil ile ilgili beklenmeyen performans sorunlarına neden olabilir. Daha fazla bilgi edinmek için bkz . Microsoft Entra Id kullanarak uygulamalar için grup taleplerini yapılandırma.

Azure rol atamaları ve ACL girişleriyle ilgili sınırlar

Grupları kullandığınızda, abonelik başına maksimum rol ataması sayısını ve dosya veya dizin başına maksimum ACL girişi sayısını aşma olasılığınız daha düşüktür. Aşağıdaki tabloda bu sınırlar açıklanmaktadır.

Mekanizma	Kapsam	Sınırlar	Desteklenen izin düzeyi
Azure RBAC	Depolama hesapları, kapsayıcılar. Abonelik veya kaynak grubu düzeyinde çapraz kaynak Azure rol atamaları.	Abonelikte 4000 Azure rol ataması	Azure rolleri (yerleşik veya özel)
ACL	Dizin, dosya	Dosya başına ve dizin başına 32 ACL girdisi (etkin olarak 28 ACL girdisi). Erişim ve varsayılan ACL’ler kendi 32 ACL girdisi sınırına sahiptir.	ACL izni

Paylaşılan Anahtar ve Paylaşılan Erişim İmzası (SAS) yetkilendirmesi

Azure Data Lake Storage, kimlik doğrulaması için Paylaşılan Anahtar ve SAS yöntemlerini de destekler. Bu kimlik doğrulama yöntemlerinin bir özelliği, arayanla ilişkili kimlik olmaması ve bu nedenle güvenlik sorumlusu izin tabanlı yetkilendirme gerçekleştirilememesidir.

Paylaşılan Anahtar söz konusu olduğunda, çağıran etkili bir şekilde "süper kullanıcı" erişimi kazanır; bu da veriler, sahip ayarlama ve ACL'leri değiştirme gibi tüm kaynaklardaki tüm işlemlere tam erişim anlamına gelir.

SAS belirteçleri, belirtecin parçası olarak izin verilen izinleri içerir. SAS belirtecine dahil edilen izinler tüm yetkilendirme kararlarına etkili bir şekilde uygulanır, ancak ek ACL denetimi yapılmaz.

Sonraki adımlar

Erişim denetim listeleri hakkında daha fazla bilgi edinmek için bkz . Azure Data Lake Storage'da erişim denetim listeleri (ACL'ler).