リモートデスクトップのセキュリティ対策

リモートデスクトップのセキュリティ対策は、接続経路・認証・権限を分けて確認することから始まります。

「社外からつながるけれど安全か分からない」という担当者へ、VPN・RD Gateway・NLA・MFAの役割と、管理者へ確認する順序を図で解説します。

外資系エンジニア

この記事は以下のような人におすすめ！

社外から会社PCへの接続経路を確認したい人
NLAとMFAの違いを整理したい人
接続許可と更新・ログの点検を担当する人

リモートデスクトップの安全性は何で決まるか

1-1. 接続できることと、安全に使えることは別

自宅から会社のPCへ接続できたとしても、それだけでは安全性を判断できません。

確認したいのは、誰が接続先へ到達でき、どの段階で本人確認が行われ、接続後に何を操作できるかです。

Windowsのリモートデスクトップは、離れた端末から接続先PCのアプリやファイルを操作する機能です。

Microsoftは、有効化するとPCでポートが開き、ローカルネットワーク内の端末から到達可能になると説明しています（参考1）。

ただし、PCの設定をオンにしたことと、インターネットへ公開したことは同じではありません。

ルーターやファイアウォール、VPNなどの構成も含めて、接続経路を確認する必要があります。

この記事はWindows標準のリモートデスクトップを使う小規模組織の担当者向けに、社外からの経路と認証・権限の確認順を整理します。

第三者の遠隔操作サービスやクラウド仮想デスクトップでは設定や責任範囲が異なるため、同じ設定手順をそのまま適用しないでください。

1-2. 最初に確認する三つの境界

一つ目はネットワークの境界で、社外端末から接続先へ直接到達できるのか、会社が管理する入口を通るのかを確認します。

二つ目は認証の境界で、入口と接続先それぞれが何を使って本人確認するかを確認します。

三つ目は権限の境界で、接続できる利用者と、利用できるPCやアプリの範囲を確認します。

例えば、VPNに多要素認証があっても、別の経路から接続先PCへ直接到達できるなら、その入口だけを調べても十分ではありません。

逆に、社外から直接到達できなくても、不要な利用者が接続を許可されていれば、社内側の権限整理は必要です。

まずは「会社の承認した入口を通り、必要な人が、必要なPCへ接続する」という一文を、自分の構成図で説明できる状態を目指しましょう。

経路・認証・権限を分けて確認すると、「つながるから安全」という判断を避けられます。

外部公開と接続経路を確認する

2-1. PCの接続許可とルーターの公開設定を分ける

リモートデスクトップの有効化は、接続先PC側の準備です。

社外から到達できるかどうかは、ルーター等の転送設定やファイアウォールの許可にも左右されます。

図では社外PC、境界装置、社内PCを分け、直接転送する経路と入口を経由する経路を区別しています。

ここでの矢印は接続の開始方向を表し、実際の画面・入力データは接続後に双方向に流れます。

図は説明用の概念図であり、特定の会社の実測構成ではありません。

2-2. 設定が分からないときに集める情報

管理者へ確認するときは、接続先PC名、使っているクライアント、接続時に指定する名前、VPNの利用有無を伝えると整理しやすくなります。

RD Gatewayの指定がある場合は、そのサーバー名と管理担当も確認しましょう。

分からない設定を試しに削除したり、接続できないからとファイアウォールを無効にしたりする前に、現在の経路を記録します。

本記事では、PCをインターネットから直接接続できる状態にすることを標準の推奨構成にしません。

会社が管理する入口で接続者と接続先を絞り込めるかを先に検討してください。

これは特定の製品を導入すれば安全になるという意味ではなく、入口の更新・認証・許可範囲まで管理できることが前提です。

VPNとRD Gatewayの役割を整理する

3-1. VPNは接続経路と許可範囲を確認する

VPNを利用する構成では、まずVPNの入口へ接続し、その経路から接続先PCへ到達させます。

「VPNを使っている」という情報だけで、どの社内端末へ到達できるかまでは判断できません。

