Централизация идентификации в 2026 году: миграция на единую IAM-платформу с минимальным простоем

Краткий ответ: какую стратегию IAM-миграции выбрать

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

Сценарий Big Bang подходит небольшому и однородному контуру: до 10-15 типовых приложений, один каталог, единое окно изменений, полная репетиция и технически проверенный rollback. При большом числе пользователей, нескольких каталогах, устаревших протоколах или неполной инвентаризации массовое переключение создает риск одновременной потери доступа к бизнес-системам.

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

Что означает централизация идентификации в 2026 году

Централизация идентификации объединяет управление учетными записями, аутентификацией, назначениями и аудитом в согласованную модель. Перенос пользователей в новый каталог решает лишь часть задачи. Полный проект связывает HRIS или другой авторитетный источник с жизненным циклом идентичности, центральным IdP, MFA, SSO, IGA, политиками RBAC и ABAC, журналированием и SIEM.

IdP проверяет личность пользователя и выпускает утверждения для приложения. IAM задает правила доступа и соединяет каталоги, приложения и факторы аутентификации. IGA управляет запросами на доступ, согласованиями, сертификацией прав и контролем жизненного цикла. Владелец приложения принимает решение по прикладной авторизации, если политика не вынесена в отдельный слой.

Для сотрудников, подрядчиков и администраторов используют workforce IAM. Клиентские учетные записи требуют отдельной модели CIAM с регистрацией, согласием на обработку данных, восстановлением доступа и высокой нагрузкой. Объединять эти контуры в один план миграции рискованно: у них разные владельцы, SLA, требования к приватности и сценарии отказа.

Какие функции должны стать централизованными

• Аутентификация, SSO и федерация приложений.
• MFA, passwordless-вход, регистрация и отзыв факторов.
• Управление сессиями, временем жизни токенов и single logout.
• Provisioning и deprovisioning учетных записей, групп и сервисных идентичностей.
• Группы, роли RBAC, атрибутные правила ABAC и политики условного доступа.
• Запросы на доступ, согласование, регулярная сертификация прав и контроль привилегий.
• Единый аудит входов, изменений, назначений, ошибок коннекторов и действий администраторов.
• Сигналы риска: необычное местоположение, запрещенная сеть, подозрительное устройство, многократные ошибки MFA.

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

Что не следует переносить без пересмотра

Перед загрузкой данных разделите объекты на переносимые, требующие очистки и подлежащие выводу. Механическое копирование старых правил сохраняет накопленные ошибки и переносит избыточные права в новую платформу.

Инвентаризация перед переходом на централизованное управление доступом

Discovery задает реальный объем миграции, допустимый простой и порядок волн. До пилота нужно получить карту пользователей, сервисных идентичностей, каталогов, приложений, API, групп, ролей, сертификатов и секретов. Общую методику оценки зависимостей можно сопоставить с практическим руководством по миграции IT-инфраструктуры и приложений.

Как построить каталог приложений и зависимостей

Один объект реестра должен описывать конкретное приложение и его окружение. Production, staging и development записывайте отдельными строками, если у них разные client ID, сертификаты, claims или владельцы.

Источники данных нужно объединить, а не выбирать один по умолчанию. Проверьте конфигурации старого IdP, журналы входа за 60-90 дней, CMDB, reverse proxy, DNS, Active Directory, LDAP, сетевые правила и ответы владельцев приложений. Журналы покажут фактическое использование, а опросы помогут найти тестовые и сезонные сценарии, которые не попали в обычный поток.

Как выявить скрытые зависимости

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

• Проверьте cron-задачи, systemd timers, Jenkins jobs и пайплайны, где записаны старый URL, client ID или DN группы.
• Найдите LDAP bind, RADIUS, VPN, SMTP relay, файловые ресурсы и базы данных, использующие локальные учетные записи.
• Сопоставьте API-токены, сертификаты подписи, секреты CI/CD и их владельцев.
• Разверните вложенные группы и проверьте, не получают ли сервисы права через косвенное членство.
• Проверьте локальных администраторов на серверах, сетевых устройствах, NAS и системах резервного копирования.
• Сопоставьте записи DNS, reverse proxy и балансировщиков со старыми endpoint федерации.
• Зафиксируйте различия между тестовым и рабочим окружением, включая разные claims и redirect URI.

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

