Microsoft Windows Server 2008 R2: 証明書が RDS のセキュリティを強化する

[アーティクル]
08/25/2016

証明書は、リモートデスクトップサービスホストとクライアント間の接続を保護するうえで、大きな役割を果たしています。

Kristin Griffin

証明書を使用している役割はどれか、という質問は引っ掛け問題の 1 つです。この質問の答えは "すべて" です。リモートデスクトップサービス (RDS) 展開で証明書が使用される場所と証明書を特定の RDS の役割サービスで使用する理由について理解することが重要です。

ほとんどの役割は構成する必要がありますが、(RD ライセンスサーバーなど) その必要がないものもあります。既定では、セッションやホストされた仮想マシン (VM) に接続するすべての段階で、SSL (x.509) 証明書が必要になります。これらの証明書には、クライアントとサーバー間の通信を保護する、クライアントが接続しているサーバーまたは Web サイトの ID を確認する、リモートデスクトッププロトコル (RDP) ファイルのソースが信頼されている場所にあるもので変更されていないことがユーザーにわかるように RDP ファイルを署名するという 3 つの主な目的があります。

RDS で証明書が使用される例には、次のようなものがあります。

RD セッションホストサーバーでは、証明書を使用して身元を証明します。これは "サーバー認証" といいます。
RD セッションホストサーバーと RD 仮想化ホストサーバーでは、証明書を使用して、クライアントとサーバー間に TLS 1.0 のリンクをセットアップします。
RD セッションホストサーバーでは、証明書を使用して、ネットワークレベル認証 (NLA)、シングルサインオン (SSO)、および Web SSO の実装に必要なクライアント認証を行います。
RD セッションホストサーバーと RD 接続ブローカーでは、SSL 証明書を使用して RemoteApp と VM の RDP ファイルに署名することで、ユーザーが信頼されたファイルを起動していることを保証します。
RD ゲートウェイサーバーでは、証明書を使用して、クライアントとの TLS 1.0 通信を暗号化します。
SSL 証明書を使用して RD Web アクセスサイトを保護すれば、ユーザーが信頼されたサイト (HTTPS) にアクセスすることを保証できます。

RDS の機能を有効にすると、証明書の使用をサポートするために、特定のテクノロジを使用します (図 1 参照)。

RDS の機能を有効にすると、特定のセキュリティテクノロジを利用することになる

図 1 RDS の機能を有効にすると、特定のセキュリティテクノロジを利用することになる

チャネルを保護する

TLS は、Netscape によって開発された SSL バージョン 3 をベースとしたインターネット技術標準化委員会 (IETF) の標準です。TLS の強化点には、新しいメッセージ通知、証明書をルート証明機関 (CA) 証明書ではなく中継 CA 証明書につなげること、SSL とはわずかに異なる暗号化アルゴリズムなどがあります。

TLS は SSL ベースの標準ですが、両者に互換性はありません。ただし、TLS には、必要に応じて SSL バージョン 3 に戻すことができるメカニズムが実装されています。TLS を使用するクライアントとサーバー間で安全な通信チャネルを確立するには、クライアントとサーバーで、メッセージング、応答、および暗号化のプロセスを行う必要があります (図 2 参照)。

安全なチャネルを確立するための双方向の暗号化プロセス

図 2 安全なチャネルを確立するための双方向の暗号化プロセス

このプロセスが適切に機能するためには、次の 2 つの要件があります。

クライアントで、サーバーの SSL 証明書に署名する CA が信頼されている必要があります。
サーバーとクライアント間の接続では、高レベルの暗号化 (既定) または Federal Information Processing Standard (FIPS) 暗号化を使用する必要があります。低レベルの暗号化では、クライアントからサーバーへのトラフィックのみが暗号化され、サーバーからクライアントへのトラフィックは暗号化されないので、セキュリティ機能や共有シークレットを送信する方法として安全ではありません。

接続と暗号化のレベルが上記 2 つの要件を満たしている場合、クライアントとサーバーでは次のように通信を確立します。

