Некоторые мысли об управлении правами пользователей на хранилище данных Jet:
если вы действительно хотите заблокировать, вы никогда не будете управлять им с помощью Jet, поскольку он по своей природе уязвим, потому что пользователь должен иметь WRITE-доступ к файлу MDB.
если вы довольны управлением правами на данные в вашем приложении переднего плана, вы можете предоставить разные интерфейсы (один для пользователей WRITE и один для READ-ONLY).
если вы не используете формат ACCDB, вы можете использовать безопасность уровня пользователя Jet. Это удивительно сложная технология, если вы действительно хотите заблокировать доступ к данным - вы должны следовать всем инструкциям, изложенным в официальном документе Jet Security, до письма, иначе ваши данные будут открыты для всех, у кого есть стандартный файл рабочей группы Jet. И даже когда вы закончите, он будет взломать (хотя и не потратит $$$ на покупку взломанного программного обеспечения). Кстати, пароли базы данных до Access 2007 были совершенно бесполезны и легко взламывались. Access 2007 повышает безопасность, повышая уровень шифрования данных, но пароль базы данных вызывает много проблем и не позволяет иметь более одного уровня доступа (если вы не предоставите два разных интерфейса с разными паролями - ср. # 2).
если вы просто хотите использовать Jet ULS для управления доступом в своем внешнем интерфейсе, вы можете добавить своих пользователей в группы, а затем проверить членство в группах в ваших интерфейсных объектах пользовательского интерфейса (т. Е. Формах) и указать НАПИСАТЬ разрешение пользователям, входящим в группу пользователей, предоставляющую такой уровень доступа. Самый простой способ сделать это, предполагая, что у вас больше пользователей READ-ONLY, чем тех, у кого есть разрешение WRITE, состоит в том, чтобы пользователи READ-ONLY вошли в систему как пользователь по умолчанию (т.е. вы ничего не делаете для их настройки) и имели WRITE пользователи входят в систему как пользователь с правами WRITE. Другими словами, если они не вошли в систему как пользователь "admin", они имеют полный доступ WRITE.
другой альтернативой является использование групп безопасности NTFS. Код API для этого находится в Access Web , но для его реализации требуется администратор Windows. Опять же, вы будете ограничивать доступ в вашем приложении перед тем, как фактически ограничивать права пользователей в MDB.
Только Jet ULS позволяет вам запретить редактированию ваших данных пользователю ТОЛЬКО ДЛЯ ЧТЕНИЯ (который не взломал файл вашей рабочей группы). Все пользователи должны иметь сетевой доступ к вашему внутреннему MDB, но вы можете затруднить им доступ к данным, даже не прыгая через трудности в реализации Jet ULS. Вот некоторые шаги, чтобы сделать это (и да, все они являются формой «безопасности от неясности» и только замедляют пользователя READ-ONLY, решившего взломать ваш бэкэнд):
Щелкните правой кнопкой мыши каждую таблицу на своем бэкэнде и включите атрибут HIDDEN. Это также можно сделать в коде (см. SetHiddenAttribute в справке). Естественно, если конечный пользователь устанавливает свои параметры доступа для отображения скрытых таблиц, это ничего не изменит. Но большинство конечных пользователей не знают об этом, и если ваши пользователи запускают ваше приложение во время выполнения, у них не будет возможности.
Измените свойства запуска внутренней базы данных на , а не , чтобы отобразить окно базы данных, и на , а не используйте специальные ключи. Код для настройки свойств запуска можно найти в разделе справки «AllowBypassKey».
В вашем бэк-энде создайте макрос с именем AutoExec с помощью одной команды Quit. Если специальные ключи отключены, невозможно предотвратить выполнение этого макроса, и как только пользователь попытается открыть серверную часть (даже если он удерживает клавишу SHIFT, т. Е. Стандартное нажатие клавиши для обхода всех процедур запуска) база данных (и экземпляр Access) закроются.
Теперь все эти вещи могут быть отменены кем-то, кто знает, что они делают. Если бы вы предоставили мне бэкэнд для реализации этих вещей, я бы занялся этим через 5 минут, просто запустив код в другой базе данных Access, чтобы изменить все эти свойства запуска, чтобы дать мне доступ.
Но ваши конечные пользователи, вероятно, не имеют такого уровня знаний. Любой такой пользователь, который, вероятно, должен быть пользователем ЗАПИСАТЬ, нет? :)
Да, конечно - все эти вещи легко взломать любой, кто знает, как. Но также легко ворваться в ваш дом за несколько секунд для человека с правильными инструментами. Это не значит, что вы не запираете двери, даже если это не пуленепробиваемая защита от взлома.
Другое соображение заключается в том, что если вы предоставите своим пользователям только среду выполнения Access вместо полного доступа, они не смогут отменить ни одну из этих настроек в вашем внутреннем MDB.
Последнее всего:
Безопасность - это не только техническая проблема, но на самом деле это проблема людей. Чтобы люди могли выполнять свою работу, вы должны в определенной степени доверять им доступ к вашим данным. Например, нет технического решения проблемы ненадежного системного администратора, и единственный способ полностью защитить ваши данные - вообще не предоставлять им доступ к ним.