Служебная учётная запись или субъект-служба в Power Automate

Когда поток работает в продуктивной среде, выбор базовой идентичности определяет, продолжит ли он работать даже тогда, когда коллега заболела, истёк срок действия пароля или кто-то уволился из компании. Именно здесь в Power Automate снова и снова встаёт один и тот же вопрос: должен ли поток выполняться под классической служебной учётной записью, то есть общей учётной записью пользователя, или под субъектом-службой, то есть самостоятельной, нечеловеческой идентичностью в Microsoft Entra ID?

Краткий ответ из официальной документации однозначен: для критически важных для бизнеса продуктивных потоков Microsoft рекомендует субъект-службу и прямо не считает классическую служебную учётную запись лучшей практикой. Тем не менее стоит внимательнее рассмотреть обе модели, поскольку технически они работают по-разному и предъявляют разные требования.

Что такое служебная учётная запись в Power Automate?

Согласно документации Microsoft о лицензировании Power Automate служебная учётная запись представляет собой обычную учётную запись пользователя Microsoft Entra, которая используется не по прямому назначению для представления нечеловеческой сущности, например приложения или службы. На практике это означает, что команда создаёт учётную запись вроде flow-production@company.de, передаёт пароль нескольким коллегам, и эта учётная запись становится владельцем продуктивных потоков.

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

Что такое субъект-служба?

Согласно документации Microsoft о поддержке потоков, принадлежащих субъекту-службе субъект-служба является нечеловеческой идентичностью безопасности, которая представляет приложение или службу и может самостоятельно владеть ресурсами в Azure и Power Platform и управлять ими. Технически в её основе лежит регистрация приложения Microsoft Entra. Чтобы субъект-служба вообще мог владеть потоками в Power Platform, сначала необходимо создать так называемого пользователя приложения, либо через центр администрирования Power Platform, либо через API.

После настройки этого пользователя приложения ему можно передать владение облачным потоком: в потоке вы открываете раздел «Сведения», выбираете «Изменить» и заменяете владельца именем пользователя приложения. Важно: согласно документации, субъект-служба не может стать совладельцем потока, а может быть только единоличным владельцем. Для потока вне решения дополнительно необходимо явно предоставить пользователю приложения доступ ко всем используемым подключениям; для потока в составе решения этот шаг не требуется.

Служебная учётная запись или субъект-служба: помощь в принятии решения

Для повседневной практики решение можно свести к чётким критериям, которые также описывает документация Microsoft о доступе к потокам Power Automate:

Критически важные для бизнеса или общекорпоративные потоки: здесь Microsoft прямо рекомендует субъект-службу, поскольку владение потоком тем самым полностью отделяется от жизненного цикла отдельного человека. Если кто-то увольняется из компании или меняет роль, поток остаётся незатронутым.
Конвейеры DevOps в нескольких средах: тем, кто автоматически разворачивает потоки из разработки через тестирование в продуктив, согласно документации, также стоит полагаться на субъект-службу, поскольку им можно аккуратно управлять через API.
Проверяемость (аудит): субъект-служба оставляет чёткий, не привязанный к конкретному человеку аудиторский след. При общей служебной учётной записи часто остаётся неясным, кто, что и когда изменил.
Интерактивные или специфичные для пользователя потоки: если потоку нужен персональный контекст человека, например для согласований или персонализированных прав доступа, правильным выбором по-прежнему остаётся обычная учётная запись пользователя, а не служебная учётная запись и не субъект-служба.
Существующие служебные учётные записи: если вы хотите перевести работающий поток со служебной учётной записи на субъект-службу, вам также следует проверить лимиты лицензий и запросов; подробнее об этом ниже.

Не стоит недооценивать лицензирование и лимиты запросов

Субъект-служба, владеющий потоком, считается в Power Automate неинтерактивным пользователем приложения и поэтому не может получить обычную пользовательскую лицензию. Вместо этого действуют собственные, нелицензируемые лимиты запросов, а как только поток использует премиум-коннекторы, ему требуется лицензия Power Automate Process или лицензия на поток, либо, в качестве альтернативы, членство в группе потоков с соответствующей лицензией.

