Авторизация для аналитики в масштабе облака в Azure
Авторизация — это акт предоставления удостоверяемого участника разрешения на выполнение действия. Ключевым принципом управления доступом является предоставление пользователям только объема доступа, необходимого для выполнения своих заданий, и только разрешения определенных действий в определенной области. Безопасность на основе ролей соответствует управлению доступом и используется многими организациями для управления доступом на основе определенных ролей или функций заданий и отдельных пользователей. Затем пользователям назначается одна или несколько ролей безопасности, каждая из которых предоставляет авторизованные разрешения на выполнение определенных задач.
При использовании Microsoft Entra ID в качестве централизованного поставщика удостоверений, авторизация для доступа к службам данных и хранилищу может предоставляться для каждого пользователя или каждого приложения и основывается на идентификации Microsoft Entra.
Авторизация службы данных
списки управления доступом (ACL) Azure Role-Based (RBAC) и списки управления доступом (ACL) Azure играют важную роль в управлении доступом и обеспечении безопасности. Azure RBAC и списки управления доступом требуют, чтобы у пользователя (или приложения) было удостоверение в Microsoft Entra ID. В облачной аналитике RBAC действует для баз данных и Azure Data Lake Storage, а списки управления доступом используются в основном в Azure Data Lake Storage для обеспечения точного контроля доступа на уровне файлов и каталогов. Списки управления доступом дополняют RBAC, предлагая более подробные разрешения в иерархии хранилища.
Azure RBAC предлагает встроенные роли, такие как "Владелец", "Участник" и "Читатель", но вы также можете создавать пользовательские роли, адаптированные к конкретным потребностям. Следующие встроенные роли являются основными для всех типов ресурсов Azure, включая службы данных Azure:
| Роль | Описание |
|---|---|
| владелец | Эта роль имеет полный доступ к ресурсу и может управлять всеми сведениями о ресурсе, включая право предоставить ему доступ. |
| участник | Эта роль может управлять ресурсом, но не может предоставить ему доступ. |
| Читалка | Эта роль может просматривать ресурс и сведения об этом (за исключением конфиденциальных данных, таких как ключи доступа или секреты), но они не могут вносить какие-либо изменения в ресурс. |
Заметка
Некоторые службы имеют определенные роли RBAC, такие как участник данных BLOB-объектов хранилища или участник фабрики данных, что означает, что для этих служб должны использоваться определенные роли RBAC. RBAC — это аддитивная модель, в которой добавление назначений ролей является активным разрешением. RBAC также поддерживает запретить назначения, которые имеют приоритет над назначениями роли.
Совет
При планировании стратегии управления доступом рекомендуется предоставить пользователям только объем доступа, который им нужно выполнить, и разрешить только определенные действия в определенной области.
Управление доступом в базах данных Azure
RBAC в базах данных Azure вращается вокруг ролей, областей и разрешений. Azure предоставляет несколько встроенных ролей, адаптированных для управления базами данных, например, SQL Server Contributor (Участник SQL Server), который позволяет управлять серверами и базами данных SQL, и SQL DB Contributor (Участник базы данных SQL), который позволяет управлять базами данных SQL, но не самим сервером. Кроме того, пользовательские роли можно создавать с определенными разрешениями для удовлетворения уникальных требований.
Роли можно назначать в разных областях, включая уровень подписки, где роли применяются ко всем ресурсам в подписке; уровень группы ресурсов, где роли применяются ко всем ресурсам в указанной группе ресурсов; и уровень ресурсов, где роли можно назначать непосредственно отдельным базам данных или серверам, предоставляя точный контроль. Разрешения определяют действия, которые может выполнять роль, например чтение, запись, удаление или управление параметрами безопасности, а также эти разрешения группируются в роли, чтобы упростить управление.
В Базе данных SQL Azureроли можно назначать пользователям, группам или приложениям для управления доступом. Например, администратору базы данных может быть назначена роль "Участник SQL Server" для управления сервером и базами данных. Роли, такие как "Участник базы данных SQL", позволяют пользователям создавать, обновлять и удалять базы данных, а роль "Диспетчер безопасности SQL" ориентирована на конфигурации безопасности.
Для Azure Cosmos DBроли можно назначать для управления доступом к учетным записям Cosmos DB, базам данных и контейнерам. Встроенные роли, такие как "Читатель учетных записей Cosmos DB" и "Участник учетной записи Cosmos DB", предоставляют различные уровни доступа.
В Базе данных Azure для MySQL, PostgreSQL и MariaDBможно назначать роли для управления серверами баз данных и отдельными базами данных. Роли, такие как "Участник" и "Читатель", можно использовать для управления доступом.
Дополнительные сведения см. в статье встроенных ролей Azure для баз данных.
Управление доступом в Azure Data Lake Storage
Azure RBAC позволяет предоставлять «грубозернистый» доступ к данным учетной записи хранения, например, доступ на чтение или запись ко всем данным этой учетной записи. Списки управления доступом позволяют предоставлять детализированный доступ, например, доступ на запись к определенному каталогу или файлу.
Во многих сценариях RBAC и ACL используются вместе для обеспечения комплексного контроля доступа в ADLS. RBAC можно использовать для управления высоким уровнем доступа к данным, обеспечивая доступ только авторизованных пользователей к самой службе. Затем списки управления доступом можно применить в учетной записи хранения для управления доступом к определенным файлам и каталогам, обеспечивая дополнительный уровень безопасности.
Управление доступом на основе атрибутов Azure (ABAC) основано на Azure RBAC путем добавления условий назначения ролей на основе атрибутов в контексте конкретных действий. Он по сути позволяет уточнить назначения ролей RBAC, добавив условия. Например, можно предоставить доступ на чтение или запись ко всем объектам данных в учетной записи хранения с определенным тегом.
Следующие роли позволяют субъекту безопасности получать доступ к данным в учетной записи хранения.
| Роль | Описание |
|---|---|
| Администратор данных BLOB-объектов хранилища | Полный доступ к контейнерам и данным в хранилище объектов Blob. Этот доступ позволяет субъекту безопасности задать владельца элемента и изменить ACL всех элементов. |
| Конрибутор данных хранилища Blob | Доступ на чтение, запись и удаление к контейнерам и блобам хранилища. Этот доступ не позволяет субъекту безопасности задать владение элементом, но он может изменить ACL элементов, принадлежащих субъекту безопасности. |
| Читатель данных блобов хранилища | Чтение и отображение контейнеров и BLOB-объектов хранилища. |
Такие роли, как владелец, участник, читатель и участник учетной записи хранения, позволяют субъекту безопасности управлять учетной записью хранения, но не предоставлять доступ к данным в этой учетной записи. Однако эти роли (за исключением читателя) могут получить доступ к ключам хранилища, которые можно использовать в различных клиентских средствах для доступа к данным. Дополнительные сведения см. в модели управления доступом в Azure Data Lake Storage .
Управление доступом в Azure Databricks
Azure Databricks поставляется с системами управления доступом, предназначенными для управления доступом в среде Databricks, акцентируя внимание на защищаемых объектах и управлении данными. Ниже перечислены три основных системы управления доступом в Azure Databricks:
- списки управления доступом: используется для настройки разрешения на доступ к объектам рабочей области, таким как записные книжки. Дополнительные сведения см. в списках управления доступом.
- Управление доступом на основе ролей учетной записи: используется для настройки разрешений на использование объектов, связанных с учетной записью, таких как основные элементы служб и группы.
- каталоге Unity: используется для защиты и управления объектами данных.
Помимо управления доступом к объектам, существуют встроенные роли на платформе Azure Databricks. Пользователям, субъектам-службам и группам можно назначать роли. Дополнительные сведения см. в разделе роли администратора Databricks.
Рекомендации по авторизации в облачной аналитике
В этом руководстве приведены рекомендации по реализации управления доступом на основе ролей (RBAC) в облачных аналитических средах. В нем рассматриваются общие принципы RBAC, управление доступом к базам данных и рекомендации по управлению доступом к озерам данных для обеспечения безопасного и эффективного управления ресурсами.
Общие рекомендации по RBAC для облачной аналитики
Следующие рекомендации помогут вам приступить к работе с RBAC:
Используйте роли RBAC для управления службами и операциями и используйте сервис-специфичные роли для доступа к данным и задач, связанных с рабочими нагрузками.: Используйте роли RBAC на ресурсах Azure для предоставления доступа субъектам безопасности, которым нужно выполнять задачи управления ресурсами и операциями. Субъекты безопасности, которым требуется доступ к данным в хранилище, не требуют роли RBAC в ресурсе, так как им не нужно управлять им. Вместо этого предоставьте разрешение объектам данных напрямую. Например, предоставьте доступ на чтение к папке в хранилище данных Azure Data Lake 2-го поколения или пользователю содержащейся базы данных и права на таблицу в базе данных в Azure SQL Database.
Использовать встроенные роли RBAC. Сначала используйте встроенные роли ресурсов RBAC Azure для управления службами и назначения ролей операций для управления доступом. Создание и использование пользовательских ролей для ресурсов Azure только в том случае, если встроенные роли не соответствуют конкретным потребностям.
Использовать группы для управления доступом. Назначение доступа группам Microsoft Entra и управление членством в группах для текущего управления доступом.
области подписки и группы ресурсов: В непроизводственных средах часто имеет смысл предоставлять доступ на уровне области группы ресурсов для разделения задач управления и операций, вместо предоставления доступа к отдельным ресурсам. Причина заключается в том, что в непроизводственных средах разработчики и тестировщики должны управлять ресурсами, такими как создание конвейера приема фабрики данных Azure или создание контейнера в Data Lake Storage 2-го поколения. Однако в рабочих средах можно предоставить доступ к отдельным ресурсам для задач, связанных с рабочими нагрузками, таких как поддержка и операции файловой системы озера данных. Причина заключается в том, что в рабочей среде пользователям необходимо использовать только ресурсы, такие как просмотр состояния запланированного конвейера приема данных фабрики данных или чтение файлов данных в Data Lake Storage 2-го поколения.
Не предоставлять ненужный доступ для области подписки: Область подписки включает все ресурсы, находящиеся в подписке.
Предпочтите доступ с наименьшими привилегиями: выберите единственно правильную роль для задачи.
Рекомендации по управлению доступом к базе данных
Реализация эффективного управления доступом на основе ролей (RBAC) имеет решающее значение для обеспечения безопасности и управляемости в вашей аналитической среде. В этом разделе приведены рекомендации по использованию групп Microsoft Entra, встроенных ролей и предотвращения прямых разрешений пользователей для обеспечения упрощенного и безопасного процесса управления доступом.
Аналитика в масштабе облака, вероятно, содержит полиглотное хранилище. Примерами являются PostgreSQL, MySQL, База данных SQL Azure, Управляемый экземпляр SQL и Azure Synapse Analytics.
- использовать группы Microsoft Entra вместо отдельных учетных записей пользователей. Рекомендуется использовать группы Microsoft Entra для защиты объектов базы данных вместо отдельных учетных записей пользователей Microsoft Entra. Используйте эти группы Microsoft Entra для проверки подлинности пользователей и защиты объектов базы данных. Аналогично шаблону озера данных, вы можете использовать внедрение вашего приложения для работы с данными для создания этих групп.
- Используйте встроенные роли для управления доступом: Создавайте пользовательские роли только в случае необходимости для удовлетворения конкретных требований или когда встроенные роли предоставляют слишком много разрешений.
- Воздержитесь от назначения разрешений отдельным пользователям.Вместо этого последовательно используйте роли (роли базы данных или сервера). Роли значительно помогают в составлении отчетов и решении проблем с доступами. (Azure RBAC поддерживает только назначение разрешений с помощью ролей.)
Заметка
Приложения данных могут хранить продукты с конфиденциальными данными в базе данных SQL Azure, управляемом экземпляре SQL или пулах Azure Synapse Analytics. Дополнительные сведения см. в разделе Конфиденциальные данные.
Рекомендации по управлению доступом к Data Lake
В современных средах данных обеспечение безопасного и эффективного управления доступом имеет первостепенное значение. Azure Data Lake Storage (ADLS) 2-го поколения предоставляет надежные механизмы управления доступом с помощью списков управления доступом (ACL). В этом разделе описаны рекомендации по реализации управления доступом на основе ролей в ADLS 2-го поколения, применении списков управления доступом, группах безопасности Microsoft Entra и принципе минимальных привилегий для обеспечения безопасной и управляемой среды озера данных. Кроме того, она подчеркивает важность согласования списков управления доступом с схемами секционирования данных и использования каталога Unity Catalog для пользователей Azure Databricks для обеспечения комплексной безопасности и управления.
- использовать списки управления доступом (ACL) для точного управления доступом: списки управления доступом играют важную роль в определении доступа на детальном уровне. В Azure Data Lake Storage (ADLS) второго поколения (Gen2) списки контроля доступа (ACL) работают с субъектами безопасности для управления детализированным доступом к файлам и каталогам.
- Применить списки управления доступом на уровне файлов и папок. Для управления доступом к данным в озере данных рекомендуется использовать списки управления доступом (ACL) на уровне файлов и папок. Azure Data Lake также принимает модель списка управления доступом, например POSIX. POSIX (переносимый интерфейс операционной системы) — это семейство стандартов для операционных систем. Один стандарт определяет простую, но мощную структуру разрешений для доступа к файлам и папкам. POSIX широко применяется для сетевых файловых ресурсов и компьютеров Unix.
- Использовать группы безопасности Microsoft Entra в качестве назначенного главного в записи ACL: не следует напрямую назначать отдельных пользователей или служебных принципалов. Эта структура позволяет добавлять и удалять пользователей или субъектов-служб без необходимости повторно применять списки управления доступом к всей структуре каталогов. Вместо этого можно просто добавить или удалить пользователей и субъектов-служб из соответствующей группы безопасности Microsoft Entra.
- назначить доступа группам Microsoft Entra и управлять членством в группах для текущего управления доступом. См. управление доступом и конфигурации озера данных в Azure Data Lake Storage.
- Применение принципа наименьших привилегий к спискам управления доступом. В большинстве случаев пользователи должны иметь только разрешения на чтение файлов и папок, необходимых в озере данных. Пользователи данных не должны иметь доступа к контейнеру учетной записи хранения.
- Совмещение списков управления доступом с схемами секционирования данных: Списки управления доступом и проектирование секционирования данных должны быть согласованы для обеспечения эффективного управления доступом к данным. Дополнительные сведения см. в разделе Секционирование хранилища данных.
- для пользователей Azure Databricks, исключительно управляйте доступом к объектам данных с помощью каталога Unity. Предоставление прямого доступа к хранилищу на уровне хранилища внешних расположений в Azure Data Lake Storage 2-го поколения не учитывает предоставленные разрешения или аудиты, поддерживаемые каталогом Unity. Прямой доступ обходит аудирование, происхождение и другие функции безопасности и мониторинга каталога Unity, включая средства управления доступом и разрешения. Поэтому конечные пользователи Azure Databricks не должны получать прямой доступ на уровне хранилища к управляемым таблицам и томам каталога Unity.