Смена MSP-провайдера: как найти и вычистить старые доступы

Смена MSP-провайдера или ИТ-аутсорсера часто выглядит как обычная административная процедура: старый подрядчик ушел, новый пришел, пароли передали, поддержку продолжили.

Но для инфраструктуры это не просто смена исполнителя. Это момент, когда нужно заново проверить цепочку доверия.

Если старый MSP несколько лет обслуживал рабочие станции, серверы, почту, VPN, резервные копии и компьютеры руководителей, у него могли остаться каналы доступа. Иногда это забытый RMM-агент. Иногда доменная учетка бывшего инженера. Иногда AnyDesk на ПК директора. Иногда OAuth-приложение в Microsoft 365, которое пережило уже три смены паролей.

Главный вопрос нового MSP звучит так:

можем ли мы доказать, что у старого подрядчика больше нет доступа?

Короткий ответ

При смене MSP нужно проводить не только инвентаризацию техники, но и аудит доступа: кто, откуда, через какие инструменты и с какими правами может попасть в инфраструктуру клиента.

Проверять нужно не только сетевое оборудование. В зоне риска рабочие станции руководителей, Active Directory, Microsoft 365 / Entra ID, VPN, RDP, RMM, резервные копии, DNS, регистраторы доменов, EDR, антивирусы и сервисные учетные записи.

Почему это важно

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

Если старый доступ не закрыт, компания живет с чужим ключом от серверной. Причем этот ключ может быть не у “старого MSP” как компании, а у конкретного инженера, который давно уволился.

Отдельная проблема: легитимные инструменты удаленного доступа все чаще используются в атаках. CISA и NSA отдельно выпускали рекомендации по защите remote access software и RMM, потому что злоумышленникам удобно прятаться за привычными админскими инструментами.

Смена MSP - это security handover

Правильная смена подрядчика должна выглядеть как контролируемая передача доверия.

Не “нам передали пароли”.
Не “старый MSP сказал, что все удалил”.
Не “мы поставили свой агент, значит теперь все наше”.

Нужен процесс:

Зафиксировать текущие точки доступа.
Найти старые и неизвестные каналы удаленного управления.
Отозвать лишние права.
Проверить критичные устройства.
Включить новый порядок администрирования.
Передать клиенту отчет: что найдено, что отключено, что осталось риском.

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

Сначала - письменный scope

Перед технической частью нужно получить письменное разрешение клиента.

В scope должны быть указаны:

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

Особенно аккуратно нужно работать с компьютерами руководителей. Цель аудита - не читать документы и переписки, а найти технические каналы доступа: удаленные агенты, локальных админов, службы, автозагрузку, scheduled tasks, VPN/RDP-профили и похожие вещи.

Карта доступа: что проверять

Первый шаг нового MSP - не установка своего инструмента, а карта доступа.

Зона	Что искать
ПК руководителей	AnyDesk, TeamViewer, RustDesk, локальные админы, автозагрузка, scheduled tasks
Active Directory	Domain Admins, старые учетки, GPO, logon scripts, service accounts
Microsoft 365 / Entra ID	Global Admin, guest users, OAuth apps, app registrations, mailbox forwarding
RMM	старые агенты, unattended access, remote shell, запуск скриптов
VPN / RDP	старые профили, общие учетки, доступ без MFA
Backup	админы, ключи шифрования, cloud repositories, restore-доступ
DNS / домены	регистраторы, зоны DNS, API-токены, внешние админы
EDR / антивирус	кто управляет консолью, кто может отключать защиту

Эта таблица не заменяет полноценный аудит, но дает правильную стартовую карту.

День 0: забрать контроль, но не сломать

В первый день легко сделать ошибку: начать удалять все неизвестное.

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

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

Принцип простой: сначала evidence, потом action.

ПК руководителей: отдельная зона риска

Рабочие станции руководителей нужно проверять отдельно. Обычно там больше полномочий, больше чувствительных данных и больше “временных” доступов, которые никто не пересматривал.

Проверить стоит:

локальных администраторов;
программы удаленного доступа;
службы Windows;
автозагрузку;
планировщик заданий;
браузерные расширения;
сохраненные RDP/VPN-профили;
облачные синхронизации;
состояние антивируса или EDR;
последние интерактивные входы;
шифрование диска;
неизвестные локальные учетные записи.

Хороший вывод в отчете выглядит так:

На рабочей станции руководителя найден AnyDesk с включенным unattended access. Владелец доступа не подтвержден. Доступ отключен после согласования, агент удален, устройство переведено под утвержденный RMM нового MSP.

Active Directory: где часто живет старый доступ

В AD нужно смотреть не только Domain Admins.

Минимальный список:

Domain Admins;
Enterprise Admins;
Administrators;
Account Operators;
Backup Operators;
делегированные права на OU;
GPO с локальными администраторами;
logon scripts;
startup/shutdown scripts;
сервисные учетные записи;
пользователи без истечения пароля;
stale accounts;
общие учетки вроде support, admin, it.

Особенно опасны shared admin accounts. Если под support работали пять инженеров старого подрядчика, невозможно понять, кто именно что делал.

После смены MSP лучше перейти на именные учетные записи и отдельные admin-аккаунты.

Microsoft 365 и Entra ID: невидимые двери

В облаке старый доступ может остаться даже после смены паролей.

Проверять нужно:

Global Administrator;
Privileged Role Administrator;
Exchange Administrator;
Security Administrator;
guest users;
enterprise applications;
app registrations;
OAuth permissions;
mailbox delegation;
inbox forwarding;
transport rules;
Conditional Access exclusions;
break-glass accounts.

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

