RPC over HTTP 展開に関する推奨事項

  • [アーティクル]

このセクションでは、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 プロキシであることを確認します。
  • RPC over HTTP クライアントが接続するマシンのみを含む ValidPorts レジストリ キーを構成します。
  • 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 Server から分離し、RPC プロキシを信頼されていない境界ネットワークに存在させるのは理にかなっています。 RPC プロキシが RPC over HTTP Server と同じコンピューター上にある場合、組織はすべてのバックエンド サーバーを信頼されていない境界ネットワークに強制的に配置し、信頼されていない境界ネットワークをセキュリティで保護することがはるかに困難になります。 RPC プロキシと RPC over HTTP サーバーの役割を分離すると、組織は信頼されていない境界ネットワーク内のマシンの数を管理可能にし、そのためより安全な状態を維持するのに役立ちます。
  • サーバー ネットワークの安全ヒューズとして機能します。 RPC プロキシは、サーバー ネットワーク用の拡張可能なヒューズとして設計されています。RPC プロキシで問題が発生した場合は、単に外に出て、実際の RPC を HTTP サーバー経由で保護します。 このセクションで概説されているベスト プラクティスがこれまでに従っている場合、RPC over HTTP トラフィックは SSL に加えて RPC 暗号化で暗号化されます。 RPC 暗号化自体は、クライアントとプロキシの間ではなく、クライアントとサーバーの間にあります。 これは、プロキシが受信した RPC トラフィックを認識せず、復号化できないことを意味します。 接続の確立、フロー制御、その他のトンネリングの詳細を処理するクライアントによって送信される一部の制御シーケンスのみが認識されます。 RPC over HTTP クライアントがサーバーに送信するデータにはアクセス権がありません。 さらに、RPC over HTTP クライアントは、RPC プロキシと RPC over HTTP サーバーの両方に対して個別に認証する必要があります。 これにより、多層防御が提供されます。 RPC プロキシ マシンが侵害された場合、何らかの構成エラーや何らかのセキュリティ侵害により、それを通過するデータは改ざんから保護されます。 RPC プロキシを制御する攻撃者は、トラフィックを中断できますが、読み取ったり改ざんしたりすることはできません。 これは、RPC プロキシのヒューズの役割が果たされる場所です。これは、HTTP トラフィック経由の RPC のセキュリティが損なわれることなく使用できます。
  • Web ファームで RPC プロキシを実行している複数のマシン間で、アクセス チェックと復号化作業の一部を配布します。 RPC プロキシは、Web ファームで正常に機能することで、組織は SSL 復号化と一部のアクセス チェックをオフロードできるため、バックエンド サーバーの処理容量を増やします。 RPC プロキシ マシンの Web ファームを使用すると、organizationは、フロントエンド サーバーの容量を増やすことによって、サービス拒否 (DoS) 攻撃に耐える能力を高めることもできます。

これまでのガイドラインの中で、組織には選択肢が残っています。 各organizationには、ユーザーの不便さ、セキュリティ、コストの間に選択肢と侵害があります。

  • 基本認証または Windows 統合認証を使用して RPC プロキシに対する認証を行う RPC over HTTP では現在、NTLM のみがサポートされています。Kerberos はサポートされていません。 また、HTTP ヘッダーに via プラグマを挿入する RPC over HTTP クライアントと RPC プロキシの間に HTTP プロキシまたはファイアウォールがある場合、NTLM 認証は機能しません。 そうでない場合、組織は基本認証と NTLM 認証のどちらかを選択できます。 基本認証の利点は、より高速でシンプルであるため、サービス拒否攻撃の機会が少なくなる点です。 ただし、NTLM の方が安全です。 organizationの優先順位に応じて、Basic、NTLM を選択するか、ユーザーが 2 つの中から選択できるようにします。 1 つだけを選択した場合は、RPC プロキシ仮想ディレクトリからもう一方をオフにして、攻撃のリスクを軽減することをお勧めします。
  • RPC プロキシと RPC over HTTP サーバーの両方に同じ資格情報セットを使用するか、それぞれに異なる資格情報を使用しますか? この決定のトレードオフは、ユーザーの利便性とセキュリティの間にあります。 複数の資格情報を入力するのが好きなユーザーはほとんどいない。 ただし、信頼されていない境界ネットワークでセキュリティ侵害が発生した場合は、RPC プロキシと RPC over HTTP Server に対して個別の資格情報セットを使用すると、追加の保護が提供されます。 個別の資格情報が使用され、1 つの資格情報セットがユーザーのドメイン資格情報である場合は、RPC プロキシではなく、RPC over HTTP Server に対してユーザーのドメイン資格情報を使用することをお勧めします。