Бухгалтер работает из дома: как отдать 1С наружу и не проделать дыру в периметре

Бухгалтер уходит на удалёнку, и на следующее утро вам говорят: «Сделай, чтобы 1С работала из дома, только быстро». Самый быстрый путь — проброс 3389 на роутере — через месяц оборачивается заблокированными учётками, тормозами и, если повезёт меньше, шифровальщиком в общей папке. Разберу три схемы, которые реально работают в компании до 50 рабочих мест, покажу свои конфиги WireGuard, объясню, когда я вместо VPN ставлю RD Gateway, а когда публикую 1С по HTTPS — и что нужно докрутить, чтобы схема не осталась полумерой.

«Пробросим 3389, пароль же сложный» — почему это ломается

Начну с того, что вижу чаще всего. Роутер, правило DNAT «внешний 3389 → внутренний сервер 1С», иногда — «внешний 33890 → 3389, мы же порт поменяли». Дальше короткий период счастья, а потом Security-журнал сервера начинает выглядеть так, что его страшно открывать. На одном из клиентских терминальных серверов я снимал срез за 14 дней и получил 44 371 событие 4625 (неудачный вход) — это чистый перебор, который шёл круглосуточно с нескольких десятков адресов. Никакой «сложный пароль» тут не главный аргумент: главный аргумент в том, что сервис аутентификации Windows выставлен в открытый интернет и обрабатывает чужие запросы 24/7.

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

Второй аргумент — не подбор, а сам код. RDP-стек за последние годы регулярно получал уязвимости, которые срабатывают ДО аутентификации: классический пример — BlueKeep (CVE-2019-0708) в RDP-службе Windows, где для эксплуатации не нужны ни логин, ни пароль. NLA (Network Level Authentication) закрывает часть таких сценариев, потому что требует аутентификации на уровне CredSSP до создания сессии, но и в CredSSP находили дыры. Логика простая: если сервис не виден из интернета — он не эксплуатируется вообще, независимо от того, успели вы поставить обновление или нет.

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

• Проброс 3389 (или любого другого порта на RDP) = сервис аутентификации Windows работает на весь интернет.
• Смена номера порта даёт эффект на дни, не на месяцы.
• Класс предаутентификационных уязвимостей RDP никуда не делся — NLA снижает риск, но не убирает.
• Скомпрометированная RDP-сессия — это доступ в LAN, а не «только к 1С».

Три схемы, которые работают, и как я между ними выбираю

Вариантов на самом деле три, и они не конкурируют, а закрывают разные ситуации. Первый — VPN до офисной сети, а внутри уже обычный RDP или тонкий клиент 1С. Второй — RD Gateway: RDP заворачивается в HTTPS, наружу смотрит только 443 с публичным сертификатом. Третий — публикация базы 1С на веб-сервере и работа через веб-клиент или тонкий клиент по HTTPS, вообще без удалённого рабочего стола.

Моя позиция без обиняков: для компании до 50 рабочих мест, где на удалёнке два-пять человек — бухгалтер, директор, кто-то из менеджеров — я делаю VPN. WireGuard, ключи по человеку, доступ строго до нужных адресов внутри. Это самая дешёвая по трудозатратам и самая понятная в сопровождении схема. Никаких лицензий, никаких публичных сертификатов, настраивается за час, отлаживается по одной команде.

RD Gateway я ставлю, когда удалённых пользователей становится много (условно от десяти-пятнадцати), когда люди ходят с личных устройств и с чужих сетей, где UDP режут, и когда нужна многофакторная аутентификация — RD Gateway умеет отдавать аутентификацию в RADIUS, и это официально описанный сценарий в документации Microsoft. Плюс у него есть то, чего у VPN нет из коробки: политики RD CAP и RD RAP, то есть «кому можно подключаться» и «к каким конкретно машинам». Это удобно, когда пользователей десятки и нужен внятный разграниченный доступ.

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

• 2–5 удалённых сотрудников, свои устройства, есть кому обслуживать — WireGuard + RDP внутри.
• 10+ пользователей, личные устройства, нужна MFA и разграничение по машинам — RD Gateway на 443.
• Одна база, внешний специалист, минимум прав — публикация 1С по HTTPS.
• Ноутбук выдан компанией и заведён в домен — VPN, и обязательно с автозапуском туннеля.