Как определить источник истины для атрибутов

Конфликт возникает, когда HRIS меняет подразделение, каталог меняет статус, а приложение продолжает хранить старое значение. Составьте матрицу атрибутов до настройки синхронизации и назначьте единственного владельца каждого поля.

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

Big Bang или поэтапная миграция IAM: критерии выбора

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

Практическое правило: 0-2 признака риска допускают оценку Big Bang, 3-5 требуют пилота с ограниченными волнами, 6 и более делают поэтапную миграцию базовым сценарием. При наличии хотя бы одного риска потери административного доступа решение нужно принимать в пользу поэтапного маршрута.

Когда допустима миграция Big Bang

Одноразовое переключение допустимо при одновременном выполнении нескольких условий:

• Каталог один, записи пользователей уникальны, а все приложения используют типовой протокол.
• Активных пользователей немного, а владельцы подтвердили полный реестр и тестовые учетные записи.
• Изменения в конфигурации заморожены минимум на одно окно релиза.
• Проведена репетиция с теми же claims, сертификатами, правилами маршрутизации и скриптами.
• Старый IdP можно вернуть за заранее измеренное время, а данные новой системы синхронизированы.
• На период запуска выделены специалисты IAM, сети, приложений, безопасности и service desk.

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

Когда обязательна поэтапная миграция

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

• Пилот показывает поведение новой связки на ограниченной аудитории.
• Канареечный запуск позволяет измерить ошибки входа, задержку MFA и обращения до расширения охвата.
• Каждая волна имеет собственного владельца, критерии go/no-go и срок стабилизации.
• Инцидент ограничивается приложениями и пользователями одной волны.
• Старый IdP сохраняет переходную функцию, пока не закрыты все зависимости.

Подробный подход к выбору стратегии для плановых и вынужденных изменений описан в руководстве по миграции IT-систем и плану отката.

Как рассчитать миграционные волны

Сначала перенесите внутренние приложения с низкой критичностью и небольшой аудиторией. Затем подключайте типовые SaaS-интеграции, после них - критичные системы с отдельными контрольными окнами. Нестандартный legacy-контур оставляйте для последней стадии, когда целевая архитектура и поддержка уже проверены.

1. Лабораторная волна: 2-3 тестовых приложения, 10-20 сотрудников, включая администраторов.
2. Пилот: 3-5 приложений и 5-10 процентов пользователей одной функции или подразделения.
3. Стандартные системы: типовые интеграции с понятными claims и автоматическим SCIM.
4. Критичные приложения: одна система на волну либо группа с общей проверенной зависимостью.
5. Legacy: приложения с LDAP bind, локальными ролями и нестандартными библиотеками.

Размер волны ограничьте двумя параметрами: числом интеграций и числом пользователей. Стартовый предел может составлять 10 приложений и 15 процентов аудитории. Следующую волну открывайте после 24-72 часов наблюдения для низкорисковых систем и после согласованного периода для критичных процессов. Приложения с общей непроверенной зависимостью не объединяйте.

Целевая архитектура единой IAM-платформы

Целевая модель должна описывать не название продукта, а границы ответственности. Рабочая цепочка выглядит так: HRIS или иной авторитетный источник формирует сведения о сотруднике, IGA управляет назначениями, каталог хранит идентичность, IdP проводит аутентификацию, MFA подтверждает фактор, federation gateway передает утверждения приложению, а SIEM сохраняет события.

RBAC подходит для устойчивых должностных ролей, например бухгалтер или оператор смены. ABAC нужен для правил с атрибутами пользователя, ресурса, сети, времени и уровня риска. Для критичных прав используйте сочетание роли, контекста входа и временного согласования.

Параллельная работа старого и нового IdP

Переходное состояние проектируют заранее. Новый IdP может федеративно принимать аутентификацию старого IdP, пока старый каталог продолжает отдавать атрибуты. Другой вариант, routing по домену или группе: часть пользователей проходит новый маршрут, остальные сохраняют прежний.

