vdevid lock что это такое

DLP-система DeviceLock 8.2 — дырявый штакетник на страже вашей безопасности

В октябре 2017 года довелось побывать на рекламном семинаре DLP-системы DeviceLock, где помимо основного функционала защиты от утечек типа закрытия USB-портов, контекстного анализа почты и буфера обмена рекламировалась защита от администратора. Модель простая и красивая — в маленькую фирму приходит установщик, ставит комплекс программ, паролит БИОС, создает администраторскую учетку DeviceLock, а местному админу оставляет только права на управление собственно Виндой и остальным софтом. Даже в случае умысла этот админ ничего украсть не сможет. Но это все теория…

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

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

На все вопросы о защите наверняка имеющихся в составе продукта драйверов представитель фирмы-разработчика Смарт Лайн уверенно заявлял, что «все на том же уровне».

Через день решил продолжить изыскания, скачал пробную версию. Сразу же удивил размерчик дистрибутива почти в 2 Гб! Привык, что системное ПО, к которому принято относить средства защиты информации (СЗИ), обычно имеет гораздо более компактный размер.

После установки удивился 2й раз — размер вышеупомянутого ехе-шника тоже весьма немаленький — 13Мб. Сразу подумалось, что при таком объеме есть за что зацепиться. Попробовал подменить модуль с помощью отложенной записи — закрыто. Покопался в каталогах программы, а там одних драйверов аж 11 штук! Потыкал в разрешения — не закрыты для изменения! Ну ладно, всем запрет, перегружаемся!

Эффект просто феерический — все функции отключились, служба не стартовала. Какая там самозащита, бери и копируй что хочешь хоть на флешки, хоть по сети. Вылез первый серьезный недостаток системы — слишком сильная взаимосвязь компонентов. Да, служба с драйверами должна общаться, но падать то зачем, если никто не отвечает? В итоге один метод обхода защиты есть.

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

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

Причем на рынке полно примеров грамотной реализации защиты от отключения, например отечественные антивирусные средства, где самозащиту просто так не объедешь. Насколько мне известно, они не поленились пройти сертификацию ФСТЭК.

Проведя несколько бесед с сотрудниками Смарт Лайн, несколько подобных мест, о которых они даже не слышали, было найдено. Один из примеров — механизм АррInitDll.

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

Вызывает вопросы полное отсутствие комплексного подхода к построению автоматизированой системы на базе DL 8.2. Предлагается живописать заказчику преимущества продукта, проверить вычислительную мощность имеющихся ПК и серверов (контекстные анализаторы весьма ресурсоемки и модные сейчас офисные моноблоки и неттопы на базе Атом в данном случае не подходят) и просто накатить сверху изделие. При этом такие термины, как «разграничение доступа», «замкнутая программная среда», даже не прозвучали на семинаре. Про шифрование было сказано, что помимо сложности оно вызовет вопросы регуляторов, хотя реально никаких проблем с этим нет. Вопросы про сертификацию даже во ФСТЭК отметаются ввиду их якобы сложности и затянутости. Как специалист по ИБ, неоднократно принимавший участие в подобных процедурах, могу сказать, что в процессе их проведения выявляется множество уязвимостей, подобных описанным в данном материале, т.к. специалисты сертифицирующих лабораторий имеют серьезную профильную подготовку.

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

Реально защитить она может разве что реально большие данные от непривилегированного пользователя, т.к. администратор вполне способен полностью деактивировать защиту, а для необъемных секретов и младший менеджер по клинингу догадается незаметно сфотографировать экран, а то и запомнить адресок или номер кредитки, заглянув в экран через плечо коллеги.
Причем все это справедливо только в случае невозможности физического доступа сотрудников к внутренностям ПК или хотя бы к БИОС для активации загрузки с внешних носителей. Тогда может не помочь даже БитЛокер, который вряд ли применяется в фирмах, которые только задумались о защите информации.

Вывод, как это ни банально звучит, в комплексном подходе к ИБ, включая не только программно/аппаратные решения, но и организационно-технические меры для исключения фото/видеосъемки и недопуска на объект посторонних «мальчиков с феноменальной памятью». Полагаться на чудо-продукт DL 8.2, рекламируемый как одношаговое решение большинства проблем с безопасностью предприятия нельзя ни в коем случае.

