Как обойти DeviceLock, или еще раз о пользе тестирования

Один мой институтский дипломник решил взять тему "внедрение системы контроля съемных носителей на предприятии". Проводя исследование проблематики вопроса, встал перед выбором программного продукта для технической реализации поставленной задачи и решил остановиться на ПО под названием DeviceLock компании SmartLine: продукт известнейший и обладающий массой регалий, включая всевозможные сертификаты (в том числе и ФСТЭК). Как полагается, развернул тестовую мини-лабораторию из 4 машин (три клиентских с разными версиями ОС Windows, одна - сервер управления), и скачал с сайта демонстрационную версию. Потратив время на изучение достаточно толстого мануала, начал разбираться в настройках, "развернул" ПО на всех четырех машинах и начал понемногу тестировать.

И вроде бы все работало хорошо: на стареньких машинах с Windows XP блокировались и принтеры, и флешки, и сидиромы, и весь остальной функционал проходил "на ура". Однако все резко изменилось, когда дело дошло до более мощной машины с Windows 7. При подключении к ней коммуникатора с Windows Mobile "на борту" система никаким образом не реагировала и свободно давала возможность подключить, синхронизировать контент, получить доступ к памяти устройства и даже запустить Internet Sharing. При этом, на других машинах с аналогичными устройствами, синхронизация и Internet Sharing тоже работали, однако доступ к внутренней памяти был заблокирован. Что он только не делал: и переустанавливал софт, и сто раз перепроверял настройки - бесполезно. Параллельно выяснилось, что доступ к принтеру на W7 ПО также не блокировало. И наконец, настало время обратиться в техподдержку...

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

Дело в том, что для корректной работы функции контроля, которая внедряется в приложения, работающие с такими устройствами как iPhone, WinMobile, Palm, Printers, Blackberry, требуется хотя бы 5 секунд после запуска приложения. Допустим, открыв документ WORD и сразу же отправив его на печать, при закрытом доступе для Всех печать пройдет и в аудит логе ничего не отобразится. Но если открыть документ и подождать5-7 секунд перед отправкой на печать, то печать запретится. То же самое и с WinMobile: если WMDC довольно таки быстро запускает все свои сервисы и начинает синхронизацию, то она проходит, если немного замедляется, то инжект успевает перехватить действия. В будущей новой версии задействован уже новый механизм контроля, благодаря которому такая проблема решится. Сейчас же, когда ожидается выход новой версии (7.0) кардинально изменять код под 6.4.1 не имеет смысла, на это уйдет еще больше времени, чем подождать когда выйдет 7.0.

На резонное замечание о том, что во-первых, как заставить пользователей "подождать 5-7 секунд перед печатью после запуска приложения" (на практике Windows Mobile не блокировался и через минуту, и через пять), и, во-вторых, как такой "баг" позволил получить сертификат ФСТЭК, или сертифицированная версия чем-то отличается он несертифицированной, было отвечено пожиманием плечами и словами о том, что "поиск багов и глюков в продукте процедура сертификации не включает".

Так что, уважаемые коллеги, внимательно относитесь к процедуре тестирования любого ПО перед принятием решения о его использовании. Сторонникам "сертифицированного" ПО, мне кажется, также стоит несколько пересмотреть свои взгляды...