Udostępnij za pośrednictwem

Kontrola dostępu w usłudze Azure Data Lake Storage Gen1

  • Artykuł

Usługa 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 usługi Data Lake Storage Gen1.

Listy kontroli dostępu w plikach i folderach

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

  • Listy dostępu ACL: Te kontrolują dostęp do obiektu. Zarówno pliki, jak i foldery mają listy dostępu ACL.

  • Domyślne listy ACL: "Szablon" list ACL powiązanych z folderem określający listy kontrolne dostępu dla wszystkich elementów podrzędnych tworzonych w tym folderze. Pliki nie mają domyślnych list kontroli dostępu (ACL).

Listy ACL dostępu 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 lub domyślną listę ACL elementów podrzędnych, które już istnieją.

Uprawnienia

Uprawnienia do obiektu systemu plików to odczyt, zapisi wykonanie, i mogą być stosowane do plików i folderów, jak pokazano w poniższej tabeli:

Plik Folder
Odczyt (R) Może odczytywać zawartości pliku Wymaga Odczytu oraz Wykonania, aby wyświetlić listę zawartości folderu
Zapisz (W) Może zapisywać w pliku lub dołączać do pliku Wymaga zapisywania i wykonywania w celu utworzenia elementów podrzędnych w folderze
Wykonaj (X) Nie oznacza nic w kontekście usługi Data Lake Storage Gen1 Wymagane do przechodzenia przez elementy podrzędne folderu

Krótkie formy uprawnień

Skrót RWX oznacza odczyt, zapis i wykonanie. Istnieje bardziej skondensowana postać liczbowa, w której Odczyt=4, Zapis=2 i Wykonanie=1, a ich suma reprezentuje uprawnienia. Poniżej przedstawiono kilka przykładów.

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

Uprawnienia nie dziedziczą

W modelu w stylu POSIX używanym przez usługę 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 usługi Data Lake Storage Gen1.

Operacja Przedmiot / Seattle/ Portland/ Data.txt
Przeczytaj Data.txt --X --X --X R--
Dodaj 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 w pliku nie są wymagane do usunięcia go, o ile poprzednie dwa warunki są spełnione.

Użytkownicy i tożsamości

Każdy plik i folder ma 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
  • 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 Gen1, może oznaczać użytkownika Microsoft Entra lub grupę zabezpieczeń firmy Microsoft Entra.

Superużytkownik

Administrator ma największe prawa wszystkich użytkowników na koncie usługi Data Lake Storage Gen1. Superużytkownik

  • 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ę właściciela dla dowolnego pliku lub folderu.

Wszyscy użytkownicy, którzy należą do roli właścicieli dla konta usługi Data Lake Storage Gen1, są automatycznie superużytkownikami.

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;
  • Zmienić grupę właściciela pliku, którego jest właścicielem, pod warunkiem że 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ć właściciela pliku lub folderu. Tylko superużytkownicy mogą zmieniać użytkownika właściciela 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 "alicja" 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 podstawowa. W systemie POSIX, gdy Alice tworzy plik, grupa będąca właścicielem tego pliku jest ustawiana na jej grupę podstawową, czyli na grupę "finanse". Grupa będąca właścicielem działa podobnie do przypisanych uprawnień dla innych użytkowników i grup.

Ponieważ nie istnieje "grupa podstawowa" skojarzona z użytkownikami w usłudze Data Lake Storage Gen1, grupa będąca właścicielem jest przypisana zgodnie z poniższym opisem.

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

  • Przypadek 1: folder główny "/". Ten folder jest tworzony podczas tworzenia konta usługi Data Lake Storage Gen1. W tym przypadku grupa będąca właścicielem jest ustawiona na identyfikator GUID składający się z samych zer. Ta wartość nie zezwala na dostęp. Jest to symbol zastępczy, dopóki nie zostanie przypisana taka grupa.
  • Przypadek 2 (wszystkie inne przypadki): Po utworzeniu nowego elementu grupa będąca właścicielem jest kopiowana z folderu nadrzędnego.

Zmienianie grupy właścicielskiej

Grupę właścicielską można zmienić przez:

  • superużytkownicy
  • 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ć listy ACL pliku lub folderu.

Dla kont utworzonych we wrześniu 2018 roku lub wcześniej, grupa właścicielska została ustawiona na użytkownika, który utworzył konto w przypadku folderu głównego dla Przypadku 1powyżej. Pojedyncze konto użytkownika nie umożliwia nadawania uprawnień za pośrednictwem grupy właściciela, dlatego żadne uprawnienia nie są przyznawane w ramach tego ustawienia domyślnego. To uprawnienie można przypisać do prawidłowej grupy użytkowników.

