Контроль доступа сотрудников в интернет: как настроить правила для разных подразделений

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

Почему важен дифференцированный контроль доступа

Одинаковая политика доступа в интернет для всей компании всегда слишком груба. Если максимально ужесточить доступ к сайтам для всех, маркетинг потеряет часть рекламных и социальных платформ, разработчики — технические ресурсы, а HR — площадки для поиска кандидатов. Если открыть широкий доступ в интернет, становится сложнее контролировать внешние взаимодействия и передачу рабочих данных. Поэтому политику разумнее строить вокруг должностных задач, а не вокруг единого профиля «сотрудник».

Современный шлюз веб-безопасности позволяет настраивать доступ с учетом разных условий:

• Пользователь или группа. Правила можно применять к конкретному сотруднику, подразделению или группе пользователей.
• Ресурс. Учитываются категория сайта, конкретный домен или URL.
• Передаваемые данные. Можно учитывать типы файлов и заданные признаки HTTP-запросов и ответов, которыми сотрудник обменивается с внешними сервисами.
• Действия пользователя. Внутри разрешенного сервиса можно отдельно применять правила к загрузке и выгрузке файлов, отправке данных через веб-формы и другим операциям, которые различимы по признакам веб-трафика.
• Время подключения. Для отдельных ресурсов и групп можно задавать расписания и временные ограничения.

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

Для организаций и информационных систем, на которые распространяется приказ ФСТЭК России № 117, управление веб-доступом следует рассматривать в контексте требований к защите соответствующей информационной системы. Ограничение доступа в интернет на практике выстраивается как постоянный процесс с понятными правилами. Практический гайд поможет сопоставить задачи веб-доступа с применимыми требованиями и определить, какие меры стоит предусмотреть в инфраструктуре.

Получите практический ориентир по требованиям приказа ФСТЭК № 117. Скачайте гайд о защите веб-контура. В нем собраны практические ориентиры по вопросам интернет-доступа, внешних сервисов, ИИ, удаленной работы, мониторинга и подтверждения выполнения мер.

Скачать практический гайд

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

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

• Какие сайты, SaaS и облачные сервисы нужны для работы.
• Какие данные сотрудники могут передавать во внешние системы.
• Какие действия в этих сервисах необходимо разрешить или ограничить.

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

Точкой применения правил может быть прокси-сервер, но специализированный шлюз дает более гибкие возможности управления доступом. Интеграция с AD/LDAPMicrosoft Active Directory и протокол LDAP, используемые для централизованной работы с учетными записями и группами пользователей позволяет определять пользователя или его группу и автоматически применять нужную политику. Для SaaS это особенно важно: разрешить сам сервис недостаточно, если внутри него необходимо отдельно контролировать загрузку файлов, отправку данных и другие операции.

Основой политик могут служить:

• Организационная структура и группы AD/LDAP. Позволяют назначать разные правила подразделениям, ролям и группам сотрудников.
• Категории веб-ресурсов webCat и данные TI-фидов Solar 4RAYS. webCat помогает группировать ресурсы по категориям, а TI-фиды дополняют политики актуальными данными о фишинговых, вредоносных и других опасных ресурсах.
• Перечень разрешенных облачных сервисов. Определяет, какими внешними платформами сотрудники могут пользоваться в рабочих целях.
• Расписания. Позволяют задавать правила с учетом рабочего времени, отдельных временных интервалов и сроков действия исключений.
• Требования ИБ к загрузке и выгрузке файлов. В политике можно учитывать тип, размер и другие характеристики передаваемых файлов, а также направление их передачи.

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

Как настроить политику и ограничивать действия внутри сервисов

В Solar webProxyроссийское SWG-решение для управления интернет-доступом, защиты от веб-угроз и контроля веб-активности пользователей политика строится не как один общий список запретов, а как последовательность проверок. Администратор работает в разделе «Политика»: выбирает нужный слой — например, «Вскрытие HTTPS», «Перенаправление по ICAP», «Фильтрация запросов» или «Фильтрация ответов» — и задаёт правила для конкретного сценария.

