Терминальный сервер для 1С: как организовать безопасную удалённую работу бухгалтерии

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

Почему проброс RDP наружу — это бомба замедленного действия

Открыть порт 3389 на роутере и дать бухгалтеру IP-адрес офиса — решение на пять минут. Быстро, бесплатно, все довольны. Проблема в том, что этот порт сканируют круглосуточно. Не какой-то конкретный хакер целится именно в вас — боты обходят весь диапазон адресов автоматически, ищут открытый RDP и пробуют пароли пачками. У нас есть клиент, небольшая юридическая фирма на 12 человек, которой в 2023 году так зашифровали сервер за одну ночь. Директор пришёл утром, а вместо 1С и документов — файл с requirements.txt и адресом кошелька. Восстанавливали из бэкапа три дня, часть документов за последний месяц потеряли безвозвратно.

И это ещё повезло, что бэкап вообще был. Я видел ситуации хуже. Слабый пароль, RDP наружу, никакого бэкапа — комбинация, которая рано или поздно выстреливает. Причём необязательно шифровальщиком. Иногда просто утаскивают базу с клиентской базой данных, реквизитами контрагентов, зарплатными ведомостями — и это уже разговор с юристами про 152-ФЗ и персональные данные.

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

Пересылка баз по почте — тоже не выход, хоть и кажется безобиднее

Второй по популярности способ — выгрузить базу в .dt, заархивировать и отправить бухгалтеру на личную почту, чтобы она поработала вечером дома в своей копии 1С. Кажется безопасным: ничего же не торчит наружу. На деле дыр не меньше. База лежит теперь в трёх местах — на сервере, в почтовом ящике отправителя и в ящике получателя, и ещё, скорее всего, в облачном бэкапе этой почты у Яндекса или Mail.ru. Контролировать это уже невозможно.

А ещё возникает проблема синхронизации. Бухгалтер поработала вечером в своей выгруженной копии, что-то провела, а утром в офисе кто-то из коллег внёс изменения в основную базу. Как сливать эти две версии? Никак, вручную, с руганью и потерянными документами. У одного клиента — производственная компания в Подмосковье — так дважды проводили одну и ту же поставку, потому что бухгалтер работала параллельно с офисной базой почти неделю, пока не заметили расхождение в остатках.

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

Что такое терминальный сервер и при чём тут RDS

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

Разница с обычным RDP не в протоколе — протокол тот же самый, RDP. Разница в архитектуре и в лицензировании. Обычный RDP на Windows Server из коробки пускает одновременно одного-двух пользователей и предназначен для администрирования, а не для полноценной многопользовательской работы. Роль RDS снимает это ограничение и добавляет вменяемые инструменты управления: RD Gateway для безопасного входа снаружи через TLS без открытого порта 3389, RD Web Access — веб-страницу со списком доступных программ, групповые политики для сессий.

На практике для конторы в 15-30 человек это отдельный сервер — физический или виртуальный, неважно, но с приличным запасом по процессору и памяти, потому что каждая открытая сессия 1С отъедает свои гигабайты. Мы обычно закладываем от 2 ГБ оперативной памяти на активного пользователя плюс запас под саму систему и SQL, если база работает не на файлах, а на MS SQL Server.

RemoteApp — публикуем не рабочий стол, а саму 1С

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

Технология RemoteApp решает это элегантно. Пользователь запускает с рабочего стола дома или из ярлыка на почте иконку «1С Бухгалтерия», и у него открывается ровно окно программы — без панели задач сервера, без остального интерфейса Windows. Выглядит так, будто 1С запущена локально на его домашнем ноутбуке, хотя на самом деле всё считается на сервере. Копировать файлы с сервера себе на диск такой пользователь не может, если это заранее ограничено политикой — и это отличный барьер против случайной или намеренной утечки.

Мы настраивали такую схему бухгалтерской компании на 40 сотрудников — им нужно было раздать доступ не только штатным бухгалтерам, но и удалённым специалистам на аутсорсе, которым совершенно ни к чему видеть внутреннюю сеть компании целиком. RemoteApp плюс жёсткие права на уровне 1С решили вопрос за неделю, включая тестирование.

