О защите данных в файлах MDB СУРДБ Access.Источник: realcoding Дмитрий Сонных
Маленькое отступление. Что такое СУРБД? Это расшифровывается как Система Управления Реляционными Базами Данных. А что такое - реляционные? Для простоты можно сказать, что это базы, основанные на таблицах. А что, бывают другие? Да, бывают. Базы знаний, иерархические базы, объектно-ориентированные базы данных. Есть файловые базы, построенные на индексно-последовательном методе доступа к данным (Indexed Sequential Access Method - ISAM). В таких системах каждая таблица хранится в отдельном файле, а название ISAM происходит от физического способа хранения и доступа к данным. Примерами баз данных ISAM могут послужить dBase, FoxPro, Paradox, Excel. Одни теоретики относят ISAM к реляционным базам данных, другие считают, что полноценная СУРДБ должна не только хранить и извлекать информацию, но и обеспечивать её целостность. Access, в этом смысле, находится где-то посередине. Она может выполнять некоторые контрольные функции, но до SQL серверов ей далеко. Есть и другие разновидности баз данных, но это уже отдельный разговор. И так, продолжим. Более-менее продвинутый разработчик делит свою MDB базу на две, а иногда и более частей. Деление на интерфейсную и табличную часть надо проводить, когда программа готова к передаче в эксплуатацию, а иногда и раньше (если Вы не пишете программу только для себя). Это облегчает сопровождение программы, находящейся у клиентов. И это, практически, обязательное требование при построении файл-серверных многопользовательских систем. О защите клиентской части здесь уже поднимался вопрос. Я же хочу рассмотреть проблему защиты данных, находящихся в таблицах. Будем рассматривать файл-серверный вариант размещения базы.
Прежде, чем начнем разговор о защите, Вы должны ясно представить себе, от чего вы хотите защитить свои данные. Защиты бывают разных уровней и сложностей. И может быть выполнение требования «максимально защитить все данные» превысит по трудоемкости разработку и отладку самой базы. И помните, что один человек сделал, другой завсегда сломать может. И никакая защита не спасет от обыкновенного разгильдяйства. Я встречал случаи, когда логин и пароль доступа писали на бумажке, а затем эту бумажку клеили на монитор, «чтобы не потерять». И это не анекдот. Дело в том, что рядовому сотруднику фирмы/отдела чаще всего нет никакого дела до защиты информации. Его задача - отработать положенные часы, причем с наибольшим комфортом для себя. Отсюда и выходит: раздаешь пароли доступа КАЖДОМУ сотруднику, а они их пишут на бумажке (общим списком) и кладут под стекло. Такое «безобразие» обычно заканчивается тем, что кто то чего то не туда ввел/удалил. Начинаются разборки - и тут до оператора доходит, что если бы он не разглашал свой пароль, то, стало быть, никто не смог бы влезть в базу и «ковыряться» там от его имени. Отсюда вывод - защита базы, дело РУКОВОДИТЕЛЯ, а не операторов. Рассмотрим теперь способы защиты. Административный метод.Позволяет защитить от несанкционированного копирования самой части базы с таблицами. Из компьютеров изымаются пишущие CD/DVD приводы, FDD, Zip и JAZZ накопители, магнитооптика, USB закрываются программно системным администратором. Все операции записи на носители может выполнять только определенный человек. Если есть выход в и-нет, то соответствующе настраивается прокси-сервер. У пользователей удаляются полные версии Access и устанавливаются Run-time версии, отбираются права администратора. Такую ситуацию сейчас можно увидеть на многих фирмах с устоявшейся структурой и налаженной работой, и где персональные компьютеры - действительно персональные, а не как шутили ранее - «персональный компьютер коллективного пользования. Если информация записана - значит, ее можно прочитать, если ее можно прочитать - можно и скопировать, если можно скопировать - можно и украсть. Маскировка.Как я писал ранее, разговор идет о разделенной базе данных. Часть с таблицами обычно хранится на сервере. И все пользователи должны иметь к ней доступ. Обычно на сервере создается каталог share (имя может быть любым) через который пользователи обмениваются файлами, где хранятся документы общего пользования и т.п. Никто не запрещает создать подходящий каталог и замаскировав его под служебный, присвоив какое-либо высокоумное название. Поместить в него базу данных (обычно, уже хорошо проработанная и долго эксплуатированная система обрастает кучей дополнительных каталогов, файлов, шаблонов и т.п.) и присвоить ей расширение, отличное от MDB. При подключении (линковании) таблиц Вы указываете точный путь и имя базы данных. И Access всё равно, как называется файл, главное, чтобы совпадала структура. В своё время, в Донецке, мне пришлось столкнуться с системой «Акцент» (бухгалтерская программа). Она была написана на VC, а вот в качестве хранилища данных в ней использовались MDB-файлы, с расширением - acc. Я встречал предложения вообще менять заголовок файла, а перед линковкой подставлять правильный. Но я бы не советовал такого делать. Операции прямой записи некоторые программы-сторожа (антивирусные мониторы) определяют как вирусные атаки и блокируют. Кроме того, в многопользовательской среде, достаточно подключиться к базе с таблицами одному из клиентов, как измененный заголовок будет восстановлен. Для того, чтобы при простом просмотре клиентской части нельзя было определить путь к базе с таблицами, путь шифруется и восстанавливается только в момент самого линкования. Для того, чтобы нельзя было скопировать линки с клиентского модуля, рекомендуется в конце работы отключать все прилинкованные таблицы, а в начале - подключать. Но это хорошо для неработающего модуля. Стоит только запустить клиентскую часть, как линки на таблицы с данными будут восстановлены. А дальше можно уже подключаться из чистой базы к работающему клиентскому приложению и копировать себе линки на таблицы. Чтобы этого не происходило, можно использовать вспомогательные программы-стартёры. Например,- ReleaseUpdate. Она проверяет наличие обновлений клиентской части, если они есть, то обновляет клиентскую часть, и запускает её на выполнение. Клиентскую часть можно расположить где-нибудь в Program Files, в специальном каталоге, а путь к ней, находящийся во внутренних таблицах программы ReleaseUpdate, можно зашифровать. Есть и другие готовые аналогичные программы. Например - MDBStarter. ПРЕДУПРЕЖДЕНИЕ. Никогда не присваивайте базе расширения, зарезервированные для временных файлов. Иначе программа очистки винчестера может его удалить. Не присваивайте расширения мультимедиа файлов. Иначе пользователи из любопытства всё время будут пытаться его запустить, чтобы глянуть, что там админ прячет на сервере? Есть еще одна возможность заморочить пользователя. Дело в том, что в Access есть три варианта отображения объектов:
Системный объект - это встроенный объект базы данных, определенный как системный, например таблица "MSysIndexes", или системные объекты, определенные пользователем. Для определения системного объекта необходимо, что бы его имя начиналось с символов USys. Например, добавьте к названию формы, таблицы, отчета USys - и они тут же «исчезнут», станут системными, но обращаться к ним из приложения можно так же, как обычно. Чтобы сделать объект скрытым, нужно выделить его, затем правой кнопкой - и в контекстном меню выбрать «Свойства» и задать параметр «Скрытый». Сервис - Параметры - Вкладка вид. В группе Отображать выберите требуемый вариант - поставьте (уберите) галочку «Скрытые объекты», «Системные объекты» и т. д. Защита на уровне доменных политик.На форуме по Access, на сайте SQL.RU я встретил такую заметку: «Всю свою трудовую историю работы с Аксесом, был твёрдо уверен, что защитить ФС (файл-сервер) Аксеса (mdbmde) в сети (да и не только Аксеса, а вообще ФС) от несанкционированного доступа толком невозможно. Пока один очень сильный админ у моего клиента не продемонстрировал мне такую штуку. Файл сервер, Аксес, домен, АД, шара (полный доступ, т.к. это требуется для ФС), приложения на клиентских ПК (более 20) работают с файлом как обычно, штатно прилинкованные таблицы. Но... Ни в сети, ни в консоли, даже зная путь к шаре и имена файла, я не смог скопировать (дёрнуть) ф-л БД с сервера, ни открыть никакой вменяемой программой - призрак. Тыкался, тыкался... Уп-с. Чего он там намудрил с политиками - не знаю, не кололся. Но факт, я не смог получить доступ к самому файлу БД. При этом админ работал штатными средствами виндового сервера. После этого случая я задумался. О жизни, о админах и о технологиях ФС, одной из острых претензий к которой у меня была "незащищаемость" хранилища БД в сети. Защита при помощи макроса AutoExec и блокировки Shift.Для построения интерфейса защиты создадим два макроса: AutoExec, AutoKeys. AutoExec нужен для перехвата события «открытие приложения», AutoKeys выполняет похожую роль - перехватывает нажатие клавиш на клавиатуре. Чтобы он их перехватывал, он должен называться AutoKeys (зарезервированное имя в Access). По этой же причине AutoExec должен называться AutoExec. Еще один важный момент - в меню Сервис - Параметры запуска уберем все галочки, иначе обойти защиту от Shift станет весьма просто: Окно - Отобразить - Окно БД. Если же отключить все меню, то в пункте меню "Окно" будут выводится только режимы расположения окон, а окно базы выводится не будет. DBS.Properties("AllowBypassKey") = True (или False) В зависимости от значения пароля, введенного в поле формы «ВклОткШифт» этому свойству присваивается True или False. Затем база закрывается (чтобы изменения вступили в силу) DoCmd.Quit acPrompt Пример, как это все работает, Вы можете посмотреть здесь Защита базы с таблицами немножко отличается от защиты базы с исполняемым кодом. Чаще всего стартовая форма представляет собой форму с предупреждающей надписью типа «Таблицы с данными, Прямой доступ запрещен!» и установленным таймером. Если после открытия стартовой формы, в течении определенного времени, не нажата комбинация клавиш, вызывающих форму отключения Shift, то приложение закрывается. И здесь фантазии разработчиков может развернуться! Я встречал программу, где при попытке открыть базу с таблицами, на весь экран разворачивался черный пиратский флаг с черепом, повязанный красным платком и повязкой на глазнице, скрещенными саблями и кровавой надписью - «Здесь Вас не ждут!». Можно через некоторое время, перед закрытием базы пустить на динамик милицейскую сирену или зловещий хохот. Среди разработчиков БД есть люди с юмором! Некоторые «особо злобные» программеры встраивают ещё команды перезагрузки и выключения компьютера. А с учетом того, что клавиш много, а вывод формы отключения защиты от Shift можно повесить и на более сложную комбинацию из нескольких клавиш, то «экспериментатору очень скоро надоест заново включать компьютер Защита с использованием пароля БД.Данный способ защиты позволяет установить пароль на открытие БД, для всех пользователей. Для его создания необходимо открыть файл БД в "монопольном" режиме и выбрать пункт меню Сервис / Защита / Задать пароль базы данных . Для работы с такой базой данных в MS Access потребуется вводить пароль. Вот пример работы с файлом БД, используя DAO или ADO. Public Sub TestDAO() Public Sub TestADO() Это тоже не самый надёжный способ защиты баз данных. Существует достаточное количество бесплатных и платных утилит, отображающих пароль. В том числе доступны исходники кода на VB позволяющие прочитать такой пароль. В прочем не всё так плохо.
Но всё это уже требует наличие определенных знаний и опыта, так, что есть шансы на то, что любопытному пользователю надоест экспериментировать. Защита при помощи терминального доступа к серверу.Практически непрошибаемая защита. И клиентская часть и база с таблицами находится на сервере. У клиента на компьютере эмулируется терминал сервера. Словно ты за ним сидишь (в смысле, за сервером). Можно настроить терминальный доступ так, что при запуске требуемой задачи (по ярлыку), запроса соответствующих паролей доступа к системе, сразу грузится требуемая база. При закрытии базы терминал закрывается. В самой базе прописана защита от шифта, отключены все стандартные Access-овские меню и горячие клавиши, отключено окно базы. И ничего пользователь ни затереть, ни скопировать не может. Ни открыть напрямую таблицы, ни получить доступ к закрытым для него формам и отчетам. Ещё терминальный доступ называется, по-моему, удаленным рабочим столом. |