Вопросы | ms-access

MS Access - каковы самые низкие требуемые разрешения для внутреннего файла и для папки, содержащей его

Вопрос

user11170 | 7035 просмотров | рейтинг: 1

Я поддерживаю приложение ms-access, разделенное на внешние и внутренние файлы. Файл интерфейса находится в пользовательских компьютерах. Внутренний файл находится в общей папке на сервере. Какие минимальные разрешения требуются? могу ли я дать некоторым пользователям только разрешения на чтение в этой папке? (или скрыть это от них каким-либо другим способом), но все же разрешить им просматривать данные? Как обеспечить максимальную безопасность файла данных и папки, в которой он находится?



Ответы

Fionnuala

+ 0 -
Да - он разрешается вплоть до прав доступа к файлу, а также для чтения / записи. Вы не можете выполнить какой-либо тип обновления данных (вы получите операцию, требующую обновляемого запроса), если пользователь не предоставит учетные данные, которые позволяют ему писать, или вы разрешите запись в файл. Выполнение запроса требует только доступа для чтения.  


David-W-Fenton

+ 2 -
К сожалению, файл блокировки (ldb) должен быть создан, обновлен и удален. Если пользователь с недостаточными разрешениями открывает базу данных, она будет заблокирована для всех остальных пользователей, поэтому всем вашим пользователям необходимы разрешения на чтение / запись / удаление на внутреннем сервере. РЕДАКТИРОВАТЬ # 1 Файл блокировки должен создаваться при каждом открытии базы данных, включая связанные таблицы, и удаляться при закрытии базы данных. Если файл блокировки завершается, а база данных закрывается, это указывает на возникшую проблему. Вы также столкнетесь с проблемами при сжатии и восстановлении, если он запущен с недостаточными разрешениями. Редактировать № 2 Безопасность для доступа - довольно серьезная тема, и она в значительной степени зависит от вашей среды и требований. Для внутреннего интерфейса она варьируется от пароля к базе данных, который является тонким, но вполне подходящим для большинства офисов, до безопасности доступа, которая может быть сложным и был удален в 2007 году. Вот ссылка http://support.microsoft.com/kb/207793 для загрузки часто задаваемых вопросов по безопасности Microsoft Access для версий <2007. Информацию о безопасности на 2007 год можно найти здесь http://www.microsoft.com/technet/security/guidance/clientsecurity/2007office/default.mspx.  


Anonymous

+ 2 -
Многие предлагают, чтобы вы давали ПОЛНЫЕ права доступа пользователям, но это не так. Вам нужно только дать им разрешения MODIFY - вы можете отказать им в разрешении DELETE, что является хорошей идеей, поскольку запрещает пользователям случайно удалять ваш файл данных. Это правда, что для пользователя с разрешениями DELETE файл LDB будет удален при выходе, когда этот пользователь будет последним пользователем, выходящим из базы данных. Но не обязательно, чтобы файл LDB был удален - действительно, в Access 2 и ранее файлы LDB не удалялись при выходе, а просто оставались там, оставаясь без дела. Как правило, это не имеет недостатка, но иногда файл LDB повреждается и вызывает проблемы, и его действительно нужно удалять и создавать заново. У меня есть два класса пользователей базы данных (как определено в пользовательских группах безопасности NT, специфичных для моих приложений Access) - DBAdmins и все остальные. DBAdmins имеют полные разрешения, все остальные только ИЗМЕНИТЬ. В результате каждый раз, когда DBAdmin завершает работу как конечный пользователь, LDB удаляется. Эта установка работает очень хорошо, и я использую ее уже более десяти лет.  


Anonymous

+ 1 -
Использование скрытого ресурса для вашего бэкэнда на самом деле является лишь защитой от неясности и не стоит затраченных усилий. Опытные пользователи могут понять это с помощью любого количества методов (в зависимости от того, как вы заблокировали свой интерфейс): просмотреть таблицу MSysObjects и найти строка CONNECT для таблиц, который будет идентифицировать скрытое доля. изучить результаты CurrentDB.TableDefs (имя связанного таблица). Подключитесь в ближайшем окне в VBE Теперь, если вы правильно защитили свое приложение, используя безопасность на уровне пользователя Jet (и очень легко подумать, что вы защитили свою базу данных и обнаружили, что есть дыры, просто потому, что действительно легко забыть некоторые важные шаги в процесс), они не смогут этого сделать, но даже если у вас есть, безопасность Jet ULS взломана (ее довольно легко найти в Google и найти взломающее программное обеспечение), так что на самом деле это не то, от чего вам следует зависеть на 100%.


Теги

ms-access