Как закрыть удалённый вход, а не просто спрятать его

Само по себе RDS не защищает от подбора пароля, если оставить RD Gateway смотрящим наружу без дополнительных мер. Первое правило — порт 3389 наружу не смотрит вообще, никогда. Подключение снаружи идёт через RD Gateway по 443 порту, обёрнутое в TLS, с валидным сертификатом — тем же самым, каким защищён обычный сайт с https. Внешне для сканера это просто ещё один веб-сервер, а не терминальная служба.

Второе — многофакторная аутентификация. Пароль плюс код из приложения на телефоне снижает риск взлома учётки на порядок, даже если пароль всё-таки утёк из какой-то другой утечки, а люди, как известно, любят использовать один пароль везде. Есть и более простой вариант для небольших контор — VPN до внутренней сети с последующим RDP уже изнутри периметра, но тогда VPN-шлюз должен быть настроен так же аккуратно, с сертификатами и ограничением по IP там, где это возможно.

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

Сколько это стоит и что с лицензиями

Тут часто начинается разочарование, потому что RDS — это не бесплатная фича Windows. Нужны лицензии RDS CAL на каждого пользователя или устройство, которые подключаются к терминальному серверу, отдельно от обычных лицензий Windows Server. По актуальным ценам одна RDS User CAL стоит порядка 6-9 тысяч рублей в зависимости от версии и поставщика, и покупать их нужно на каждого сотрудника, который будет заходить удалённо, даже если заходит редко.

Плюс сама лицензия Windows Server Standard или Datacenter, плюс, если база работает на SQL Server, а не на файлах — лицензии на SQL, которые считаются отдельно и не самые дешёвые. Для конторы на 10-15 бухгалтеров вся история с железом, ОС и лицензиями RDS обычно укладывается в 150-250 тысяч рублей разовых вложений, если сервер разворачивается с нуля, и это без учёта самой 1С, которая лицензируется отдельно.

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

Бэкап терминального сервера — не забудьте, это теперь ваша точка отказа

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

Мы обычно ставим Veeam Backup с ежедневным снапшотом всей виртуальной машины сервера и отдельным резервированием базы 1С по расписанию — раз в несколько часов, если работа интенсивная. Копии храним в двух местах: локально на NAS для быстрого восстановления и во внешнем хранилище на случай, если сгорит сам офис или его затопит, что тоже, поверьте, случается чаще, чем хотелось бы.

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

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

Сколько времени занимает настройка RDS для небольшой бухгалтерии на 5-10 человек?
Если сервер уже есть и его достаточно по мощности, разворачивание роли RDS, настройка RemoteApp для 1С и RD Gateway занимает три-пять рабочих дней вместе с тестированием. Если сервер нужно покупать или арендовать с нуля, добавьте ещё неделю-полторы на закупку и настройку железа.

Можно ли обойтись просто VPN без полноценного RDS?
Можно, и для совсем маленьких команд из двух-трёх человек это иногда даже проще: поднимаете VPN до офисной сети и подключаетесь обычным RDP уже изнутри периметра. Но как только людей становится больше десяти, управлять индивидуальными RDP-сессиями без RDS и RemoteApp превращается в головную боль, и лицензионные ограничения обычного RDP всё равно упрутся в потолок.

У нас уже открыт RDP наружу, что делать прямо сейчас, не дожидаясь полной перестройки?
Первым делом закройте порт 3389 на файрволе для внешних адресов — это можно сделать за час и уже сильно снизит риск. Дальше временно можно поднять простой VPN как переходный вариант, пока не будет готова нормальная схема с RD Gateway и RemoteApp, но затягивать с этим переходом не стоит.

Нужен ли для этого отдельный физический сервер или подойдёт виртуальная машина?
Виртуальная машина подходит прекрасно, и мы чаще всего именно так и делаем — что на своём железе через Hyper-V, что в аренде у хостера. Важнее не физическая или виртуальная природа сервера, а честный запас по процессору и памяти под количество одновременных сессий, иначе 1С будет тормозить у всех сразу.