Источник

Vdevid lock что это такое

Согласно правилам ресурса 4pda перед написанием сообщения в теме необходимо ознакомиться с шапкой, FAQ, выполнить поиск по теме и лишь тогда, при отсутствии ответа на интересующий вопрос, задавать его в теме. Если Ваше сообщение удалено, значит на интересующий Вас вопрос есть ответ в шапке, теме, FAQ или вопрос является оффтопом для данной темы. Если Вам интересна причина удаления поста, то Вы можете обратиться к куратору темы в QMS, чтобы получить разъяснение по поводу удаления Вашего сообщения.
Пункты правил, которые нужно внимательно прочесть и выполнить перед написанием сообщения в теме:

4.1. Перед созданием новой темы или сообщения следует внимательно ознакомиться с принятыми в этом разделе правилами.

4.3. Не торопитесь создавать тему, сообщение. Весьма вероятно, что ваш вопрос обсуждался ранее, либо существует тема обсуждения вашего девайса. Не забудьте обратить внимание на подраздел «Важное» в соответствующем вашему вопросу разделе. Воспользуйтесь поиском. При этом последовательно совершите поиск по нескольким подходящим ключевым словам. Например, если ваш вопрос связан с использованием Bluetooth на Qtek S100, следует искать по словам «Bluetooth» и «Qtek».

4.4. Если вы нашли тему, которая соответствует вашей проблематике, не следует сразу же писать в ней сообщение. Возможно, ваша проблема уже обсуждалась, и решение найдено. Воспользуйтесь «версией для печати» и поиском по ключевым словам в ней. Непременно прочитайте шапку темы — в неё помещается полезная информация, специально для вас.

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

3.1. Прежде чем задать вопрос, прочтите FAQ по Устройству и по Прошивке (ссылка на FAQ размещается в шапке темы обсуждения прошивки устройства), если такой имеется. Если Вы не нашли ответа на свой вопрос в FAQ по вашему устройству, или же он отсутствует, то поищите похожие вопросы в общем FAQ по Android и только если ответа там нет спрашивайте. Пользователи, задающие вопросы, ответы на которые занесены в FAQ могут быть наказаны на усмотрение модератора (РО от 1 до 3 дней).

Источник

Средство предотвращения утечек данных DeviceLock

Программа DeviceLock предназначена для управления доступом пользователей ОС семейства Windows к периферийным устройствам хранения и обработки данных, а также для контроля действий пользователей с устройствами (вставка, чтение, запись файлов, форматирование, извлечение) и для контроля содержимого скопированных файлов.

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

Ниже в случаях, если специально не указывается версия и билд программы, имеется в виду версия 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 из папки с дистрибутивом программы используется, как правило, только для установки программы на компьютер, с которого сервер и сервисы будут контролироваться консолями, на сервер и на контроллер домена при необходимости интеграции с Active Directory — создания GPO, определяющих настройки агента DeviceLock на тех или иных группах компьютеров в домене. При установке консолей и сервера через setup.exe из дистрибутива на одну и ту же машину нужно иметь в виду следующее: если Вы хотите, чтобы Вам был доступен DeviceLock Enterprise Manager, проводите установку в два этапа: сначала выбирайте в мастере установки: Service+Consoles, потом запускайте setup.exe повторно и выбирайте Server+Consoles. Если Вы сразу выберете первый вариант, DeviceLock Enterprise Manager не установится, и для установки его потребуется сначала удалить установленные компоненты, а потом запустить Service+Consoles. Остается только гадать, зачем разработчики ввели это странное ограничение.

