Контроль над доступом в Интернет сотрудников предприятия
Как-то недавно мы решали одну стандартную задачу – контроль над доступом сотрудников организации в Интернет. Решение предлагалось реализовать на ранее приобретенном комплекте средств защиты информации, которые играли роль шлюза в Интернет. Для заказчика, по-видимому, оказалось неожиданностью, что решение задачи контроля доступа в Интернет потребовало не только скрупулёзной формулировки ожидаемого результата, но и некоторой подстройки сетевой инфраструктуры.
На что стоило бы обратить внимание на стадии планирования технического решения, читайте ниже.
Постановка задачи
Постановка задачи может отличаться в зависимости от требований организации, но, как правило, выражается в комбинации следующих требований:
а) отфильтровать (заблокировать) обращения к сервисам в Интернет, которые не отвечают служебной необходимости;
б) обеспечить доступ в Интернет на основе полномочий;
в) для разрешенных сервисов определить интенсивность их использования (создавать отчеты).
Вопрос 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, который опирается на настройки прокси в операционной системе.
Если же рассмотреть применение прокси с точки зрения задачи контроля доступа в Интернет, то на поверхность всплывают другие проблемы: отдельные программы на рабочих станциях пользователей с одной стороны требуют подключения в Интернет, с другой стороны не имеют поддержки прокси. В связи с этим, направление трафика в средства защиты информации проще выполнять за счёт маршрутизации, отказавшись от инструментов прокси.
В заключение
Надеюсь, что рассуждения выше помогут вам в решении вашей задачи контроля доступа пользователей в Интернет. Конечно, в решении есть еще много деталей, которые по желанию можно обсудить в комментариях.
Комментариев пока нет
Добавить комментарий