Критическая уязвимость в RMM-платформе способна превратить один скомпрометированный сервер в проблему для тысяч клиентских устройств. В сентябре 2026 года N-able выпустила экстренное исправление для CVE-2026-86218 в N-central: это pre-auth RCE максимальной критичности, а в интернете, по оценке публикации, было доступно около 1 500 серверов. Для российских интеграторов и управляемых сервис-провайдеров безопасность RMM — уже не фоновая настройка, а защита собственного «пульта управления» клиентской инфраструктурой.
Как сообщает BleepingComputer, Acronis предложила MSP проверять RMM-решения не по длине списка функций, а по восьми практическим сценариям: от обнаружения устройств и установки патчей до изоляции арендаторов и восстановления после инцидента. Материал спонсирован компанией, поэтому её продуктовые заявления стоит отделять от самого полезного тезиса: доступ без присмотра администратора, выданный RMM-агенту и технику, даёт атакующему масштаб, о котором на одном скомпрометированном ноутбуке можно только мечтать.
N-central — показательный случай не только из-за CVE-2026-86218. Это был уже четвёртый экстренный патч для продукта за пять недель. Для MSP такая серия означает необходимость быстро понять, где именно развёрнуты серверы управления, кто имеет к ним доступ, как обновление повлияет на клиентов и что произойдёт, если патч придётся откатывать. В классической схеме «обновим на выходных» здесь слишком много неизвестных: атакующий может начать эксплуатацию раньше, чем служба поддержки согласует окно работ.
История последних лет показывает, что риск не сводится к самой RMM-платформе. В июле 2025 года уязвимости ToolShell в локальных серверах Microsoft SharePoint — CVE-2025-53770 и CVE-2025-53771 — эксплуатировались до появления исправления; по данным публикации, были скомпрометированы как минимум 85 on-premises-серверов. Урок для провайдера очевиден: даже идеальная консоль управления не спасёт, если она не видит активы, не умеет расставлять приоритеты патчей и не показывает, какие обновления завершились ошибкой.
Что проверять до закупки, а не после инцидента
Первый тест выглядит почти скучно, но обычно вскрывает больше проблем, чем демонстрация вендора: подключить новое устройство в тестовой среде и проверить, когда оно появится в инвентаре, как будет классифицировано и получит ли нужную политику. Неучтённый сервер, сетевое устройство или забытая виртуальная машина быстро становятся исключением, на которое не распространяются обновления, мониторинг и правила доступа.
Второй блок — управление патчами. Важно не только наличие кнопки массовой установки, но и логика приоритизации, обработка неудачных развёртываний, план отката и прозрачный журнал действий. Полезно искусственно сорвать обновление на части машин: именно тогда становится видно, способен ли сервис отделить критичную брешь от очередного сбоя агента и не превратить массовую автоматизацию в массовый простой.
Третий блок — учётные записи техников. Минимальный набор для платформы с административным доступом: многофакторная аутентификация, ролевое разграничение прав и разделение обязанностей. На пилоте стоит создать роль с ограниченными правами и попытаться выполнить действия за пределами её зоны ответственности: запустить скрипт, выдать доступ, изменить политику, посмотреть данные другого клиента. Если хотя бы один из этих сценариев проходит, проблема не в настройке интерфейса, а в модели доверия.
Отдельного внимания заслуживает автоматизация. Скрипты экономят часы рутины, но при ошибке или захвате учётной записи так же быстро размножают последствия на сотни машин. Поэтому безопасность RMM включает двухэтапное согласование чувствительных сценариев, хранение учётных данных без открытого текста, аудит изменений и историю исполнения. Техник должен видеть, кто изменил сценарий, на каких устройствах он отработал и с каким результатом, а не искать ответ по разрозненным чатам и логам.
Единая платформа не отменяет проверок
Acronis продвигает свой RMM как часть общей платформы с резервным копированием, защитой конечных точек и удалённым доступом. У такого подхода есть понятное преимущество: при инциденте можно сохранить контекст клиента, устройства и события между обнаружением угрозы, изоляцией и восстановлением. Но «единая консоль» сама по себе не является контролем безопасности. Провайдеру нужно уточнять состав лицензии, доступность EDR, XDR, MDR и резервного копирования в конкретном пакете, а затем проверять сценарий целиком — включая возврат восстановленной системы в обновлённое и безопасное состояние.
Не менее критична изоляция арендаторов. В мультиклиентской среде политики, права, отчёты и административные действия одного заказчика не должны просачиваться к другому. Это следует проверять не только в интерфейсе, но и через экспорт отчётов, API, роли операторов и журнал аудита. Хороший audit trail нужен не для галочки в тендере: он помогает объяснить клиенту, кто и когда изменил настройку, а команде реагирования — восстановить картину атаки.
Регуляторы и исследователи давно предупреждают, что операторы вымогательских программ используют легитимные RMM-инструменты для проникновения в сети клиентов. Поэтому главная метрика при выборе платформы — не число интеграций в буклете, а ответ на неприятный вопрос: что увидит и сможет сделать команда, если скомпрометированы учётная запись техника, конечная точка или сам управляющий контур? Для MSP, которые продают клиентам устойчивость инфраструктуры, этот тест постепенно становится частью собственной репутации.