信頼できる接続を使用しない場合のリスクは何ですか？
たとえば、シナリオは次のとおりです。web.config内の接続文字列でSQL接続を使用し、データベースにselectコマンドを送信して、結果を表示する4〜5行のコードのみを持つ非常に単純なアプリケーションを作成しました。インターフェイス。
ここでのセキュリティの弱点は何ですか？
編集：
信頼できる接続が認証に関連していることは知っていますが、使用しないとシステムがハッキングされる可能性があるのではないかと思います。（私は会社のサーバーでアプリケーションを使用します。アプリケーションはパブリックアプリケーションであるため、すべての会社のメンバーが使用できます。ローカルの会社のアプリケーションである場合、なぜ信頼できる接続が必要なのですか？）
逆に言えば、信頼できる接続の主な利点は、アプリケーションでパスワードを管理する必要がないことです。アプリケーションが SQL Server に接続するためにパスワードを必要とする場合、アプリケーション ユーザー (または他の開発者、システム管理者、外部コンサルタントなど) が読み取れないように、パスワード (または接続文字列) をどこに配置しますか?必要に応じて簡単に変更できますか?
ファイルまたはレジストリ内のパスワードは、アプリケーションを実行するときにパスワードを取得する必要があり、ユーザーがアクセスする必要があるため、ユーザーによって読み取られることがよくあります。または、システム管理者またはコンサルタントが、アプリケーション構成ファイルがあるファイルシステムにアクセスできます。何らかの形式の暗号化を使用してパスワードを難読化することは可能ですが、復号化キーを保護および管理する必要があります。アプリケーションでパスワードをハードコーディングすると、変更が難しくなり、ソース管理システムでパスワードが表示される可能性が高くなります。ソース管理システムは通常、(設計上ではないにしても、実際には) 比較的安全でないシステムです。アプリケーションが起動時にパスワードを取得する Web サービスを作成できますが、その後、何らかの方法でサービスへのアクセスを認証する必要があります。
信頼できる認証を使用すると、オペレーティング システムに認証を任せることで、これらすべてを完全に回避できます。また、世界クラスのセキュリティ プログラマーでない限り、Windows は、自分で作成するよりも信頼性の高いメカニズムを提供する可能性が高くなります。
会社のサーバーでアプリケーションを使用します。このアプリケーションは公開アプリケーションであるため、会社のすべてのメンバーが使用できます。ローカルの会社のアプリケーションである場合、なぜ信頼できる接続が必要なのですか?
信頼されていない接続のセキュリティ リスクは、SQL サーバーのパスワードを保存し、アプリケーションで使用する方法にあります。パスワードを構成ファイルまたはプログラムのハードコードに保存すると、コードにアクセスできる他の開発者がそれを表示でき、最悪の場合、アプリケーションを破壊したり機密情報を盗んだりするような方法でデータベースを変更できます。それはプライバシー侵害にもなり、あなたの会社はこれで訴えられるかもしれません (何が起こるか想像できません)。
@Pondlife も非常に詳しく説明しています。
私の知る限り、信頼できる接続が提供する唯一の追加のセキュリティ層は認証です。信頼できる接続を使用する場合、Windows は Active Directory で接続を認証します。
簡単なグーグルでこのリンクが得られます：