クライアントは、ランダムな固定長の値と共に、Hello メッセージを送信します。サーバーは、ランダムな固定長の値で応答します。この交換プロセスでは、クライアントは、サポートする圧縮方法、暗号化、ハッシュをサーバーに通知します。また、プロトコルのバージョンとセッション ID もサーバーに送信します。セッション ID は、通信チャネルを識別するためのもので、RD セッションホストサーバーのセッション ID ではありません。
サーバーは、クライアントとサーバーの両方がサポートする最も高度な暗号化方式と、クライアントが提示したリストから暗号とハッシュ関数を選択し、選択したものをクライアントに通知します。サーバーで最小レベルが設定されている場合に、クライアントが最小レベルを満たさない場合は、接続は失敗します。
サーバーが、クライアントにデジタル証明書を送信します。この証明書には、サーバー名、証明書に署名した信頼されている CA、およびサーバーの公開キーが含まれています。
クライアントは、証明書が有効で信頼されていることを検証します。サーバーの証明書の署名に使用された証明書は、クライアントの信頼されたルート証明機関ストアにあります。それから、クライアントは、プリマスターシークレットを作成し、サーバーの公開キーで暗号化してサーバーに送信します。
サーバーは、プリマスターシークレットを受け取って、秘密キーを使用して暗号化を解除します。これを実行できるのは、公開キーに一致する秘密キーを保有している、このサーバーだけです。
サーバーとクライアントのどちらにも、プリマスターシークレットと、プロセスの最初で交換したランダムな数字があります。サーバーとクライアントは、これらの値を使用して、48 バイトのマスターシークレット (共有シークレット) を生成します。マスターシークレットを生成すると、サーバーとクライアントは、プリマスターシークレットを削除します。
クライアントとサーバーは、48 バイトのマスターシークレットをハッシュして、MAC シークレット (ハッシュに使用するセッションキー) と WRITE キー (暗号化に使用するセッションキー) の生成に使用します。これらのキーは、このセッションの通信を暗号化/暗号化解除します。セッションが終了すると、キーは破棄されます。

これらの手順が 1 つでも機能しない場合、接続は完全には保護されません。この場合の処理は、リモートデスクトップ接続 (RDC) クライアントの [詳細設定] タブの設定によって異なります。認証が失敗した場合、ユーザーは、次のいずれかから実行する操作を選択できます。

サーバーの認証で問題があったことをクライアントに通知せずに接続する
クライアントに警告メッセージを表示して接続する (既定の設定)
確認できない場合は接続を拒否する

サーバーが最小のセキュリティレベルを要求している場合は、例外になります。サーバーで最小レベルが設定されている場合に、クライアントが最小レベルを満たさない場合、接続は失敗します。既定では、クライアントとサーバーがネゴシエートし、両方がサポートする中で最も安全な接続の設定を使用します。

CredSSP による資格情報のキャッシュ

資格情報のキャッシュは、Windows Vista と Windows Server 2008 で導入されました。資格情報のキャッシュにより、2 つの機能 (ユーザーをサポートする機能とサーバーを保護する機能) が使用できるようになりました。

資格情報のキャッシュは、特定の接続の資格情報を保存して、ユーザーがサーバーに接続するたびに資格情報を提示する必要性をなくします (これが SSO です)。その結果、迅速にサーバーに接続できるようになります。資格情報をキャッシュできない場合、その都度、ブローカー接続を確認する必要があります。

サーバー側では、資格情報のキャッシュによって、セッションを確立する前にサーバーに資格情報が提示されます。これにより、ユーザーが承認されていない場合のセッションのオーバーヘッドを回避できます (これが NLA です)。

資格情報のキャッシュは、Credential Security Service Provider (CredSSP) によって機能しています。CredSSP は、Windows 7、Windows Vista、Windows Server 2008、および Windows XP SP3 でサポートされています。CredSSP は OS の構成要素なので、使用されている RDC のバージョンとは関係ありません。CredSSP では、次の機能を実行します。

NLA では、接続が完全に確立される前に、RD セッションホストサーバーに対してユーザーを認証するフレームワークを提供します。
ファーム内のセッションに再接続するために、RD セッションホストサーバーがセッション全体を確立しなくてもログインしているユーザーを確認できるようにして、適切なサーバーに接続を渡すプロセスを高速化しています。わずかに異なるシナリオで、NLA が使用されます。
SSO では、ログオンを自動化するために、ユーザーの資格情報を保存して RD セッションホストサーバーに渡します。

CredSSP では、サーバーとクライアントの相互認証を可能にします (図 3 参照)。

サーバーとクライアント両方の認証で安全なチャネルが必要である

図 3 サーバーとクライアント両方の認証で安全なチャネルが必要である

この認証プロセスでは、次の手順を実行します。

