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

  • Artykuł
  • Czas czytania: 9 min

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. W tym artykule przedstawiono 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:

Plik 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 nic 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-- Odczyt
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 pewnych operacji na koncie Data Lake Storage Gen1.

Operacja Obiekt / Seattle/ Portland/ Data.txt
Odczyt 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ą tożsamościami usługi Azure Active Directory (Azure AD). Tak więc, chyba że zostanie zanotowany inaczej, "użytkownik", w kontekście Data Lake Storage Gen1, może oznaczać użytkownika Azure AD lub grupę zabezpieczeń Azure AD.

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

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 poSIX, gdy Alice tworzy plik, grupa będąca właścicielem tego pliku jest ustawiona na jej grupę podstawową, która w tym przypadku jest "finanse". Grupa będąca właścicielem w przeciwnym razie 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 w następujący sposób.

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 takim przypadku grupa będąca właścicielem jest ustawiona na identyfikator GUID typu all-zero. Ta wartość nie zezwala na dostęp. Jest to symbol zastępczy, dopóki taka grupa nie zostanie przypisana.
  • 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 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 kontroli dostępu do pliku lub folderu.

W przypadku kont utworzonych we wrześniu 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 celu zapewnienia uprawnień za pośrednictwem grupy właścicieli, dlatego żadne uprawnienia nie są przyznawane przez to ustawienie domyślne. 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 ("/") jest domyślnie ustawiona na 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 był 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ę ACL 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 listy ACL dostępu podrzędnego

Wartość maski umask używana przez Azure Data Lake Storage Gen1 skutecznie oznacza, że wartość dla innych nigdy nie jest domyślnie przesyłana dla nowych elementów podrzędnych — niezależnie od tego, co wskazuje domyślna lista ACL.

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 dotyczące list ACL w 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 na listach ACL są przechowywane jako identyfikatory GUID odpowiadające użytkownikom w usłudze Azure AD. 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 w przypadku, gdy dany użytkownik nie istnieje już 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. Upewnij się również, że używasz odpowiedniego identyfikatora do ustawiania list ACL (szczegóły podane 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 Azure Active Directory —> aplikacje dla przedsiębiorstw i wybierz aplikację. Karta Przegląd powinna wyświetlić identyfikator obiektu i jest to, co należy użyć 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 listy ACL można ustawić na plik 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. Korzystając z 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ż