Практически настройка сводится к трем шагам:

1. Выбрать слой, в котором нужно контролировать трафик. От этого зависит, какие условия и действия доступны.
2. Создать правило: определить, для кого и какого ресурса оно действует, какие признаки трафика или файла учитывать и что должна сделать система. При необходимости можно использовать исключения для отдельных случаев.
3. Сохранить изменения и применить политику. Порядок правил важен: внутри слоя сначала проверяются исключения, затем правила.

После сохранения изменения ещё нужно применить — только тогда новая версия политики начинает использоваться системой. При необходимости история политик позволяет посмотреть изменения и вернуться к предыдущей версии конфигурации.

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

Правило в Solar webProxy удобно описывать как сценарий: кто обращается к ресурсу, куда направлен запрос, какие признаки трафика или файла нужно учесть, когда действует правило и какое действие должна выполнить система. При этом одного универсального набора атрибутов для всех проверок нет — доступные параметры зависят от слоя политики и типа обрабатываемого трафика.

В политике можно использовать, в частности:

• пользователя, группу и другие признаки источника;
• адрес назначения, URL и категорию веб-ресурса;
• HTTP-методы и заголовки;
• ключевые слова в HTTP-запросах и ответах;
• MIME-тип, имя, расширение, размер и хеш файла;
• расписание и срок действия правила или исключения.

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

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

В интерфейсе критерии объединяются логикой «И» и «ИЛИ», поэтому правило можно сделать точнее простой проверки одного URL или одной категории.

Например, компании нужен облачный сервис, но загрузку ZIP-файлов в него требуется ограничить. Сам сервис можно оставить доступным, а для нужного трафика настроить SSL-инспекцию и правило фильтрации, которое учитывает направление передачи и признаки файла и при совпадении блокирует операцию. По той же логике можно отдельно работать с HTTP-запросами и ответами или направлять выбранные объекты на внешнюю проверку по ICAP.

Для архивов, содержимое которых нельзя проверить без пароля, можно отдельно задать обработку ошибки распаковки — например, блокировать передачу такого объекта. DPIанализ трафика на прикладном уровне для распознавания протоколов и приложений помогает распознавать приложения и протоколы на уровне L7, а по ICAP файлы можно направлять во внешние DLP, антивирусы и песочницы. Такой контроль веб-доступа позволяет оставить разрешенный сервис рабочим, но закрыть рискованную операцию.

Сделайте веб-доступ управляемым для каждого подразделения

Используйте Solar webProxy, чтобы централизованно задавать правила для пользователей и групп, управлять доступом к SaaS, облачным и ИИ-сервисам и применять политики к веб-трафику и передаваемым файлам.

Запросить консультацию

Гибкий конструктор политик в Solar webProxy

Специализированный SWGшлюз веб-безопасности, который применяет политики доступа и защиты к пользовательскому веб-трафику позволяет управлять веб-трафиком детальнее, чем фильтрация по URL. В Solar webProxy правила можно привязывать к категориям сайтов, пользователям и группам, содержимому трафика и отдельным ресурсам. Система работает с HTTP, HTTPS, FTP over HTTP и SOCKS5, а также анализирует запросы и ответы. Благодаря этому выход в интернет можно настраивать в соответствии с задачами конкретных подразделений и ролей.

Для применения и актуализации правил используются несколько компонентов:

• webCat. Распределяет веб-ресурсы по категориям и позволяет создавать пользовательские категории для внутренних политик.
• TI-фиды Solar 4RAYS. Дополняют категоризацию актуальными данными о фишинговых, вредоносных и других опасных ресурсах.
• MultiProxy. Централизует управление политиками для распределенной инфраструктуры и позволяет учитывать особенности отдельных филиалов.
• Endpoint Agent. Направляет веб-трафик рабочих станций Windows через назначенные узлы Solar webProxy, где к нему применяются политики системы.

