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

Azure Data Lake Depolama 2. Nesil, hem Azure rol tabanlı erişim denetimi (Azure RBAC) hem de POSIX gibi erişim denetim listelerini (ACL) destekleyen bir erişim denetimi modeli sunar. Bu makalede Data Lake Depolama 2. Nesil'de erişim denetimi listeleri açıklanmıştır. Azure RBAC'yi ACL'lerle birlikte dahil etmeyi ve sistemin bunları yetkilendirme kararları almak üzere nasıl değerlendirip değerlendirip değerlendirmesini öğrenmek için bkz. Azure Data Lake'te erişim denetimi modeli Depolama 2. Nesil.

ACL'ler hakkında

Bir güvenlik sorumlularını dosyalar ve dizinler için erişim düzeyiyle ilişkilendirilebilirsiniz. Her ilişkilendirme, bir erişim denetim listesinde (ACL) bir girdi olarak yakalanır. Depolama hesabınızla ilgili her dosya ve dizinin bir erişim denetimi listesi vardır. Bir güvenlik sorumlusu bir dosya veya dizin üzerinde işlem gerçekleştirmeye çalışırsa, ACL denetimi güvenlik sorumlusun (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 herhangi birini okuyun:

ACL türleri

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

Erişim ACL'leri bir nesneye erişimi kontrol eder. Hem dosya hem de dizinlerin erişim ACL'leri vardır.

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

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

İzin düzeyleri

Kapsayıcıdaki dizinler ve dosyalar üzerinde izinler Okuma, Yazma ve Yürütme izinleridir 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 Depolama 2. Nesil tarafından kullanılan POSIX stili modelde, öğenin izinleri öğenin kendisinde depolanır. Diğer bir deyişle, izinler alt öğe oluşturulduktan sonra ayarlanırsa bir öğenin izinleri üst öğelerden devralınamaz. İzinler yalnızca alt öğeler oluşturulmadan önce üst öğelerde varsayılan izinler ayarlanmışsa devralınır.

ACL izinleri ile ilgili yaygın senaryolar

Aşağıdaki tabloda, bir güvenlik sorumlusuna İşlem sütununda listelenen işlemleri gerçekleştirmek için gereken ACL girişleri gösterilir.

Bu tabloda kurgusal bir dizin hiyerarşisinin her düzeyini temsil eden bir sütun bulunur. Kapsayıcının kök dizini ( ) için bir sütun, Oregon adlı bir alt dizin, Portland adlı Bir Portland dizininin alt dizini ve Portland dizinindeData.txtadlı bir metin dosyası / vardır. ****

Kullanıcılar ve kimlikler

Her dosya ve dizin bu kimlikler için ayrı izinlere sahip olur:

• 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, Azure Active Directory (Azure AD) kimlikleridir. bu nedenle, aksi belirtilmediği takdirde, Data Lake Storage 2. bağlamında bir kullanıcı Azure AD kullanıcısına, hizmet sorumlusuna, yönetilen kimliğe veya güvenlik grubuna başvurabilir.

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, "Gamze" kullanıcısı "Finans" grubuna ait gelebilir. Gamze birden çok gruba ait olabilir, ancak bir grup her zaman birincil grubu olarak atanır. POSIX’te Gamze bir dosya oluşturduğunda o dosyanın sahibi olan grup birincil grubu olarak ayarlanır (bu örnekte "finans" grubudur). Aksi takdirde sahip olan grup, diğer kullanıcılar/gruplar için atanan izinlere benzer şekilde davranır.

Yeni bir dosya veya dizin için sahip olan grup atanıyor

• Durum 1: Kök dizin / . bu dizin Data Lake Storage 2. bir kapsayıcı 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 kullanılarak oluşturulduysa, sahip ve sahip olan grup olarak ayarlanır $superuser .
• Durum 2 (diğer her durum): 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ı 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ış bir kullanıcı ise, sahip olan kullanıcı ile ilişkili izin düzeyi geçerli olur.

Aşağıdaki sözde kod, depolama hesapları için erişim denetimi algoritmasını temsil eder. Bu algoritma, kimliklerin değerlendirildiği sırayı 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ırlandırır.

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

Dosyalar yalnızca mağaza sistemindeki dosyalara ait olduğundan, X bitini almaz.

Maske, arama başına temelinde belirtilebilir. Bu, kümeler gibi farklı tüketim sistemlerinin dosya işlemleri için farklı etkin maskelerle çalışmasına izin verir. Belirli bir istekte bir maske belirtilmişse, 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 2. bağlamında, yapışkan bitin gerekli olacağı pek olası bir olasılıktır. Özet ' te, bir dizinde yapışkan bit etkinse, alt öğe yalnızca alt öğenin sahibi olan kullanıcı tarafından silinebilir veya yeniden adlandırılabilir.

Yapışkan bit Azure portal gösterilmez.

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 şunları belirler:

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

umask

Bir dosya veya dizin oluştururken, varsayılan ACL 'Lerin alt öğede nasıl ayarlandığını değiştirmek için umask kullanılır. umask, sahip olan Kullanıcı, sahip olan grup ve diğer için bir RWX değeri içeren üst dizinlerdeki 9 bitlik bir değerdir.

umask, 007 olarak ayarlanan sabit bir değer Azure Data Lake Storage 2.. Bu değer şunu yapar:

Azure Data Lake Storage 2. tarafından kullanılan umask değeri, ana dizinde varsayılan bir ACL tanımlanmadığı müddetçe, diğer için varsayılan olarak yeni alt klasörlerde hiçbir şekilde iletilmediği anlamına gelir. Bu durumda, umask etkin bir şekilde yok sayılır ve varsayılan ACL tarafından tanımlanan izinler alt öğeye uygulanır.

Aşağıdaki sözde kod, bir alt öğe için ACL 'Ler oluştururken umask 'in nasıl uygulanacağını gösterir.

def set_default_acls_for_new_child(parent, child):
    child.acls = []
    for entry in parent.acls :
        new_entry = None
        if (entry.type == OWNING_USER) :
            new_entry = entry.clone(perms = entry.perms & (~umask.owning_user))
        elif (entry.type == OWNING_GROUP) :
            new_entry = entry.clone(perms = entry.perms & (~umask.owning_group))
        elif (entry.type == OTHER) :
            new_entry = entry.clone(perms = entry.perms & (~umask.other))
        else :
            new_entry = entry.clone(perms = entry.perms )
        child_acls.add( new_entry )

SSS

ACL desteğini etkinleştirmem gerekiyor mu?

Hayır. Hiyerarşik ad alanı (HNS) özelliği açık olduğu sürece bir depolama hesabı için ACL 'Ler aracılığıyla erişim denetimi etkinleştirilir.

HNS kapalıysa, Azure Azure RBAC yetkilendirme kuralları yine de geçerlidir.

ACL 'Leri uygulamak için en iyi yol nedir?

Her zaman Azure AD güvenlik gruplarını bir ACL girişinde atanan sorumlu olarak kullanın. Bireysel kullanıcıları veya hizmet sorumlularını doğrudan atamaya yönelik fırsatı yeniden ölçeklendirin. Bu yapının kullanılması, ACL 'Leri tüm dizin yapısına yeniden uygulama gereksinimi olmadan Kullanıcı veya hizmet sorumluları eklemenize ve kaldırmanıza olanak tanır. Bunun yerine, uygun Azure AD güvenlik grubundan kullanıcıları ve hizmet sorumlularını yalnızca ekleyebilir veya kaldırabilirsiniz.

Grupları kurmanı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. Verileri bu klasöre Azure Data Factory (ADF). Hizmet Mühendisliği ekibinin 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:

• LogsWriterGrubu /logData dizininin ACL 'sine rwx izinlerle ekleyin.
• LogsReaderGrubu /logData dizininin ACL 'sine r-x izinlerle ekleyin.
• ADF için hizmet sorumlusu nesnesini veya Yönetilen Hizmet Kimliği (MSI) öğesini LogsWriters gruba ekleyin.
• Hizmet Mühendisliği ekibine kullanıcıları LogsWriter gruba ekleyin.
• Databricks için hizmet sorumlusu nesnesini veya MSI 'ı LogsReader gruba ekleyin.

Hizmet Mühendisliği ekibinizdeki bir kullanıcı şirketten ayrılırsa, onları gruptan kaldırmanız yeterlidir LogsWriter . Bu kullanıcıyı bir gruba eklemediyseniz, bu kullanıcı için adanmış bir ACL girişi eklediyseniz, bu ACL girişini /logData dizininden kaldırmanız gerekir. Girişi, /logData dizininin tüm dizin hiyerarşisindeki tüm alt dizinlerden ve dosyalardan de kaldırmanız gerekir.

Bir grup oluşturmak ve üye eklemek için bkz. Azure Active Directory kullanarak temel Grup oluşturma ve üye ekleme.

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

Sistemin depolama hesabı kaynakları için yetkilendirme kararları vermesini sağlamak üzere Azure RBAC ve ACL 'Leri birlikte nasıl değerlendirdiğini öğrenmek için, bkz. Izinlerin nasıl değerlendirildiği.

Azure rol atamaları ve ACL girdileri sınırları nelerdir?

Aşağıdaki tabloda, Azure RBAC kullanılırken "kaba" izinleri (depolama hesapları veya kapsayıcılar için uygulanan izinler) ve ACL 'Leri kullanarak "hassas" izinleri (dosyalar ve dizinler için uygulanan izinler) yönetmek için göz önünde bulundurmanız gereken limitlerin Özet görünümü verilmektedir. ACL atamaları için güvenlik gruplarını kullanın. Grupları kullanarak abonelik başına rol ataması sayısı üst sınırını ve dosya veya dizin başına en fazla ACL girişi sayısını aşma ihtimaliniz daha düşüktür.

Data Lake Depolama 2. Nesil, Azure RBAC'nin devralmasını destekliyor mu?

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

Data Lake Depolama 2. Nesil ACL'lerin devralınımını destekliyor mu?

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

Bir dizini ve içeriğini tekrar tekrar silmek için hangi izinler gereklidir?

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

Veya

• Üst dizin Yazma + Yürütme izinlerine sahip olmalıdır.
• Silinecek dizin ve içindeki her dizin Okuma + Yazma + Yürütme izinlerini gerektirir.

Who dizinin sahibi nedir?

Dosya veya dizinin oluşturucusu, sahibi olur. Kök dizinde bu, kapsayıcıyı oluşturan kullanıcının kimliğidir.

Oluşturma sırasında dosyanın veya dizinin sahibi olan grup olarak hangi grup ayarlanır?

Sahip olan grup, yeni dosyanın veya dizinin oluşturularak ü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'ler görüyorum?

Giriş bir kullanıcıyı temsil ediyorsa ve bu kullanıcı artık Azure AD'de mevcut yoksa GUID gösterilir. Bu genellikle, kullanıcı şirketten ayrıldığında veya Azure AD’de kullanıcının hesabı silindiğinde gerçekleşir. Ayrıca, hizmet sorumlularının ve güvenlik gruplarının bunları tanımlamak için bir Kullanıcı Asıl Adı (UPN) olmaz ve bu nedenle OID öznitelikleriyle (guid) temsil ederler.

Nasıl yaparım? sorumlu için ACL'leri doğru şekilde ayarlamak mı gerekir?

Hizmet sorumluları için ACL'leri tanımlarken, oluşturduğunuz uygulama kaydı için hizmet sorumlusu nesne kimliğini (OID) kullanmak önemlidir. Kayıtlı uygulamaların belirli bir Azure AD kiracısı içinde ayrı bir hizmet sorumlusuna sahip olduğunu unutmayın. Kayıtlı uygulamalarda, hizmet sorumlusunda görünür olan bir OID Azure portal ancak hizmet sorumlusunda başka bir (farklı) OID vardır.

Uygulama kaydına karşılık gelen hizmet sorumlusu OID'lerini almak için komutunu az ad sp show kullanabilirsiniz. Parametre olarak Uygulama Kimliği'ne tıklayın. Burada, Uygulama Kimliği = 18218b12-1895-43e9-ad80-6e8fc1ea88ce ile bir uygulama kaydına karşılık gelen hizmet sorumlusu için OID'yi alma örneği ve ardından bir örnek ve ardından ve bir örnek yer almaktadır. 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örüntülenir.

Hizmet sorumlusu için doğru OID'ye sahipken, OID'yi eklemek ve OID için uygun izinleri atamak için Depolama Gezgini Erişim Yönet sayfasına gidin. Kaydet’i seçtiğinizden emin olun.

Kapsayıcının ACL'sini ayarlamam gerekir mi?

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

Azure Depolama REST API Kapsayıcı ACL'sini Ayarla adlı bir işlem içerir, ancak bu işlem kapsayıcının ACL'siniveya kapsayıcının kök dizinini ayarlamak için kullanılamaz. Bunun yerine bu işlem, bir kapsayıcıda yer alan bloblara genel olarak erişilip erişilelamayacağını belirtmek için kullanılır.

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
• Linux üzerinde erişim denetim listelerini kullanan ACL

Ayrıca bkz.

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