Выбор и настройка подходящего метода для доступа к таблицам Azure

  • 7 мин

служба хранилища Azure поддерживает использование идентификатора Microsoft Entra для авторизации запросов к табличным данным. С помощью идентификатора Microsoft Entra можно использовать управление доступом на основе ролей Azure (Azure RBAC) для предоставления разрешений субъекту безопасности, который может быть пользователем, группой или субъектом-службой приложений. Принципал безопасности проходит проверку подлинности с помощью Microsoft Entra ID, чтобы вернуть токен OAuth 2.0. Затем маркер можно использовать для авторизации запроса к службе таблиц.

Авторизация запросов к хранилищу Azure с помощью Microsoft Entra ID обеспечивает высокую безопасность и удобство использования по сравнению с авторизацией с общим ключом. Корпорация Майкрософт рекомендует использовать авторизацию Microsoft Entra с приложениями таблиц, если это возможно, чтобы обеспечить доступ с минимальными необходимыми привилегиями. Для приложений, работающих в Azure, используйте управляемые удостоверения, чтобы устранить необходимость хранения учетных данных в коде.

Аутентификация с помощью Microsoft Entra ID доступна для всех общих целей во всех общедоступных регионах и национальных облаках. Только учетные записи хранения, созданные с помощью модели развертывания Azure Resource Manager, поддерживают авторизацию Microsoft Entra.

Обзор идентификатора Microsoft Entra для таблиц

Когда участник безопасности (пользователь, группа или приложение) пытается получить доступ к ресурсу таблицы, запрос должен быть авторизован. С идентификатором Microsoft Entra доступ к ресурсу является двухэтапным процессом. Вначале удостоверение участника безопасности проходит аутентификацию, которая возвращает токен OAuth 2.0. Затем маркер передается как часть запроса в службу таблиц и используется этой службой для авторизации доступа к указанному ресурсу.

Для этапа аутентификации требуется, чтобы приложение запросило маркер доступа OAuth 2.0 во время выполнения. Если приложение работает в сущности Azure, такой как виртуальная машина Azure, масштабируемый набор виртуальных машин или приложение "Функции Azure", оно может использовать управляемое удостоверение для доступа к таблицам. Использование управляемых удостоверений — это рекомендуемый подход , так как он устраняет необходимость управления учетными данными в коде приложения.

Шаг авторизации требует, чтобы одна или несколько ролей Azure были назначены субъекту безопасности. Azure Storage предоставляет роли Azure, включающие общие наборы разрешений для данных таблиц. Роли, назначаемые субъекту безопасности, определяют доступные ему разрешения.

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

Язык .NET Java JavaScript Python Вперед
Обзор проверки подлинности с помощью идентификатора Microsoft Entra Проверка подлинности приложений .NET с помощью служб Azure Аутентификация в Azure при помощи Java и Azure Identity Проверка подлинности приложений JavaScript в Azure с помощью пакета SDK Azure Проверка подлинности приложений Python в Azure с помощью пакета SDK Azure Не применимо
Аутентификация с помощью учетных данных сервисов для разработчиков Проверка подлинности приложений .NET в службах Azure во время локальной разработки с помощью субъектов-служб Аутентификация Azure с помощью служебного принципала Авторизация JS-приложений к службам Azure с помощью служебного принципала Аутентификация приложений Python в Azure-сервисах во время локальной разработки с помощью учетных записей служб Аутентификация Azure SDK для Go с помощью учетной записи службы
Проверка подлинности с помощью учетных записей разработчика или пользователей Проверка подлинности приложений .NET в службах Azure во время локальной разработки с помощью учетных записей разработчиков Проверка подлинности Azure с учетными данными пользователя Аутентификация приложений JS в службах Azure с учетными записями разработки Проверка подлинности приложений Python в службах Azure во время локальной разработки с помощью учетных записей разработчиков Аутентификация в Azure с помощью Azure SDK для Go
Аутентификация приложений, размещенных в Azure Проверка подлинности размещенных в Azure приложений в ресурсах Azure с помощью пакета SDK Azure для .NET Проверка подлинности размещенных в Azure приложений Java Проверка подлинности размещенных в Azure приложений JavaScript в ресурсах Azure с помощью пакета SDK Azure для JavaScript Проверка подлинности размещенных в Azure приложений в ресурсах Azure с помощью пакета SDK Azure для Python Аутентификация с использованием Azure SDK для Go и управляемого удостоверения
Проверка подлинности из локальных приложений Аутентификация к ресурсам Azure из приложений .NET, размещенных на локальных серверах Не применимо Проверка подлинности локальных приложений JavaScript в ресурсах Azure Аутентификация к ресурсам Azure из приложений Python, размещённых локально Не применимо
Общие сведения о клиентской библиотеке идентификации библиотека клиента Azure Identity для .NET Клиентская библиотека идентификации Azure для Java Клиентская библиотека идентификации Azure для JavaScript Клиентская библиотека идентификации Azure для Python Клиентская библиотека идентификации Azure для Go

