У меня есть распределенная интерфейсная база данных MsAccess, в которой используется серверная часть mysql.
Он использует ODBC-соединения Windows System DSN для подключения к серверу. Все мои связанные таблицы относятся к этому соединению ODBC. Дело в том, что все они используют одно и то же имя пользователя и пароль, которые жестко запрограммированы на каждом компьютере.
Как лучше реализовать его, чтобы каждый пользователь получал логин?
Поскольку каждое DSN-соединение является «аппаратным», я не думаю, что перезапись реестра при каждом запуске приложения является безопасным способом, поскольку в момент сбоя приложения настройки DSN останутся.
Я не знаю, могу ли я оставить системный DSN без имени пользователя и пароля для запроса, однако мы подключаемся к четырем разным базам данных, поэтому я не хочу, чтобы пользователь вводил свою информацию четыре раза, так как это просто расстроит пользователя.
Я подумал, может быть, я мог бы использовать пользователя System DSN как доступного только для чтения для пользовательской таблицы, или, может быть, предпочтительнее процедура, которая проверяла бы пользователя, кроме как после проверки, я не уверен, как я впоследствии подключу каждую таблицу. Могу ли я сохранить глобальную переменную в строке подключения ODBC?
Как лучше сделать MsAccess более осведомленным о пользователях?
(Я просмотрел настройки безопасности MSACCESS, однако кажется, что Microsoft отказывается от этого, и моя попытка установить его полностью блокирует меня и не предоставляет никакой формы проверки входа в систему. Я думаю, он просто использует вход вдов в качестве безопасности, но это не настоящее решение) И здесь есть отказ от ответственности:
Введение в безопасность Access 2010 (office.microsoft.com)
Доступ и безопасность на уровне пользователя
Access не поддерживает безопасность на уровне пользователя для баз данных, созданных в новом формате файлов (файлы .accdb и .accde). Однако если вы откроете базу данных из более ранней версии Access в Access 2010 и к этой базе данных будет применена безопасность на уровне пользователя, эти параметры все равно будут работать.
ВАЖНО Разрешения, созданные с помощью функции безопасности на уровне пользователя, не защищают вашу базу данных от пользователей, имеющих злонамеренные намерения, и не предназначены для использования в качестве барьера безопасности. Эту функцию целесообразно использовать для повышения удобства использования базы данных для доверенных пользователей. Чтобы обеспечить безопасность ваших данных, разрешите только доверенным пользователям доступ к файлу базы данных или связанным файлам безопасности на уровне пользователя с помощью разрешений файловой системы Windows.
Если вы конвертируете базу данных из более ранней версии Access с безопасностью на уровне пользователя в новый формат файла, Access автоматически удаляет все параметры безопасности, и применяются правила защиты файла .accdb или .accde.
Наконец, помните, что все пользователи могут видеть все объекты базы данных в любое время, когда вы открываете базы данных с новым форматом файлов.
Насколько я понимаю, вы стремитесь обеспечить более персонализированный опыт / среду для ваших конечных пользователей в приложении («пользователи приложения»), а также повысить безопасность путем объединения процесса аутентификации пользователя с учетными данными подключения OBDC DSN («база данных пользователь ").
Такая настраиваемая пользовательская среда обычно достигается за счет аутентификации конечных пользователей в вашем приложении. Обычно это делается путем ввода имени пользователя и пароля (которые обычно хранятся в my_app_db.users table) при загрузке приложения.
Прежде чем эта аутентификация пользователя приложения может произойти, само приложение (или машина) должно установить соединение с сервером базы данных. Этот «пользователь базы данных» обычно достигается с помощью:
CREATE и GRANT разрешения (обычно пользователь root), чтобы установщик мог создать нужного пользователя базы данных.Что касается безопасности, здесь важно Правило наименьших привилегий: этому пользователю базы данных должно быть предоставлено только наименьшее количество привилегий, необходимых для правильной работы приложения (т.е. SELECT, INSERT, UPDATE и, возможно, DELETE, и только для базы данных приложения. , а не системную / главную базу данных).
Это в сочетании с не хранение учетных данных базы данных в виде обычного текста на машинах конечных пользователей может помочь защитить ваши применение от несанкционированного доступа. Имейте в виду, что если злоумышленник получает доступ локального администратора к машине, на которой установлено ваше приложение, игра в значительной степени окончена: они, вероятно, могут вытащить эту строку подключения из дешифрованной памяти или даже нюхать трафик MySQL в сетевом интерфейсе, чтобы получить учетные данные пользователя базы данных, и в этот момент все зависит от того, насколько ограничены вы сделали этого пользователя (ну, и, надеюсь, MySQL регулярно обновляется) и насколько сложным и решительным является злоумышленник.
Имейте в виду, что многие приложения базы данных будут использовать сервер приложений, по сути, «сторожа» посередине, который осуществляет соединения с базой данных и из нее от имени клиента. Обычно это делается из соображений производительности / масштабируемости, но есть также преимущество в безопасности, поскольку сервер базы данных может быть изолирован / ограничен только сервером приложений, и никакие клиенты конечных пользователей не могут напрямую обращаться к нему.
Что касается параметров ODBC DSN и MySQL, я не очень разбираюсь в том, что доступно. Однако, похоже, есть Поддержка встроенной аутентификации Windows в более поздних версиях MySQL.
Однако мне удалось успешно использовать соединитель MySQL / NET с сертификатами безопасности в сочетании с MySQL и приложением ASP.NET, но я не знаю, распространяется ли это вообще на Microsoft Access; вам, вероятно, придется написать там немного клея .NET.
И когда / если доходит до деталей, вам, вероятно, лучше спросить в Переполнение стека в таком случае.
Надеюсь это поможет.