Применение средств удаленного доступа выходит за рамки привычных задач по поддержке дистанционной работы сотрудников и централизованному администрированию устройств компании. Раньше их использовали только для поддержки пользователей и удаленного администрирования. Сегодня они входят в состав защищенной ИТ-инфраструктуры организации, поэтому только удобства, производительности и цены для выбора решения уже недостаточно. Для ГИС, объектов КИИ и информационных систем персональных данных (ИСПДн) действует отдельный набор правил: защита канала передачи данных, аутентификация, аудит и разграничение прав.

Разберем, почему выбор подобных решений теперь утверждает служба безопасности, а не только ИТ-отдел, какие критерии и нюансы компаниям необходимо учитывать на всех этапах проекта внедрения и как будут меняться регуляторные требования к этому классу продуктов.

Удаленный доступ — один из базовых элементов современной ИТ-инфраструктуры. Он используется в самых разных сценариях: от поддержки одного сотрудника до управления тысячами устройств в распределенных сетях. Такие решения востребованы в корпоративных системах и географически распределенных компаниях, а также применяются в АСУ ТП, ГИС, ИСПДн и объектах критической информационной инфраструктуры.

Среди множества сценариев применения удаленного доступа в контексте защищенной инфраструктуры особое значение имеют три направления:

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

В 2022 году поиск зрелого отечественного решения стал вынужденным шагом: с российского рынка ушли западные вендоры, среди них — TeamViewer и Dameware. Сегодня выбор системы удаленного доступа осложняется рисками безопасности: на фоне роста количества кибератак на российские компании требования регуляторов к защите информационных систем становятся жестче. Подключение через скомпрометированную учетную запись или один клик сотрудника по фишинговой ссылке могут открыть злоумышленнику путь в корпоративный контур. Поэтому в текущих реалиях отечественная система удаленного доступа должна закрывать не только задачи заказчика, но и нормы регуляторов, а также быть совместимой с другими элементами ИТ-инфраструктуры компании (операционной системой, СУБД и т.д.).

Раньше средство удаленного доступа выбирал ИТ-отдел, а служба ИБ лишь согласовывала внедрение продукта постфактум. Сегодня решение все чаще принимают специалисты по безопасности. На мой взгляд, есть ряд причин, повлекших подобные изменения:

Первая причина — регуляторная. Приказ ФСТЭК России от 11.04.2025 № 117 прямо описывает, как организовать удаленный доступ в государственных информационных системах. Служба ИБ несет ответственность за соответствие выбранного продукта этим нормам.

Вторая причина — характер угрозы. Использование удаленного доступа расширяет поверхность атаки. Злоумышленники активно используют такие каналы для проникновения в инфраструктуру: перехватывают трафик, крадут учетные данные через фишинг, ищут уязвимости в клиентских устройствах. Оценить эти риски может только специализированная экспертиза службы ИБ.

Третья причина — разные приоритеты у двух служб:

• ИТ-отдел ориентируется на функциональность, скорость подключения, стабильность, простоту масштабирования;
• служба ИБ оценивает минимизацию поверхности атаки, полноту аудита, предсказуемость поведения системы.

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

Четвертая причина — интеграция систем удаленного доступа с другими системами защиты, которая включает несколько важных аспектов:

• Для ГИС, объектов КИИ и систем персональных данных важен статус самого продукта — например, наличие сертификатов ФСТЭК или ФСБ. Этот статус проверяет служба безопасности. При выборе решения она оценивает его гораздо выше, чем удобство и функциональность. Регуляторы также требуют доказательств защиты: журналы событий, корреляцию в SIEM (Security Information and Event Management, система сбора и анализа событий безопасности со всей инфраструктуры), правильное хранение логов, защиту записей от подмены. Формат и сроки хранения журналов, а также способы защитить их от изменений, тоже определяет служба ИБ.
• Меняется и сама архитектура доступа: классический VPN уступает место ZTNA (Zero Trust Network Access, удаленный доступ с нулевым уровнем доверия). Пользователь получает доступ не ко всей сети, а к конкретному приложению или сервису. Здесь служба безопасности выступает архитектором политик и определяет критерии для каждой группы пользователей.

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

