Блокировки РКН и корпоративный VPN: как разграничить личный и рабочий трафик
Массовые блокировки подтолкнули сотрудников к VPN и прокси - часто к личным. Помогаем клиентам выстроить политику корпоративного VPN с разделением трафика.
Массовые блокировки РКН создают прецедент применения VPN и прокси в корпоративной среде
Примерно через неделю после начала масштабных блокировок у нас начались странные разговоры с клиентами. Не про AWS и не про перенос workloads - это мы уже обсуждали. Новая тема: «у нас сотрудники массово ставят VPN-приложения на рабочие ноутбуки, что с этим делать».
Вопрос логичный. Telegram заблокирован, часть сервисов нестабильна, люди хотят работать - и идут за решением туда, куда могут дотянуться: бесплатный VPN из App Store, расширение Hola в браузере, подписка на ProtonVPN с личной карты. ИТ-отдел об этом либо не знает, либо закрывает на это глаза, потому что людям надо как-то общаться с контрагентами.
С точки зрения информационной безопасности это ситуация неприятная. Не потому что сотрудники «нарушают», а потому что корпоративный трафик начинает ходить через инфраструктуру, о которой компания ничего не знает и контроля над которой не имеет.
Что конкретно происходит
Сотрудник ставит на рабочую машину VPN-клиент. После этого весь трафик с этой машины - включая подключения к корпоративным системам, почту, запросы к внутренним API - идёт через сервер этого VPN-провайдера. Бесплатные сервисы в большинстве своём зарабатывают на данных пользователей: это их бизнес-модель, и она прямо описана в условиях использования мелким шрифтом, который никто не читает.
Для физлица - его выбор. Для сотрудника на рабочем ноутбуке с доступом к корпоративным ресурсам - это передача потенциально чувствительных данных третьей стороне без ведома работодателя.
Отдельная история с расширениями типа Hola: там трафик пропускается не через централизованный сервер, а через машины других пользователей сети. То есть чужой трафик тоже идёт через корпоративный ноутбук. Это уже двустороннее веселье.
Почему запрет - не решение
Самый очевидный ответ - запретить сторонние VPN. Формально он правильный. Практически - не работает без нескольких условий.
Если сотруднику объективно нужен доступ к заблокированному ресурсу для работы (а Telegram в 2018 году - это не развлечение, это канал коммуникации с командой и клиентами у многих), и компания говорит «нельзя», но ничего не предлагает взамен - запрет либо игнорируется, либо человек использует личный телефон. Во втором случае корпоративных данных там, конечно, нет - но рабочие переписки и принятые решения есть, и теперь они вообще вне видимости компании.
Правильная логика: сначала дать инструмент, потом объяснить правила, потом - если нужно - ограничить альтернативы.
Как выстраиваем политику
С несколькими клиентами сейчас работаем над тем, что можно назвать политикой корпоративного VPN. Ключевое требование здесь - разграничение трафика: рабочий и личный не должны идти через одну и ту же точку выхода.
Корпоративный VPN только для рабочих ресурсов. Это split tunneling в терминах сетевой конфигурации: через VPN идут только обращения к корпоративной инфраструктуре, внутренним сервисам, почтовым серверам. Остальное - браузер, стриминг, личная почта - идёт напрямую через интернет-провайдера, минуя VPN. Это снижает нагрузку на канал и убирает ситуацию, когда весь трафик сотрудника оказывается в руках одной точки.
Личная жизнь сотрудника - не дело компании. Если человек хочет использовать личный VPN для личных задач на личном телефоне - это его выбор. Политика не должна пытаться регулировать это. Она должна регулировать рабочие устройства и рабочий трафик.
MDM как точка контроля. На управляемых устройствах - через Mobile Device Management или endpoint-политики - можно явно запретить установку VPN-клиентов из неодобренного списка, или настроить профиль так, что корпоративный VPN-профиль не позволяет переопределить маршруты нерабочего трафика. Это техническое закрепление политики, а не только документ.
Список одобренных инструментов. Что-то вроде корпоративного решения для конкретного кейса с Telegram - например, шлюзовой прокси только для одобренных приложений, без пропуска через него всего трафика. Некоторые клиенты разворачивают свой MTProxy или SOCKS5 на собственном VPS за рубежом - это хотя бы понятная инфраструктура под контролем компании.
Что сейчас делаем практически
Для клиентов на managed-сопровождении это выглядит как несколько шагов. Сначала аудит того, что уже стоит на устройствах: какие VPN-клиенты, расширения, прокси-настройки появились за последние недели. Потом - разговор с ответственными за ИБ о том, какие сценарии использования VPN легитимны с точки зрения бизнеса. Дальше - конфигурация одобренного инструмента и политика в MDM.
Это не сложная задача технически. Сложность в том, чтобы не сделать её чисто запретительной: когда ИТ-отдел просто выпускает директиву «VPN запрещён», не предложив ничего взамен, следующий шаг - люди переходят на личные телефоны, и контроль исчезает полностью.
Что неясно
Непонятно, как долго продолжатся блокировки в нынешнем масштабе. Если РКН найдёт другой способ достать Telegram, или суд что-то изменит, или Telegram сам договорится - часть запроса на VPN уйдёт. Но привычка к VPN у сотрудников уже формируется, и вопрос «а можно я буду использовать свой VPN для работы» никуда не денется.
Так что политика нужна в любом случае - не только на период блокировок.
- РКН блокирует миллионы IP: реестр зависимостей от SaaS и облачных API · 6 апреля 2018
- Роскомнадзор блокирует Telegram: заодно кладёт AWS и GCP · 3 апреля 2018