О бедном гусаре замолвите слово… или Опять про защищённый веб-прокси

О бедном гусаре замолвите слово… или Опять про защищённый веб-прокси

Эта статья зародилась достаточно забавным образом. Мой многолетний друг и коллега Денис Батранков предложил мне её написать, конечно же, про межсетевые экраны нового поколения, они же ММЭ, они же NGFW. Так как они них не писал только ленивый, что греха таить, я тоже писал, то я предложил ему написать статью про SWG, они же защищённые веб-прокси. Денис подумал, сказал: «Ты будешь единственный» — и согласился. Подумал я после этого и решил начать статью с аналогий, а потом уж чуть больше про технику. 

Итак, давайте представим нашу инфраструктуру как город. У него есть Кремль, он же ЦОД. Он, кстати, может быть и облачным. По городу проложены широкие и ровные дороги, например, как местами в Москве. По ним можно быстро мчаться, что и делают наши NGFW, то есть прямо такие спортивные машины. Теперь же давайте представим, что этому NGFW понадобилось выехать из города. А там творится кошмар — грунты, болота, ямы и прочая беда. Чтобы не оторвать себе бесценные запчасти, наш NGFW вынужден ехать шагом, а то и просто проехать не может. И тут на помощь приходят иначе подготовленные машины — на больших колёсах, с лебёдками и прочим. Они, конечно, едут не особо быстро, но с существенно большей вероятностью довезут нас до цели. 

Как вы уже догадались, весь описанный выше кошмар и есть современный интернет, а пробирающийся через него специально подготовленный автомобиль — как раз наш SWG. Теперь посмотрим на эту историю чуть глубже с технической точки зрения. NGFW в первую очередь заточены на анализ, пусть и глубокий, транзитных соединений и, конечно, их фильтрацию. В том случае, если соединения оказываются сложными — зашифрованными, бинарный трафик (HTTP/3 он же QUIC), то NGFW должен работать или в упрощённом режиме, то есть ориентируясь, например, на репутационную аналитику или результаты частичной расшифровки трафика. Или, да, всё верно, переходить в режим фактически полного проксирования трафика, терминируя на себе соединение, анализируя его содержимое и потом уже фильтруя его или передавая дальше. Откровенно говоря, такой режим — это как раз езда на спорткаре по бездорожью. Причём с кучей дополнительных ограничений. Например, нет возможности полноценной трансформации контента, интерактивного взаимодействия с пользователем, контроля прикладных вызовов (API — Application Programming Interface), в том числе при их использовании для интеграции с облачными приложениями (SaaS — Software as a Service). Вот я фактически и определил тот перечень задач, для чего люди используют SWG. Грубыми мазками — это детальный контроль выезда туристов в дремучее болото, вернее выхода пользователей в интернет, а также детальное управление их взаимодействием с внешними сервисами. Вопрос же производительности и надёжности таких решений решается нескольким способами. Первый из них — это когда весь трафик летит в интернет и назад через NGFW, при этом тот трафик, который подлежит более детальному анализу, передаётся на группу веб-прокси, например используя политики маршрутизации (так себе вариант), или протокол WCCP (Web Cache Communication Protocol), разработанный компанией Cisco. Этот протокол позволяет выбрать в настройках NGFW определённые типы трафика, например HTTP, HTTPS, FTP, и, прозрачно для пользователя, переслать их на один прокси-сервер или их группу (рис. 1).

Рисунок 1. Этот протокол позволяет выбрать в настройках NGFW определённые типы трафика, например HTTP, HTTPS, FTP, и, прозрачно для пользователя, переслать их на один прокси-сервер или их группу.

При этом надо отметь, что это обеспечивает возможность глубокого анализа трафика HTTP/HTTPS без добавления излишней нагрузки на NGFW, но не решает множество вопросов, которые я упоминал выше. Например, контроль интеграций, интерактивное взаимодействие и работу с HTTP/3.

