集中和保護應用程序使用的連接字符串的最佳方法是什麼？在我的環境中，我們有很多內部應用程序每個應用程序都需要一個或多個連接字符串才能訪問數據庫。我們的目標是集中所有這些連接字符串（特別是SQL登錄名和密碼），以便我們可以在一個位置更改密碼，而不是在35個不同的.config文件，註冊表項等中。集中和保護連接字符串的最佳方法是什麼？
當前我們正在使用家庭成分組件它從訪問數據庫中提取連接字符串信息，這涵蓋了集中要求，但不是特別安全。另外，我們使用經典的asp，vb6，delphi，C++，.net語言編寫應用程序，因此所有這些應用程序都需要使用該解決方案。
有沒有人有如何更好地做到這一點的想法，或者我們是否需要將我們的整個方法修改爲我們的應用程序訪問數據庫的方式。
您可以使用Windows服務器來創建允許訪問您的SQL Server數據庫的用戶。然後，您可以在連接字符串中使用集成的Windows登錄。
BTW在公共MDB中存儲密碼使它們變得不相關。和他們不存在一樣。
這比連接字符串存儲庫更好。一個COM組件本質上並不安全，因爲攻擊者沒有義務使用它。如果COM組件可以訪問您的存儲庫，那麼任何其他進程都可以訪問。 – 2009-11-16 22:24:59
我工作的公司通過SQL Server數據庫使用了類似的情況。我們最終創建了一個符合COM的.net dll來簡化和保護API到數據庫中，並確保在經典的asp，.Net和DTS包之間使用相同的邏輯。它對我們來說一年的工作非常好，雖然有一些重構項目是我們很多人想要處理的，但解決服務器遷移或重新安裝等問題非常好。
我認爲你是在正確的道路上;但是，我會建議進行以下更改：
編輯：
東西在一個系統工作多年這樣的是，它稍微綁你的手在一些解決方案之後，我已經注意到了。當連接字符串不再存在於配置文件中時，那裏的許多工具（即.Net世界中的nHibernate，Elmah等）都是有限的。許多可以很容易地修改使用您的API;然而，這是需要更多時間來調查，如果你想使用它。就此而言，只是一個參考。
是不是可以在連接字符串中移動到Window Integrated Security，那麼您不必擔心安全方面的問題（除非您需要確保連接的實際位置）。
經過我們老化的集中式存儲庫之後，我發現遵循現有的配置文件最佳實踐以及專用Windows帳戶和集成安全性是更好的方法。我們確實獲得的很少，並且通過集中式方法損失很多，並且有第三方工具可以幫助管理整個企業中的配置文件的配置點。 – Stimy 2013-10-02 17:11:22