Для установки агента DeviceLock, требуется файл DeviceLock Service.msi либо DeviceLock Servicex64.msi, в зависимости от целевой операционной системы. Если ИТ-инфраструктура позволяет, для массовой установки агентов на компьютеры сети, лучше обойтись без использования консолей производителя, т.к. в них не предусмотрены механизмы автоматического контроля наличия агента на машинах и доустановки на ранее недоступные машины, выходящие в онлайн. Устанавливать агенты DeviceLock можно через применение GPO к доменам/контейнерам/фильтрам безопасности или средствами SMS/SCCM. Используемый MSI-файл может быть либо «голым», т.е. без установленных настроек (такой агент ничего не блокирует, ничего не логирует и не защищен от удаления/изменения из-под любой привилегированной учетной записи), либо со встроенными настройками. MSI-файл со встроенными настройками создается с помощью DeviceLock Service Settings Editor из обычного MSI-файла. Устанавливать «голый» MSI не рекомендую; т.к. такой агент смогут удалить на своих машинах люди с привилегированными учетными записями до того, как репликацией групповых политик до них докатятся настройки. А уж подключаться ко всем агентам через DeviceLock Enterprise Manager после установки через SMS/SCCM — вообще двойная работа, не говоря о том, что за промежуток времени между установкой и попыткой залить настройки целевая машина может уйти в оффлайн.

Если инфраструктура 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 прямым запуском файла setup.exe на любой машине без участия пользователя. Для такой установки нужно запустить setup.exe на локальной или удаленной (например, с помощью psexec.exe) машине с параметром /s. При этом параметры установки будут браться из файла DeviceLock.ini из той же директории, где находится setup.exe.

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

Для этого при наличии у вас pstools, можно использовать следующий простой скрипт командной строки:

Если все работает правильно, то при выполнении скрипт запросит у Вас пароль. Если Вы правильно введете пароль, скрипт отработает, и при отсутствии ошибок в его работе, Вам будет сообщено следующее:

cmd exited on Pc01455 with error code 0.

Лицензии DeviceLock требуются для консолей управления DeviceLock и отдельно лицензируемых модулей DeviceLock Content Security Server, ContentLock и NetworkLock. Для автономной работы агентов лицензии не нужны, поэтому если вы захотите с помощью DeviceLock запретить всем пользователям доступ к определенным устройствам, настройки запрета разольете через GPO и не будете включать логирование событий, вы можете это сделать, не покупая лицензию, на любом числе компьютеров. Количество лицензий определяет то, для скольких машин одновременно можно будет запустить задание через DeviceLock Enterprise Manager и сколько машин сможет отчитываться перед сервером DeviceLock. При нехватке лицензий всегда можно запустить задание в DeviceLock Enterprise Manager в несколько заходов, поднять несколько серверов DeviceLock и прописать в настройках нескольких групп агентов DeviceLock разные имена серверов DeviceLock. Поднять сервера можно в том числе на одной физической машине, создав на ней несколько виртуальных и настроив NAT — переадресацию сетевого трафика по определенным портам на виртуальные сетевые адаптеры с физического. Это еще одна ситуация, в которой может потребоваться использование фиксированных портов. Впрочем, все вышесказанное — голая теория, т.к. такие ухищрения с лицензиями противозаконны, и я искренне надеюсь, что разработчики рано или поздно создадут механизмы защиты от подобных злоупотреблений.

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

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

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

Начиная с седьмой версии программы, появился также контроль доступа к буферу обмена 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 получить не удастся, ведь настройка для порта важнее. Во втором же тип устройств Removable (они же USB Storage) перестает подчиняться иерархии, и доступ к Removable становится возможен.

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

Лучше понять этот момент позволят следующие таблицы:

Доступ пользователя Xк Removable при разных настройках и исключениях доступа в DeviceLock:

Результирующий доступ пользователей к Removable при выставленном флажке Access control for USB Storage devices:

Доступ пользователей к USBPort и Removable при снятом флажке Access control for USB storage devices:

Взаимосвязь между доступами к другим портам и соответствующим им типам устройств аналогична.

Самое страшное по контролю доступа к устройствам позади. Напоследок хочется сказать пару слов о доступе к 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 синим экраном смерти.

Третий эшелон защиты — это мониторинг активности агентов и восстановление целостности их настроек с помощью модуля «Мониторинг» сервера DeviceLock. В частности, модуль будет уведомлять, удаленный агент замолчал, если злоумышленники все-таки узнали имя сервера / IP-адрес и порт и загасил коммуникации на них.

