Listy kontroli dostępu (ACL) w usłudze Azure Data Lake Storage Gen2

Usługa Azure Data Lake Storage Gen2 implementuje model kontroli dostępu, który obsługuje zarówno kontrolę dostępu opartą na rolach platformy Azure (Azure RBAC) i listy kontroli dostępu podobne do modelu POSIX (ACL). W tym artykule opisano listy kontroli dostępu w usłudze Data Lake Storage Gen2. Aby dowiedzieć się więcej na temat sposobu dołączania kontroli dostępu opartej na rolach platformy Azure wraz z listami ACL i oceniania ich w celu podejmowania decyzji dotyczących autoryzacji, zobacz Model kontroli dostępu w usłudze Azure Data Lake Storage Gen2.

Informacje o listach ACL

Podmiot zabezpieczeń można skojarzyć z poziomem dostępu dla plików i katalogów. Każde skojarzenie jest przechwytywane jako wpis na liście kontroli dostępu (ACL). Każdy plik i katalog na koncie magazynu ma listę kontroli dostępu. Gdy podmiot zabezpieczeń próbuje wykonać operację w pliku lub katalogu, sprawdzanie listy ACL określa, czy podmiot zabezpieczeń (użytkownik, grupa, jednostka usługi lub tożsamość zarządzana) ma prawidłowy poziom uprawnień do wykonania operacji.

Uwaga

Listy ACL mają zastosowanie tylko do podmiotów zabezpieczeń w tej samej dzierżawie i nie mają zastosowania do użytkowników korzystających z uwierzytelniania tokenu klucza współdzielonego lub sygnatury dostępu współdzielonego (SAS). Dzieje się tak, ponieważ nie jest skojarzona żadna tożsamość z obiektem wywołującym i dlatego nie można wykonać autoryzacji opartej na uprawnieniach podmiotu zabezpieczeń.

Jak ustawić listy ACL

Aby ustawić uprawnienia na poziomie pliku i katalogu, zobacz dowolny z następujących artykułów:

Środowisko Artykuł
Eksplorator usługi Azure Storage Zarządzanie listami ACL w usłudze Azure Data Lake Storage Gen2 za pomocą Eksploratora usługi Azure Storage
Azure Portal Zarządzanie listami ACL w usłudze Azure Data Lake Storage Gen2 przy użyciu witryny Azure Portal
.NET Zarządzanie listami ACL w usłudze Azure Data Lake Storage Gen2 przy użyciu platformy .NET
Java Zarządzanie listami ACL w usłudze Azure Data Lake Storage Gen2 przy użyciu języka Java
Python Zarządzanie listami ACL w usłudze Azure Data Lake Storage Gen2 przy użyciu języka Python
JavaScript (Node.js) Używanie zestawu JAVAScript SDK w Node.js do zarządzania listami ACL w usłudze Azure Data Lake Storage Gen2
PowerShell Zarządzanie listami ACL w usłudze Azure Data Lake Storage Gen2 przy użyciu programu PowerShell
Interfejs wiersza polecenia platformy Azure Zarządzanie listami ACL w usłudze Azure Data Lake Storage Gen2 przy użyciu interfejsu wiersza polecenia platformy Azure
Interfejs API REST Ścieżka — aktualizacja

Ważne

Jeśli jednostka zabezpieczeń jest jednostką usługi , ważne jest użycie identyfikatora obiektu jednostki usługi, a nie identyfikatora obiektu powiązanej rejestracji aplikacji. Aby uzyskać identyfikator obiektu jednostki usługi, otwórz interfejs wiersza polecenia platformy Azure, a następnie użyj następującego polecenia: az ad sp show --id <Your App ID> --query objectId. Pamiętaj, aby zastąpić <Your App ID> symbol zastępczy identyfikatorem aplikacji rejestracji aplikacji.

Typy list ACL

Istnieją dwa rodzaje list kontroli dostępu: listy ACL dostępu i domyślne listy ACL.

Listy ACL dostępu kontrolują dostęp do obiektu. Pliki i katalogi mają osobne listy ACL dostępu.

Domyślne listy ACL to szablony list ACL skojarzonych z katalogiem, które określają listy ACL dostępu dla wszystkich elementów podrzędnych utworzonych w tym katalogu. Pliki nie mają domyślnych list ACL.