Для классической же служебной учётной записи действует обычная логика лицензирования пользовательских учётных записей, дополненная специальным правилом против так называемого мультиплексирования: если несколько человек используют общие учётные данные служебной учётной записи и поток задействует премиум-функции, документация рекомендует лицензию Process для потока, как только учётную запись начинает использовать много разных людей, чтобы вновь добавляемые пользователи автоматически оставались лицензионно корректными. Служебную учётную запись не следует путать с неинтерактивными учётными записями пользователей, которые Dataverse предусматривает для фоновых процессов, таких как миграция данных: их допускается максимум семь на одного клиента, и сам Power Automate, согласно документации, пока не поддерживает этот особый тип учётной записи в качестве владельца потока.

А что насчёт управляемого удостоверения (managed identity)?

Тот, кто пришёл из мира Azure, при мысли о нечеловеческих идентичностях быстро вспоминает об управляемых удостоверениях, то есть идентичностях, назначаемых системой или пользователем, которые делают учётные данные полностью ненужными. Однако для облачных потоков Power Automate эта концепция пока не является прямой опцией: управляемые удостоверения закреплены прежде всего в Azure Logic Apps, где через них могут аутентифицироваться определённые встроенные и управляемые коннекторы, такие как Azure Key Vault, Azure Blob Storage или Azure SQL. В самом Power Automate сопоставимую задачу, дать потоку стабильную, не зависящую от отдельных людей идентичность, выполняет субъект-служба. Тем, кто одновременно эксплуатирует потоки и Logic Apps, стоит помнить об этом различии, а не отождествлять мысленно оба понятия.

Переход на практике: от служебной учётной записи к субъекту-службе

Переход происходит в три шага: сначала вы создаёте регистрацию приложения в Microsoft Entra ID и на её основе создаёте пользователя приложения в Power Platform. Затем вы явно предоставляете этому пользователю приложения доступ ко всем подключениям, которые использует поток, если только это не поток в составе решения. Наконец, вы меняете в потоке владельца на нового пользователя приложения и снова включаете поток. Для этого последнего шага заложите короткий тестовый прогон, прежде чем отключать прежнюю служебную учётную запись, чтобы продуктивные процессы не остались без результата.

Тем, кто не хочет самостоятельно проводить перевод нескольких продуктивных потоков со служебных учётных записей на субъекты-службы, поддержку окажет предложение NordFlux по Power Automate, от настройки регистрации приложения до защиты структуры лицензий и прав доступа. Так вы сохраняете контроль над тем, кто владеет той или иной автоматизацией и управляет ею, даже по мере роста ландшафта потоков.

Часто задаваемые вопросы

Запрещена ли служебная учётная запись для продуктивных потоков?

Не запрещена, но Microsoft прямо не считает её лучшей практикой. Для критически важных для бизнеса или долго работающих потоков документация вместо этого чётко рекомендует субъект-службу, поскольку он не зависит от отдельных людей или общих паролей.

Может ли субъект-служба быть совладельцем потока?

Нет. Согласно документации, пользователь приложения субъекта-службы может быть только единоличным владельцем потока, но не совладельцем. Поэтому в диалоге редактирования совладельцев он вообще не отображается.

Нужна ли субъекту-службе собственная лицензия Power Automate?

Субъект-служба является неинтерактивным пользователем приложения и поэтому не может получить обычную пользовательскую лицензию. Как только поток использует премиум-коннекторы, ему вместо этого требуется лицензия Power Automate Process или лицензия на поток, либо членство в группе потоков с подходящей лицензией.

Можно ли использовать управляемое удостоверение и в Power Automate?

Не напрямую для владения облачным потоком. Управляемые удостоверения представляют собой прежде всего концепцию Azure Logic Apps для аутентификации в отношении определённых ресурсов Azure. В Power Automate сопоставимую роль стабильной, нечеловеческой идентичности потока выполняет субъект-служба.

Что происходит с существующими подключениями при смене владельца?

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