Приказ ФСТЭК России от 11.04.2025 № 117 описывает подробные меры защиты информации для ГИС и других информационных систем. Часть из них касается именно программного обеспечения, включая средства удаленного доступа:

• регистрация событий безопасности, их обработка и анализ (п.40, п.49);
• многофакторная аутентификация (п.48, п.63);
• защита каналов передачи данных при удаленном подключении, исключение несанкционированного входа (п.46);
• настройка прав и политик для учетных записей (п.48);
• контроль целостности компонентов ПО (п.10, п.39).

Отдельные требования для значимых объектов КИИ устанавливает Приказ ФСТЭК России от 25.12.2017 № 239 (ред. от 28.08.2024). В частности, документ требует использовать ПО в соответствии с эксплуатационной документацией (п. 30), обеспечивать гарантийную и техническую поддержку такого ПО (п.31), а для объектов 1 и 2 категорий — размещать серверную часть внутри страны.

В приказе № 117 и в остальных документах меры защиты классифицированы по группам: идентификация и аутентификация (ИАФ), управление доступом (УПД), регистрация событий безопасности (РСБ). Чтобы использовать средство удаленного доступа в составе ГИС, на объектах КИИ или в ИСПДн, производитель должен выполнить каждое из этих требований и подтвердить это на практике — доказать, что заявленные функции безопасности реально работают. Подтверждение проходит через сертификационные испытания, например в системе ФСТЭК России. Большинство приказов ФСТЭК (№ 117, № 21, № 31, № 239) и других нормативных актов — ФЗ-152, ФЗ-187, постановления правительства № 1119, № 447, № 478, ГОСТ Р 57580.1-2017 — сходятся в одном: продукт должен быть сертифицирован и включен в реестр отечественного ПО.

Сертификаты ФСТЭК на программное обеспечение выдаются по шести уровням доверия — с 1 (наивысшего) по 6. На практике это значит, что заказчику недостаточно просто спросить «есть ли у вас сертификат ФСТЭК?». Нужно проверить: какой именно уровень доверия указан в сертификате, для какой редакции продукта он действителен и не истек ли срок. Сертификат привязан к конкретной версии, поэтому при обновлении продукта его необходимо переоформлять, и это тоже критерий надежности вендора.

Российский рынок средств удаленного доступа после ухода зарубежных вендоров в 2022–2023 годах прошел этап хаотичного замещения и сейчас структурируется. Представленные на нем решения можно условно разделить на четыре группы:

• Коммерческие отечественные решения с сертификатом ФСТЭК России. Полноценные системы удаленного мониторинга и управления с серверной и облачной версиями, включенные в реестр отечественного ПО, например, «Ассистент» (компания «Сафиб»), имеющий сертификат ФСТЭК России 4 уровня доверия.
• Коммерческие отечественные решения без сертификата ФСТЭК России. Они закрывают задачи удаленного доступа, технической поддержки и администрирования, но не прошли сертификационные испытания, например, RMS, LiteManager.
• Open Source решения. Продукты с открытым исходным кодом, такие как RustDesk, дают больше возможностей для самостоятельной настройки и доработки. Для защищенного контура практически не применимы, если не вкладываться в самостоятельную сертификацию — это может быть дороже, чем купить готовый продукт.
• Встроенные средства ОС и сетевые протоколы. RDP, SSH и VNC не требуют закупки отдельного продукта, однако из-за своей специфики допустимы скорее для единичных подключений в небольшом офисе; для масштабной инфраструктуры требуют дополнительных средств контроля и аудита. Чтобы проект внедрения отечественной системы удаленного доступа прошел гладко и безболезненно, детально разберем нюансы, которые необходимо учитывать на всех этапах.

На этапе выбора решения стоит обращать внимание на следующие критерии:

• Полнота логирования и корреляция. Для расследования инцидентов журнал подключений не должен ограничиваться записью факта сессии. Он должен с достаточной детализацией фиксировать параметры подключения и работы в системе — например, IP-адрес, время, использованный протокол, список измененных файлов и др. Отдельного внимания требует интеграция решения с SIEM-системами для ускорения расследований инцидентов.
• Управление сессией, а не только моментом подключения. В требования к решению обычно включают настройку таймаутов, принудительное завершение сессии и оперативный отзыв прав при увольнении сотрудника или смене должности.
• Управление секретами. Помимо паролей, в защищенном контуре используют SSH-ключи, API-токены и сертификаты. Их безопасное хранение и изоляция от пользователя помогают закрыть требования к защите привилегированного доступа.
• Встраиваемость в инфраструктуру. При выборе оценивают не только функции продукта, но и его совместимость с текущей сетью, средствами защиты, операционными системами, СУБД и другим внешним окружением продукта. Архитектура решения должна соответствовать реальному ландшафту инфраструктуры.
• Перспектива масштабирования. На этапе выбора полезно учитывать планы развития компании. Централизованное управление, интеграция со службами каталогов, аудит сессий и возможность расширить парк до сотен устройств позволяют не возвращаться к замене системы при росте нагрузки.
• Кроссплатформенность. В корпоративной среде обычно одновременно используются Windows, macOS, Linux, Android и iOS. Поэтому при выборе учитывают работу клиента на всех типах устройств. Решения вроде «Ассистента» или RustDesk поддерживают несколько платформ, тогда как базовый RDP в первую очередь ориентирован на Windows.
• Надежность вендора и возможность обучения. Помимо функциональности продукта, значение имеют репутация поставщика, SLA, регулярность обновлений, техническая поддержка на русском языке и возможность обучения специалистов.
• Работа при нестабильном соединении. Полезно оценивать не только типовой сценарий, но и поведение системы при слабом или прерывистом канале связи. Именно в таких условиях проявляется устойчивость удаленного доступа. 

Выбор решения для ГИС, ИСПДн и объектов КИИ отличается от коммерческого сектора не по степени строгости, а по самой логике: здесь без прямого соответствия закону обойтись нельзя. Ключевые требования включают использование российского ПО из реестра Минцифры РФ, размещение серверной части внутри страны и применение сертифицированных продуктов. Для КИИ правила особенно жесткие: действует принцип наименьших привилегий, а иногда удаленное подключение запрещено вообще. Правила разграничения должны четко описывать, кто и на каких условиях подключается к объекту, а все данные — видео, ввод с клавиатуры, передача файлов — идут только по защищенному каналу внутри организации. Продукт при этом должен соответствовать классу защищенности конкретной системы.

На этапе внедрения важны такие вопросы, как:

• Разграничение прав. Игнорирование принципа минимальных привилегий и выдача избыточного доступа открывают путь к утечкам данных и внутренним атакам.
• Поддержка вендора. Гарантийное и постгарантийное обслуживание, помощь при развертывании — без них настройка серверов, политик и связей с другими системами затягивается на месяцы.
• Эксплуатационная документация. В ней описаны порядок установки, настройки и безопасной эксплуатации средства удаленного доступа. Это особенно важно для функций безопасности: при некорректной настройке они могут работать не в полном объеме или не так, как предусмотрено производителем. Изучение документации помогает использовать возможности продукта и сохранить заявленный уровень защиты.

Чтобы избежать проблем в процессе эксплуатации решения, важно предусмотреть следующие нюансы:

• Несовместимость с legacy-системами. Вендор может заявлять поддержку интеграций, а на практике его API не покрывает нужные сценарии.
• Разнородность инфраструктуры. Готовые политики безопасности рассчитаны на усредненный случай, а инфраструктура заказчика почти всегда особая. Настройка профилей под разные группы людей требует времени и опыта.
• Слабая производительность. Медленная работа, зависания, разрывы сессий, сбои буфера обмена.
• Личные устройства сотрудников. Их сложно привести под корпоративные правила безопасности, а это создает постоянный риск, который трудно закрыть настройками одного продукта.

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

• Управление конечными устройствами (UEM) станет нормой. Продукт должен не просто открывать доступ, а централизованно управлять настройками устройств во всей сети.
• Инвентаризация ИТ-активов станет обязательной. Подробный учет оборудования и ПО с хорошей аналитикой нужен для безопасности и для планирования закупок.
• Работа в разнородной среде станет критичной способностью, а не просто удобной опцией.
• Контроль сместится с момента подключения на весь период работы в системе. Проверка должна идти постоянно, а не выборочно.

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