Zero Trust вместо VPN: как ограничить удалённым сотрудникам доступ только к нужным сервисам

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

VPN был придуман не для того, что мы от него хотим

Технически VPN — это туннель. Он поднимает удалённый компьютер до уровня «как будто он воткнут в розетку в вашем офисе». Всё. Дальше начинается работа обычной локальной сети: маршрутизация, широковещательные запросы, доступ по IP к чему угодно, до чего дотянется маршрут.

Когда VPN придумывали в девяностых, это было гениально. Один офис, один сервер, несколько командировочных сотрудников с ноутбуками. Доверяли всем поголовно, потому что и сеть была маленькая, и сотрудников было пятнадцать человек, всех знали в лицо.

Сегодня у клиента на 30 рабочих мест обычно крутится: 1С на терминальном сервере, CRM, бухгалтерская база, сетевая шара с договорами, принт-сервер, иногда ещё и видеонаблюдение в той же VLAN. И вот бухгалтеру на удалёнке, чтобы он мог зайти в 1С, я по старинке должен дать VPN-профиль. А через этот же профиль он технически получает доступ и к шаре с кадровыми документами, и к камерам в переговорке, и даже, прости господи, к веб-морде управляемого коммутатора, если админ не подумал про ACL.

История одного взлома, который случился не у нас, но чуть не повторился

В 2023 году у меня был клиент — небольшая юрфирма, 18 рабочих мест. Они пришли не с проблемой безопасности, а с просьбой «ускорить VPN, тормозит». Полез разбираться и обнаружил прекрасное: у бывшего сисадмина, который уволился полгода назад, всё ещё активна учётка на pfSense и живой VPN-профиль. Просто забыли отключить.

Ладно, повезло — человек оказался порядочным, ничего не натворил. Но представьте на секунду: этот профиль давал доступ не только к терминальному серверу с 1С Бухгалтерией, но и напрямую в подсеть 192.168.1.0/24, где сидели сервер 1С, файловая шара с исковыми материалами клиентов и даже RDP на рабочую станцию директора. Один забытый VPN-аккаунт — и потенциально вся контора наружу.

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

Что такое Zero Trust, если без маркетингового тумана

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

На практике это означает, что вместо одной большой трубы в сеть сотрудник получает набор точечных разрешений. Бухгалтеру — веб-доступ к 1С через опубликованный сервис. Менеджеру по продажам — только к CRM. Удалённому программисту-фрилансеру — только к одному Git-репозиторию и тестовому серверу, и ни граммом больше.

Я обычно объясняю клиентам так: VPN — это ключ от подъезда, который заодно открывает все квартиры. Zero Trust — это домофон, где для каждой квартиры своя кнопка и свой код, и код можно поменять для одной квартиры, не трогая остальные.

Как я это внедряю на практике — без космических бюджетов

Пугает клиентов обычно не идея, а ожидание, что придётся покупать дорогое энтерпрайз-решение вроде Zscaler или Palo Alto Prisma за сотни тысяч в месяц. Для конторы на 20-50 рабочих мест это действительно избыточно. Я использую связку куда доступнее.

Для веб-сервисов — 1С через веб-клиент, внутренние админки, CRM — ставлю Cloudflare Access либо Tailscale с их Access-контролем. Это бесплатно или почти бесплатно до определённого числа пользователей, и настраивается за пару часов. Сотрудник открывает браузер, вводит рабочую почту, получает код на телефон — и попадает ровно на тот сервис, к которому у него есть право, без открытых портов наружу вообще.

Там, где нужен RDP на терминальный сервер — а у меня таких клиентов половина, все сидят в 1С через терминалку — использую Teleport или связку WireGuard с жёсткими ACL-правилами на уровне firewall, где каждому пользователю прописан доступ только к одному хосту по одному порту. Никакого «пустил в подсеть 192.168.х.0/24», только точка-точка. У одного клиента, производственная компания на 40 человек, мы в 2025 году так и сделали: 12 удалённых менеджеров получили доступ только к 3389 порту одного терминального сервера, и всё, ни склад по 1С Управление торговлей они не видят напрямую по сети, ни бухгалтерский сервер.

Филиалы — отдельная больная тема, и вот почему