クライアントが、TLS を使用して、サーバーとの安全なチャネルを開始します。サーバーは、名前、CA、および公開キーを含む証明書を返します。この時点では、サーバーのみが識別され、クライアントは匿名のままです。
セッションが確立されセッションキーが作成されたら、CredSSP では Simple and Protected GSS-API Negotiation (SPNEGO) プロトコルを使用して、サーバーとクライアントを相互に認証します。基本的に、このメカニズムでは、Kerberos や Windows NT LAN Manager (NTLM) など、クライアントとサーバーの両方がサポートする認証メカニズムに合意できるようにします。
相互認証が完了したら、クライアント側の CredSSP では、手順 2. で作成したセッションキーでサーバーの証明書を暗号化して、サーバーに送信します。サーバーは、暗号化された証明書を受け取り、秘密キーで暗号化を解除して、証明書番号の最上位ビットに 1 を追加します。その後、結果を暗号化して、クライアントに返します。この処理により、クライアントとサーバーの間で行われたやり取りをインターセプトして、サーバーをスプーフすることが不可能になります。
クライアントは、サーバーから受け取った暗号化されている証明書を確認して、ローカルにある証明書と比較します。
結果が一致すると、クライアント側の CredSSP では、ユーザーの資格情報をサーバーに送信します。

サーバーの ID を認証する

資格情報を提示するように求めるリモートコンピューターと通信する場合、サーバーが偽装されている危険性があることに留意してください。承認されていないサーバーが、信頼されたサーバーを偽装している場合、無意識のうちに不適切なサーバーに資格情報を渡してしまうことになりかねません。このような事象が発生すると、ドメインやサーバーに接続するために必要なすべての情報が攻撃者の手に渡ってしまいます。

RDP には暗号化の機能が用意されていますが、このプロトコルには、サーバーを認証する方法がありません。ここで役に立つのが、TLS と CredSSP です。サーバー認証では、接続先 RD セッションホストサーバーの RD 構成ツールで指定された証明書に含まれている名前と RDC クライアント (または RDP ファイル) にユーザーが入力した名前を照合します。

RDP ファイルに署名する

証明書を使用して、RemoteApp ファイルやプールされた VM または個人用 VM (VDI) への接続に使用する RDP ファイルにデジタル署名することができます。これらのファイルに署名すると、ファイルが信頼されたソースによって作成されていることがユーザーに保証されます。また、RDP ファイルが改ざんされるのを防ぐこともできます。

RemoteApp ファイルの署名は、Web SSO の実装でも必要になります。ファイルの署名によって、ユーザーは、RD Web アクセスの Web サイトに 1 回の操作でサインインできるようになります。1 回サインインすると、その後は、資格情報を再提示することなく、すべてのファームから RemoteApp を起動できます。

CredSSP では、RD Web アクセスに資格情報を渡すことができません。ユーザーは、まず Web サイトにログインして、資格情報を格納する必要があります。その後は、RemoteApp プログラムを起動するために、再度認証が必要になることはありません。これを機能させるためには、RemoteApp が署名され、RemoteApp の署名に使用された証明書をユーザーが信頼している必要があります。

ユーザーが RD Web アクセスの [リモートデスクトップ] タブから RDP 接続を起動するときに作成される RPD ファイルは、その場で作成されます。ファイルは署名されていないので、デスクトップに接続するとき Web SSO は機能しません。ユーザーは、接続が確立されてから、エンドポイントにログインする必要があります。Web SSO は、プールされた VM や個人用 VM への接続でも機能しません。

接続を保護する

RD ゲートウェイでは、RD ゲートウェイと (通常、企業ネットワーク外にある (インターネット経由で接続する)) デスクトップクライアントとの間の通信を保護するために TLS 1.0 を使用します。既に説明したように、TLS では、SSL 証明書が必要になります。デジタル証明書を使用して Web サイトのセッション (HTTPS) を暗号化することで、クライアントと RD Web アクセスサーバー間の通信を保護することもできます。

証明書は、RDS 展開の重要な構成要素の 1 つです。RDS では、証明書を使用して、通信と RDS で有効にする機能を保護します。来月は、これらの証明書を使用するように RDS の役割サービスをセットアップする方法を説明します。

Raymond Chen

Kristin Griffin は、リモートデスクトップサービスの MVP です。サーバーベースコンピューティングのコミュニティに役立つマイクロソフトフォーラム (リモートデスクトップサービス) を運営しており、RDS に関するブログ (blog.kristinlgriffin.com、英語) を公開しています。また、Mark Minasi の著書『Windows Server 2008 パーフェクトガイド』(翔泳社、2010 年) と『Windows Server 2008 R2 パーフェクトガイド』(ソフトバンククリエイティブ、2010 年) の執筆に貢献し、『Microsoft Windows Server 2008 Terminal Services Resource Kit』(Microsoft Press、2008 年) と『Microsoft Windows Server 2008 R2 Remote Desktop Services Resource Kit』(Microsoft Press、2010 年) を Christa Anderson と共同で執筆しました。

次の方法で共有