0

Web.config悪意のあるユーザーが私たちの Web サーバーやチーム内の若手開発者にアクセスすることからファイルを保護する必要があります。RsaProtectedConfigurationProviderファイルの暗号化と復号化に成功しました。ただし、接続文字列の復号化は、暗号化されているかどうかに関係なく、アプリケーション内からアクセスするのと同じくらい簡単です

protected void btnShowConnectionString_Click(object sender, EventArgs e)
{
    lblMessage.Text = WebConfigurationManager.ConnectionStrings["MyTestConnection"].ConnectionString;
}

このような回避策を回避するために接続文字列を保護するにはどうすればよいですか?

4

3 に答える 3

1

secure string connectionmsdn による推奨ソリューションに関するこのリンクを読むことができます

リンク: http://msdn.microsoft.com/en-us/library/89211k9b(v=vs.80).aspx

于 2013-03-29T10:38:32.840 に答える
1

標準的なソリューションではこれを行うことはできません。

このような保護を行うには、この接続文字列を使用して標準ライブラリの周りに独自のラッパーを作成する必要があります。これにより、webconfig から接続文字列が復号化されます。また、Sentinel Hasp などを使用して、ラッパーが逆コンパイルされないように保護する必要があります。ラッパーを保護しない場合、暗号化アルゴリズムを取得して接続文字列を復号化するのは簡単です。

ただし、運用接続文字列を開発者の webconfig に書き込まない方が簡単です。本番環境にデプロイするときは、開発者環境を使用して本番環境の接続文字列を開発および記述します。

于 2013-03-29T10:35:36.800 に答える
1

私見、あなたが言及している「回避策」は実際には回避策ではなく、それが何であるかです。

アプリケーション (Web またはその他) は、実際に接続できるように、情報を復号化できる必要があります。SQL サーバーに対して Windows 認証を使用していない限り、user/pwd は常に "そこ" にあります...私が抱えている厄介な質問は、なぜ/どのようにそのようなコードがアプリケーションに存在するのか (そもそも) ですか?

上記の以前の回答で述べたように、開発環境を本番環境から分離してください。おそらく、本番環境には本番構成の変換のみがあります。

于 2013-03-29T12:11:49.460 に答える