ТЗ на Secure Web Gateway: SSL inspection, категории и AD

Что решает Secure Web Gateway простыми словами

Secure Web Gateway (SWG) - это контрольный пункт для веб-трафика сотрудников. Он проверяет, куда пользователь идет в интернете, что скачивает и какие данные пытается отправить наружу, и блокирует то, что нарушает правила компании. В ТЗ на SWG важно описывать не бренд, а задачи, риски и ожидаемый результат.

SWG закрывает самые частые угрозы: фишинг (кража паролей), вредоносные сайты и загрузки, а также случайные утечки, когда сотрудник отправляет данные в личные облака или на внешнюю почту. Типичный сценарий из жизни: сотруднику приходит письмо со "счетом", он открывает ссылку, сайт выглядит как обычный портал, но на самом деле собирает логины и пароли. SWG может остановить переход еще до ввода данных или предупредить пользователя.

Один антивирус на ПК проблему не закрывает. Часть атак работает через браузер и социальную инженерию, без "классического" файла. Плюс доступ в интернет идет не только с корпоративных ПК: BYOD, подрядчики, терминальные сессии, временные устройства. Поэтому нужен контроль именно на уровне веб-доступа.

Фильтрация в SWG обычно строится в несколько слоев: блокировка по URL и доменам, фильтрация по категориям (соцсети, азартные игры, взрослый контент, анонимайзеры и т.д.), а также контроль веб-приложений. Например, можно разрешить Teams, но запретить загрузку файлов в личные облака.

По размещению SWG бывает разным: в головном офисе (прокси/шлюз), в филиалах (локальный узел или туннель в центр), для удаленных сотрудников (агент или принудительный прокси). В ТЗ лучше сначала зафиксировать, где стоит решение и кого именно оно защищает, и только потом уходить в детали SSL inspection и политик.

FortiProxy, Blue Coat и on-prem альтернативы: как сравнивать

Перед тем как сравнивать FortiProxy, Blue Coat и другие варианты, определитесь с форматом: on-prem, облачный сервис или гибрид.

On-prem обычно выбирают, когда важны полный контроль, локальное хранение логов, предсказуемая задержка и требования к размещению данных. Облако чаще удобнее там, где много филиалов, нет желания обслуживать железо, а масштабирование нужно быстро.

Сравнивайте решения по тому, как они закрывают ваши реальные сценарии (офис, филиалы, удаленные сотрудники, гостевой Wi‑Fi, серверные сегменты) и как будут расти через 1-2 года.

Практичные критерии, которые стоит одинаково проверить у всех вариантов:

• Производительность: пропускная способность с включенным SSL inspection, а не только "на бумаге".
• Масштабирование: кластер, отказоустойчивость, распределение по площадкам.
• Политики: категории, исключения, расписания, разные правила для групп.
• Интеграции: AD/LDAP, прокси-авторизация, SIEM, DLP (если нужно).
• Эксплуатация: отчеты, обновления баз, поддержка и время реакции.

Отдельно разберите лицензирование. У одних решений лимит идет по пользователям, у других - по скорости, у третьих - по модулям (фильтрация, SSL inspection, sandbox). В ТЗ фиксируйте, что должно входить в поставку и какие ограничения неприемлемы (например, "SSL inspection только до N Мбит/с" или "категории доступны только в дорогом пакете").

Заранее учтите требования ИБ и внутренних регуляторов без привязки к конкретным нормам: где хранятся логи, кто имеет доступ к расшифрованному трафику, как оформляются исключения, как подтверждается целостность журналов. Если планируете on-prem, полезно сразу заложить требования к площадке и железу. Эту часть часто закрывают системные интеграторы - от подбора серверов и схемы включения до эксплуатации.

Какие исходные данные собрать до написания ТЗ

Хорошее ТЗ на Secure Web Gateway начинается не с выбора FortiProxy или Blue Coat, а с исходных вводных. Без них требования к SSL inspection, категориям и логам получаются либо слишком общими, либо невыполнимыми.

Сначала зафиксируйте, сколько у вас пользователей и где они работают: головной офис, филиалы, удаленка, подрядчики. Важно описать не только "400 человек", но и картину доступа: у кого постоянный VPN, у кого прямой выход в интернет, есть ли отдельные сети для гостей и Wi‑Fi.

Дальше нужны цифры по нагрузке. Попросите у сетевой команды хотя бы оценку пикового трафика и доли HTTPS. Отдельно отметьте "тяжелые" сценарии: видеоконференции, обучение с видео, большие загрузки, обновления ПО. Это напрямую влияет на производительность расшифровки и на то, где ставить шлюз.