Впрочем, последняя задача может решаться иначе — select-ом из таблицы DLstationsSQL-базы данных DeviceLock с определенной глубиной по дате последнего репорта на сервер (например, 24 часа), сопоставлением списка со списком машин в домене/OU, на которых агент должен стоять.

Использование криптографических ключей при авторизации соединения консолями DeviceLock Management Console и DeviceLock Enterprise Manager с сервером или агентом не предусмотрено. Доступ будет даваться либо административным учетным записям, либо учетным записям, включенным в список доступа на сервере / агенте. При этом на сервере можно задать для каждой учетной записи режим доступа полный (с возможностью удалять содержимое логов) либо только чтение.

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

У криптографических ключей существует второе применение, и оно на взгляд автора так важно, что с первого дня развертывания необходимо снабдить все агенты публичным криптографическим ключом. Ключи применяются для 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 на стороне пользователя при ожидании разблокирующего кода от администратора недопустимо.

…то ничего не выйдет. Можно понять разработчиков: они не ожидали, что функция может пригодиться, когда целевой компьютер онлайн. Однако такие ситуации возникают, например, при тестировании установки агентов в другом домене. Агент на удаленной машине во втором домене может не принять учетные записи первого домена в качестве членов своего списка доступа. Это может произойти из-за неправильной обработки членства во вложенных группах, из-за того, что группы, учетные записи которых добавлены в список доступа, являются локальными группами первого домена, из-за того, что не прошло достаточно времени для репликации состава групп на домен-контроллер второго домена. В этой ситуации не очень удобно просить ИТ-специалистов второго домена идти, сгонять с компьютера его пользователя и руками менять неудачные настройки агента на настройки с отключенными списком доступа.

Сетевое взаимодействие компонентов

По умолчанию, компоненты DeviceLock при сетевых взаимодействиях пытаются использовать определенные порты (агент DeviceLock, сервер DeviceLock, DeviceLock Content Security Server используют порты TCP 9132, 9133 и 9134 соответственно), но вообще используют динамическую привязку, т.е. если соответствующие порты заняты, компонент DeviceLock будет использовать другой, который даст подсистема RPC. Если же задать фиксированный порт, который займет другая служба/приложение, компонент DeviceLock не осуществит привязку к этому порту и будет недоступен для управления.

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

В течение пяти минут после того, как агент DeviceLock создал записи в своем логе (например, о вставке в USB-порт устройства), он выбирает сервер DeviceLock из списка, заданного в своих настройках, чтобы передать записи на сервер для централизованного хранения. В зависимости от настройки Fast Servers First, он выбирает сервер либо случайным образом, либо тот, «цена» трафика с которым (в условных единицах) наименьшая. Агент шлет серверу запрос. Сервер получает запрос и ставит его в очередь. Когда очередь приходит, сервер начинает попытки сбора логов с агента. Если подключение удалось, то он все собирает и заканчивает сбор, удаляя соответствующий компьютер из очереди (в логе пишется). В случае ошибки подключения, сервер предпринимает еще 2 попытки с интервалом в оду минуту (в логе сервера появляется запись об этом «Collecting data from put on hold for 60 seconds», а также вторая запись с указанием когда ошибки, например ). Если и после двух других попыток, серверу не удастся подключиться к агенту, он удалит его из очереди и снова поставит его в очередь, когда тот, записав локально новую порцию логов, пришлет ему новый запрос. Если после этого соединение установится, агент передаст серверу сначала более старые записи, потом более новые.

Агент отправляет запрос на IP-адрес, который либо вбит в поле DeviceLock Servers его настроек, либо резолвится из доменного имени компьютера, вбитого в это поле настроек. Система RPC компьютера, куда отправляет запрос агент, выдает ему номер Tcp-порта, на котором работает сервер. По умолчанию, это 9133. Если он занят, это один из портов выше 1024. Если в настройках сервера прописан фиксированный порт, то агенту сообщается этот порт. Происходит соединение агента с сервером, и сервер ставит в очередь запрос агента, содержащий в том числе информацию о локальном порте, на котором работает агент. Сервер подключается к агенту, используя, полученный от него номер порта (по умолчанию 9132, если занят, то порт выше 1024; если фиксированный, то фиксированный).