• Федерация: новый IdP доверяет старому провайдеру как upstream на ограниченный срок.
• Routing: домен, группа или приложение выбирают нужный маршрут входа.
• Теневой режим: новая политика рассчитывается и журналируется без влияния на доступ.
• Синхронизация: изменения пользователей и групп передаются по согласованному направлению.
• Compatibility layer: адаптер сохраняет старый формат claims или endpoint для legacy-приложения.

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

Для временного тестового контура, где нет рабочих учетных данных, можно использовать отдельные облачные ресурсы, например VDS и другие инфраструктурные сервисы Timeweb Cloud. Production-идентичности и секреты не размещайте в таком стенде без утвержденной модели защиты.

SAML, OpenID Connect и SCIM в переходной архитектуре

SAML и OpenID Connect отвечают за федерацию и SSO. SCIM отвечает за жизненный цикл записей. Подключение SSO без deprovisioning оставляет бывшим сотрудникам активные учетные записи, а SCIM без проверки claims не гарантирует корректный доступ внутри приложения.

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

Аварийный доступ и независимость администраторов

Центральная IAM-платформа не должна быть единственным способом попасть в систему управления. Подготовьте независимый путь восстановления и регулярно проверяйте его без нарушения аудита.

• Создайте две или более break-glass учетные записи с минимальным набором аварийных прав.
• Храните секреты в отдельном защищенном хранилище, доступ к которому не зависит от рабочего IdP.
• Применяйте аппаратную MFA, отдельные телефоны или физические ключи с контролем выдачи.
• Ограничьте локальные администраторские записи сроком, сетью и журналированием.
• Назначьте двух независимых ответственных за проверку доступа и ротацию секретов.
• Проводите тест аварийного входа перед каждой крупной волной и после изменений политики.

Автоматизация переноса пользователей, групп и назначений

Перенос строится как конвейер extract - transform - validate - load - reconcile. Ручной импорт допустим для небольшой лабораторной группы, но не подходит для массовой миграции с требованиями к повторяемости. Практика построения идемпотентных сценариев и постмиграционной проверки разобрана в руководстве по автоматизированному миграционному пайплайну.

1. Extract: выгрузите пользователей, группы, роли, статусы, сервисные записи и связи через API, Microsoft Graph, LDAP export или CSV.
2. Transform: нормализуйте регистр, имена подразделений, форматы email, UPN и правила групп.
3. Validate: выполните проверки уникальности, обязательных полей, владельцев, допустимых ролей и зависимостей.
4. Load: загрузите записи через API целевой платформы или SCIM. Terraform применяйте для декларативной настройки политик, групп и интеграций, а не как замену системе жизненного цикла пользователей.
5. Reconcile: сравните источник и приемник, сохраните отчет об ошибках и разрешите исключения до подключения пользователей.

Каждая операция должна поддерживать dry run, журналировать входные данные и давать одинаковый результат при повторном запуске. Для сопоставления используйте immutable ID, а email и UPN оставляйте вспомогательными ключами: они могут измениться при реорганизации или смене домена.

Подготовка и нормализация данных

Неактивные и спорные записи помещайте в отдельный quarantine-набор. Сначала импортируйте активных пользователей без привилегий, затем базовые группы, после сверки - роли и административные назначения.

Перенос паролей, факторов MFA и активных сессий

Универсальный перенос хэшей паролей обещать нельзя. Форматы хэшей, соль, параметры растяжения и политика безопасности различаются. Для большинства переходов безопаснее выбрать один из трех сценариев: федерация со старым IdP, миграция учетной записи после успешного входа или массовый сброс паролей.

• Федерация: новый IdP временно отправляет пользователя на старый IdP и создает целевую запись после успешной проверки.
• JIT-миграция: запись создается во время первого входа, после чего пользователь получает предложение задать новый пароль.
• Массовый сброс: всем пользователям отправляется контролируемое уведомление, а новый пароль задается через проверенный канал.
• Passwordless enrollment: пользователи регистрируют аппаратный ключ или другой фактор в отдельном окне подготовки.

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