WireGuard так, как я его ставлю: конфиги и грабли

WireGuard подкупает тем, что его конфиг помещается на экран и читается вслух. В основе — то, что авторы называют Cryptokey Routing: публичный ключ пира связывается со списком IP-адресов, которым разрешено ходить внутри туннеля. Формулировка с сайта проекта прямая: при отправке пакетов список allowed IPs работает как таблица маршрутизации, а при приёме — как список контроля доступа. Это одна строка, которая одновременно и маршрут, и права. Второе важное свойство — сервер молчит в ответ на неаутентифицированные пакеты: рукопожатие Noise_IK устроено так, чтобы не выделять состояние под потенциально поддельные сообщения. На практике это означает, что просто «увидеть» ваш WireGuard сканером нельзя — для сканера UDP-порт неотличим от закрытого или отфильтрованного: ответа нет ни на пустой пакет, ни на мусор.

Серверная часть у меня обычно живёт на pfSense или на отдельной Linux-машине в DMZ. Ключи генерирую по человеку, никогда не общие. umask 077 перед генерацией — рекомендация из Quick Start проекта: приватный ключ сразу создаётся с правами только для владельца.

umask 077
wg genkey | tee ol.key | wg pubkey > ol.pub

Серверный конфиг — по одному блоку [Peer] на сотрудника, и в AllowedIPs только его собственный /32. Это ровно тот момент, где список выступает как ACL: с ключа Ольги в туннель не пролезет пакет с чужим адресом источника. Важная оговорка, которую часто упускают: серверный AllowedIPs ограничивает, с какого адреса пир может слать пакеты, но не то, куда он может ходить. Доступ «только до сервера 1С и терминала» задаётся отдельно — правилами фаервола на интерфейсе туннеля (на pfSense это вкладка правил интерфейса WireGuard), и без них пир с офисной подсетью в AllowedIPs видит всю LAN.

[Interface]
PrivateKey = <приватный ключ сервера>
Address = 10.66.66.1/24
ListenPort = 51820

[Peer]
# Ольга, бухгалтерия, домашний ноутбук
PublicKey = <публичный ключ Ольги>
AllowedIPs = 10.66.66.11/32

[Peer]
# Директор, ноутбук
PublicKey = <публичный ключ директора>
AllowedIPs = 10.66.66.12/32

Клиентский конфиг — и вот здесь главная развилка. Я почти всегда делаю раздельное туннелирование: в AllowedIPs только офисная подсеть и адресация самого туннеля, а не 0.0.0.0/0.

[Interface]
PrivateKey = <приватный ключ Ольги>
Address = 10.66.66.11/32
DNS = 192.168.10.5

[Peer]
PublicKey = <публичный ключ сервера>
Endpoint = vpn.example.ru:51820
AllowedIPs = 192.168.10.0/24, 10.66.66.0/24
PersistentKeepalive = 25

Почему не полный туннель: я на этом обжигался дважды. Первый раз — у клиента, где сотрудники сидели на Mac с полным туннелем через сервер в дата-центре: маркетплейсы, банк-клиент и госуслуги начали требовать «отключите VPN», потому что видели IP хостинга, а не домашний адрес. Второй — сюрприз с адресацией: 0.0.0.0/0 не перебивает домашнюю сеть 192.168.1.0/24, потому что on-link маршрут /24 длиннее и выигрывает. Если офис у вас тоже на 192.168.1.0/24 — вы получите ровно ничего, и человек будет уверен, что «VPN не работает». Поэтому офисную сеть я выбираю нестандартную, из середины диапазона: 192.168.37.0/24, 10.66.10.0/24 — что угодно, кроме 192.168.0.0/24 и 192.168.1.0/24.

• PersistentKeepalive = 25 обязателен для клиентов за NAT, иначе трансляция протухает и туннель «оживает» только при исходящем пакете.
• Один ключ = один человек. Общий конфиг «для бухгалтерии» лишает вас возможности отозвать доступ одному уволенному.
• Отзыв доступа = удалить блок [Peer] и применить конфиг. Никаких CRL и церемоний.
• Проверка живости: `wg show wg0 latest-handshakes` — если рукопожатие старше пары минут, туннеля фактически нет.
• Офисную подсеть выбирайте заранее нестандартную — переезжать адресацией потом дороже, чем выбрать правильно один раз.