Поэтому сейчас прокси обычно используются во втором варианте — когда они настроены в явном режиме. То есть когда клиенты настроены так, чтобы посылать определённый тип трафика именно на прокси-серверы. Обычно это делается распространением специального файла PAC — proxy autoconfiguration. В целом этот файл может распространяться на компьютеры пользователей любым подходящим методом, начиная от групповых политик Windows, DHCP, DNS и заканчивая принудительным перенаправлением на тот же самый прокси для загрузки себе этого файла. И тут тоже встаёт вопрос производительности и отказоустойчивости группы прокси-серверов. Обычно он решается весьма просто: перед ними ставится балансировщик трафика. Тут надо отметить два интересных момента. Балансировщики могут быть сетевого и транспортного уровня, и тогда они просто распределяют трафик между серверами в группе. А также они могут быть прикладного уровня. Этот класс продуктов называется ADC — Application Delivery Controller. Они более интеллектуальны и могут перераспределять трафик между серверами на основании их текущей загрузки, доступности, времени отклика и ряда других параметров (рис. 2).

Рисунок 2. Продукты класса ADC — Application Delivery Controller — более интеллектуальны и могут перераспределять трафик между серверами на основании их текущей загрузки, доступности, времени отклика и ряда других параметров.

На практике же встречаются все варианты внедрений, описанные выше, а также их разнообразные гибриды. Есть и такие интересные внедрения, когда у нас выстраивается цепочка прокси, каждый из которых решает свой набор задач. Это бывает в ситуации, когда мы не хотим трогать текущие настройки прокси у клиентов, но при этом надо внести дополнительные уровни проверок, или же у нас есть несколько уровней размещений проксируемых ресурсов, как на схеме ниже (рис. 3).

Рисунок 3. Ситуации, когда мы не хотим трогать текущие настройки прокси у клиентов, но при этом надо внести дополнительные уровни проверок, или же у нас есть несколько уровней размещений проксируемых ресурсов.

Но давайте вернёмся к началу статьи. Как я уже говорил, NGFW — это в первую очередь про скорость и приемлемый анализ контента и контекста. SWG же — это про гибкость внедрения, глубину анализа, простоту интеграции с внешними решениями, такими как системы защиты от утечек (DLP — Data Leakage Prevention) или защиты от ВПО (вредоносного программного обеспечения), и возможность настроить контроль взаимодействия с фактически любыми внешними ресурсами, в том числе через API. Это, кстати, одна из причин, почему, если посмотреть внимательнее, именно SWG является ядром облачных центров обеспечения сетевой безопасности (SASE — Secure Access Service Edge), и один из методов подключения пользователей к нему как раз упомянутые выше PAC-файлы. И если мы уж заговорили про SASE, то можно вспомнить и другую интересную и популярную аббревиатуру ZTNA (Zero Trust Network Access) — и увидеть, что прокси играют свою роль и там, обеспечивая контроль доступа к ресурсам.

И вот, почти дописав эту статью, я вспомнил то, о чём забыл написать ранее, а именно о том, что прокси ещё и прекрасно интегрируется в любые системы корпоративной аутентификации, обеспечивая механизм для единого входа (SSO-Single Sing-On), в том числе к облачным сервисам SaaS.

Ну и напоследок одно наблюдение и пара практических выводов. Наблюдение такое: практически каждая крупная организация имеет в своей инфраструктуре как обычные межсетевые экраны (МСЭ), так и многофункциональные межсетевые экраны (ММЭ) и обязательно несколько прокси-серверов. И чем важнее для этой организации полноценный контроль взаимодействия пользователей с приложениями, как локальными, так и облачными, тем активнее они используют эти самые прокси. Так что наш практический вывод №1: ММЭ (NGFW), если нам нужно приемлемое решение по контролю трафика и нас не очень волнует полноценное управление содержимым и контекстом взаимодействия. И вывод №2: если волнует, то добавляем прокси «по вкусу», в нужных местах и в нужном количестве.

Кстати, чуть не забыл! Любые выводы прикольно подтверждать статистикой. Она широко доступна в интернете и гласит, что рынок NGFW в 2024 году был, по разным оценкам, от 4 до 6 млрд долларов и продолжает расти чуть больше чем на 10% в год. Рынок SWG же был в том же самом 2024 году примерно 12 млрд долларов с ожидаемым ростом около 15% в год, из которых половина внедрений — облачные сервисы. Так что даже не знаю теперь про правильность заголовка этой статьи — кто именно там «бедный гусар», а кто и «эскадрон гусар летучих».