Такой подход уменьшает зависимость от ручного ведения списков доменов и упрощает управление веб-доступом в распределенной инфраструктуре. MultiProxy используется для централизованного управления политиками на связанных узлах Solar webProxy, а Endpoint Agent — для направления веб-трафика рабочих станций Windows через назначенные узлы системы. История политики и контроль ее применения помогают отслеживать изменения конфигурации и проводить аудит.

Доступ должен следовать за ролью

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

Екатерина Черкасова

PMM Solar webProxy

Контроль файлов, мониторинг и доказуемость

Даже корректный доступ к сайтам не решает задачу полностью, если ИБ не видит, какие данные сотрудники передают через разрешенные ресурсы. Solar webProxy позволяет учитывать:

• MIME-тип файла.
• Расширение и имя файла.
• Размер файла.
• Хеш файла (MD5, SHA1, SHA256).
• Ключевые слова в HTTP-запросах и ответах.

За счет этого SaaS или облачный сервис может оставаться доступным, а отдельные действия внутри него — ограничиваться политикой. Например, можно контролировать загрузку и выгрузку определенных типов файлов или направлять их на дополнительную проверку через ICAP. Поэтому контроль доступа в интернет охватывает не только посещение ресурса, но и операции с данными внутри разрешенного сервиса.

Следующий уровень — мониторинг веб-активности пользователей. Solar webProxy регистрирует события веб-подключения, а при настроенной интеграции события могут передаваться в SIEM. Отчеты, настраиваемые рабочие столы и «Досье пользователя» помогают анализировать активность отдельных сотрудников и групп, срабатывания политик и контекст событий при расследовании.

Возможности системы решают разные задачи в зависимости от роли:

• CISO. Получает инструменты для контроля политик, расследований, журналирования и интеграции с DLP и SIEM.
• CIO. Получает возможность развивать использование SaaS, облачных и ИИ-сервисов, сохраняя управляемое подключение сотрудников к внешним ресурсам.
• Администратор. Централизованно управляет группами пользователей, категориями ресурсов, расписаниями, исключениями и изменениями политик.
• Руководство и закупки. Получают понятную модель применения решения и возможность подтвердить выполнение установленных правил отчетами и журналами.

Контроль без запрета на работу

Зрелый контроль доступа к сайтам не должен превращаться в тотальный запрет. Его задача — дать сотрудникам необходимые SaaS и ИИ-сервисы, одновременно ограничивая рискованные действия и передачу данных. Поэтому доступ в интернет нельзя сводить только к списку разрешенных и запрещенных ресурсов.

Для каждого подразделения правила можно адаптировать под рабочие задачи. Маркетинг продолжает использовать рекламные площадки, разработка — репозитории и ИИ, финансы — банки и ЭДО, а ИБ контролирует запросы, ответы, файлы и события. При этом универсальные защитные меры, например блокировку фишинговых и вредоносных ресурсов, можно применять ко всем группам.

Solar webProxy объединяет ролевые политики, категоризацию, SSL/TLS-инспекцию, DPI, контроль файлов, интеграции и аналитику в специализированной SWG-платформе. В распределенной инфраструктуре MultiProxy помогает централизованно управлять политиками на узлах Solar webProxy, а Endpoint Agent направляет веб-трафик рабочих станций Windows через назначенные узлы системы, где к нему применяются соответствующие правила.

Для разных участников такой подход дает свои преимущества:

• Для ИБ. Прозрачность веб-активности пользователей и доказуемость применения политик.
• Для ИТ. Централизованное управление правилами подключения и исключениями.
• Для пользователей. Использование привычных сервисов без избыточных ограничений.

В результате веб-контур становится управляемым, а ограничение доступа в интернет — понятным и предсказуемым для бизнеса.

Часто задаваемые вопросы