Устранение проблем с политикой доступа к Azure Key Vault
Часто задаваемые вопросы
Я не могу перечислить или получить секреты, ключи или сертификат. Я вижу ошибку "что-то пошло не так"
Если у вас возникли проблемы с описанием, получением или созданием или доступом к секрету, убедитесь, что у вас есть политика доступа, определенная для этой операции: политики доступа Key Vault
Как можно определить, как и когда осуществляется доступ к хранилищам ключей?
Создав одно или несколько хранилищ ключей вы, вероятно, захотите отслеживать, кто, как и когда осуществлял доступ к этим хранилищам. Вы можете выполнять мониторинг, включив ведение журнала для Azure Key Vault. Пошаговые инструкции по включению ведения журнала см. в этой статье.
Как отслеживать доступность хранилища, периоды задержки веб-службы или другие метрики производительности для хранилища ключей?
После начала масштабирования службы количество запросов, отправленных в хранилище ключей, будет возрастать. Такой спрос может увеличить задержку ваших запросов и в крайних случаях привести к регулированию ваших запросов, что приведет к снижению производительности вашей службы. Вы можете отслеживать метрики производительности хранилища ключей и получать оповещения по конкретным пороговым значениям. Пошаговые инструкции по настройке мониторинга см. в этой статье.
Я не могу изменить политику доступа, как ее можно включить?
Пользователь должен иметь достаточные разрешения Microsoft Entra для изменения политики доступа. В этом случае пользователю потребуется роль участника более высокого уровня.
Я вижу ошибку "Неизвестная политика". Что это означает?
Существует две причины, по которым в разделе "Неизвестно" может появить политика доступа:
- Предыдущий пользователь имел доступ, но этот пользователь больше не существует.
- Политика доступа была добавлена с помощью PowerShell с помощью объекта приложения вместо субъекта-службы.
Как можно назначить управление доступом для каждого объекта хранилища ключей?
Следует избегать назначения ролей для отдельных ключей, секретов и сертификатов. Исключения для общих рекомендаций:
Сценарии, в которых отдельные секреты должны совместно использоваться для нескольких приложений, например, одному приложению требуется доступ к данным из другого приложения.
Как обеспечить проверку подлинности хранилища ключей с помощью политики управления доступом?
Самый простой способ проверить подлинность облачного приложения в Key Vault — с помощью управляемых удостоверений. Дополнительные сведения см. в статье Проверка подлинности в Azure Key Vault. Если вы создаете локальное приложение, выполняете локальную разработку или не сможете использовать управляемое удостоверение, можно зарегистрировать субъект-службу вручную и предоставить доступ к хранилищу ключей с помощью политики управления доступом. Ознакомьтесь со статьей Назначение политики доступа к Key Vault с помощью портала Azure.
Как предоставить группе AD доступ к хранилищу ключей?
Предоставьте разрешения группе AD для хранилища ключей с помощью команды Azure CLI az keyvault set-policy
или командлета Azure PowerShell Set-AzKeyVaultAccessPolicy. Ознакомьтесь со статьями Назначение политики доступа к Key Vault и Назначение политики доступа к Key Vault с помощью Azure PowerShell.
Приложению также требуется по крайней мере одна роль Системы управления идентификацией и доступом (IAM), назначенная хранилищу ключей. В противном случае оно не сможет войти в систему и завершится ошибкой о недостаточных правах доступа к подписке. Для групп Microsoft Entra с управляемыми удостоверениями может потребоваться много часов для обновления маркеров и станут эффективными. Сведения об ограничении использования управляемых удостоверений для авторизации
Как выполнить повторное развертывание Key Vault с помощью шаблона Resource Manager без удаления существующих политик доступа?
В настоящее время повторное развертывание Key Vault удаляет любую политику доступа в Key Vault и заменяет их политикой доступа в шаблоне ARM. Для политик доступа Key Vault нет добавочного параметра. Чтобы сохранить политики доступа в Key Vault, необходимо считать имеющиеся политики доступа в Key Vault и заполнить ими шаблон Resource Manager для избежания сбоев при доступе.
Другой вариант, который может помочь в этом сценарии, — использовать Azure RBAC и роли в качестве альтернативы политикам доступа. С помощью Azure RBAC можно повторно развернуть хранилище ключей, не указав политику еще раз. Дополнительные сведения об этом решении см. здесь.
Рекомендуемые действия по устранению неполадок для указанных ниже типов ошибок:
- HTTP 401: запрос не прошел проверку подлинности — действия по устранению неполадок;
- HTTP 403: недостаточно разрешений — действия по устранению неполадок;
- HTTP 429: слишком много запросов — действия по устранению неполадок.
- Проверьте, удаляете ли вы разрешение на доступ к хранилищу ключей: см . статью "Назначение политики доступа" — CLI, назначение политики доступа — PowerShell или назначение политики доступа на портале.
- Если у вас возникли проблемы при проверке подлинности в Key Vault в коде, используйте пакет SDK проверки подлинности.
Каковы рекомендации при регулировании хранилища ключей?
Следуйте рекомендациям, описанным здесь.
Next Steps
Узнайте, как устранять неполадки при проверке подлинности в хранилище ключей: Руководство по устранению неполадок в Azure Key Vault.