Закрыть RDP на сервере — половина работы, которую забывают

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

После того как туннель заработал, я делаю три вещи. Удаляю (не отключаю — удаляю) правило проброса на периметре. Ограничиваю правило Windows-фаервола для RDP только адресами VPN-подсети. И проверяю снаружи, что порт действительно закрыт — с любой машины вне периметра.

New-NetFirewallRule -DisplayName "RDP only from VPN" -Direction Inbound -Protocol TCP `
  -LocalPort 3389 -RemoteAddress 10.66.66.0/24 -Action Allow

Отдельная ремарка про правила на pfSense и подобных: они умеют быть в конфиге и при этом не работать. У одного клиента NAT-правило значилось в config.xml как disabled, а в веб-интерфейсе выглядело абсолютно живым — и полдня ушло на «почему не пробрасывается». Всегда проверяйте фактическое состояние на самом фильтре, а не картинку в панели.

И параллельно — гигиена учётных записей. Политика блокировки должна быть включена, иначе перебор ничем не ограничен. В домене её меняют в политике паролей домена (Default Domain Policy) — локальная команда net accounts на рядовом сервере будет перезаписана доменной политикой при следующем применении GPO. Проще всего задать значения модулем ActiveDirectory на контроллере домена; окно наблюдения по документации не может быть больше длительности блокировки:

Get-ADDefaultDomainPasswordPolicy -Current LoggedOnUser |
  Set-ADDefaultDomainPasswordPolicy -LockoutThreshold 10 -LockoutDuration 00:15:00 -LockoutObservationWindow 00:15:00
Get-ADDefaultDomainPasswordPolicy | Select-Object LockoutThreshold, LockoutDuration, LockoutObservationWindow

И посмотрите, кто именно к вам стучится — это полезно и до, и после закрытия периметра. В событии 4625 шестое поле данных (индекс 5) — имя учётной записи, под которой пытались войти, а двадцатое (индекс 19) — сетевой адрес источника, поэтому я строю две выборки: по логинам и по адресам:

$ev = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-7)}
# по учётным записям (TargetUserName)
$ev | Group-Object { $_.Properties[5].Value } | Sort-Object Count -Descending | Select-Object -First 15 Count, Name
# по адресам источника (IpAddress)
$ev | Group-Object { $_.Properties[19].Value } | Sort-Object Count -Descending | Select-Object -First 15 Count, Name

• Удалить правило проброса, а не выключить его.
• RDP-правило фаервола — только с адресов VPN-подсети.
• Проверить закрытие снаружи, с мобильного интернета, а не из офиса.
• Включить блокировку учётных записей в доменной политике паролей и проверить через `Get-ADDefaultDomainPasswordPolicy`, что значения реально применились.
• Снять срез 4625 через неделю после закрытия — правильный результат близок к нулю.

Когда я ставлю RD Gateway вместо VPN

RD Gateway — это роль Windows Server, которая заворачивает RDP в HTTPS-туннель. Наружу смотрит 443, публичный сертификат, а RDP-сессия дальше идёт уже внутри защищённого канала. Microsoft описывает три задачи шлюза в порядке подключения: установить зашифрованный SSL-туннель между устройством пользователя и шлюзом, аутентифицировать пользователя средствами IIS (в том числе через RADIUS для многофакторной аутентификации) и дальше пересылать трафик к целевому ресурсу. Дополнительно, при включённом UDP-транспорте, шлюз использует отдельный UDP-порт (по умолчанию 3391) — если он закрыт, всё продолжит работать по TCP, просто отзывчивость картинки будет хуже.

Практическая ценность RD Gateway для меня в двух вещах. Первая — 443 проходит везде: из гостиничного Wi-Fi, из корпоративной сети клиента, с телефона в роуминге. UDP для WireGuard режут заметно чаще. Вторая — политики RD CAP (кто может подключаться) и RD RAP (к каким компьютерам), которые дают внятную матрицу доступа без ручной возни с фаерволом на каждой машине.

Есть и цена. Нужен публичный сертификат — Microsoft прямым текстом рекомендует публично выпущенный сертификат для продакшена, а самоподписанный оставляет только для тестов и PoC, иначе придётся раскатывать цепочку доверия на все клиентские устройства. Нужен IIS, а значит — регулярное обновление веб-стека, который смотрит в интернет. Нужны RDS CAL. И надо помнить, что вы всё-таки публикуете наружу службу аутентификации, пусть и куда более прочную, чем голый RDP.

Отсюда мой критерий выбора. Если удалённых людей мало и они предсказуемы — WireGuard, потому что снаружи не видно вообще ничего. Если людей много, устройства разношёрстные и нужна MFA — RD Gateway, но обязательно с многофакторной аутентификацией через RADIUS и с закрытым RDP на самих сессионных хостах. Без MFA шлюз превращается в красиво оформленную ту же самую точку перебора паролей.

• Плюсы: работает через 443 из любых сетей, MFA через RADIUS, политики CAP/RAP, знакомый клиент Remote Desktop.
• Минусы: публичный сертификат и его продление, IIS наружу, RDS CAL, служба аутентификации видна из интернета.
• Обязательное условие: MFA. Шлюз без второго фактора — это RDP наружу с приятным интерфейсом.

Разбор: архитектурная мастерская «Контур и Свет», бухгалтерия на удалёнке и проброшенный 3389

Архитектурная мастерская «Контур и Свет», 22 рабочих места: архитекторы и конструкторы, два ГИПа, бухгалтерия из двух человек и директор. Инфраструктура типовая для небольшого проектного бюро: один сервер приложений с 1С и MS SQL, контроллер домена, файловый сервер с проектным архивом и терминальный сервер на четыре сессии. На удалёнке трое — главбух, бухгалтер по зарплате и директор. Досталось мне всё со следующей картиной: на периметровом роутере три правила проброса (33389, 33390, 33891) на три разные машины, у каждого сотрудника ярлык RDP с внешним адресом и портом, пароли — «фамилия плюс год» у двоих из трёх.

Первым делом снял срез журналов. За 14 дней — 27 с небольшим тысяч событий 4625 на терминальном сервере и около 5 тысяч на сервере приложений, источники — 40+ уникальных адресов, в лидерах одна хостинговая сеть с 18 412 попытками. Политика блокировки учётных записей: LockoutThreshold = 0, то есть блокировки нет вообще. Учётная запись главбуха при этом имела права локального администратора на сервере приложений — «чтобы обновления 1С ставить». Хуже того, с терминального сервера была подключена шара с проектным архивом мастерской: подобранный пароль бухгалтера открывал дорогу к чертежам за десять лет работы. Скорость подбора при таком раскладе ограничивается только каналом.

Что сделал за один вечер и одно утро. Поднял WireGuard на pfSense, подсеть туннеля 10.66.66.0/24, три пира с личными ключами, AllowedIPs у каждого — свой /32 на сервере и на клиенте только офисная 192.168.37.0/24 (сеть уже была нестандартная — повезло). Клиентам поставил официальный клиент WireGuard с автозапуском туннеля при старте системы. Удалил все три правила проброса. На интерфейсе туннеля разрешил пирам только терминальный сервер и сервер 1С — файловый сервер с проектами из туннеля недоступен вовсе. Ограничил RDP-правила Windows-фаервола адресами 10.66.66.0/24. Включил блокировку: порог 10, окно и длительность по 15 минут. Снял с главбуха локального админа, а установку обновлений 1С перевёл на отдельную сервисную учётку и на нашу удалённую процедуру.

Результат через неделю: 4625 на терминальном сервере — 14 событий, все свои, все от опечаток. Через месяц — 31 событие, столько же природы. Жалоб на скорость не было ни одной: WireGuard добавляет к RDP-сессии единицы миллисекунд, а раздельное туннелирование оставило домашний интернет, банк-клиент и госуслуги работать напрямую. Единственная реальная проблема за квартал — у бухгалтера по зарплате дома провайдер выдавал CGNAT и рвал UDP-трансляцию: лечилось строкой PersistentKeepalive = 25 в её конфиге, до этого туннель «просыпался» только через минуту после начала работы.

Что бы я сделал иначе, если бы делал заново. Сразу выдал бы всем троим корпоративные ноутбуки (для мастерской на 22 места это три машины, а не бюджетная катастрофа) вместо домашних машин — потому что домашний компьютер с играми детей внутри VPN-периметра остаётся самым слабым звеном всей схемы, и никакой WireGuard этого не лечит. И сразу поставил бы мониторинг рукопожатий с алертом в Telegram: первые две недели я узнавал о проблемах от пользователей, а не от системы.

• Было: 3 проброса RDP, ~32 000 событий 4625 за 14 дней, блокировки учёток нет, главбух — локальный админ, из RDP-сессии виден проектный архив.
• Стало: WireGuard 10.66.66.0/24, персональные ключи, из туннеля доступны только терминал и 1С, RDP только из туннеля, блокировка 10/15/15, права урезаны.
• Через неделю: 14 неудачных входов, все свои. Через месяц: 31.
• Трудозатраты: примерно 6 часов, включая удалённую настройку трёх домашних машин.

Публикация 1С по HTTPS: когда это хорошее решение, а когда самообман

Отдельный вопрос, который мне задают постоянно: «А зачем вообще удалённый рабочий стол, давайте опубликуем 1С через веб — и пусть бухгалтер работает в браузере». Технически это делается: база публикуется на веб-сервере (Apache или IIS), и дальше к ней ходит либо веб-клиент в браузере, либо обычный тонкий клиент 1С по адресу вида https://1cbase.example.ru/base. Я такие публикации держу у нескольких клиентов, и для части задач это действительно лучший вариант.

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

Где начинается самообман. Первое — печать и файлы: печать этикеток, сканирование первички, выгрузка в банк-клиент, работа с внешними обработками, подписание документов через КриптоПро на локальном компьютере — всё это в браузере либо не работает, либо требует расширения и превращается в ежедневную боль. Второе — производительность: тяжёлые конфигурации через веб-клиент ощутимо медленнее, особенно на списках с большим числом колонок. Третье — обмены и интеграции, которые часто завязаны на конкретную машину. У меня был кейс, где вход в опубликованную базу вообще падал с «Сеанс отсутствует или удален» у всех, кто вводил пароль дольше 25–30 секунд, — и разбирались мы с настройками времени жизни сеансов, а не с бухгалтером.

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

И ещё одно, про что почти всегда забывают: публикация должна быть только по HTTPS, с редиректом с 80 порта и с валидным сертификатом. Публикация базы по чистому HTTP — это пароли к вашей учётной системе открытым текстом через чужой Wi-Fi. Такое встречается чаще, чем хотелось бы.

• Годится: внешний бухгалтер, аудитор, отчёты руководителю, лёгкий доступ к одной базе.
• Не годится: печать этикеток и первички, сканирование, банк-клиент, ЭЦП на локальной машине, тяжёлые списки.
• Обязательно: только HTTPS, валидный сертификат, ограничение доступа к каталогу публикации.
• Проверьте настройки времени жизни сеансов — нестандартные значения дают загадочные «сеанс отсутствует или удален».

Обвязка, без которой любая схема — полумера

VPN закрывает канал. Он не закрывает ни украденный пароль, ни домашний компьютер с майнером, ни шифровальщик, который приехал во вложении. Поэтому после туннеля я всегда прохожу по короткому списку, и это важнее, чем выбор между WireGuard и RD Gateway.

Права. Удалённый бухгалтер не должен быть локальным администратором сервера. Это самое частое возражение («а как я обновления 1С поставлю?») и самая частая причина, по которой один подобранный пароль превращается в компанию без бэкапов. Обновления — сервисная учётка и регламент, а не права админа у пользователя.

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

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

Бэкапы и журналы. Резервные копии баз 1С — на отдельный носитель или площадку, без доступа с рабочих учёток. Журналы входов — с ретенцией хотя бы 90 дней, иначе при разборе инцидента вы просто ничего не увидите. Мониторинг — минимум на доступность туннеля и на всплески неудачных входов, с алертом туда, куда вы реально смотрите.

Уход сотрудников. Удаление пира из конфига WireGuard занимает 30 секунд — если про него вспомнили. Заведите привычку: увольнение = отзыв ключа и отключение учётной записи в тот же день. Я регулярно нахожу в конфигах пиров, названных именами людей, уволившихся год назад.

• Никаких прав локального администратора у удалённых пользователей.
• Отключить проброс локальных дисков в RDP-сессию, буфер обмена — по ситуации.
• MFA там, где точка входа видна из интернета (RD Gateway обязательно).
• Бэкапы вне досягаемости рабочих учёток, проверка восстановления хотя бы раз в квартал.
• Мониторинг доступности туннеля и всплесков событий 4625.
• Регламент отзыва доступа при увольнении — в тот же день.

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