Назначение ролей Azure для предоставления прав доступа

Microsoft Entra разрешает доступ к защищенным ресурсам с помощью управления доступом на основе ролей Azure (Azure RBAC). Служба хранилища Azure определяет набор встроенных ролей Azure, охватывающих общие наборы разрешений, используемых для доступа к данным таблиц. Вы также можете определить собственные роли для доступа к данным таблиц.

Когда роль Azure назначается субъекту безопасности Microsoft Entra, Azure предоставляет доступ к этим ресурсам для этого субъекта безопасности. Субъект безопасности Microsoft Entra может быть пользователем, группой, служебным принципалом приложения или управляемым удостоверением для ресурсов Azure.

Область ресурсов

Прежде чем назначить роль RBAC Azure участнику безопасности, определите область его доступа. Всегда предоставлять только самую узкую область, необходимую субъекту безопасности для выполнения своих задач. Это следует принципу наименьших привилегий и сводит к минимуму риски безопасности. Роли RBAC Azure, определенные на более высоком уровне, наследуются подчиненными ресурсами.

Доступ к ресурсам таблицы Azure можно получить на следующих уровнях, начиная с самой узкой (наиболее строгой) области:

  • Отдельная таблица. В этой области назначение роли применяется только к указанной таблице.
  • Учетная запись хранения. В этой области назначение ролей применяется ко всем таблицам в учетной записи.
  • Группа ресурсов. В этой области назначение ролей применяется ко всем таблицам во всех учетных записях хранения в группе ресурсов.
  • Подписка. В этой области назначение ролей применяется ко всем таблицам во всех учетных записях хранения во всех группах ресурсов в подписке.
  • Группа управления. В этой области назначение ролей применяется ко всем таблицам во всех учетных записях хранения во всех группах ресурсов во всех подписках в группе управления.

Дополнительные сведения об области для назначения ролей Azure RBAC см. в статье Сведения об области действия для Azure RBAC.

Встроенные роли Azure для таблиц

Azure RBAC предоставляет встроенные роли для авторизации доступа к данным таблицы с помощью идентификатора Microsoft Entra и OAuth. Встроенные роли, которые предоставляют разрешения для таблиц в службе хранилище Azure, включают:

  • Контрибьютор таблиц хранилища: предоставляет разрешения на чтение, запись и удаление ресурсов таблиц хранилища. Используйте эту роль для приложений или пользователей, которые должны создавать, изменять или удалять сущности таблицы.
  • Читатель данных хранилища таблиц: предоставляет доступ только для чтения к ресурсам хранилища таблиц. Используйте эту роль для приложений или пользователей, которые должны запрашивать или извлекать данные таблицы без прав на изменение.

Сведения о назначении встроенной роли Azure субъекту безопасности см. в статье "Назначение роли Azure для доступа к табличным данным". Чтобы узнать, как составить список ролей RBAC Azure и их разрешений, см. Список определений ролей Azure.

