Azure Data Lake Storage'da 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’nin ACL’lerle birlikte nasıl kullanılacağını ve sistemin yetkilendirme kararları vermek için bunları nasıl değerlendirdiğini öğrenmek için Azure Data Lake Storage’da erişim denetimi modeli konusuna bakın.

Not

NFS 3.0 isteğini yetkilendirmek için ACL'leri kullanamazsınız. Ancak, SSH Dosya Aktarım Protokolü (SFTP) isteklerini yetkilendirmek için ACL'leri kullanabilirsiniz. Bkz. Microsoft Entra ID ile bloblara SFTP erişimini yetkilendirmeye yönelik Bilinen Sorunlar ve sınırlamalar.

Azure Data Lake Storage'daki 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 listesindeki (ACL) bir girdidir. 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.

Not

ACL'ler yalnızca aynı kiracıdaki güvenlik sorumlularına uygulanır. Arayanla ilişkili kimlik olmadığından ve bu nedenle güvenlik sorumlusu izin tabanlı yetkilendirme gerçekleştirilemediğinden, ACL'ler Paylaşılan Anahtar yetkilendirmesini kullanan kullanıcılar için geçerli değildir. Aynı kural, kullanıcı tarafından atanan sas belirtecinin kullanılması dışında paylaşılan erişim imzası (SAS) belirteçleri için de geçerlidir. Bu durumda Azure Depolama, isteğe bağlı suoid parametresi kullanıldığı sürece işlemi yetkilendirmeden önce nesne kimliğine karşı bir POSIX ACL denetimi gerçekleştirir. Daha fazla bilgi edinmek için Kullanıcı Temsilcisi SAS’i Oluşturma başlığına bakın.

Azure Data Lake Storage'de ACL'leri ayarlama

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

Ortam Makale
Azure Depolama Gezgini Azure Data Lake Storage'da ACL'leri yönetmek için Azure Depolama Gezgini kullanma
Azure portalı Azure Data Lake Storage'da ACL'leri yönetmek için Azure portalını kullanma
.NET Azure Data Lake Storage'da ACL'leri yönetmek için .NET kullanma
Java Azure Data Lake Storage'da ACL'leri yönetmek için Java kullanma
Piton Azure Data Lake Storage'da ACL'leri yönetmek için Python kullanma
JavaScript (Node.js) Azure Data Lake Storage'da ACL'leri yönetmek için Node.js javascript SDK'sını kullanma
PowerShell Azure Data Lake Storage'da ACL'leri yönetmek için PowerShell kullanma
Azure Komut Satırı Arayüzü (Azure CLI) Azure Data Lake Storage'da ACL'leri yönetmek için Azure CLI kullanma
REST API Yol - Güncelleştirme

Önemli

Güvenlik sorumlusu bir hizmet sorumlusuysa, ilgili uygulama kaydının nesne kimliğini değil hizmet sorumlusunun nesne kimliğini kullanın. Hizmet sorumlusunun nesne kimliğini almak için Azure CLI açın ve şu komutu kullanın: az ad sp show --id <Your App ID> --query objectId. <Your App ID> yer tutucusunu, uygulama kaydınızın Uygulama Kimliği ile değiştirin. Hizmet sorumlusu adlandırılmış kullanıcı olarak değerlendirilir. Bu kimliği ACL'ye, diğer adlandırılmış kullanıcılar gibi ekleyin. Adlandırılmış kullanıcılar bu makalenin devamında açıklanmıştır.

ACL türleri: ERIŞIM ACL'leri ve varsayılan ACL'ler

İ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, bir dizinle ilişkili olan ve bu dizin altında oluşturulan alt öğeler için erişim kontrol listelerini belirleyen 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.

Not

Ana öğedeki varsayılan ACL'nin değiştirilmesi, zaten var olan alt öğelerin erişim ACL'sini veya varsayılan ACL'sini etkilemez.

İzin düzeyleri

Kapsayıcıdaki dizinler ve dosyalar üzerindeki izinler Okuma, Yazma ve Yürütme'dir. Aşağıdaki tabloda gösterildiği gibi dosyalar ve dizinler üzerinde bu izinleri kullanın:

Dosya Dizin
Okuma (R) Bir dosyanın içeriğini okuyabilir Dizinin içeriğini listelemek için Okuma ve Yürütme gerektirir
Yaz (W) Bir dosyaya yazabilir veya ekleyebilir Bir dizinde alt öğeler oluşturmak için Yazma ve Yürütme izinleri gerektirir.
Yürütme (X) Data Lake Storage bağlamında bir anlam ifade etmez Bir dizinin alt öğeleri arasında geçiş yapmak için gereklidir

Not

Bir dosyaya bir güvenlik asıl öğesine okuma veya yazma erişimi vermek için, izinleri yalnızca ACL’leri kullanarak veriyorsanız (Azure RBAC olmadan), güvenlik asıl öğesine kapsayıcının kök klasörü için ve dosyaya giden klasör hiyerarşisindeki her klasör için Execute izinleri vermeniz gerekir.

