接続文字列を集中化して保護する最良の方法は何ですか？

Question

アプリケーションで使用される接続文字列を集中化して保護する最良の方法は何ですか？私の環境には、多くの内部アプリケーションがあります。データベースにアクセスするには、各アプリケーションに1つ以上の接続文字列が必要です。これらすべての接続文字列（特にSQLログインとパスワード）を一元化することにより、35種類の.configファイル、レジストリエントリなどではなく1か所でパスワードを変更できるようにすることを目標としています。

現在、アクセスデータベースから接続文字列情報を取得する自作コンポーネントを使用しています。これは集中化の要件をカバーしていますが、特に安全ではありません。さらに、従来のasp、vb6、delphi、c ++ 、. netの言語で記述されたアプリケーションがあるため、これらのすべてのアプリケーションでソリューションを使用できる必要があります。

これをもっとうまくやる方法のアイデアを誰かが持っているか、アプリケーションがデータベースにアクセスする方法へのアプローチ全体をやり直す必要がありますか。

Answer 1

Windowsサーバーを使用して、SQL Serverデータベースへのアクセスを許可するユーザーを作成できます。次に、接続文字列で統合Windowsログインを使用できます。

BTWパブリックMDBにパスワードを保存すると、パスワードは無関係になります。存在しないのと同じです。

Answer 2

私が勤務している会社は、代わりにSQL Serverデータベースを介して同様の状況を利用しています。最終的に、COM準拠の.net dllを作成して、データベースへのAPIを簡素化および保護し、同じロジックが従来のasp、.Net、およびDTSパッケージ間で使用されるようにしました。私たちにとっては長年うまくいきましたし、多くの人がやりたいリファクタリング項目がありますが、サーバーの移行や名前の変更などの問題に対処するのは素晴らしいことです。

あなたは正しい道にいると思います。ただし、次の変更をお勧めします。

• 真のデータベースサーバーに移行してみてください。アクセスはMS Officeには最適ですが、この規模のアクセスには適していません。
• 誰が情報を追加および編集しているかを監査できる管理コンソールを構築します（誰がどの設定にアクセスできるかを保護します）。
• COM準拠のDLLをビルドして、安全で一貫した方法で他のシステムで使用できるようにします。

編集：

このようなシステムで何年も働いた後に気づいたのは、いくつかの解決策と手を少し結びつけていることです。接続文字列が構成ファイルに含まれていない場合、そこにある多くのツール（つまり、.Net世界のnHibernate、Elmahなど）は実際に制限されます。多くは、APIを使用するように簡単に変更できます。ただし、それを使用するかどうかを調査するには、より時間がかかります。ちょっと参考にしてください。

Answer 3

接続文字列でWindow Integrated Securityに移動することはできません。その場合、セキュリティの側面についてそれほど心配する必要はありません（実際の接続の場所をセキュリティで保護する必要がない限り）。