このセクションでは、RPC over HTTP を使用する場合の最大のセキュリティとパフォーマンスを実現するためのベスト プラクティスと推奨される展開構成について説明します。 ここに記載されているさまざまな構成は、さまざまなサイズ、予算、およびセキュリティの要件に基づいて異なる組織に適用されます。 また、各構成では、特定のシナリオに最適なデプロイに関する考慮事項も示されます。
大量の RPC over HTTP シナリオの詳細については、「Microsoft RPC 負荷分散」を参照してください。
次の推奨事項は、すべての構成に適用されます。
- RPC over HTTP v2 をサポートする Windows のバージョンを使用します。
- IIS 6.0 モードで RPC プロキシを実行するコンピューターに IIS を配置します。
- RPC プロキシ仮想ディレクトリへの匿名アクセスを禁止します。
- AllowAnonymous レジストリ キーを有効にしないでください。
- RPC over HTTP クライアントで、CertificateSubjectField (詳細については、「RpcBindingSetAuthInfoEx 」を参照) を使用して、接続先の RPC プロキシが予想される RPC プロキシであることを確認します。
- ValidPorts レジストリ キーを構成して、RPC over HTTP クライアントが接続するマシンのみを含めます。
- ValidPorts キーではワイルドカードを使用しないでください。そうすることで時間を節約できますが、完全に予期しないマシンもワイルドカードに適合する可能性があります。
- RPC over HTTP クライアントで SSL を使用します。 これらのセクションに記載されているガイドラインに従うと、RPC over HTTP クライアントは SSL を使用せずに接続できなくなります。
- SSL を使用するだけでなく、RPC 暗号化を使用するように RPC over HTTP クライアントを構成します。 RPC over HTTP クライアントが KDC に到達できない場合は、ネゴシエートと NTLM のみを使用できます。
- NTLMv2 を使用するようにクライアント マシンを構成します。 LMCompatibilityLevel レジストリ キーを 2 以上に設定します。 LMCompatibilityLevel キーの詳細については、msdn.microsoft.com を参照してください。
- 上記の構成で RPC プロキシ マシンの Web ファームを実行します。
- インターネットと RPC プロキシの間にファイアウォールをデプロイします。
- 最適なパフォーマンスを得るために、成功しないエラー コードに対して短い応答を送信するように IIS を構成します。 IIS 応答のコンシューマーは自動化されたプロセスであるため、わかりやすい説明をクライアントに送信する必要はありません。これらは単に RPC over HTTP クライアントによって無視されます。
セキュリティ、パフォーマンス、管理容易性の観点からの RPC プロキシの基本的な目標は次のとおりです。
- サーバー ネットワークへの RPC over HTTP トラフィックの単一のエントリ ポイントを指定します。 サーバー ネットワークへの RPC over HTTP トラフィックに対して単一のエントリ ポイントを持つことには、主に 2 つの利点があります。 まず、RPC プロキシはインターネットに接続されているため、ほとんどの組織は、通常の組織ネットワークとは別の信頼されていない境界ネットワークと呼ばれる特別なネットワークでこのようなマシンを分離します。 信頼されていない境界ネットワーク内のサーバーは、インターネットからの攻撃に耐えられるように、非常に慎重に管理、構成、監視されます。 信頼されていない境界ネットワーク内のマシンが少ないほど、コンピューターの構成、管理、監視、およびセキュリティ保護が容易になります。 2 つ目は、RPC プロキシがインストールされた 1 つの Web ファームで企業ネットワーク上に存在する任意の数の RPC over HTTP サーバーにサービスを提供できるため、RPC プロキシを RPC over HTTP サーバーから分離し、RPC プロキシを信頼されていない境界ネットワークに存在させるのは理にかなっています。 RPC プロキシが RPC over HTTP サーバーと同じコンピューター上にある場合、組織はすべてのバックエンド サーバーを信頼されていない境界ネットワークに強制的に配置し、信頼されていない境界ネットワークのセキュリティを維持することがはるかに困難になります。 RPC プロキシと RPC over HTTP サーバーの役割を分離すると、組織は信頼されていない境界ネットワーク内のマシンの数を管理しやすくし、セキュリティを強化するのに役立ちます。
- サーバー ネットワークの安全ヒューズとして機能します。 RPC プロキシは、サーバー ネットワークの消耗品ヒューズとして設計されています。RPC プロキシで問題が発生した場合は、単に出力され、HTTP サーバー経由で実際の RPC が保護されます。 このセクションで概説されているベスト プラクティスにこれまでに従っている場合、RPC over HTTP トラフィックは SSL に加えて RPC 暗号化で暗号化されます。 RPC 暗号化自体は、クライアントとプロキシの間ではなく、クライアントとサーバーの間にあります。 これは、プロキシが受信した RPC トラフィックを認識せず、復号化できないことを意味します。 接続の確立、フロー制御、およびその他のトンネリングの詳細を処理するクライアントによって送信される一部の制御シーケンスのみが認識されます。 RPC over HTTP クライアントがサーバーに送信するデータにはアクセス権がありません。 さらに、RPC over HTTP クライアントは、RPC プロキシと RPC over HTTP サーバーの両方に対して個別に認証する必要があります。 これにより、多層防御が提供されます。 RPC プロキシ マシンが侵害された場合、何らかの構成エラーまたは何らかのセキュリティ侵害により、それを通過するデータは改ざんから保護されます。 RPC プロキシを制御する攻撃者は、最大でもトラフィックを中断できますが、読み取ったり改ざんしたりすることはできません。 これは、RPC プロキシのヒューズの役割が果たされる場所です。これは、HTTP トラフィック経由の RPC のセキュリティが損なわれずに費やされます。
- Web ファームで RPC プロキシを実行している複数のマシン間で、アクセス チェックと復号化の作業の一部を分散します。 WEB ファームで適切に機能することにより、RPC プロキシを使用すると、組織は SSL 復号化と一部のアクセス チェックをオフロードできるため、バックエンド サーバーで処理できる容量が増えます。 RPC プロキシ マシンの Web ファームを使用すると、組織はフロントエンド サーバーの容量を増やすことで、サービス拒否 (DoS) 攻撃に耐える能力を高めることもできます。
これまでのガイドラインの中で、組織には選択肢があります。 各組織には、ユーザーの不便さ、セキュリティ、コストの間に選択肢と妥協があります。
- 基本認証または Windows 統合認証を使用して RPC プロキシに対する認証を行う RPC over HTTP では現在、NTLM のみがサポートされています。Kerberos はサポートされていません。 また、HTTP ヘッダーに プラグマを介して を挿入する RPC over HTTP クライアントと RPC プロキシの間に HTTP プロキシまたはファイアウォールがある場合、NTLM 認証は機能しません。 そうでない場合、組織は基本認証と NTLM 認証のどちらかを選択できます。 基本認証の利点は、より高速でシンプルであるため、サービス拒否攻撃の機会が少なくなる点です。 ただし、NTLM の方が安全です。 組織の優先順位に応じて、Basic、NTLM を選択することも、ユーザーが 2 つから選択できるようにすることもできます。 いずれか 1 つしか選択されていない場合は、RPC プロキシ仮想ディレクトリからもう一方をオフにして、攻撃のリスクを軽減することをお勧めします。
- RPC プロキシと RPC over HTTP サーバーの両方に同じ資格情報セットを使用するか、それぞれに異なる資格情報を使用しますか? この決定のトレードオフは、ユーザーの利便性とセキュリティの間にあります。 複数の資格情報を入力するユーザーはほとんどいない。 ただし、信頼されていない境界ネットワークでセキュリティ侵害が発生した場合、RPC プロキシと RPC over HTTP サーバーに対して個別の資格情報セットを使用すると、追加の保護が提供されます。 個別の資格情報が使用され、1 つの資格情報セットがユーザーのドメイン資格情報である場合は、RPC プロキシではなく RPC over HTTP サーバーに対してユーザーのドメイン資格情報を使用することをお勧めします。