Zarówno listy ACL dostępu, jak i domyślne listy ACL mają taką samą strukturę.

Uwaga

Zmiana domyślnej listy ACL elementu nadrzędnego nie ma wpływu na listę ACL dostępu ani domyślną listę ACL elementów podrzędnych, które już istnieją.

Poziomy uprawnień

Uprawnienia do katalogów i plików w kontenerze są przeznaczone do odczytu, zapisu i wykonywania oraz mogą być używane w plikach i katalogach, jak pokazano w poniższej tabeli:

Plik Katalog
Odczyt (R) Może odczytywać zawartości pliku Wymaga odczytu i wykonania , aby wyświetlić listę zawartości katalogu
Zapis (W) Może zapisywać w pliku lub dołączać do pliku Wymaga zapisu i wykonywania w celu utworzenia elementów podrzędnych w katalogu
Wykonanie (X) Nie oznacza nic w kontekście usługi Data Lake Storage Gen2 Wymagane do przechodzenia przez elementy podrzędne katalogu

Uwaga

Jeśli udzielasz uprawnień tylko przy użyciu list ACL (bez kontroli dostępu opartej na rolach platformy Azure), a następnie przyznać jednostce zabezpieczeń dostęp do odczytu lub zapisu do pliku, musisz nadać podmiotowi zabezpieczeń uprawnienia Wykonywanie do folderu głównego kontenera i do każdego folderu w hierarchii folderów prowadzących do pliku.

Krótkie formy uprawnień

Skrót RWX służy do wskazywania uprawnień do odczytu, zapisu i wykonania. Istnieje bardziej skondensowana postać liczbowa, w której uprawnienia do odczytu = 4, zapisu = 2 i wykonania = 1, a ich suma reprezentuje uprawnienia. Poniżej przedstawiono kilka przykładów.

Forma liczbowa Forma krótka Co to oznacza
7 RWX Odczyt (R) + zapis (W) + wykonanie (X)
5 R-X Odczyt (R) + wykonanie (X)
4 R-- Odczyt
0 --- Brak uprawnień

Dziedziczenie uprawnień

W modelu w stylu POSIX używanym przez usługę Data Lake Storage Gen2 uprawnienia do elementu są przechowywane w samym elemencie. Innymi słowy, uprawnienia dla elementu nie mogą być dziedziczone z elementów nadrzędnych, jeśli uprawnienia są ustawione po utworzeniu elementu podrzędnego. Uprawnienia są dziedziczone tylko wtedy, gdy uprawnienia domyślne zostały ustawione na elementach nadrzędnych przed utworzeniem elementów podrzędnych.

W poniższej tabeli przedstawiono wpisy listy ACL wymagane do umożliwienia podmiotowi zabezpieczeń wykonywania operacji wymienionych w kolumnie Operacja .

W tej tabeli przedstawiono kolumnę reprezentującą każdy poziom fikcyjnej hierarchii katalogów. Istnieje kolumna katalogu głównego kontenera (/), podkatalog o nazwie Oregon, podkatalog katalogu Oregon o nazwie Portland i plik tekstowy w katalogu Portland o nazwie Data.txt.

Ważne

W tej tabeli założono, że używasz tylko list ACL bez żadnych przypisań ról platformy Azure. Aby wyświetlić podobną tabelę, która łączy kontrolę dostępu opartą na rolach platformy Azure wraz z listami ACL, zobacz Tabela uprawnień: łączenie kontroli dostępu opartej na rolach platformy Azure i listy ACL.

Operacja / Oregon/ Portland/ Data.txt
Odczyt Data.txt --X --X --X R--
Dołącz do Data.txt --X --X --X RW-
Usuwanie Data.txt --X --X -WX ---
Tworzenie Data.txt --X --X -WX ---
Lista / R-X --- --- ---
Lista /Oregon/ --X R-X --- ---
Lista /Oregon/Portland/ --X --X R-X ---

Uwaga

Uprawnienia do zapisu w pliku nie są wymagane do jego usunięcia, o ile dwa poprzednie warunki są spełnione.

Użytkownicy i tożsamości

Każdy plik i katalog mają odrębne uprawnienia dla tych tożsamości:

  • Użytkownik będący właścicielem
  • Grupa będąca właścicielem
  • Użytkownicy nazwani
  • Grupy nazwane
  • Nazwane jednostki usługi
  • Nazwane tożsamości zarządzane
  • Wszyscy pozostali użytkownicy

