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