Azure Data Lake Storage 2. Nesil'deki erişim denetim listeleri (ACL'ler)

Azure Data Lake Storage, hem Azure rol tabanlı erişim denetimini (Azure RBAC) hem de POSIX benzeri erişim denetim listelerini (ACL) destekleyen bir erişim denetimi modeli uygular. Bu makalede Data Lake Storage'daki erişim denetim listeleri açıklanmaktadır. Azure RBAC'yi ACL'lerle birleştirme ve sistemin yetkilendirme kararları almak için bunları nasıl değerlendirdiğini öğrenmek için bkz . Azure Data Lake Storage'da erişim denetimi modeli.

ACL'ler hakkında

Bir güvenlik sorumlusunu dosyalar ve dizinler için erişim düzeyiyle ilişkilendirebilirsiniz. Her ilişkilendirme, erişim denetimi listesinde (ACL) bir girdi olarak yakalanır. Depolama hesabınızdaki her dosya ve dizinin bir erişim denetimi listesi vardır. Bir güvenlik sorumlusu bir dosya veya dizin üzerinde işlem yapmaya çalıştığında, ACL denetimi güvenlik sorumlusunun (kullanıcı, grup, hizmet sorumlusu veya yönetilen kimlik) işlemi gerçekleştirmek için doğru izin düzeyine sahip olup olmadığını belirler.

ACL'leri ayarlama

Dosya ve dizin düzeyi izinlerini ayarlamak için aşağıdaki makalelerden birine bakın:

ACL türleri

İki tür erişim denetimi listesi vardır: erişim ACL'leri ve varsayılan ACL'ler.

Erişim ACL'leri bir nesneye erişimi denetler. Hem dosyalar hem de dizinler erişim ACL'lerine sahiptir.

Varsayılan ACL'ler, bu dizin altında oluşturulan alt öğeler için erişim ACL'lerini belirleyen bir dizinle ilişkili ACL şablonlarıdır. Dosyaların varsayılan ACL'leri yoktur.

Hem erişim ACL'leri hem de varsayılan ACL'ler aynı yapıya sahiptir.

İzin düzeyleri

Kapsayıcıdaki dizinler ve dosyalar üzerindeki izinler Okuma, Yazma ve Yürütme'dir ve aşağıdaki tabloda gösterildiği gibi dosya ve dizinlerde kullanılabilir:

İzinlerin kısaltmaları

RWX, Okuma + Yazma + Yürütme için kullanılır. Okuma=4, Yazma=2 ve Yürütme=1 olup toplamları izinleri temsil eden daha da kısaltılmış bir sayısal biçim mevcuttur. Bazı örnekler aşağıda verilmiştir.

İzin devralma

Data Lake Storage tarafından kullanılan POSIX stili modelde, bir öğenin izinleri öğenin kendisinde depolanır. Başka bir deyişle, alt öge oluşturulduktan sonra izinler ayarlandıysa bir ögenin izinleri üst ögelerden devralınamaz. İzinler yalnızca alt ögeler oluşturulmadan önce üst ögelerde varsayılan izinler ayarlanmışsa devralınır.

ACL izinleriyle ilgili yaygın senaryolar

Aşağıdaki tabloda, bir güvenlik sorumlusunun İşlem sütununda listelenen işlemleri gerçekleştirmesini sağlamak için gereken ACL girişleri 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.

Dosyaları ve dizinleri silme

Önceki tabloda gösterildiği gibi, dizin izinleri düzgün ayarlandığı sürece dosyayı silmek için dosya üzerinde yazma izinleri gerekli değildir. Ancak, bir dizini ve tüm içeriğini silmek için üst dizinin Yazma + Yürütme izinlerine sahip olması gerekir. Silinecek dizin ve içindeki tüm dizinler Okuma + Yazma + Yürütme izinleri gerektirir.

Kullanıcılar ve kimlikler

