Шифрование содержимого полей в таблицах.
Здесь необходимо уточнить. Можно шифровать всю базу данных, а можно шифровать содержимое отдельных полей в таблицах. Рассмотрим для начала вторую возможность.
Этот способ защиты не плох. Во всяком случае, появляется реальная надежда, что-то спасти. Однако есть ряд ограничений. Шифровать следует только символьные поля или поля типа MEMO. Немного подумав, Вы сами поймете, почему так. Ну, хотя бы, при шифровании числовых полей, Вы можете получить в результате нечисловое значение. Впрочем, и это легко обходится. Я встречал варианты, когда счетчик записи использовался для шифрования числовых данных. Например, складывался с нужным числом. Или из счетчика бралась последняя цифра и добавлялась к числу. Но шифровать числовые данные допустимо только в особых случаях, когда их значение может быть однозначно привязано к определенному объекту или действию. В остальных случаях достаточно шифровать символьную информацию. Да и то выборочно. Например, названия клиентов, их адреса, контактные телефоны, реквизиты банковских счетов, фамилии и должности представителей заказчика (клиента). В общем, в зависимости от требований, шифроваться должно то, что однозначно позволяет идентифицировать запись.
Чем и как можно шифровать? Всем, чем угодно и как угодно. Здесь всё зависит от Вашего умения и опыта. Можно написать собственную функцию. Можно использовать специальные библиотеки. Пример можно посмотреть на сайте Сергея Подосенова (aka SRG), вот здесь http://mdbprogs.narod.ru/arCL.htm . Можно сочетать приятное с полезным, не шифровать, а сжимать содержимое поля, используя библиотеки архивирования данных. Например, zlib.dll (zlibwapi.dll). Адрес сайта http://www.zlib.net/ . А если Вы горите желанием, то и сами можете разработать подпрограмму сжатия. Но не стоит без нужды усложнять алгоритм шифрования, ведь перед отображением и обработкой данных их необходимо дешифровать. А на это необходимо время. И чем больше полей у Вас зашифровано, чем навороченнее алгоритм шифрования, тем больше времени на это уходит.
Ну, а теперь, как всегда, переходим к недостаткам этого метода. О том, что на это уходит время, я упоминал. Нельзя напрямую вводить в таблицы и формы данные, подлежащие шифрованию. Приходится делать для ввода и редактирования записей, содержащих шифрованные или сжатые данные, специальные формы. Но в некоторых случаях это даже к лучшему. Можно разрешить доступ к таким формам только определенным пользователям, с соответствующими привилегиями. Если Вы используете самописные функции (функции собственной разработки), то алгоритм шифрования и ключ содержатся в программе, а значит, есть и потенциальная уязвимость. В этом случае рекомендуется эти подпрограммы вынести в отдельный модуль. Если у пользователя клиентская часть будет в формате MDE, то он не сможет определить, какой файл подключен по References. Конечно, под отладчиком можно определить, какая библиотека (функция, класс) отсутствует. Для этого потенциальный взломщик должен иметь под рукой и клиентскую часть базы и часть с таблицами. И это уже квалификация не рядового пользователя. Если Вы используете библиотеки DLL, то здесь могут возникнуть вопросы с их установкой и регистрацией. Но в и-нете можно найти примеры, как можно установить и зарегистрировать DLL из самой базы Access. Кроме того, установку DLL и OCX можно возложить на программу-инсталлятор клиентского приложения (если она у Вас есть). В конце-концов в и-нете много бесплатных программ для создания инсталляционных пакетов - например, InnoSetup. Потратив некоторое время, вы можете создать свой инсталляционный пакет, предназначенный для установки необходимых библиотек.
|