Модель безопасности (развертывание) для приложения MS Access с SQL Server Backend

Question

У нас есть приложение, состоящее из внешнего интерфейса MS Access (2007, формат mdb), нескольких библиотек .net и внутреннего интерфейса SQL Server (2008). Я работаю над установщиком, который автоматически устанавливает среду выполнения MS Access, наше приложение, наши библиотеки, SQL Server Express и все настраивает.

Очевидно, что приложению MS Access и библиотекам (работающим в обычном пользовательском контексте без прав администратора ) необходим доступ к базе данных SQL Server. Как лучше всего предоставить доступ к приложению?

---

Это то, что я придумал. К сожалению, все они имеют недостатки:

• SQL Server Compact Edition : не поддерживает представления.

• Роли в приложениях : Кажется, это наилучшая практика . Тем не менее, он требует выполнения хранимой процедуры перед доступом к базе данных (я не могу передать учетные данные приложения в строке подключения). Таким образом, я не могу использовать это для присоединения таблиц SQL Server в качестве связанных таблиц в Access MDB , что является требованием нашего приложения Access.

• Пользовательский экземпляр SQL Server : Цитировать из MSDN: " Эта функция будет удалена в будущей версии Microsoft SQL Server. Избегайте использования этой функции в новых разработках ..."

• Аутентификация SQL : Microsoft говорит: « Если возможно, используйте аутентификацию Windows. »

• Использование проверки подлинности Windows и предоставление полного доступа BUILTIN \ USERS : Это, безусловно, самое простое решение, но почему-то это "неправильно" ...

Приложение предназначено для нетехнической аудитории, поэтому попросить пользователя настроить разрешения не вариант.

РЕДАКТИРОВАТЬ: Некоторые пояснения: это «локальное» приложение, т. Е. SQL Server расположен на том же компьютере, что и приложение; Доступ к SQL Server из сети не является ни необходимым, ни желательным. Программное обеспечение (обычное бизнес-приложение для управления запасами, счетами и т. Д.) Будет доступно для бесплатной загрузки, поэтому оно должно работать в различных средах (доменных / не доменных, в разных операционных системах и т. Д.) И ИТ для его установки не требуются знания - кроме обычного «нажмите на setup.exe, подтвердите запрос UAC, подтвердите каталог установки и т. д.». Я ожидаю, что наиболее распространенными сценариями будут «Windows XP, локальный администратор» и «Windows Vista / 7, локальный администратор с включенным UAC». Поскольку мы хотим следовать рекомендациям, работает приложение не должно требовать «Запуск от имени администратора» в последнем случае.

Answer 1

Как насчет:

• Использовать проект Access ADP, предварительно настроенный для подключения к локально установленному экземпляру SQL Server.
• Подключение через группу BuiltIn \ Users (или проверку подлинности SQL), но предоставить только минимальные полномочия.Достаточно войти в систему и ...
• Вызовите sp_setappprole, чтобы "повысить" клиентское соединение до идентификатора вашей определенной роли приложения.

Answer 2

Если звучит так, будто у вас есть только галстук айсберга.Когда дело доходит до продажи и развертывания приложений доступа SQL.

Я выбрал другой маршрут.У меня есть виртуальные машины как автономная рабочая станция, так и сервер домена и рабочая станция, все виртуальные.

У меня есть сценарии, которые представляют собой комбинацию VBA и VBScript.Спросите, работает ли БД и приложение на одном компьютере или на разных компьютерах.Если компьютер отличается от имени компьютера, на котором расположена БД.Является ли БД и приложение в среде рабочей группы, домашней группы или домена. На компьютере БД уже установлен SQL Express или более поздней версии. На компьютере приложения уже установлен Access или Access Runtime.
Если да, то какая версия.Будет ли у всех или только у ограниченных пользователей доступ.
Если ограничено, какое имя группы пользователей будет иметь доступ к данным.Существует ли эта группа, если нет списка имен пользователей, которые должны быть добавлены в группу? Также вопросы о пользователях и группах администратора

Сценарий запускает виртуальные машины и выполняет серию шагов, чтобы повторитьMDB и SQL DB для развертывания.Затем создает MSI для установки сервера с включенным пользовательским сценарием, который устанавливает среду.Наконец, упаковывает MDB в хороший MSI.

С тех пор я усовершенствовал этот процесс, чтобы дать возможность ответить на некоторые вопросы в начале установки сервера.Это означает, что группы пользователей и пользователи могут быть выбраны из списков на рабочей станции или в домене в зависимости от ранее заданных вопросов.

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

Сейчас я перехожу к следующему этапу и рассматриваю возможность размещения моего оценочного приложения в качестве SasS (Программное обеспечение как услуга) (Аренда).Таким образом, приложение можно использовать в любом браузере HTML5, Windows или Mac в качестве виртуального рабочего стола или устройства Android и Apple.Сказав, что Access немного уродлив на мобильных устройствах.

Когда я начну работать, я сделаю платформу доступной для других.

Answer 3

@ Хайнци пишет:

Использование проверки подлинности Windows и Предоставление BUILTIN \ USERS полного доступа: Это, безусловно, самое простое решение, но как-то это "кажется неправильным" делать что ...

Обычный подход здесь - добавить пользовательскую группу пользователей (например, «db-users») и поместить пользователей в эту группу. Таким образом, вы можете точно контролировать, кому разрешен доступ.