リモートデスクトップ(RDP)の認証を強化しようとしたとき、実務でつまずくのは「製品を入れるかどうか」ではなく「どの接続経路に、どこまで適用されるのか」です。RDPは接続の経路によって認証が行われる場所が変わるため、同じ製品を導入しても構成によって守れる範囲が違います。この記事では、代表的な4つの構成それぞれで認証がどこにかかるかを整理し、設定したつもりで穴が残る典型的なパターンを解説します。
なお、RDPに認証強化が必要な理由そのものはWindows/Windows Server OSログインの二要素認証で、製品比較の観点はWindows向け多要素認証製品の選び方で扱っています。本記事は構成ごとの適用範囲に絞ります。
RDPで認証がかかる場所は1か所ではない
RDP接続が成立するまでには、認証が行われうるポイントが複数あります。ここを分けて考えないと、「2要素認証を導入したのにRDPでは効いていなかった」という状態に気づけません。
- 接続前の認証(ネットワークレベル認証／NLA) — セッションを張る前に資格情報を検証する段階。ここで弾ければ、そもそもログオン画面が表示されません
- 接続後のWindowsログオン — 接続先OSがログオン処理を行う段階。OSログインに追加要素を要求する方式はここで働きます
- ゲートウェイ機器での認証 — RD GatewayやVPN装置など、経路上の機器が独自に認証する段階
重要なのは、この3か所は互いに独立していることです。ゲートウェイで追加要素を求めていても接続先OSのログオンは素通り、逆にOSログオンを強化していても経路の入口には何もない、という構成が成立してしまいます。
接続経路別に、守れる範囲はどう変わるか
構成1：インターネットから直接RDP接続している
RDPのポートをインターネット側に開けている構成です。攻撃者は世界中からポートスキャンで到達でき、盗まれたID・パスワードをそのまま試すリスト型攻撃や総当たり攻撃の標的になります。
この構成では、認証を強化する場所は接続先OSのログオンしかありません。経路上に認証を挟む機器が存在しないためです。したがって、OSログイン自体に追加要素を要求する方式でなければ効果がありません。ただし、そもそもこの構成は経路を閉じる(直接公開をやめる)ことが先で、認証強化はその上での多重化として位置づけるべきものです。
構成2：RD Gateway経由で接続している
RD Gatewayを置き、外部からの接続をいったんゲートウェイで受ける構成です。ゲートウェイ側で追加要素を要求できるため、外部からの接続に対しては入口で止められます。
見落としやすいのは社内からの接続がゲートウェイを通らない点です。社内LANのPCから接続先へ直接RDPを張れる状態であれば、ゲートウェイの認証は迂回されます。1台の社内PCが侵害されれば、そこを起点に社内のサーバーへRDPで横移動できてしまう構成です。
構成3：踏み台サーバー(ジャンプサーバー)を経由している
いったん踏み台サーバーにRDPで入り、そこから目的のサーバーへ再度RDPで接続する構成です。認証が2回発生するため強く見えますが、2回目の認証で同じID・パスワードだけを使っている場合、実質的な壁は踏み台への1回目だけになります。
踏み台構成で効かせるべきは、踏み台へのログオンに追加要素を要求することと、踏み台から先へ進む際に使うアカウントを日常業務のアカウントと分けることです。ここが同一だと、踏み台を取られた時点で先のサーバーまで到達されます。踏み台側で使う管理者アカウントの扱いはWindows Serverの特権アカウント管理も参照してください。
構成4：VPNで社内に入ってからRDPを使っている
もっとも多い構成です。VPN装置で認証を行うため入口は守られますが、VPN接続後のRDPには何の追加認証もかかっていないケースが大半です。
この構成の弱点は、VPNの認証が突破されるか、VPN装置自体の脆弱性を突かれた場合に、社内のRDPが無防備なまま残ることです。近年のランサムウェア被害でVPN機器の脆弱性が主要な侵入経路になっているのは、この「VPNを抜ければ中は自由」という構成が広く使われているためです。VPNとRDPは別の層として、それぞれに認証を持たせる設計が必要になります。
コンソールログオンとRDPログオンが別扱いになる問題
認証を強化する仕組みの多くは、「本体の画面から直接ログオンする場合(コンソールログオン)」と「RDP経由でログオンする場合」を別のログオン種別として扱います。製品や設定によっては、一方にだけ適用されている状態が起こりえます。
実務上、これは次の形で表面化します。
- 導入時の動作確認をコンソールだけで行った — 目の前のPCで追加要素が求められることを確認して完了とし、RDP接続時には求められないことに気づかない
- サーバーの検証を省略した — クライアントPCで検証し、サーバーへはRDPしか使わないため実機確認をしていない
- 例外設定が残っている — 導入時の切り替え作業で一時的に除外した対象が、そのまま除外され続けている
したがって、導入後の確認はコンソールとRDPの両方で、対象となる全種別の端末について実際にログオンして確かめる必要があります。ここを設定画面の表示だけで済ませると、適用漏れが残ります。
導入前に決めておくこと
構成を整理したうえで、次の3点を先に決めておくと導入後の手戻りが減ります。
- 保守ベンダーのRDP接続をどう扱うか — 社外の作業者に追加要素をどう渡すか。渡し方と作業期間の限定については保守ベンダー・委託先アカウントの管理で詳しく扱っています
- 認証要素が使えないときの接続手段 — 認証キーの紛失や端末故障でRDPに入れなくなった場合、誰がどう復旧するか。ここを決めずに導入すると、障害対応時に例外を作って穴が固定化します
- サービスアカウントによる自動接続の有無 — バッチ処理や監視のためにRDPやリモート実行を使っているアカウントがあると、追加要素を要求した時点で処理が止まります。事前の洗い出しはサービスアカウントの管理を参照してください
自社の構成でどこに穴があるかを確認する
RDPの認証がどこまで効いているかは、経路の構成とログオン種別ごとの適用状況を突き合わせないと判断できません。applippliの無料診断では、約3分の質問に回答するだけで、リモート接続を含めた自社のID・パスワード対策の状況を確認できます。