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

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

Сведения об ACL

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

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

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

Типы ACL

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

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

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

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

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

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

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

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

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

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

Распространенные сценарии, связанные с разрешениями ACL

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

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

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

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

Пользователи и идентичности

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

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

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

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

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

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

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

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

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

Владеющий пользователь

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

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

группа собственников

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

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

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

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

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

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

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

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

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)

Маска

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

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

Бит фиксации

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

На портале Azure не отображается липкий бит. Дополнительные сведения о липкой бите и его настройке см. в разделе "Что такое липкий бит Data Lake Storage?"

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

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

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

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

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

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

umask

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

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

Umask для Azure Data Lake Storage является константным значением, равным 007. Это значение означает:

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

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

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

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

Как лучше всего применять списки контроля доступа (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 RBAC и ACL?

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

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

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

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

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

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

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

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

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

или

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

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

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

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

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

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

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

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

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

Как правильно установить списки контроля доступа (ACL) для учетной записи службы?

При определении списков управления доступом для служебных принципалов важно использовать идентификатор объекта (OID) служебного принципала для приложения, которое вы создали. Важно отметить, что зарегистрированные приложения имеют отдельный служебный объект в определенном экземпляре Microsoft Entra. Идентификатор объекта зарегистрированных приложений виден на портале Azure, но у представителя службы будет другой (отличающийся) OID. Статья. Чтобы получить OID субъекта-службы, соответствующий регистрации приложения, можно использовать команду az ad sp show. Укажите идентификатор приложения в качестве параметра. Вот пример получения OID для учетной записи службы, соответствующей регистрации приложения с идентификатором приложения = 00001111-aaaa-2222-bbbb-3333cccc4444. Выполните указанную ниже команду в Azure CLI.

az ad sp show --id 00001111-aaaa-2222-bbbb-3333cccc4444 --query objectId

Появится OID.

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

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

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

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

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

• POSIX контроль доступа Lists on Linux (Списки управления доступом POSIX для Linux)
• HDFS Permission Guide (Руководство по разрешениям в HDFS)
• POSIX FAQ (POSIX: вопросы и ответы)
• POSIX 1003.1 2008
• POSIX 1003.1 2013
• POSIX 1003.1 2016
• POSIX ACL on Ubuntu (POSIX ACL для Ubuntu)

См. также

• Модель управления доступом в Azure Data Lake Storage