Отдельным блоком опишите критичные бизнес-сервисы: госпорталы, интернет-банкинг, облака, CRM, почта, бухгалтерия. В ТЗ полезно сразу указать, что для таких сервисов важнее: доступность, минимальная задержка или полное логирование.

И наконец - что уже есть в инфраструктуре и как это должно работать вместе. Обычно это Active Directory (структура OU/группы), SIEM (какие события нужны и как быстро), DLP/EDR (нужна ли корреляция по пользователю), DNS-фильтрация или существующий прокси. Короткий пример: если филиалы выходят в интернет через разные каналы, а AD единый, это сразу задает требования к идентификации пользователей и к сбору логов в одном месте.

SSL inspection: что обязательно описать в требованиях

SSL inspection почти всегда становится самым спорным пунктом. Без него фильтрация во многом слепая, а с ним появляются вопросы к приватности, совместимости и нагрузке. В требованиях важно заранее зафиксировать, какой контроль вы хотите, а где вы осознанно делаете исключения.

Сначала опишите режимы расшифровки. Обычно выбирают один вариант или сочетание:

• полная расшифровка всего HTTPS;
• выборочная расшифровка по группам пользователей;
• расшифровка только для категорий риска (вредоносные сайты, анонимайзеры, фишинг, недавно зарегистрированные домены).

Укажите, должны ли разные подразделения иметь разные режимы.

Дальше - сертификаты. Пропишите, кто выпускает корпоративный корневой сертификат, как он распространяется на Windows, macOS, мобильные устройства и тонкие клиенты, как часто делается ротация и что считать успехом (например, процент устройств с корректным доверием). Отдельно отметьте требования к поддержке современных TLS-версий и к обработке ошибок.

Исключения лучше описывать не "по просьбе", а по правилам. Например, интернет-банк, медицинские порталы и личные кабинеты с чувствительными данными могут идти в bypass, но с сохранением факта доступа и базовых метаданных. Зафиксируйте и обратную ситуацию: какие категории запрещено исключать.

Чтобы не спорить после внедрения, добавьте измеримые требования:

• допустимая задержка на запрос и рост времени загрузки страниц;
• максимальная нагрузка по одновременным сессиям и трафику;
• что и как измеряется на пилоте (до и после включения расшифровки).

Отдельным пунктом закрепите приватность: какие поля попадают в логи при SSL inspection, кто имеет доступ к расшифрованным данным, как долго хранить журналы и как фиксировать выдачу доступа. Пример формулировки: "контент не сохранять, хранить только метаданные и категорию; доступ к логам - только ИБ по заявке с регистрацией".

Категории, политики и правила доступа

В требованиях важно описать не только "что блокируем", но и "для кого" и "когда". Иначе один поставщик настроит все по категориям, другой - по спискам доменов, а на приемке результаты окажутся несопоставимыми.

Минимальный набор категорий и логика решений

Начните с базовых классов и укажите действие для каждого: блокировать, предупреждать, разрешать с логированием. Обычно в стартовый набор входят вредоносные и зараженные ресурсы, фишинговые страницы, анонимайзеры и обходные сервисы, контент 18+ и азартные игры. Социальные сети и развлекательные платформы часто не запрещают полностью, а ограничивают по времени или режиму.

Обязательно пропишите поведение при "неизвестной категории" и при ошибке классификации: что делать, если SWG не смог определить сайт или отнес его не туда.

Дальше опишите политики по группам. Примеры:

• бухгалтерии - доступ к банкам и госресурсам, но жестко закрыть файлообменники;
• ИТ - доступ к документации и репозиториям, но с контролем загрузок;
• гостям - ограниченный доступ по простому набору правил;
• учебным классам - запрет соцсетей, но доступ к обучающим платформам.

Отдельным пунктом добавьте пользовательские категории и списки: домены вашей организации, партнеров, критичные SaaS-сервисы. Укажите, кто имеет право добавлять записи и как быстро изменения должны вступать в силу.

И не забудьте про расписания. В ТЗ стоит зафиксировать разные режимы (рабочие часы, экзамены, сменный график) и что меняется: категории, лимиты или доступ по спискам.

Исключения: как не превратить безопасность в хаос

Исключения неизбежны: часть сайтов ломается на проверке, часть нужна для бизнеса прямо сейчас. Проблемы начинаются, когда исключения появляются "на словах" и живут годами. В требованиях лучше сразу описать не только технические флаги, но и правила управления ими.

