Маленькое отступление. Что такое СУРБД? Это расшифровывается как Система Управления Реляционными Базами Данных. А что такое - реляционные? Для простоты можно сказать, что это базы, основанные на таблицах. А что, бывают другие? Да, бывают. Базы знаний, иерархические базы, объектно-ориентированные базы данных. Есть файловые базы, построенные на индексно-последовательном методе доступа к данным (Indexed Sequential Access Method – ISAM). В таких системах каждая таблица хранится в отдельном файле, а название ISAM происходит от физического способа хранения и доступа к данным. Примерами баз данных ISAM могут послужить dBase, FoxPro, Paradox, Excel. Одни теоретики относят ISAM к реляционным базам данных, другие считают, что полноценная СУРДБ должна не только хранить и извлекать информацию, но и обеспечивать её целостность. Access, в этом смысле, находится где-то посередине. Она может выполнять некоторые контрольные функции, но до SQL серверов ей далеко. Есть и другие, но это уже отдельный разговор. И так, продолжим. Более-менее продвинутый разработчик делит свою базу на две, а иногда и более частей. Деление на интерфейсную и табличную часть надо проводить, когда программа готова к передаче в эксплуатацию, а иногда и раньше (если Вы не пишете программу только для себя). Это облегчает сопровождение программы, находящейся у клиентов. Это практически обязательное требование при построении файл-серверных многопользовательских систем. О защите клиентской части здесь уже поднимался вопрос. Я же хочу рассмотреть проблему защиты данных, находящихся в таблицах. Будем рассматривать файл-серверный вариант размещения базы.

Прежде, чем начнем разговор о защите, Вы должны ясно представить себе, от чего вы хотите защитить свои данные. Защиты бывают разных уровней и сложностей. И может быть выполнение требования «максимально защитить все данные» превысит по трудоемкости разработку и отладку самой базы. И помните, что один человек сделал, другой завсегда сломать может. И никакая защита не спасет от обыкновенного разгильдяйства. Я встречал случаи, когда логин и пароль доступа писали на бумажке, а затем эту бумажку клеили на монитор, «чтобы не потерять». И это не анекдот. Дело в том, что рядовому сотруднику фирмы/отдела чаще всего нет никакого дела до защиты информации. Его задача – отработать положенные часы, причем с наибольшим комфортом для себя. Отсюда и выходит: раздаешь пароли доступа КАЖДОМУ сотруднику, а они их пишут на бумажке (общим списком) и кладут под стекло. Такое «безобразие» обычно заканчивается тем, что кто то чего то не туда ввел/удалил. Начинаются разборки – и тут до оператора доходит, что если бы он не разглашал свой пароль, то, стало быть, никто не смог бы влезть в базу и «ковыряться» там от его имени. Отсюда вывод – защита базы, дело РУКОВОДИТЕЛЯ, а не операторов. Рассмотрим теперь способы защиты. Есть несколько уровней и способов защиты.

Административный метод

Позволяет защитить от несанкционированного копирования самой части базы с таблицами. Из компьютеров изымаются пишущие CD/DVD приводы, FDD, Zip и JAZZ, магнитооптика, USB закрываются программно системным администратором. Все операции записи на носители может выполнять только определенный человек. Если есть выход в и-нет, то соответствующе настраивается прокси-сервер. У пользователей удаляются полные версии Access и устанавливаются Run-time версии, отбираются права администратора. Такую ситуацию сейчас можно увидеть на многих фирмах с устоявшейся структурой и налаженной работой, и где персональные компьютеры – действительно персональные, а не как шутили ранее - «персональный компьютер коллективного пользования.

Иногда, к сожалению, административная защита превращается в фарс: «опломбировали» (заклеили) бумажками USB, на КПП охране дали указание проверять входящих/выходящих на наличие дискет (подумать только, какой архаизм – воровать дискетами), дисков… А многие спокойно ходят с мобильниками, в которых встроена Flash – карта. Такой уровень «защиты» показывает, что ей занимается человек весьма далекий от программных дел. Обычно такая картина наблюдается на госпредприятиях. Вообще, в отделах, отвечающих за защиту, не мешало бы повесить такой плакат:

