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

  • Статья

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

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

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

  • ACL для доступа. Эти списки позволяют управлять доступом к объекту. Списки ACL для доступа позволяют управлять доступом как к файлам, так и к папкам.

  • ACL по умолчанию. "Шаблон" списков управления доступом, связанных с папкой, определяющей списки ACL для доступа любого дочернего элемента, созданного в этой папке. Файлы не имеют ACL по умолчанию.

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

Примечание

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

Разрешения

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

File Папка
Разрешение на чтение (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-го поколения.

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

Примечание

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

Пользователи и удостоверения

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

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

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

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

Суперпользователь обладает самыми широкими правами среди всех пользователей учетной записи Data Lake Store 1-го поколения. Суперпользователь:

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

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

Владелец

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

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

Примечание

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

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

Фон

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

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

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

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

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

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

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

Примечание

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

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

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

В следующем псевдокоде показан алгоритм проверки доступа к учетным записям 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 1-го поколения маске для списка ACL для доступа для корневой папки (/) по умолчанию присваивается значение RWX.

Бит фиксации

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

Бит фиксации не отображается на портале Azure.

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

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

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

umask

Когда создается файл или папка, значение umask используется для изменения того, как списки ACL по умолчанию устанавливаются для дочернего элемента. 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 1-го поколения, фактически означает, что значение для других никогда не передается по умолчанию в новые дочерние элементы независимо от того, что указывает ACL по умолчанию.

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

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 )

Общие вопросы о списках ACL в хранилище Data Lake Storage 1-го поколения

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

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

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

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

Примечание

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

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

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

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

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

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

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

При просмотре списков ACL на портале Azure я вижу имена пользователей, а при просмотре в интерфейсе API — идентификаторы GUID. Почему так происходит?

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

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

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

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

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

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

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

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

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

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

См. также раздел