Tożsamości użytkowników i grup są tożsamościami usługi Azure Active Directory (Azure AD). Dlatego, o ile nie określono inaczej, użytkownik w kontekście usługi Data Lake Storage Gen2 może odwoływać się do użytkownika usługi Azure AD, jednostki usługi, tożsamości zarządzanej lub grupy zabezpieczeń.

Użytkownik będący właścicielem

Użytkownik, który utworzył element, jest automatycznie właścicielem elementu. Użytkownik będący właścicielem może:

  • zmieniać uprawnienia dla pliku, którego jest właścicielem;
  • zmieniać grupę będącą właścicielem dla pliku, którego jest właścicielem, jeśli użytkownik będący właścicielem jest również członkiem grupy docelowej.

Uwaga

Użytkownik będąc właścicielem nie może zmienić użytkownika będąc właścicielem pliku lub katalogu. Tylko administratorzy mogą zmienić użytkownika będącego właścicielem pliku lub katalogu.

Grupa będąca właścicielem

W listach ACL POSIX każdy użytkownik jest skojarzony z grupą podstawową. Na przykład użytkownik "Alice" może należeć do grupy "finanse". Alicja może również należeć do wielu grup, ale jedna grupa jest zawsze wyznaczona jako ich grupa podstawowa. W systemie POSIX, gdy Alice tworzy plik, grupa będąca właścicielem tego pliku jest ustawiona na jej grupę podstawową, co w tym przypadku jest "finanse". W przeciwnym razie grupa będąca właścicielem zachowuje się podobnie do przypisanych uprawnień dla innych użytkowników/grup.

Przypisywanie grupy właścicieli dla nowego pliku lub katalogu

  • Przypadek 1: Katalog /główny . Ten katalog jest tworzony podczas tworzenia kontenera usługi Data Lake Storage Gen2. W takim przypadku grupa będąca właścicielem jest ustawiona na użytkownika, który utworzył kontener, jeśli został on wykonany przy użyciu protokołu OAuth. Jeśli kontener jest tworzony przy użyciu klucza wspólnego, sygnatury dostępu współdzielonego konta lub sygnatury dostępu współdzielonego usługi, właściciel i grupa będąca właścicielem są ustawione na $superuserwartość .
  • Przypadek 2 (każdy inny przypadek): Po utworzeniu nowego elementu grupa będąca właścicielem jest kopiowana z katalogu nadrzędnego.

Zmienianie grupy będącą właścicielem

Grupę będącą właścicielem może zmienić:

  • każdy administrator;
  • użytkownik będący właścicielem, jeśli jest on również członkiem grupy docelowej.

Uwaga

Grupa będąca właścicielem nie może zmienić list ACL pliku lub katalogu. Gdy grupa będąca właścicielem jest ustawiona na użytkownika, który utworzył konto w przypadku katalogu głównego, przypadek 1 powyżej, pojedyncze konto użytkownika nie jest prawidłowe do zapewnienia uprawnień za pośrednictwem grupy będącej właścicielem. Możesz przypisać te uprawnienia do prawidłowej grupy użytkowników, jeśli ma to zastosowanie.

Jak są oceniane uprawnienia

Tożsamości są oceniane w następującej kolejności:

  1. Superużytkownik
  2. Użytkownik będący właścicielem
  3. Nazwany użytkownik, jednostka usługi lub tożsamość zarządzana
  4. Grupa będąca właścicielem lub nazwana grupa
  5. Wszyscy pozostali użytkownicy

Jeśli więcej niż jedna z tych tożsamości ma zastosowanie do podmiotu zabezpieczeń, zostanie przyznany poziom uprawnień skojarzony z pierwszą tożsamością. Jeśli na przykład podmiot zabezpieczeń jest zarówno użytkownikiem będącym właścicielem, jak i nazwanym użytkownikiem, zostanie zastosowany poziom uprawnień skojarzony z użytkownikiem będącym właścicielem.

Poniższy pseudokod reprezentuje algorytm sprawdzania dostępu dla kont magazynu. Ten algorytm pokazuje kolejność oceniania tożsamości.

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)

Maska

Jak pokazano w algorytmie sprawdzania dostępu, maska ogranicza dostęp do nazwanych użytkowników, grupy właścicieli i nazwanych grup.

