Программа DeviceLock предназначена для управления доступом пользователей ОС семейства Windows к периферийным устройствам хранения и обработки данных, а также для контроля действий пользователей с устройствами (вставка, чтение, запись файлов, форматирование, извлечение) и для контроля содержимого скопированных файлов.
Общие сведения о том, какие устройства и какие типы файлов попадают под контроль, описаны подробно на сайте разработчика и в руководстве пользователя. Мы же сосредоточимся на неочевидных нюансах, которые необходимо учитывать при развертывании и эксплуатации программы в достаточно большом домене.
Поскольку программа состоит из нескольких независимых компонентов, вначале кратко остановимся на их обзоре. Далее мы рассмотрим следующие аспекты работы с программой:
- установка, удаление, в том числе установка новых версий поверх старых и совместимость модулей разных версий между собой;
- особенности контроля доступа к внешним устройствам;
- аутентификация и авторизация при административном доступе к компонентам, при взаимодействии компонентов, в том числе дополнительные механизмы обеспечения целостности службы (агента) DeviceLock;
- сетевые аспекты взаимодействия компонентов;
- работа с логами и файлами теневого хранилища, в том числе некоторые полезные SQL-запросы для реализации функций не доступных через DeviceLock;
- интеграция с Active Directory для управления доступами в большом домене
Ниже в случаях, если специально не указывается версия и билд программы, имеется в виду версия 7.1. билд 31981.
Компоненты
DeviceLock имеет 6 основных и 3 дополнительных компонента. Основными являются DeviceLock Service (далее — агент), DeviceLock Server (далее — сервер), DeviceLock Management Console, DeviceLock Enterprise Manager, DeviceLock Service Settings Editor, DeviceLock Group Policy Manager, DeviceLock Signing Tool. Дополнительными компонентами являются: DeviceLock Content Security Server, Network Lock, Content Lock.
DeviceLock Service — служба на рабочих станциях, которая блокирует доступы к устройствам, ведет лог активности, отправляет лог и теневые копии записанных/прочитанных файлов на сервер.
DeviceLock Enterprise Server — служба на сервере, которая собирает данные от агентов, фильтрует собранные данные, выводит их в разных представлениях, а также может осуществлять мониторинг целостности настроек агентов и восстановление нарушенных настроек.
DeviceLock Management Console и DeviceLock Enterprise Manager — консоли управления агентом и сервером выполненные как оснастки MMC; первая из них предназначена для индивидуальной работы с агентами (например, изменение отдельных настроек агента), вторая — для массовой работы (массовая установка, массовая разливка файла настроек, отчет о настройках, массовое удаление).
DeviceLock Service Settings Editor предназначен для создания файлов, содержащих набор настроек агента, а также для прикрепления созданных настроек к MSI-файлу для установки агента.
DeviceLock Group Policy Manager предназначен для интеграции DeviceLock с Active Directory, оснастка доступна из Group Policy Management, при редактировании свойств объектов групповой политики — (далее — GPO).
DeviceLock Signing Tool предназначен для создания кодов (хэшей) для временной разблокировки доступа к внешним устройствам на компьютерах, находящихся оффлайн и потому не доступных для управления другими методами. Также компонент предназначен для подписывания файлов настроек. Подписанный секретным ключом асимметричной пары файл настроек может быть применен к агенту DeviceLock, настроенному использовать публичный ключ асимметричной пары, даже непривилегированным пользователем.
Для работы с дополнительными компонентами требуются отдельные файлы лицензионных ключей.
DeviceLock Content Security Server — компонент, без которого теневое копирование файлов, прочитанных/записанных пользователями с/на внешние устройства, было бы не очень полезной вещью. Компонент позволяет индексировать теневое хранилище, включая в индекс значимые слова. Это позволяет быстро искать файлы в теневом хранилище по нужным словам, таким как, например, «конфиденциально». В DeviceLock Search Server лицензируются не количество рабочих станций, а количество проиндексированных записей. Поэтому созданный компонентом индекс необходимо время от времени очищать. Иначе DeviceLock Content Security Server может проиндексировать старые данные, истратив лицензии, и тогда новые данные индексироваться не будут. Чистить индекс следует, в частности, при удалении файлов из теневого хранилища сервера, иначе может возникнуть ситуация, когда лицензии отнимают записи в индексе, адресующиеся к уже удаленным файлам теневого хранилища.
ContentLock — компонент, расширяющий возможности фильтрации файлов по содержимому. Стандартными настройками сервера DeviceLock ему можно запретить/предписать сохранять логи операций с файлами и теневые копии файлов, если эти файлы относятся к тому или иному типу. ContentLock позволяет устанавливать запреты/предписания по ключевым словам и по соответствию фрагментов текста в файлах заданным регулярным выражениям. Он включает набор ключевых слов и регулярных выражений, а также конструктор регулярных выражений.
NetworkLock — компонент, позволяющий контролировать содержание сетевой активности или блокировать сетевую активность. Он дает возможность запрещать доступ к определенным сайтам, доступ по определенным протоколам, разрешение IP-адресов в адреса URL. Интерес представляет блокировка активности по различным протоколам уровня приложений, например, блокировка ICQ, Mail Agent, других служб мгновенных сообщений. Если в новых версиях разработчикам удастся реализовать удобный механизм просмотра теневых копий веб-страниц, большую ценность станет представлять функция отслеживания активности в Gmail. Дело в том, что весь трафик между рабочей станцией пользователя и сервером Gmail шифруется, поэтому в логах прокси-сервера нельзя видеть, какие именно пакеты передавал и получал пользователь с сервера / на сервер.
Установка, удаление, совместимость
- Установка административных инструментов с помощью setup.exe
Файл setup.exe из папки с дистрибутивом программы используется, как правило, только для установки программы на компьютер, с которого сервер и сервисы будут контролироваться консолями, на сервер и на контроллер домена при необходимости интеграции с Active Directory — создания GPO, определяющих настройки агента DeviceLock на тех или иных группах компьютеров в домене. При установке консолей и сервера через setup.exe из дистрибутива на одну и ту же машину нужно иметь в виду следующее: если Вы хотите, чтобы Вам был доступен DeviceLock Enterprise Manager, проводите установку в два этапа: сначала выбирайте в мастере установки: Service+Consoles, потом запускайте setup.exe повторно и выбирайте Server+Consoles. Если Вы сразу выберете первый вариант, DeviceLock Enterprise Manager не установится, и для установки его потребуется сначала удалить установленные компоненты, а потом запустить Service+Consoles. Остается только гадать, зачем разработчики ввели это странное ограничение.
Рисунок 7. Два варианта выбора способа установки — запущено два инсталлятора параллельно (в нормальной ситуации нижнее окно возникает после выбора Custom в верхнем). Обратите внимание на файл setup_dlcss.exe (слева) — это отдельный установщик для DeviceLock Content Security Server - Установка из MSI-файла средствами Windows
Для установки агента DeviceLock, требуется файл DeviceLock Service.msi либо DeviceLock Servicex64.msi, в зависимости от целевой операционной системы. Если ИТ-инфраструктура позволяет, для массовой установки агентов на компьютеры сети, лучше обойтись без использования консолей производителя, т.к. в них не предусмотрены механизмы автоматического контроля наличия агента на машинах и доустановки на ранее недоступные машины, выходящие в онлайн. Устанавливать агенты DeviceLock можно через применение GPO к доменам/контейнерам/фильтрам безопасности или средствами SMS/SCCM. Используемый MSI-файл может быть либо «голым», т.е. без установленных настроек (такой агент ничего не блокирует, ничего не логирует и не защищен от удаления/изменения из-под любой привилегированной учетной записи), либо со встроенными настройками. MSI-файл со встроенными настройками создается с помощью DeviceLock Service Settings Editor из обычного MSI-файла. Устанавливать «голый» MSI не рекомендую; т.к. такой агент смогут удалить на своих машинах люди с привилегированными учетными записями до того, как репликацией групповых политик до них докатятся настройки. А уж подключаться ко всем агентам через DeviceLock Enterprise Manager после установки через SMS/SCCM — вообще двойная работа, не говоря о том, что за промежуток времени между установкой и попыткой залить настройки целевая машина может уйти в оффлайн.
В случае установки на большое число машин при слабых каналах связи в сети, лучше не использовать DeviceLock версии 7. Дело в том, что MSI-файл версии 7 стал из-за обязательного включения в него компонентов ContentLock и NetworkLock весить значительно больше, чем весил MSI-файл версии 6 (24 против 4 Мб). При этом пересобрать MSI с исключением из него ненужных компонентов невозможно. Такой тяжелый MSI представляет трудность, когда необходимо разлить программу массово на несколько сотен рабочих станций. Приходится задуматься о выставлении приоритетов трафика с помощью BITS — Background Intelligent Transfer Service либо об откате к старой версии программы.
- Установка с помощью консолей управления DeviceLock
Если инфраструктура SCCM не развернута в организации, придется использовать для массовой установки DeviceLock Enterprise Manager, с возможностью на единичных машинах проводить установку через DeviceLock Management Console. Здесь сразу надо оговориться, разочаровав многих, что инструмент Monitoring сервера DeviceLock не позволяет устанавливать агенты DeviceLock на машинах, где они отсутствуют. Он только может с заданной периодичностью проверять наличие и целостность настроек агентов на компьютерах по списку либо по домену / OU, а также восстанавливать настройки, отличающиеся от эталона. Установка агентов c тотальным покрытием компьютеров сети станет намного удобнее, если этот механизм будет реализован. Тогда станет возможным средствами DeviceLock автоматически доливать агенты на все компьютеры по их выходу в онлайн.
Итак, консоли DeviceLock Enterprise Manager и DeviceLock Management Console для установки агентов на удаленные машины используют файлы DeviceLock RemoteInstaller.exe, InstMsiW.exe, Dlservice.msi (для 32-битных Ос Windows), DeviceLock Service x64.msi (для 64-битных Ос Windows) из директории, куда установлена программа — как правило, это C:Program FilesDeviceLock или С:Program FilesDeviceLock Agent; при этом файлы DeviceLock RemoteInstaller.exe и InstMsiW.exe используются для запуска удаленной установки с вызовом Windows Installer. В DeviceLock Enterprise Manager Вы можете указать путь к файлам в окне InstallOptions, открывающемся из окна ScanNetwork при выборе плагина Install Service и нажатии кнопки Settings. Там же вы можете указать фиксированный TCP-порт для работы агента. Последнее очень важно: позднее вы не сможете изменить этот параметр заливкой новых настроек. Вам потребуется переустанавливать агент.
Установка из DeviceLock Enterprise Manager происходит по группе компьютеров, которая может задаваться либо списком из файла (при этом внутри домена достаточно неполных имен), либо выбором компьютеров в домене / орагинизационной единице (OU), либо выбором всех компьютеров определенного типа в домене / OU: primary domain controller, backup domain controller, Microsoft SQL Server, terminal server, standalone server, cluster server, print server, NTworkstation. Последняя функция удобна, если в организации нет прозрачной практики именования компьютеров в зависимости от типов. Можно задать установку на все рабочие станции домена, избегая установки на серверы. Правда, здесь можно обмануться, т.к. MS SQL Server при установке на рабочую станцию вносит изменение в реестр, помечающее ее как тип «Microsoft SQL Server».
При установке с помощью DeviceLock Enterprise Manager и DeviceLock Management Console эти консоли должны быть запущены под учетной записью, входящей в список локальных администраторов на удаленной машине. Можно запустить их от имени привилегированной учетной записи через пункт Run As контекстного меню исполняемого файла (или ярлыка) в сессии обычной учетной записи, но если речь идет о доменной учетной записью, ее нужно будет указывать в полной нотации: DomainNameUserName. Это относится ко всем случаям прямого указания учетных записей в DeviceLock. Также между машиной, на которой запущена DeviceLock Management Console/DeviceLock Enterprise Manager и целевой машиной не должно быть файервола. Попытки автора установить агенты на машины, находящиеся в сегменте сети, входящие соединения внутрь которого контролируются файерволом, не привели к успеху даже после того, как на файерволе был открыт для машины с DeviceLock Management Console/DeviceLock Enterprise Manager следующий внушительный список протоколов/портов: ICMP, UDP137 TCP139 TCP445 TCP135, UDP139. При этом удаление агентов при этих дырках в файерволе проходило на ура.
- Установка без участия человека
Разработчиками предусмотрена установка компонентов DeviceLock прямым запуском файла setup.exe на любой машине без участия пользователя. Для такой установки нужно запустить setup.exe на локальной или удаленной (например, с помощью psexec.exe) машине с параметром /s. При этом параметры установки будут браться из файла DeviceLock.ini из той же директории, где находится setup.exe.
Для того, чтобы параметры в этом текстовом файле использовались, нужно удалить квадратные скобки, обрамляющие названия параметров. Назначение параметров описано в мануле, здесь же ограничимся одним важным замечанием. Для того, чтобы агент использовал фиксированный Tcp-порт, что важно в сегментированных сетях, нужно указать это в описанном выше ini-файле (параметр FixedPort).
- Установка с помощью командной строки
В случае, если агент не устанавливается на удаленную машину с помощью консолей, при этом вы убеждаетесь, что удаленная машина не выключена, не за файерволом, и вы имеете на ней права администратора, можно попробовать установку в ручном режиме. Иногда это помогает.
Для этого при наличии у вас pstools, можно использовать следующий простой скрипт командной строки:
psexec.exe \ -e -u "" -s cmd /c msiexec.exe /i "" /norestart /passive /quiet /log ""
Если все работает правильно, то при выполнении скрипт запросит у Вас пароль. Если Вы правильно введете пароль, скрипт отработает, и при отсутствии ошибок в его работе, Вам будет сообщено следующее:
cmd exited on Pc01455 with error code 0.
Пароль можно включить в изначальный скрипт, добавив после вот этого фрагмента:-u "" вот этот: -p "". Я бы, впрочем, не рекомендовал это делать, хотя бы для того, чтобы пароль не был виден на экране.
- Удаление программы
Из компонентов DeviceLock, интерфейс для удаления агентов предоставляет только DeviceLock Enterprise Manager. С помощью компонентов DeviceLock невозможно остановить агент на удаленном компьютере. Попытка остановить службу DLService средствами Computer Management не даст результатов. В случае, если DeviceLock не защищен от «любого администратора» (к этому вопросу мы еще вернемся позднее), возможна остановка и удаление запуском его исполняемого файла с особыми параметрами: -e — остановка, -u — удаление.
- Совместимость версий
Что касается совместимости версий, то на примере установки версии, о которой идет речь в статье, поверх версии 6.4.1 билд 24986 автор имеет сказать следующее. Во-первых, установка новой версии поверх старой проходит гладко средствами DeviceLock Enterprise Manager. Во-вторых, обнаружены следующие сочетаемости / несовместимости компонентов разных версий:
- Старой консолью и DeviceLock Enterprise Manager нельзя соединиться с новым агентами.
- При попытке соединения новой консолью и DeviceLock Enterprise Manager со старым агентами запрашивается обновление агента, при отказе соединение не происходит.
- Старый сервер успешно собирает логи и теневые файлы от новых агентов.
- Новый сервер успешно собирает логи и теневые файлы со старых агентов.
- При передаче новому серверу базы данных SQL, созданной и наполнявшейся старым сервером, в базу успешно добавляются новые таблицы/колонки/процедуры, и доступность всех данных сохраняется.
- Старые установщики не могут использовать файл настроек, отредактированный в DeviceLock Service Settings Editor новой версии.
- Новые установщики успешно применяют старые файлы настроек к новым агента.
- При подключении старой консолью к новому серверу, некорректно работает просмотр логов и теневых файлов на сервере
- При подключении новой консолью к старому сервису, запрашивается обновление сервера, при отказе соединение не происходит.
Следует отметить, что разработчики не гарантируют межверсионное взаимодействие компонентов, за исключением корректного применения старых файлов настроек к новым агентам.
- Лицензионные файлы
Лицензии DeviceLock требуются для консолей управления DeviceLock и отдельно лицензируемых модулей DeviceLock Content Security Server, ContentLock и NetworkLock. Для автономной работы агентов лицензии не нужны, поэтому если вы захотите с помощью DeviceLock запретить всем пользователям доступ к определенным устройствам, настройки запрета разольете через GPO и не будете включать логирование событий, вы можете это сделать, не покупая лицензию, на любом числе компьютеров. Количество лицензий определяет то, для скольких машин одновременно можно будет запустить задание через DeviceLock Enterprise Manager и сколько машин сможет отчитываться перед сервером DeviceLock. При нехватке лицензий всегда можно запустить задание в DeviceLock Enterprise Manager в несколько заходов, поднять несколько серверов DeviceLock и прописать в настройках нескольких групп агентов DeviceLock разные имена серверов DeviceLock. Поднять сервера можно в том числе на одной физической машине, создав на ней несколько виртуальных и настроив NAT — переадресацию сетевого трафика по определенным портам на виртуальные сетевые адаптеры с физического. Это еще одна ситуация, в которой может потребоваться использование фиксированных портов. Впрочем, все вышесказанное — голая теория, т.к. такие ухищрения с лицензиями противозаконны, и я искренне надеюсь, что разработчики рано или поздно создадут механизмы защиты от подобных злоупотреблений.
Обратите внимание, что лицензии DeviceLock Content Security Server закупаются отдельно и даются не по числу машин, а по числу проиндексированных записей логов. На данный момент нет интерфейса для просмотра текущего числа использованных лицензий или частичного удаления лицензий, а также алертов об израсходовании лицензий. Поэтому нужно самостоятельно пересоздавать индекс по мере потери актуальности и/или удаления записей логов и файлов теневого хранилища. Установка файлов лицензионных ключей *.lic, как правило, не представляет трудностей. Мастер установки запрашивает директорию с лиценизонными файлами, вы указываете, он подхватывает. Он понимает загрузку в список сразу нескольких лицензионных файлов, в том числе триальных совместно с нормальными. Если в процессе установки вы не стали указывать лицензии, то интерфейса для загрузки лицензий в DeviceLock Management Console/DeviceLock Enterprise Server Вы не найдете. Для загрузки Вам потребуется просто переместить новый лицензионный файл в установочную директорию DeviceLock, при этом расширение файла должно быть .lic. После запуска консоли файл *.lic будет переименован в *.li_ — это значит, что программа «подхватила» нужный лицензионный файл. При необходимости замены одного файла другим по такой схеме, понадобится сначала удалить старый файл из установочной директории и удалить параметр Lic из реестра Hkey_Local_MachineSoftwareSmartLine VisionDeviceLock.
Контроль доступа к внешним устройствам
DeviceLock не препятствует установке устройств в системе, но фильтрует обращения к устройствам пользователей на уровне драйвера. При обращении пользователя к устройству драйвер запрашивает у сервиса разрешения пользователя на доступ к этому устройству и предоставляет или ограничивает его.
Все многообразие интерфейсов, доступ к которым способен контролировать DeviceLock, разбивается на порты и типы устройств:
- порты: Bluetooth, FireWire, Infraread, Parallel Port, Serial port, USBPort
- типы устройств: DVD/CD-ROM, Floppy, Hard Disk, Printer, Removable, Tape, WiFi, а также смартфоны/КПК Blackberry, IPhone, Palm, WindowsMobile.
Последние четыре из перечисленных типов устройств распознаются, когда они подключаются к компьютеру включенными, и устанавливается синхронизация между ними и компьютером.
Начиная с седьмой версии программы, появился также контроль доступа к буферу обмена Windows, с помощью которого можно блокировать операции копирования/вставки фрагментов текста, графики в документы. Этот интерфейс стоит особняком, не относясь ни к портам, ни к типам устройств.
Агент DeviceLock определяет, давать ли доступ пользователю к устройству, в следующем порядке: 1) есть ли у него доступ к тому или иному порту (задается в разделе настроек Devices/Permissions), 2) есть ли у него доступ к тому или иному типу устройств (задается там же), 3) есть ли доступ к тому или иному типу файлов (задается в разделе настроек Devices/Content Aware Rules). Так, если у пользователя есть доступ к порту USB и есть доступ к типу устройств Removable, но нет доступа к файлам Jpeg, то он сможет передавать через порт USB, в частности на/с устройств(а) Removable, все файлы, кроме Jpeg. Если же у пользователя есть доступ к порту USB, но нет доступа к типу устройств Removable, то он сможет работать со всеми устройствами, работающими через порт USB, кроме устройств Removable. Наконец, если у пользователя нет доступа к порту USB, то даже если у него есть доступ к типу устройств Removable, он не сможет воспользоваться этими устройствами. (Заметим в скобках, что DeviceLock относит к Removable все устройства, которые Windows относит к таковым, т.е. все Storage устройства, кроме Floppy, DVD/CD. Есть характерный признак для определения, относится ли устройство к классу Removable — Windows для Removable-устройств позволяет делать Safe remove).
Описанная иерархия была бы слишком жесткой и неудобной, если бы для нее не были предусмотрены исключения.
Первое по приоритету исключение — «белый список» USB-устройств. Настраивается он в разделе Devices/USBDevicesWhiteList. В белый список может быть внесена определенная линейка устройств одного производителя (VendorID+ProductID) либо конкретное уникальное устройство (VendorID+ProductID+SerialNumber). Если в белый список внесена линейка/устройство и при настройке белого списка снят флажок «ControlasType», то доступ к линейке/устройству будет открыт независимо от запретов на уровне порта и уровне типа устройств, и операции с ним не будут логироваться. Каждому пользователю можно назначить свой белый список. Это в теории дает возможность построить систему, в которой ни один пользователь не сможет воспользоваться «чужой флешкой».
Второе по приоритету исключение — снятие контроля на уровне порта для отдельных типов устройств. Это исключение настраивается в разделе DevicesSecurity Settings — единым списком, либо в окне Security Settings настроек доступа каждого из портов — только для устройств, которые могут работать через этот конкретный порт. В частности, из контроля доступа на уровне порта USB могут исключаться: Human Interface Devices (HID) — клавиатура, мышь и т.д., принтеры, Bluetooth-адаптеры, «USB and FireWire network cards», сканеры, Removable-устройства.
И здесь наступает момент, когда можно запутаться. Во-первых, эти самые Removable устройства называются именно так в разделе настроек Devices/Permissions, но называются USB Storage Devices в разделе DevicesSecurity Settings. Во-вторых, не так просто сразу понять, в чем разница между двумя следующими конфигурациями:
- В разделе настроек DevicesPermissions: USBPort — доступ запрещен, Removable — доступ разрешен
- В разделе настроек DevicesPermissions: USBPort — доступ запрещен, но в разделе настроек DevicesSecuritySettings флажок напротив USB Storage Devices снят
А разница в том, что в первом случае иерархия работает, и доступа к Removable получить не удастся, ведь настройка для порта важнее. Во втором же тип устройств Removable (они же USB Storage) перестает подчиняться иерархии, и доступ к Removable становится возможен.
При этом, во втором случае иерархия перестает работать не для конкретного пользователя, а для всех пользователей на данной машине. В результате, для одних пользователей порт USB может быть запрещен, для других разрешен, но для всех из них доступ к Removable не будет зависеть от доступа к порту USB. И пользователям можно будет закрывать или открывать доступ к Removable уже настройкой доступа к самому Removable, а не к USB-порту.
Лучше понять этот момент позволят следующие таблицы:
Доступ пользователя Xк Removable при разных настройках и исключениях доступа в DeviceLock:
| USB Port | USB Port Security Settings Access control for USB Storage devices | Removable | Результирующий доступ к Removable |
| Запрещен | Флажок выставлен | Запрещен | Запрещен |
| Запрещен | Флажок выставлен | Разрешен | Запрещен |
| Запрещен | Флажок снят | Запрещен | Запрещен |
| Запрещен | Флажок снят | Разрешен | Разрешен |
| Разрешен | Флажок выставлен | Запрещен | Запрещен |
| Разрешен | Флажок выставлен | Разрешен | Разрешен |
| Разрешен | Флажок снят | Запрещен | Запрещен |
| Разрешен | Флажок снят | Разрешен | Разрешен |
| Не задан | Не задан | Запрещен | Запрещен |
| Не задан | Не задан | Разрешен | Разрешен |
| Не задан | Не задан | Запрещен | Запрещен |
| Не задан | Не задан | Разрешен | Разрешен |
Результирующий доступ пользователей к Removable при выставленном флажке Access control for USB Storage devices:
| Пользователь | USB порт | Removable | Результирующий доступ к Removable |
| User A | Запрещен | Запрещен | Запрещен |
| User B | Запрещен | Разрешен | Запрещен |
| User С | Разрешен | Запрещен | Запрещен |
| User D | Разрешен | Разрешен | Разрешен |
Доступ пользователей к USBPort и Removable при снятом флажке Access control for USB storage devices:
| Пользователь | USB порт | Removable | Результирующий доступ к Removable |
| User A | Запрещен | Запрещен | Запрещен |
| User B | Запрещен | Разрешен | Разрешен |
| User С | Разрешен | Запрещен | Запрещен |
| User D | Разрешен | Разрешен | Разрешен |
Взаимосвязь между доступами к другим портам и соответствующим им типам устройств аналогична.
Самое страшное по контролю доступа к устройствам позади. Напоследок хочется сказать пару слов о доступе к WiFi и к смартфонам/КПК.
Доступ к WiFi-адаптерам пресекается на уровне порта, если это USB-WiFi-адаптеры, так что пользователь не сможет увидеть даже списка доступных WiFi-сетей. В случае с Pci-WiFi-адаптерами программа всего лишь запрещает смену SSID сети. Последнее означает, что если у Вас настроено автоматическое подключение к какой-то сети, и Ваша рабочая станция оказывается в радиусе ее действия, Вы сможете к ней подключиться, несмотря на DeviceLock с запретом WiFi. Также запрет доступа к WiFi не означает запрета доступа к WiMAX. Можно не дать пользователю использовать USB-WiMAX-адаптеры, для чего потребуется запрещать доступ к порту USB.
Что касается смартфонов/КПК, то если Вы соедините их с рабочей станцией выключенными, они будут видеться как Removable, и Вы сможете записать на них данные как на флеш-карту. Тонко настраиваемый контроль доступа к функциями этих гаджетов (включая, например, отключение доступа на чтение или запись в контактов, календаря, заметок, на исполнение файлов) работает, когда устройства соединяются с рабочей станцией в режиме синхронизации. Контроль доступа возможен для стандартных интерфейсов синхронизации (ActiveSync — для Windows Mobile, iTunes — для IPhone, IPod), а также для интерфейсов программирования приложений (API), предоставляемых разработчиком устройства и используемых приложениями различных разработчиков для взаимодействия с устройством. При этом пока нет гарантии, что в случае с Windows Mobile и Palm программа будет корректно контролировать доступ при синхронизации с использованием универсальных приложений синхронизации, таких как Mozilla SongBird.
Безопасность компонентов
- Защита агента от нарушения целостности
Разработчики 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 синим экраном смерти.
Рисунок 11. Ограничение доступа к агенту DeviceLock по списку без выставления защиты UnhookProtectionТретий эшелон защиты — это мониторинг активности агентов и восстановление целостности их настроек с помощью модуля «Мониторинг» сервера DeviceLock. В частности, модуль будет уведомлять, удаленный агент замолчал, если злоумышленники все-таки узнали имя сервера / IP-адрес и порт и загасил коммуникации на них.
Рисунок 12. Модуль Monitoring сервера DeviceLockВпрочем, последняя задача может решаться иначе — select-ом из таблицы DLstationsSQL-базы данных DeviceLock с определенной глубиной по дате последнего репорта на сервер (например, 24 часа), сопоставлением списка со списком машин в домене/OU, на которых агент должен стоять.
Авторизация при взаимодействии сервера и агентов DeviceLock может быть построена не только на членстве учетной записи, под которой запущен сервер DeviceLock, в списке доступа агента DeviceLock. Может использоваться несимметричная пара криптографических ключей. Секретный (private) ключ секретной пары хранится на сервере, с ним сопоставляются открытые (public) ключи, хранящиеся на агентах. Если открытый ключ, предъявленный агентом, соответствует секретному ключу, предъявленному сервером, сервер принимает запрос агента. Это называется аутентификацией по сертификату, она имеет приоритет, т.е. используется в первую очередь она, но если она не проходит, делается аутентификация по учетной записи. Если не проходит и она, выдается ошибка подключения. Надо заметить, что даже если обе указанных аутентификации пройдут, это не гарантирует успеха, т.к. отказ в доступе сервера к удаленному агенту может случиться от самой операционной системы. Поэтому рекомендуется в настройках запуска службы сервера DeviceLock использовать учетную запись с большими привилегиями в домене. Лучше не давать слишком большие права (domain admin, enterprise admin), а создать учетную запись, имеющую права администратора на машинах определенного типа в домене/OU (например, только типа workstations).
- Подключение консолью к агенту из-под ограниченной учетной записи
Использование криптографических ключей при авторизации соединения консолями DeviceLock Management Console и DeviceLock Enterprise Manager с сервером или агентом не предусмотрено. Доступ будет даваться либо административным учетным записям, либо учетным записям, включенным в список доступа на сервере / агенте. При этом на сервере можно задать для каждой учетной записи режим доступа полный (с возможностью удалять содержимое логов) либо только чтение.
Заметьте, что возможно подключение консолью к агенту на удаленном компьютере под учетной записью, не имеющей привилегий на удаленном компьютере. В нормальной ситуации, консоль при подключении к агенту вычитывает информацию о статусе/версии агента DeviceLock из удаленного реестра. В таком случае потребуются привилегии на удаленной машине. Но внесением в реестр на машине, на которой установлена консоль, следующего изменения, позволяет отключать эту проверку:
[Hkey_Current_UserSoftwareSmartLine VisionDLManagerManager]"CheckService"=dword:00000000
- Разблокировка доступа с помощью криптографических ключей
У криптографических ключей существует второе применение, и оно на взгляд автора так важно, что с первого дня развертывания необходимо снабдить все агенты публичным криптографическим ключом. Ключи применяются для out-of-bandmanagement, т.е. экстренного управления агентами в случае недоступности стандартных каналов управления. Представьте себе ситуацию: на компьютере установлен агент, защищенный списком доступа, в который включены только доменные учетные записи, при этом агент запрещает любой доступ к внешним устройствам. Теперь случается сетевой сбой, компьютер оказывается оффлайн, но вдруг срочно нужно разблокировать доступ к какому-то из внешних устройств. Настройки доступа нельзя изменить, т.к. невозможен логин под доменной учетной записью. На этот случай предусмотрена пара функций, объединенная в компоненте DeviceLock Signing Tool.
Первая функция — выдача временного кода доступа. Администратор DeviceLock получает от пользователя т.н. «код устройства», сгенерированный им на своей рабочей станции с помощью своего инстанса DeviceLock Signing Tool с использованием открытого ключа. Администратор вводит полученный код в нужное поле в своем инстансе DeviceLock Signing Tool, подгружает секретный ключ и генерирует ответный код, задавая срок или условие (лог-офф пользователя либо отключение устройства) прекращения его действия. Пользователь получает ответный — разблокирующий — код по телефону или другим доступным образом, вводит его в нужном поле своего инстанса DeviceLock Signing Tool и получает временный доступ к нужному устройству. Пожалуйста, перед использованием этих кодов, примите во внимание две тонкости. Первая: код устройства генерируется на основе информации о машине, сертификате и устройстве. Не используется идентификаторов конкретного инстанса агента DeviceLock. Это означает, что если на машине, где запущен апплет DeviceLock Signing Tool, после генерации DeviceCode, будет удален агент и затем установлен агент с тем же открытым ключом, то полученный на основании кода устройства код разблокировки все еще можно будет использовать. Вторая: если пользователь, сгенерировав код устройства, закрыл апплет DeviceLock Signing Tool, то открыв его заново и получив от администратора код разблокировки, он не сможет им воспользоваться; прерывание сеанса DeviceLock Signing Tool на стороне пользователя при ожидании разблокирующего кода от администратора недопустимо.
Рисунок 13. Использование временной разблокировки устройства с помощью DLTempAccess.cplВторая функция DeviceLock Signing Tool — подписывание файла настроек. Продолжим рассматривать наш пример. С помощью обмена кодами мы смогли получить временный доступ к «флешке» на компьютере, отрезанном от сети. Теперь мы хотим изменить его настройки, чтобы не дай бог не пришлось еще раз проходить через муки обмена кодами. Для этого мы получаем от администратора DeviceLock файл с нужными настройками агента, подписанный секретным ключом. Мы вставляем «флешку» с файлом настроек и применяем его с помощью локального DeviceLock Signing Tool (файл DLTempAccess.cpl в установочной директории DeviceLock). Настройки применятся, даже если они применяются от имени ограниченной учетной записи и учетной записи, не включенный в список доступа агента DeviceLock. На случай недоступности графического интерфейса, разработчики предусмотрели выполнение операции из командной строки: DLTempAccess.cpl -s <путь к подписанному файлу настроек>. К сожалению, функция установки подписанного файла настроек не работает в удаленном режиме. То есть если я помещу на диск удаленного компьютера подписанный файл настроек signed_settings_file.dls и попробую, например, следующее:
Run > cmd.exe
psexec \cmd.exe
cd C:Program FilesDeviceLock Agent
DLTempAccess.cpl -s signed_settings_file.dls…то ничего не выйдет. Можно понять разработчиков: они не ожидали, что функция может пригодиться, когда целевой компьютер онлайн. Однако такие ситуации возникают, например, при тестировании установки агентов в другом домене. Агент на удаленной машине во втором домене может не принять учетные записи первого домена в качестве членов своего списка доступа. Это может произойти из-за неправильной обработки членства во вложенных группах, из-за того, что группы, учетные записи которых добавлены в список доступа, являются локальными группами первого домена, из-за того, что не прошло достаточно времени для репликации состава групп на домен-контроллер второго домена. В этой ситуации не очень удобно просить ИТ-специалистов второго домена идти, сгонять с компьютера его пользователя и руками менять неудачные настройки агента на настройки с отключенными списком доступа.
Сетевое взаимодействие компонентов
- Использование фиксированных сетевых портов
По умолчанию, компоненты DeviceLock при сетевых взаимодействиях пытаются использовать определенные порты (агент DeviceLock, сервер DeviceLock, DeviceLock Content Security Server используют порты TCP 9132, 9133 и 9134 соответственно), но вообще используют динамическую привязку, т.е. если соответствующие порты заняты, компонент DeviceLock будет использовать другой, который даст подсистема RPC. Если же задать фиксированный порт, который займет другая служба/приложение, компонент DeviceLock не осуществит привязку к этому порту и будет недоступен для управления.
Однако в сети, разделенной на сегменты файерволами, использование фиксированных портов целесообразно. Так, если агенты находятся в защищенном сегменте, а сервер в основной сети (агенты имеют доступ в основную сеть, а основной сети доступ к ним ограничен), серверу для работы с агентами фиксированном порту нужно, чтобы на файреволе были открыты порты Tcp 139, 445, а также фиксированный порт. А для работы сервера с агентами, использующими динамическую привязку: TCP 139, 445, 135 + все порты выше 1024. Для подключения консолью к агентам, те же порты, если в строке адреса будут указываться IP-адреса удаленных машин; те же адреса + UDP 137, если в строке адреса будут указываться имена компьютеров, а не IP-адреса. Указанных портов достаточно в том числе для того, чтобы обновлять версию агента на удаленном компьютере.
- Сетевое взаимодействие сервера и агента DeviceLock
Прежде чем подробно описать сетевое взаимодействие агента и сервера, нужно сказать об общем порядке их взаимодействия.
В течение пяти минут после того, как агент DeviceLock создал записи в своем логе (например, о вставке в USB-порт устройства), он выбирает сервер DeviceLock из списка, заданного в своих настройках, чтобы передать записи на сервер для централизованного хранения. В зависимости от настройки Fast Servers First, он выбирает сервер либо случайным образом, либо тот, «цена» трафика с которым (в условных единицах) наименьшая. Агент шлет серверу запрос. Сервер получает запрос и ставит его в очередь. Когда очередь приходит, сервер начинает попытки сбора логов с агента. Если подключение удалось, то он все собирает и заканчивает сбор, удаляя соответствующий компьютер из очереди (в логе пишется). В случае ошибки подключения, сервер предпринимает еще 2 попытки с интервалом в оду минуту (в логе сервера появляется запись об этом «Collecting data from put on hold for 60 seconds», а также вторая запись с указанием когда ошибки, например ). Если и после двух других попыток, серверу не удастся подключиться к агенту, он удалит его из очереди и снова поставит его в очередь, когда тот, записав локально новую порцию логов, пришлет ему новый запрос. Если после этого соединение установится, агент передаст серверу сначала более старые записи, потом более новые.
Какие при этом используются порты? Порт, на котором работает компонент DeviceLock, используется для входящих подключений, исходящие подключения идут по портам, которые выдает подсистема RPC удаленных машин. Входящими подключениями являются:
- для серверов: отправка агентами запросов на них в связи с появившимися на агентах логами; подключения консолями к ним.
- для агентов: подключения серверов к ним для сбора логов; подключения консолями к ним
Агент отправляет запрос на IP-адрес, который либо вбит в поле DeviceLock Servers его настроек, либо резолвится из доменного имени компьютера, вбитого в это поле настроек. Система RPC компьютера, куда отправляет запрос агент, выдает ему номер Tcp-порта, на котором работает сервер. По умолчанию, это 9133. Если он занят, это один из портов выше 1024. Если в настройках сервера прописан фиксированный порт, то агенту сообщается этот порт. Происходит соединение агента с сервером, и сервер ставит в очередь запрос агента, содержащий в том числе информацию о локальном порте, на котором работает агент. Сервер подключается к агенту, используя, полученный от него номер порта (по умолчанию 9132, если занят, то порт выше 1024; если фиксированный, то фиксированный).
В настройках агента DeviceLock есть параметр Traffic priority, определяющий какую часть пропускной способности канала может занимать агент для своих целей. Оптимальным автор считает режим, когда агенту не дается больше 50%. Однако настройка работает только при условии, что на целевой машине установлена и запущена служба QoS — Quality of Service Packet Scheduler. (Не перепутайте со службой QoS Rsvp). Без службы QoS функция не работает, и агент будет занимать до 100% пропускной способности, если ему будет надо.
- Сетевое взаимодействие консоли и агента DeviceLock
Соединение консолями к агенту и сервера DeviceLock происходит по портам, указанным в настройках агента и сервера. В интерфейсе консолей нет поля настроек, в котором можно указать порт, по которому она всегда будет пытаться соединяться с удаленными машинами. Таким образом, консоль сначала подключается к RPC, которая выдает ей номер порта, после чего консоль соединяется по полученному номеру порта. Можно сократить процедуру подключения консоли, явно задав порт. Порт указывается в строке адреса для подключения консоли в квадратных скобках сразу после имени/IP адреса удаленной машины без пробелом: computer_name[port]. Указание в явном виде порта при подключении консоли к серверу избавляет консоль от необходимости подключения к RPC.
- Сетевые настройки модуля Monitoring сервера DeviceLock
Модуль «Мониторинг» сервера DeviceLock имеет свои особенности сетевых настроек. В Разделе его настроек Network discovery method возможны следующие методы:
- Ping sweep (ICMP),
- NetBIOS
- TCP Discovery (в этой строке настроек вписываются интересующие порты)
В порядке относительной скорости проверки состояния удаленных агентов по ним, их можно расположить общем случае так: ICMP, TCP, NetBIOS. Выбирается способ в зависимости от того, какие протоколы/порты открыты. Чем больше выбрано, тем надежней будет определяться, находится ли компьтер онлайн. В TCP Discovery нельзя прописывать порт агента по умолчанию (9132) либо явно заданный в настройках агента фиксированный порт. Дело в том, что по указанному в этой строке порту определяется, включен ли удаленный компьютер. Прописывание порта, на котором работает агент, наоборот внесет неясность, так как нельзя будет различить ситуации, когда выключен удаленный компьютер и когда на удаленном компьютере остановлен сервис.
Работа с логами и файлами теневого хранилища
- Просмотр логов агентов на сервере DeviceLock и через Event Viewer Windows
Агенты DeviceLock фиксируют, в зависимости от настроек, операции с теми или иными внешними устройствами, в том числе несостоявшиеся по причине запрета доступа операции. Это операции подключения и извлечения внешних устройств, чтения и записи файлов с них / на них, создания и удаления файлов, операции отправки документов на печать (в том числе на виртуальные принтеры), операции прожига дисков (в том числе записи образов дисков). В отношении синхронизированных с рабочей станцией смартфонов, возможно более детальное логирование, где раздельно отображаются такие операции, как, например, работа с записями календаря, контактов, заметок и т.д. Автор строго не рекомендует включать два вида логирования: операций с жестким диском и операций с буфером обмена. Первые настолько многочисленны, что их логирование замедляет работу целевой рабочей станции, вызывает стремительный рост размера базы данных с записями лога на сервере и вызывает неконтролируемое разрастание transaction log SQL-сервера, к которому подключен сервер DeviceLock. Операции с буфером обмена (копирование — вставка) не так многочисленны, но поскольку не ведется их теневое копирование, сами по себе записи об этих операциях несодержательны, однообразны.
Рисунок 14. Вид лога при просмотре на сервере DeviceLock через консоль DeviceLockАгенты могут вести 2 вида лога: Event Log и DeviceLock Log (настраивается в Service Options —> Auditing& Shadowing —> Audit log type). Их отличие в том, что первый хранится локально на машине и доступен для просмотра любому пользователю, а второй может быть отправлен на сервере при отключенной на агенте Default Security, а пока хранится локально, доступен для просмотра только учетным записям в списке DeviceLock Administrators. Поэтому не удивляйтесь, когда в списке записей в логе агента, вы обнаружите строки, которые не исчезают из списка и не появляются в списке на сервере, сколько бы вы ни нажимали кнопку Send Data To Server.
Рисунок 15. Вид лога DeviceLock при просмотре с помощью EventViewerАгенты DeviceLock, в зависимости от настроек, также ведут теневое копирование файлов, записываемых на различные устройства. Подлежат теневому копированию, в первую очередь, запись на Removable, CD/DVD, Floppy, а также отправка документов на печать. В режиме теневого копирования файл, записываемый на внешнее устройство, одновременно записывается в промежуточное хранилище агента DeviceLock на локальной машине. Агент, в зависимости от настроек, может переправлять файлы на сервер и удалять их из локального хранилища. Сервер может хранить сами файлы как в директории на жестком диске, так и в базе данных SQL. Последнее не рекомендуется, т.к. будет вызывать разрастание базы данных за счет неиндексируемых массивов данных. Предпочтительнее первый вариант, когда сами файлы хранятся в директории на жестком диске, а в базе данных SQL хранится индекс для быстрого доступа к файлам.
Работа с агентами DeviceLock без сервера возможна. Можно настроить лимит размера локального хранилища логов и теневых файлов и порядок действий при достижении лимита (прекращение логирования; блокировка возможности дальнейшей записи на внешние устройства; удаление старых записей в хранилище). Можно подключаться к каждому агенту по очереди с помощью DeviceLock Management Console и просматривать логи и файлы теневого хранилища. Однако такая модель неудобна, поэтому в дальнейшем речь идет только о работе с логами с подключением к серверу DeviceLock.
Сервер DeviceLock хранит три вида записей: уже описанные логи и теневые файлы, а также ServerLog — записи о событиях, связанных с сами сервером. Эти записи состоят при нормальной работе, из сообщений о получении запросов от агентов на сбор с них логов, о начале копирования логов с агентов и успешном завершении копирования. В оптимальных условиях, передача идет на 6-м уровне аутентификации RPC и в логе нет сообщений о понижении уровня аутентификации до 1-го или другого. В случае ошибок при сборе данных в записях логов присутствуют стандартные коды ошибок Windows, по которым легче установить причину неполадок.
Рисунок 16. Вид лога самого серера DeviceLock (имена компьютеров удалены) - Ограничение размера логов агентов на сервере DeviceLock
При работе с логом, особенно не очень большого размера (до 2-3 млн. записей) и на мощном сервере (на примере сервера с 22 Гб оперативной памяти) не возникает никаких затруднений. Пролистывание страниц, сортировка по полям, выдача результатов фильтрации происходят мгновенно. При работе с логом в 10-15 млн. записей на менее мощном сервере (первые гигабайты оперативной памяти, не такие быстрые жесткие диски) время ожидания при пролистывании страниц и применении фильтров составляет минуты, а сортировка по полю вызовет, скорее всего, зависание консоли. В связи с этим, если нет возможности ограничить поступающий поток логов (например, отключить логирование чтения с устройств и оставить только логирование записи) и нет возможности баловаться мощным сервером, остается три пути перечисленных ниже.
- Настроить автоматическое удаление старых записей лога на сервере по достижении определенного количества записей в логе: дерево консоли —> клик правой кнопкой по строке AuditLog Viewer —> пункт Settings —> настройки максимального количества записей и порядка действий в случае достижения максимального размера. Недостаток метода — вы не сможете хранить записи о действиях пользователей годами, что может быть полезно и даже необходимо по требованию регуляторов в крупной компании, особенно в финансовом секторе.
- регулярно обрезать старую (например, старше 1 месяца) часть таблицы [DeviceLock DB].[dbo].[DLAuditLog], сохраняя ее копию в отдельную базу данных.
- изредка обрезать старую часть таблицы и вообще не работать с логом через интерфейс консоли DeviceLock, а выполнять все те же операции — фильтрация логов по содержимому полей, выводить записи в порядке возрастания/убывания значений в полях — командами transact-SQL, подключаясь SQL Management Studio к SQL-серверу. Замедление работы с логами через интерфейс консолей DeviceLock — проблема, которую, надеюсь, разработчики рано или поздно решат. Пока же прямое обращение к SQL остается лучшим решением.
Заметьте, среди них нет выборочного удаления записей лога. Дело в том, что в логе аудита невозможно удалить отдельные записи, его только целиком можно очистить, что принципиально отличает его от лога теневого копирования. Для удаления всего лога нужно нажать правой кнопкой на строке Audit log и нажать Clear Log. К слову, пункт Clear Log не будет доступен для нажатия, если нажать правой кнопкой на Audit Log, не выбрав прежде этот пункт левой кнопкой и не дождавшись, чтобы лог загрузился в окне консоли. Таким образом, если лог слишком большой, очистить через интерфейс консоли будет просто невозможно. До загрузки лога нельзя его очистить, а его загрузка в окно консоли вызовет ее зависание. Таким образом, при необходимости полностью удалить очень большой лог, нужно прибегнуть к SQL-запросу: use DeviceLock DB exec DLClearAuditLog null (указано имя базы данных по умолчанию — DeviceLock DB).
Проблема при использовании SQL-запросов вместо интерфейса консоли DeviceLock в том, что реальные имена пользователей и компьютеров домена хранятся не в таблице DLAuditLog, а в таблицах DLUsers и DLStations. Поэтому для вывода таблицы, аналогичной по содержанию тому, что можно видеть через консоль, нужен следующий запрос (в структуру запроса включены параметры, позволяющие при необходимости дублировать функции фильтров, доступных через интерфейс консоли):
Select[DeviceLock DB].[dbo].[DLStations].[NetworkAddr]
,[DeviceLock DB].[dbo].[DLUsers].[UserName]
,[CreationDate]
,[EventId]
,[Type]
,[ProcessName]
,[Pid]
,[DeviceTypeId]
,[Action]
,[Name]
,[Info]
,[CustomData]
,[AdditionDate]
,[DeviceType]
From[DeviceLock DB].[dbo].[DLAuditLog], [DeviceLock DB].[dbo].[DLUsers], [DeviceLock DB].[dbo].[DLStations]
Where[DeviceLock DB].[dbo].[DLAuditLog].[UserId] = [DeviceLock DB].[dbo].[DLUsers].[UserId] And[DeviceLock DB].[dbo].[DLAuditLog].[CompId] = [DeviceLock DB].[dbo].[DLStations].[CompId]And[AdditionDate] >{d ''}And[DeviceType] Like'' And[Action] Like'' And [Action] NotLike''Для более тонких ухищрений с базой данных, с которой работает сервер DeviceLock, приведу запрос, которым сервер версии 6.4.1 создает базу данных (запрос сервера 7.1. отличается незначительно):CreateTable [DLAuditLog] ( [ServerId] [int] NotNull, [RecordId] [int] Identity (1, 1) Not For Replication Not Null , [CompId] [int] Not Null , [UserId] [int] Null , [CreationDate] [bigint] Null , [EventId] [int] Null , [Type] [smallint] Null , [ProcessName] [nvarchar] (1500) Null , [Pid] [int] Null , [DeviceTypeId] int Default(0) Not Null , [DeviceType] As dbo.DLGetDeviceString( DeviceTypeId ), [Action] [nvarchar] (500) Null , [Name] [nvarchar] (500) Null , [Info] [nvarchar] (500) Null , [CustomData] [ntext] Null , [AdditionDate] datetime Not Null Default( Getutcdate()) , Constraint [Pk_DLAuditLog] Primary Key Clustered ([ServerId],[RecordId])) Go Alter Table [DLAuditLog] Add Constraint [Fk_DLAuditLog_DLServers] Foreign Key ([ServerId] ) References [DLServers] ( [ServerId] ) On Update Cascade , Constraint [Fk_DLAuditLog_DLStations] Foreign Key ([ServerId],[CompId]) References [DLStations] ( [ServerId],[CompId] ), Constraint [Fk_DLAuditLog_DLUsers] Foreign Key ([ServerId],[UserId]) References [DLUsers] ([ServerId],[UserId]) Go Create Nonclustered Index [Ind_CreationDateAsc] On [DLAuditLog] ([CreationDate] Asc) Go Create Nonclustered Index [Ind_CreationDateDesc] On [DLAuditLog] ([CreationDate] Desc) Go Create Nonclustered Index [Ind_DeviceTypeIdAsc] On [DLAuditLog] ([DeviceTypeId] Asc) Go Create Nonclustered Index [Ind_AdditionDateAsc] On [DLAuditLog] ([AdditionDate] Asc) Go
Чтобы создать таблицу с идентичной структурой, лучше выполнить запрос, который на одну строчку отличается от запроса, которым DeviceLock создает эту таблицу автоматически при создании своей базы данных. В изначальном запросе третья строка выглядит так:
[RecordId] [int] Identity (1, 1)NotForReplicationNotNull,
Для целей дальнейшего копирования записей из таблицы в другую таблицу, лучше изменить эту строку, чтобы она выглядела так:
[RecordId] [int] Identity (1, 1)NotNull,
Для копирования всего содержимого таблицы DLAuditLog.db в созданную таблицу, нужно при указании колонок для копирования исключить колонку DeviceType, иначе копирование не произойдет, и появится сообщение об ошибке: «The column "DeviceType" cannot be modified because it is either a computed column or is the result of a Union operator».
Перед копированием может потребоваться дать команду:
setidentity_insert[ИмяТаблицы]On
После чего производится копирование:
insertinto[ИмяТаблицы]([ServerId],[RecordId], [CompId], [UserId], [CreationDate], [EventId], [Type], [ProcessName], [Pid], [DeviceTypeId], [Action], [Name], [Info], [CustomData], [AdditionDate])select [ServerId],[RecordId], [CompId], [UserId], [CreationDate], [EventId], [Type], [ProcessName], [Pid], [DeviceTypeId], [Action], [Name], [Info], [CustomData], [AdditionDate] fromDLAuditLog
В случае выше речь идет о копировании в таблицу, созданную в той же базе данных, что и таблица-источник. В случае, если две таблицы находятся в разных базах данных на разных серверах, возникает проблема с копированием колонки [RecordId], поскольку команда setidentity_insert[ИмяСервера.ИмяБазыДанных.ИмяСхемы.ИмяТаблицы]On не срабатывает правильно, по крайней мере в MS SQL Server 2005, о чем можно почитать в сети.
Поэтому команда setidentity_insert не используется, а колонка [RecordId] не копируется:
insertinto[ИмяСервера1.ИмяБазыДанных.ИмяСхемы.ИмяТаблицы]([ServerId], [CompId], [UserId], [CreationDate], [EventId], [Type], [ProcessName], [Pid], [DeviceTypeId], [Action], [Name], [Info], [CustomData], [AdditionDate])select [ServerId], [CompId], [UserId], [CreationDate], [EventId], [Type], [ProcessName], [Pid], [DeviceTypeId], [Action], [Name], [Info], [CustomData], [AdditionDate] from[ИмяСервера1.ИмяБазыДанных.ИмяСхемы.ИмяТаблицы]
Исключение столбца [RecordId] не оборачивается отличиями содержимого целевой таблицы от таблицы-источника, поскольку эта колонка — уникальный идентификатор записи (счетчик). При создании каждой следующей строки соответствующее значение в колонке устанавливается на 1 больше предыдущего. Копирование строк осуществляется без нарушения порядка строк, поэтому значение идентификатора (счетчика) для скопированной строки в целевой таблице равно значению счетчика соответствующей строки в таблице-источнике.
- Особенности работы с логом через интерфейс консоли DeviceLock
Если все-таки работать с логом, хранящемся на сервере, через интерфейс консоли DeviceLock (строка AuditLog Viewer), нельзя забывать о некоторых тонкостях, иначе вы столкнетесь с неприятными неожиданностями:
- Пока лог не пролистан, его нельзя экспортировать. В текстовый файл будет экспортировано столько, сколько пролистано на экране. А листать длинный лог очень долго. Поэтому функция экспорта логов лишь ограниченно полезна: она применима, когда нужно выгрузить несколько сотен записей (например, список, отфильтрованный по учетной записи или по компьютеру или по типу устройства за несколько дней).
- При фильтрации лога можно включить одновременно фильтрацию на включение и на исключение — на двух разных вкладках окна, при этом существует возможность включать/исключать несколько типов событий: достаточно указать несколько критериев, разделяя их точкой с запятой (;) без пробелов, например так: «Set Permissions; Direct Access»
- При фильтрации по имени учетной записи пользователя / компьютера, нужно писать учетную запись в полной нотации с указанием домена, либо использовать астериски (*).
- Особенности работы с теневым хранилищем
Существуют и свои особенности при работе с теневым хранилищем.
Не удивляйтесь, если некоторые файлы с нормальным расширением, не будут открываться при наличие программ для их чтения. Дело в том, что агенты DeviceLock делают теневые копии всех данных, которые пишутся непосредственно на носитель. Если файл .doc запускается, например, с флеш-карты, и затем редактируется, то в теневое хранилище в виде отдельных файлов .doc будут сохранены изменения, сделанные в файле. Такие файлы, если они содержат, главным образом, текст, как правило, очень хорошо сжимаемы. Если открыть такую теневую копию любым Hex-редактором (например, WinHex), можно увидеть, что до определенного смещения в файлах есть данные, а потом идут нули — этим объясняется хорошая сжимаемость файлов. Открыть файлы предназначенной для них программой не удается потому, что программе не хватает данных в файле для его обработки.
Рисунок 17. Вид лога теневого хранилища на сервере DeviceLockКстати, сказанное выше означает, что если вы хотите скопировать на внешний носитель данные, но не хотите, чтобы они были прочитаны, вам нужно создавать зашифрованный контейнер на локальном диске и потом готовый контейнер перемещать на внешний носитель. Если вы создадите контейнер, например, контейнер TrueCrypt на внешнем носителе, откроете его и скопируете в него файлы, они попадут в теневое хранилище DeviceLock в плейнтексте, т.к. программа будет перехватывать данные из оперативной памяти до их шифрования.
При записи большого файла на внешний носитель, например, при прожиге DVD, его теневая копия даже не появляется в локальном теневом хранилище агента, но и не сразу появляется в теневом хранилище на сервере DeviceLock. Это нормально. Компонентам нужно время на передачу данных по сети, а затем серверу нужно время, чтобы «собрать» и проверить теневую копию на предмет ее корректности. Это делается и для небольших файлов, просто для них задержки по времени не очень существенны и порой незаметны.
Не существует приоритета передачи маленьких файлов теневого копирования на сервер по отношению к большим. В очередь для передачи данных на сервер встают агенты DeviceLock, а файлы передаются на сервер в порядке времени их создания в локальном теневом хранилище агента — сначала старые, потом новые. Таким образом, передача большого файла вызовет отсрочку передачи маленьких файлов, созданных непосредственно после создания большого. При этом соответствующие теневым копиям записи логов передаются асинхронно, т.е. в теории возможны ситуации, когда на сервере уже видны записи лога (например, о записи на DVD), но еще недоступны сами файлы.
Также нужно знать, что для сокращения используемого места, сервер DeviceLock не дублирует одинаковые файлы в хранилище. Если контрольные суммы нового пришедшего на сервер файла совпадают с контрольными суммами ранее созданного, в логе теневого копирования (Shadow Log Viewer) появляется отдельная запись, но при обращении к этой записи, ей подкладывается старый файл, а не новый. Таким образом, возможна ситуация, когда вы удалили строку в логе теневого копирования (что обычно ведет к удалению соответствующего файла) с целью уменьшить размер теневого хранилища, но размер не уменьшился. Это значит, что с целевым файлам связана еще одна или более записей в логе теневого копирования.
В ряде старых версий DeviceLock (достоверно — в 6.4.1) есть ошибка в управлении теневым копированием. Если пользователь включен в две группы: одной включено логирование на чтение и запись, отключено теневое копирование; другой отключено логирование на чтение и запись, включено теневое копирование, — в соответствии с логикой разрешений DeviceLock (о чем будет сказано в разделе про интеграцию с Active Directory) должно быть в включено только логирование, но оказывается включено и то и другое.
Наконец, вам может потребоваться перенести директорию для хранения файлов теневого копирования (например, перенести на другой физический жесткий диск). Если такой перенос не сопроводить изменениями в таблицах SQL-базы данных, перенесенные данные станут недоступны для просмотра, а относящиеся к ним записи в таблицах (и соответственно — строки, видимые в ShadowLogViewer) — недоступны для удаления. По умолчанию данные пишутся в директорию %SystemRoot%DLStore. Допустим, Вам понадобилось сменить директорию на D:DLStore. Тогда гасите сервер DeviceLock в списке служб операционной системы, переносите все файлы стандартными средствами копирования (например, x-copy или robocopy), после чего подключайтесь к SQL-серверу и в БД DeviceLock DB (название по умолчанию) меняйте путь к физическим файлам, которых хранится в таблицы DLStoreUrl. Сами имена файлов теневого копирования (и прочая описательная информация) хранятся в таблице DLShadowFiles. Установить соответствие между записями в таблицах можно при помощи параметра StoreID. Таким образом, оторректировать записи в базе данных вы можете с помощью следующего SQL-запроса:
Update[DeviceLock DB].[dbo].[DLStoreUrl] Set[Url]=cast(replace(cast([Url] as nvarchar(max)),'\<Старый_ПутьДля_Замены>','\<Новый_ПутьКоторым_Следует_Заменить>') as ntext)*Где 'DeviceLock DB' — имя Вашей базы данных DeviceLock
У сервера DeviceLock есть модуль построения стандартных отчетов, где строятся графики / таблицы, например, наиболее активных пользователей / компьютеров / устройств за период времени. По данным лога и по данным теневого хранилища строятся свои наборы отчетов. Отчеты теневого хранилища позволяют выявлять лидеров по объему скопированных данных. При этом в существующих версиях программы не учитывается объем данных, теневое копирование которых запрещено правилами фильтрации содержимого (Content Aware Rules). То есть учитывается то, что есть в наличие в теневом хранилище, а не то, что могло бы там быть. Таким образом, если Вы отключили теневое копирование видео-файлов и JPEG, в лидерах вы, возможно увидите сотрудника, скопировавшего большой архив или базу данных или записавшего образ на диск, но не увидите тех, кто, возможно, в разы больше по объему скопировал видео/картинок. При этом отключать теневое копирование мультимедиа очень разумно, ведь иначе потоки видео-роликов и фотографий забивают диски сервера очень быстро. Однако строить рейтинг на неполных данных неправильно, поэтому функционал, о котором здесь говорится, запланирован разработчиками на будущие версии.
Завершим разговор о теневом хранилище неприятной темой — недоступностью для просмотра некоторых теневых копий документов, отправленных на печать. Формат теневых копий может не поддерживаться модулем сервера DeviceLock — DL PrinterViewer. В таком случае нужно будет выяснить, какой язык принтера используется в таких теневых копиях, и поискать отдельный вьюер для него. DLPrinterViewer поддерживает следующие форматы спулера: PostScrIPt, PCL5, PCL6 (PCL XL), HP-Gl/2, GDI printing (ZjStream) и EMF Spooled Files. Таким образом, в некоторых случаях, столкнувшись с проблемным принтером, можно потребовать от ИТ-специалистов, чтобы они изменили язык печати такого принтера на поддерживаемый DeviceLock. Если нужно в экстренном порядке получить данные о том, что распечатывал пользователь, и при этом допустимо позаимствовать принтер подразделения, где работает сотрудник, или принтер сотрудника (например, если дело дошло до открытого расследования инцидента информационной безопасности), то можно отправить созданную DeviceLock теневую копию на печать на тот же принтер командой:
copy /b <имя_файла> <имя_принтера>
Однако есть форматы, которые не поддерживаются DLPrinterViewer и никогда не будут поддерживаться, поскольку это закрытые форматы. Грешит их использованием, например, Hewlett-Packard. Одним из таких форматов является ZIMF. Единственная возможность просмотреть такие теневые копии — отправить их на печать на принтер с поддержкой ZIMF. Не имея возможности реализовать поддержку подобных форматов, надеюсь, разработчики создадут в будущих версиях возможность запрета печати в неподдерживаемых вьюером форматах.
- Правила фильтрации по содержимому
В заключение раздела, несколько слов о правилах фильтрации по содержимому (Content Aware Rules; контентные правила). Контентные правила позволяют изменять разрешения на доступ или настройки логирования для разных типов файлов, причем типы определяются не по расширениям, а по сигнатурам — по структуре содержимого. Поэтому список файлов, для которых можно выставлять настройки, ограничен, хотя и велик. С каждой новой версией программы список, впрочем, растет. Контентные правила очень удобно использовать, чтобы ограничить поток файлов в теневое хранилище сервера. Ограничения можно ввести для предзаданных групп типов файлов, например, «Images, Cad, and Drawing», а можно для самостоятельно скомпонованной группы файлов.
Обратите внимание, что в контентных правилах недоступна настройка исключений по типам файлов для теневого копирования записи на устройств DVD/CD-ROM. Этого нельзя сделать потому, что для DVD/CD-ROM в качестве теневой копии создается образ записанных на диск данных, который надо распаковать для того, чтобы можно было произвести контентный анализ содержимого. Распаковывать такие вещи на агентской стороне слишком ресурсоемко, поэтому этим ведает сервер. Как следствие, нет возможности применить контентный анализ для теневого копирования класса DVD/CD.
Интеграция с Active Directory
Первое, что надо запомнить, приступая к интеграции продукта с Active Directory, это то, что политики DeviceLock являются политиками компьютеров, а не политиками пользователей. Например, если Вы захотите привязать применение файла настроек агента DeviceLock не к компьютеру, а к пользователю — то есть чтобы настройки подгружались на рабочую станцию, на которой он сделал log-on, когда он делает log-on — Вы потерпите неудачу.
Иными словами, для разливки настроек применяются GPO, и в списки безопасности GPO включаются только имена компьютеров / групп компьютеров (к слову, файл настроек не захочет прикрепляться к GPO, если на машине администратора AD, который производит операцию, стоит не та версия программы, в которой создан файл настроек). Если в домене вы будете использовать несколько GPO с разными настройками DeviceLock, и фильтры безопасности этих GPO будут накладываться, помните о двух вещах: 1) порядок применение GPO, 2) тот факт, что значение строки настроек DeviceLock «Not Configured» при применении таких настроек поверх других настроек ведет к сохранению ранее имевшегося значения этой строки настроек; то есть если к машине с агентом DeviceLock будет применен GPO с файлом настроек «все доступы запретить», а затем GPO с файлом настроек «все доступы — Not Configured», запреты сохранятся.
Профили доступа доменных групп пользователей к устройствам задаются в настройках агентов DeviceLock, например, указывается, что группе Floppy_Allow (условное название) не блокируется доступ к дискетам. Доступы конкретных пользователей задаются их членством в доменных группах пользователей.
Таким образом, на первом этапе можно ко всем компьютерам домена применить GPO, определяющий настройки агента DeviceLock. Затем можно установить сам агент. Способов установки множество, в том числе также через GPO. К установленным агентам по прошествии периода репликации применятся заданные ранее для всего домена настройки DeviceLock. В результате пользователи, входящие в группу, например, Floppy_Allow, на каком бы компьютере домена они ни залогинились, получат доступ к дискетам, в то время как те, кто входят в группу, например, Floppy_Deny ни на одном компьютере домена не смогут открыть дискету (к слову, если пользователь окажется членом обоих групп, будет действовать стандартный для AD приоритет запрета; но вот если пользователь находится в группах, одна из которых разрешает полный доступ к устройству (чтение и запись), а другая разрешает неполный (только чтение), включается уже внутренняя логика DeviceLock — давать приоритет тому набору разрешений, где разрешений больше; не забудьте эту особенность программы!).
Такой подход очень удобен, он позволяет использовать архитектуру, ориентированную на пользователя, а не на рабочую станцию, и, соответственно, за счет создания единообразной среды для пользователей, обеспечивает большую мобильность пользователей внутри компании.
Необходимость создания нескольких сегментов рабочих станций с разной строгостью доступа к внешним устройствам решается выделением нескольких OU, к каждому из которых будет применен свой GPO со своими настройками DeviceLock. Тогда, не трогая структуру доменных групп пользователей, заданием разных настроек доступа для групп в разных файлах настроек, можно добиться того, что пользователь, имеющий полный доступ к дискетам на компьютерах в одном OU, будет иметь ограниченный (только чтение) доступ или не будет иметь доступа к дискетам вообще на компьютерах в другом OU.
Таким образом, комплексное использование AD для управления доступами пользователей к внешним устройствам средствами DeviceLock будет предусматривать:
- Объект групповой политики, примененный ко всему домену, предписывающий установку агентов DeviceLock;
- Объект групповой политики, примененный ко всему домену, либо несколько объектов групповой политики, примененных к нескольким организационным единицам домена, предписывающий (ие) применение агентами DeviceLock тех или иных настроек доступа доменных групп пользователей к внешним устройствам;
- Доменные группы пользователей, прописанные в применяемых с помощью объектов групповой политики настройках агентов DeviceLock.
При реализации такой схемы, для включения или отключения доступов пользователей по поступающим от пользователей авторизованным заявкам достаточно включать/исключать их учетные записи в доменные группы / из доменных групп. После изменения членства пользователя в группах всегда будет требоваться, чтобы сессия его учетной записи была завершена (log-off) и начата заново (log-on). В противном случае изменения прав доступа не вступят в силу даже по прошествии периода репликации доменной политики, поскольку только при завершении сессии учетной записи пользователя обновляется ее Security Descriptor.
В связи с тем, что могут возникать ситуации, когда требуется немедленная блокировка доступа учетной записи к устройству, у администратора безопасности должна быть возможность локально изменить настройки агента (удалить, соединившись с агентом DeviceLock на конкретной машине, из списка доступа к устройству доменную группу / группы, в которую/которые входит пользователь). Для того, чтобы такая возможность сохранялась, необходимо снять в настройках DeviceLock галочку с параметра Override Local Policy. Внимание! Эта настройка видна только в интерфейсе DeviceLock Service Settings Editor. При подключении консолью DeviceLock Management Consoleк агенту DeviceLock, эта настройка не видна, но в зависимости от ее статуса, администратор либо сможет, либо не сможет локально изменить настройки, залитые на машину объектом групповой политики. Чтобы только закрытый список администраторов мог производить такие изменения, необходимо, чтобы Default Security агента была отключена и административный доступ к нему был дан только списку учетных записей пользователей / групп в настройке DeviceLock Administrators.
На этапе развертывания возможен смешанный режим , когда на агент устанавливается на компьютеры в ручном режиме (через DeviceLock Enterprise Manager) и им же ему прописываются настройки (альтернативный вариант — через разлив MSI с заданными настройками). При этом в настройках ставится флаг Use Group Policy и снимается флаг Override Local Policy. В результате, когда компьютер окажется включен в список фильтрации GPO с новыми настройками, настройки автоматически сменятся по прошествии времени репликации либо после gpudate /force и перезагрузки либо после двух перезагрузок (это обеспечит флаг Use Gropu Policy), но после этого у администратора безопасности останется возможность быстро изменить настройки до следующей репликации (снятый флаг Override Local Policy). Последнее может быть нужно, когда доступ сотруднику надо заблокировать немедленно, но делать ему насильный лог-офф или перезагрузку нельзя.
На время развертывания, в DeviceLock предусмотрено включение в настройки доступа специальной учетной записи Everyone. По нажатии кнопки Default Settings, список разрешений наполняется спецучеткой Everyone и локальными группами Users и Administrators. Последние две можно смело удалить, а Everyone сохранить с настройками доступа — все разрешить. Можно сделать два файла настроек, отличающихся одной строкой в списке разрешений для каждого устройства — в одном будут перечислены, например, группы Deny_All, Allow_Read, Allow_All — он будет применятся для выборочной блокировки доступов. Во втором будут перечислены Deny_All, Allow_Read, Allow_All, Everyone (последняя — в режиме — все разрешить), в результате всем, кроме тех, кому явно запрещено все, все будет разрешено.
Заключение
Основная функция рассмотренной программы — отслеживание действий пользователей. Задача просто блокировки доступа к внешним устройствам на отдельных компьютерах решается стандартными средствами Active Directory и Logon-скриптами.
Продукт отличается обширными настройками, позволяющими гибко настроить работу всех компонентов. Нужно сказать, что для решения стандартного набора задач мониторинга, возложенных на подразделение информационной безопасности, большинство возможностей, которые предоставляют настройки, никогда не будет задействовано.
Также продукт показал высокую надежность. За более чем год работы агентов на более чем 1000 компьютеров случаи, когда агент занимал большое количество памяти или прекращал откликаться на внешние воздействия, были единичными. Случаи относились в основном к проблемным компьютерам: с нестандартными конфигурациями, с поврежденными ветвями реестра, с проблемами в работе и других приложений.
Из недостатков надо отметить не слишком широкий список криптографических средств, зашифрованные при помощи которых носители распознаются программой. Впрочем, насколько известно автору, список поддерживаемых криптосредств будет последовательно расширяться.
Также для отдельных специфических задач не хватает предусмотренных программой функций, но все они, насколько известно автору, планируются к внедрению в будущих версиях. К ним относятся: расширения списка интерфейсов синхронизации, которые контролируются (требуют добавления, по крайней мере Symbian и Android); добавление к модулю Monitoring сервера функции установки агентов на машины, где агенты отсутствуют; добавление в модуль Reports сервера отчета о совокупном размере файлов, которые должны были попасть в теневое хранилище при отсутствии фильтрации, а не файлов, записанных в теневое хранилище. Ну и конечно, хотелось бы, чтобы в будущих версиях программы разработчики вернулись к MSI-файлам маленького размера.
