SQLデータを提供するためにdomain \ computername $アカウントを使用することの影響IIS
私たちのコーダーの1人は、彼が開発している新しいWebアプリ（.Net 4.0、MVC、IIS 7.0/7.5）でWindows認証を機能させることを試みています。
アプリケーションは、単一のSQLログオンアカウントを介してSQL Serverデータベースバックエンドに接続します。
ドメイン\コンピュータ名$
単一のデータベース内で同じ名前のユーザーアカウントにマップされ、次の役割が与えられます。
db_datareader
db_datawriter
その後、Windowsドメインユーザーは何らかの方法で認証され、DBへのアクセスが許可されます。
Webサーバー（SQLサーバーではない）がネット上で公開されている場合に、これが重大なセキュリティリスクをもたらすかどうか誰かが知っていますか？ NT AUTHORITY\ANONYMOUS LOGONにこれらの権限を与えるのと同じくらい悪いことのように思えますが、私はこの分野に厳密に対応しているわけではないことを認めなければなりません。
Webサーバーのセキュリティには影響しません。
この場合、Webアプリケーションは次のいずれかのコンテキストで実行されている可能性が高いため、接続しているアカウントはマシンアカウントになります。
- ネットワークサービスアカウント
- AppPoolIdentityアカウント。
どちらの場合も、それらは非対話型のアカウントに制限されており、アプリケーションはalreadyのいずれかのアカウントのコンテキストで実行されているため、作成されるWebサーバーまたはネットワークにさらされることはありません同じアカウントを使用してデータベースにアクセスする。データベース（およびデータベースサーバー）への公開は、このアカウントアクセスを構成する方法によって決定され、同じ方法で構成された他のアカウントを使用して作成された公開と同じです。
アカウントをdb_datareaderロールとdb_datawriterロールに追加することに関しては、それは不合理ではありません。ストアドプロシージャを介してすべてのデータアクセスが行われ、アカウントをpublicロールに制限できれば、betterになりますが、基礎となるテーブルに直接アクセスする必要があります。これは、データにアクセスして更新するために必要な最小限の権限セットであり、それほど危険ではありません。アプリでのSQLインジェクション攻撃の可能性を説明することがより重要になります。
Webアプリが侵害された場合、攻撃者は通常、アプリケーションを実行しているユーザーと同じ権限を取得します。それがどのように聞こえるかから、それはドメインユーザーでしょう。また、データベースへの読み取りおよび書き込みアクセス権を持っているようです。そこに何があるかによっては、それを望まないかもしれません。