Отправляет email-рассылки с помощью сервиса Sendsay

Программирование и готовые решения

Подписаться Бесплатная «Серебряная» новостная рассылка . Подписчиков 5.409 RSS
←   Март 2007   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


За последние 60 дней ни разу не выходила


Сайт рассылки: http://blog.leadersoft.ru
Открыта: 29-08-2000

Автор
leadersoft.ru

Статистика

5.409 подписчиков
0 за неделю
←   Все выпуски   →

Microsoft Access - программирование и готовые решения


Выпуск 71. Материалы для начинающих (18 урок)

Подписка: "Access 2000 - программирование и готовые решения"
Дата:         09.03.2007
Автор:     Дмитрий Сонных (aka Joss)
Сайт:        http://www.accessoft.ru под редакцией с http://www.leadersoft.ru/
Новые материалы: защита данных в Access
На сайте AccesSoft публикуются статьи, посвященые вопросам, связанным с разработкой и продвижением приложений Access. Вы так же можете ознакомиться с готовыми программами, получить исходный код, купить программу, связаться с автором для решения вопроса о доработке программы под Ваши требования.


    Данная статья ориентирована на начинающих разработчиков Access, желающих более углубленно изучить возможности программирования в Access и сделать свои приложения более профессиональными.
Защита данных в файлах MDB СУРДБ Access. Часть 4.

Шифрование содержимого полей в таблицах.

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

    Этот способ защиты не плох. Во всяком случае, появляется реальная надежда, что-то спасти. Однако есть ряд ограничений. Шифровать следует только символьные поля или поля типа 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. Потратив некоторое время, вы можете создать свой инсталляционный пакет, предназначенный для установки необходимых библиотек.
Комментарий к предыдущему выпуску (№70)

    Честно сказать, я совершенно убит рекомендациями, которые вы даёте начинающим разработчикам в номере рассылки от 7 марта 2007 :( Не дай бог кто-нибудь из них действительно им последует и станет называть таблицы t001, t002, ..., поля f01, f02, ... Этим они станут бороться не с хакерами, а в первую очередь с самими собой. Представляю, как они будут себя чувствовать, когда захотят сделать изменения в собственной программе через полгода! Особенно если ни один хакер никогда этих программ не увидит, что скорее всего. Зря вы это написали, видит бог зря! Предлагаемый "метод" защиты данных представляется мне самым вредным из всех, что только можно придумать. Если бы Microsoft писала свои программы подобным образом, мы вообще никогда не увидели бы даже самую первую версию MS Access.

прислал Павел Воронков http://sq.narod.ru
В избранное