RA VPN, NAC, ZTNA… пора разобраться. Обзор технологий и доступных решений

RA VPN, NAC, ZTNA… пора разобраться. Обзор технологий и доступных решений

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

Вскоре все осознали, что период удалёнки «немного» затянется (а у кого-то и вовсе стал стандартом) и, кроме быстрого развёртывания удалённого доступа, нужно ещё думать и о безопасности в условиях новой реальности. И этот вызов куда серьёзнее для любого ИБ-специалиста. Пользователи могут подключаться откуда угодно и с чего угодно. А если их учётная запись будет скомпрометирована, то под угрозой оказывается вся корпоративная сеть. 

Все эти проблемы, конечно же, решаемы, и существует множество инструментов и классов средств защиты. На этой волне уже долгое время в ИБ-медиапространстве звучат такие термины, как RA VPN, ZTNA, 2FA, PAM и т. д. Неподготовленному человеку довольно трудно сразу разобраться во всех этих терминах. Что они означают, когда и как их применяют и в чём их преимущества? Чтобы расставить все точки над i, мы и создали эту небольшую статью. Помимо обзора этих технологий, мы также акцентируем внимание на доступных на сегодняшний день решениях, так как после февраля 2022 года выбор существенно уменьшился. 

Remote Access VPN

VPN (Virtual Private Network) — виртуальная частная сеть, как пишут в «Википедии». Здесь важно сразу разделять две большие категории этого самого VPN:

• Site-to-Site VPN применяется для объединения нескольких офисов. Классический пример: сотрудникам филиалов требуется доступ к ресурсам центрального офиса. Если говорить простым языком, то Site-to-Site VPN позволяет организовать защищённый (шифрованный) канал или туннель между офисами через публичную сеть Интернет. Это быстро, удобно и дёшево (в отличие от организации выделенного канала, что и не всегда возможно). Чаще всего для этого используются технологии IPSec, которые поддерживаются практически любым маршрутизируемым сетевым устройством (Cisco, D-Link, Mikrotik и т. д.).
• Remote Access VPN (RA VPN) — тот самый VPN для организации удалённого доступа пользователей к сервисам компании. Здесь уже строится защищённый туннель между конкретным устройством пользователя и VPN-шлюзом. Удалённый сотрудник может подключаться с компьютера (Windows, Linux, MacOS) или мобильного устройства (Аndroid, iOS). Обычно на устройство устанавливается специальный VPN-клиент, и чаще всего он работает, используя всё тот же IPSec или же более «модный» SSL. В качестве VPN-шлюза может выступать межсетевой экран или маршрутизатор, которые поддерживают IPSec/SSL.     

Мы не сможем в рамках одной небольшой статьи рассмотреть оба варианта. Поэтому давай сконцентрируемся на особенностях RA VPN. И начнём, пожалуй, с вопроса: «А на чём раньше строили RA VPN?» Раньше — до февраля 2022-го. И тут есть несколько безоговорочных лидеров:

1. Cisco AnyConnect + Cisco ASA (а иногда и + Cisco ISE). Решение корпоративного уровня. До сих пор во многом является эталоном в сфере RA VPN.
2. OpenVPN/Wireguard. Бесплатный вариант. Причём WireGuard становится всё более популярным. Клиенту требуется установка специального VPN-клиента.
3. Встроенный функционал сетевых устройств RA VPN. Как писал выше, практически все маршрутизаторы/межсетевые экраны поддерживают работу в качестве VPN-шлюза (IPSec). Для подключения пользователь может использовать встроенные функции операционной системы (native-vpn-клиент).

Также довольно большой популярностью пользовались решения Fortinet, Palo Alto и Check Point (последний до сих пор доступен на отечественном рынке). 

С недавних пор рынок изменился, а потребность в RA VPN только растёт. Кто-то использует VPN исключительно для админов, кто-то и для обычных пользователей, предоставляя им доступ к корпоративным ресурсам. Какие же типовые требования традиционно предъявляли для решений по организации RA VPN?

