Почему я должен использовать управляемую идентификацию?

В чем преимущество использования управляемой идентификации для доступа к службам Azure? Я часто упоминаю о том, что благодаря этому вы не сохраняете секреты в файлах конфигурации. Но я развертываю все ресурсы с помощью шаблонов ARM, и у меня также нет никаких секретов в моих файлах конфигурации. Такие параметры, как строки подключения, задаются во время развертывания. Единственное различие, которое я вижу здесь, заключается в том, что с управляемой идентификацией, даже если кто-то перейдет на портал Azure, он не сможет, например, получить логин и пароль для моей БД. Но у этого человека уже есть доступ к моей подписке. Так это проблема?

Что еще мне дают управляемые удостоверения?


azure azure-devops azure-managed-identity azure-active-directory
person Piotr Perak    schedule 06.04.2020    source источник

Ответы (4)


arrow_upward
4
arrow_downward

Речь идет не только о секретах конфигурации, которые хранятся или нет, но и о том, сколько секретов необходимо хранить и управлять ими.
Когда вы создаете управляемое удостоверение, в частности system- назначенный управляемый идентификатор, никто из вашей команды не должен будет управлять секретами, связанными с идентификатором приложения, или даже иметь к ним доступ. Удостоверение выдается, и вы можете предоставить ему доступ к различным ресурсам, например к хранилищу ключей. Никто другой не сможет использовать удостоверение приложения и воспользоваться этим доступом.

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

person ChiefMcFrank    schedule 06.04.2020
comment
в основном то, что я пытался сказать, но вы ответили лучше - person Thiago Custodio; 07.04.2020

arrow_upward
3
arrow_downward

Вы просто видите счастливый путь. Что, если злоумышленник воспользуется уязвимостью в вашем приложении и получит, например, строку подключения? Если вы используете Managed Identity, он / она не сможет выдавать себя за вашу службу.

person Thiago Custodio    schedule 06.04.2020
comment
и чтобы избежать доступа к подписке, всегда используйте 2Fa - person Thiago Custodio; 07.04.2020

arrow_upward
1
arrow_downward

  • Управление секретами / ключами. Передача секретов - лучшая практика. Это делается автоматически с помощью Managed Identities. Сложно при смене паролей вручную / скриптингом.

  • Секретный / ключевой инвентарь. Упрощает просмотр того, какие приложения и какие разрешения имеют.

  • Отмена доступа. Упрощает отмену доступа к определенному приложению. Может быть страшно отозвать доступ, например, обновив пароль.

  • Гранулярность. Предоставление доступа строки подключения к учетной записи хранения предоставит полный доступ ко всему в этой учетной записи хранения. Используя MI / RBAC для ресурсов, можно установить, например, доступ для чтения к определенному BLOB-объекту.

person jed.johan    schedule 14.07.2020

arrow_upward
0
arrow_downward

почему бы не использовать шифрование в строке подключения. Управляемый идентификатор находится на машине и может быть скомпрометирован, если кто-то получит доступ к машине.

person Sha    schedule 09.04.2020
comment
Я сомневаюсь, что вы сможете сделать это в Azure. Когда его зашифровать? Что, если вы развернете его с помощью шаблонов ARM? Что, если ваше приложение масштабируется для работы в нескольких копиях на нескольких виртуальных серверах? - person Piotr Perak; 10.04.2020