担当者は、対象ユーザーに必要な宛先だけを許可できるか、入口の認証方式は何か、運用中の機器が更新されているかを確認してください。

例えば経理PC一台だけを操作したい人に、他部署のPCへも広く到達できる設定が必要かを考えます。

許可範囲の変更は業務へ影響するため、管理者が現在の依存関係を確認してから行います。

VPNの方式自体を知りたい場合は、関連記事で基礎を確認し、この記事では遠隔接続先への許可範囲に注目してください。

3-2. RD Gatewayは接続者と接続先を制御する

RD Gatewayは、社外端末と社内リソースの間に置くRemote Desktop Servicesの入口です。

Microsoftの説明では、クライアントとGateway間の暗号化トンネル確立、利用者の認証、指定リソースとの通信中継を担います（参考2）。

本番ではクライアントが信頼できる認証局発行の証明書を用いることが案内されており、自己署名証明書の検証構成をそのまま本番の基準にしないことが大切です。

接続ポリシーRD CAPは誰がGatewayへ接続できるか、リソースポリシーRD RAPはどの接続先を利用できるかを定めます（参考3）。

例えば営業グループが入口を通過できても、経理PCを接続先として許可する必要はありません。

両方の許可を分けて確認すれば、「入口を通れる人は全PCを使える」という設計を避けやすくなります。

RD GatewayはWindows Serverの役割として管理する構成であり、WindowsのPC側設定をオンにするだけで設置される機能ではありません。

図2：RD CAPとRD RAPによる接続者・接続先の許可の区別（説明用の概念図）

NLA・MFA・接続権限を分けて対策する

4-1. NLAはセッション確立前の認証

NLA（Network Level Authentication）は、リモートセッションを確立する前に利用者を認証する仕組みです。

Microsoftは多くの環境でNLAを有効にすることを推奨しています（参考1）。

ただし、NLAが有効であることと、多要素認証が有効であることは別の確認事項です。

古いクライアントでつながらない場合も、原因を調べずにNLAを恒久的に無効化するのではなく、対応クライアントや管理方針を確認してください。

設定画面の表記はWindowsの版によって異なるため、見た目だけを頼りにせず、接続先側のNLA要求とクライアント側の対応をセットで確認します。

4-2. MFAは適用する入口と方式を確認する

MFA（多要素認証）は、パスワードだけに本人確認を頼らないための対策です。

確認すべきなのは「会社でMFAを使っているか」だけでなく、「今回のリモート接続が通る入口でMFAを要求するか」です。

参考3はRD GatewayとNPS拡張機能、Microsoft Entra多要素認証を組み合わせる特定の構成を説明しています。

この資料は、一般的なWindows PCのRDP接続に、MicrosoftアカウントのMFAが自動適用されることを示す資料ではありません。

また、同構成では使える認証方法に制約があり、普段のWebログインと同じ画面や入力方法になるとは限りません。

導入時は、登録済みの方式、利用者の操作、失敗時のログを管理者が確認し、認証できない利用者が出ても安易にMFAを外さない運用を準備します。

図のMFAは入口側の確認を表し、接続先Windowsの認証・権限確認を置き換えるものではありません。

NLAとMFAは同じ機能ではありません。

入口側と接続先側の両方を確認してください。

4-3. 接続を許可するアカウントを絞る

Windowsでは管理者グループのメンバーと、接続を許可した利用者がリモート接続できます（参考1）。

日常業務のために管理者へ追加するのではなく、必要な接続権限と業務上の権限を分けて検討してください。

共有アカウントを安易に使わず、誰が利用したか追える運用を目指します。

担当変更や退職があったときは、入口側の許可グループと接続先PC側の許可の両方を確認します。

強く固有のパスワードを用意することに加え、不要になった接続許可を残さないことが基本です。

ここまでを「入口で認証」「接続先を許可」「Windowsへ認証」という別々の確認として記録すると、設定漏れを探しやすくなります。

運用で続ける確認と困ったときの切り分け

