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

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

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

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


connection-string database-connection
person Stimy    schedule 25.11.2008    source источник
comment
Побывав в нашем устаревшем централизованном репозитории, я пришел к выводу, что использование существующих передовых методов работы с файлами конфигурации с выделенными учетными записями Windows и интегрированной безопасностью является лучшим подходом. Мы действительно очень мало получаем и очень много теряем при централизованном подходе, и есть сторонние инструменты, которые помогают управлять точками конфигурации через файлы конфигурации на предприятии.   -  person Stimy    schedule 02.10.2013

Ответы (3)


arrow_upward
2
arrow_downward

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

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

person dmajkic    schedule 25.11.2008
comment
Это намного лучше, чем репозиторий строк подключения. Компонент COM не является безопасным по своей сути, поскольку злоумышленник не обязан его использовать. Если компонент COM может получить доступ к вашему репозиторию, то же самое может сделать любой другой процесс. - person Peter Ruderman; 17.11.2009

arrow_upward
3
arrow_downward

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

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

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

РЕДАКТИРОВАТЬ:

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

person JamesEggers    schedule 25.11.2008

arrow_upward
0
arrow_downward

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

person Andrew Cox    schedule 25.11.2008