Списки управления доступом (ACL) в Azure Data Lake Storage 2-го поколения

  • Статья

В Azure Data Lake Storage 2-го поколения реализована модель управления доступом, которая поддерживает управление доступом на основе ролей в Azure (Azure RBAC) и списки управления доступом (ACL), соответствующие стандарту POSIX. В этой статье описываются списки управления доступом в Data Lake Storage 2-го поколения. Сведения о том, как внедрить Azure RBAC вместе с ACL и как система оценивает их для принятия решений об авторизации, см. в разделе Модель управления доступом в Azure Data Lake Storage 2-го поколения.

Сведения об ACL

Субъект безопасности можно связать с уровнем доступа для файлов и каталогов. Каждая связь фиксируется в виде записи в списке управления доступом (ACL). Список управления доступом есть у каждого файла и каталога в учетной записи хранения. Когда субъект безопасности пытается выполнить операцию в файле или каталоге, ACL проверка определяет, имеет ли этот субъект безопасности (пользователь, группа, субъект-служба или управляемое удостоверение) правильный уровень разрешений для выполнения операции.

Примечание.

Списки управления доступом применяются только к субъектам безопасности в одном клиенте и не применяются к пользователям, использующим проверку подлинности с использованием общего ключа или подписанного URL-адреса (SAS). Это связано с тем, что с вызывающим объектом не связано удостоверение, поэтому не удается выполнить авторизацию на основе разрешений субъекта безопасности.

Руководство по настройке ACL

Сведения о задании разрешений на уровне файлов и каталогов см. в следующих статьях:

Среда Статья
Обозреватель службы хранилища Azure Использование обозревателя службы хранилища Microsoft Azure для управления списками ACL в Azure Data Lake Storage 2-го поколения
Портал Azure Использование портала Azure для управления списками ACL в Azure Data Lake Storage 2-го поколения
.NET Использование .NET для управления списками ACL в Azure Data Lake Storage 2-го поколения
Java Использование Java для управления списками ACL в Azure Data Lake Storage 2-го поколения
Python Использование Python для управления списками ACL в Azure Data Lake Storage 2-го поколения
JavaScript (Node.js) Использование JavaScript SDK в Node.js для управления списками ACL в Azure Data Lake Storage 2-го поколения
PowerShell Использование PowerShell для управления списками ACL в Azure Data Lake Storage 2-го поколения
Azure CLI Использование Azure CLI для управления списками ACL в Azure Data Lake Storage 2-го поколения
REST API Путь — обновление

Внимание

Если субъект безопасности является субъектом-службой, важно использовать идентификатор объекта субъекта-службы, а не идентификатор объекта соответствующей регистрации приложения. Чтобы получить идентификатор объекта субъекта-службы, откройте Azure CLI, а затем используйте следующую команду: az ad sp show --id <Your App ID> --query objectId. Обязательно замените <Your App ID> заполнитель идентификатором приложения регистрации приложения. Субъект-служба рассматривается как именованный пользователь. Вы добавите этот идентификатор в ACL, как и любой именованный пользователь. Именованные пользователи описаны далее в этой статье.

Типы списков ACL

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

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

ACL по умолчанию — это шаблоны ACL, связанные с каталогом, которые определяют ACL для доступа для всех дочерних элементов, создаваемых в этом каталоге. У файлов нет списков ACL по умолчанию.

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

Примечание.

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

Уровни разрешений

К объекту-контейнеру применяются такие разрешения на каталоги и файлы, как Чтение, Запись и Выполнение, и их можно использовать для файлов и каталогов, как показано в следующей таблице:

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

Примечание.

Если разрешения предоставляются только с помощью ACL (без Azure RBAC), то чтобы предоставить субъекту безопасности доступ к файлу на чтение или запись, необходимо предоставить субъекту безопасности разрешения на выполнение для корневой папки контейнера, а также для каждой папки в иерархии папок, которая ведет к файлу.

Сокращения для разрешений

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

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

Наследование разрешений

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

В следующей таблице показаны записи ACL, необходимые для включения субъекта безопасности для выполнения операций, перечисленных в столбце Операция.

В этой таблице показан столбец, отражающий каждый уровень вымышленной иерархии каталогов. Есть столбец для корневого каталога контейнера (/), подкаталог с именем Oregon, вложенный каталог Portland в каталоге Oregon, и текстовый файл с именем Data.txt в каталоге Portland.

Внимание

В этой таблице предполагается, что вы используете только списки ACL без назначений ролей Azure. Чтобы просмотреть аналогичную таблицу, которая объединяет Azure RBAC вместе с списками управления доступом, см . таблицу разрешений: объединение azure RBAC, ABAC и списков управления доступом.

Операция / Каталог Oregon/ Portland/ Data.txt
Чтение файла Data.txt --X --X --X R--
Добавление в файл Data.txt --X --X --X RW-
Удаление файла Data.txt --X --X -WX ---
Delete /Oregon/ -WX RWX RWX ---
Delete /Oregon/Portland/ --X -WX RWX ---
Создание файла Data.txt --X --X -WX ---
Перечисление / R-X --- --- ---
Перечисление для каталога /Oregon/ --X R-X --- ---
Перечисление для каталога /Oregon/Portland/ --X --X R-X ---