Дополнительные сведения о том, как определяются встроенные роли для службы хранилища Azure, см. в статье "Общие сведения об определениях ролей". Дополнительные сведения о создании настраиваемых ролей Azure см. в разделе Настраиваемые роли Azure.

Только роли, явно определенные для доступа к данным, позволяют субъекту безопасности получать доступ к данным таблиц. Встроенные роли, такие как владелец, участник и участник учетной записи хранения, позволяют субъекту безопасности управлять учетной записью хранения, но не предоставлять доступ к данным таблицы в этой учетной записи через идентификатор Microsoft Entra. Однако если роль включает Microsoft.Storage/storageAccounts/listKeys/action, то пользователь, которому назначена роль, может получить доступ к данным в учетной записи хранения с помощью авторизации общего ключа с ключами доступа к учетной записи.

Замечание

Роли, включающие действие listKeys , предоставляют полный доступ к данным учетной записи хранения через общий ключ. Чтобы повысить безопасность, рассмотрите возможность использования пользовательских ролей, которые исключают это действие и применяют доступ только для идентификатора Microsoft Entra.

Подробные сведения о встроенных ролях Azure для службы хранилища Azure, для служб данных и службы управления см. в разделе хранилища в встроенных ролях Azure для Azure RBAC. Кроме того, сведения о различных типах ролей, которые предоставляют разрешения в Azure, см. в ролях Azure, ролях Microsoft Entra и классических ролях администратора подписки.

Назначение ролей Azure может требовать до 30 минут на распространение.

Разрешения доступа к операциям с данными

Дополнительные сведения о разрешениях, необходимых для вызова определенных операций службы таблиц, см. в разделе "Разрешения для вызова операций с данными".

Рекомендации по авторизации доступа к таблице

При реализации авторизации идентификатора Microsoft Entra для хранилища таблиц Azure следуйте приведенным ниже рекомендациям по обеспечению безопасности.

  • Используйте управляемые удостоверения: для приложений, работающих в Azure (виртуальных машинах, службе приложений, Функциях Azure, экземплярах контейнеров, AKS), всегда используйте управляемые удостоверения вместо субъектов-служб с сохраненными учетными данными. Это устраняет необходимость управления секретами и смены их.
  • Реализуйте наименьшие привилегии: назначьте самую ограничивающую роль, которая соответствует требованиям. Используйте читателя данных таблицы хранилища для сценариев только для чтения, а не более разрешающие роли, такие как вкладчик данных таблицы хранилища.
  • Соответствующее назначение областей: Применяйте назначения ролей на уровне таблицы, если это возможно, а не на уровне учетной записи хранения или подписки. Это ограничивает доступ только к определенным таблицам, которым требуются пользователи или приложения.
  • Избегайте авторизации общего ключа. После перехода на проверку подлинности идентификатора Microsoft Entra ID рекомендуется отключить авторизацию общего ключа на уровне учетной записи хранения, чтобы предотвратить несанкционированный доступ с помощью ключей учетных записей.
  • Используйте пользовательские роли для точного управления. Если встроенные роли не соответствуют вашим требованиям, создайте пользовательские роли Azure RBAC, которые включают только необходимые разрешения.
  • Мониторинг доступа. Включите ведение журнала диагностики и регулярно просматривайте журналы Azure Monitor для отслеживания доступа к данным таблицы и выявления подозрительных или несанкционированных попыток доступа.
  • Применение политик условного доступа. Используйте политики условного доступа Microsoft Entra для применения дополнительных требований безопасности, таких как многофакторная проверка подлинности, проверки соответствия устройств или ограничения на основе расположения.
  • Регулярные проверки доступа. Периодически просматривайте и проверяйте назначения ролей, чтобы гарантировать, что пользователям и приложениям по-прежнему требуются их назначенные разрешения.
  • Отдельная разработка и производство. Используйте различные учетные записи хранения и назначения ролей для разработки и рабочей среды, чтобы свести к минимуму риск случайного воздействия или изменения данных.