Белые списки: кто и на сколько

Попросите, чтобы любое добавление в белый список проходило согласование и имело срок действия. Простая схема обычно работает надежнее всего: инициатор (бизнес), согласующий (ИБ), исполнитель (администратор SWG). По окончании срока исключение либо продлевают с обоснованием, либо удаляют.

Чтобы это было проверяемо, закрепите минимальные требования к заявке на исключение: что именно исключаем (домен/URL/категория/приложение), причина и ожидаемый риск, срок действия и владелец исключения, кто согласовал и когда, как проверить, что исключение все еще нужно.

SSL inspection: исключения для "ломающихся" сервисов

Некоторые критичные сервисы не переживают расшифровку трафика (например, из-за certificate pinning или специфичных клиентов). В ТЗ зафиксируйте, что такие исключения должны быть точечными: по конкретным доменам и группам пользователей, а не "выключить SSL inspection всем".

Отдельно опишите временный обход (break-glass): кто имеет право включить его ночью или в филиале, на какой максимум срок (например, 1-4 часа), и что обязательно фиксируется в журнале.

И запретите "теневые исключения": никаких локальных правок на местах, ручных правил в браузерах и отдельных прокси в филиалах. Все изменения - только через центральное управление, с логированием и отчетом по внесенным правкам.

Логирование, отчеты и расследования

Если в требованиях заранее не определить, какие данные попадут в логи, легко получить красивые отчеты без ответа на простой вопрос: кто, куда и зачем ходил.

Минимальный набор полей, который стоит требовать для каждого события (разрешено, заблокировано, предупреждение): пользователь (или технический идентификатор, если пользователь не определен), группа (из AD или локальная роль), URL и домен (плюс IP назначения), категория и причина срабатывания (категория/репутация/правило), действие (allow/block/monitor), время, источник (IP, филиал/площадка).

Дальше задайте правила хранения и доступа. Пропишите срок хранения (например, рабочие логи 90 дней, архив 1 год) и кто имеет право смотреть логи и выгружать их. Отдельно укажите аудит действий администраторов: кто менял политики, кто добавлял исключения, кто удалял данные.

Отчеты лучше описывать как список задач, а не общими словами: топ блокировок по пользователям и группам, попытки обхода (прокси, анонимайзеры, неизвестные категории), всплески по подозрительным категориям. Уточните периодичность (ежедневно/еженедельно) и формат выгрузки.

Для расследований полезна интеграция с SIEM: какие события отправлять, в каком формате (например, syslog CEF/LEEF или JSON), с какой частотой и с синхронизацией времени. Пример: если бухгалтерия внезапно делает десятки запросов к недавно зарегистрированным доменам, по логам должно быть видно пользователя, группу, категорию, правило и точное время, чтобы быстро поднять цепочку событий.

Требования к хранению данных формулируйте аккуратно: укажите, что срок и место хранения должны соответствовать внутренним политикам и применимым нормам, без обещаний про конкретные статьи и сроки, если они не подтверждены юристами.

Интеграция с AD: пользователи, группы и SSO

Если не описать, как SWG узнает пользователя, отчеты будут по IP-адресам, а дальше начнутся споры уровня "это был не я". Начните с модели идентификации и проверьте, подходит ли она для филиалов, NAT и удаленных сотрудников.

Чаще всего используют один вариант или комбинацию: SSO через Kerberos/NTLM (прозрачная авторизация в домене), агент на ПК для передачи пользователя и группы, прокси-авторизация (explicit proxy) с доменной учеткой, captive portal для редких случаев и гостевых устройств.

Дальше важно описать привязку политик к структуре AD. Укажите, какие группы или OU считаются источником прав, и что делать при конфликте (например, пользователь в двух группах). Полезно сразу зафиксировать принцип: доступ определяется по группе, а не по должности в названии учетной записи.

Отдельный пункт - отказоустойчивость. Пропишите, что происходит, если контроллер домена недоступен: разрешать только базовые категории, переводить в карантинную политику или блокировать все, кроме критичных сервисов. Также укажите требования к кэшу учетных данных и сроку его жизни.

Для гостей и подрядчиков задайте отдельный контур: отдельные учетные записи, отдельная политика, короткий срок действия и простая процедура отключения.

В журналировании зафиксируйте, что должно писаться: пользователь, группа, устройство, IP до и после NAT, филиал или площадка. Пример: в филиале 200 человек выходят в интернет через один белый IP, и без связки "user + workstation + источник" расследование превращается в угадайку.

Пошагово: как оформить ТЗ, чтобы его не трактовали по-разному

