Поделиться через

Управление доступом в Azure Data Lake Storage 1-го поколения

Azure Data Lake Storage 1-го поколения реализует модель управления доступом, наследуемую от HDFS, которая, в свою очередь, является производным от модели управления доступом POSIX. В этой статье приведены основы модели управления доступом для Data Lake Storage 1-го поколения.

Списки управления доступом в файлах и папках

Существует два типа списков управления доступом (ACL), списки управления доступом и списки управления доступом по умолчанию.

  • Списки управления доступом (ACL): они контролируют доступ к объекту. Файлы и папки имеют списки управления доступом (ACLs).

  • Списки управления доступом по умолчанию: шаблон списков управления доступом, связанный с папкой, которая определяет списки управления доступом для всех дочерних элементов, созданных в этой папке. Файлы не имеют список управления доступом по умолчанию.

Оба списка управления доступом (ACL) и списки ACL по умолчанию имеют одинаковую структуру.

Замечание

Изменение ACL по умолчанию для родительского элемента не влияет на ACL доступа или ACL по умолчанию у уже существующих дочерних элементов.

Разрешения

Разрешения для объекта файловой системы : чтение, запись и выполнение, а также их можно использовать в файлах и папках, как показано в следующей таблице:

Файл Папка
Чтение (R) Чтение содержимого файла Требуется чтение и выполнение для перечисления содержимого папки
Запись (W) Можно записывать или добавлять данные в файл Требуется запись и выполнение для создания дочерних элементов в папке
Разрешение на выполнение (X) Не означает ничего в контексте Data Lake Storage 1-го поколения Требуется для обхода дочерних элементов папки

Сокращённые формы для разрешений

RWX используется для указания чтение + запись + выполнение. Существует еще более краткая форма — цифровая, согласно которой чтение = 4, запись = 2, выполнение = 1, а их сумма выражает предоставленные разрешения. Ниже приводятся некоторые примеры.

Цифровая форма Краткая форма Что это означает
7 RWX чтение, запись и выполнение
5 R-X Чтение + выполнение
4 R-- Читайте
0 --- Нет разрешений

Разрешения не наследуются

В модели стиля POSIX, используемой Data Lake Storage 1-го поколения, разрешения для элемента хранятся в самом элементе. Другими словами, разрешения для элемента не могут быть унаследованы от родительских элементов.

Ниже приведены некоторые распространенные сценарии, которые помогут вам понять, какие разрешения необходимы для выполнения определенных операций с учетной записью Data Lake Storage 1-го поколения.

Операция Объект / Сиэтл/ Portland/ Data.txt
Читайте Данные.txt --X --X --X R--
Добавить к Data.txt --X --X --X -W-
Удалить Data.txt --X --X -WX ---
Создайте Data.txt --X --X -WX ---
Список / R-X --- --- ---
Список /Сиэтл/ --X R-X --- ---
Список /Сиэтл/Портленд/ --X --X R-X ---

Замечание

Для удаления файла не требуются разрешения на запись в файл, если верны два предыдущих условия.

Пользователи и идентификации

Каждый файл и папка имеют различные разрешения для этих удостоверений:

  • Владелец
  • владельческая группа
  • именованные пользователи;
  • именованные группы;
  • все остальные пользователи.

Удостоверения пользователей и групп — это удостоверения Microsoft Entra. Поэтому, если иное не указано, пользователь в контексте Data Lake Storage 1-го поколения может означать пользователя Microsoft Entra или группу безопасности Microsoft Entra.

Суперпользователь

Суперпользователь имеет больше прав, чем все другие пользователи в учетной записи Data Lake Storage версии 1. Суперпользователь:

  • обладает разрешениями RWX для всех файлов и папок;
  • может изменять разрешения для любых файлов или папок;
  • может изменять владельца или группу владельцев любого файла или папки.

Все пользователи, которые являются частью роли «Владельцы» для учетной записи Data Lake Storage 1-го поколения, автоматически являются супер-пользователями.

Владелец

Пользователь, создавший элемент, автоматически становится владельцем элемента. Владелец может:

  • Изменить права доступа к файлу, владельцем которого вы являетесь.
  • изменить группу владельца файла, которым он владеет, если пользователь-владелец одновременно является участником целевой группы.

Замечание

Пользователь-владелец не может изменить владельца файла или папки. Только суперпользователи могут изменять владельца файла или папки.

группа владельцев;

Основные сведения

В списке ACL POSIX каждый пользователь связан с "основной группой". Например, пользователь "Алиса" может принадлежать группе "finance". Алиса также может принадлежать нескольким группам, но одна группа всегда назначается в качестве основной группы. Когда Алиса создает файл в POSIX, его группой владельцев становится ее основная группа — "финансы". В противном случае группа владельцев назначается в соответствии с назначенными разрешениями для других пользователей и групп.

Поскольку в Data Lake Storage Gen1 не связана "основная группа" с пользователями, группа владельцев назначается следующим образом.

Назначение группы владельцев для нового файла или папки

  • Случай 1. Корневая папка "/". Эта папка создается при создании учетной записи Data Lake Storage 1-го поколения. В этом случае группа владельцев имеет значение GUID, состоящий из одних нулей. Это значение не разрешает никакого доступа. Это временный элемент до тех пор, пока не будет назначена группа.
  • Случай 2 (каждый другой случай): при создании нового элемента группа владельцев копируется из родительской папки.

Изменение группы владельцев

Группа владельцев может быть изменена:

  • Любые суперпользователи.
  • владелец, если владелец также является участником целевой группы.

Замечание