Algorytm sprawdzania dostępu

Poniższy pseudokod reprezentuje algorytm sprawdzania dostępu dla kont usługi 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, grupa będąca właścicielemi nazwanych grup.

Uwaga

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

Sticky bit

Sticky bit jest bardziej zaawansowaną funkcją systemu plików POSIX. W kontekście usługi Data Lake Storage Gen1 jest mało prawdopodobne, że będzie potrzebny lepki bit. Podsumowując, jeśli bit przyklejony jest włączony w folderze, element podrzędny może zostać usunięty lub zmieniony tylko przez użytkownika podrzędnego.

Bit klejący nie jest pokazywany w portalu Azure.

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

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

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

umask

Podczas tworzenia pliku lub folderu umask służy do zmiany sposobu ustawiania domyślnych list ACL na elementach podrzędnych. umask to wartość 9-bitowa w folderach nadrzędnych, która zawiera wartość RWX dla właściciela, grupy będącej właścicielemi pozostałych.

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

składnik umask Forma liczbowa Forma krótka Znaczenie
umask.właściciel_użytkownika 0 --- Dla użytkownika będącego właścicielem skopiuj domyślną listę ACL elementu nadrzędnego do listy dostępu ACL elementu podrzędnego.
umask.owning_group 0 --- W przypadku grupy będącej właścicielem skopiuj domyślną listę ACL obiektu nadrzędnego do listy ACL dostępu obiektu podrzędnego.
umask.other 7 RWX Dla innych usuń wszystkie uprawnienia na liście kontroli dostępu elementu podrzędnego

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

Poniższy pseudokod pokazuje, w jaki sposób umask jest stosowany podczas tworzenia list kontroli dostępu (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 )

Najczęściej zadawane pytania dotyczące listy kontroli dostępu (ACL) w usłudze Data Lake Storage Gen1

Czy muszę włączyć obsługę list kontroli dostępu (ACL)?

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

Jakie uprawnienia są wymagane do cyklicznego usuwania folderu i jego zawartości?

  • Folder nadrzędny musi mieć uprawnienia Write + Execute.
  • Folder, który ma zostać usunięty, a każdy folder w nim, wymaga uprawnień do odczytu, zapisu oraz wykonywania.

Uwaga

Nie potrzebujesz uprawnień do zapisu, aby usunąć pliki w folderach. Ponadto folder główny "/" może nigdy nie zostać usunięty.

Kto jest właścicielem pliku lub folderu?

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

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

Grupa właściciela jest kopiowana z grupy właściciela folderu nadrzędnego, w którym tworzony jest nowy plik lub folder.

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

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

Po zapoznaniu się z listami ACL w witrynie Azure Portal widzę nazwy użytkowników, ale za pośrednictwem interfejsów API widzę identyfikatory GUID, dlaczego tak jest?

Wpisy w listach kontroli dostępu (ACL) są przechowywane jako identyfikatory GUID, które odpowiadają użytkownikom w Microsoft Entra ID. Interfejsy API zwracają identyfikatory GUID bez zmian. Portal Azure próbuje ułatwić korzystanie z list kontroli dostępu (ACL), tłumacząc identyfikatory GUID na przyjazne nazwy, jeśli to możliwe.

Dlaczego czasami widzę identyfikatory GUID w listach ACL podczas korzystania z witryny Azure Portal?

Identyfikator GUID jest wyświetlany, gdy użytkownik już nie istnieje w 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. 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 ustawienia list kontroli dostępu (ACL)?

W witrynie Azure Portal przejdź do pozycji Microsoft Entra ID —> Aplikacje dla przedsiębiorstw i wybierz aplikację. Zakładka Overview (Przegląd) powinna wyświetlać identyfikator obiektu, który należy użyć podczas dodawania list ACL w celu uzyskania dostępu do danych (a nie identyfikatora aplikacji).

Czy usługa Data Lake Storage Gen1 obsługuje dziedziczenie list kontroli dostępu (ACL)?

Nie, ale domyślne listy ACL mogą służyć do ustawiania list ACL dla plików podrzędnych i folderów nowo utworzonych 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 dla każdego katalogu. Listy ACL dostępu i domyślne mają własny limit 32 wpisów. Jeśli to możliwe, używaj grup zabezpieczeń do przypisywania 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ż