Начните с одной страницы "границы проекта": что именно считается Secure Web Gateway в вашем случае (веб-доступ сотрудников, доступ серверов в интернет, гостевая сеть), а что не входит (например, почта или DLP, если это отдельные системы). Это сразу снимает лишние ожидания.

Дальше фиксируйте требования в одинаковой форме: "сценарий -> правило -> ожидаемый результат -> как проверяем". Когда подрядчик видит критерий проверки, трактовок становится меньше.

1) Опишите структуру ТЗ (коротко и по делу)

Удобно держать документ в пяти блоках:

• Роли и права: кто администратор, кто только смотрит отчеты, кто утверждает исключения и в какие сроки.
• Сетевые сценарии: явный прокси, прозрачный, через PAC, работа через VPN и вне офиса.
• Отказоустойчивость: кластер/резерв, где хранятся настройки, что происходит при падении узла, возможны ли обновления без простоя.
• Приемка: список тестов и формат отчета по результатам.
• Документация и обучение: какие инструкции нужны и кого обучать.

2) Сразу зафиксируйте приемочные проверки

Фраза "должно работать стабильно" на приемке не помогает. Лучше перечислите тесты, которые подрядчик обязан выполнить вместе с вами, и что считается "пройдено":

• Доступ по категориям: 5-10 тестовых сайтов в разрешенных и запрещенных категориях.
• SSL inspection: проверка для выбранных групп и проверка исключений (например, банки/госуслуги, если так решено).
• Идентификация пользователя: корректное определение пользователя/группы (AD) и применение нужной политики.
• Логи и отчеты: видны пользователь, сайт, категория, действие, причина блокировки; есть выгрузка за период.
• Отказ узла: при сбое одного устройства трафик продолжает идти по заданному сценарию.

В конце добавьте "пакет запуска": схемы включения, резервное копирование конфигурации, регламент обновлений и короткое обучение для админов и службы ИБ. Без этого даже хорошее решение внедряется болезненно.

Частые ошибки в ТЗ на SWG и к чему они приводят

Самая дорогая ошибка - писать ТЗ на Secure Web Gateway как набор общих пожеланий. Формулировки вроде "фильтровать опасные сайты" или "вести логи" звучат понятно, но на приемке превращаются в спор: что именно считается "опасным", какие логи нужны, за какой срок, с какой детализацией и у кого доступ.

Часто проблемы начинаются на включении SSL inspection. Если в требованиях не указать ожидаемую долю HTTPS, требования к производительности и допустимую задержку, после запуска можно получить жалобы "интернет тормозит" и неожиданные сбои в корпоративных сервисах.

Ошибки, которые чаще всего приводят к хаосу в эксплуатации:

• Нет измеримых критериев приемки (скорость, покрытие категорий, полнота логов) - подрядчик "сдал", а пользоваться неудобно.
• SSL inspection включили без оговорок по исключениям - ломаются банковские кабинеты, медсервисы, обновления ПО.
• Не прописан процесс исключений - начинается поток "разблокируйте", а решения остаются в чатах без следов.
• Не учтены филиалы, NAT и цепочки прокси - в логах видно только внешний IP, расследования упираются в "кто это был".
• Смешаны роли и права - админы меняют политики без согласования, и никто не понимает, почему вчера работало, а сегодня нет.

Хорошее ТЗ заранее фиксирует: кто утверждает исключения, как они документируются, какие изменения требуют согласования и как проверяется, что правила применяются к пользователю, а не к "безымянному IP".

Короткий чек-лист: все ли вы включили в ТЗ

Перед тем как отдавать требования на согласование и закупку, пройдитесь по короткому списку. Он помогает быстро проверить, что документ читается одинаково и безопасниками, и ИТ.

• Контекст и масштабы: сколько пользователей и устройств, где площадки и каналы связи, филиалы и удаленные сотрудники, какие сервисы критичны (банк-клиент, ЭДО, гос-порталы, облака).
• Политики доступа: какие категории разрешены и запрещены, какие правила по группам Active Directory, нужны ли расписания (например, соцсети только в обед), как обрабатывать гостей и BYOD.
• SSL inspection: какой режим нужен (полный, выборочный, только для риск-категорий), какие исключения обязательны (медицина, банки, личные кабинеты), кто выпускает и устанавливает сертификат, какие допустимы задержки и ошибки (например, не ломать видеозвонки).
• Логирование и отчеты: какие поля фиксировать (пользователь, группа, URL, категория, действие, причина блокировки), срок хранения, кто имеет доступ, нужна ли интеграция с SIEM.
• Приемка: тест-план и критерии "готово" (проверка категорий, идентификация пользователя из AD, работа исключений, качество отчетов, стабильность под нагрузкой).