Сверка после каждой загрузки

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

Тестирование IAM-интеграций до переключения

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

Матрица позитивных и негативных сценариев

Тесты жизненного цикла Joiner, Mover, Leaver

• Joiner: создать сотрудника в HRIS, дождаться записи в каталоге, проверить базовую роль, MFA enrollment и доступ к первому приложению.
• Mover: изменить подразделение и руководителя, убедиться в отзыве старых прав, назначении новых согласованных ролей и обновлении маршрута согласования.
• Leaver: установить статус завершения работы, проверить блокировку, отзыв токенов, удаление активных сессий, закрытие VPN и deprovisioning приложений.
• Сервисная идентичность: проверить ротацию секрета, владельца, срок действия и поведение при недоступности старого коннектора.

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

Критерии go/no-go и репетиция отката

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

Пошаговый план IAM-миграции с минимальным простоем

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

До окна изменений

• Завершите начальную синхронизацию и сверку активных, заблокированных и привилегированных учетных записей.
• Сделайте резервные копии конфигураций IdP, metadata, политик, коннекторов, сертификатов и ключей. Проверьте восстановление выборочной копии.
• Проверьте сроки сертификатов, redirect URI, claims, scopes, сетевые правила и доступность DNS.
• Заморозьте изменения в группах, ролях, интеграциях и кадровых справочниках на время, указанное в runbook.
• Откройте единый канал координации, назначьте дежурства IAM, приложений, сети, безопасности и service desk.
• Подтвердите синтетические учетные записи, тестовые транзакции и независимый break-glass-вход.
• Разошлите пользователям уведомление, а владельцам приложений - точное окно, список проверок и критерии rollback.

Во время переключения

1. Зафиксируйте исходные значения метрик: входы, latency, ошибки MFA, provisioning, обращения и использование старого IdP.
2. Включите новую маршрутизацию только для контрольной группы.
3. Проверьте синтетические входы, logout, MFA, назначение роли и ключевую бизнес-транзакцию.
4. Сравните ошибки с критериями go/no-go и получите подтверждение владельца приложения.
5. Расширяйте охват ступенчато, сохраняя паузу для анализа метрик после каждого шага.
6. При превышении порога остановите расширение, соберите диагностические события и активируйте заранее назначенного владельца решения.

На экране координации должны быть видны ошибки аутентификации, задержка ответа IdP, состояние SCIM-коннекторов, ошибки provisioning, активные сессии и обращения пользователей. Общий процент успешных входов скрывает отказ отдельного критичного приложения, поэтому метрики разбивайте по системе, группе и географии.

После переключения

• Сверьте данные, группы, роли, привилегии, статусы и ошибки API с отчетом до запуска.
• Попросите владельцев приложений подтвердить ключевые операции по бизнес-процессу.
• Проверьте административный доступ и доступность break-glass-учетных записей.
• Разберите исключения, назначьте срок исправления и владельца каждого остаточного дефекта.
• Сохраните журналы IdP, IGA, коннекторов, приложений и service desk в едином наборе аудита.
• Оставьте старый маршрут доступным для отката до окончания периода стабилизации.

План коммуникации с пользователями и службой поддержки

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

Календарь уведомлений

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

Подготовка service desk и эскалации

• Создайте базу известных ошибок по кодам SAML, OIDC, SCIM, MFA и истекшим сессиям.
• Подготовьте скрипт диагностики: пользователь, приложение, время ошибки, группа, браузер, сеть, request ID и снимок события без секретов.
• Определите признаки массового инцидента: резкий рост ошибок входа, отказ нескольких приложений, недоступность MFA или SCIM.
• Назначьте уровни эскалации: service desk, IAM, владелец приложения, сеть, безопасность и руководитель изменения.
• Введите обязательное подтверждение личности перед сбросом фактора или изменением доступа.
• Создайте отдельный канал для владельцев критичных приложений и запретите неучтенные ручные изменения в каталогах.

Руководителям нужна информация о влиянии на команды и времени окна. Администраторам нужны claims, endpoint и rollback. Владельцам приложений нужны критерии приемки. Пользователям достаточно даты, действия и канала помощи.