İzinlerin kısaltmaları

Okuma + Yazma + Yürütme izinlerini göstermek için RWX kullanın. Read=4, Write=2 ve Execute=1 değerlerinin bulunduğu sayısal bir form da vardır. İzinleri göstermek için bu sayıları ekleyin. Aşağıda bazı örnekler verilmiştir:

Sayısal biçim Kısa biçim Anlamı
7 RWX Okuma + Yazma + Yürütme
5 R-X Okuma + Yürütme
4 R-- Okundu
0 --- İzin yok

İzin devralma

Data Lake Storage kullanan POSIX stili modelde, öğenin kendisinde bir öğenin izinlerini depolarsınız. Başka bir deyişle, alt öğeyi oluşturduktan sonra izinleri ayarlarsanız, alt öğe üst öğelerden izinleri devralamaz. Öğeler izinleri yalnızca alt öğeleri oluşturmadan önce üst öğelerde varsayılan izinleri ayarladığınızda devralır. Örneğin, bir dizin oluşturup daha sonra bu dizinde varsayılan bir ACL ayarlarsanız, bu dizinde zaten var olan dosyalar yeni varsayılan ACL'yi devralmaz. Yalnızca ACL'yi ayarladıktan sonra oluşturulan dosyalar devralır.

Azure Data Lake Storage'de ACL izinleri için 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.

Önemli

Bu tabloda, Azure rol ataması olmadan only ACL'leri kullandığınız varsayılır. Azure RBAC'yi ACL'lerle birleştiren benzer bir tablo görmek için bkz . İzinler tablosu: Azure RBAC, ABAC ve ACL'leri birleştirme.

İşlem / Oregon/ Portland/ Data.txt
Okuma Data.txt --X --X --X R--
Data.txt dosyasına ekle --X --X --X RW-
Data.txt dosyasını sil --X --X -WX ---
Sil /Oregon/ -WX RWX RWX ---
Sil /Oregon/Portland/ --X -WX RWX ---
"Veri.txt'yi oluştur / güncelle" --X --X -WX ---
Liste/ R-X --- --- ---
Liste /Oregon/ --X R-X --- ---
Liste /Oregon/Portland/ --X --X R-X ---

Dosyaları ve dizinleri silme

Bir dosyayı silmek için, dosyanın kendisinde yazma izinlerine ihtiyacınız yoktur. Üst dizin yalnızca izinlere ihtiyaç duyar -WX . 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.

Not

"/" kök dizinini hiçbir zaman silemezsiniz.

ACL'lerdeki 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örler için RWX izinlerine 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’i veya Hizmet SAS’i kullanarak bir kapsayıcı, dosya ya da dizin oluşturursanız, sahip ve sahip grup $superuser olarak ayarlanır.

Sahip olan kullanıcı

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

  • Sahip oldukları dosyanın izinlerini değiştirin.
  • Sahibi olan kullanıcı da hedef grubun üyesi olduğu sürece, sahip oldukları dosyanın sahip olan grubunu değiştirin.

Not

Sahip olan kullanıcı , bir dosyanın veya dizinin sahibi olan kullanıcıyı değiştiremez. Bir dosya veya dizinin sahibi olan kullanıcıyı yalnızca süper kullanıcılar değiştirebilir.

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 sahip grubu onun birincil grubu olarak ayarlanır; bu örnekte bu grup "finance"tir. Sahip grup, bunun dışında, diğer kullanıcılar ve gruplar için atanmış izinlere benzer şekilde davranır.

Yeni bir dosya veya dizin için sahip 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ıyorsa kapsayıcıyı oluşturan kullanıcıya ayarlanır. Kullanıcı kapsayıcıyı Paylaşılan Anahtar, Hesap SAS’ı veya Hizmet SAS’ını kullanarak oluşturursa, sahibi ve sahip grup $superuser olarak ayarlanır.
  • Olay 2 (diğer her durumda): Yeni bir öğe oluşturulduğunda, sahip olan grup üst dizinden kopyalanır.

Sahiplik grubunu değiştirme

Sahiplik grubu aşağıdaki yöntemlerle değiştirilebilir:

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

Not

Sahip olan grup, bir dosya veya dizinin ACL'lerini değiştiremez. Sahip olan grup, kök dizin ( Olay 1 ) durumunda hesabı oluşturan kullanıcıya ayarlanmış olsa da, sahip olan grup aracılığıyla izin sağlamak için tek bir kullanıcı hesabı geçerli değildir. Uygunsa bu izni geçerli bir kullanıcı hesabına atayabilirsiniz.

Sistem ACL izinlerini nasıl değerlendirir?

Sistem kimlikleri aşağıdaki sırayla değerlendirir:

  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, sistem ilk kimlikle ilişkili izin düzeyini verir. Ö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.

Sistem tüm adlandırılmış grupları birlikte değerlendirir. Bir güvenlik sorumlusu birden fazla adlandırılmış grubun üyesiyse, sistem istenen izni bulana 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)

ACL maskesi

