Модель управления доступом в Azure Data Lake Storage 2-го поколения
Data Lake Storage 2-го поколения поддерживает следующие механизмы авторизации:
- авторизация на основе общих ключей;
- Авторизация на основе подписанных URL-адресов (SAS)
- Управление доступом на основе ролей (Azure RBAC)
- Управление доступом на основе атрибутов (Azure ABAC)
- Списки управления доступом (ACL)
Общий ключ и авторизация SAS предоставляют доступ пользователю (или приложению) без необходимости иметь удостоверение в идентификаторе Microsoft Entra. С этими двумя формами проверки подлинности Azure RBAC, Azure ABAC и списки управления доступом не влияют.
Azure RBAC и ACL требуют, чтобы пользователь (или приложение) имели удостоверение в идентификаторе Microsoft Entra. Azure RBAC позволяет предоставлять доступ к данным учетной записи хранения, таким как доступ на чтение или запись ко всем данным в учетной записи хранения. Azure ABAC позволяет уточнить назначения ролей RBAC, добавив условия. Например, можно предоставить доступ на чтение или запись ко всем объектам данных в учетной записи хранения с определенным тегом. Списки управления доступом позволяют предоставлять "точный" доступ, например доступ на запись к определенному каталогу или файлу.
В этой статье основное внимание уделяется Azure RBAC, ABAC и списков управления доступом, а также о том, как система оценивает их вместе, чтобы принимать решения об авторизации для ресурсов учетной записи хранения.
Управление доступом на основе ролей (Azure RBAC)
Azure RBAC использует назначение ролей для применения наборов разрешений субъектам безопасности. Субъект безопасности — это объект, представляющий пользователя, группу, субъект-службу или управляемое удостоверение, определенное в идентификаторе Microsoft Entra. Набор разрешений может предоставить субъекту безопасности уровень низкой детализации, например, доступ для чтения или записи всех данных в учетной записи хранения или всех данных в контейнере.
Следующие роли позволяют субъекту безопасности получать доступ к данным в учетной записи хранения.
| Роль | Описание |
|---|---|
| владелец данных BLOB-объектов хранилища; | Полный доступ к контейнерам и данным хранилищ BLOB-объектов. Этот доступ позволяет субъекту безопасности задать владельца элемента и изменить ALS для всех элементов. |
| участник данных BLOB-объектов хранилища; | Доступ для чтения, записи и удаления контейнеров хранилища BLOB-объектов и больших двоичных объектов. Этот доступ не позволяет субъекту безопасности задавать владение элементом, но позволяет изменять ACL элементов, которые принадлежат субъекту безопасности. |
| читатель данных больших двоичных объектов хранилища. | Чтение и перечисление контейнеров хранилища BLOB-объектов и больших двоичных объектов. |
Роли, такие как Владелец, Участник, Читатель и Участник учетных записей хранения, позволяют субъекту безопасности управлять учетной записью хранения, но не предоставляют доступ к данным в этой учетной записи. Однако эти роли (за исключением Читателя) могут получить доступ к ключам хранилища, которые можно использовать в различных клиентских средствах для доступа к данным.
Управление доступом на основе атрибутов (Azure ABAC)
Azure ABAC основывается на Azure RBAC путем добавления условий назначения ролей на основе атрибутов в контексте определенных действий. Условие назначения ролей — это дополнительная проверка, которую можно дополнительно добавить в назначение роли, чтобы обеспечить более точное управление доступом. Вы не можете явно запретить доступ к определенным ресурсам с помощью условий.
Дополнительные сведения об использовании Azure ABAC для управления доступом к служба хранилища Azure см. в статье "Авторизация доступа к Хранилище BLOB-объектов Azure с помощью условий назначения ролей Azure".
Списки управления доступом (ACL)
ACL дают возможность применять "более детализированный" уровень доступа к каталогам и файлам. Список управления доступом представляет собой конструкцию разрешений, содержащую ряд записей ACL. Каждая запись ACL связывает субъекта безопасности с уровнем доступа. Чтобы узнать больше, ознакомьтесь с разделом Списки управления доступом (ACL) в Azure Data Lake Storage 2-го поколения.
Оценка разрешений
Во время авторизации на основе субъекта безопасности разрешения оцениваются, как показано на следующей схеме.
- Azure определяет, существует ли назначение роли для субъекта.
- Если назначение роли существует, условия назначения ролей (2) оцениваются далее.
- В противном случае вычисляются списки управления доступом (4).
- Azure определяет, существуют ли условия назначения ролей ABAC.
- Если условия отсутствуют, доступ предоставляется.
- Если условия существуют, они оцениваются, если они соответствуют запросу (3).
- Azure определяет, соответствуют ли все условия назначения ролей ABAC атрибутам запроса.
- Если все они совпадают, доступ предоставляется.
- Если по крайней мере один из них не соответствует, то списки ACL (4) оцениваются следующим образом.
- Если доступ не был явно предоставлен после оценки назначений ролей и условий, вычисляются списки управления доступом.
- Если списки управления доступом разрешают запрошенный уровень доступа, предоставляется доступ.
- В противном случае доступ запрещен.
Важно!
Из-за того, что разрешения доступа оцениваются системой, нельзя использовать ACL для ограничения доступа, который уже предоставлен назначением ролей и его условиями. Это связано с тем, что система сначала оценивает назначения ролей Azure и условия, а если назначение предоставляет достаточное разрешение на доступ, списки управления доступом игнорируются.
На следующей схеме показан поток разрешений для трех распространенных операций: перечисления содержимого каталога, чтения файла и записи файла.
Таблица разрешений: объединение azure RBAC, ABAC и списков управления доступом
В следующей таблице показано, как объединить роли, условия и записи ACL Azure, чтобы субъект безопасности смог выполнять операции, перечисленные в столбце операции . В этой таблице показан столбец, отражающий каждый уровень вымышленной иерархии каталогов. Есть столбец для корневого каталога контейнера (/), подкаталог с именем Oregon, вложенный каталог Portland в каталоге Oregon, и текстовый файл с именем Data.txt в каталоге Portland. Отображение в этих столбцах является кратким представлением записи ACL, необходимой для предоставления разрешений. Н/П (не применимо) отображается в столбце, если для выполнения операции не требуется запись ACL.
| Операция | Назначенная роль Azure (с условиями или без нее) | / | Каталог Oregon/ | Portland/ | Data.txt |
|---|---|---|---|---|---|
| Чтение файла Data.txt | Владелец данных BLOB-объектов хранилища | Неприменимо | Н/Д | Н/Д | Неприменимо |
| Участник данных BLOB-объектов хранилища | Неприменимо | Н/Д | Н/Д | Неприменимо | |
| Читатель данных больших двоичных объектов хранилища | Неприменимо | Н/Д | Н/Д | Неприменимо | |
| None | --X |
--X |
--X |
R-- |
|
| Добавление в файл Data.txt | Владелец данных BLOB-объектов хранилища | Неприменимо | Н/Д | Н/Д | Неприменимо |
| Участник данных BLOB-объектов хранилища | Неприменимо | Н/Д | Н/Д | Неприменимо | |
| Читатель данных больших двоичных объектов хранилища | --X |
--X |
--X |
-W- |
|
| None | --X |
--X |
--X |
RW- |
|
| Удаление файла Data.txt | Владелец данных BLOB-объектов хранилища | Неприменимо | Н/Д | Н/Д | Неприменимо |
| Участник данных BLOB-объектов хранилища | Неприменимо | Н/Д | Н/Д | Неприменимо | |
| Читатель данных больших двоичных объектов хранилища | --X |
--X |
-WX |
Неприменимо | |
| None | --X |
--X |
-WX |
Неприменимо | |
| Создание файла Data.txt | Владелец данных BLOB-объектов хранилища | Неприменимо | Н/Д | Н/Д | Неприменимо |
| Участник данных BLOB-объектов хранилища | Неприменимо | Н/Д | Н/Д | Неприменимо | |
| Читатель данных больших двоичных объектов хранилища | --X |
--X |
-WX |
Неприменимо | |
| None | --X |
--X |
-WX |
Неприменимо | |
| Перечисление / | Владелец данных BLOB-объектов хранилища | Неприменимо | Н/Д | Н/Д | Неприменимо |
| Участник данных BLOB-объектов хранилища | Неприменимо | Н/Д | Н/Д | Неприменимо | |
| Читатель данных больших двоичных объектов хранилища | Неприменимо | Н/Д | Н/Д | Неприменимо | |
| None | R-X |
Неприменимо | Н/Д | Неприменимо | |
| Перечисление для каталога /Oregon/ | Владелец данных BLOB-объектов хранилища | Неприменимо | Н/Д | Н/Д | Неприменимо |
| Участник данных BLOB-объектов хранилища | Неприменимо | Н/Д | Н/Д | Неприменимо | |
| Читатель данных больших двоичных объектов хранилища | Неприменимо | Н/Д | Н/Д | Неприменимо | |
| None | --X |
R-X |
Неприменимо | Неприменимо | |
| Перечисление для каталога /Oregon/Portland/ | Владелец данных BLOB-объектов хранилища | Неприменимо | Н/Д | Н/Д | Неприменимо |
| Участник данных BLOB-объектов хранилища | Неприменимо | Н/Д | Н/Д | Неприменимо | |
| Читатель данных больших двоичных объектов хранилища | Неприменимо | Н/Д | Н/Д | Неприменимо | |
| None | --X |
--X |
R-X |
Неприменимо |
Примечание.
Чтобы просмотреть содержимое контейнера в служба хранилища Azure Обозреватель, субъекты безопасности должны войти в Обозреватель службы хранилища с помощью идентификатора Microsoft Entra, а (как минимум) иметь доступ на чтение (R--) к корневой папке (\) контейнера. Такой уровень разрешений дает им возможность перечислять содержимое корневой папки. Если вы не хотите, чтобы содержимое корневой папки было видимым, можно назначить роль Читателя . С такой ролью они смогут составлять перечни контейнеров в учетной записи, но не содержимого контейнера. Затем вы можете предоставить доступ к определенным каталогам и файлам с помощью ALS.
Группы безопасности
Всегда используйте группы безопасности 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 и записи ACL
С помощью групп снижается вероятность превышения максимального количества назначений ролей в каждой подписке и максимального количества записей ACL для каждого файла или каталога. Ограничения описаны в приведенной ниже таблице.
| Механизм | Область | Ограничения | Поддерживаемый уровень разрешений |
|---|---|---|---|
| Azure RBAC | Учетные записи хранения, контейнеры. Назначения ролей между ресурсами Azure на уровне подписки или группы ресурсов. |
4000 назначений ролей Azure в подписке | Роли Azure (встроенные или пользовательские) |
| ACL | Каталог, файл | 32 записи ACL (фактически 28 записей ACL) для каждого файла и каталога. Списки ACL для доступа и по умолчанию имеют собственное ограничение в размере 32 записей. | Разрешение ACL |
Общие ключи и авторизация подписанного URL-адреса (SAS)
В Azure Data Lake Storage 2-го поколения поддерживается проверка подлинности с помощью общего ключа и SAS. Характерная особенность этих способов проверки подлинности заключается в том, что с вызывающей стороной не связано удостоверение, и поэтому авторизацию на основе разрешений субъекта безопасности выполнить нельзя.
В случае общего ключа вызывающая сторона фактически получает доступ суперпользователя, то есть полный доступ ко всем операциям над всеми ресурсами, включая данные, указание владельца и изменение списков ACL.
Маркеры SAS включают в себя допустимые разрешения. Разрешения, включенные в маркер SAS, эффективно применяются ко всем решениям об авторизации, но без дополнительных проверок списков ACL.
Следующие шаги
Дополнительные сведения о списках управления доступом см. в статье Управление списками управления доступом (ACL) в Azure Data Lake Storage 2-го поколения.