Группа владельцев не может изменить списки управления доступом к файлу или папке.

Для учетных записей, созданных до сентября 2018 года, группа владельцев была задана пользователю, создавшему учетную запись в случае корневой папки для дела 1 выше. Одна учетная запись пользователя недопустима для предоставления разрешений через группу владельцев, поэтому разрешения не предоставляются этим параметром по умолчанию. Вы можете назначить это разрешение допустимой группе пользователей.

Алгоритм проверки доступа

Следующий псевдокод представляет алгоритм проверки доступа для учетных записей Data Lake Storage 1-го поколения.

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)

Маска

Как показано в алгоритме проверки доступа, маска ограничивает доступ для именованных пользователей, группы владельцев и именованных групп.

Замечание

Для новой учетной записи Data Lake Storage Gen1 маска для Access ACL корневой папки ("/") по умолчанию равна RWX.

Бит фиксации

Липкий бит является более расширенной функцией файловой системы POSIX. В контексте Data Lake Storage 1-го поколения вряд ли потребуется липкий бит. В общем, если битовая метка включена в папке, дочерний элемент может быть удален или переименован только пользователем, владеющим дочерним элементом.

Липкий бит не отображается на портале Azure.

Разрешения по умолчанию для новых файлов и папок

При создании нового файла или папки в существующей папке ACL по умолчанию в родительской папке определяется:

  • ACL по умолчанию и ACL доступа дочерней папки.
  • Доступ к ACL дочернего файла (файлы не имеют ACL по умолчанию).

umask

При создании файла или папки umask используется для изменения настройки списков управления доступом по умолчанию для дочернего элемента. umask — это 9-разрядное значение в родительских папках, содержащее значение RWX для владельца, владеющей группы и остальных.

Umask для Azure Data Lake Storage 1-го поколения является константным значением, равным 007. Это значение преобразуется в

Компонент umask Числовая форма Краткая форма Значение
umask.owning_user 0 --- Для владения пользователем скопируйте ACL родительского элемента по умолчанию в ACL доступа дочернего пользователя.
umask.owning_group 0 --- Для владеющей группы скопируйте стандартный ACL родительского элемента в ACL доступа дочернего элемента.
umask.other 7 RWX Для других удалите все разрешения на доступ к ACL дочернего элемента управления доступом

Значение umask, используемое в Azure Data Lake Storage Gen1, фактически означает, что значение для других пользователей никогда не передается по умолчанию в новых дочерних элементах, независимо от того, что указано в Default ACL.

В следующем псевдокоде показано, как применяется umask при создании списков управления доступом для дочернего элемента.

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 )

Распространенные вопросы о списках управления доступом в Data Lake Storage 1-го поколения

Нужно ли мне активировать поддержку ACL?

Нет. Для учетной записи Data Lake Storage 1-го поколения всегда включен контроль доступа с помощью списков управления доступом.

Какие разрешения необходимы для рекурсивного удаления папки и его содержимого?

  • Родительская папка должна иметь разрешения на запись и выполнение .
  • Для удаления папки и каждой папки в ней требуются разрешения на чтение и запись и выполнение .

Замечание

Вам не нужны разрешения на запись для удаления файлов в папках. Кроме того, корневую папку "/" нельзя удалить.

Кто является владельцем файла или папки?

Создатель файла или папки становится владельцем.

Какая группа устанавливается как группа владельцев файла или папки при создании?

Группа владения копируется из группы владельцев родительской папки, в которой создается новый файл или папка.

Я являюсь владельцем файла, но у меня нет необходимых разрешений RWX. Чем я занимаюсь?

Владелец может изменить разрешения на доступ к файлу на любое из требуемых RWX-разрешений.

Когда я просматриваю списки управления доступом на портале Azure, я вижу имена пользователей, но через API, я вижу идентификаторы GUID, почему это так?

Записи в ACL хранятся в виде идентификаторов GUID, соответствующих пользователям в Microsoft Entra ID. API возвращают идентификаторы GUID как есть. Портал Azure пытается упростить использование списков управления доступом, превратив идентификаторы GUID в понятные имена, когда это возможно.

Почему иногда идентификаторы GUID отображаются в списках управления доступом при использовании портала Azure?

Идентификатор GUID отображается, когда пользователь больше не существует в Microsoft Entra. Обычно это происходит, когда пользователь покинул компанию или если ее учетная запись была удалена в идентификаторе Microsoft Entra. Кроме того, убедитесь, что вы используете правильный идентификатор для настройки списков управления доступом (сведения, указанные ниже).

При использовании субъекта-службы какой идентификатор следует использовать для задания списков управления доступом?

На портале Azure перейдите к идентификатору Microsoft Entra —> корпоративным приложениям и выберите свое приложение. Вкладка "Обзор " должна отображать идентификатор объекта, и это то, что следует использовать при добавлении списков управления доступом к данным (а не идентификатора приложения).

Поддерживает ли Data Lake Storage 1-го поколения наследование списков управления доступом?

Нет, но списки ACL по умолчанию можно использовать для задания списков управления доступом для дочерних файлов и папок, только что созданных в родительской папке.

Каковы ограничения для записей ACL в файлах и папках?

32 списков управления доступом можно задать для каждого файла и каталога. Списки ACL для доступа и по умолчанию имеют собственное ограничение в размере 32 записей. По возможности используйте группы безопасности для назначений ACL. С помощью групп вероятность превышения максимального количества записей ACL для каждого файла или каталога меньше.

Где можно получить дополнительную информацию о модели контроля доступа POSIX?

См. также

  • Last updated on