Her dosya ve dizin şu kimlikler için ayrı izinlere sahiptir:

• Sahip olan kullanıcı
• Sahip olan grup
• Adlandırılmış kullanıcılar
• Adlandırılmış gruplar
• Adlandırılmış hizmet sorumluları
• Adlandırılmış yönetilen kimlikler
• Diğer tüm kullanıcılar

Kullanıcıların ve grupların kimlikleri Microsoft Entra kimlikleridir. Bu nedenle, aksi belirtilmediği sürece, bir kullanıcı Data Lake Storage bağlamında bir Microsoft Entra kullanıcısına, hizmet sorumlusuna, yönetilen kimliğe veya güvenlik grubuna başvurabilir.

Süper kullanıcı

Süper kullanıcı, tüm kullanıcılardan en fazla haklara sahiptir. Süper kullanıcı:

• Tüm dosya ve klasörlerde RWX İzinlerine sahiptir.

• Herhangi bir dosya veya klasörün izinlerini değiştirebilir.

• Herhangi bir dosya veya klasörün sahibi olan kullanıcıyı ya da grubu değiştirebilir.

Paylaşılan Anahtar, Hesap SAS veya Hizmet SAS'sı kullanılarak bir kapsayıcı, dosya veya dizin oluşturulduysa, sahip ve sahip olan grup olarak $superuserayarlanır.

Sahip olan kullanıcı

Öğeyi oluşturan kullanıcı otomatik olarak öğenin sahibi olan kullanıcıdır. Sahip olan kullanıcı şunları yapabilir:

• Sahip olunan bir dosyanın izinlerini değiştirme.
• Sahip olan kullanıcı aynı zamanda hedef grubun bir üyesi oldukça, sahip olunan bir dosyanın sahibi olan grubunu değiştirme.

Sahip olan grup

POSIX ACL'lerinde, her kullanıcı bir birincil grupla ilişkilendirilir. Örneğin, "Alice" kullanıcısı "finans" grubuna ait olabilir. Alice birden çok gruba da ait olabilir, ancak bir grup her zaman birincil grup olarak belirlenir. POSIX'te, Alice bir dosya oluşturduğunda, bu dosyanın sahibi olan grup birincil grubuna ayarlanır ve bu durumda "finans" olur. Sahip olan grup, diğer kullanıcılar/gruplar için atanmış izinlere benzer şekilde davranır.

Yeni bir dosya veya dizin için sahip olan grubu atama

• Olay 1: Kök dizini /. Bu dizin, Data Lake Storage kapsayıcısı oluşturulduğunda oluşturulur. Bu durumda sahip olan grup, OAuth kullanılarak yapıldıysa kapsayıcıyı oluşturan kullanıcıya ayarlanır. Kapsayıcı Paylaşılan Anahtar, Hesap SAS veya Hizmet SAS'i kullanılarak oluşturulduysa, sahip ve sahip olan grup olarak $superuserayarlanır.
• Olay 2 (diğer her durumda): Yeni bir öğe oluşturulduğunda, sahip olan grup üst dizinden kopyalanır.

Sahip olan grubu değiştirme

Sahip olan grup aşağıdakiler tarafından değiştirilebilir:

• Herhangi bir süper kullanıcı.
• Sahip olan kullanıcı aynı zamanda hedef grubun üyesi ise sahip olan kullanıcı.

İzinler nasıl değerlendirilir?

Kimlikler aşağıdaki sırayla değerlendirilir:

1. Süper kullanıcı
2. Sahip olan kullanıcı
3. Adlandırılmış kullanıcı, hizmet sorumlusu veya yönetilen kimlik
4. Sahip olan grup veya adlandırılmış grup
5. Diğer tüm kullanıcılar

Bu kimliklerden birden fazlası bir güvenlik sorumlusu için geçerliyse, ilk kimlikle ilişkili izin düzeyi verilir. Örneğin, bir güvenlik sorumlusu hem sahip olan kullanıcı hem de adlandırılmış kullanıcıysa, sahip olan kullanıcıyla ilişkili izin düzeyi uygulanır.