В порядке относительной скорости проверки состояния удаленных агентов по ним, их можно расположить общем случае так: ICMP, TCP, NetBIOS. Выбирается способ в зависимости от того, какие протоколы/порты открыты. Чем больше выбрано, тем надежней будет определяться, находится ли компьтер онлайн. В TCP Discovery нельзя прописывать порт агента по умолчанию (9132) либо явно заданный в настройках агента фиксированный порт. Дело в том, что по указанному в этой строке порту определяется, включен ли удаленный компьютер. Прописывание порта, на котором работает агент, наоборот внесет неясность, так как нельзя будет различить ситуации, когда выключен удаленный компьютер и когда на удаленном компьютере остановлен сервис.

Работа с логами и файлами теневого хранилища

Агенты DeviceLock фиксируют, в зависимости от настроек, операции с теми или иными внешними устройствами, в том числе несостоявшиеся по причине запрета доступа операции. Это операции подключения и извлечения внешних устройств, чтения и записи файлов с них / на них, создания и удаления файлов, операции отправки документов на печать (в том числе на виртуальные принтеры), операции прожига дисков (в том числе записи образов дисков). В отношении синхронизированных с рабочей станцией смартфонов, возможно более детальное логирование, где раздельно отображаются такие операции, как, например, работа с записями календаря, контактов, заметок и т.д. Автор строго не рекомендует включать два вида логирования: операций с жестким диском и операций с буфером обмена. Первые настолько многочисленны, что их логирование замедляет работу целевой рабочей станции, вызывает стремительный рост размера базы данных с записями лога на сервере и вызывает неконтролируемое разрастание transaction log SQL-сервера, к которому подключен сервер DeviceLock. Операции с буфером обмена (копирование — вставка) не так многочисленны, но поскольку не ведется их теневое копирование, сами по себе записи об этих операциях несодержательны, однообразны.

Агенты могут вести 2 вида лога: Event Log и DeviceLock Log (настраивается в Service Options —> Auditing& Shadowing —> Audit log type). Их отличие в том, что первый хранится локально на машине и доступен для просмотра любому пользователю, а второй может быть отправлен на сервере при отключенной на агенте Default Security, а пока хранится локально, доступен для просмотра только учетным записям в списке DeviceLock Administrators. Поэтому не удивляйтесь, когда в списке записей в логе агента, вы обнаружите строки, которые не исчезают из списка и не появляются в списке на сервере, сколько бы вы ни нажимали кнопку Send Data To Server.

Агенты DeviceLock, в зависимости от настроек, также ведут теневое копирование файлов, записываемых на различные устройства. Подлежат теневому копированию, в первую очередь, запись на Removable, CD/DVD, Floppy, а также отправка документов на печать. В режиме теневого копирования файл, записываемый на внешнее устройство, одновременно записывается в промежуточное хранилище агента DeviceLock на локальной машине. Агент, в зависимости от настроек, может переправлять файлы на сервер и удалять их из локального хранилища. Сервер может хранить сами файлы как в директории на жестком диске, так и в базе данных SQL. Последнее не рекомендуется, т.к. будет вызывать разрастание базы данных за счет неиндексируемых массивов данных. Предпочтительнее первый вариант, когда сами файлы хранятся в директории на жестком диске, а в базе данных SQL хранится индекс для быстрого доступа к файлам.

Работа с агентами DeviceLock без сервера возможна. Можно настроить лимит размера локального хранилища логов и теневых файлов и порядок действий при достижении лимита (прекращение логирования; блокировка возможности дальнейшей записи на внешние устройства; удаление старых записей в хранилище). Можно подключаться к каждому агенту по очереди с помощью DeviceLock Management Console и просматривать логи и файлы теневого хранилища. Однако такая модель неудобна, поэтому в дальнейшем речь идет только о работе с логами с подключением к серверу DeviceLock.

