Защита баз mdb : Программирование для всех. Языки программирования, программирование баз данных, технологии. Статьи для програмиста скачать бесплатно учебники книги документация форум : Статьи

Проблемы отчетов в ACCESS

Защита баз mdb

Как защитить базу данных в формате mdb.

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

Итак, как защитить?
Опытный акцессист ответит сразу - никак. И будет прав.
Почти. От него защиты нет, а от менее опытных - есть.
Другой опытный скажет: об этом все известно. И то же будет прав. Почти.
Кое-что новенькое есть.

Вступление. Проблем защиты еще нет.

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

Вы скоростным способом за ... недель создаете базу.
Конечно, ставите автозапуск базы с помощью макро Autoexec или указанием первой формы. Кстати, Autoexec - более универсально. Вы можете запустить программу, которая не только откроет первую форму, но и может сделать разные настроечные операции.
Далее ставите базу на компы, и начинаете борьбу с недовольными женщинами, не знающими как, а главное зачем, вводить данные, которые у них и так уже где-то есть. И с собственными ошибками, которые имеют свойство вылезать в самый неподходящий момент.
Но проходит некоторое время, и этот период заканчивается. Пользователи и шеф видят первые результаты, ошибки почти перестают выскакивать... Женщины уже просят для себя изменить надписи, шрифты, цвета.
И Вы у них на глазах это делаете с чувством взаимной радости. У шефа появляются новые пожелания, и Вы развиваете задачу дальше.
И вдруг... И вдруг вас вызывают, и вы видите искореженную форму (варианты: испорченный модуль, удаленную таблицу и т.д.). Конечно это хорошо, так как это значит, что женщины полюбили вашу задачу, хотят в ней разобраться и кое-что улучшить. Это также значит, что пользователи из начинающих юзеров перешли в разряд любопытных. Но у вас появилась головная боль - ведь шеф винит вас за все сбои задачи. Ведь вы программист - с вас и спрос. Теперь вы отчетливо чувствуете, что сидите на бочке с порохом. Хотите вы или не хотите, но вас появилась задача:

Защита от любопытного юзера.

Конечно, хочется решить эту задачу просто и быстро. Например, вообще спрятать окно Access со всеми его вредными кнопками. Как это сделать? - такой вопрос задавался неоднократно.

Итак, решение 1. Спрятать окно Access.