Maske yalnızca adlandırılmış bir kullanıcının, adlandırılmış grubun ve sahip olan grubun ACL girdisine uygulanır. Maske, erişimi yetkilendirmek için ACL girdisindeki izinlerden hangisinin kullanılacağını belirtir. Uygulanan bu izinler, ACL girişinin etkin izinleri olarak adlandırılır. Sistem, ACL girdisindeki diğer tüm izinleri yoksayar. Maskeyi kullanarak izin düzeylerinde üst sınır oluşturabilirsiniz.

Maskeyi her çağrı için belirtebilirsiniz. Bu esneklik, 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 belirtirseniz, bu maske varsayılan maskeyi tamamen geçersiz kılar.

Data Lake Storage'daki 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 bite ihtiyacınız olması pek olası değil. Özetle, bir dizinde yapışkan biti etkinleştirirseniz yalnızca alt öğenin sahibi olan kullanıcı, dizinin sahibi veya süper kullanıcı ($superuser) bir alt öğeyi silebilir veya yeniden adlandırabilir.

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

Kök dizinin varsayılan izinleri

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

Varlık Dizinler Dosyalar
Sahip olan kullanıcı rwx rw-
Sahip olan grup r-x r--
Diğer --- ---

Dosyalar, salt depolama sisteminde dosyalar için anlamlı olmadığından X bitini almaz.

Yeni dosya ve dizinlerde varsayılan izinler

Mevcut bir dizin altında yeni bir dosya veya dizin oluşturduğunuzda, üst dizindeki varsayılan ACL şunları belirler:

  • Bir alt dizinin varsayılan ACL'si ve erişim ACL'si.
  • Bir alt dosyanın erişim ACL’si (dosyaların varsayılan ACL’si yoktur).

Data Lake Storage'deki umask

Varsayılan ACL oluşturduğunuzda sistem, varsayılan ACL'nin ilk izinlerini belirlemek için erişim ACL'sine umask uygular. Üst dizinde varsayılan bir ACL tanımlarsanız, sistem umask'ı yoksayar ve ilk değerleri ayarlamak için üst dizinin varsayılan ACL'sini kullanır.

umask, ana dizinlerde sahip olan kullanıcı, sahip olan grup ve diğerleri için bir RWX değeri içeren 9 bitlik bir değerdir.

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

umask bileşeni Sayısal biçim Kısa biçim Anlamı
umask.sahip_kullanıcı 0 --- Kullanıcıya sahip olmak için ebeveynin erişim ACL'sini çocuğun varsayılan ACL'sine kopyalayın
umask.sahip_olan_grup 0 --- Sahip olan grup için ebeveynin erişim ACL'sini çocuğun varsayılan ACL'sine kopyalayın
umask.diğer 7 RWX Diğer için, çocuğun erişim ACL'sinde tüm izinleri kaldırın

SSS

ACL desteğini etkinleştirmem gerekiyor mu?

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

HNS kapalıysa 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 grubunu /LogData dizininin ACL'sine rwx izinleriyle ekleyin.
  • LogsReader grubunu /LogData dizininin ACL'sine r-x izinleriyle 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 ilkesi nesnesini veya MSI'sini LogsReader grubuna ekleyin.

Şirketten ayrılan hizmet mühendisliği ekibindeki bir kullanıcıyı gruptan LogsWriter kolayca 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 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.

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)
Ön Çapraz Bağ (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 izinleri

Data Lake Storage, Azure RBAC devralmayı destekliyor mu?

Azure rol atamaları devralınır. Atamalar abonelik, kaynak grubu ve depolama hesabı kaynaklarından kapsayıcı kaynağına aktarılır.

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,

Veya

  • Üst dizin, yazma ve çalıştırma izinlerine sahiptir.
  • Silinecek dizin ve içindeki tüm dizinler Okuma, Yazma ve Yürütme izinleri gerektirir.

Not

Dizinlerdeki dosyaları silmek için Yazma izinlerine ihtiyacınız yoktur. Ayrıca, "/" kök dizini hiçbir zaman silinemez.

Bir dosyanın veya dizinin sahibi kimdir?

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

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?

Kayıt, Microsoft Entra’da artık bulunmayan bir kullanıcıyı temsil ediyorsa bir GUID görürsünüz. Bu durum genellikle kullanıcı şirketten ayrıldığında veya hesabı Microsoft Entra ID silindiğinde ortaya çıkar. Ayrıca, hizmet sorumlularının ve güvenlik gruplarının Kullanıcı Asıl Adı (UPN) yoktur, bu nedenle sistem bunları OID özniteliği (GUID) ile tanımlar. 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 = 00001111-aaaa-2222-bbbb-3333cccc4444 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 00001111-aaaa-2222-bbbb-3333cccc4444 --query objectId

komutu OID'yi görüntüler.

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'i yoktur. 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 kapsayıcının ACL'sini veya kapsayıcının kök dizinini ayarlamak için bu işlemi kullanamazsınız. 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 gerektir. 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?

Ayrıca bkz.

  • Last updated on