Поделиться через


Управление ключами доступа к учетной записи хранения

При создании учетной записи хранения платформа Azure создает два 512-разрядных ключа доступа к учетной записи хранения для этой учетной записи. Эти ключи можно использовать для авторизации доступа к данным в учетной записи хранения с помощью авторизации общего ключа или через маркеры SAS, подписанные общим ключом.

Корпорация Майкрософт рекомендует использовать хранилище ключей Azure Key Vault для управления ключами доступа и производить регулярную ротацию и повторное создание ключей. Использование хранилища ключей Azure упрощает процесс ротации ключей без прерывания работы приложений. Вы также можете вручную производить процесс ротации.

Внимание

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

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

В сценариях, когда используются подписанные URL-адреса (SAS), корпорация Майкрософт рекомендует использовать SAS делегирования пользователей. SAS делегирования пользователей защищены учетными данными Microsoft Entra вместо ключа учетной записи. Дополнительные сведения о подписанных URL-адресах см. в статье Предоставление ограниченного доступа к данным с помощью подписанных URL-адресов. Пример создания и использования SAS делегирования пользователей с .NET см. в статье "Создание SAS делегирования пользователей для большого двоичного объекта с помощью .NET".

Защита ключей доступа

служба хранилища ключи доступа к учетной записи предоставляют полный доступ к конфигурации учетной записи хранения, а также к данным. Не забудьте защитить ключи доступа. Для безопасного управления ключами и их замены воспользуйтесь Azure Key Vault. Доступ к общему ключу предоставляет пользователю полный доступ к конфигурации учетной записи хранения и его данным. Доступ к общим ключам следует тщательно ограничить и отслеживать. Используйте маркеры SAS делегирования пользователей с ограниченным область доступа в сценариях, когда авторизация на основе идентификатора Microsoft Entra не может использоваться. Избегайте жесткого написания ключей доступа или сохраняйте их в любом месте обычного текста, доступного другим пользователям. Поверните ключи, если вы считаете, что они были скомпрометированы.

Внимание

Чтобы запретить пользователям доступ к данным в учетной записи хранения с общим ключом, вы можете запретить авторизацию общего ключа для учетной записи хранения. Подробный доступ к данным с минимальными привилегиями рекомендуется в качестве рекомендации по обеспечению безопасности. Авторизация на основе идентификатора Microsoft Entra с помощью управляемых удостоверений должна использоваться для сценариев, поддерживающих OAuth. Kerberos или SMTP следует использовать для Файлы Azure по протоколу S МБ. Для Файлы Azure по протоколу REST можно использовать маркеры SAS. Доступ к общему ключу следует отключить, если не требуется, чтобы предотвратить его непреднамеренное использование. Дополнительные сведения см. в статье Предотвращение авторизации с общим ключом для учетной записи службы хранения Azure.

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

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

Просмотр ключей доступа к учетной записи

Вы можете просматривать и копировать ключи доступа к учетной записи с помощью портала Azure, PowerShell или Azure CLI. Портал Azure также предоставляет строку подключения для вашей учетной записи хранения, которую можно скопировать.

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

  1. Войдите в свою учетную запись хранения на портале Azure.

  2. В разделе Безопасность и сетьвыберите Ключи доступа. Появятся ключи доступа к учетной записи и полная строка подключения для каждого ключа.

  3. Выберите Показать ключи, чтобы просмотреть ключи доступа и строки подключения, а также включить кнопки для копирования значений.

  4. В разделе key1 найдите значение Ключа. Нажмите кнопку Копировать, чтобы скопировать ключ учетной записи.

  5. Кроме того, можно скопировать всю строку подключения. В разделе key1 найдите значение Строки подключения. Нажмите кнопку Копировать, чтобы скопировать строку подключения.

    Снимок экрана, показывающий, как просмотреть ключи доступа на портале Azure

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

Для просмотра или чтения ключей доступа учетной записи пользователь должен быть администратором службы, или ему должна быть назначена роль Azure, включающая в себя Microsoft.Storage/storageAccounts/listkeys/action. Некоторые встроенные роли Azure включают в себя это действие. Это роли владелец, участник и оператор обслуживания ключей учетной записи хранения. Дополнительные сведения о роли службы Администратор istrator см. в ролях Azure, ролях Microsoft Entra и роли администратора классической подписки. Подробные сведения о встроенных ролях Azure для службы хранилища Azure, как для служб данных, так и для службы управления, см. в разделе Хранилище статьи Встроенные роли Azure для Azure RBAC.

Использование хранилища ключей Azure Key Vault для управления ключами доступа

Корпорация Майкрософт рекомендует использовать Azure Key Vault для управления ключами доступа и их ротации. Приложение может безопасно получать доступ к ключам в Key Vault, что позволяет избежать их хранения в коде приложения. См. дополнительные сведения об использовании Azure Key Vault в следующих статьях:

Выполнение ротации ключей доступа вручную

Корпорация Майкрософт рекомендует периодически выполнять ротацию ключей доступа, чтобы защитить свою учетную запись хранения. По возможности рекомендуется использование Azure Key Vault для управления ключами доступа. Если вы не используете Key Vault, необходимо будет вручную производить замену ключей.

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

Предупреждение

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