Сервер DeviceLock хранит три вида записей: уже описанные логи и теневые файлы, а также ServerLog — записи о событиях, связанных с сами сервером. Эти записи состоят при нормальной работе, из сообщений о получении запросов от агентов на сбор с них логов, о начале копирования логов с агентов и успешном завершении копирования. В оптимальных условиях, передача идет на 6-м уровне аутентификации RPC и в логе нет сообщений о понижении уровня аутентификации до 1-го или другого. В случае ошибок при сборе данных в записях логов присутствуют стандартные коды ошибок Windows, по которым легче установить причину неполадок.

Заметьте, среди них нет выборочного удаления записей лога. Дело в том, что в логе аудита невозможно удалить отдельные записи, его только целиком можно очистить, что принципиально отличает его от лога теневого копирования. Для удаления всего лога нужно нажать правой кнопкой на строке Audit log и нажать Clear Log. К слову, пункт Clear Log не будет доступен для нажатия, если нажать правой кнопкой на Audit Log, не выбрав прежде этот пункт левой кнопкой и не дождавшись, чтобы лог загрузился в окне консоли. Таким образом, если лог слишком большой, очистить через интерфейс консоли будет просто невозможно. До загрузки лога нельзя его очистить, а его загрузка в окно консоли вызовет ее зависание. Таким образом, при необходимости полностью удалить очень большой лог, нужно прибегнуть к SQL-запросу: use DeviceLock DB exec DLClearAuditLog null (указано имя базы данных по умолчанию — DeviceLock DB).

Проблема при использовании SQL-запросов вместо интерфейса консоли DeviceLock в том, что реальные имена пользователей и компьютеров домена хранятся не в таблице DLAuditLog, а в таблицах DLUsers и DLStations. Поэтому для вывода таблицы, аналогичной по содержанию тому, что можно видеть через консоль, нужен следующий запрос (в структуру запроса включены параметры, позволяющие при необходимости дублировать функции фильтров, доступных через интерфейс консоли):

Чтобы создать таблицу с идентичной структурой, лучше выполнить запрос, который на одну строчку отличается от запроса, которым 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».

Перед копированием может потребоваться дать команду:

После чего производится копирование:

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.ИмяБазыДанных.ИмяСхемы.ИмяТаблицы]

Существуют и свои особенности при работе с теневым хранилищем.

Кстати, сказанное выше означает, что если вы хотите скопировать на внешний носитель данные, но не хотите, чтобы они были прочитаны, вам нужно создавать зашифрованный контейнер на локальном диске и потом готовый контейнер перемещать на внешний носитель. Если вы создадите контейнер, например, контейнер 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 теневую копию на печать на тот же принтер командой:

В заключение раздела, несколько слов о правилах фильтрации по содержимому (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.

При реализации такой схемы, для включения или отключения доступов пользователей по поступающим от пользователей авторизованным заявкам достаточно включать/исключать их учетные записи в доменные группы / из доменных групп. После изменения членства пользователя в группах всегда будет требоваться, чтобы сессия его учетной записи была завершена (log-off) и начата заново (log-on). В противном случае изменения прав доступа не вступят в силу даже по прошествии периода репликации доменной политики, поскольку только при завершении сессии учетной записи пользователя обновляется ее Security Descriptor.

В связи с тем, что могут возникать ситуации, когда требуется немедленная блокировка доступа учетной записи к устройству, у администратора безопасности должна быть возможность локально изменить настройки агента (удалить, соединившись с агентом DeviceLock на конкретной машине, из списка доступа к устройству доменную группу / группы, в которую/которые входит пользователь). Для того, чтобы такая возможность сохранялась, необходимо снять в настройках DeviceLock галочку с параметра Override Local Policy. Внимание! Эта настройка видна только в интерфейсе DeviceLock Service Settings Editor. При подключении консолью DeviceLock Management Consoleк агенту DeviceLock, эта настройка не видна, но в зависимости от ее статуса, администратор либо сможет, либо не сможет локально изменить настройки, залитые на машину объектом групповой политики. Чтобы только закрытый список администраторов мог производить такие изменения, необходимо, чтобы Default Security агента была отключена и административный доступ к нему был дан только списку учетных записей пользователей / групп в настройке DeviceLock Administrators.

На время развертывания, в 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-файлам маленького размера.

Источник