К обсуждениям

Перенос Azure из личного в рабочий тенант: карта границ подписки, приложений и домена

Редакция VOne Технологии

План миграции Azure без обещания «перенести всё»: инвентаризируем подписку и ресурсы, отдельно app registrations и service principals, RBAC, управляемые идентичности, домен и внешние интеграции.

Нарисуйте пять контуров вместо одного переноса

Создайте инвентарь: Azure subscription и ресурсы; Azure RBAC и managed identities; Microsoft Entra app registrations; service principals и согласия; проверенные домены и внешние интеграции, включая WOPI. Для каждого объекта укажите текущий tenant, владельца, идентификатор, секрет или сертификат только как факт наличия, redirect URI и потребителей. Не помещайте сами секреты в таблицу. Пока объект не отнесён к контуру, его нельзя считать включённым в план.

Оцените последствия смены каталога подписки

Microsoft называет перенос подписки между каталогами сложным и предупреждает, что назначения ролей и custom roles из исходного каталога не переносятся, а зависимые ресурсы могут требовать восстановления. Сверьте каждый тип ресурса с актуальной таблицей влияния, отдельно отметьте Key Vault, managed identities и сервисы, зависящие от security principals. Не назначайте дату переключения, пока не определены простой, порядок восстановления доступа и ответственный за каждый ресурс.

Не путайте app registration и service principal

Официальная модель Entra различает application object в домашнем tenant и service principal как локальный экземпляр в конкретном tenant. Перемещение подписки не превращает автоматически регистрацию приложения в объект нового каталога. Для каждого приложения зафиксируйте single-tenant или multitenant, home tenant, owners, redirect URI, API permissions, certificates, federated credentials и связанные service principals. Решение «перерегистрировать» или «дать consent» принимайте по архитектуре, а не по совпадению имени.

Проведите репетицию на некритичной зависимости

Выберите один некритичный ресурс и одно тестовое приложение без пользовательских данных. В целевом tenant заранее создайте необходимые владельцы и роли, проверьте вход, токен, redirect URI и доступ к ресурсу, затем удалите тестовый доступ. Не используйте рабочий домен или WOPI endpoint для первой репетиции. Сравните фактические шаги с инвентарём и добавьте пропущенные зависимости. Репетиция должна быть обратимой и не требовать переноса production-подписки.

Гейт переключения и пакет поддержки

Переключение допустимо только при экспортированном инвентаре, подтверждённых владельцах обеих сторон, резервных административных учётных записях, плане RBAC после переноса, проверке managed identities, окне простоя и способе возврата либо восстановления. В поддержку передавайте тип подписки, список типов ресурсов, исходный и целевой tenant в замаскированном виде и конкретную неподдерживаемую зависимость. Не публикуйте tenant ID, client secrets, сертификаты, redirect URL с токенами или WOPI-конфигурацию.

Материал подготовлен самостоятельно с автоматизацией и редакционно проверен 30 июля 2026 года по обезличенному сигналу Microsoft Q&A и официальной документации Microsoft; домены, tenant ID, подписки и конфигурации автора не использовались.

Источники и проверка

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

Ответы

0 опубликовано
Ответов пока нет. Вы можете начать обсуждение.

Ваш ответ

Добавьте свой опыт или уточнение по теме.

Вы публикуете как Аноним Аватар отличает разговоры, но не раскрывает личные данные.

Ответ появится сразу. Не публикуйте личные данные, ключи и приватные ссылки.