セットアップIIS 8.5-セキュリティ慣行
IISインストールをセットアップするのはこれが初めてであり、最大限のセキュリティを確保するために確認したいと思います。セットアップ中にいくつかの質問が浮かびました。
このサーバーは、同時に約50人のユーザーと1日あたり約1000人のユーザーがいる外部のWebサイトをホストしていることに注意してください。顧客はこれらのサイトを使用する）
アプリケーションプールID：
アプリケーションプールIDにビルトインアカウントApplicationPoolIdentityを使用することがセキュリティのベストプラクティスであると読みました。私の質問は、Wep Application Isolationを展開するために、このアプリケーションアカウントごとにこのアカウントを使用できるかどうかです。つまり、持っているすべてのWebアプリケーションに異なるAppPoolをセットアップします。 Webアプリごとに異なるApppoolを展開したとしても、これはすべてのAppPoolで同じアカウントを使用するという矛盾ではありませんか？
サーバー強化：
できるだけ少ない機能とサービスをインストールして、サーバーを可能な限り強化します。インストールした機能が使用されているかどうか、またはまったく必要ないかどうかを確認する方法はありますか？ （ええ、私は知っています。少しnoobの質問）
認証：
外部訪問者がいるWebサイトには匿名認証が必要ですか？ www.mycompany.comのような誰もがアクセスできる必要があるウェブサイト匿名認証を無効にする方法をまだ見つけていませんが、誰もがウェブサイトにアクセスできるようにしています。
一般的なネットワークの質問：
IISのベストプラクティスは、サーバーをDMZにすることです。サーバーがハッキングされた場合、侵入者が他のすべてにアクセスできないためです。私たちのドメインネットワークにあるサーバー。ドメインコントローラーと通信する必要があるDigestauthentificationのような新しい認証方法があり、サーバー自体もこのためにドメインにある必要があるので、私はそれを自問していましたサーバーをドメインネットワークに配置し、他のセキュリティ対策（プロキシなど）を使用してサーバーへのアクセスをセキュリティで保護する方が適切でしたか、それともDMZが最良のセキュリティ対策ですか？
よろしくお願いします。
1。アプリケーションプールID
アプリケーションごとに個別のアカウントを使用します。各アプリケーションプールは、割り当てられたユーザーコンテキストで実行される個別のw3wpプロセスになります。ファイルやその他のリソース（データベース認証など）のようなものがあると、デフォルトのオペレーティングシステム、ファイルシステム、およびその他のセキュリティサブシステム（Kerberosなど）の利用によるセキュリティを強化できます。
明らかに、割り当てられたアカウントは、ホストへのアクセスをできるだけ少なくする必要があります（アプリケーションで絶対に必要でない限り、ウェブサイトには特権の高いアカウントを使用しないでください（実際にはそうではありません））。
可能であれば、istronglyは、公開されているWebサイトをホストしているサーバーと内部のものを分離することをお勧めします。パブリックに到達可能なサーバーも、別のネットワークセグメントに配置する必要があります。
2。サーバーの強化
主な攻撃対象はIIS（サーバーの前にファイアウォールがあると仮定しています）-ローカル攻撃を防ぐためにサービスを無効にすることによる強化が必要です。ローカルの場合、ローカルネットワーク（ネットワーク関連のサービス）だけでなく、独自のオペレーティングシステムやローカルハードウェア（ cachebleed のように）も使用できます。
だから、はい-不要なサービスを無効にします。あなたを保護するサービスを無効にしないでください。このことについては、Webでいくつかのリソースを見つけることができます。
最終的にサーバーのより多くの部分を構成する可能性のあるカスタムアプリケーションを悪意のあるユーザーが起動するのを防ぐには、ソフトウェア制限ポリシーを使用することをお勧めします：
- アプリケーションプールが弱いアカウント（ワークステーションのユーザーなど）を使用しており、「アプリケーションパス」と見なされるパスにアプリケーションをインストール/変更できない
- 実行されるソフトウェアをこれらのパスに制限する
これは相互排除につながり、シェルを開いて実際にサーバーへの扉を開く実際のアプリケーションをダウンロードするなどの単純な攻撃を防ぎます。
SSL/TLS iを使用する場合は、ここでもサーバーを強化することをお勧めします。このジョブに適したツールは、検証用の IISCrypto および SslLabs です。時間があれば、トランスポートセキュリティに関する追加の利点を提供するリバースプロキシとしてNGINXを使用することを検討できます。
3。認証
匿名認証は、多かれ少なかれ「認証なし」です。だから大丈夫です。
4。ネットワークセグメンテーション
多くのネットワークがDMZの概念を適用し、そこにサーバーの束全体を配置し、プライマリネットワークへの扉を開いて、でホストされているサーバーから提供されるサービスのバックエンド接続をサポートすることでDMZ。
これにより、何のメリットもないネットワークセグメンテーションがあるという結論につながります。
したがって、はい、DMZ絶対にあります。しかし、そこにすべてを入れたり、不要なドアを開けたりしないでください。同じDMZに関連しないサービスが多すぎる場合は、提供されるサービスを互いに関連し、依存関係があるサービスグループに分離する分離ゾーンを作成する。
IISのセキュリティのベストプラクティスは完全な規律であり、何ヶ月も読んで学習することができます。そして、あなたは確かに正しい質問をしています。
私はあなたの特定のトピックのそれぞれについて長くワックスをかけて説明をしますが、すでに十分に文書化されている情報を繰り返すだけです。
つまり、IISでベストプラクティスの構成を実行する場合は、CIS II8ベンチマークに従ってください。知って設定する必要があるすべてがここにあります。 https://benchmarks.cisecurity.org/tools2/iis/CIS_Microsoft_IIS_8_Benchmark_v1.4.0.pdf