Rollback: когда и как возвращаться на старую систему

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

Триггеры автоматического и управленческого отката

• Доля ошибок входа превысила утвержденный порог, например 0,5 процента на контрольной группе.
• Критичное приложение недоступно более согласованного времени или не выполняет ключевую транзакцию.
• Администраторы потеряли рабочий и аварийный доступ к управлению.
• Массовая ошибка MFA блокирует пользователей и не устраняется в пределах окна.
• Нарушилась целостность групп, ролей или привилегированных назначений.
• Deprovisioning не выполняется в пределах SLA, а старые токены остаются активными.
• Обнаружена неподтвержденная запись, которая получила административное право.

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

Контроль данных при обратном переключении

Разделите возврат приложения, пользовательской волны и всей платформы. Откат одного приложения не должен возвращать уже исправленные атрибуты во все системы.

1. Заморозьте конфликтующие задания синхронизации и ручные изменения.
2. Зафиксируйте журнал изменений новой системы с момента начала волны.
3. Определите, какие изменения успели попасть в HRIS, старый каталог, новый IdP и приложение.
4. Восстановите старую маршрутизацию для выбранного приложения или группы.
5. Сверьте учетные записи, группы, роли, токены и статусы по immutable ID.
6. Повторно включите синхронизацию в одном направлении и обработайте исключения.
7. Проведите синтетический вход и бизнес-транзакцию перед снятием ограничений.

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

Метрики стабилизации и вывод старой IAM-системы

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

KPI переходного периода

Базовые значения снимите за 30 дней до первой волны. Цели утверждают владельцы процессов: для VPN, платежей и производственных систем допустимые значения могут отличаться от внутренних порталов.

Чек-лист безопасного decommission

• Все приложения, каталоги, сервисные записи, API, сертификаты и коннекторы имеют статус migrated, retired или accepted exception.
• Зафиксировано отсутствие трафика к старому IdP, LDAP bind, старых endpoint и локальных обходных маршрутов.
• Владельцы приложений подтвердили вход, роли, deprovisioning и аудит через новый контур.
• Журналы старой системы, конфигурации, metadata и отчеты миграции архивированы с контролем доступа и сроком хранения.
• Старые сертификаты, токены, ключи и секреты отозваны или заменены.
• Коннекторы, DNS-записи, сетевые правила, firewall-порты и задания автоматизации отключены.
• Резервные копии старой системы получили срок удаления и ответственного за его соблюдение.
• Документация, схема архитектуры, runbook и контакты поддержки обновлены.

Для критичного контура задайте период наблюдения 14-30 суток после последней волны. Отключайте legacy-компоненты только после закрытия остаточных зависимостей и утверждения отчета безопасности.

Типичные ошибки при централизации идентификации

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

Почему проект застревает на последних приложениях

Итоговый чек-лист готовности

• Реестр пользователей, сервисных идентичностей, приложений, каталогов, групп, ролей, сертификатов и секретов заполнен.
• Для каждого объекта назначены технический и бизнес-владелец, критичность, SLA и путь rollback.
• Целевая архитектура описывает HRIS, IGA, каталог, IdP, MFA, SSO, RBAC, ABAC, коннекторы и SIEM.
• Для каждого атрибута выбран один источник истины, направление синхронизации и правило конфликта.
• Подготовлены SAML, OpenID Connect и SCIM-интеграции с проверенными metadata, claims, scopes и схемами.
• Данные прошли нормализацию, dry run, импорт и сверку по immutable ID.
• Стратегия Big Bang или поэтапных волн подтверждена числовыми критериями и ограничениями риска.
• Пилот, UAT и negative testing покрывают вход, выход, MFA, авторизацию, Joiner, Mover, Leaver и сбои коннекторов.
• Критерии go/no-go, метрики и пороги автоматического отката записаны в runbook.
• Break-glass-доступ проверен, секреты защищены, а действия администраторов журналируются.
• Пользователи, руководители, владельцы приложений и service desk получили сообщения своего уровня детализации.
• Период стабилизации, KPI и условия decommission согласованы до первой рабочей волны.

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