ЁхынПалыч, я здесь не имел ввиду защиту при помощи терминалСервера и политик. Я здесь как раз и хотел обратить внимание на чисто Access-овские погремушки, как то раздача прав через MDW, установки пароля на базу, шифрование базы. Грамотное использование их может сильно попортить кровь любителям подсматривать. А приведенные выше форматы (dBase, Paradox) не имеют даже такой защиты.

Мда-а-а... Статью заметили. Вчера получил рассылку "Работа с MS Access" и там ссылка на мою статью по защите данных в MDB. Размещена на сайте www.interface.ru и ещё, там есть ссылка на статью Access. Безопасность. , которая взята с моей странички на сайте Андрея Митина Нет, я её не писал. Я только привел её в божеский вид, в смысле оформление (по сравнению с тем, что было найдено изначально). Я совсем не против, чтобы их читали, качали и выкладывали на других сайтах. Просто хотел заметить, что статья "О защите данных в файлах MDB СУРДБ Access." Несколько устарела. Более новый вариант можно найти на сайте www.accessoft.ru Над статьей потихоньку продолжается работа по рекомендациям ЁхынПалыча . Но сейчас сильно подгрузили с работой, так, что скорого завершения не предвидется.

Дополнение к статье (если кому-нибудь ещё интересно)

Вот что я нашел про кодирование/раскодирование баз данных 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 можно прочитать вот здесь
А об его стойкости - вот здесь

Подымаю старую ветку. Через десять(!) лет решил переписать статью. Может кого-то заинтересует. А я жду замечаний и предложений.

Ещё немного о проблемах защиты данных

Нужно ли беречь данные от сотрудников

Почитайте. Некоторые проблемы повернуться новой стороной.