Adlandırılmış grupların tümü birlikte değerlendirilir. Bir güvenlik sorumlusu birden fazla adlandırılmış grubun üyesiyse, sistem istenen izin verilene kadar her grubu değerlendirir. Adlandırılmış gruplardan hiçbiri istenen izni sağlamazsa, sistem diğer tüm kullanıcılarla ilişkilendirilmiş izinlere göre bir isteği değerlendirmek üzere hareket eder.

Aşağıdaki sahte kod, depolama hesapları için erişim denetimi algoritmasını temsil eder. Bu algoritma, kimliklerin değerlendirilme sırasını gösterir.

def access_check( user, desired_perms, path ) :
  # access_check returns true if user has the desired permissions on the path, false otherwise
  # user is the identity that wants to perform an operation on path
  # desired_perms is a simple integer with values from 0 to 7 ( R=4, W=2, X=1). User desires these permissions
  # path is the file or directory
  # Note: the "sticky bit" isn't illustrated in this algorithm

  # Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask isn't used.
  entry = get_acl_entry( path, OWNER )
  if (user == entry.identity)
      return ( (desired_perms & entry.permissions) == desired_perms )

  # Handle the named users. Note that mask IS used.
  entries = get_acl_entries( path, NAMED_USER )
  for entry in entries:
      if (user == entry.identity ) :
          mask = get_mask( path )
          return ( (desired_perms & entry.permissions & mask) == desired_perms)

  # Handle named groups and owning group
  member_count = 0
  perms = 0
  entries = get_acl_entries( path, NAMED_GROUP | OWNING_GROUP )
  mask = get_mask( path )
  for entry in entries:
    if (user_is_member_of_group(user, entry.identity)) :
        if ((desired_perms & entry.permissions & mask) == desired_perms)
            return True

  # Handle other
  perms = get_perms_for_other(path)
  mask = get_mask( path )
  return ( (desired_perms & perms & mask ) == desired_perms)

Maske

Erişim Denetimi Algoritması'nda gösterildiği gibi, maske adlandırılmış kullanıcılar, sahip olan grup ve adlandırılmış gruplar için erişimi sınırlar.

Yeni bir Data Lake Storage kapsayıcısı için kök dizinin ("/") erişim ACL'si maskesi varsayılan olarak dizinler için 750 ve dosyalar için 640'tır . Aşağıdaki tabloda bu izin düzeylerinin sembolik gösterimi gösterilmektedir.

Dosyalar, yalnızca depo sistemindeki dosyalarla ilgisiz olduğundan X bit'i almaz.

Maske, çağrı başına olarak belirtilebilir. Bu, kümeler gibi farklı tüketen sistemlerin dosya işlemleri için farklı etkili maskelere sahip olmasını sağlar. Belirli bir istekte bir maske belirtilirse, varsayılan maskeyi tamamen geçersiz kılar.

Yapışkan bit

Yapışkan bit, POSIX kapsayıcısının daha gelişmiş bir özelliğidir. Data Lake Storage bağlamında yapışkan bitin gerekli olması pek olası değildir. Özetle, yapışkan bit bir dizinde etkinleştirildiyse, alt öğe yalnızca alt öğenin sahibi, dizin sahibi veya Superuser ($superuser) tarafından silinebilir veya yeniden adlandırılabilir.

Yapışkan bit, Azure portalında gösterilmez. Yapışkan bit ve nasıl ayarlanacağı hakkında daha fazla bilgi edinmek için bkz . Yapışkan bit Data Lake Storage nedir?.

Yeni dosya ve dizinlerde varsayılan izinler

Mevcut bir dizin altında yeni bir dosya veya dizin oluşturulduğunda, üst dizindeki varsayılan ACL şunu belirler:

• Bir alt dizinin varsayılan ACL'si ve erişim ACL'si.
• Bir alt dosyanın erişim ACL’si (dosyaları varsayılan ACL’ye sahip değildir).

umask

Varsayılan ACL oluşturulurken, varsayılan ACL'nin ilk izinlerini belirlemek için erişim ACL'sine umask uygulanır. Üst dizinde varsayılan bir ACL tanımlanmışsa, umask etkin bir şekilde yoksayılır ve bunun yerine bu ilk değerleri tanımlamak için üst dizinin varsayılan ACL'si kullanılır.

umask, üst dizinlerde kullanıcıya, sahip olan gruba ve diğer kullanıcılara sahip olmak için RWX değeri içeren 9 bitlik bir değerdir.

Azure Data Lake Storage için umask değeri 007 olarak ayarlanmış sabit bir değerdir. Bu değer şu şekilde çevrilir:

SSS

ACL desteğini etkinleştirmem gerekiyor mu?

Hayır Hiyerarşik Ad Alanı (HNS) özelliği AÇIK olduğu sürece ACL'ler aracılığıyla erişim denetimi bir depolama hesabı için etkinleştirilir.

HNS KAPALI durumdaysa Azure RBAC yetkilendirme kuralları geçerli olmaya devam eder.

ACL'leri uygulamanın en iyi yolu nedir?

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.

Azure RBAC ve ACL izinleri nasıl değerlendirilir?

Sistemin depolama hesabı kaynakları için yetkilendirme kararları almak üzere Azure RBAC ve ACL'leri nasıl değerlendirdiğini öğrenmek için bkz . İzinler nasıl değerlendirilir?

Azure rol atamaları ve ACL girişleri için sınırlar nelerdir?

Aşağıdaki tabloda, Azure RBAC kullanarak "ayrıntılı" izinleri (depolama hesapları veya kapsayıcılar için geçerli olan izinler) ve "ayrıntılı" izinleri (dosyalar ve dizinler için geçerli olan izinler) yönetmek için ACL'leri kullanırken dikkate alınacak sınırların özet bir görünümü sağlanır. ACL atamaları için güvenlik gruplarını kullanın. 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.

Data Lake Storage, Azure RBAC devralmayı destekliyor mu?

Azure rol atamaları devralır. Atamalar abonelik, kaynak grubu ve depolama hesabı kaynaklarından kapsayıcı kaynağına doğru akar.

Data Lake Storage ACL devralmayı destekliyor mu?

Varsayılan ACL'ler, yeni alt alt dizinler ve üst dizin altında oluşturulan dosyalar için ACL'leri ayarlamak için kullanılabilir. Mevcut alt öğelerin ACL'lerini güncelleştirmek için, istenen dizin hiyerarşisi için ACL'leri yinelemeli olarak eklemeniz, güncelleştirmeniz veya kaldırmanız gerekir. Yönergeler için bu makalenin ACL'leri ayarlama bölümüne bakın.

Bir dizini ve içeriğini özyinelemeli olarak silmek için hangi izinler gereklidir?

• Çağıranın 'süper kullanıcı' izinleri vardır,

Or

• Üst dizinin Yazma + Yürütme izinleri olmalıdır.
• Silinecek dizin ve içindeki tüm dizinler Okuma + Yazma + Yürütme izinleri gerektirir.

Bir dosyanın veya dizinin sahibi kimdir?

Bir dosya veya dizinin oluşturucusu sahibi olur. Kök dizin söz konusu olduğunda bu, kapsayıcıyı oluşturan kullanıcının kimliğidir.

Hangi grup, oluşturulurken bir dosyanın veya dizinin sahibi olan grup olarak ayarlanır?

Sahip olan grup, yeni dosya veya dizinin oluşturulduğu üst dizinin sahip olan grubundan kopyalanır.