1. Аутентификация и авторизация. Необходима поддержка интеграции с AD, Radius и системами двухфакторной аутентификации (2FA).
2. Гибкие политики доступа на основе групп, ролей, профилей.
3. Поддержка современных протоколов шифрования (IPSec, TLS и т. д.).
4. Детализированное журналирование и мониторинг состояния.
5. Поддержка различных платформ (WIndows, Linux, MacOS, Android, iOS).
6. Отказоустойчивость (поддержка различных технологий кластеризации).

Здесь важно понимать, что сам концепт RA VPN довольно стар и появился несколько десятков лет назад. В связи с этим традиционные требования уже не отвечают современным потребностям, так как существует ряд проблем:

• В большинстве случаев доступ удалённым пользователям предоставляется на L3 уровне, то есть открывается полный доступ до конкретного IP-адреса или (даже чаще) до целых подсетей. Это, в свою очередь, увеличивает площадь возможной атаки в случае компрометации учётной записи или устройства пользователя.
• Пользователи могут подключаться к корпоративной сети со своих устройств (BYOD), которые не всегда соответствуют стандартам безопасности. Компьютер удалённого сотрудника может быть банально заражён (кейлогер, шифровальщик, криптомайнер), а это может привести к распространению вирусов уже в корпоративную сеть или утечке конфиденциальных данных.
• Для подключения требуется VPN-клиент, что может вызвать трудности при его распространении на большое количество пользователей с различными операционными системами. Даже сейчас довольно трудно найти решение, которое поддерживало бы все виды и все версии ОС.
• Нет возможности мониторить или запрещать действия удалённого пользователя в рамках VPN-трафика. Вы просто НЕ видите, что происходит после подключения удалённого пользователя.  

Часть проблем удаётся решить, часть остаётся открытыми. К примеру, одним из наиболее важных дополнений к классическому RA VPN являются NAC-системы.

NAC

Network Access Control (NAC) — система, которая позволяет выполнять проверку рабочей станции перед подключением к корпоративной сети. NAC может работать как без специальных агентов (802.1х), так и с агентами. Второй вариант чаще всего применяется именно для RA VPN, когда перед подключением удалённого пользователя его компьютер может быть проверен на:

• наличие критических обновлений системы;
• наличие антивирусного ПО;
• наличие необходимого ПО;
• запрещённые системные процессы;
• хеш-суммы отдельных файлов;

и т. д.

Сам концепт NAC существует очень давно, и решения данного класса применяются не только для RA VPN, но и для проводного/беспроводного доступа внутри корпоративной сети. Наиболее популярные решения:

• Cisco ISE;
• ForeScout;
• PortNox;
• TruNAC (доступен в России).

На отечественном рынке выбор значительно меньше:

• Efros Defence Operations;
• AxelNAC

Несмотря на то что NAC-решения позволяют существенно повысить безопасность и управляемость удалённого доступа, всё же ещё остаются серьёзные проблемы:

• всё ещё регулирование на уровне сетей;
• отсутствие мониторинга после подключения;
• отсутствие контроля действий в рамках разрешённого трафика.

Решить эти и многие другие проблемы можно в рамках ZTNA.

ZTNA

Zero Trust Network Access (ZTNA) — принцип нулевого доверия в сетевом доступе. Первое, что нужно здесь усвоить, — ZTNA — это не технология, это концепт. Причём этот концепт используется не только в рамках RA VPN, но и внутри корпоративных сетей, внутри баз данных, внутри микросервисных архитектур и т. д. Мы рассмотрим этот концепт в рамках задачи RA VPN.

Главная предпосылка зарождения ZTNA — уход от исключительно периметральной защиты к защите индивидуальных транзакций. Такой подход ещё называют SDP (software defined perimeter) или «программно определяемый периметр». Концепт ZTNA был сформулирован в далёком 2004 году в публикациях компании Forrester (да-да, не всё идёт от Gartner!). 

