Что требовалось

Одним прекрасным вечером появилась экстренная необходимость дополнительной защиты от “кривых” или “умышленных рук”. Так как основой нашей базы данных служит MS ACCESS, то в нем встречается несколько неприятных моментов таких как применения горячих клавиш (удаление, печать и прочие) и наш разработчик не удосужился их отключить. Собственно, времени разбираться с макросами Access и правами юзеров на их использование не было, да и сама идея отключения всех функциональных клавиш на клавиатуре решало еще и попутные задачи встроенного элемента управления типа «Веб браузер» – запрет на удаление файлов созданных пользователем, запрет вызова справки и горячих клавиш в программах просмотра изображений и PDF. Дырку надо было залатать быстро и дождаться нашего разработчика из отпуска.

Предварительный анализ и план действий

Решение которое сразу пришло на ум, это создать параметр в реестре Scancode Map по адресу HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout и прописать в нем все необходимые переназначения клавиш, но достаточно быстро выяснилось, что это не работает по RDP, да и к тому же применялось полностью к системе затрагивая привилегированных пользователей, которым позволено использовать горячие клавиши.

Далее вспомнил про Microsoft Keyboard Layout Creator, которым в свое время редактировал раскладку клавиатуры домашнего компьютера, но увы в новую версию так и не добавили работу с системными клавишами.

Изучив просторы интернета путного и жизнеспособного решения найдено не было. Оставалось одно – создание собственной раскладки и добавление ее в систему. Для начала был изучены файлы KBDRU.dll и KBDUS.dll после чего стало понятно, что собственными силами за вечер разобраться будет крайне сложно. Обзор программ, которые могут решить данную проблему не занял много времени и у всех были свои недостатки, самый главный из которых – установка их на сервер, что является крайне нежелательной мерой. Достойные из программ судя по отзывам были: KbdEdit и Keyboard Layout Manager 2000.

И тут нашлась подсказка, что можно создать раскладку на виртуальной машине при помощи вышеуказанных программ, а Microsoft Keyboard Layout Creator использовать как компилятор установочных файлов новой раскладки на сервер.

Делаем

Но не все оказалось так просто. Изучив KbdEdit стало сразу подозрительным, что создаваемый им файл раскладки dll веси более 50KB а оригинал 7KB, а так же что раскладка работать не будет в отсутствие данной программы. Файлы, созданные Keyboard Layout Manager весили 9KB, что было вполне приемлемо.

Переходим к настройке KLM2000, ничего сложного, создаем новую раскладку, на базе существующей и выбираем редактировать, все ненужные системные и функциональные клавиши отключаем (в моем случае все что выделено красным). Единственное с чем немного пришлось повозиться это с NUMPAD, чтобы данные (выделено синим) клавиши не несли в себе функции системных необходимо сделать некоторые переназначения: “0” не трогаем, на “.” выбираем значение параметра Virtual Key – VK_OEM_PERIOD, на “1” — unassigned 0x89, “2” — 0x8A, “3” — 0x8B, “4” — 0x8C, “5” — 0x8D, “6” — 0x8E, “7” — 0x8F, “8” — 0x92, “9” — 0x93.
Сохраняем Export, и применяем в системе OK.





Далее открываем Microsoft Keyboard Layout Creator, выбираем данную раскладку пытаемся сохранить и видим ошибку. К сожалению, MKLC не пропускает раскладку с отключенными системными клавишами. Тогда копируем из папок Windows\System32 и Windows\SysWOW64 dll созданные KLM2000, а на другой машине при помощи MKLC создаем установочные файлы на базе стандартной раскладки, а в свойствах указываем имя раскладки, которое мы указали, когда создавали раскладку при помощи KLM2000.

Далее на сервере устанавливаем раскладку клавиатуры, созданную при помощи MKLC, а файлы dll созданные KLM2000 копируем в соответствующие папки Windows\System32 и Windows\SysWOW64 на сервере.

Важно

Для корректной работы, и это обязательно, должна быть только одна раскладка клавиатуры для одного языка. Не забываем про параметр в реестре IgnoreRemoteKeyboardLayout, чтобы не цеплялась раскладка клиента. Перезагружаемся.

Дополнение

Если к этому всему добавить следующие изменения для конкретного пользователя в реестре:

• отключить «Drag and Drop» («DragHeight» и «DragWidth»)
• отключить контекстное меню в проводнике («NoViewContextMenu» и «NoTrayContextMenu»)
• установить открытие файлов по одному щелчку мыши

— то получим, что пользователь из под Встроенного элемента управления типа «Веб браузер» в MS Access ни переименовывать, ни копировать, ни удалять, ни перемещать файлы не сможет даже те, которые созданы MS ACCESS из под его учетной записи. (создает ACCESS файлы по следующей процедуре, сначала в папке назначения создается временный файл, а потом он переименовывается в итоговый, поэтому запрет на изменение в групповых политиках тут не подходят).

Заключение

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

В целом задача по очень быстрой заплатке была решена, без установки на сервер, каких либо сторонних программ, что есть хорошо.