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

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

Сведения об ACL

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

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

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

Типы ACL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Владелец

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

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

владеющая группа

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

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

• Случай 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 вряд ли возникнет необходимость использования sticky bit. Вкратце, если для каталога включен бит фиксации, дочерний элемент может быть удален или переименован только владельцем этого дочернего элемента, владельцем каталога или пользователем Superuser ($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?

№ Управление доступом с помощью списков управления доступом (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 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 Access Control 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