Если информация записана – значит, ее можно прочитать, если ее можно прочитать – можно и скопировать, если можно скопировать – можно и украсть.

Маскировка базы

Как я писал ранее, разговор идет о разделенной базе данных. Часть с таблицами обычно хранится на сервере. И все пользователи должны иметь к ней доступ. Обычно на сервере создается каталог share (имя может быть любым) через который пользователи обмениваются файлами, где хранятся документы общего пользования и т.п. Никто не запрещает создать подходящий каталог и замаскировав его под служебный, присвоив какое-либо высокоумное название. Поместить в него базу данных (обычно, уже хорошо проработанная и долго эксплуатированная система обрастает кучей дополнительных каталогов, файлов, шаблонов и т.п.) и присвоить ей расширение, отличное от MDB. При подключении (линковании) таблиц Вы указываете точный путь и имя базы данных. И Access всё равно, как называется файл, главное, чтобы совпадала структура. В своё время, в Донецке, мне пришлось столкнуться с системой «Акцент» (бухгалтерская программа). Она была написана на VC, а вот в качестве хранилища данных в ней использовались MDB-файлы, с расширением – acc. Я встречал предложения вообще менять заголовок файла, а перед линковкой подставлять правильный. Но я бы не советовал такого делать. Операции прямой записи некоторые программы-сторожа (антивирусные мониторы) определяют как вирусные атаки и блокируют.

