Azure Data Lake Storage 2. Nesil'de erişim denetimi modeli

Data Lake Storage 2. Nesil 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.

Azure RBAC ve ACL'nin her ikisi de 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 sunar.

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.

Sahip, Katkıda Bulunan, Okuyucu ve Depolama Hesap 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 ABAC kullanarak Azure Depolama erişimini denetleme 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 2. Nesil'de 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.

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.

Güvenlik grupları

ACL girişinde atanan sorumlu olarak her zaman Microsoft Entra güvenlik gruplarını kullanın. Tek tek kullanıcıları veya hizmet sorumlularını doğrudan atama fırsatına direnin. 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 sağlar. 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.

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

Grupları kullanarak abonelik başına rol ataması sayısı üst sınırını ve dosya veya dizin başına en fazla ACL girdisi sayısını aşma olasılığınız daha düşüktür. Aşağıdaki tabloda bu sınırlar açıklanmaktadır.

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

Azure Data Lake Storage 2. Nesil ayrıca Kimlik doğrulaması için Paylaşılan Anahtar ve SAS yöntemleri. 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 2. Nesil'de Erişim denetim listeleri (ACL'ler).