Устранение неполадок политики доступа Azure Key Vault

Часто задаваемые вопросы

Я не могу перечислить или получить секреты, ключи или сертификат. Я вижу ошибку "что-то пошло не так"

Если у вас возникла проблема с описанием, получением, созданием или доступом к секрету, убедитесь, что у вас есть соответствующая роль Azure RBAC. См. Azure RBAC для Key Vault. Если вы используете устаревшую модель политики доступа, см. раздел Назначение политики доступа к хранилищу ключей.

Как определить, как и когда к хранилищам ключей обращаются?

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

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

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

Я не могу изменить политику доступа, как ее можно включить?

Пользователь должен иметь достаточные Microsoft Entra разрешения для изменения политики доступа. В этом случае пользователю потребуется более высокая роль участника.

Я вижу ошибку "Неизвестная политика настройки". Что это обозначает?

Существует две причины, по которым в разделе "Неизвестно" может появиться политика доступа.

• Предыдущий пользователь имел доступ, но этот пользователь больше не существует.
• Политика доступа была добавлена с помощью PowerShell, при этом вместо основного элемента службы использовался объект приложения.

Как назначить управление доступом для каждого объекта хранилища ключей?

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

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

Как разрешить проверку подлинности для хранилища ключей с помощью политики управления доступом?

Самый простой способ проверки подлинности облачного приложения для Key Vault является управляемым удостоверением; дополнительные сведения см. в статье Authenticate для Azure Key Vault. Если вы создаете локальное приложение, выполняете локальную разработку или не можете использовать управляемое удостоверение, вместо этого можно зарегистрировать сервисный принципал вручную и предоставить доступ к хранилищу ключей с помощью Azure RBAC. См. Azure RBAC для операций на дата-плоскости Key Vault.

Как предоставить группе AD доступ к хранилищу ключей?

Предоставьте группе AD разрешения для хранилища ключей с помощью Azure RBAC с командой Azure CLI az role assignment create или командлетом Azure PowerShell New-AzRoleAssignment. См. система Azure RBAC для операций в плоскости данных Key Vault.

Замечание

При использовании устаревших политик доступа можно использовать команду Azure CLI az keyvault set-policy или командлет Azure PowerShell Set-AzKeyVaultAccessPolicy. Однако Azure RBAC является рекомендуемой моделью авторизации. См. раздел Назначение политики доступа для Key Vault.

Приложению также требуется по крайней мере одна роль управления удостоверениями и доступом (IAM), назначенная хранилищу ключей. В противном случае он не сможет войти в систему, и произойдет сбой из-за недостаточных прав на доступ к подписке. Группы Microsoft Entra с управляемыми удостоверениями могут потребовать много часов на обновление токенов, прежде чем они начнут действовать. См. ограничения использования управляемых удостоверений для авторизации

Как повторно развернуть Key Vault с помощью шаблона ARM без удаления существующих политик доступа?

В настоящее время повторное развертывание данного Key Vault удаляет любую политику доступа в этом хранилище и заменяет её политикой доступа из шаблона ARM. Для политик доступа Key Vault нет добавочного параметра. Чтобы сохранить политики доступа в Key Vault, необходимо прочитать существующие политики доступа в Key Vault и заполнить шаблон ARM этими политиками, чтобы избежать сбоев доступа.

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

Рекомендуемые действия по устранению неполадок для следующих типов ошибок

• HTTP 401. Запрос без проверки подлинности — действия по устранению неполадок
• HTTP 403: недостаточно разрешений — действия по устранению неполадок
• HTTP 429: слишком много запросов — действия по устранению неполадок
• Проверьте, удалено ли разрешение на доступ к key vault: см. раздел Azure RBAC для Key Vault. При использовании устаревших политик доступа, см. Назначение политики доступа к Key Vault.
• Если у вас возникли проблемы с проверкой подлинности в коде для хранилища ключей, используйте SDK для проверки подлинности

Какие лучшие практики следует использовать, если хранилище ключей подвергается ограничению?

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

Дальнейшие шаги

Узнайте, как устранять ошибки аутентификации хранилища ключей: Руководство по устранению неполадок Key Vault.