Безопасность строки подключения Microsoft Access 2010 и ODBC - PullRequest
1 голос
/ 13 апреля 2011

Я использую Microsoft Access 2010 с несвязанными формами. Связанные таблицы не допускаются, в противном случае строка соединений сохраняется в определениях таблиц. Следовательно, мы будем использовать определение запроса без имени для доступа к SQL SERVER. Это рекомендуется Microsoft. Нам нужно получить строку подключения откуда-то, хотя. Поэтому рекомендуется вернуть его из метода с запутанным именем. Рекомендуется не вставлять строку подключения в виде простого текста в исходный код приложения. Поэтому мы используем шифрование.

Хороший способ сделать это - потребовать, чтобы администратор приложения определил строку подключения при первом запуске приложения и в соответствии с этой статьей MSDN

... зашифруйте его значение через DPAPI с помощью пользовательского ключа учетной записи, под которым приложение запускает , и сохраните зашифрованное значение в реестре Windows.

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

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

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

Должен быть более простой способ, есть идеи?

1 Ответ

0 голосов
/ 14 апреля 2011

Есть ли причина, по которой вам нужно сохранить строку подключения от сеанса к сеансу? Не могли бы вы вместо этого создать форму входа в свое приложение, в которой вы принимаете учетные данные пользователя, экземпляр сервера и имя базы данных, к которым они будут подключаться, и сохраняете эту информацию в памяти во время работы приложения?

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

...