Каков самый простой способ разрешить одному пользователю доступ на запись и доступ ко всем остальным доступным только для чтения в базу данных MS Access в локальной сети?Как управлять правами пользователя в базе данных Access?
Я доверяю своим пользователям, но, к сожалению, Access сохраняет изменения в данных, как только строка таблицы отменяется. Случайные нажатия клавиш сохраняются без запроса пользователя о сохранении изменений.
Самый простой способ - использовать права доступа. Предоставьте доступ для записи в группу и поместите пользователей, которые должны писать в базу данных в этой группе. Поместите всех в читаемую группу. Это предполагает, что у вас есть домен Windows, конечно.
Here - это сайт, на котором есть информация о защите баз данных Access. Он имеет дело с Access 2000, может быть больше вариантов для более новых версий.
Очень распространенная причина проблем при доступе к базе данных Access заключается в том, что не все пользователи имеют полные права доступа к каталогу. – Fionnuala
На самом деле им не нужны полные разрешения - только все *, но * разрешение DELETE. Это будет означать, что файл LDB не будет удален, но это не имеет значения. Именно так Jet до версии 3.0 работал по умолчанию. –
Спасибо, поместив файл .mdb в общую папку, где только один пользователь имеет полные разрешения, а остальные имеют только разрешение на чтение, похоже, работает хорошо. – Liam
Это назойливый ответ, но если вам нужна более эффективная безопасность, серьезно подумайте о переходе на более надежную СУБД.
Я думал, что Access предназначен для простой базы данных для рабочего стола пользователя, а не для многопользовательского корпоративного решения. Если бы это было, у SQL Server не было бы причин. – duffymo
Я тоже так думал, но часто вижу документы Word и электронные таблицы, разделяемые в сети, и большинство людей обращаются к Access тем же. – Liam
К сожалению, мне нужно было написать многопользовательский доступ db в одном месте, потому что они не дали бы нам SQL-сервер. было больно сказать меньше –
Факт есть, НЕТ функциональной безопасности для базы данных доступа.
Ссылка ниже продает программное обеспечение, которое «восстановит» вашу базу данных доступа Даже если у нее есть пароль.
Хорошо, что они существуют. Их программа спасла один из прикладов моего клиента один раз, когда их предыдущий программист умер, и ни у кого другого не было пароля. Благодаря этой программе мы не смогли войти и никаких данных не было потеряно.
http://www.stellarinfo.com/access-recovery.htm
И прежде чем вы даже подумать, нет, я не работаю на них.
Пароль db действительно не является особо безопасным устройством. Это не означает, что «нет функциональной безопасности». До 2007 года модель безопасности пользователя была надежной. Я подозреваю, что инструмент Stellar Info не будет работать с пользовательской безопасностью до 2007 года, и я не вижу поддержки, указанной в версии 2007 года. –
Нет, никакой функциональной безопасности на .mdb-файлах нет. Есть больше бесплатных инструментов для извлечения пароля из одного, чем вы можете встряхнуть палку, потому что это просто, чтобы написать один. С документацией здесь: http://jabakobob.net/mdb/first-page.html Я мог бы написать хорошее консольное приложение, чтобы извлечь пароль за полдня на разных языках. «Модель безопасности пользователя», возможно, была надежной, но она была аналогична дверце из стального сердечника рядом с незамкнутым окном. –
Некоторые мысли о управлении правами пользователей в хранилище данных Jet:
, если вы действительно хотите, чтобы заблокировать вещи вниз, вы никогда не будете управлять с Jet, поскольку это по своей сути уязвимы, потому что пользователь должен имеют WRITE доступ к файлу MDB.
Если вы довольны контролем прав на данные в своем интерфейсном приложении, вы можете предоставить разные интерфейсные терминалы (один для пользователей WRITE и один для READ-ONLY).
Если вы не используете формат ACCDB, вы можете использовать безопасность на уровне Jet. Это удивительно сложная технология, если вы действительно хотите заблокировать доступ к данным - вы должны следовать всем инструкциям в White Paper White Paper к письму, или ваши данные будут открыты для всех, у кого есть стандартный файл рабочей группы Jet. И даже после того, как вы закончите, это является crackable (хотя не без расходов $$$ купить программное обеспечение для взлома). BTW, пароли базы данных до того, как Access 2007 были совершенно бесполезны и легко взломали. Access 2007 повышает безопасность, повышая уровень шифрования данных, но пароль базы данных вызывает множество проблем и не позволяет вам иметь более одного уровня доступа (если вы не предоставляете два разных интерфейса с разными паролями - ср. # 2).
Если вы просто хотите использовать Jet ULS для управления доступом в своем интерфейсе, вы можете добавить своих пользователей в группы, а затем проверить членство в группе в интерфейсных пользовательских интерфейсных объектах (т. Е. Формах) и дать WRITE разрешение пользователям, которые находятся в группе пользователей, которая обеспечивает этот уровень доступа.Самый простой способ сделать это, предполагая, что у вас больше пользователей READ-ONLY, чем у тех, у кого есть разрешение WRITE, заключается в том, что пользователи READ-ONLY регистрируются как пользователь admin по умолчанию (т. Е. Вы ничего не делаете для их настройки) и имеете WRITE пользователи регистрируются в качестве пользователя в группе с разрешением WRITE. Другими словами, если они не вошли в систему как пользователь «admin», у них есть полный доступ WRITE.
Другой альтернативой является использование групп безопасности NTFS. Код API для этого находится на Access Web, но для этого требуется администратор Windows. Опять же, вы ограничиваете доступ в своем внешнем приложении, а не ограничиваете права пользователя во внутреннем MDB.
только Jet ULS фактически позволяет предотвратить READ-ONLY пользователя (который не треснул файл рабочей группы) от редактирования данных. Все пользователи должны иметь сетевой доступ к вашему внутреннему MDB, но вы можете усложнить им доступ к данным, даже не перепрыгивая через обручи при внедрении Jet ULS. Вот некоторые шаги, чтобы сделать это (и да, все они являются формой «безопасность через маскировку» и будет только замедлить READ-ONLY пользователь определяется взломать ваш задний конец):
правой кнопкой мыши каждой таблицы на вашем заднем конце и включите атрибут HIDDEN. Это также можно сделать в коде (см. SetHiddenAttribute в справке). Естественно, если конечный пользователь устанавливает свои параметры доступа для отображения скрытых таблиц, это ничего не сделает. Но большинство конечных пользователей об этом не знают, и если ваши пользователи запускают ваше приложение во время выполнения, у них не будет такой возможности.
Изменения Startup Properties в серверной базе данных, чтобы не дисплея окна базы данных и на не использования специальных ключей. Вы можете найти код для настройки свойств запуска в разделе справки «AllowBypassKey».
В фоновом режиме создайте макрос с именем AutoExec с помощью одной команды Quit. Если отключены специальные клавиши, невозможно предотвратить выполнение этого макроса, и как только пользователь попытается открыть задний конец (даже если они удерживают клавишу SHIFT, то есть стандартное нажатие клавиши для обхода всех подпрограмм запуска) , база данных (и экземпляр Access) будет закрыта.
Теперь все эти вещи могут быть отменены кем-то, кто знает, что они делают. Если вы дадите мне задний план с этими реализованными вещами, я буду в нем примерно через 5 минут, просто запустив код в другой базе данных Access, чтобы изменить все эти свойства запуска, чтобы дать мне доступ.
Но ваши конечные пользователи, вероятно, не обладают таким уровнем знаний. Любой такой пользователь, который, вероятно, должен быть пользователем WRITE, нет? :)
Да, конечно, все эти вещи легко взломать любой, кто знает, как это сделать. Но также легко пробиться в ваш дом за секунды для человека с правильными инструментами. Это не означает, что вы не запираете двери, даже если это не пуленепробиваемая защита от взлома.
Другое соображение состоит в том, что если вы предоставляете своим пользователям только время выполнения Access, а не полный доступ, они не смогут отменить любые из этих параметров в вашем внутреннем MDB.
Последняя всего:
Безопасность не только техническая проблема - большинство из них, на самом деле, люди, проблемы. Для того, чтобы люди могли выполнять свою работу, вы должны доверять им в определенной степени, предоставляя им доступ к вашим данным.Например, нет технического решения проблемы ненадежного системного администратора, и единственный способ полностью защитить ваши данные - не предоставлять им никакого доступа к нему вообще.
@ David Спасибо за ваш вклад! Я уточнил свой вопрос, поскольку мне кажется, что нам нужно более простое решение. – Liam
Я думаю, что с помощью ODBC-соединения можно использовать Access как интерфейс практически для любой базы данных. Например, я успешно настроил базу данных SQL Server 2008 Express Edition с двумя пользователями, один для чтения/записи и один для чтения. Я смог подключиться к базе данных из Access, открыв источник данных ODBC. Таким образом, пользователь может иметь функциональные возможности создания отчетов и обмена сообщениями на основе Office, с которыми они знакомы. Но с любым сервером базы данных вы хотите.
Да, вы обязательно захотите выбрать SQL Server Express поверх брандмауэра .MDB. Хороший выбор! – HardCode
Этот разговор может быть немного старым, но по некоторым причинам у меня возникла такая же проблема в последнее время. Он не подходит для всех, потому что он полагается не на M $ SQL Server, а на MySQL. Используйте соединитель ODBC MySQL (см. Здесь: http://dev.mysql.com/downloads/connector/odbc/) и сохраните свои таблицы на сервере MySQL. Права пользователя Access на таблицы будут наследоваться от прав пользователя MySQL. Довольно легко настроить ...
Я думаю, что у вас есть неправильный заголовок вашего вопроса. Вы не спрашиваете о безопасности, но об управлении правами пользователя на данные. Это может быть достигнуто с помощью безопасности Jet ULS, если вы не используете формат ACCDB Access 2007. –