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

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

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

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

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

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

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


azure oauth-2.0 azure-management-api impersonation
person Prodip    schedule 29.02.2020    source источник

Ответы (3)


arrow_upward
4
arrow_downward

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

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

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

введите здесь описание изображения

3) Перейдите к ресурсу Azure (уровень подписки, группы ресурсов или группы управления в зависимости от ваших требований) и добавьте роль IAM / RBAC в зарегистрированное приложение. Я назначил роль Contributor приложению TestPermissions на уровне подписки.

введите здесь описание изображения

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

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

введите здесь описание изображения

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

введите здесь описание изображения

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

введите здесь описание изображения

person Prodip    schedule 01.03.2020

arrow_upward
1
arrow_downward

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

Основной способ, который я видел, когда требуются ограничения, - это то, что вы:

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

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

person juunas    schedule 29.02.2020
comment
Мне понравилось ваше предложение. Вы можете иметь в виду поток учетных данных клиента oauth2, где взаимодействие с пользователем не требуется, верно? Я собираюсь попробовать это и поделиться своими отзывами здесь. Выдача себя за другое лицо облегчает работу, но, как вы упомянули, это вопрос доверия и того, на какой риск вы можете пойти. - person Prodip; 01.03.2020
comment
Ваше предложение сработало, спасибо за советы. Поделюсь решением в разделе ответов. Спасибо еще раз. - person Prodip; 01.03.2020

arrow_upward
0
arrow_downward

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

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

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

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

person Gaurav Mantri    schedule 29.02.2020
comment
Привет, Гаурав. Спасибо, что нашли время, чтобы ответить на вопрос. Вы абсолютно правы в отношении RBAC пользователя и объема RBAC - от уровня группы управления до уровня ресурсов. Меня не слишком заботит встроенная роль читателя. Я имею в виду пользователей, которые обычно регистрируют приложения в Azure AD, и они, как правило, являются владельцами подписок или членами ролей каталогов с более высокими привилегиями, включая глобального администратора (боги!). Что они нажимают на созданный URL-адрес для тестирования или попадают в ловушку попытки фишинга? Вызывает беспокойство выдача себя за привилегированную учетную запись. - person Prodip; 29.02.2020
comment
То же самое может произойти и с вашим примером графического API, верно? Администратор тоже может ошибиться. - person Gaurav Mantri; 29.02.2020
comment
Гаурав - да, это может случиться с любым делегированным разрешением. Опять же, я бы не стал слишком беспокоиться, если приложение может читать информацию о каталоге. - person Prodip; 01.03.2020