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

Как-то недавно мы решали одну стандартную задачу –  контроль над доступом сотрудников организации в Интернет. Решение предлагалось реализовать на ранее приобретенном комплекте средств защиты информации, которые играли роль шлюза в Интернет. Для заказчика, по-видимому, оказалось неожиданностью, что решение задачи контроля доступа в Интернет потребовало не только скрупулёзной формулировки ожидаемого результата, но и некоторой подстройки сетевой инфраструктуры.

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

Постановка задачи

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

а) отфильтровать (заблокировать) обращения к сервисам в Интернет, которые не отвечают служебной необходимости;

б) обеспечить доступ в Интернет на основе полномочий;

в) для разрешенных сервисов определить интенсивность их использования (создавать отчеты).

Вопрос 1: Идентификация сервисов в Интернет

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

Поскольку довольно часто несколько сервисов размещаются на одном и том же сервере (т. е. за одним и тем же IP адресом), средства защиты информации не в состоянии точно идентифицировать сервис только лишь по IP адресу сервера. По этой причине для идентификации сервиса используется анализ сессий на прикладном уровне – Deep Packet Inspection (DPI): для протокола HTTP(S) средствами функции Web Filter, для любых других протоколов – функция Application Control.

Одним из преимуществ применения механизма DPI является то, что кроме имени сервиса возможно получить детальные сведения об использовании Интернет-сервиса, например, в YouTube можно распознать просмотр видео, включая его наименование, публикацию видео или создание комментария.

Своего рода препятствием для механизма DPI оказывается шифрование протокола SSL/TLS, из-за которого содержимое запросов скрыто от средств защиты информации. Если все же требуется получать детальную информацию о приложении, например, распознавать имя ролика на YouTube, прибегают к атаке Man-in-the-Middle в отношении соединений SSL/TLS. При этом чтобы атака не была замечена браузером, для терминирования соединений SSL/TLS в средство защиты информации устанавливается цифровой сертификат,  доверенный с точки зрения рабочих станций пользователей (для генерирования такого сертификата используют удостоверяющий центр организации).

Получение детальной информации о содержимом SSL/TLS требует взвешенного решения потому, что сам по себе механизм атаки MitM требует значительных вычислительных ресурсов средства защиты информации, а порядка 70% трафика в Интернет – это как раз трафик HTTPS.

Вопрос 2. Как идентифицировать пользователя?

Как правило, в организациях стандартной ситуацией является назначение рабочей станции пользователя статического IP адреса, благодаря чему IP адрес рабочей станции может использоваться как идентификатор пользователя при доступе в Интернет.

На  практике оказывается, что подход с привязкой статических IP адресов к пользователю имеет ряд существенных недостатков.

Во первых, в случае изменений (новый пользователь, увольнение пользователя, перевод пользователя в другой департамент, перевод рабочей станции в другой сегмент сети и т. д.) требуется корректировать «базу» пользователей, что означает изменение конфигурации средств защиты информации.

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

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

Таким образом, в качестве идентификаторов пользователей в средствах защиты информации настраивают учётные записи пользователей  центрального каталога организации (как правило, Active Directory), которым динамически устанавливаются в соответствие IP адреса рабочих мест. Запрос идентификатора выполняется через взаимодействие с пользователем в момент доступа в Интернет (веб-портал запрашивает логин-пароль), или же без запросов пользователю (события аутентификации пользователя запрашиваются из сервера Active Directory – механизм SSO).

Вопрос 3: Какая информация будет в отчётах?

Для выполнения среднестатистического запроса к веб-сайту браузер открывает 20 сессий TCP более чем к 10 доменам, чтобы выполнить 80 HTTP запросов для загрузки теста, стилей, скриптов и медиа-содержимого страницы (по информации httparchive.org). Какую статистику по запросам пользователей хотелось бы иметь в отчётах, учитывая то, что детальность информации означает бОльшую нагрузку на средство защиты информации, больший объем данных, которые надо хранить и обрабатывать?

Золотой серединой, с моей точки зрения, является подход, который включает одновременно два варианта сбора данных для отчётов:

а) для всех пользователей выполняется сбор обобщенной информации: объем переданных и принятых данных, число сессий с группировкой  по категориям сервисов (веб-приложения, P2P, VoIP и т.д.)

б) для топ-5 пользователей «под подозрением»  – сбор детальной информации: объем переданных и принятых данных, число сессий по каждому отдельному приложению.

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

А что с прокси?

Один из вопросов, который остался за кадром – это способ направления трафика в средства защиты информации и далее в Интернет. Во многих организациях исторически доступ в Интернет предоставляется через прокси-сервер (explicit proxy). Доступ в Интернет без настройки на рабочем месте параметров прокси-сервера (IP адрес и порт) блокировался.

Такой способ, вероятно, был продиктован соображениями безопасности: после проникновения в КСПД malware попытается подключиться к серверам C&C, и, не зная о том, что доступ в Интернет требует подключения через прокси-сервер, не сможет этого сделать. Но данный довод, очевидно, потерял свой вес: современные экземпляры вредоносного ПО разрабатываются для подключения к серверам C&C уже с учётом прокси-серверов. Так в случае Windows вредоносные программы могут выполнять запросы в Интернет через программный интерфейс Win32 Internet Extensions API, который опирается на настройки прокси в операционной системе.

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

В заключение

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