Для бизнеса это выглядит как “мы всех отключили”.
Для инфраструктуры - нет, не всех.

RMM: главный кандидат на проверку

RMM - нормальный инструмент для MSP. Но при смене подрядчика он становится одной из главных точек риска.

Нужно понять:

какие RMM-агенты стоят на устройствах;
кто владеет панелью управления;
включен ли unattended access;
есть ли MFA у операторов;
можно ли запускать скрипты;
можно ли открыть remote shell;
пишутся ли сессии;
кто имеет доступ к группам устройств;
удалены ли агенты старого MSP.

Плохая, но частая ситуация: на одном ПК стоят новый RMM, старый RMM, AnyDesk “для срочного доступа” и TeamViewer “для бухгалтерии”.

Это не отказоустойчивость. Это неконтролируемая поверхность атаки.

Резервные копии: доступ страшнее, чем кажется

Backup часто забывают при смене MSP. Зря.

Если у старого подрядчика остался доступ к резервным копиям, он может видеть данные, менять задания, удалять restore points или восстановить данные в другую среду.

Проверить нужно:

администраторов backup-системы;
ключи шифрования;
cloud repositories;
storage credentials;
расписания заданий;
уведомления;
успешность restore test;
кто получает отчеты;
кто может удалить точки восстановления.

После смены MSP важно не просто “backup работает”. Важно, чтобы backup находился под контролем клиента и нового ответственного подрядчика.

Что отключать сразу, а что расследовать

Не все находки одинаковые.

Риск	Пример	Действие
Критичный	внешний Global Admin старого MSP	отключить после фиксации и согласования
Критичный	RMM без понятного владельца	изолировать или отключить доступ
Высокий	VPN без MFA	закрыть или перевести на MFA
Высокий	общая доменная учетка `support`	заменить именными учетками
Средний	stale users без привилегий	отключить по плану
Средний	старый агент мониторинга	проверить назначение, затем удалить
Низкий	устаревшая документация	обновить

Главная ошибка - удалить все подряд.
Вторая ошибка - ничего не трогать, потому что “вдруг сломается”.

Рабочая схема: evidence -> owner -> impact -> action -> verification.

Что должно быть в отчете

Клиенту нужен не текст “все проверили”, а понятный отчет.

Минимальный состав:

какие системы проверены;
какие внешние доступы найдены;
какие доступы отключены;
какие оставлены временно и почему;
где включена MFA;
какие RMM-агенты обнаружены;
какие ПК руководителей проверены;
какие риски требуют решения бизнеса;
что сделать за 7 дней;
что сделать за 30 дней;
что сделать за 90 дней.

Плохой отчет: “Проверили, все нормально”.

Хороший отчет: “Найдены старые точки доступа, часть отключена, часть оставлена временно до миграции backup, по двум пунктам нужно решение владельца бизнеса”.

Новый порядок доступа

После очистки старого наследия важно не построить такой же хаос заново.

Минимальные правила:

никаких общих админских учеток;
MFA для всех админских и внешних доступов;
отдельные именные admin accounts;
least privilege вместо “всем Domain Admin”;
один утвержденный RMM;
журналирование remote sessions;
VPN только с MFA;
доступ подрядчиков через PAM или jump host;
регулярный access review;
инвентаризация сервисных учеток;
LAPS для локальных админов;
документированный offboarding подрядчика.

Самый важный артефакт - реестр доступов. Не в голове у инженера, не в переписке, не в старом Excel, а в живой системе или документе: кто имеет доступ, зачем, кто владелец и когда доступ пересматривается.

Частые вопросы

Старый MSP сказал, что все удалил. Этого достаточно?

Нет. Это нормальное заявление, но не доказательство.

Новый MSP должен проверить фактическое состояние: учетные записи, RMM, VPN, облачные роли, OAuth-приложения, backup, локальных админов.

Можно ли проверять ПК руководителя?

Можно только с разрешения клиента и в заранее согласованных границах.

Проверка должна касаться технических каналов доступа: удаленные инструменты, локальные админы, службы, автозагрузка, задачи, EDR, VPN/RDP. Содержимое личных файлов и переписок не является целью такого аудита.

Что если мы удалим нужный агент?

Поэтому сначала фиксируем и определяем владельца. Если агент неизвестен, но похож на мониторинг, backup или EDR-компонент, его нужно не удалять вслепую, а проверить и согласовать действие.

Нужно ли менять все пароли?

Не всегда достаточно и не всегда правильно. Кроме паролей есть токены, OAuth-приложения, SSH-ключи, API-ключи, RMM-сессии и delegated permissions.

Кто должен владеть мастер-доступом?

Клиент. MSP может администрировать, но бизнес должен сохранять контроль над доменами, облаками, backup, DNS, регистраторами и критичными break-glass аккаунтами.

Полезные материалы

Итог

Смена MSP-провайдера - редкий момент, когда компания может честно пересобрать модель доступа.

Можно просто заменить одного подрядчика другим и унаследовать старые риски. А можно провести нормальный handover: найти старые входы, закрыть лишние права, проверить ПК руководителей, убрать чужие RMM-агенты, навести порядок в AD, Entra, VPN и backup.

Главный результат такой работы - не новый договор на поддержку.

Главный результат - инфраструктура, где понятно:

кто имеет доступ;
зачем он нужен;
как он контролируется;
где он логируется;
как он будет отозван.

И это хороший момент для нового MSP показать реальную ценность: не просто “мы теперь обслуживаем”, а “мы вернули клиенту контроль над его инфраструктурой”.