Listy kontroli dostępu (ACL) dla usługi 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) jak 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ę, jak włączyć kontrolę dostępu opartą na rolach platformy Azure wraz z listami ACL i jak system ocenia je 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 mają listę kontroli dostępu. Gdy podmiot zabezpieczeń próbuje wykonać operację w pliku lub katalogu, sprawdzanie listy ACL określa, czy jednostka 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, zapoznaj się z jednym z następujących artykułów:
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. Jednostka usługi jest traktowana jako nazwany użytkownik. Ten identyfikator zostanie dodany do listy ACL, tak jak każdy nazwany użytkownik. Nazwani użytkownicy są opisani w dalszej części tego artykułu.
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.
Listy ACL dostępu i domyślne listy ACL mają taką samą strukturę.
Uwaga
Zmiana domyślnej listy ACL w lokalizacji nadrzędnej nie wpływa na listę ACL dostępu lub domyślną listę ACL elementów podrzędnych, które już istnieją.
Poziomy uprawnień
Uprawnienia do katalogów i plików w kontenerze to Odczyt, Zapis i Wykonywanie. 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 przyznać podmiotowi zabezpieczeń uprawnienia Wykonywanie do folderu głównego kontenera i do każdego folderu w hierarchii folderów, które prowadzą 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 | Znaczenie |
|---|---|---|
| 7 | RWX |
Odczyt (R) + zapis (W) + wykonanie (X) |
| 5 | R-X |
Odczyt (R) + wykonanie (X) |
| 100 | R-- |
Przeczytaj |
| 0 | --- |
Brak uprawnień |
Dziedziczenie uprawnień
W modelu w stylu POSIX, który jest używany przez usługę Data Lake Storage Gen2, uprawnienia dla 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.
Typowe scenariusze dotyczące uprawnień z listy ACL
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 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, kontroli dostępu opartej na rolach i list ACL.
| Operacja | / | Oregon/ | Portland/ | Data.txt |
|---|---|---|---|---|
| Odczyt Data.txt | --X |
--X |
--X |
R-- |
| Dołączanie do Data.txt | --X |
--X |
--X |
RW- |
| Usuwanie Data.txt | --X |
--X |
-WX |
--- |
| Usuń /Oregon/ | -WX |
RWX |
RWX |
--- |
| Usuń /Oregon/Portland/ | --X |
-WX |
RWX |
--- |
| Tworzenie Data.txt | --X |
--X |
-WX |
--- |
| Listy/ | R-X |
--- |
--- |
--- |
| Lista /Oregon/ | --X |
R-X |
--- |
--- |
| Lista /Oregon/Portland/ | --X |
--X |
R-X |
--- |
Usuwanie plików i katalogów
Jak pokazano w poprzedniej tabeli, uprawnienia do zapisu w pliku nie są wymagane do usunięcia go, o ile uprawnienia katalogu są ustawione prawidłowo. Jednak aby usunąć katalog i całą jego zawartość, katalog nadrzędny musi mieć uprawnienia 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 można usunąć katalogu głównego "/".
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 to tożsamości firmy Microsoft Entra. 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 firmy Microsoft, jednostki usługi, tożsamości zarządzanej lub grupy zabezpieczeń.
Administrator
Administrator ma największe prawa wszystkich użytkowników. Administrator:
ma uprawnienia RWX do wszystkich plików i folderów;
może zmieniać uprawnienia do dowolnego pliku lub folderu;
może zmieniać właściciela lub grupę będącą właścicielem dla dowolnego pliku lub folderu.
Jeśli kontener, plik lub katalog jest tworzony przy użyciu klucza współużytkowanego, 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 mają wartość $superuser.
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 superuzy użytkownicy 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". 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ółużytkowanego, 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 mają wartość$superuser. - 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 właścicieli
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 w przypadku udzielania 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:
- Superużytkownik
- Użytkownik będący właścicielem
- Nazwany użytkownik, jednostka usługi lub tożsamość zarządzana
- Grupa będąca właścicielem lub nazwana grupa
- 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, ma zastosowanie poziom uprawnień skojarzony z użytkownikiem będącym właścicielem.
Wszystkie nazwane grupy są uwzględniane razem. Jeśli podmiot zabezpieczeń jest członkiem więcej niż jednej nazwanej grupy, system ocenia każdą grupę do momentu udzielenia żądanego uprawnienia. Jeśli żadna z nazwanych grup nie zapewni żądanego uprawnienia, system przejdzie do oceny żądania względem uprawnienia skojarzonego ze wszystkimi innymi użytkownikami.
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 dla 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ń.
| Encja | Directories | 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, mają różne skuteczne maski dla operacji na plikach. Jeśli maska jest określona w danym żądaniu, 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, że będzie potrzebny lepki bit. 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 administratora ($superuser).
Bit sticky nie jest wyświetlany w witrynie Azure Portal.
Domyślne uprawnienia do nowych plików i katalogów
Gdy nowy plik lub katalog jest tworzony w istniejącym katalogu, domyślna lista ACL w katalogu nadrzędnym określa:
- domyślną listę ACL i listę ACL dostępu katalogu podrzędnego;
- listę ACL dostępu pliku podrzędnego (pliki nie mają domyślnej listy ACL);
umask
Podczas tworzenia domyślnej listy ACL maska umask jest stosowana do listy ACL dostępu w celu określenia początkowych uprawnień domyślnej listy ACL. Jeśli domyślna lista ACL jest zdefiniowana w katalogu nadrzędnym, maska umask jest skutecznie ignorowana, a domyślna lista ACL katalogu nadrzędnego jest używana do definiowania tych wartości początkowych.
Maska umask jest wartością 9-bitową 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 stała ustawiona na wartość 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 listę ACL dostępu nadrzędnego do domyślnej listy ACL elementu podrzędnego |
| umask.owning_group | 0 | --- |
W przypadku grupy będącą właścicielem skopiuj listę ACL dostępu elementu nadrzędnego do domyślnej listy ACL elementu podrzędnego |
| umask.other | 7 | RWX |
W przypadku innych opcji usuń wszystkie uprawnienia do listy ACL dostępu do elementu podrzędnego |
Często zadawane pytania
Czy muszę włączyć obsługę list ACL?
L.p. 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ń Entra firmy Microsoft jako przypisanego podmiotu zabezpieczeń we wpisie listy ACL. Unikaj bezpośredniego przypisywania poszczególnych użytkowników lub zleceniodawców usług. Użycie tej struktury umożliwia 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 dodawać lub usuwać użytkowników i jednostki usługi z odpowiedniej grupy zabezpieczeń firmy Microsoft Entra.
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) pozyskiwa dane do tego folderu. 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żesz utworzyć grupę LogsWriter i grupę LogsReader . Następnie można przypisać uprawnienia w następujący sposób:
- Dodaj grupę
LogsWriterdo listy ACL katalogu /LogData z uprawnieniamirwx. - Dodaj grupę
LogsReaderdo listy ACL katalogu /LogData z uprawnieniamir-x. - Dodaj do grupy obiekt jednostki usługi lub tożsamość usługi zarządzanej (MSI) dla usługi
LogsWritersADF. - Dodaj użytkowników w zespole inżynierów usług do
LogsWritergrupy. - Dodaj do grupy obiekt jednostki usługi lub tożsamość usługi zarządzanej
LogsReaderdla 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 podstawowej grupy i dodawanie członków przy użyciu identyfikatora Entra firmy Microsoft.
Ważne
Usługa Azure Data Lake Storage Gen2 zależy od identyfikatora entra firmy Microsoft do zarządzania grupami zabezpieczeń. Identyfikator Entra firmy Microsoft zaleca ograniczenie członkostwa w grupie dla danego podmiotu zabezpieczeń do mniej niż 200. To zalecenie jest spowodowane ograniczeniem tokenów sieci Web JSON (JWT), które zapewniają informacje o członkostwie podmiotu zabezpieczeń w aplikacjach firmy Microsoft Entra. Przekroczenie tego limitu może prowadzić do nieoczekiwanych problemów z wydajnością usługi Data Lake Storage Gen2. Aby dowiedzieć się więcej, zobacz Konfigurowanie oświadczeń grup dla aplikacji przy użyciu identyfikatora Entra firmy Microsoft.
W jaki sposób są oceniane uprawnienia kontroli dostępu opartej na rolach platformy Azure i listy ACL?
Aby dowiedzieć się, jak system ocenia RBAC platformy Azure i listy ACL razem w celu podejmowania decyzji dotyczących autoryzacji dla zasobów konta magazynu, zobacz Jak są oceniane uprawnienia.
Jakie są limity przypisań ról platformy Azure i wpisów listy ACL?
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 w celu zarządzania uprawnieniami "gruboziarnistymi" (uprawnieniami dotyczącymi kont magazynu lub kontenerów) oraz używanie list ACL do zarządzania uprawnieniami "szczegółowe" (uprawnienia stosowane do plików i katalogów). Użyj grup zabezpieczeń dla przypisań listy ACL. Korzystając z grup, mniej prawdopodobne jest przekroczenie maksymalnej liczby przypisań ról na subskrypcję i maksymalnej liczby wpisów listy ACL na plik lub katalog.
| Mechanizm | Scope | 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. |
4000 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. Listy ACL dostępu i domyślne listy ACL mają własny limit wynoszący 32 wpisy ACL. | 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 ponownie dodać, zaktualizować lub usunąć listy ACL 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 administratora,
Or
- 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 katalog główny "/" nigdy nie może zostać usunięty.
KtoTo 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 ramach którego jest tworzony nowy plik lub katalog.
Jestem właścicielem pliku, ale nie mam wymaganych uprawnień RWX. Co należy 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 nie istnieje już w firmie Microsoft Entra. Zazwyczaj dzieje się tak, gdy użytkownik opuścił firmę lub jeśli konto zostało usunięte w identyfikatorze Entra firmy Microsoft. 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). Aby wyczyścić listy ACL, usuń ręcznie te wpisy identyfikatora GUID.
Jak mogę 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 dla utworzonej rejestracji aplikacji. Należy pamiętać, że zarejestrowane aplikacje mają oddzielną jednostkę usługi w określonej dzierżawie firmy Microsoft Entra. Zarejestrowane aplikacje mają identyfikator OID widoczny w witrynie Azure Portal, ale jednostka usługi ma inny (inny) identyfikator OID.
Artykuł Aby uzyskać identyfikator OID 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 uzyskania identyfikatora OID dla jednostki usługi odpowiadającej rejestracji aplikacji za pomocą identyfikatora 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 Eksplorator usługi Storage Zarządzanie dostępem, aby dodać identyfikator OID i przypisać odpowiednie uprawnienia dla identyfikatora OID. Upewnij się, że wybrano pozycję Zapisz
Czy mogę ustawić listę ACL kontenera?
L.p. 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 Ustaw listę ACL kontenerów, ale tej operacji nie można użyć do ustawienia listy ACL kontenera lub katalogu głównego kontenera. Zamiast tego ta operacja służy do wskazywania, czy do obiektów blob w kontenerze można uzyskać dostęp za pomocą żądania anonimowego. Zalecamy wymaganie autoryzacji dla wszystkich żądań do danych obiektów blob. Aby uzyskać więcej informacji, zobacz Omówienie: korygowanie anonimowego dostępu do odczytu dla danych obiektów blob.
Gdzie można dowiedzieć się więcej na temat modelu kontroli dostępu POSIX?
- Listy kontroli dostępu w modelu POSIX w systemie Linux
- Przewodnik po uprawnieniach systemu plików HDFS
- POSIX — często zadawane pytania
- POSIX 1003.1 2008
- POSIX 1003.1 2013
- POSIX 1003.1 2016
- Listy ACL modelu POSIX w systemie Ubuntu