W przypadku nowego kontenera usługi Data Lake Storage Gen2 maska dostępu do listy ACL katalogu głównego ("/") domyślnie to 750 dla katalogów i 640 dla plików. W poniższej tabeli przedstawiono symboliczną notację tych poziomów uprawnień.

Jednostka Katalogi Pliki
Użytkownik będący właścicielem rwx rw-
Grupa będąca właścicielem r-x r--
Inne --- ---

Pliki nie otrzymują bitu X, ponieważ nie ma znaczenia dla plików w systemie tylko do przechowywania.

Maskę można określić dla poszczególnych wywołań. Dzięki temu różne systemy zużywające, takie jak klastry, mogą mieć różne skuteczne maski na potrzeby operacji na plikach. Jeśli maska jest określona dla danego żądania, całkowicie zastępuje maskę domyślną.

Atrybut sticky bit

Sticky bit jest bardziej zaawansowaną funkcją kontenera POSIX. W kontekście usługi Data Lake Storage Gen2 jest mało prawdopodobne, aby bit sticky był potrzebny. Podsumowując, jeśli bit sticky jest włączony w katalogu, element podrzędny można usunąć lub zmienić nazwę tylko przez użytkownika elementu podrzędnego, właściciela katalogu lub superużytkownika ($superuser).

Bit sticky nie jest wyświetlany w witrynie Azure Portal.

Domyślne uprawnienia do nowych plików i katalogów

Po utworzeniu nowego pliku lub katalogu w istniejącym katalogu domyślna lista ACL w katalogu nadrzędnym określa:

  • Domyślna lista ACL katalogu podrzędnego i lista ACL dostępu.
  • Lista ACL dostępu pliku podrzędnego (pliki nie mają domyślnej listy ACL).

umask

Podczas tworzenia pliku lub katalogu maska umask służy do modyfikowania sposobu ustawiania domyślnych list ACL w elemencie podrzędnym. umask to wartość 9-bitowa w katalogach nadrzędnych, która zawiera wartość RWX dla użytkownika będącego właścicielem, grupy będącej właścicielem i innych.

Maska umask dla usługi Azure Data Lake Storage Gen2 jest stałą wartością ustawioną na 007. Ta wartość przekłada się na:

składnik maski umask Forma liczbowa Forma krótka Znaczenie
umask.owning_user 0 --- W przypadku użytkownika, który jest właścicielem, skopiuj domyślną listę kontroli dostępu elementu nadrzędnego do listy ACL dostępu elementu podrzędnego
umask.owning_group 0 --- W przypadku grupy będącą właścicielem skopiuj domyślną listę kontroli dostępu elementu nadrzędnego do listy ACL dostępu elementu podrzędnego
umask.other 7 RWX W przypadku innych usuń wszystkie uprawnienia do listy ACL dostępu elementu podrzędnego

Wartość maski umask używanej przez usługę Azure Data Lake Storage Gen2 skutecznie oznacza, że wartość dla innych nigdy nie jest domyślnie przesyłana dla nowych elementów podrzędnych, chyba że domyślna lista ACL jest zdefiniowana w katalogu nadrzędnym. W takim przypadku maska umask jest skutecznie ignorowana, a uprawnienia zdefiniowane przez domyślną listę ACL są stosowane do elementu podrzędnego.

Poniższy pseudokod pokazuje, jak maska umask jest stosowana podczas tworzenia list ACL dla elementu podrzędnego.

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 )

Często zadawane pytania

Czy muszę włączyć obsługę list ACL?

Nie. Kontrola dostępu za pośrednictwem list ACL jest włączona dla konta magazynu, o ile funkcja hierarchicznej przestrzeni nazw (HNS) jest włączona.

Jeśli usługa HNS jest wyłączona, nadal obowiązują reguły autoryzacji RBAC platformy Azure.

Jaki jest najlepszy sposób stosowania list ACL?

Zawsze używaj grup zabezpieczeń usługi Azure AD jako przypisanego podmiotu zabezpieczeń we wpisie listy ACL. Oprzej się możliwości bezpośredniego przypisywania poszczególnych użytkowników lub jednostek usługi. Użycie tej struktury umożliwi dodawanie i usuwanie użytkowników lub jednostek usługi bez konieczności ponownego stosowania list ACL do całej struktury katalogów. Zamiast tego możesz po prostu dodać lub usunąć użytkowników i jednostki usługi z odpowiedniej grupy zabezpieczeń usługi Azure AD.

