Access control in Azure Data Lake Storage Gen1 (Kontrola dostępu w usłudze Azure Data Lake Storage Gen1)

  • Artykuł

Azure Data Lake Storage Gen1 implementuje model kontroli dostępu pochodzący z systemu plików HDFS, który z kolei pochodzi z modelu kontroli dostępu POSIX. Ten artykuł zawiera podsumowanie podstaw modelu kontroli dostępu dla Data Lake Storage Gen1.

Listy kontroli dostępu do plików i folderów

Istnieją dwa typy list kontroli dostępu (ACL) — Listy ACL dostępu i Domyślne listy ACL.

  • Listy ACL dostępu: listy te kontrolują dostęp do obiektu. Pliki i foldery mają listy ACL dostępu.

  • Domyślne listy ACL: „szablon” list ACL skojarzonych z folderem, który określa listy ACL dostępu dla wszelkich elementów podrzędnych, które zostały utworzone w tym folderze. Pliki nie mają domyślnych list ACL.

Zarówno listy ACL dostępu, jak i domyślne listy ACL mają tę 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ą.

Uprawnienia

Uprawnienia do obiektu systemu plików to uprawnienia do odczytu, zapisu i wykonania. Mogą one być używane w stosunku do plików i folderów, jak pokazano w poniższej tabeli:

File Folder
Odczyt (R) Może odczytywać zawartości pliku Wymaga uprawnień do odczytu i wykonania, aby wyświetlać listę zawartości folderu
Zapis (W) Może zapisywać w pliku lub dołączać do pliku Wymaga uprawnień do zapisu i wykonania, aby tworzyć elementy podrzędne w folderze
Wykonanie (X) Nie oznacza niczego w kontekście Data Lake Storage Gen1 Wymagane w przypadku przechodzenia między elementami podrzędnymi w folderze

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-- Read
0 --- Brak uprawnień

Uprawnienia nie są dziedziczone

W modelu w stylu POSIX używanym przez Data Lake Storage Gen1 uprawnienia do elementu są przechowywane w samym elemencie. Innymi słowy, uprawnienia dla elementu nie mogą być dziedziczone z elementów nadrzędnych.

Poniżej przedstawiono kilka typowych scenariuszy, które ułatwiają zrozumienie, które uprawnienia są potrzebne do wykonywania niektórych operacji na koncie Data Lake Storage Gen1.

Operacja Obiekt / Seattle/ Portland/ Data.txt
Read Data.txt --X --X --X R--
Dołącz do Data.txt --X --X --X -W-
Usuń Data.txt --X --X -WX ---
Utwórz Data.txt --X --X -WX ---
Lista / R-X --- --- ---
Lista /Seattle/ --X R-X --- ---
Lista /Seattle/Portland/ --X --X R-X ---

Uwaga

Uprawnienia do zapisu dla pliku nie są wymagane do usunięcia go, jeśli dwa poprzednie warunki pozostają spełnione.

Użytkownicy i tożsamości

Każdy plik i folder ma różne uprawnienia do tych tożsamości:

  • Użytkownik będący właścicielem
  • Grupa będąca właścicielem
  • Użytkownicy nazwani
  • Grupy nazwane
  • Wszyscy pozostali użytkownicy

Tożsamości użytkowników i grup są Microsoft Entra tożsamościami. Dlatego, o ile nie określono inaczej, "użytkownik", w kontekście Data Lake Storage Gen1, może oznaczać użytkownika Microsoft Entra lub Microsoft Entra grupy zabezpieczeń.

Administrator

Administrator ma najwięcej praw wszystkich użytkowników na koncie Data Lake Storage Gen1. 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.

Wszyscy użytkownicy będący częścią roli Właściciele konta Data Lake Storage Gen1 są automatycznie administratorami.

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ący właścicielem nie może zmienić użytkownika będącego właścicielem pliku lub folderu. Tylko administratorzy mogą zmieniać użytkowników będących właścicielami pliku lub folderu.

Grupa będąca właścicielem

Tło

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 jej grupa główna. 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.

Ponieważ nie istnieje "grupa podstawowa" skojarzona z użytkownikami w Data Lake Storage Gen1, grupa będąca właścicielem jest przypisana tak, jak pokazano poniżej.

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

  • Przypadek 1: folder główny „/”. Ten folder jest tworzony podczas tworzenia konta Data Lake Storage Gen1. W tym przypadku grupa będąca właścicielem jest ustawiona na identyfikator GUID all-zero. Ta wartość nie zezwala na dostęp. Jest to symbol zastępczy do momentu przypisania takiej grupy.
  • Przypadek 2 (każdy inny przypadek): gdy tworzony jest nowy element, grupa będąca właścicielem jest kopiowana z folderu 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 kontroli dostępu do pliku lub folderu.

W przypadku kont utworzonych we wrześniu 2018 r. lub przed wrześniem 2018 r. grupa będąca właścicielem została ustawiona na użytkownika, który utworzył konto w przypadku folderu głównego dla sprawy 1 powyżej. Jedno konto użytkownika nie jest prawidłowe w przypadku udzielania uprawnień za pośrednictwem grupy będącą właścicielem, dlatego do tego ustawienia domyślnego nie są przyznawane żadne uprawnienia. To uprawnienie można przypisać do prawidłowej grupy użytkowników.

Algorytm kontroli dostępu