Кроме того, смена или повторное создание ключей доступа отменяет подписанные URL-адреса (SAS), созданные на основе этого ключа. После смены ключа доступа необходимо повторно создать учетные записи и маркеры SAS службы , чтобы избежать сбоев в приложениях. Обратите внимание, что маркеры SAS делегирования пользователей защищены учетными данными Microsoft Entra и не влияют на смену ключей.

Если вы планируете выполнять смену ключей доступа вручную, корпорация Майкрософт рекомендует настроить политику срока действия ключей. Дополнительные сведения см. в статье Создание политики срока действия ключей.

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

Для ротации ключей доступа к учетной записи хранения через портал Azure:

  1. Обновите строки подключения в коде приложения, чтобы ссылаться на дополнительный ключ доступа учетной записи хранения.
  2. Войдите в свою учетную запись хранения на портале Azure.
  3. В разделе Безопасность и сетьвыберите Ключи доступа.
  4. Чтобы повторно создать первичный ключ доступа для учетной записи хранения, нажмите кнопку Повторно создать рядом с первичным ключом доступа.
  5. Обновите строки подключения в коде, чтобы они ссылались на новый основной ключ доступа.
  6. Повторите процедуру, чтобы повторно создать вторичный ключ доступа.

Внимание

Во всех приложениях рекомендуется использовать одновременно только один из ключей. Если в одних приложениях используется ключ 1, а в других — ключ 2, вы не сможете произвести смену ключей без того, чтобы некоторые приложения утратили доступ.

Для выполнения ротации ключей доступа учетной записи пользователь должен быть администратором службы, или ему должна быть назначена роль Azure, включающая в себя Microsoft.Storage/storageAccounts/regeneratekey/action. Некоторые встроенные роли Azure включают в себя это действие. Это роли владелец, участник и оператор обслуживания ключей учетной записи хранения. Дополнительные сведения о роли службы Администратор istrator см. в ролях Azure, ролях Microsoft Entra и роли администратора классической подписки. Подробные сведения о встроенных ролях Azure для службы хранилища Azure см. в разделе Хранилище статьи Встроенные роли Azure для Azure RBAC.

Создание политики срока действия ключа

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

Примечание.

Перед созданием политики срока действия ключей может потребоваться выполнить смену каждого из ключей доступа к учетной записи хотя бы один раз.

Чтобы создать политику срока действия ключей на портале Azure, выполните следующие действия:

  1. Войдите в свою учетную запись хранения на портале Azure.
  2. В разделе Безопасность и сетьвыберите Ключи доступа. Появятся ключи доступа к учетной записи и полная строка подключения для каждого ключа.
  3. Нажмите кнопку Установить напоминание о смене ключей. Если кнопка Установить напоминание о смене ключей неактивна, вам придется сменить каждый из ключей. Соответствующие действия описаны в руководстве Выполнение ротации ключей доступа вручную.
  4. В разделе Установка напоминания о смене ключей доступа установите флажок Включить напоминания о смене ключей и задайте частоту напоминания.
  5. Выберите Сохранить.

Снимок экрана: создание политики истечения срока действия ключа в портал Azure

Проверка нарушений для политики срока действия ключей

Вы можете отслеживать учетные записи хранения с помощью Политики Azure, чтобы убедиться, что смена ключей доступа учетной записи выполняется в течение рекомендуемого периода времени. Служба хранилища Azure предоставляет встроенную политику, которая обеспечивает своевременную смену ключей. Дополнительные сведения о встроенной политике см. в разделе Ключи учетной записи хранения не должны быть просрочены статьи Список определений встроенных политик.

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

Чтобы назначить встроенную политику соответствующей области на портале Azure, выполните указанные ниже действия:

  1. На портале Azure выполните поиск по слову Политика, чтобы найти панель мониторинга "Политика Azure".

  2. В разделе Разработка выберите Назначения.

  3. Выберите Назначить политику.

  4. На вкладке Основные сведения страницы Назначение политики в разделе Область укажите область назначения политики. Чтобы выбрать подписку и группу ресурсов (при желании), нажмите кнопку Дополнительно.

  5. В поле Определение политики нажмите кнопку Дополнительно и введите текст ключи учетной записи хранения в поле Поиск. Выберите определение политики Ключи учетной записи хранения не должны быть просрочены.

    Снимок экрана: выбор встроенной политики для отслеживания интервалов смены ключей для учетных записей хранения

  6. Чтобы назначить определение политики указанной области, выберите Просмотреть и создать.

    Снимок экрана: создание назначения политики

Отслеживание соответствия для политики срока действия ключей

Чтобы отслеживать учетные записи хранения на соответствие политике срока действия ключей, выполните указанные ниже действия:

  1. На панели мониторинга Политики Azure найдите встроенное определение политики для области, указанной в назначении политики. Чтобы найти встроенную политику, можно ввести текст Ключи учетной записи хранения не должны быть просрочены в поле Поиск.

  2. Выберите имя политики с нужной областью.

  3. На странице Назначение политики для встроенной политики выберите Просмотр соответствия. В отчете о соответствии отображаются все учетные записи хранения в указанной подписке и группе ресурсов, которые не соответствуют требованиям политики.

    Снимок экрана: просмотр отчета о соответствии для встроенной политики окончания срока действия ключа

Чтобы обеспечить соответствие требованиям для учетной записи хранения, выполните смену ключей доступа к учетной записи.

Следующие шаги