Istnieje wiele różnych sposobów konfigurowania grup. Załóżmy na przykład, że masz katalog o nazwie /LogData , który przechowuje dane dziennika generowane przez serwer. Usługa Azure Data Factory (ADF) pozysuje dane w tym folderze. Konkretni użytkownicy z zespołu inżynierów usług będą przekazywać dzienniki i zarządzać innymi użytkownikami tego folderu, a różne klastry usługi Databricks będą analizować dzienniki z tego folderu.

Aby włączyć te działania, można utworzyć grupę LogsWriter i grupę LogsReader . Następnie można przypisać uprawnienia w następujący sposób:

  • Dodaj grupę LogsWriter do listy ACL katalogu /LogData z uprawnieniami rwx .
  • Dodaj grupę LogsReader do listy ACL katalogu /LogData z uprawnieniami r-x .
  • Dodaj do grupy obiekt jednostki usługi lub tożsamość usługi zarządzanej LogsWriters (MSI) dla usługi ADF.
  • Dodaj użytkowników w zespole inżynierów usług do LogsWriter grupy.
  • Dodaj do grupy obiekt jednostki usługi lub tożsamość usługi zarządzanej LogsReader dla usługi Databricks.

Jeśli użytkownik w zespole inżynierów usług opuści firmę, możesz je usunąć z LogsWriter grupy. Jeśli nie dodano tego użytkownika do grupy, ale zamiast tego dodano dedykowany wpis listy ACL dla tego użytkownika, należy usunąć ten wpis listy ACL z katalogu /LogData . Należy również usunąć wpis ze wszystkich podkatalogów i plików w całej hierarchii katalogów katalogu /LogData .

Aby utworzyć grupę i dodać członków, zobacz Tworzenie grupy podstawowej i dodawanie członków przy użyciu usługi Azure Active Directory.

W jaki sposób są oceniane uprawnienia kontroli dostępu opartej na rolach platformy Azure i listy ACL?

Aby dowiedzieć się, w jaki sposób system ocenia kontrolę dostępu opartą na rolach platformy Azure i listy ACL w celu podejmowania decyzji dotyczących autoryzacji dla zasobów konta magazynu, zobacz Jak są oceniane uprawnienia.

Jakie są limity przypisań ról i wpisów listy ACL platformy Azure?

W poniższej tabeli przedstawiono podsumowanie limitów, które należy wziąć pod uwagę podczas korzystania z kontroli dostępu opartej na rolach platformy Azure do zarządzania uprawnieniami "gruboziarnistymi" (uprawnienia stosowane do kont magazynu lub kontenerów) i używania list ACL do zarządzania uprawnieniami "szczegółowe" (uprawnienia stosowane do plików i katalogów). Użyj grup zabezpieczeń dla przypisań listy ACL. Przy użyciu grup mniej prawdopodobne jest przekroczenie maksymalnej liczby przypisań ról na subskrypcję i maksymalnej liczby wpisów listy ACL na plik lub katalog.

Mechanism (Mechanizm) Zakres Limity Obsługiwany poziom uprawnień
Kontrola dostępu na podstawie ról platformy Azure Konta magazynu, kontenery.
Przypisania ról platformy Azure między zasobami na poziomie subskrypcji lub grupy zasobów.
2000 Przypisań ról platformy Azure w subskrypcji Role platformy Azure (wbudowane lub niestandardowe)
ACL Katalog, plik 32 wpisy listy ACL (skutecznie 28 wpisów listy ACL) na plik i na katalog. Dostęp i domyślne listy ACL mają własny limit wprowadzania listy ACL 32. Uprawnienie listy ACL

Czy usługa Data Lake Storage Gen2 obsługuje dziedziczenie kontroli dostępu opartej na rolach platformy Azure?

Przypisania ról platformy Azure dziedziczą. Przypisania przepływają z zasobów subskrypcji, grupy zasobów i konta magazynu do zasobu kontenera.

Czy usługa Data Lake Storage Gen2 obsługuje dziedziczenie list ACL?

Domyślne listy ACL mogą służyć do ustawiania list ACL dla nowych podkatalogów podrzędnych i plików utworzonych w katalogu nadrzędnym. Aby zaktualizować listy ACL dla istniejących elementów podrzędnych, należy dodać, zaktualizować lub usunąć listy ACL cyklicznie dla żądanej hierarchii katalogów. Aby uzyskać wskazówki, zobacz sekcję How to set ACL (Jak ustawić listy ACL ) tego artykułu.

