Проверка подлинности для аналитики в масштабе облака в Azure
Проверка подлинности — это процесс проверки удостоверений пользователя или приложения. Для управления удостоверениями и проверкой подлинности рекомендуется использование одного поставщика удостоверений источника. Этот поставщик называется службой каталогов. Он предоставляет методы для хранения данных каталога и предоставления доступа к этим данным сетевым пользователям и администраторам.
Любое решение для озера данных должно использовать и уже используемую службу каталогов и обеспечивать интеграцию с ней. Для большинства организаций Active Directory является службой каталогов для всех служб, связанных с удостоверениями. Это основная и централизованная база данных для всех учетных записей служб и пользователей.
В облаке Идентификатор Microsoft Entra — это централизованный поставщик удостоверений и предпочтительный источник для управления удостоверениями. Делегирование проверки подлинности и авторизации идентификатору Microsoft Entra позволяет сценариям, таким как политики условного доступа, требующие, чтобы пользователь был в определенном расположении. Он поддерживает многофакторную проверку подлинности для повышения уровня безопасности доступа. Настройте службы хранилища данных озера данных с помощью интеграции Microsoft Entra, когда это возможно.
Для служб данных, не поддерживающих идентификатор Microsoft Entra, используйте ключ доступа или маркер для проверки подлинности. Клиент должен хранить ключ доступа в хранилище управления ключами, таком как Azure Key Vault.
Сценарии проверки подлинности для облачной аналитики:
- Проверка подлинности пользователей
- Проверка подлинности приложений и между службами
Проверка подлинности пользователей
Пользователи, подключающиеся к службе данных или ресурсу, должны представлять учетные данные. Эти учетные данные подтверждают, что пользователи являются теми, кем себя заявляют. Затем они могут получить доступ к службе или ресурсу. Проверка подлинности также позволяет службе узнавать идентификатор пользователей. Служба определяет, что пользователь может видеть и что делать после проверки удостоверения.
Azure Data Lake Storage 2-го поколения, База данных SQL Azure и Azure Synapse поддерживают интеграцию Microsoft Entra. Режим интерактивной проверки подлинности пользователя требует, чтобы пользователи предоставляли учетные данные в диалоговом окне.
Важно!
Не следует жестко кодировать учетные данные пользователя в приложении для проверки подлинности.
Проверка подлинности приложений и между службами
Эти запросы не связаны с конкретным пользователем, или нет доступа к пользователю для ввода учетных данных.
Аутентификация между службами
Даже если служба обращается к другой службе без взаимодействия с человеком, служба должна предоставить действительное удостоверение. Это удостоверение подтверждает, что служба является реальной. Служба, к которой он обращался, может использовать удостоверение, чтобы решить, что может сделать служба.
Для аутентификации между службами предпочтительным методом проверки подлинности служб Azure являются управляемые удостоверения. Управляемые удостоверения для ресурсов Azure позволяют выполнять проверку подлинности в любой службе, поддерживающей проверку подлинности Microsoft Entra без явных учетных данных. Дополнительные сведения см. в статье Что такое управляемые удостоверения для ресурсов Azure?.
Управляемые удостоверения — это субъекты-службы, которые можно использовать только с ресурсами Azure. Например, управляемое удостоверение можно создать непосредственно для экземпляра Фабрики данных Azure. Это управляемое удостоверение является объектом, зарегистрированным в идентификаторе Microsoft Entra. Он представляет этот экземпляр Фабрики данных. Это удостоверение можно использовать для проверки подлинности в любой службе, например Data Lake Storage, без каких бы то ни было учетных данных в коде. Azure обрабатывает учетные данные, используемые экземпляром службы. Удостоверение может предоставить разрешение на доступ к ресурсам службы Azure, например к папке в Azure Data Lake Storage. При удалении этого экземпляра Фабрики данных Azure очищает удостоверение в идентификаторе Microsoft Entra.
Преимущества использования управляемых удостоверений
Управляемые удостоверения следует использовать для проверки подлинности службы Azure в другой службе или ресурсе Azure. Они обеспечивают следующие преимущества:
- Управляемое удостоверение представляет службу, для которой оно создано. Оно не представляет интерактивного пользователя.
- Учетные данные управляемого удостоверения поддерживаются, управляются и хранятся в идентификаторе Microsoft Entra. Нет пароля для сохранения пользователем.
- При использовании управляемых удостоверений службы клиента не используют пароли.
- Управляемое удостоверение, назначаемое системой, удаляется при удалении экземпляра службы.
Эти преимущества означают, что учетные данные лучше защищены, и вероятность нарушения безопасности снижается.
Проверка подлинности между приложением и службой
Другой сценарий доступа — это приложение, например мобильное веб-приложение, обращающееся к службе Azure. Кто бы ни пытался получить доступ к службе Azure, он должен предоставить свое удостоверение, и это удостоверение должно быть проверено.
Субъект-служба Azure — это альтернатива приложениям и службам, которые не поддерживают управляемые удостоверения для проверки подлинности в ресурсах Azure. Субъект-служба Azure — это удостоверение, созданное для использования с приложениями, размещенными службами и автоматизированными средствами с целью получения доступа к ресурсам Azure. Доступ ограничен ролями, присвоенными этому субъекту-службе. По соображениям безопасности рекомендуется использовать субъекты-службы с автоматизированными инструментами или приложениями, а не разрешать им выполнять вход с помощью удостоверения пользователя. Дополнительные сведения см. в разделе "Объекты приложения и субъекта-службы" в идентификаторе Microsoft Entra.
Примечание.
Управляемые удостоверения и субъекты-службы создаются и поддерживаются только в идентификаторе Microsoft Entra.
Различие между управляемым удостоверением и субъектом-службой
| Субъект-служба | Управляемое удостоверение |
|---|---|
| Удостоверение безопасности, созданное вручную в идентификаторе Microsoft Entra для использования приложениями, службами и инструментами для доступа к определенным ресурсам Azure. | Особый тип субъекта-службы. Это автоматическое удостоверение, создаваемое при создании службы Azure. |
| Может использоваться любым приложением или службой. Он не привязан к определенной службе Azure. | Представляет сам экземпляр службы Azure. Его нельзя использовать для представления других служб Azure. |
| Имеет независимый жизненный цикл. Его необходимо удалить явным образом. | Удаляется автоматически при удалении экземпляра службы Azure. |
| Проверка подлинности на основе пароля или сертификата. | Для проверки подлинности не указан явный пароль. |
Проверка подлинности и разрешений баз данных
Аналитика в масштабе облака, вероятно, содержит хранилище polyglot. К примерам относятся PostgreSQL, MySQL, База данных SQL Azure, Управляемый экземпляр SQL и Azure Synapse Analytics.
- Использование идентификатора Microsoft Entra для проверки подлинности с помощью PostgreSQL
- Использование проверки подлинности Microsoft Entra с База данных SQL Azure, Управляемый экземпляр SQL и Azure Synapse Analytics
- Использование идентификатора Microsoft Entra для проверки подлинности с помощью MySQL
Мы рекомендуем использовать группы Microsoft Entra для защиты объектов базы данных вместо отдельных учетных записей пользователей Microsoft Entra. Используйте эти группы Microsoft Entra для проверки подлинности пользователей и защиты объектов базы данных. Аналогично шаблону озера данных, можно использовать подключение приложения данных для создания этих групп.
Примечание.
Приложения данных могут хранить продукты конфиденциальных данных в База данных SQL Azure, Управляемый экземпляр SQL или пулах Azure Synapse Analytics. Дополнительные сведения см. в статье Конфиденциальные данные.
Безопасность Azure Data Lake в облачной аналитике
Для управления доступом к данным в озере данных рекомендуется использовать список управления доступом (ACL) на уровне файлов и папок. Azure Data Lake также применяет модель списка управления доступом, аналогичную POSIX. POSIX (портативный интерфейс операционной системы) — это семейство стандартов для операционных систем. Один стандарт определяет простую, но мощную структуру разрешений для доступа к файлам и папкам. POSIX был широко распространен для сетевых общих папок и компьютеров UNIX.
Как и в случае с общими рекомендациями Azure RBAC, в ACL следует применять следующие правила:
Управляйте доступом с помощью групп; Назначьте доступ к группам Microsoft Entra и управляйте членством в группах для текущего управления доступом. См. статью "Управление доступом" и конфигурации озера данных в Azure Data Lake служба хранилища.
Минимум привилегий. В большинстве случаев у пользователей должно быть только разрешение на чтение тех папок и файлов, которые им необходимы в озере данных. Управляемое удостоверение или субъект-служба, например та, которая используется фабрикой данных Azure, имеет разрешения на чтение, запись и выполнение. У пользователей данных не должно быть доступа к контейнеру учетной записи хранения.
Согласуйте со схемой секционирования данных. Список ACL и структура секционирования данных должны быть согласованы, чтобы обеспечить эффективное управление доступом к данным. Дополнительные сведения см. в разделе [Секционирование озера данных].
Следующие шаги
Управление данными и управление доступом на основе ролей для облачной аналитики в Azure