Удалённый доступ к 1С и серверу: VPN или RDP — как сделать безопасно

Есть вопрос, который новому клиенту я задаю почти первым: «Сотрудники к 1С из дома как подключаются?» И если в ответ звучит «да мы им просто порт прокинули», дальше можно не спрашивать — картина понятна, и я примерно знаю, что увижу в журналах.

Прокинутый наружу RDP — самая массовая дыра в малом бизнесе, и я не устаю удивляться, насколько она живучая. Не потому, что админы глупые, — таких я не встречал. Наоборот: потому что это работает с первой попытки, делается за пять минут и ничего не требует покупать. А последствия наступают не сразу. Связь между «мы открыли 3389 в марте» и «у нас всё зашифровано в октябре» видна только постфактум. Когда объяснять её уже некому.

Сразу оговорюсь и уберу ложную развилку, из-за которой половина споров на эту тему бессмысленна. RDP и VPN — не конкуренты. RDP это протокол работы с чужим рабочим столом, VPN это транспорт до сети, где стол стоит, и сравнивать их так же осмысленно, как дверь с дорогой, которая к ней ведёт. Правильный ответ на вопрос «что безопаснее» скучен: RDP внутри VPN.

Почему опубликованный наружу RDP — это критично

Открытый порт — не «дверь, про которую никто не знает», и вот это заблуждение я встречаю чаще прочих: диапазон IPv4 сканируется непрерывно, десятками ботнетов и исследовательских проектов, так что новый открытый 3389 находят в течение минут после публикации. Не дней. Минут.

Проверить легко, и я советую сделать это самому, а не верить мне на слово. Откройте порт, подождите полчаса и загляните в журнал безопасности. Там уже будут попытки входа под Administrator, admin, 1c, buh. Поток не прекращается никогда. Смена порта на нестандартный, кстати, помогает слабо: она отсекает самых ленивых, но массовый сканер проходит весь диапазон и опознаёт RDP по ответу, а не по номеру. Я пробовал, разницы не увидел.

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

[Изображение: схема «RDP наружу против RDP через VPN» — слева порт, торчащий в интернет, справа закрытый периметр с туннелем]

Что реально происходит с открытым портом

Три сценария, по нарастанию неприятности. Все три я видел живьём.

Перебор паролей. Самое скучное и самое частое. Боты подбирают учётки круглосуточно, медленно, с разных адресов, чтобы не упереться в блокировку, и рано или поздно попадают: пароль вида Firma2026 в компании есть почти всегда. У уволившегося сотрудника. У временной учётки подрядчика. У сервисного, которого заводили «на один раз». Побочный эффект, о котором мало думают: перебор грузит сервер и раздувает журналы до состояния, когда их никто не открывает.

Эксплойты. В протоколе периодически находят уязвимости, часть которых позволяет выполнить код без входа в систему. Патчи выходят. Но обновлять терминальный сервер страшно. Там 1С, там бухгалтерия, там «а вдруг отвалится», и я эту логику понимаю: сам откладывал обновление до выходных, которые не наступали. Сервер стоит непропатченным месяцами.

Шифровальщики. Финал. Скомпрометированный RDP — один из основных путей, которыми вымогатели заходят в сеть малого бизнеса, и схема отработана до автоматизма: получили доступ, осмотрелись, удалили бэкапы, отключили антивирус, дождались выходных и запустили шифрование. В понедельник утром выясняется, что 1С не открывается, а на столе лежит файл с инструкцией по оплате. Дальше идёт неделя, которую я никому не пожелаю. Помню такую в деталях.

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

[Изображение: обезличенный фрагмент журнала безопасности с потоком неудачных попыток входа]

Правильная схема: RDP внутри туннеля

Идея, на мой взгляд, простая до неприличия: наружу не торчит ничего, кроме точки входа VPN.

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

Что меняется технически, мне проще перечислить по пунктам. Порт 3389 закрыт снаружи наглухо, боты видят пустоту, сканировать нечего. Перебор невозможен: до формы входа нужно сначала попасть внутрь. Свежая уязвимость в RDP перестаёт быть поводом для ночной паники: снаружи не достучаться. И менее очевидное, про что вспоминают уже после инцидента: туннель даёт собственный журнал подключений — кто, когда, откуда, сколько времени. У голого RDP есть только системный журнал на самом сервере. Тот самый, который первым делом чистят после проникновения.

Это и есть безопасный удалённый доступ в нормальном виде — ничего экзотического, просто убранный внутрь протокол.