С удалённым сотрудником всё более-менее понятно: один человек, один ноутбук. С филиалом сложнее, потому что там обычно поднимают site-to-site VPN между офисами — и вот тут-то и зарыта самая жирная дыра. Site-to-site туннель объединяет две сети в одну целиком, по умолчанию без ограничений.

У меня был кейс с сетью стоматологических клиник — два филиала, связанные именно так, IPsec-туннель между Keenetic в одной точке и pfSense в другой. Работало годами, никто не жаловался. Но при аудите выяснилось, что из филиала можно было достучаться до сервера 1С в головном офисе по SMB напрямую, хотя филиалу для работы нужен был только один сервис записи пациентов.

Правильная логика для филиала та же, что для удалённого сотрудника, просто масштабированная: не объединяй сети целиком, публикуй конкретные сервисы. Если филиалу нужна только 1С — публикуй веб-клиент 1С через реверс-прокси с аутентификацией, а не открывай тоннель в всю /24. Да, это чуть больше настройки на старте. Зато когда в одном из филиалов кто-то словит шифровальщик — а такое, поверьте, случается, у меня в практике было три случая за последние два года именно через слабое звено на удалённой точке — зловред не расползётся по всей компании за десять минут.

Сколько это стоит и с чего начать, если у вас пока классический VPN

Если у вас сейчас работает обычный VPN и всё более-менее спокойно, я не призываю всё бросить и утром сломать привычную схему. Переход делаю поэтапно, обычно за 3-4 недели для конторы в 30-40 человек.

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

По деньгам для малого бизнеса это часто дешевле, чем кажется. Cloudflare Access бесплатен до 50 пользователей на базовом тарифе, Tailscale тоже имеет бесплатный план для небольших команд. Основные затраты — это моё время на настройку, обычно от 25 до 60 тысяч рублей разово в зависимости от количества сервисов и сложности инфраструктуры, плюс сопровождение потом по обычному абонентке. Сравните это с ценой одного успешного шифровальщика, который, по моей статистике за последние три года, обходился клиентам в 300-800 тысяч рублей на восстановление, не считая репутационных потерь и разборок со страховой, если она вообще была.

Частые возражения, которые я слышу от директоров

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

«Это же неудобно, сотрудники будут жаловаться» — на практике всё ровно наоборот. Классический VPN-клиент с ручным подключением, вводом пароля и иногда токена — куда более муторная штука, чем Zero Trust доступ через браузер с одним кликом по ссылке из закладок. Мои клиенты, которые перешли, чаще жалуются, что раньше было неудобнее, а не наоборот.

«А если интернет накроется у провайдера Zero Trust-сервиса» — да, зависимость от облачного провайдера есть, это честно. Но она ничем не хуже зависимости от вашего же pfSense или Keenetic, который тоже может упасть, зависнуть или потребовать перезагрузки в самый неподходящий момент. Резервирование нужно в обоих случаях.

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

Zero Trust — это конкретный продукт, который нужно купить?
Нет, это подход к организации доступа, а не коробочное решение. Реализовать его можно разными инструментами — Cloudflare Access, Tailscale, Teleport, WireGuard с жёсткими ACL. Я обычно подбираю связку под конкретную инфраструктуру клиента, а не продаю одну и ту же схему всем подряд.

Можно ли перейти на Zero Trust, если у нас всего 10 сотрудников?
Можно и нужно, размер компании тут не аргумент против. Для 10 человек это делается даже быстрее и дешевле — обычно укладываемся в неделю работы и минимальный бюджет, потому что бесплатных лимитов у большинства сервисов хватает с запасом.

Что делать с оборудованием, которое не умеет работать без VPN, например старым 1С-сервером или промышленным контроллером?
Такие устройства оставляем за точечным VPN-туннелем, но максимально узким: доступ только к одному хосту по одному порту, с ограничением по времени и учётной записи, а не общий доступ в сеть. Это гибридная схема, и она абсолютно рабочая для переходного периода или для железа, которое физически нельзя обновить.

Сколько времени занимает полный переход с VPN на Zero Trust?
Для компании на 20-40 рабочих мест обычно 3-4 недели с параллельной работой старой схемы, чтобы не рисковать простоем. Для филиальной структуры с несколькими офисами — от 1,5 до 2,5 месяцев, потому что там больше согласований и тестирования на каждой площадке.