Кроме того, в многопользовательской среде, достаточно подключиться к базе с таблицами одному из клиентов, как измененный заголовок будет восстановлен. Для того, чтобы при простом просмотре клиентской части нельзя было определить путь к базе с таблицами, путь шифруется и восстанавливается только в момент самого линкования. Для того, чтобы нельзя было скопировать линки с клиентского модуля, рекомендуется в конце работы отключать все прилинкованные таблицы, а в начале – подключать. Но это хорошо для неработающего модуля. Стоит только запустить клиентскую часть, как линки на таблицы с данными будут восстановлены. А дальше можно уже подключаться из чистой базы к работающему клиентскому приложению и копировать себе линки на таблицы. Чтобы этого не происходило, можно использовать вспомогательные программы-стартёры. Например,- ReleaseUpdate (http://am.rusimport.ru/MsAccess/topic.aspx?ID=533). Она проверяет наличие обновлений клиентской части, если они есть, то обновляет клиентскую часть, и запускает её на выполнение. Клиентскую часть можно расположить где-нибудь в Program Files, в специальном каталоге, а путь к ней, находящийся во внутренних таблицах программы ReleaseUpdate, можно зашифровать. Есть и другие готовые аналогичные программы. Например – MDBStarter (http://mdbprogs.narod.ru/mdbstart.html).

На одном из предприятий мне показывали следующую систему. На сервере лежал каталог с общим доступом и названием типа SystemControlFS. Пользователи не могли там ничего удалить. В нем была куча файлов и каталогов и файл SystemControlFS.exe. При попытке его запустить выдавалось сообщение, что у вас нет администраторских прав. База данных была замаскирована под один из вспомогательных файлов.

ПРЕДУПРЕЖДЕНИЕ. Никогда не присваивайте базе расширения, зарезервированные для временных файлов. Иначе программа очистки винчестера может его удалить. Не присваивайте расширения мультимедиа файлов. Иначе пользователи из любопытства всё время будут пытаться его запустить, чтобы глянуть, что там админ прячет на сервере?

Маскировка таблиц и полей

Предположим, что злоумышленнику удалось обойти вашу защиту и добраться до таблиц. Как быть в этом случае? Здесь тоже можно подпортить «хакеру» немного крови. Как Вы называете таблицы? Русские версии Access понимает русские названия и поначалу таблицы имеют такие имена; Адрес организации, Поступление Товара, Транспортные накладные и т.п. Очень скоро разработчик приходит к пониманию, что пробелы в названиях сильно усложняют жизнь, и появляются названия АдресОрганизации, ПоступлениеТовара, ТоварноТранспортныеНакладные… Еще через некоторое время появляются таблицы с именами: Sotrudniki, Tovar, Otdel… И в конце концов появляются названия tblAdressOrg (или tbAdressOrg), tblOtdel, tblZarplata… То же самое происходит и с именами запросов, форм, макросов, отчетов, а так же с названиями полей в таблицах и контролов на форме. Для большей читабельности базы, заполняются параметры «Описание» таблиц, запросов, форм, отчетов, макросов, полей.
А теперь представьте себе такую картину. Вы открываете базу, а там Table01, Table02, Table03…. Form01, Form02…. Report01, Report02… Поля в таблице имеют наименование Field01, Field02… В общем Вы меня поняли. Но для этого у Вас на компе или на листочке всё должно быть расписано подробнейшим образом. Имя таблицы, её назначение, имя поля – характер информации. Это потребует дополнительных затрат рабочего времени и большей организованности в работе. Не все на это легко согласятся.

А как же связи между таблицами? Открыв схему данных можно легко отследить связи между таблицами и тогда… В книгах и на форумах высказывалось много соображений про полезность и необходимость установки связей между таблицами. И сохранение целостности данных, и каскадное удаление записей, и увеличение скорости выполнения запросов и т.д. и т.п. Я не буду возражать насчет полезности связей, но без них можно обойтись. Пусть меня ругают и тыкают в меня пальцем, но я скажу, что создать довольно сложные приложения на Access можно и без создания схемы данных. Я это говорю из личного опыта. Но при этом все действия по сохранению целостности базы, удалению данных, разруливанию критических ситуаций Вы берете на себя. Это дополнительный код, это более тщательное программирование, дополнительный контроль при некоторых операциях (например – удалении). Более тщательный порядок при работе с таблицами. Всё это дополнительные затраты, но всё это не так сложно, как кажется на первый взгляд. А схему данных можно сделать и на бумаге. (Я так и делал).

А теперь, критические замечания. Про неудобство составления запросов и работы с рекордсетами, я уже писал. И про дополнительные сложности в программировании при отсутствии схемы данных – тоже. А вот про то, что текст всех запросов можно спокойно просмотреть даже в MDE файле об этом не упоминал. Даже то, что формы нельзя править, не является препятствием, для определения запроса, на котором основана форма. Даже если вы вручную набрали текст в поле «Источник данных» не спасает его от просмотра через панель (форму) «Свойства». Терпеливый пользователь, посидев с бумагой и ручкой, может восстановить схему данных.

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

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

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

Защита на уровне доменных политик

На форуме по Access, на сайте SQL.RU я встретил такую заметку: «Всю свою трудовую историю работы с Аксесом, был твёрдо уверен, что защитить ФС (файл-сервер) Аксеса (mdb\mde) в сети (да и не только Аксеса, а вообще ФС) от несанкционированного доступа толком невозможно. Пока один очень сильный админ у моего клиента не продемонстрировал мне такую штуку. Файл сервер, Аксес, домен, АД, шара (полный доступ, т.к. это требуется для ФС), приложения на клиентских ПК (более 20) работают с файлом как обычно, штатно прилинкованные таблицы. Но... Ни в сети, ни в консоли, даже зная путь к шаре и имена файла, я не смог скопировать (дёрнуть) ф-л БД с сервера, ни открыть никакой вменяемой программой - призрак. Тыкался, тыкался... Уп-с. Чего он там намудрил с политиками - не знаю, не кололся. Но факт, я не смог получить доступ к самому файлу БД. При этом админ работал штатными средствами виндового сервера. После этого случая я задумался. О жизни, о админах и о технологиях ФС, одной из острых претензий к которой у меня была "незащищаемость" хранилища БД в сети. Если бы мне это рассказали ДО этого случая, если бы я сам не пытался безуспешно "ломануть" свою же АСУ, не поверил бы.» Подробности не были раскрыты, но высказывалось предположение, «Как версия: например, в Windows зашёл пользователь user1, у которого нет прав на доступ к сетевому каталогу с базой, а приложение запускалось с правами другого пользователя user2 (через runas или указан в свойствах ярлыка), у которого есть такие права.». Я не являюсь специалистом по администрированию Windows, но из личного опыта расскажу следующее. Когда возникла необходимость мне работать с Developer SQL Server, то наш админ установил его у меня на компе, причем так, что я мог свободно работать с базами, которые находились локально тут же на компьютере, знал раздел, где они лежали, но не мог в него зайти.

Защита с использованием пароля БД

Данный способ защиты позволяет установить пароль на открытие БД, для всех пользователей. Для его создания необходимо открыть файл БД в "монопольном" режиме и выбрать пункт меню Сервис / Защита / Задать пароль базы данных. Для работы с такой базой данных в MS Access потребуется вводить пароль. Вот пример работы с файлом БД, используя DAO или ADO.

Public Sub TestDAO()
    Dim mWS As DAO.Workspace
    Dim mDB As DAO.Database
    Set mWS = DBEngine.Workspaces(0)
    Set mDB = mWS.OpenDatabase ("C:\a97.mdb", True, True, ";pwd=123")
End Sub

Public Sub TestADO()
    Dim CnDB As New ADODB.Connection
    CnDB.Open "Provider=Microsoft.Jet.OLEDB.4.0" & ";Data Source=C:\a97.mdb" & ";Jet OLEDB:Database Password=123"
End Sub

Это тоже не самый надёжный способ защиты баз данных. Существует достаточное количество бесплатных и платных утилит, отображающих пароль. В том числе доступны исходники кода на VB позволяющие прочитать такой пароль. В прочем не всё так плохо.
Дело в том, что некоторые разработчики считают, что кроме английского языка, других языков не существует. Достаточно включить в пароль русские буквы, чтобы привести в ступор пользователя, который использует такие программы. Да, они вроде бы и вскрывают пароль, но то, что они выдают в качестве пароля, разобрать невозможно.
Продолжим игры с паролем базы данных. Например, можно использовать в пароле непечатные символы. В первую очередь этот способ нацелен на противодействие определению паролей с помощью специальных программ. Стандартный способ установки и использования пароля БД подразумевает его ввод с клавиатуры в диалоговом окне. Если стока пароля содержит непечатные символы, то они не будут корректно отображены программой открывающей пароли БД. С другой стороны этот пароль нельзя ввести в диалоговом окне при открытии БД в MS Access.

Если бы пароль содержал символы табуляции, Esc или Enter, то стандартным образом Вы бы не смогли их ввести в окошко ввода пароля. Способ основан на том, что пароль БД формата Access 2000 и 2002-2003 - текстовая строка в формате Unicode (в Access 97 – ANSI). При этом нет ни каких ограничений на её содержимое. В спецификации баз данных и в справке по DAO 3.60 указано, что максимальное число символов в пароле - 14. Но на самом деле их может быть 20. При этом и сам Access 97 не допускает ввода строк пароля более 14 символов. В спецификации Access 2003 также сказано про 14 символов, но программа допускает ввод всех 20. Также возможно использование непечатных символов, что приводит большинство программ взламывающих пароли в ступор.

Для установки такого пароля потребуется применить специальную программу, использующую метод CompactDatabase библиотек ADOX или DAO. Но, как говорится, против всего можно найти лом. И такая защита вскрывается.

Во-первых, можно воспользоваться программой AccessRecovery, которая создаёт новый файл без защиты и переносит в него таблицы, запросы, формы, макросы, отчеты и код модулей.

Во-вторых, можно попытаться определить пароль БД с помощью специальных программ.

В-третьих, можно узнать пароль, проанализировав код программы в отладчике. Каков бы ни был пароль, он всё равно передаётся как текстовая строка в методе открытия БД. При наличии определённого опыта - это не очень сложная задача.

Узнать или изменить пароль БД можно, не прибегая к помощи специальных программ. В Access 97 пароль получается сложением по XOR пароля с 20 байтной последовательностью. Значения этих байт можно получить из любого не защищённого паролем mdb файла. Начиная с Access 2k, в связи с использованием Unicode, для хранения 20 символов пароля отведены 40 байт. При шифровании также используется сложение по XOR, но для получения последовательности байт соответствующей пустому паролю необходимо создать файл с датой исследуемой БД. Полученные байты можно вписать в исследуемый файл и обнулить пароль, либо сложить их с аналогичными байтами исследуемого файла и получить значение пароля. Но всё это уже требует наличие определенных знаний и опыта, так, что есть шансы на то, что любопытному пользователю надоест экспериментировать.

Шифрование/Дешифрование базы средствами Access

Вот что я нашел про кодирование/раскодирование баз данных Access в книге Access 2002. Разработка корпоративных приложений П.Литвина, К.Гетца и М.Гунделоя.

«Как бы хорошо не была защищена база данных Jet, любой мало-мальски сообразительный хакер может при помощи низкоуровневого дискового редактора и получить доступ к её содержимому. Поэтому серьезная защита баз данных предполагает ещё и их шифрование. Конечно, взлом баз данных – дело не самое обыденное, но искатель приключений всегда может найтись. Само по себе шифрование базы данных ещё не гарантирует её надежной защиты, но всё же препятствует её просмотру средствами, внешними по отношению к Access и Jet.

Зашифровать и дешифровать базу данных могут только её владелец и члены группы Admins. Для шифрования Jet использует алгоритм RSA (назван по первым буквам фамилий его изобретателей: Rivest, Shamir, Adelman) с ключом на основе идентификатора рабочей группы. Для шифрования и дешифрования предназначена команда Access Tools > Security .> Encrypt / Decrypt Database.

У шифрования базы данных имеется два негативных побочных эффекта. Во-первых, снижается её быстродействие – по оценкам Microsoft, процентов на 10-15. Во-вторых, зашифрованную базу данных нельзя сжимать такими программами, как PKZip, LHA, Stacker и DriveSpace. Точнее, сжимать можно, только в этом нет смысла – её размер уменьшится незначительно».

Вот, что удалось ещё нарыть на сайте Microsoft:

Шифрование базы данных — это простейший способ защиты. При шифровании базы данных ее файл сжимается и становится недоступным для чтения с помощью служебных программ или текстовых редакторов.

Шифрование незащищенной базы данных неэффективно, поскольку каждый сможет открыть такую базу данных и получить полный доступ ко всем ее объектам.

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

Немного потыкал клавиши. В шифрованную базу можно добавлять записи, а имеющиеся - изменять. Шифрованную базу можно сжимать. Таблицы из шифрованной базы можно подлинковывать.

Пароль на базу не шифруется. Тело базы шифруется начиная с адреса 1000h. При просмотре тела базы разными вьюерами там действительно ерунда. Программы типа AccessFix не могут ничего из базы выдрать. (по крайней мере версии 3.70). Они там просто ничего не находят. Объекты из шифрованной базы можно импортировать в другую базу и они уже будут не шифрованные.

Вывод, шифровать стоит базу, уже защищенную стандартными средствами при помощи MDW.

На что не смог найти ответа:

1. можно ли к шифрованной базе подключиться из других клиентов - VB, Delphi, VC... (скорее всего можно)?
2. в случае краха, какова вероятность восстановления шифрованной БД?

Об алгоритме шифрования RSA можно прочитать вот здесь http://ru.wikipedia.org/wiki/RSA
А об его стойкости - http://www.bugtraq.ru/library/crypto/rsa.html

Защита при помощи терминального доступа к серверу

Практически непрошибаемая защита. И клиентская часть и база с таблицами находится на сервере. У клиента на компьютере эмулируется терминал сервера. Словно ты за ним сидишь (в смысле, за сервером). Можно настроить терминальный доступ так, что при запуске требуемой задачи (по ярлыку), запроса соответствующих паролей доступа к системе, сразу грузится требуемая база. При закрытии базы терминал закрывается. В самой базе прописана защита от шифта, отключены все стандартные Access-овские меню и горячие клавиши, отключено окно базы. И ничего пользователь ни затереть, ни скопировать не может. Ни открыть напрямую таблицы, ни получить доступ к закрытым для него формам и отчетам. Ещё терминальный доступ называется, по-моему, удаленным рабочим столом.

Недостатки этого способа – вся обработка данных ложится на сервер, зато в качестве клиентов можно использовать слабые машины.

Есть еще два метода: Защита при помощи макроса AutoExec и блокировки Shift, защита паролем. Но о них уже рассказывалось в предыдущизх статьях.