Удалённый доступ к 1С: где на самом деле узкое место

Теперь про производительность, потому что после разговоров о безопасности всегда идёт вопрос «а тормозить не будет». Не знаю ни одного проекта, где бы его не задали.

Будет — если сделать неправильно. Самая частая ошибка выглядит так: сотруднику дают VPN, он ставит толстый клиент 1С на домашний ноутбук и подключается к базе прямо через туннель, а если база файловая, боль наступает на второй день.

Почему это плохо, объясню подробно: тут кроется большая часть жалоб на «тормозящую удалёнку». Толстый клиент общается с базой очень болтливо — множество мелких обращений туда-обратно на каждое действие. Открыть журнал документов это не один запрос, а сотни. Каждый уходит в туннель и ждёт ответа. Сложите сотни ожиданий по сто миллисекунд, и получите те полминуты, за которые бухгалтер успевает сказать о вас всё. Полоса ни при чём, данных мало. Дело в раундтрипах.

Аналогия бытовая, зато я ни разу не видел, чтобы её не поняли: вы готовите по рецепту, но рецепт лежит в соседней комнате, и вы ходите за каждой строчкой отдельно. Расстояние до комнаты — три метра или тридцать — решает всё. Ширина двери не решает ничего.

Отсюда правильная схема: клиент 1С должен стоять рядом с базой. На терминальном сервере в той же локалке, где и сервер 1С. А к сотруднику идёт только картинка рабочего стола и его нажатия клавиш.

Последовательность такая: туннель до офисной сети, внутри туннеля RDP до терминального сервера, на нём 1С, которая общается с базой по гигабитной локалке. Болтливость остаётся в офисе, а через интернет летит сжатый видеопоток.

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

Тут, к слову, ломается интуиция почти у всех, и я сам когда-то ломался. Провайдер продаёт мегабиты, все меряют мегабиты, и когда 1С тормозит, первая мысль — «надо тариф пошире».

Не надо. Вернее, надо, но не это: для комфортной работы в 1С через удалённый рабочий стол критична задержка, а не полоса пропускания.

Порядок цифр по опыту настройки:

• До 40–50 мс — работа неотличима от локальной, поля заполняются мгновенно.
• 60–100 мс — заметно, но привыкаешь. Основная масса пользователей не жалуется.
• 120–150 мс — раздражает. Ввод отстаёт, прокрутка рваная, идут жалобы.
• Выше 200 мс — полноценно работать нельзя. Бухгалтер будет писать вам каждый день.

Полосы на сессию нужно немного — один-три мегабита, с пиками при перерисовке экрана, так что десять человек комфортно живут на канале, который вы даже не заметите. Сильнее мегабит бьют джиттер и потери: стабильные девяносто миллисекунд приятнее, чем прыгающие от тридцати до двухсот. Мобильный интернет, на моей памяти, справляется с этим плохо. Работает сотрудник с модема — готовьтесь к жалобам независимо от заявленной скорости. Отдельный случай, когда сессию режет сам оператор связи. Тогда дело не в канале, а в том, что туннель опознали, и помогает транспорт, который со стороны выглядит обычным HTTPS, вроде VLESS для бизнеса.

Вывод практический. Выбирайте точку входа близко к людям и к офису: лишние две тысячи километров — это лишние десятки миллисекунд в каждую сторону, и они складываются с каждым из тех сотен запросов, о которых я говорил выше. Если 1С тормозит, начинайте не с тарифа, а с ping и трассировки. Общие причины разобраны в материале про то, почему VPN тормозит.

Сравнение способов доступа

Четыре варианта, с которыми я реально сталкиваюсь.

Про веб-клиент 1С, к слову, отдельной строкой: его любят предлагать как универсальное решение. Он избавляет от толстого клиента на машине пользователя и удобен тем, кому нужны два-три документа в день. Но заменой рабочему месту бухгалтера он, по моим наблюдениям, не стал: часть форм ведёт себя иначе, часть обработок не работает. И публиковать его наружу без защиты — та же история, что с RDP, только по HTTP.

Облачная 1С снимает с вас железо и обновления, но база уезжает на чужую площадку. Для многих это нормально, и я тут предмета для спора не вижу. Для тех, у кого бухгалтерия принципиально не должна покидать контур, — нет.

Как выдать доступ сотруднику и не расширить дыру

Порядок действий, который я считаю минимально приличным.