Так как это концепт, разные компании могут по-разному реализовать данный принцип. Есть компании, которые внедряют ZTNA в рамках одного решения от одного вендора. Другие могут реализовать ZTNA на нескольких решениях. Главное, чтобы по итогу вы могли делать следующее:

1. Проверка пользователя

• интеграция с AD/LDAP/Radius;
• 2FA (SMS/OTP/Email/Token).

2. Проверка устройства

Так называемый постчуринг или комплаенс:

• Device ID;
• наличие обновлений/антивируса;
• наличие/отсутствие процессов;
• время подключения;
• место подключения;

и т. д.

Если хост прошёл проверку, это не значит, что ему можно доверять. Его нужно всё время перепроверять!

3. Применение политики минимального доступа

Политика минимально необходимого доступа:

• доступ только по сервису (например, tcp 22, 80, 443 порт);
• доступ к приложению (публикация на портале);
• ограничение по времени;
• запрет определённых действий в рамках активного подключения (например, блокировка сторонних VPN или открытия CLI).

Один из принципов ZTNA: доступ к одному ресурсу не гарантирует доступ к другому. Авторизации подвергается каждое сетевое взаимодействие!

Если попробовать резюмировать, то получим, что ZTNA и RA VPN — это два разных подхода к обеспечению безопасного удалённого доступа к корпоративным ресурсам и информации. ZTNA реализует более гранулированный доступ, с контролем рабочих станций и сессий. RA VPN более простое решение по обеспечению удалённого доступа, на базе обычных сетевых взаимодействий.

Выбор между ZTNA и RA VPN зависит от конкретных потребностей вашей организации, уровня безопасности, масштабируемости и архитектурных предпочтений. Многие организации также могут рассматривать комбинированный подход, чтобы обеспечить максимальную безопасность и удобство для пользователей.

ZTNA на отечественном рынке

Как обстоят дела с RA VPN и ZTNA-решениями на отечественном рынке? Если коротко, пока не очень. После ухода зарубежных вендоров стало совершенно очевидно, что российские разработки нуждаются в очень серьёзной доработке под современные требования клиентов.

Давайте рассмотрим возможности наиболее заметных игроков рынка корпоративного сегмента на российском рынке (на сентябрь 2024 года):

«Континент» («Код Безопасности»):

• «Континент АП» (работает с 3.х, 4.Х) — классический VPN;
• бесклиентский VPN («Континент TLS»);
• ZTN-клиент («Континент АП» + TLS);
• есть комплаенс проверки, но только перед подключением (NAC через скрипт); 
• нет централизованного управления;
• есть интересная интеграция с «Сакура» (ближе к концепту ZTNA);
• Split Tunneling/Default route;
• интеграция с 2FA («Мультифактор», Indeed AM, Avanpost).

UserGate:

• нативные клиенты (Win, Linux, MacOS) + бесклиентский;
• UG Client (работает с UserGate 7.1);
• дорабатывается, пока только Windows;
• постоянная проверка станций + централизованное управление;
• есть Firewall/URL Filtering;
• базовый функционал EDR (сбор телеметрии);
• Split Tunneling/Default route;
• интеграция с 2FA («Мультифактор», Indeed AM, Avanpost).

Check Point:

• Mobile Access — классический VPN (Win, Mac), SSL-портал;
• интеграция с 2FA («Мультифактор», Indeed AM и т. д.);
• есть возможность проверки хоста (SCV), без централизованного управления;
• нет профилей;
• Harmony Endpoint — VPN, Compliance, EDR, AV, Firewall, App Control, Disk Encryption и т. д.;
• наиболее комплексное и зрелое решение;
• локальное и облачное управление;
• Quantum SASE (Perimeter 81).

Как видим, выбор невелик, но он всё же есть.

Заключение

Как уже было сказано, ZTNA — это всего лишь концепт без применения каких-то конкретных технологий. Этот концепт позволяет существенно повысить защищённость корпоративной сети, но не решает всех проблем. Надеюсь, мы сможем рассмотреть решения класса SASE в наших следующих статьях.