Które uprawnienia są wymagane do cyklicznego usuwania katalogu i jego zawartości?

  • Obiekt wywołujący ma uprawnienia "superuchodźców",

Lub

  • Katalog nadrzędny musi mieć uprawnienia Do zapisu i wykonywania.
  • Katalog, który ma zostać usunięty, i każdy katalog w nim, wymaga uprawnień do odczytu i zapisu i wykonywania.

Uwaga

Nie potrzebujesz uprawnień do zapisu, aby usunąć pliki w katalogach. Ponadto nigdy nie można usunąć katalogu głównego "/".

Kto jest właścicielem pliku lub katalogu?

Twórca pliku lub katalogu staje się właścicielem. W przypadku katalogu głównego jest to tożsamość użytkownika, który utworzył kontener.

Która grupa jest ustawiana jako grupa będąca właścicielem pliku lub katalogu podczas tworzenia?

Grupa będąca właścicielem jest kopiowana z grupy będącej właścicielem katalogu nadrzędnego, w którym tworzony jest nowy plik lub katalog.

Jestem właścicielem pliku, ale nie mam wymaganych uprawnień RWX. Co mam zrobić?

Użytkownik będący właścicielem może zmienić uprawnienia do pliku, aby przydzielić sobie wymagane uprawnienia RWX.

Dlaczego czasami widzę identyfikatory GUID w listach ACL?

Identyfikator GUID jest wyświetlany, jeśli wpis reprezentuje użytkownika i ten użytkownik już nie istnieje w usłudze Azure AD. Zwykle dzieje się tak, gdy użytkownik opuścił firmę lub jego konto w usłudze Azure AD zostało usunięte. Ponadto jednostki usługi i grupy zabezpieczeń nie mają głównej nazwy użytkownika (UPN), aby je zidentyfikować i dlatego są reprezentowane przez ich atrybut OID (identyfikator GUID).

Jak poprawnie ustawić listy ACL dla jednostki usługi?

Podczas definiowania list ACL dla jednostek usługi ważne jest użycie identyfikatora obiektu (OID) jednostki usługi na potrzeby utworzonej rejestracji aplikacji. Należy pamiętać, że zarejestrowane aplikacje mają oddzielną jednostkę usługi w określonej dzierżawie usługi Azure AD. Zarejestrowane aplikacje mają identyfikator OID widoczny w witrynie Azure Portal, ale jednostka usługi ma inny (inny) identyfikator OID.

Aby uzyskać identyfikator OID dla jednostki usługi odpowiadającej rejestracji aplikacji, możesz użyć az ad sp show polecenia . Określ identyfikator aplikacji jako parametr . Oto przykład uzyskiwania identyfikatora OID dla jednostki usługi odpowiadającej rejestracji aplikacji o identyfikatorze aplikacji = 18218b12-1895-43e9-ad80-6e8fc1ea88ce. Uruchom następujące polecenie w interfejsie wiersza polecenia platformy Azure:

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

Zostanie wyświetlony OID.

Jeśli masz prawidłowy identyfikator OID dla jednostki usługi, przejdź do strony Zarządzanie dostępem w Eksploratorze usługi Storage, aby dodać identyfikator OID i przypisać odpowiednie uprawnienia dla identyfikatora OID. Upewnij się, że wybrano pozycję Zapisz

Czy mogę ustawić listę ACL kontenera?

Nie. Kontener nie ma listy ACL. Można jednak ustawić listę ACL katalogu głównego kontenera. Każdy kontener ma katalog główny i ma taką samą nazwę jak kontener. Jeśli na przykład kontener ma nazwę my-container, katalog główny ma nazwę my-container/.

Interfejs API REST usługi Azure Storage zawiera operację o nazwie Set Container ACL (Ustaw listę ACL kontenerów), ale tej operacji nie można użyć do ustawienia listy ACL kontenera ani katalogu głównego kontenera. Zamiast tego ta operacja służy do wskazania, czy obiekty blob w kontenerze mogą być dostępne publicznie.

Gdzie można dowiedzieć się więcej na temat modelu kontroli dostępu POSIX?

Zobacz też