В корпоративной среде прокси-сервер обычно воспринимают как что-то фоновое: он просто есть, где-то работает, пропускает трафик и редко попадает в поле зрения пользователей — до тех пор, пока что-нибудь не перестает открываться. Но на практике его роль куда шире. Особенно если речь идет уже не просто о прокси, а о Secure Web Gateway.
Меня зовут Михаил Левин, я администратор сети группы сетевой безопасности SM Lab. В этой статье расскажу, что такое прокси-сервер, чем он отличается от SWG, какие решения есть на рынке и как вся эта схема работает в компании.
Что такое прокси-сервер
Если говорить в целом, прокси-сервер — это посредник между пользователем и внешним ресурсом.
Когда пользователь открывает какой-либо сайт, его запрос идет не напрямую в интернет. Сначала трафик отправляется на прокси-сервер, а уже затем прокси перенаправляет его во внешнюю сеть и возвращает ответ обратно пользователю. То есть прямого выхода в интернет у пользователя в этой схеме нет.
Для компании такой подход дает сразу несколько возможностей.
Во-первых, можно разграничивать доступ сотрудников к интернет-ресурсам в зависимости от того, к каким группам Active Directory они относятся.
Во-вторых, появляется возможность выявлять подозрительные или запрещенные ресурсы и блокировать к ним доступ. По сути, анализируются страницы, к которым обращаются пользователи.
В-третьих, можно регулировать, какое программное обеспечение и какие расширения разрешено скачивать.
Кроме того, прокси-сервер позволяет кешировать обращения к сайтам, что помогает экономить трафик.
Как используют прокси-серверы
Прокси-сервер в компании может использоваться в двух основных режимах: явном и прозрачном.
Явный прокси-сервер
В случае с явным прокси настройки прописываются на устройстве пользователя. Их можно увидеть на компьютере сотрудника и проверить, что прокси действительно указан.
Настраивается это несколькими способами: либо через сценарий автоматической настройки, либо вручную. Как правило, такие параметры распространяются групповыми политиками, поэтому сотруднику ничего не нужно делать самостоятельно — все уже настроено заранее.
Прозрачный прокси-сервер
Во втором случае используется прозрачный прокси. Здесь на компьютере пользователя ничего не прописывается.
Когда сотрудник обращается к веб-ресурсу, его трафик сначала попадает на маршрутизатор, а затем перенаправляется на прокси-сервер с помощью протокола WCCP. В результате пользователь все равно выходит в интернет через прокси, но сам этого не видит.
Этот режим особенно полезен в тех случаях, когда указать прокси на устройстве нельзя или сделать это затруднительно. Например, речь может идти о серверах на Linux. Бывает и так, что само программное обеспечение не позволяет задать прокси-сервер — тогда прозрачный режим становится рабочим вариантом.
Почему прокси-сервера уже недостаточно
По факту прокси-сервер — это просто посредник между пользователем и интернетом. Этим его базовая роль и ограничивается.
Secure Web Gateway, или SWG, — это уже не просто посредник, а целый комплекс решений, предназначенных для обеспечения веб-безопасности сотрудников.
SWG включает все базовые возможности прокси-сервера, но дополнительно дает:
категоризацию ресурсов;
использование постоянно обновляемой базы сайтов с данными об их репутации;
проверку ресурса при обращении;
определение подозрительных сайтов;
выявление исполняемого кода;
обнаружение вредоносного ПО;
применение политик безопасности к трафику пользователей;
аналитику и мониторинг в реальном времени.
То есть обычный прокси просто пропускает пользователей в интернет через себя, а SWG уже помогает управлять этим доступом, контролировать его и снижать риски.
Чем SWG отличается от обычного прокси
Оба решения умеют перехватывать веб-трафик. Но дальше различия становятся принципиальными.
SSL-инспекция
У обычного прокси возможности SSL-инспекции ограничены.
Под SSL-инспекцией здесь имеется в виду возможность анализировать шифрованный трафик, проходящий к веб-ресурсам: понять, куда именно идет обращение, и на основании этого принять решение — разрешать его или нет.
Для SWG это штатный сценарий. А вот у обычных прокси-серверов при росте трафика, увеличении компании и масштабировании инфраструктуры могут возникать проблемы с производительностью.
URL-фильтрация
Если речь идет о URL-фильтрации, различие тоже заметное.
В SWG для этого используется полноценная база категорий и репутаций ресурсов. В обычном прокси все чаще сводится к белым и черным спискам, которые нужно поддерживать вручную. Для крупной компании это неудобный и плохо масштабируемый подход.
Защита от угроз
У обычного прокси нет полноценной защиты от фишинга и вредоносного ПО. В SWG такие механизмы входят в стандартный набор возможностей.
Режимы
Также важен вопрос прозрачного режима. В SWG такие сценарии реализуются, а в случае с обычными прокси могут быть ограничения.
Отчетность и аналитика
У обычного прокси нет той отчетности и аналитики, которую дает SWG.
Какие решения есть на рынке
Если говорить о практической стороне вопроса, на рынке есть несколько популярных решений.
Symantec Blue Coat SWG
В нашей компании используется коммерческое решение Symantec Blue Coat SWG.
Это решение для крупных компаний, мировой лидер в области Secure Web Gateway. По сути, оно умеет практически все — возможно, даже больше, чем нам требуется на практике.
Среди его возможностей:
полноценная инспекция трафика;
категоризация ресурсов;
постоянно обновляемые базы категорий сайтов;
работа в явном и прозрачном режиме;
качественная документация;
техническая поддержка.
Отдельно отмечу документацию: если нужно что-то настроить или разобраться, почему что-то сломалось, обычно можно найти описание, которое действительно соответствует реальной конфигурации. Если этого недостаточно, всегда можно обратиться в поддержку.
UserGate
Это уже не SWG в чистом виде, а Next Generation Firewall, то есть межсетевой экран нового поколения с функциями SWG.
Решение тоже ориентировано на крупные компании и считается лидером российского рынка. По набору функций оно умеет практически все то же самое, что и Symantec.
Но есть ограничения:
на текущий момент UserGate не умеет работать в прозрачном режиме;
документация не всегда соответствует тому, что должно быть;
с поддержкой тоже бывают нюансы.
При этом решение у нас закуплено, в прошлом году оно тестировалось, и по итогам можно сказать, что если с Symantec что-то случится, UserGate сможет его почти полноценно заменить.
Squid
Бесплатный опенсорсный прокси-сервер.
На этом его основные плюсы для крупных компаний, по сути, заканчиваются. Это действительно решение скорее для небольших офисов.
Squid умеет инспектировать HTTPS-трафик, но если через него пойдет большой объем трафика, сразу возникает вопрос, справится ли он.
При этом в Squid нет речи о категоризации ресурсов. Все строится исключительно на белых и черных списках. То есть автоматически определить, к какому типу относится ресурс, он не сможет.
Кроме того:
работает он только в явном режиме;
документация по сути сводится к форумам и тому, что удастся найти в интернете;
поддержки нет.
Проект живет за счет энтузиастов: когда у них есть время — они его поддерживают, когда времени нет — нет.
Как SWG работает в нашей компании
Теперь расскажу, как эта схема выглядит у нас.
Допустим, сотрудник хочет зайти на внешний сайт — например, на Asics, чтобы посмотреть модельный ряд конкурентов.
Первым делом его запрос идет на прокси-сервер.
Дальше прокси-сервер подменяет сертификат на доверенный. За счет этого становится возможной SSL-инспекция: трафик можно расшифровать и проверить.
С точки зрения пользователя все выглядит так, будто он обращается к сайту напрямую. На самом деле пользователь взаимодействует только с прокси-сервером, точнее с SWG, а уже SWG обращается к внешнему сайту от своего имени.
После получения запроса SWG:
проверяет группу AD, к которой относится сотрудник;
проверяет наличие ресурса в white list и black list;
определяет категорию ресурса;
устанавливает защищенное соединение с адресом назначения;
проверяет ресурс на наличие вредоносного ПО и кода;
и только после этого решает, открывать доступ или блокировать его.
Распределение прав доступа между сотрудниками
Прокси-сервер получает данные из LDAP, где хранится информация о пользователях и их принадлежности к группам. На этой основе сотрудники делятся на несколько групп:
администраторы магазинов;
директоры магазинов;
сотрудники со стандартным доступом;
сотрудники с расширенным доступом;
сотрудники без ограничений в доступе.
Формирование матрицы доступа
Дальше для групп задаются права по категориям ресурсов.
На стороне SWG есть набор категорий, и по каждой из них формируется матрица: какой группе доступ разрешен, а какой — запрещен.
Именно из-за этого периодически приходят заявки от пользователей в духе «я открываю сайт, а он не работает». В таких случаях смотрим на две вещи: к какой категории относится ресурс и в какой группе состоит пользователь. Иногда проблема решается не открытием конкретного сайта, а переводом сотрудника в другую группу с более широкими правами.
Анализ сторонних ресурсов
Каждое обращение к внешнему ресурсу сопровождается проверкой его категории.
SWG анализирует сайт и сопоставляет его со своей базой данных. В зависимости от результата ресурс попадает в ту или иную категорию.
Например, ресурс underlinestore.ru может по какой-то причине оказаться в категории Suspicious, то есть среди подозрительных сайтов. Это значит, что при анализе код или скрипты на сайте показались системе подозрительными, и ресурс был заблокирован.
Но на практике может оказаться, что это обычный сайт с одеждой, который нужен для работы. В таком случае в Blue Coat можно воспользоваться сервисом рекатегоризации ресурсов.
Для этого проверяется текущая категория сайта, после чего можно отправить заявку на ее пересмотр. Дальше ресурс проверяется на стороне Symantec, и затем приходит ответ:
либо категория меняется, например на Shopping, что соответствует сути сайта;
либо приходит отказ, и ресурс остается в прежней категории
Во втором случае уже приходится принимать решение внутри компании — внести сайт в whitelist или отказать сотруднику в доступе.
Внутренние политики безопасности SWG
Помимо категоризации и репутационных баз, в SWG действуют и внутренние политики безопасности — те, которые мы настраиваем сами.
Например, мы используем корпоративный браузер Mozilla Firefox. Для некоторых групп, как правило магазинных, использование других браузеров запрещено.
Если сотрудник магазина откроет Chrome или любой другой браузер, он получит сообщение с ошибкой. При этом мы получим информацию о том, какой пользователь выполнял действие, какой прокси-сервер ответил, в какой группе он состоит и что именно было запущено.
Есть и другие политики. Например, можно запретить скачивание определенных типов файлов, в частности, исполняемых файлов .exe.
Если сотрудник из группы с такими ограничениями попытается скачать подобный файл, система покажет блокирующее сообщение и откажет в доступе.
Что у нас под капотом
С технической точки зрения все начинается с объявления групп пользователей из Active Directory: директоры и администраторы магазинов, сотрудники со стандартным или расширенным доступом и так далее.
После этого для каждой группы формируются правила доступа.
Если взять для примера группу сотрудников со стандартными доступами, в которой состоит подавляющее большинство сотрудников, то для нее можно, например, разрешить категорию Finance. Это означает, что сайты из этой категории будут доступны.
Следующим шагом задается запрет по blacklist — списку ресурсов, который ведется вручную на основе внутренних политик безопасности.
Источники для такого списка разные. Иногда служба информационной безопасности просит заблокировать конкретные ресурсы. Иногда мониторинг показывает, что зараженный компьютер постоянно пытается обращаться к подозрительным сайтам, чтобы, вероятно, подтянуть что-то еще вредоносное. Такие ресурсы заносятся в blacklist, чтобы как можно раньше отсечь этот трафик.
Дальше идет запрет не категоризированных сайтов.
Проблема в том, что новые интернет-ресурсы появляются каждый день, и отслеживать и категоризировать абсолютно все сайты в режиме «секунда в секунду» невозможно. Поэтому существует категория ресурсов без категории. А там может оказаться что угодно: и нормальный сайт, и площадка с вредоносным ПО.
Поэтому такие ресурсы по умолчанию блокируются. Логика здесь простая: лучше сначала запретить неизвестное и потом обработать заявку на открытие доступа, чем сразу разрешить все подряд и позже разбирать последствия.
После этого составляется whitelist — список разрешенных ресурсов.
Он нужен, например, в такой ситуации: компания отправила заявку на рекатегоризацию ресурса, который считает безопасным и нужным для работы, но вендор ответил, что не считает его безопасным. Если внутри компании все же уверены, что угрозы нет, такой ресурс можно добавить в whitelist.
В этом случае SWG сначала проверит whitelist, а затем уже не будет смотреть на категорию сайта и просто пропустит пользователя к нему.
Дальше применяются остальные политики по категориям. Например, категория Suspicious, о которой говорилось выше, у нас запрещена.
Кроме blacklist и whitelist, есть еще один важный список — ресурсы, для которых не применяется SSL Interception.
Это нужно в случаях, когда внешний ресурс не допускает присутствия посредника между пользователем и сервером. С его точки зрения такое поведение может выглядеть как недоверенная схема или даже как попытка man-in-the-middle-атаки, поэтому запросы через прокси он может не принимать.
По такому сценарию часто работают банки. Поэтому Сбербанк, ВТБ, Юникредит и другие подобные ресурсы попадают в отдельный список: прокси не вмешивается в трафик, и пользователи могут обращаться к ним напрямую.
Часто по такому же принципу работает и государственный сектор: различные ведомственные и государственные сервисы. Поэтому такой список в инфраструктуре необходим.
Что будет, если пользователь отключит прокси
Теперь о практическом вопросе, который периодически всплывает в поддержке: что будет, если пользователь просто отключит прокси в настройках.
Кажется, что ничего сложного: открыл параметры, выключил — и пошел в интернет напрямую. Но реальная схема работает иначе.
Представим двух сотрудников: у одного прокси включен, у другого — нет.
Если прокси включен
Пользователь обращается к ресурсу и первым делом упирается в ближайший маршрутизатор.
На маршрутизаторе есть список доступа — это первый уровень ограничений. Конечно, в нем нельзя перечислить весь интернет, но можно разрешить доступ к локальным ресурсам компании и к самому SWG.
В итоге получается такая схема:
доступ к прокси-серверу разрешен;
корпоративные ресурсы живут вне прокси-сервера;
даже если прокси не работает, внутренние ресурсы компании все равно доступны;
выход во внешний интернет идет уже через прокси.
Если прокси выключен
Если пользователь отключает прокси, он точно так же сначала попадает на маршрутизатор.
Но дальше возникает проблема: какой бы внешний ресурс он ни попытался открыть — Яндекс, Asics, Госуслуги или что угодно еще, — этот доступ напрямую через сетевое оборудование не описан. В результате интернет у него просто не заработает.
При этом доступ к корпоративным ресурсам останется, потому что они разрешены отдельно.
Именно поэтому, когда в офисе у кого-то «не работает интернет», один из первых вопросов обычно звучит так: а настройки прокси-сервера у вас вообще прописаны?
Выводы
Если смотреть формально, прокси-сервер — это посредник между пользователем и интернетом. Но в корпоративной среде на одном только посредничестве далеко не уедешь.
Когда компании нужно не просто направлять трафик, а понимать, какие сайты посещают пользователи, проверять ресурсы, разграничивать доступ, применять политики безопасности, работать с категоризацией, SSL-инспекцией, аналитикой и мониторингом, на первый план выходит уже SWG.
Именно поэтому в крупной инфраструктуре разговор обычно идет не про «просто прокси», а про полноценный шлюз веб-безопасности, который становится одной из базовых точек контроля доступа в интернет.