アプリケーションで使用される接続文字列を一元化して保護する最善の方法は何ですか? 私の環境には、多くの内部アプリケーションがあります。各アプリケーションには、データベースにアクセスするために 1 つ以上の接続文字列が必要です。これらすべての接続文字列 (特に SQL ログインとパスワード) を一元化して、35 の異なる .config ファイルやレジストリ エントリなどではなく、1 か所でパスワードを変更できるようにすることを目標としています。
現在、アクセス データベースから接続文字列情報を取得する独自のコンポーネントを使用しています。これは集中化の要件をカバーしていますが、特に安全ではありません。さらに、従来の asp、vb6、delphi、c++、.net などの言語で記述されたアプリケーションがあるため、ソリューションはこれらすべてのアプリケーションで使用できる必要があります。
これを改善する方法を知っている人はいますか?それとも、アプリケーションがデータベースにアクセスする方法に対するアプローチ全体を作り直す必要がありますか?
私が働いている会社は、代わりに SQL Server データベースを介して同様の状況を使用しています。最終的に、COM 準拠の .net dll を作成して、データベースへの API を簡素化および保護し、従来の asp、.Net、および DTS パッケージ間で同じロジックが使用されるようにしました。この 1 年間はうまく機能しており、多くの人がやりたいリファクタリング項目がいくつかありますが、サーバーの移行や名前の変更などの問題に対処するのは素晴らしいことです。
あなたは正しい道を進んでいると思います。ただし、次の変更をお勧めします。
編集：
このようなシステムで何年も働いた後に気づいたことは、いくつかのソリューションでは手を縛られるということです。そこにある多くのツール (つまり、.Net の世界では nHibernate、Elmah など) は、接続文字列が構成ファイルに含まれなくなった場合に実際に制限されます。多くは API を使用するように簡単に変更できます。ただし、使いたい場合は調査に時間がかかるものです。参考までに。
Windows サーバーを使用して、SQL Server データベースへのアクセスを許可するユーザーを作成できます。次に、接続文字列で統合 Windows ログインを使用できます。
ところで、パスワードをパブリック MDB に保存すると、それらは無関係になります。存在しないのと同じです。
接続文字列でウィンドウ統合セキュリティに移動することはできませんか?その場合、セキュリティの側面についてそれほど心配する必要はありません(接続の実際の場所を保護する必要がない限り)。