セキュリティ QOS オプションの選択

セキュリティ QOS オプションは、RpcBindingSetAuthInfoEx 関数に指定された SecurityQOS パラメーターの一部として渡されます。 次のベスト プラクティスを使用します。

相互認証を使用する

真の相互認証は、特定のセキュリティ プロバイダー (Kerberos をネゴシエートする場合)、Kerberos、Schannel でのみ使用できます。 NTLM では、相互認証はサポートされていません。 相互認証を使用するには、整形式のサーバー プリンシパル名を指定する必要があります。 多くの開発者は、次の誤ったセキュリティプラクティスを使用します。サーバーは、そのプリンシパル名 (RpcMgmtInqServerPrincName) を要求するために呼び出され、そのプリンシパル名を使用して相互認証を盲目的に要求します。 このアプローチは、相互認証の概念全体を破ります。相互認証の考え方は、データを解析して処理するために信頼されているため、特定のサーバーのみが呼び出されるということです。 前述の誤ったセキュリティプラクティスを使用して、開発者は自分の名前を返すのに十分なスマートな人にデータを提供します。

たとえば、クライアント ソフトウェアが Joe、Pete、または Alice のアカウントで実行されているサーバーのみを呼び出す必要がある場合は、 RpcMgmtInqServerPrincName 関数を呼び出し、返される名前を確認する必要があります。 Joe、Pete、Alice の場合は、サーバー プリンシパル名を使用して相互認証を要求する必要があります。 これにより、会話の両方の半分が同じプリンシパルに確実に移動します。

クライアント ソフトウェアが Joe のアカウントでのみ実行されているサービスを呼び出す必要がある場合は、Joe のサーバー プリンシパル名を直接作成し、呼び出しを行います。 サーバーが Joe でない場合、呼び出しは単に失敗します。

多くの場合、サービスは Windows システム サービスとして実行されます。つまり、マシン アカウントで実行されます。 相互認証とサーバー プリンシパル名の作成は、引き続きお勧めします。

呼び出しの実行を許可する最下位の ImpersonationType を使用する

このベスト プラクティスはかなり自明です。 相互認証を使用する場合でも、サーバーに必要以上の権限を与えないでください。正当なサーバーが侵害された可能性があり、送信したデータが間違った手に落ちた場合でも、少なくともサーバーはユーザーに代わってネットワーク上の他のデータにアクセスできません。 一部のサーバーでは、呼び出し元を特定し、偽装するのに十分な情報がない呼び出しが拒否されます。 また、一部のプロトコル シーケンスでは、トランスポート レベルのセキュリティ (ncacn_np と ncalrpc) がサポートされていることに注意してください。 このような場合、バインド ハンドルを作成するときに NetworkOptions パラメーターを使用して十分に高い権限借用レベルを指定した場合、サーバーは常にユーザーを偽装できます。

最後に、一部のセキュリティ プロバイダーまたはトランスポートは、ImpersonationType を指定したよりも高いレベルに透過的にバンプする場合があります。 プログラムを開発するときは、目的の ImpersonationType を使用して呼び出しを行い、サーバー上で ImpersonationType が高くなっているかどうかをチェックしてください。