Если хотя бы один пункт описан общими словами, на внедрении это почти неизбежно превращается в споры. Лучше один раз уточнить формулировки в требованиях, чем потом исправлять политики в бою.

Пример сценария: SWG для 400 пользователей и нескольких филиалов

Компания на 400 сотрудников работает в головном офисе и 6 филиалах. Интернет выходит через единый канал в ЦОД, учетные записи и группы ведутся в одном Active Directory. Задача - описать в ТЗ понятные правила доступа, чтобы филиалы не жили на "ручных исключениях", а ИБ могла быстро разбирать инциденты.

Политики удобнее задавать не "по отделам на бумаге", а по AD-группам, которые отражают реальную работу: офисные пользователи (стандартный доступ и строгая блокировка риск-категорий), колл-центр (только CRM, почта, база знаний и разрешенные сайты), ИТ (расширенный доступ плюс контроль загрузок), подрядчики ("только необходимое" и ограничение по времени). Для филиалов важно сохранить те же правила, но с отдельной видимостью в отчетах по площадкам.

SSL inspection в таком сценарии чаще всего нужен выборочный. В ТЗ стоит описать, что расшифровка включается для категорий с высоким риском (новые домены, анонимайзеры, файлообменники, вредоносные/фишинговые ресурсы), а для чувствительных сервисов задаются исключения. Типичный подход: не расшифровывать интернет-банкинг, госпорталы, медицинские и другие сайты, где важна конфиденциальность или возможны проблемы из-за pinning. И отдельно зафиксировать, кто утверждает список исключений и как часто он пересматривается.

Отчеты лучше разделить по аудитории. Руководству обычно нужен короткий еженедельный срез (топ категорий, блокировки, тренды по филиалам). ИБ и администраторам нужны ежедневные детали: события SSL inspection, попытки обхода, загрузки исполняемых файлов, новые домены, поиск по пользователю и устройству.

Перед вводом в эксплуатацию включите проверки приемки, чтобы не поймать проблемы в рабочий день:

• тест-доступ к ключевым бизнес-сайтам и госресурсам из офиса и филиалов;
• проверка SSO/аутентификации и правильного определения групп из AD;
• контроль, что исключения SSL не расширены больше необходимого;
• сверка логов: есть пользователь, группа, сайт, действие, причина блокировки;
• нагрузочное тестирование на пиковое время и план отката на случай сбоев.

Следующие шаги после ТЗ: пилот, внедрение и поддержка

После согласования ТЗ важно сразу определить, кто принимает решения и кто отвечает за ежедневную работу. Обычно нужны три роли: ИБ формулирует правила и риски, ИТ отвечает за сеть, сертификаты и интеграции (например, с AD), а бизнес подтверждает, что доступ к нужным сайтам и сервисам не ломается.

Начинать лучше с пилота на небольшой группе пользователей, а не включать фильтрацию сразу на всю компанию. На пилоте быстро всплывают реальные исключения (банки, гос-порталы, специфические SaaS), нюансы SSL inspection и требования к отчетам.

Как провести пилот, чтобы он дал результат

• Выберите 30-50 пользователей из разных отделов и 1-2 типовых филиала.
• Включите базовые категории и одну-две политики по группам AD.
• Проверьте SSL inspection на критичных сервисах и оформите исключения письменно.
• Сверьте логи: видно ли пользователя, группу, URL, категорию, действие, причину блокировки.
• По итогам зафиксируйте изменения в политиках и требованиях к отчетности.

Перед внедрением подготовьте инфраструктуру: где будет стоять решение (on-prem), как трафик попадет на SWG (явный прокси или прозрачный режим), какие нужны сертификаты для расшифровки, и какое резервирование требуется. Если планируется высокая доступность, уточните схему переключения и что будет при отказе узла.

Дальше нужен понятный план поддержки: частота обновлений категорий и сигнатур, порядок разбора инцидентов, регламент запроса исключений, сроки реакции и формат регулярных отчетов.

Если не хватает ресурсов или экспертизы, часть задач можно отдать системному интегратору: проектирование on-prem SWG, подбор серверов и схемы включения, интеграция с Active Directory и организация логирования. Например, GSE.kz (gse.kz) как производитель серверов и системный интегратор в Казахстане может собрать инфраструктуру под требования и обеспечить поддержку после запуска.