Прежде чем открыть VPN-туннель, главный вопрос — не протокол, а кто, с какого устройства и к чему получит доступ.
В традиционных VPN-архитектурах туннель чаще всего управляется отдельно от политики идентичности. С одной стороны корпоративный каталог, с другой система проверки VPN, отдельно сервис MFA, другой инструмент для доверия устройства и отдельная линия логов для аудита. Эта фрагментированная структура делает удалённый доступ скорее операционно хрупким, чем безопасным.
Того, что пользователь знает правильный пароль, само по себе недостаточно. Управляется ли устройство, включено ли шифрование диска, актуально ли защитное ПО, в правильной ли группе пользователь, рискован ли исходный IP или временной интервал? Если на эти вопросы не отвечают до открытия туннеля, VPN превращается в неконтролируемую дверь, расширяющую корпоративную сеть.
Split tunneling, полный туннель и сегментный доступ — это тоже не только вопрос сетевого маршрута. Пользователь из финансов и подрядчик не должны иметь доступ к одной сети; управляемое корпоративное устройство и личное устройство не должны обладать одинаковыми правами. Когда политика туннеля не проектируется вместе с идентичностью, группой и доверием устройства, область доступа остаётся шире необходимого.
На операционной стороне проблема растёт. Если SSL VPN, IKEv2, MFA, групповая политика, журнал сессий и передача в SIEM управляются по отдельности, команда безопасности не видит всю картину в момент инцидента. Кто подключился, с какого устройства, к каким сегментам получил доступ и почему соединение было разорвано — всё это должно быть видно в едином аудиторском следе.
Подход TR7 AAM рассматривает VPN-доступ не как отдельный сетевой сервис, а как контролируемый слой удалённого доступа, где сходятся решения по идентичности, MFA, постуре устройства, условному доступу и аудиту.
Наш подход
TR7 AAM рассматривает удалённый доступ с клиентом ещё до выбора протокола — как решение об идентичности, доверии устройства и области доступа.
Единое решение об идентичности применяется к разным вариантам туннеля
Пользователь может быть проверен через LDAP/AD, RADIUS, OIDC, SAML или локальный источник пользователей. То же решение об идентичности образует общую основу политики для вариантов доступа с клиентом, таких как SSL VPN или IKEv2.
Постура устройства ETM даёт сигнал доверия до открытия туннеля
Оценка доверия устройства учитывается как часть решения об условном доступе. Можно применить модель: широкий доступ для управляемых устройств, ограниченный доступ для личных устройств и отказ в доступе для недоверенных устройств.
SSL VPN позиционируется для доступа из ограниченных сетей
Подход SSL VPN на базе TLS работает через порт 443, поэтому обеспечивает удобство прохождения в средах корпоративных межсетевых экранов и прокси. Решение о split tunneling или полном туннеле может быть привязано к модели политики.
IKEv2/IPsec позиционируется для нативного клиентского опыта
IKEv2/IPsec предлагает модель удалённого доступа, совместимую с нативными VPN-клиентами таких операционных систем, как Windows, macOS, iOS и Android. При смене мобильной сети подход IKEv2 даёт практическое преимущество в непрерывности туннеля.
Возможности
TR7 SSL VPN и IKEv2 ставят в центр не столько протокол туннеля, сколько решение AAM об идентичности, MFA, постуре и области доступа.
Подход SSL VPN нацелен на удобство доступа через порт 443
SSL VPN с туннельным подходом на базе HTTPS/TLS позиционируется для доступа к корпоративным ресурсам из ограниченных сетей. Использование порта 443 обеспечивает удобство доступа во многих корпоративных, гостиничных, аэропортовых и внешних сетевых средах. Эта модель особенно ценна там, где ограничены дополнительные клиенты или специальные UDP-порты.
IKEv2/IPsec позиционируется для работы с нативными клиентами операционной системы
IKEv2/IPsec подходит для модели корпоративного удалённого доступа, совместимой с нативными VPN-клиентами операционной системы. На таких платформах, как Windows, macOS, iOS и Android, он может уменьшить дополнительные сложности пользовательского опыта. В сценариях, где мобильные пользователи меняют сеть, архитектура IKEv2 выгодна с точки зрения переподключения.
Условный доступ AAM привязывается к решению об открытии туннеля
VPN-соединение может оцениваться вместе с политикой условного доступа AAM. Идентичность пользователя, членство в группе, исходный IP, временное окно, доверие устройства и сигналы риска включаются в процесс принятия решения до открытия туннеля. Этот подход выводит VPN из роли открытой двери на сетевом уровне. Решение о доступе ограничивается контекстом пользователя и устройства.
Движок MFA обеспечивает общий слой доверия и при VPN-доступе
Подход TR7 AAM к MFA может использоваться как общий фактор доверия, применяемый и к решению о VPN-доступе. Такие методы, как TOTP, SMS OTP или e-mail OTP, усиливают проверку пользователя. Модель доверенного устройства или проверки на основе риска позволяет сбалансировать пользовательский опыт и безопасность. Так снижается потребность эксплуатировать отдельную инфраструктуру MFA для VPN.
Корпоративный каталог и федеративные источники объединяются в едином движке идентичности
AAM обладает моделью поставщика идентичности, способной работать с источниками LDAP/AD, RADIUS, OIDC, SAML и локальными пользователями. VPN-доступ не рассматривается как отдельная база пользователей или отдельный остров идентичности. С какой идентичностью пользователь уже управляется в организации, к тому же контексту идентичности привязывается и решение об открытии туннеля. Эта структура упрощает управление жизненным циклом пользователя.
Доступ к сети на основе групп сужает область сегментов
То, к каким сетевым сегментам может получить доступ пользователь, может быть связано с членством в группе или политикой пользователя AAM. Команду финансов можно направить только к финансовым системам, подрядчика только к проектным сервисам, команду DevOps только к среде разработки. Эта модель снижает ошибку предоставления доступа ко всей сети после открытия VPN. Доступ к туннелю превращается в сегментный контроль на основе идентичности.
Доверие устройства ETM разделяет корпоративные и личные устройства
Сигналы постуры устройства ETM могут использоваться для разделения управляемых и неуправляемых устройств при доступе к туннелю. Шифрование диска, защитное ПО, статус патчей или сигналы корпоративного управления могут влиять на уровень доступа. Доверенное устройство можно направить к полной сети, а устройство с низким доверием только к ограниченным корпоративным сервисам. Этот подход делает риск устройства видимым при удалённом доступе.
Аудиторские записи делают VPN-доступ отслеживаемым в контексте пользователя
VPN-сессии могут быть привязаны к аудиторскому следу через такие поля, как идентичность пользователя, исходный IP, время сессии, длительность соединения и результат политики. Эти записи могут передаваться в поток SIEM и коррелироваться с событиями безопасности. Операционная команда может видеть не только то, что соединение было открыто, но и с какими решениями о доверии оно было открыто. Эта видимость критична для соответствия и расследования инцидентов.
Решения о split tunneling и полном туннеле привязываются к политике
Split tunneling обеспечивает прохождение через туннель только корпоративных диапазонов IP или определённых сервисов. Полный туннель же переносит весь клиентский трафик на корпоративную точку прохода. Какая модель применяется, может определяться в зависимости от группы пользователя, доверия устройства, локации или уровня риска.
Завершение сессии может отозвать доступ в зависимости от риска
Если постура устройства ухудшается во время соединения, меняется оценка риска или нарушается политика пользователя, необходимо разорвать сессию или запросить повторную аутентификацию. Архитектура TR7 AAM связывает это решение с моделью условного доступа и аудита. Этот подход выводит VPN-доступ из роли постоянного канала, забытого после однократного открытия. Доступ должен оставаться наблюдаемым и отзываемым на протяжении всей сессии.
Операционная глубина
В архитектуре SSL VPN и IKEv2 проверенные возможности идентичности AAM должны рассматриваться вместе с требованиями к эксплуатации туннеля.
Проверенная основа AAM
Поставщики идентичности, MFA, условный доступ и концепция постуры устройства ETM — это надёжная основа этой страницы. Главное сообщение страницы в том, что VPN привязывается к этому движку доступа. Протокол туннеля позиционируется как канал, по которому применяется решение об идентичности и политике.
Портовая модель SSL VPN
Подход SSL VPN позиционируется через TLS 1.2+ и порт 443. Это даёт преимущество с точки зрения доступа из ограниченных сетей. Удобство прохождения в средах корпоративных межсетевых экранов и прокси — практическое преимущество, выделяющее его по сравнению с IKEv2.
Требования IKEv2 к межсетевому экрану
В модели IKEv2/IPsec критическими становятся порты UDP 500 (IKE) и UDP 4500 (NAT-T), поведение NAT-T и разрешения межсетевого экрана. По сравнению с SSL VPN вероятность блокировки в некоторых ограниченных сетях выше. Поэтому SSL VPN и IKEv2 — взаимодополняющие варианты для разных условий доступа.
Пул IP туннеля
В VPN-архитектуре необходимо планировать пул IP туннеля, выделяемый каждой сессии. При исчерпании пула новые соединения могут быть отклонены или поставлены в ожидание. Размер пула и модель управления должны конфигурироваться в зависимости от требований развёртывания.
DNS и split DNS
При VPN-доступе может потребоваться, чтобы корпоративные домены шли через внутренний DNS, а другие домены через внешнее разрешение. Split DNS — естественное дополнение проектирования split tunneling. Это поведение зависит от архитектуры развёртывания и конфигурации политики.
Планирование MTU и MSS
Протоколы туннелирования создают дополнительные накладные расходы на заголовки. Настройка MTU/MSS важна особенно для производительности IPsec ESP и TLS-туннеля. Неправильные настройки могут вызвать фрагментацию, низкую пропускную способность или проблемы соединения в некоторых приложениях.
Поведение HA и failover
Когда шлюз AAM работает в паре, поведение failover для VPN-сессий зависит от технологии туннеля. Со стороны IKEv2 архитектура мобильного переподключения может быть выгодной; со стороны SSL VPN проектирование VIP и непрерывности сессии должно рассматриваться отдельно.
В каких сценариях применяется
Корпоративный SSL VPN-доступ для удалённого сотрудника
Пользователь, работающий из дома или из поездки, проверяется через AAM с корпоративной идентичностью и MFA. Если доверие устройства ETM достаточно, предоставляется доступ к сервисам интранета через SSL VPN; на личных устройствах доступ ограничивается более узкими сегментами.
IKEv2-доступ для мобильной полевой команды
Полевой техник может подключаться к корпоративной сети с помощью нативного IKEv2-клиента на своём мобильном устройстве. Если устройство имеет управляемый профиль и высокую оценку доверия ETM, предоставляется более широкий доступ; при смене сети подход IKEv2 более подходит для мобильного использования.
Доступ с ограничением по времени к проекту для подрядчика
Стороннему подрядчику назначается учётная запись и ограниченная группа, действующие только на время проекта. VPN-доступ открывается только к сегменту, где расположены проектные корпоративные сервисы, и все сессии привязываются к аудиторской записи.
Контролируемый удалённый доступ к сети OT и SCADA
Инженер промышленной автоматизации получает VPN-политику с доступом только к OT-сегменту. Условный доступ ограничивает решение по рабочему времени, группе пользователя, исходному IP и доверию устройства; широкий доступ к общей корпоративной сети не предоставляется.
Часто задаваемые вопросы
Как выбрать между SSL VPN и IKEv2/IPsec?
Нужен ли для VPN-соединения отдельный сервер RADIUS?
Как MFA включается в VPN-соединение?
Как постура устройства ETM влияет на решение о туннеле?
В чём разница между split tunneling и полным туннелем?
Может ли активная VPN-сессия быть разорвана во время соединения?
Управляйте VPN-доступом с помощью идентичности и доверия устройства
Взгляните на архитектуру, объединяющую туннели SSL VPN и IKEv2 с движком идентичности AAM, MFA и постурой устройства ETM. Проведём вас по живой установке в вашей собственной среде.