Poniższy pseudokod reprezentuje algorytm sprawdzania dostępu dla kont Data Lake Storage Gen1.

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 folder
  # Note: the "sticky bit" is not illustrated in this algorithm
  
# Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask IS NOT 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.permmissions & mask) == desired_perms)

  # Handle named groups and owning group
  member_count = 0
  perms = 0
  entries = get_acl_entries( path, NAMED_GROUP | OWNING_GROUP )
  for entry in entries:
    if (user_is_member_of_group(user, entry.identity)) :
      member_count += 1
      perms | =  entry.permissions
  if (member_count>0) :
    return ((desired_perms & perms & mask ) == desired_perms)
 
  # 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.

Uwaga

W przypadku nowego konta Data Lake Storage Gen1 maska listy ACL dostępu folderu głównego ("/") domyślnie ma wartość RWX.

Atrybut sticky bit

Sticky bit jest bardziej zaawansowaną funkcją systemu plików POSIX. W kontekście Data Lake Storage Gen1 jest mało prawdopodobne, aby bit lepki będzie potrzebny. Podsumowując, jeśli bit sticky jest włączony w folderze, element podrzędny można usunąć lub zmienić nazwę tylko przez użytkownika elementu podrzędnego.

Atrybut sticky bit nie jest wyświetlany w witrynie Azure Portal.

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

Gdy nowy plik lub folder jest tworzony w istniejącym folderze, domyślna lista ACL w folderze nadrzędnym określa:

  • domyślną listę ACL i listę ACL dostępu folderu podrzędnego;
  • listę ACL dostępu pliku podrzędnego (pliki nie mają domyślnej listy ACL);

umask

Podczas tworzenia pliku lub folderu maska umask służy do modyfikowania sposobu ustawiania domyślnych list ACL w elemencie podrzędnym. maska umask to wartość 9-bitowa w folderach 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 Azure Data Lake Storage Gen1 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ę ACL 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 Azure Data Lake Storage Gen1 skutecznie oznacza, że wartość dla innych nigdy nie jest domyślnie przekazywana dla nowych elementów podrzędnych — niezależnie od tego, co wskazuje domyślna lista ACL.

Poniższy kod pseudokodowy 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 dotyczące list ACL w usłudze Data Lake Storage Gen1

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

Nie. Kontrola dostępu za pośrednictwem list ACL jest zawsze włączona dla konta Data Lake Storage Gen1.

Jakie uprawnienia są wymagane do rekursywnego usunięcia folderu i jego zawartości?

  • Folder nadrzędny musi mieć uprawnienia do zapisu i wykonania.
  • Folder do usunięcia i każdy folder w tym folderze muszą mieć uprawnienia do odczytu, zapisu i wykonania.

Uwaga

Do usuwania plików w folderach nie potrzebujesz uprawnienia do zapisu. Ponadto nigdy nie można usunąć folderu głównego „/”.

Kto jest właścicielem pliku lub folderu?

Twórca pliku lub folderu staje się jego właścicielem.

Jaka grupa zostaje ustawiona jako grupa będąca właścicielem pliku lub folderu w momencie jego tworzenia?

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

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.

Na listach ACL przeglądanych w witrynie Azure Portal są widoczne nazwy użytkowników, natomiast w przypadku korzystania z interfejsów API wyświetlane są identyfikatory GUID. Dlaczego?

Wpisy w listach ACL są przechowywane jako identyfikatory GUID odpowiadające użytkownikom w Tożsamość Microsoft Entra. Interfejsy API zwracają identyfikator GUID w faktycznej postaci. Witryna Azure Portal stara się ułatwić korzystanie z list ACL, dlatego identyfikatory GUID są w miarę możliwości zamieniane na przyjazne nazwy.

Dlaczego na listach ACL w witrynie Azure Portal są czasami wyświetlane identyfikatory GUID?

Identyfikator GUID jest wyświetlany, gdy użytkownik już nie istnieje w Microsoft Entra. Zwykle dzieje się tak, gdy użytkownik opuścił firmę lub jeśli jego konto zostało usunięte w Tożsamość Microsoft Entra. Upewnij się również, że używasz odpowiedniego identyfikatora do ustawiania list ACL (szczegóły, o których mowa poniżej).

W przypadku korzystania z jednostki usługi jakiego identyfikatora należy użyć do ustawiania list ACL?

W witrynie Azure Portal przejdź do pozycji Tożsamość Microsoft Entra —> Aplikacje dla przedsiębiorstw i wybierz aplikację. Na karcie Przegląd powinien zostać wyświetlony identyfikator obiektu, który powinien być używany podczas dodawania list ACL na potrzeby dostępu do danych (a nie identyfikatora aplikacji).

Czy Data Lake Storage Gen1 obsługuje dziedziczenie list ACL?

Nie, ale domyślne listy kontroli dostępu mogą być używane do ustawienia list ACL dla podrzędnych plików i folderów, które zostały nowo utworzone w folderze nadrzędnym.

Jakie są limity dla wpisów listy ACL w plikach i folderach?

32 list ACL można ustawić dla każdego pliku i na katalog. Listy ACL dostępu i domyślne listy ACL mają własny limit wynoszący 32 wpisy ACL. Jeśli to możliwe, użyj grup zabezpieczeń dla przypisań listy ACL. Przy użyciu grup mniej prawdopodobne jest przekroczenie maksymalnej liczby wpisów listy ACL na plik lub katalog.

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

Zobacz też