.NETWebアプリケーションを介してアクセスしたいデータベースがあります。web.configの接続文字列は簡単に暗号化できますが、ボックスにアクセスできる開発者なら誰でも数行のコードで復号化できます。ボックスにアクセスできるため、マシンに保存されている暗号化キーにアクセスできます。構成。
ユーザーアカウントへのアクセスを拒否することでデータベースからユーザーを締め出すことはできますが、Webアプリが王国のことわざの鍵を持っていることは役に立ちません。Webアプリで使用されるSQLアカウントを知識のある開発者が利用できなくても、Webアプリがデータベースにアクセスできるようにするための良い方法を知っている人はいますか？
これは鶏が先か卵が先かという問題です。アプリケーションがシークレット（接続文字列を暗号化するためのキー）にアクセスできる場合、アプリケーションと同じ権限で実行されているすべてのユーザーにもシークレットがあります。
これを管理する最善の方法は、シークレットをまったく持たず、SQLServer接続文字列でlogin/ pwdを使用せず、統合セキュリティ（SSPI）を使用することです。このように、アプリケーションは、ネットワーク上でクレデンシャルを送信せずに、Windowsクレデンシャル（アプリケーションを実行しているアカウント）を使用してデータベースに対して認証します（通常の認証とは、開くたびにアプリケーションとデータベースの間でログイン/パスワードが渡されることを意味します）接続）、パスワードを保存する必要はありません。実行中のアカウントのパスワードが簡単に推測できないことを確認する必要があります。その後、アカウントが安全であるのと同じくらい安全になります（これについては何も書きませんが、プロセス間で資格情報を渡すよりもはるかに優れています）。
同じクレデンシャル（アプリケーション内の任意のコード）で実行されるものはすべて、サービスアカウントの権限でも実行されることに注意してください。
また、アプリケーションアカウントがDBで実行できることを、必要最小限に制限する必要があります（admin / dboなし）。
プログラムがデータを暗号化する方法を知っていて、キーがどこにあるかを知っていれば、データを復号化できます。（"I" ==任意の開発者）
キー（Unixパーミッション、Windows ACL）を保護すると、ほとんどのキーが停止する可能性がありますが、プログラムにいつでも行を追加して、キー（または暗号化されていないデータ）を秘密の場所にダンプすることができます。（または、暗号化コマンドを、実際には単純なXORまたは同等の外観のコマンドに変更します...）
結論として、私がソースコードを制御できれば、プログラムに何でも実行させることができます。
あなたはこれを間違った方法で見ているかもしれません。
セキュリティの高い状況では、開発者は（他のすべての人と同じように）本番データベースにアクセスできないようにする必要があります。これは、ファイアウォールなどで実行できます。
Yann Schwartzが述べたようにSSPIを使用する場合、データベースにアクセスできるのは本番Webサーバーのみです。それが不可能な場合、システム管理者は展開時に（暗号化された）パスワードをweb.configファイルに手動で配置する必要があります。
言うまでもなく（または少なくともそうすべきです）、開発/QA用に異なる認証を備えた別個のデータベースが必要です。
開発者を信頼できない場合は、まったく異なる一連の問題が発生する可能性があると思いますが、aspnet_setregをチェックして、それが役立つかどうかを確認することをお勧めします。
または、知識のない開発者を雇うこともできます。:)
ここで与えられた答えは質問に答えません。
設定ファイルの値を暗号化する理由はたくさんあります。ボックスが侵害された場合にデータベースサーバーボックスが侵害されないことを確認するなど。
そのデータベースがoracleやsybaseなどのSQLサーバー以外のものである場合、上記のソリューションは機能しません。
この問題を解決するために、ASP.NET2.0でのWeb.Config値の暗号化には多くのリンクがあります。
この質問で提起する意味で、開発者が深刻なセキュリティリスクをもたらすと本当に信じている場合は、すぐにそれらを解雇し、最終的に信頼できる開発者を雇う必要があります。
DBのキーで信頼できない開発者も、コードベースで信頼されるべきではありません。
サイドノートDEL*からそれらを遠ざけているもの。*ファイルシステム上？