Azure API управления ресурсами без user_impersonation, возможно ли это?

Question

Я пытаюсь найти рекомендации по безопасности для разрешений приложений в контексте azure управления ресурсами.

В настоящее время для управления указано только одно разрешение. azure .com, и это управление . azure .com / user_impersonation (превью). Это олицетворение делегированного пользователя может быть серьезной проблемой и может привести к захвату аккаунта вредоносным приложением.

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

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

В отличие от API Graph (graph.microsoft.com), в котором можно вручную выбрать разрешение (user.read) и API управления ресурсами. есть только одна опция - user_impersonation!

Вы можете поспорить, почему привилегированный пользователь санкционирует действие, но люди делают ошибки. Наша работа заключается в том, чтобы остановить или минимизировать такой риск путем разработки. Итак, как лучше всего разрешить приложению управлять ресурсами в azure и минимизировать риск безопасности?

Answer 1

Это правда, что, предоставляя это разрешение, вы позволяете приложению действовать как вы со всеми доступными разрешениями.

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

• Зарегистрировали приложение в своем Azure AD
• Предоставьте субъекту службы необходимые роли (например, Reader на указанных c ресурсах)
• Установите идентификатор клиента, идентификатор клиента, секрет клиента и т. Д. c. в приложении

Это, конечно, требует, чтобы само приложение поддерживало этот подход. Если он допускает использование только через олицетворение, то вам нужно либо доверять, либо не использовать его.

Answer 2

Спасибо @juunas за наброски и советы. Спасибо @Gaurav за попытку ответить на мой вопрос. Мне удалось изменить ресурсы azure в подписке, не предоставляя user_impersonation для управления. azure .com api. Вот шаги -

1) Зарегистрируйте приложение (TestPermissions в моем случае)

2) Добавьте разрешения API (необязательно). Вам не нужно добавлять управление. azure .com.

3) Go ресурс Azure (подписка, ресурс уровень группы или группы управления на основе ваших требований) и добавьте роль IAM / RBA C в зарегистрированное приложение. Я назначил роль «Участник» приложению TestPermissions на уровне подписки.

4) Запрос токена доступа oauth2 после потока предоставления учетных данных клиента . Вы можете указать client_id и client_secret в теле запроса POST или в виде заголовка, закодированного в Basei c base64 (это я и сделал). Сохраните токен доступа для будущего использования (до истечения срока его действия).

Примечание. Я не смог добавить несколько аудиторий (сфер) одновременно. Если вы хотите получить токен для Graph API, вы можете запросить отдельный токен, изменив область действия на http://graph.microsoft.com/.default

5) Используйте токен доступа, полученный на предыдущем шаге, для взаимодействия с azure диспетчером ресурсов. При каждом запросе вам нужно будет добавлять токен переноса jwt в заголовок авторизации (здесь не показан) в https://management.azure.com. В этом примере я создаю новую группу ресурсов с именем TestCreateRG003 для одной из моих подписок Pay-as-you- go.

6 ) Давайте проверим / подтвердим, что ресурс создан или обновлен в Azure. Бин go, вот они! Приложение может считывать / изменять (на основе RBA C) azure ресурсов без предоставления разрешения на олицетворение.

Answer 3

Дайте мне посмотреть, смогу ли я ответить на этот вопрос.

Когда пользователь запрашивает токен для management.azure.com, в это время все делается для того, чтобы у пользователя было разрешение на выполнение Azure ARM API. Это не значит, что они могут делать все возможное с Azure ARM API.

То, что они могут делать, контролируется Azure Role Based Access Control (RBAC). Поэтому, если пользователь играет роль Reader, токен, полученный от имени пользователя, может только читать информацию о ресурсах в своей подписке Azure. Им не будет разрешено создавать, обновлять или удалять ресурсы в своей подписке Azure.

Вам нужно будет предоставить пользователям соответствующую роль RBA C, чтобы минимизировать риски неправомерного использования.