Практическое использование DLPсистемы DeviceLock в корпоративной среде банка
Часть 2. Взаимодействие и безопасность компонентов
Особенности сетевого взаимодействия компонентов
Использование фиксированных сетевых портов
Сетевое взаимодействие сервера и агента DeviceLock
Сетевое взаимодействие консоли и агента DeviceLock
Защита агента от нарушения целостности
Разблокировка доступа с помощью криптографических ключей
Программный комплекс DeviceLock Endpoint DLP Suite разработки российской компании «Смарт Лайн Инк» предназначен для управления доступом пользователей ОС семейства Windows к периферийным устройствам хранения и обработки данных, каналам сетевых коммуникаций, а также для контроля действий пользователей с устройствами и сетевыми протоколами (чтение, запись файлов, форматирование) и контроля содержимого переданных файлов и информации.
О возможностях продукта и механизмах управления им подробно рассказывается на сайте разработчика и в руководстве пользователя. В данном же цикле статей описываются неочевидные нюансы, с которыми мы столкнулись при использовании DeviceLock Endpoint DLP Suite в банковской корпоративной среде и которые необходимо учитывать при развертывании и эксплуатации программы в достаточно большом домене.
Вторая статья цикла посвящена особенностям сетевого взаимодействия компонентов и механизмам обеспечения собственной безопасности компонентов в DeviceLock Endpoint DLP Suite.
Особенности сетевого взаимодействия компонентов
Использование фиксированных сетевых портов
По умолчанию компоненты DeviceLock при сетевых взаимодействиях пытаются применять определенные порты (TCP 9132, 9133 и 9134), но помимо этого используют динамическую привязку, то есть если соответствующие порты заняты, то компонент DeviceLock воспользуется другим — тем, который предоставит подсистема RPC. Если же задать фиксированный порт, который займет другая служба или приложение, компонент DeviceLock не осуществит привязку к этому порту и станет недоступным для управления. Однако в сети, разделенной на сегменты файерволами, целесообразно применять фиксированные порты. Так, если агенты находятся в защищенном сегменте, а сервер — в основной сети (агенты имеют доступ в основную сеть, а для основной сети доступ к ним ограничен), то серверу для работы с агентами в фиксированном порте нужно, чтобы на файерволе были открыты порты TCP 139, 445, а также фиксированный порт. А для работы сервера с агентами, использующими динамическую привязку, — TCP 139, 445, 135 плюс все порты выше 1024. Для подключения консолью к агентам — те же порты, если в строке адреса будут указываться IP-адреса удаленных машин; те же адреса плюс UDP137, если в строке адреса будут указываться имена компьютеров, а не IP-адреса. Указанных портов достаточно в том числе для того, чтобы обновлять версию агента на удаленном компьютере.
Сетевое взаимодействие сервера и агента DeviceLock
В течение пяти минут после того, как агент DeviceLock создал записи в своем логе (например, о вставке в USB-порт устройства), он выбирает сервер DeviceLock из списка, заданного в своих настройках, чтобы передать записи на сервер для централизованного хранения. В зависимости от настройки Fast Servers First выбирается либо случайный сервер, либо тот, «цена» трафика с которым (в условных единицах) минимальна. Агент шлет серверу запрос: сервер получает запрос и ставит его в очередь. Когда очередь подходит, сервер начинает попытки сбора логов с агента. При удачном подключении он всё собирает и заканчивает сбор, удаляя соответствующий компьютер из очереди. В случае ошибочного подключения сервер предпринимает еще две попытки с минутным интервалом, фиксируя их в соответствующем журнале. Если и после этих двух попыток серверу не удастся подключиться к агенту, он удалит его из очереди и снова поставит в очередь, когда тот, записав локально новую порцию логов, пришлет ему новый запрос. После удачного соединения агент передаст серверу сначала более старые записи, а потом более новые.
В настройках агента DeviceLock есть параметр Traffic priority, определяющий, какую часть пропускной способности канала может занимать агент для своих целей. Оптимальным автор считает режим, когда агенту предоставляется не больше 50%. Однако настройка работает только при условии, что на целевой машине установлена и запущена служба QoS — Quality of Service Packet Scheduler. Без этой службы функция не работает и агент может занимать до 100% пропускной способности.
Сетевое взаимодействие консоли и агента DeviceLock
Подключение консолями к агенту и серверу DeviceLock происходит по портам, указанным в настройках агента и сервера. В интерфейсе консолей нет поля настроек, где можно указать порт, по которому она всегда будет пытаться соединяться с удаленными машинами. Таким образом, консоль сначала подключается к RPC, выдающей ей номер порта, после чего соединяется по полученному номеру порта. Можно сократить процедуру подключения консоли, явно задав порт. Порт указывается в строке адреса для подключения консоли в квадратных скобках сразу после имени или IP-адреса удаленной машины без пробелов: computer_name[port]. Указание в явном виде порта при подключении консоли к серверу избавляет консоль от необходимости подключения к RPC.
Безопасность компонентов
Защита агента от нарушения целостности
Разработчики DeviceLock предусмотрели несколько эшелонов защиты компонентов программы от несанкционированного доступа и модификации, в том числе при взаимодействии друг с другом. К их чести нужно отметить, что защита целостности не идет в ущерб доступности: предусмотрены процедуры out-of-band management, позволяющие в экстренных ситуациях менять настройки доступа к устройствам, снимать защиту от модификации с агентов DeviceLock.
Первый эшелон защиты сервера и агента DeviceLock — отключение так называемой Default Security. До отключения этого режима любой пользователь с повышенными привилегиями, позволяющими устанавливать либо удалять программы и менять параметры запуска служб, сможет просматривать настройки агента DeviceLock и логи на своей машине, если является администратором, менять настройки агента или удалять его. Отключение Default Security означает включение списков доступа к агенту DeviceLock. В список могут входить как доменные, так и локальные учетные записи пользователей или групп. Привилегированные учетные записи, вплоть до администраторов домена, не смогут модифицировать либо удалять агент, если они не будут включены в список доступа. В частности, они не смогут поставить на той же машине «враждебный» агент DeviceLock, который разрешит доступы. В таком случае установленный DeviceLock будет считать, что его пытаются обновить, и не позволит этого сделать. Более того, они не смогут поставить не только агент, но даже просто консоли. Они также не смогут соединиться с помощью враждебной консоли DeviceLock Enterprise Manager/DeviceLock Management Console, уже установленной на компьютере, и не смогут удалить его в безопасном режиме, прочитать его настройки, узнать из настроек, на какие серверы агент шлет логи, и внести эти имена серверов в файл hosts, чтобы отсылка логов прекратилась. Правда, для получения данных для модификации файла hosts они могут перехватить трафик, если уровень аутентификации RPC понижен до 1 (rpc_c_protect_level_none). В этом случае трафик между агентами и сервером не шифруется. Такая ситуация может сложиться при взаимодействии между сегментами сети или между доменами с разными политиками доступа. По умолчанию же соединение агента и сервера проходит на уровне аутентификации Rpc 6 (rpc_c_protect_level_pkt_privacy). Отслеживание случаев незашифрованного трафика между сервером и агентами возможно по записям Authentication level for comp changed from 6 to 1 в логе сервера. Для обладателей учетных записей, не внесенных в список доступа к агенту, останется один способ избавления от агента DeviceLock, не удаляя операционную систему, — манипулировать параметрами реестра.
На этот случай разработчики предусмотрели второй эшелон защиты — режим Unhook protection, при котором агент DeviceLock не позволит пользователям отключить защиту критичных для сервиса веток реестра и файлов, таким образом делая невозможным отключение DeviceLock при помощи утилит-руткитов (например, Kernel Detective). В режиме Unhook protection агент DeviceLock при нарушении целостности вызывает завершение работы Windows синим экраном «смерти».
Третий эшелон защиты — это мониторинг активности агентов и восстановление целостности их настроек с помощью модуля Мониторинг сервера DeviceLock. В частности, модуль будет уведомлять, что удаленный агент замолчал, если злоумышленники всетаки узнали имя сервера или IP-адрес и порт, и загасил коммуникации на них.
Авторизация при взаимодействии сервера и агентов DeviceLock может быть построена не только на наличии учетной записи, под которой запущен сервер DeviceLock, в списке доступа агента DeviceLock. Может также использоваться несимметричная пара криптографических ключей. С секретным (private) ключом секретной пары, который хранится на сервере, сопоставляются открытые (public) ключи, хранящиеся на агентах. Если открытый ключ, предъявленный агентом, соответствует секретному ключу, предъявленному сервером, сервер принимает запрос агента. Это называется аутентификацией по сертификату, которая имеет приоритет, то есть используется в первую очередь, но если она не проходит, то осуществляется аутентификация по учетной записи. Если не проходит и она, выдается ошибка подключения. Однако даже если обе указанные аутентификации пройдут, это не гарантирует успеха, поскольку отказ в доступе сервера к удаленному агенту может случиться от самой операционной системы. В связи с этим в настройках запуска службы сервера DeviceLock рекомендуется применять учетную запись с большими привилегиями в домене. Лучше не давать слишком большие права (domain admin, enterprise admin), а создать учетную запись, имеющую права администратора на машинах определенного типа в домене/OU (например, только типа workstations).
Разблокировка доступа с помощью криптографических ключей
У криптографических ключей существует и второй способ применения, и он, на взгляд автора, настолько важен, что с первого дня развертывания необходимо снабдить все агенты публичным криптографическим ключом. Ключи используются для out-of-band management, то есть экстренного управления агентами в случае недоступности стандартных каналов управления. Представьте себе ситуацию: на компьютере установлен агент, защищенный списком доступа, в который включены только доменные учетные записи, при этом агент запрещает любой доступ к внешним устройствам. Когда случается сетевой сбой, компьютер оказывается вне сети, но вдруг срочно требуется разблокировать доступ к какому-то внешнему устройству. Настройки доступа нельзя изменить, поскольку невозможен логин под доменной учетной записью. На этот случай предусмотрена пара функций, объединенная в компоненте DeviceLock Signing Tool.
Первая функция — выдача временного кода доступа. Администратор DeviceLock получает от пользователя так называемый код устройства, сгенерированный им на своей рабочей станции посредством своего инстанса DeviceLock Signing Tool с помощью открытого ключа. Администратор вводит полученный код в нужное поле в своем инстансе DeviceLock Signing Tool, подгружает секретный ключ и генерирует ответный код, задавая срок или условие (log-off пользователя либо отключение устройства) прекращения его действия. Пользователь получает ответный — разблокирующий — код по телефону или другим доступным способом, вводит его в нужном поле своего инстанса DeviceLock Signing Tool и получает временный доступ к нужному устройству. Внимание: перед применением этих кодов, пожалуйста, учтите две тонкости. Первая: код устройства генерируется на основе информации о машине, сертификате и устройстве. Не используются идентификаторы конкретного инстанса агента DeviceLock. Это означает, что если на машине, где запущен аплет DeviceLock Signing Tool, после генерации DeviceCode будет удален агент, а затем установлен агент с тем же открытым ключом, то полученный на основании кода устройства код разблокировки всё еще можно будет применять. Вторая: если пользователь, сгенерировав код устройства, закрыл аплет DeviceLock Signing Tool, то, открыв его заново и получив от администратора код разблокировки, он не сможет им воспользоваться; прерывание сеанса DeviceLock Signing Tool на стороне пользователя при ожидании разблокирующего кода от администратора недопустимо.
Вторая функция DeviceLock Signing Tool — подписывание файла настроек. Продолжим рассматривать наш пример. С помощью обмена кодами мы смогли получить временный доступ к флэшке на компьютере, отрезанном от сети. Теперь мы хотим изменить его настройки более глобально, а не только для отдельно взятого устройства. Для этого мы получаем от администратора DeviceLock файл с нужными настройками агента, подписанный секретным ключом, который используем с помощью локального DeviceLock Signing Tool (файл DLTempAccess.cpl в установочной директории DeviceLock). Настройки будут действительны, даже если они применяются от имени ограниченной учетной записи и учетной записи, не включенной в список доступа агента DeviceLock.
В следующей статье цикла мы рассмотрим некоторые нюансы задания DLP-политик для контроля устройств и каналов сетевых коммуникаций в DeviceLock Endpoint DLP Suite.
 |
|