Удаление файлов и каталогов

Как показано в предыдущей таблице, разрешения на запись в файле не требуются, пока разрешения каталога заданы должным образом. Однако для удаления каталога и всего его содержимого родительский каталог должен иметь разрешения на запись и выполнение. Чтобы удалить каталог и все вложенные в него каталоги, требуются разрешения на чтение, запись и выполнение.

Примечание.

Корневой каталог "/" никогда не может быть удален.

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

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

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

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

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

Супер-пользователь имеет большинство прав всех пользователей. Суперпользователь:

  • обладает разрешениями RWX для всех файлов и папок;

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

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

Если контейнер, файл или каталог создается с помощью общего ключа, SAS учетной записи или SAS службы, то для владельца и группы владельца задано значение $superuser.

Владелец

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

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

Примечание.

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

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

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

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

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

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

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

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

Примечание.

Группа владельцев не может изменить списки ACL для файла или каталога. Если группа владельцев закрепляется за пользователем, который создал учетную запись с корневым каталогом (случай 1 выше), одна учетная запись пользователя не может предоставлять разрешения группе владельцев. Разрешение можно назначить допустимой группе пользователей, если это применимо.

Оценка разрешений

Удостоверения оцениваются в следующем порядке:

  1. суперпользователь;
  2. владельца
  3. именованный пользователь, субъект-служба или управляемое удостоверение;
  4. группа владельцев или именованная группа;
  5. все остальные пользователи.

Если к субъекту безопасности применяется более одного удостоверения, то предоставляется уровень разрешений, связанный с первым удостоверением. Например, если субъект безопасности является и пользователем-владельцем, и именованным пользователем, то применяется уровень разрешений, связанный с пользователем-владельцем.

Именованные группы рассматриваются все вместе. Если субъект безопасности является членом нескольких именованных групп, система оценивает каждую группу, пока не будет предоставлено требуемое разрешение. Если ни одна из именованных групп не предоставляет требуемое разрешение, система переходит к оценке запроса на соответствие разрешению, связанному со всеми остальными пользователями.

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

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 directory
  # Note: the "sticky bit" isn't illustrated in this algorithm

  # Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask isn't 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.permissions & mask) == desired_perms)

  # Handle named groups and owning group
  member_count = 0
  perms = 0
  entries = get_acl_entries( path, NAMED_GROUP | OWNING_GROUP )
  mask = get_mask( path )
  for entry in entries:
    if (user_is_member_of_group(user, entry.identity)) :
        if ((desired_perms & entry.permissions & mask) == desired_perms)
            return True

  # Handle other
  perms = get_perms_for_other(path)
  mask = get_mask( path )
  return ( (desired_perms & perms & mask ) == desired_perms)

Маска

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

Для нового контейнера Data Lake Storage 2-го поколения маска для списка ACL корневого каталога ("/") по умолчанию имеет значение 750 для каталогов и 640 для файлов. В следующей таблице показана символьная нотация этих уровней разрешений.

Объект Directories Файлы
владельца rwx rw-
Группа владельцев r-x r--
Другие --- ---

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

Маску можно указать для каждого вызова. Это позволяет установить для разных потребляющих систем, например кластеров, разные действующие маски для файловых операций. Если маска указана в конкретном запросе, она полностью переопределяет маску по умолчанию.

Бит фиксации

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

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

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

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

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

umask

При создании ACL по умолчанию umask применяется к ACL доступа, чтобы определить начальные разрешения ACL по умолчанию. Если для родительского каталога определен ACL по умолчанию, umask фактически не учитывается, и вместо этого для определения этих начальных значений используется ACL родительского каталога по умолчанию.

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

umask для Azure Data Lake Storage 2-го поколения является константой со значением 007. Это значение преобразуется в следующие формы:

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

Вопросы и ответы

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

№ Управление доступом с помощью списков ACL включено для учетной записи хранения, если включена функция "Иерархическое пространство имен" (HNS).

Если функция HNS выключена, будут по-прежнему применяться правила авторизации Azure RBAC.

Каким способом лучше всего применять списки ACL?

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

Имеется множество разных способов настройки групп. Предположим, что у вас есть каталог с именем /LogData, содержащий данные журнала, создаваемые сервером. Фабрика данных Azure (ADF) принимает данные в эту папку. Конкретные пользователи из группы инженеров поддержки будут отправлять журналы и управлять другими пользователями этой папки, а различные кластеры Databricks будут анализировать журналы из этой папки.