5-1. 更新・棚卸し・ログを確認する

最初に安全な構成を作っても、使わないアカウントや古い機器が残れば管理は難しくなります。

接続先Windows、接続クライアント、VPN機器やGatewayの更新担当と確認頻度を決めておきましょう。

入口の接続記録と接続先のログを、利用者・時刻・接続先の観点で関連付けられるかも確認します。

参考3には、Gateway側でポリシーを満たして接続が許可された記録や、NPSの認証記録の確認例があります。

ただし、ログの有効化や保存場所・保持期間は環境によるため、すべてのPCに同じ記録が必ずあるとは考えないでください。

許可されない利用者の試行や、普段と違う時間帯の接続を見つけた場合の連絡先と確認手順も決めます。

不審な操作が進んでいるときは、社内のインシデント対応手順に従い、管理者へ連絡して記録を保全してください。

証拠を失う操作を急いで行ったり、根拠なく感染を断定したりしないことが大切です。

5-2. つながらないときは境界ごとに調べる

接続できないときは、ネットワーク到達、入口の認証、接続先の認証・権限を順に分けて調べます。

例えば「VPNには入れるが対象PCへ接続できない」なら、VPNの成功をPC側の許可の成功と読み替えないでください。

接続先の電源・ネットワーク接続・リモートデスクトップ有効化・許可ユーザー・ファイアウォールも確認対象です（参考1）。

エラーが出た画面、時刻、接続先名、入口を通過できたかを記録して管理者へ共有します。

パスワードや認証コード、秘密情報をスクリーンショットへ含めないようにしましょう。

表の順序は安全性確認用の整理であり、全環境でこの順にパケットが処理されることを保証するものではありません。

確認する場所	確認すること	記録する情報
経路	会社の入口を通るか	VPN・Gateway・接続先名
入口	本人確認と許可先	MFA方式・許可グループ
接続先	起動状態・NLA・利用者	PC名・権限・エラー時刻

よくある疑問と確認チェックリスト

6-1. リモートデスクトップのセキュリティに関するFAQ

Q1. 暗号化されていれば安全ですか？

暗号化だけでは、接続を試せる相手や許可された利用者の範囲までは決まりません。

経路・認証・権限を別々に確認してください。

Q2. NLAを有効にするとMFAになりますか？

なりません。

NLAはセッション確立前の認証であり、MFAの適用場所と方式は別途確認します。

Q3. Windows Homeを接続先にできますか？

Microsoftの案内ではWindows Homeはリモートデスクトップのホストになれません。

接続元のクライアントとして使うこととは区別してください（参考1）。

Q4. VPNがあればPC側の対策は不要ですか？

不要にはなりません。

接続先Windowsの更新、NLA、許可ユーザー、パスワード、ログなども確認します。

Q5. 一人で使うPCでも無効にしたほうがよいですか？

遠隔操作に使わないなら、リモートデスクトップは無効にしておきます。

業務で必要な場合は会社の管理方針に従い、接続する人と経路を限定します（参考1）。

6-2. 管理者へ渡せるチェックリスト

まずは下の表へ、現状と確認担当を書き込んでください。

空欄があっても、すぐ危険だと断定する必要はありません。

「誰に何を確認すればよいか」が見えることが、改善の出発点です。

最優先は、社外からの経路、入口の本人確認、接続先の許可を説明できることです。

そのうえで更新とログの運用を整え、不要になった接続を片付けましょう。

対策を検討するときは製品名から選ぶより、必要な利用者・接続先・運用担当を先に決めると、導入後の設定確認にも使えます。

項目	確認事項	現状・担当
外部経路	直接到達の有無と入口の管理担当	未記入
入口の認証	MFAの適用対象と失敗時の対応	未記入
接続先の権限	許可された人と利用できるPC	未記入
Windows	ホスト対応版・NLA・更新担当	未記入
運用	ログの保存先・保持期間・連絡先	未記入
終了時	不要な接続と利用者の削除手順	未記入