Web設定で接続文字列を設定することは良い習慣ですか？
最近、私の職場で何人かの同僚と話し合っています。暗号化された文字列接続が.DLLにある方がよいと彼らが言ったからです。そして、暗号化されたweb.configで定義された文字列接続を使用しないのはなぜですか。エンティティフレームワークは、たとえば、アプリケーションのWeb構成で接続の名前を探すため、同じであり、より優れています。セキュリティポイントから、何が良いのか、または何がベストプラクティスなのかを知りたいですか？
実質的な違いはありませんが、DLLに入れて構成を変更したい場合は、実際にバイナリをビルドする必要がありますが、管理者は、よく知られている既成のツールを使用して構成を変更するだけです。設定にある場合。 構成文字列を暗号化するためのメカニズム と MSDNの追加ガイダンス はすでにあります。 Asp.Netの現在のバージョンには別のメカニズムがある可能性があるため、アプローチに取り組む前に追加の調査を行ってください。
DLLに何かが置かれているからといって、それが安全になることはありません。テキストエディターもバイナリファイルを開くことができ、Reflectorなどのツールは、.Net DLLをナビゲートするためのより優れたインターフェイスを提供できます。 a DLLは、「特別な」暗号化を提供しません。
暗号化されたデータがどこに保存されているかは重要ではありませんどのように重要ですか暗号化されています。
通常、web.configの暗号化されたセクションは Data Protection API で暗号化されます。これは、極端に妥協せずに解読することが困難ですマシン全体。同様のRSAキーコンテナーを使用することもできます（マシンから取得するのが難しい）。
暗号化された文字列をDLLに保存したい場合は、それは問題ないと思いますが、本質的には暗号化されたweb.configよりも安全ではありません（DLLで- Reflector ）、そして明らかに変更が困難です（再コンパイルする必要があります）しかし、さらに重要なことは、暗号化された文字列がどのように生成されたかです;おそらく同じプロバイダーを使用していません暗号化されたweb.configの場合、何を使用していますか？
暗号化方式は、秘密鍵または共有秘密と同じくらい強力です。そのキーがまたアセンブリに格納されている場合は、暗号化がまったく行われていない可能性もあります。外部データベースに格納されている場合、thatデータベースの接続文字列がどのように保護されているかという問題が発生します。これは実際には全体的なセキュリティの低下につながるだけです。
一方、サービスプロバイダーであり、接続文字列がuserパスワードで暗号化されている場合、それはmore静的マシンキーを使用するよりも安全です。繰り返しになりますが、ユーザーパスワードを使用して暗号化する場合は、ユーザー（開発者ではない）のアクションに応答して生成および保存する必要があるため、暗号化されたデータをアセンブリにハードコーディングすることはほとんどありません。
実際に、DLL）で（暗号化された）接続文字列をハードコーディングすることは、関連するweb.configセクションを暗号化するよりも安全です。せいぜい追加するだけです。不便な点としては、最悪の場合、不器用に記述されたカスタムセキュリティが穴だらけになっているためです。機密データが含まれている場合は、web.configを暗号化してください。
ASP.NETのベストプラクティスは、すべての構成/設定をweb.configファイルまたはapp.configファイル（他のプロジェクトタイプの場合）に置くことです。
暗号化とそれを接続文字列で使用する理由については、非常に特殊なケースでなければなりません。ほとんどの場合、最大99％であるため、接続文字列を暗号化する必要はありません。 Microsoft独自のエンタープライズアプリケーションの接続文字列は、web.config/app.configファイルで公開されています。セキュリティが複雑すぎると思います。
もう1つ、接続文字列をハードコーディングすることは悪い習慣です。たとえば、接続文字列（別名connectionstring）をDLLまたは.aspx/.ascx/.cshtmlまたは分離コードに含めないでください。