Ограничение доступа к хранилищу лазурного ключа

Question

Я хочу создать хранилище ключей Azure с довольно ограниченным доступом (одно или два наших приложения).Я создал Key Vault через портал Azure, но когда я просматриваю раздел «Контроль доступа», я обнаружил, что несколько приложений и пользователей имеют роль Contributor (унаследованную от подписки) для хранилища ключей, что дает им больше доступа, чемони должны иметь.

Поскольку подписка - это самый высокий уровень, на котором можно установить контроль доступа, я не могу отозвать доступ для этих приложений / пользователей, не отменяя его на уровне подписки, и это, вероятно, вызовет все видыпроблем.(не совсем понятно, какие разрешения им нужны, поэтому было бы немного больно выдавать эти разрешения на уровне группы ресурсов или ресурса).Более того, ничто не остановит того, кто придет позже, от добавления ролей участника на уровне подписки (например, для какого-то нового приложения) и нарушения безопасности хранилища ключей.

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

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

Answer 1

Похоже, что вы не можете добиться этого при сегодняшней работе RBAC.

Вот пара запросов обратной связи, уже запущенных на Форумы обратной связи - https://feedback.azure.com. Oneдля Key Vault, а другой - на примере учетной записи хранения, но, по сути, ищет ту же функцию для переопределения унаследованных разрешений.

Возможно, вы захотите проголосовать за эти запросы.

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

2. Исключать / переопределять разрешения RBAC, полученные из подписки науровень группы ресурсов

ОБНОВЛЕНИЕ (для ответа на дополнительные запросы из комментариев):

Не предоставление доступа на уровне подписки впервое место (кроме админов)

Да, это определенно поможет.

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