Bir dosyanın sahibiyim ama ihtiyacım olan RWX izinlerine sahip değilim. Ne yapmalıyım?

Sahip olan kullanıcı kendisine gerekli olan her türlü RWX iznini vermek için dosyanın izinlerini değiştirebilir.

Neden bazen ACL'lerde GUID'leri görüyorum?

Girdi bir kullanıcıyı temsil ediyorsa ve bu kullanıcı artık Microsoft Entra'da yoksa GUID gösterilir. Bu durum genellikle kullanıcı şirketten ayrıldığında veya hesabı Microsoft Entra Id'de silindiğinde gerçekleşir. Ayrıca, hizmet sorumlularının ve güvenlik gruplarının bunları tanımlamak için kullanıcı asıl adı (UPN) yoktur ve bu nedenle OID öznitelikleri (guid) ile temsil edilirler. ACL'leri temizlemek için bu GUID girdilerini el ile silin.

Hizmet sorumlusu için ACL'leri nasıl doğru şekilde ayarlarım?

Hizmet sorumluları için ACL'leri tanımlarken, oluşturduğunuz uygulama kaydı için hizmet sorumlusunun Nesne Kimliğini (OID) kullanmanız önemlidir. Kayıtlı uygulamaların belirli Bir Microsoft Entra kiracısında ayrı bir hizmet sorumlusuna sahip olduğunu unutmayın. Kayıtlı uygulamaların Azure portalında görünen bir OID'leri vardır, ancak hizmet sorumlusunun başka bir (farklı) OID'i vardır. Makale Bir uygulama kaydına karşılık gelen hizmet sorumlusunun OID'sini az ad sp show almak için komutunu kullanabilirsiniz. Parametre olarak Uygulama Kimliğini belirtin. Aşağıda, Uygulama Kimliği = ffffffff-eeee-dddd-cccc-bbbbbbbbbbb0 olan bir uygulama kaydına karşılık gelen hizmet sorumlusu için OID alma örneği verilmiştir. Azure CLI’da aşağıdaki komutu çalıştırın:

az ad sp show --id 18218b12-1895-43e9-ad80-6e8fc1ea88ce --query objectId

OID gösterilir.

Hizmet sorumlusu için doğru OID'ye sahip olduğunuzda, Depolama Gezgini Erişimi Yönet sayfasına giderek OID'yi ekleyin ve OID için uygun izinleri atayın. Kaydet'i seçtiğinizden emin olun

Bir kapsayıcının ACL'sini ayarlayabilir miyim?

Hayır Kapsayıcının ACL'si yok. Ancak, kapsayıcının kök dizininin ACL'sini ayarlayabilirsiniz. Her kapsayıcının bir kök dizini vardır ve kapsayıcıyla aynı adı paylaşır. Örneğin, kapsayıcının adı my-containerise kök dizin olarak adlandırılır my-container/.

Azure Depolama REST API'sinde Kapsayıcı ACL'sini Ayarla adlı bir işlem bulunur, ancak bu işlem bir kapsayıcının ACL'sini veya kapsayıcının kök dizinini ayarlamak için kullanılamaz. Bunun yerine bu işlem, bir kapsayıcıdaki bloblara anonim bir istekle erişilip erişilemeyeceğini göstermek için kullanılır. Blob verilerine yönelik tüm istekler için yetkilendirme gerektirmenizi öneririz. Daha fazla bilgi için bkz . Genel Bakış: Blob verileri için anonim okuma erişimini düzeltme.

POSIX erişim denetimi modeli hakkında daha fazla bilgiyi nereden bulabilirim?

• Linux üzerinde POSIX Erişim Denetim Listeleri
• HDFS izin kılavuzu
• POSIX SSS
• POSIX 1003.1 2008
• POSIX 1003.1 2013
• POSIX 1003.1 2016
• Ubuntu üzerinde POSIX ACL

Ayrıca bkz.

• Azure Data Lake Storage'da erişim denetimi modeli