1. Персональный доступ, а не общий конфиг. Один человек — одна учётка и один профиль. Общий конфиг «для бухгалтерии» означает, что при увольнении одного менять придётся всем, и поэтому не поменяют никому.
2. Второй фактор на входе в туннель. Пароль утекает, второй фактор — нет. Подробности по вариантам и внедрению — в разборе 2FA для VPN.
3. Маршрут только туда, куда нужно. Бухгалтеру — адрес терминального сервера и порт RDP. Не вся подсеть. Не гипервизор. Не сетевые шары соседнего отдела.
4. Ограничение прав внутри системы. Пользователь RDP не должен быть локальным администратором. Скучно, все знают, регулярно нарушается.
5. Отключённые буфер обмена и проброс дисков там, где уместно. Заодно снимает половину вопросов про утечку данных.
6. Срок действия для подрядчиков. Временный доступ должен заканчиваться сам. Как это оформить регламентом — в статье про политику доступа к VPN.
7. Фиксированный внешний адрес, если банк-клиент пускает только с известного IP. Для этого есть выделенный адрес — заодно проще разбирать журналы.

И, если честно, главное: заведите список выданных доступов. Просто таблицу. Без неё через год никто не ответит, кто и зачем подключается к вашему серверу, — я это проверял не один раз.

Что логировать и как контролировать подключения

Журнал, и я на этом настаиваю, нужен не для слежки за людьми, а чтобы заметить чужого и разобрать инцидент, когда он случится.

Минимум по каждому подключению: учётка, время начала и конца, внешний адрес источника, объём данных. Плюс отдельно — неудачные попытки входа.

Реакции сразу требуют вход из региона, где у вас никого нет, всплеск неудачных попыток по одной учётке, одновременные сессии с одним логином и активность в четыре утра у человека, который работает с девяти. Ни один из признаков сам по себе не приговор, бывают командировки и авралы, я помню. Но звонок с вопросом «это ты?» занимает минуту, а разбор шифровальщика — неделю.

Как построить это по-взрослому, с оповещениями и приоритетами, разобрано в статье про мониторинг VPN-подключений, готовая реализация — на странице мониторинга VPN.

Чек-лист безопасного удалённого доступа

• Порт RDP не доступен из интернета. Проверьте снаружи, а не «по памяти».
• Точка входа — только VPN, со вторым фактором.
• У каждого сотрудника свой доступ, общих конфигов нет.
• Маршруты нарезаны по ролям, доступ ко всей подсети не выдаётся.
• Пользователи RDP не администраторы на сервере.
• Терминальный сервер и сервер 1С обновляются.
• Бэкапы лежат там, куда нельзя дотянуться со взломанного сервера. Восстановление проверено хотя бы раз.
• Задержка до точки входа измерена и укладывается в сотню миллисекунд.
• Журналы подключений собираются и кто-то их смотрит.
• Доступ подрядчиков ограничен по сроку.

[Изображение: чек-лист безопасного удалённого доступа — десять пунктов с отметками]

Если коротко

Открытый наружу RDP — это не «пока пронесло», это отложенный инцидент: его находят автоматически и быстро, а дальше всё зависит только от того, насколько прочный у вас пароль и насколько свежий патч. Закрывается это, впрочем, не героическими усилиями, а одним архитектурным решением — убрать рабочий стол внутрь туннеля. Полдня работы для небольшой компании. А если 1С после этого тормозит, смотрите на задержку и на то, где стоит толстый клиент. В девяти случаях из десяти причина там. Не в узком канале.

Такую схему мы собираем под ключ: настроим защищённый удалённый доступ к серверу и 1С — персональные доступы, второй фактор, журналы. Две недели теста без карты, чтобы вы померили задержку на своих людях. Остальные сценарии — на странице VPN для бизнеса.

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

Опасно ли открывать RDP в интернет?

Да, и это не преувеличение. Открытый порт находят сканеры в течение минут, после чего начинается непрерывный перебор паролей. Скомпрометированный RDP — один из главных путей проникновения шифровальщиков в сеть небольших компаний. Смена порта проблему не решает.

Как подключиться к 1С удалённо?

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

Что лучше: VPN или RDP?

Вопрос некорректен — это разные уровни. RDP отвечает за работу с удалённым рабочим столом, VPN за транспорт до сети. Правильная комбинация — RDP внутри VPN, при этом порт рабочего стола наружу не публикуется.

Почему 1С тормозит через удалённый доступ?

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