Отвечая на вопрос "Как?", Юрий Прус дал полное открытое описание этого решения в статье "Запуск приложения без окна Access и отключение кнопки закрытия окна Access"
(http://HiProg.com/access/article.asp?id=28).

Представим, что вы это сделали. И тут же оказывается, что вместе с вредными кнопками исчезли и вполне полезные типа: копировать, вставить, сортировать, фильтровать, найти... К которым ваши женщины привыкли от Word и Excel. Их теперь что - вешать на формы? Или учить женщин выполнять их с клавиатуры? То и другое весьма накладно. К тому же теперь нельзя просто свернуть задачу, а на больших мониторах нельзя сдвинуть в сторону все формы сразу - нужно поштучно. При этом все формы необходимо стали всплывающими. А программирование таких форм имеет свои неприятные особенности. Например, больше не работают события "Включение" и "Отключение" (Activate, Deactivate).
Подводя итоги, можно сказать, что это "простое и быстрое" решение влечет за собой достаточно длинные и неприятные последствия. Так что не будем прятать окно Access. Давайте спрячем "вредные" кнопки.

Решение 2. Спрятать "вредные" кнопки.

Вредные это те, которые дают доступ к окну базы данных и переводят объекты в режим конструктора.
Итак, окно базы данных. Прежде всего надо позаботиться об выключении клавиши Shift, останавливающей запуск программы и тем самым дающей доступ к окну базы данных. Затем отключить горячие клавиши вызова окна базы данных (Ctrl+F1, F11). И, наконец, заменить стандартные панели инструментов на свои.
Как это сделать описано и в Help, и почти в любой книжке по Access, и в оригинальных разработках.
Примеры: "Защита от Shift" (http://HiProg.com/access/article.asp?id=128)
"Защита от Shift-а" (http://nsa.chat.ru/UserInterfase_Sas_Shift.html).
Надо отметить, что во второй статье дается много больше, чем просто защита от Shift-а.
Заменив панели инструментов на свои, вы почти решили и вторую задачу - запрет вызова конструкторов.
Почти - потому, что часто забывают отключить вызов контекстного меню в формах правой клавишей мыши. А оно дает возможность перейти в режим конструктора. Для отключения вызова следует установить в формах в состояние "нет" свойство "Контекстные меню" (ShortcutMenu = No).
Выполнив эту более кропотливую работу, вы, наконец, облегченно вздыхаете. Любопытный юзер больше ничего не испортит, а все полезные кнопки есть. Это действительно так. Но...
Но опять выскочила ваша ошибка. У юзера. Вы смотрите на сообщение Access, и ничего не можете сделать. Ни посмотреть состояние таблиц, ни значений переменных, ни ... Вы же сами все запретили.
И этот запрет теперь бьет по вам. Ничего сделать на месте больше нельзя. Придется сначала расспрашивать, что делал юзер перед этим, потом идти к своему открытому варианту базы и пытаться имитировать последовательность действий, вызвавших ошибку. Обычно это удается. Реже - нет, потому что юзер рассказал не то или не все. Но бывает гораздо хуже. У юзера ошибка редко, но появляется, а у вас - нет. Общая схема появления такой ошибки: возникает она при редком сочетании данных в момент их изменения. После сброса ошибки хитрый Access поправляет сбой в данных. И вы ее не видите. Самому построить это сочетание данных трудно из-за ее редкости. Как бороться с такой ошибкой? Хорошо бы все-таки провести ее анализ прямо на месте. И не расспрашивая юзера.
Но сделать это не дает выбранная система защиты. А можно ли сделать такую защиту, что бы любопытный юзер никуда влезть не мог, а вы в тот же момент - могли? Ответ - да!

Решение 3. Следящая система. Вот это и есть новое.

Снова у вас полностью не защищенная база. Юзер сделал какое-то вредное действие: вызвал окно базы данных, перевел форму в режим конструктора, открыл окно отладки ... А ведь это можно определить программным способом и схватить юзера за руку! И не дать ему ничего сделать.
А если у компьютера сидите вы, то вы программе скажете -"это я!". И она должна снять всю защиту.
Дальше вы разбираетесь в ошибке, исправляете и т.д. Затем вы перегружаете базу и защита снова автоматически включается. В этом общая идея следящей системы.

Теперь техника исполнения. Защиту от Shift-а конечно нужно поставить - следящую систему надо запустить. Следящую систему (программу определения типа активного окна) следует вызывать по таймеру. Текст программы дается ниже. Программа работает очень быстро. Даже при интервале таймера в 0,01 сек. процессор практически не загружается. Из практики (первый вариант программы был написан в 1998 г.) достаточен интервал таймера в 2 сек. Юзер за это время ничего плохого сделать не успевает. В случае обнаружения вредного окна надо открыть защитную форму.
Пример защитной формы можно взять по адресу: http://nsa.chat.ru/Secur_FormNoEnter.html
К этому примеру два замечания: не обязательно форму раскрывать на весь экран монитора - достаточно сделать ее монопольной. И второе: снять в ней возможность вызова контекстного меню. В данном конкретном примере это не мешает, но при его модификации возможность вызова может оказаться дырой в защите.

Запуск по таймеру лучше всего делать из скрытой формы, открываемой первой и всегда загруженной.
Эту же форму я использую для хранения общих переменных. Есть два преимущества по сравнению с использованием Public переменных в общем модуле: они не сбрасываются при Reset, что облегчает отладку, и могут прямо использоваться в запросах как параметры отбора.
Если юзер попытается сделать эту форму видимой (у нас же есть все стандартные меню), то следует в форме на событие активизации поставить вызов все той же защитной формы при условии, что TimerInterval > 0.
Теперь почти все. Остается сделать в защитной форме секретный вход для себя. Это можно выполнить многими способами. Например, кликом какой-нибудь кнопки мыши с одновременным нажатием комбинации клавиш Shift, Ctrl, Alt. Можно снимать защиту при последовательной комбинации таких кликов.
Можно реагировать и на ввод символов с клавиатуры. В общем, это дело вкуса.
Само снятие защиты сводится к обнулению интервала таймера (отключение следящей системы) и закрытию защитной формы. Теперь и первая (скрытая) форма становится доступной.

Функция определения типа активного окна. Приводится версия для А-97.
Выход: = True, если окно вредное, и False в противном случае.

Public Function rpProtect() As Boolean
Static S As String, n As Long, TypeWindow As Long

On Error Resume Next
Err.Clear

n = Screen.Application.CurrentObjectType
If Err > 0 Then Exit Function 'на всякий случай
S = Screen.Application.CurrentObjectName

'тип не определен или диалоговая форма
If n = -1 Then Exit Function

'Тип определен
TypeWindow = n
n = SysCmd(acSysCmdGetObjectState, TypeWindow, S)
If n = 0 Then GoTo TruEnd 'объект не открыт - окно базы

Select Case TypeWindow
Case acTable, acQuery, acMacro, acModule
GoTo TruEnd 'доступ всегда запрещен
Case acForm
S = Screen.ActiveForm.Name
If Err > 0 Then GoTo TruEnd 'форма в окне базы данных
If Forms(S).CurrentView = 0 Then GoTo TruEnd 'форма в конструкторе
Case acReport
S = Screen.ActiveReport.Name
If Err > 0 Then GoTo TruEnd 'отчет в окне базы данных
n = Reports(S).HasData
If Err > 0 Then GoTo TruEnd 'отчет в конструкторе
End Select
Exit Function

TruEnd:
rpProtect = True
End Function

Для А-2000 функция посложнее.

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

О защите от любопытного юзера сказано все. И, будем считать, она сделана. Бочка с порохом убрана.
Однако разовьем ситуацию дальше. В вашу фирму приходит новый сотрудник, и через некоторое время просит у вас объяснения, почему вы функцию такую-то в таком-то модуле написали так, а не иначе.
Справившись со своим удивлением, вы понимаете, что перед вами не юзер, а, как минимум, ламер (начинающий программист). И он снял вашу защиту. Теперь перед вами возникает новая задача:

Защита от ламера.

Как же ламер снял вашу защиту? Вообще-то, есть много способов. Так как эта статья не ставит целью описание методов взлома баз Access, то изложу простейший и самый известный.
Все три метода защиты, указанные выше, имеют в своей основе защиту от Shift-а. Если ее снять, то доступ к базе свободен. Простейшим методом снятия защиты от Shift-а, не требующим программирования, является импорт базы. То есть ламер создает пустую базу и стандартной операцией Access импортирует в нее вашу базу. При импорте переписываются не все свойства базы. В частности, не переписывается свойство AllowBypassKey, управляющее защитой от Shift-а. Полученная база ничем не защищена.
Так как во время импорта никакие ваши программы не работают, то защититься от него можно только средствами самого Access. Они имеются. Это создание собственного файла рабочих групп, создание групп пользователей, назначение им прав доступа, паролированный вход для каждого юзера и т.д.
Все это многократно описано в книгах по Access и излагать их содержание не имеет смысла.
Можно только рекомендовать хорошую программу Юрия Пруса "AdmTools"
(http://am.rusimport.ru/MsAccess/pgAccDownload.htm), упрощающую работу по настройке и ведению встроенной системы защиты Access.
В методах защиты от юзера ничего не говорилось о защите базы с таблицами в случае, если вы отделили программы (клиентская часть) от собственно данных. Считается, что юзер просто не догадается вызвать Access и открыть базу с данными. А если догадается, то будет ... Ох, как нехорошо будет ...
Для защиты базы с данными единственно, что можно сделать - это применить встроенную защиту Access.

Если вы решите совместить защиту от ламера со следящей системой (а именно так я и делаю), то следует хорошо продумать уровень прав (разрешений) , которые вы предоставляете юзеру.
Не забывайте, что в момент анализа ошибки у компьютера будете вы, но с правами юзера.
Замечание для более опытных. Можно сделать программку, которая динамически меняет права юзера на администратора у всех обьектов базы при использовании секретного входа. То есть для вас. Тогда не надо сильно думать над назначением прав. И, конечно, не забыть о программе, восстанавливающий исходные назначения прав, если они были изменены.
Вызов этой программы я помещаю блок стартовых настроек, вызываемых макро Autoеxec. Программы изменения прав довольно просты, но индивидуальны. Поэтому не приводятся. Для их написания Help достаточен.

Завершение. Защита от опытного акцессиста.

Как сказал на форуме SSY: "Хреновая ситуация... Защита как-бы есть, но ломается с пол-пинка.
Проблема в том, что имя и код владельца БД можно определить с пом. спец. программ, например
http://msa.polarcom.ru/"

Могу добавить еще ссылку на забугорный источник: http://www.lostpassword.com/access.htm.

Такова текущая ситуация. Такой ли она должна быть? Ответ, конечно, нет. Есть хорошо известные методы, превращающую задачу взлома пароля в NP-трудную задачу. То есть, время решения такой задачи растет быстрее любого полинома от длины пароля (например, экспотенциально). Известны алгоритмы и открытые программы такого шифрования, например RSA. (Более подробно узнать об этом алгоритме можно по адресу: http://www.leadersoft.ru/subscribe/sub/sub32.htm). Просто для примера, если вы решите подобрать пароль методом полного перебора, то, если в пароле будут применяться только латинские буквы и цифры, оценка времени подбора = C*62^n, где C - константа, а n - длина пароля. Это только киношные герои ломают пароли, три раза нажав на Enter.
Почему Microsoft не применяет более мощные алгоритмы шифрования? Мне что-то не приходит в голову никаких разумных объяснений. И письма Гейтсу писать бесполезно - об этих алгоритмах он наверняка знает...
На этой пессимистической ноте придется статью закончить.

PS. Мощнейшей защитой базы является перевод ее в формат mde. Но это тема уже другой статьи.