Чтобы включить эти действия, следует создать группу LogsWriter и группу LogsReader. Затем можно назначить разрешения следующим образом.

  • Добавьте группу LogsWriter в список ACL каталога /LogData с разрешениями rwx.
  • Добавьте группу LogsReader в список ACL каталога /LogData с разрешениями r-x.
  • Добавьте объект субъекта-службы или управляемое удостоверение службы (MSI) для ADF в группу LogsWriters.
  • Добавьте пользователей из группы инженеров поддержки в группу LogsWriter.
  • Добавьте объект субъекта-службы или MSI для Databricks в группу LogsReader.

Если пользователь из группы инженеров поддержки уходит из компании, можно просто удалить его из группы LogsWriter. Если вы не добавили этого пользователя в группу, а добавили для него выделенную запись списка ACL, эту запись потребуется удалить из каталога /LogData. Кроме того, необходимо удалить запись из всех подкаталогов и файлов во всей иерархии каталога /LogData.

Сведения о создании группы и добавлении участников см. в статье "Создание базовой группы" и добавление участников с помощью идентификатора Microsoft Entra.

Внимание

Azure Data Lake Storage 2-го поколения зависит от идентификатора Microsoft Entra для управления группами безопасности. Идентификатор Microsoft Entra рекомендует ограничить членство в группах для заданного субъекта безопасности менее 200. Эта рекомендация связана с ограничением веб-токенов JSON (JWT), которые предоставляют сведения о членстве субъекта безопасности в приложениях Microsoft Entra. Превышение этого ограничения может привести к непредвиденным проблемам с производительностью Data Lake Storage 2-го поколения. Дополнительные сведения см. в статье "Настройка утверждений группы для приложений с помощью идентификатора Microsoft Entra".

Как оцениваются разрешения Azure RBAC и ACL?

Сведения о том, как система оценивает Azure RBAC и списки ACL для принятия решений об авторизации ресурсов учетной записи хранения, см. в разделе Оценка разрешений.

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

В следующей таблице представлен краткий обзор ограничений, которые необходимо учитывать при использовании Azure RBAC для управления "грубыми" разрешениями (разрешения, которые применяются к учетным записям хранилища или контейнерам) и использовании ACL для управления "тонкими" разрешениями (разрешения, которые применяются к файлам и каталогам). Используйте группы безопасности для назначений списков управления доступом. С помощью групп снижается вероятность превышения максимального количества назначений ролей в каждой подписке и максимального количества записей ACL для каждого файла или каталога.

Механизм Область Ограничения Поддерживаемый уровень разрешений
Azure RBAC Учетные записи хранения, контейнеры.
Назначения ролей между ресурсами Azure на уровне подписки или группы ресурсов.		 4000 назначений ролей Azure в подписке Роли Azure (встроенные или пользовательские)
ACL Каталог, файл 32 записи ACL (фактически 28 записей ACL) для каждого файла и каталога. Списки ACL для доступа и по умолчанию имеют собственное ограничение в размере 32 записей. Разрешение ACL

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

Назначения ролей Azure наследуются. Назначения передаются из подписки, группы ресурсов и ресурсов учетных записей хранения в ресурс контейнера.

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

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

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

  • Наличие у вызывающей стороны разрешений суперпользователя,

Or

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

Примечание.

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

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

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

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

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

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

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

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

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

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

При определении списков управления доступом для субъектов-служб важно использовать идентификатор объекта (OID) субъекта-службы для созданной регистрации приложения. Важно отметить, что зарегистрированные приложения имеют отдельный субъект-службу в определенном клиенте Microsoft Entra. Идентификатор объекта зарегистрированных приложений виден на портале Azure, но у субъекта-службы будет другой (отличающийся) OID. Статья. Чтобы получить OID субъекта-службы, соответствующий регистрации приложения, можно использовать команду az ad sp show. Укажите идентификатор приложения в качестве параметра. Ниже приведен пример получения идентификатора OID для субъекта-службы, соответствующего регистрации приложения с идентификатором приложения 18218b12-1895-43e9-AD80-6e8fc1ea88ce. Выполните указанную ниже команду в Azure CLI.

az ad sp show --id 18218b12-1895-43e9-ad80-6e8fc1ea88ce --query objectId

Появится OID.

Если у субъекта-службы правильный идентификатор объекта, перейдите на страницу Управление доступом Обозревателя службы хранилища, чтобы добавить OID и назначить соответствующие разрешения для OID. Обязательно выберите Сохранить.

Можно ли задать список управления доступом для контейнера?

№ Контейнер не имеет ACL. Однако можно задать список управления доступом для корневого каталога контейнера. Каждый контейнер имеет корневой каталог и имеет то же имя, что и контейнер. Например, если контейнер называется my-container, то корневой каталог будет называться my-container/.

REST API службы хранилища Azure содержит операцию Set Container ACL, но эту операцию нельзя использовать для задания ACL контейнера или корневого каталога контейнера. Вместо этого эта операция используется для указания того, могут ли большие двоичные объекты в контейнере получить доступ к анонимному запросу. Мы рекомендуем авторизации для всех запросов к данным BLOB-объектов. Дополнительные сведения см. в статье "Обзор: устранение анонимного доступа на чтение для данных BLOB-объектов".

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

См. также