Как улучшить защиту на MS Access MDB помимо защиты паролем? - PullRequest
1 голос
/ 07 мая 2009

У меня есть доступ к MDB, который защищен паролем, но который может быть легко взломан с помощью бесплатного инструмента, найденного в Google в течение 1 секунды. Помимо оплаты некоторых дорогих инструментов, есть ли хороший способ защиты файла базы данных ms access? Я подумываю о том, чтобы затем зашифровать его через dll, чтобы расшифровать, получить некоторые данные и передать его стороннему приложению, а затем, когда соединение установлено, снова зашифровать файл.

Если кто-то захочет прокомментировать ошибку этого метода или у него есть какие-то другие ресурсы, инструменты и т. Д., Это было бы здорово.

спасибо:)

Ответы [ 7 ]

2 голосов
/ 07 мая 2009

Доступ это старая база данных, почему бы не SQL Express 2005 (ведь это бесплатно)? вы получите больше информации о безопасности, и внутри вашего приложения вы используете user / pwd в соединении, которое никто не узнает и не сможет увидеть ... если они попытаются открыть SQL, они увидят только имя базы данных и больше ничего (не забудьте использовать проверку подлинности SQL, а не проверку подлинности Windows)

если вы используете .NET, в вашей программе установки вы можете указать устанавливать приложение только после установки SQL 2005 Express или, если вы используете другой язык, используйте InstallShield, FinalBuilder и т. Д., Чтобы сделать то же самое ...

:)

ваша идея "борется" со мной, когда я думаю, что ... Access начал иметь низкое время отклика с более чем 30 тыс. Строк в одной таблице (цитата из Microsoft), и если вы собираетесь создать слой для шифрования / дешифрования данные ... ваше приложение просто перестанет работать медленно ... вообще не будет ли это хорошей идеей?

2 голосов
/ 08 мая 2009

Я за то, чтобы использовать Jet везде, где это уместно, но когда вы начинаете беспокоиться о защите паролем данных, превышающих то, что вы получаете с NTFS security и Jet ULS, вы находитесь на территории, где вам нужно использовать другое хранилище данных.

Но позвольте мне сказать это:

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

И, наконец, вы должны доверять людям, чтобы они вели себя ответственно, и Jet или SQL Server ничего не могут с этим поделать.

1 голос
/ 07 мая 2009

Мне непонятно, прочитав ваш пост, если вы пытаетесь защитить только данные или если вы пытаетесь защитить что-то еще, например, скажем, исключительно код VBA. Вы говорите, что у вас есть файл MDB, но вы работаете с Access 2003, 2007 или другой версией? Планируете ли вы развертывать свое решение Access на интранет-сайте? (Для моих комментариев ниже я собираюсь предположить, что вы).

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

  1. Если вы работаете с Access 2003, возможно, вы захотите рассмотреть безопасность на уровне пользователей и групп (настройка и настройка безопасности на уровне пользователей / групп недоступна в базах данных формата Access 2007 (accdb), однако Access 2007 распознает пользователя / Групповые разрешения для файлов MDB. С безопасностью на уровне пользователя / группы вы можете ограничить доступ к вашей базе данных на основе определенных пользователей и рабочих групп. Для получения дополнительной информации - [http://office.microsoft.com/en-us/access/HP051882261033.aspx][1]

  2. Рассмотрите возможность разделения вашей базы данных (держите ваши данные отдельно от объектов приложения, таких как формы, отчеты) и / или создавайте разные версии, ограничивающие доступные объекты.

  3. Держите мастера по дизайну и реплики по производству. Это согласуется с предыдущим комментарием, где идея заключается в том, что не все на столе для принятия. Возможно, вы захотите ознакомиться с расширениями для разработчиков Access (если вы еще этого не сделали), которые доступны на 2003 и 2007 годы (их можно бесплатно загрузить и установить в Microsoft).

  4. Применяйте, когда это возможно, политики, которые препятствуют и / или ограничивают доступ сотрудников или коллег (опять же, я предполагаю, что вы развертываете в корпоративной сети компании)

  5. Кодировать вашу базу данных. Это сделает информацию о свойствах для ваших таблиц, код VBA сложнее для извлечения, так как база данных будет сжата, а любая информация уровня проектирования будет удалена или труднее получить доступ.

  6. Наконец, если у вас есть время, ресурсы и / или находящаяся поблизости библиотека / книжный магазин с доступной копией, я рекомендую вам проверить владение Элисон Балтер Microsoft Office Access 2003 раздел по разработке многопользовательских и корпоративных приложений, в котором есть раздел по безопасности. Обновлено для ACCESS 2007: Освоение Элисон Балтер Microsoft® Office Access 2007 Разработка

1 голос
/ 07 мая 2009

Как насчет обновления из формата MDB в формат ACCDB (Access2007)?

Начало работы с безопасностью Access 2007

"Средство шифрования в Office Access 2007 объединяет и улучшает два более старых инструмента - пароли базы данных и кодирование. Когда вы используете пароль базы данных для шифрования базы данных, вы делаете все данные нечитаемыми для других инструментов, и вы заставляете пользователей вводить пароль для использования базы данных. Шифрование, применяемое в Access 2007, использует более надежный алгоритм, чем в предыдущих версиях Access ... "

0 голосов
/ 07 мая 2009

Для настольного приложения я бы предложил вам пойти по пути Sql Server Compact Edtition (SQLCE) . Или, если у вас есть немного денег, VistaDB (в отличие от SQLCE он поддерживает хранимые процедуры, представления и триггеры). Вы получите лучшую безопасность, лучшую производительность, меньше хлопот с обслуживанием и повреждениями и более простое развертывание.

0 голосов
/ 07 мая 2009

Какой бы метод вы ни использовали, он будет взломан кем-то знающим.

Это действительно зависит от того, насколько ценны данные: если бы они действительно были ценными, я бы использовал другую модель, такую ​​как размещение базы данных за сервером в Интернете. Тогда вы можете ограничить количество запросов, а также фильтр для неправильного использования.

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

Также подумайте о будущем: некоторым сетевым администраторам через 10 лет может потребоваться законно получить доступ к данным, и при использовании простого пароля будет показано, что данные должны быть защищены, но все же разрешать обход.

0 голосов
/ 07 мая 2009

Сохранение данных в зашифрованном формате было бы решением. Если пароль «не удался», взломщик также должен расшифровать данные

...