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

  • Makale

Azure Data Lake Storage 2. Nesil 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 2. Nesil erişim denetimi 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 2. Nesil'de 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.

Not

ACL'ler yalnızca aynı kiracıdaki güvenlik sorumluları için geçerlidir ve Paylaşılan Anahtar veya paylaşılan erişim imzası (SAS) belirteç kimlik doğrulaması kullanan kullanıcılar için geçerli değildir. Bunun nedeni, arayanla ilişkili kimlik olmaması ve bu nedenle güvenlik sorumlusu izin tabanlı yetkilendirme gerçekleştirilememesidir.

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 2. Nesil'da ACL'leri yönetmek için Azure Depolama Gezgini kullanma
Azure portal Azure Data Lake Storage 2. Nesil'de ACL'leri yönetmek için Azure portalını kullanma
.NET Azure Data Lake Storage 2. Nesil'de ACL'leri yönetmek için .NET kullanma
Java Azure Data Lake Storage 2. Nesil'da ACL'leri yönetmek için Java kullanma
Python Azure Data Lake Storage 2. Nesil'de ACL'leri yönetmek için Python kullanma
JavaScript (Node.js) Azure Data Lake Storage 2. Nesil'da ACL'leri yönetmek için Node.js JavaScript SDK'sını kullanma
PowerShell Azure Data Lake Storage 2. Nesil'da ACL'leri yönetmek için PowerShell kullanma
Azure CLI Azure Data Lake Storage 2. Nesil'de 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 kullanmak önemlidir. Hizmet sorumlusunun nesne kimliğini almak için Azure CLI'yı açın ve şu komutu kullanın: az ad sp show --id <Your App ID> --query objectId. Yer tutucuyu <Your App ID> uygulama kaydınızın Uygulama Kimliği ile değiştirdiğinden emin olun. Hizmet sorumlusu adlandırılmış kullanıcı olarak değerlendirilir. Bu kimliği, adlandırılmış herhangi bir kullanıcı gibi ACL'ye ekleyeceksiniz. Adlandırılmış kullanıcılar bu makalenin devamında açıklanmıştır.

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.

Not

Bir üst ögedeki varsayılan ACL'yi değiştirmek, halihazırda var olan alt ögelerin 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 ve aşağıdaki tabloda gösterildiği gibi dosya ve dizinlerde kullanılabilir:

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

Not

Yalnızca ACL'leri (Azure RBAC olmadan) kullanarak izinler veriyorsanız, bir güvenlik sorumlusuna bir dosyaya okuma veya yazma erişimi vermek için, güvenlik sorumlusuna kapsayıcının kök klasörü ve dosyaya yol açan klasör hiyerarşisindeki her klasör için Yürütme izinleri vermeniz gerekir.

İ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.

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 2. Nesil tarafından kullanılan POSIX stili modelinde bir ögenin izinleri ögenin kendisine 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.

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, herhangi bir Azure rol ataması olmadan yalnızca 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 ekle --X --X --X RW-
Data.txt sil --X --X -WX ---
Sil /Oregon/ -WX RWX RWX ---
Sil /Oregon/Portland/ --X -WX RWX ---
Data.txt oluşturma --X --X -WX ---
Liste/ R-X --- --- ---
Liste /Oregon/ --X R-X --- ---
Liste /Oregon/Portland/ --X --X R-X ---

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.

Not

"/" kök dizini hiçbir zaman silinemez.

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 2. Nesil 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.

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

Not

Sahip olan grup, bir dosya veya dizinin ACL'lerini değiştiremez. Sahip olan grup, yukarıdaki Örnek 1 kök dizini söz konusu olduğunda 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.

İ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 2. Nesil 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.

Entity Directories Dosyalar
Sahip olan kullanıcı rwx rw-
Sahip olan grup r-x r--
Diğer --- ---

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 2. Nesil bağlamında, yapışkan bitin gerekli olması 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.

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.

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

umask bileşeni Sayısal biçim Kısa biçim Anlamı
umask.owning_user 0 --- Kullanıcıya sahip olmak için ebeveynin erişim ACL'sini çocuğun varsayılan ACL'sine kopyalayın
umask.owning_group 0 --- Sahip olan grup için ebeveynin erişim ACL'sini çocuğun varsayılan ACL'sine kopyalayın
umask.other 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Ç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.

Ö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 hesapları, kapsayıcıları Depolama.
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

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

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, 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ğıdaki örnekte Uygulama Kimliği = 18218b12-1895-43e9-ad80-6e8fc1ea88ce olan bir uygulama kaydına karşılık gelen hizmet sorumlusu için OID elde edilmiş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, OID'yi eklemek ve OID için uygun izinleri atamak üzere Depolama Explorer Erişimi Yönet sayfasına gidin. 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?

Ayrıca bkz.