Каков наилучший способ централизовать и защитить строки подключения?

Question

Каков наилучший способ централизации и защиты строк соединений, используемых приложениями? В моей среде у нас много внутренних приложений. Каждому приложению требуется одна или несколько строк подключения для доступа к базе данных. Наша цель - централизовать все эти строки подключения (в частности, логины и пароли SQL), чтобы мы могли менять пароли в одном месте, а не в 35 различных файлах .config, записях реестра и т. Д.

В настоящее время мы используем доморощенный компонент, который извлекает информацию строки подключения из базы данных доступа, это покрывает требование централизации, но не особенно безопасно. Кроме того, у нас есть приложения, написанные на языках классического asp, vb6, delphi, c ++, .net, поэтому решение должно быть пригодно для использования всеми этими приложениями.

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

Answer 1

Компания, в которой я работаю, использовала аналогичную ситуацию в базе данных SQL Server. В итоге мы создали COM-совместимую DLL-библиотеку .net, чтобы упростить и защитить API в базе данных и обеспечить использование той же логики между классическими пакетами asp, .Net и DTS. Это отлично сработало для нас в течение года, и хотя есть некоторые пункты рефакторинга, которые многие из нас хотели бы с этим сделать, было здорово решать такие вопросы, как миграция серверов или переименование.

Я думаю, что вы на правильном пути; Однако я бы порекомендовал следующие изменения:

• Попробуйте перейти на настоящий сервер базы данных. Доступ отлично подходит для MS Office, но не для такого масштаба.
• Создайте административную консоль, которая позволяет проверять, кто добавляет и редактирует информацию (защищенный, кто также имеет доступ к каким настройкам).
• Создайте COM-совместимую DLL, чтобы ее можно было безопасно и согласованно использовать другими системами.

EDIT:

Что-то, что я заметил после многих лет работы в такой системе, это то, что она слегка связывает ваши руки в некоторых решениях. Многие инструменты (например, nHibernate, Elmah и т. Д. В мире .Net) действительно ограничены, когда строка подключения больше не находится в файлах конфигурации. Многие могут быть легко изменены для использования вашего API; однако, это то, что требует больше времени для изучения, если вы хотите использовать его. Просто к вашему сведению.

Answer 2

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

Кстати, хранение паролей в общедоступной MDB делает их неактуальными. Так же, как они не существуют.

Answer 3

Если в строках соединения невозможно перейти к Window Integrated Security, то вам не нужно слишком беспокоиться об аспекте безопасности (если, конечно, вам не нужно защищать фактическое местоположение соединения).