RDP ポート ガイド: ポート 3389 の Windows リモート デスクトップ

RDP を使用すると、ユーザーはネットワーク経由でリモート Windows デスクトップと対話できます。クライアントは RDP サービスに接続し、セキュリティ設定をネゴシエートし、ユーザーを認証した後、ポリシーに応じてキーボード、マウス、ディスプレイ、クリップボード、オーディオ、およびデバイス リダイレクト データを交換します。

最新の RDP では、ネットワーク レベル認証、TLS、ゲートウェイ、およびエンタープライズ ID 制御を使用できますが、ポート自体は依然としてトランスポート エントリ ポイントにすぎません。 3389 ポートが到達可能だからといって、展開が安全であるとは限りません。これは、リモート クライアントが RDP セッションの開始を試行できることのみを意味します。

管理者、サポート チーム、または制御されたリモート ワーカーが Windows システムに対話的にアクセスする必要がある場合にのみ、RDP を開きます。その場合でも、インターネットに直接さらされるのは最後の手段としてください。リモート デスクトップ ゲートウェイ、VPN、ゼロトラスト アクセス、要塞ホスト、またはプライベート ネットワーク接続を優先します。

クラウド VM が時折緊急アクセスを必要とする場合は、3389 を 24 時間開いたままにするのではなく、ジャストインタイム ファイアウォール ルール、一時的なソース IP 許可リスト、またはプロバイダーのシリアル コンソール機能を検討してください。

TCP 3389 はプライマリ RDP パスであり、ほとんどの接続チェックで検証される最初のポートです。 TCP 3389 がブロックされている場合、通常は直接リモート デスクトップ セッションを開始できません。したがって、TCP ポート チェッカーは、RDP サービスへの基本パスを確認するのに役立ちます。

最新の RDP クライアントは UDP 3389 を使用して、セッション確立後の応答性、グラフィックス、オーディオ、および損失の多いネットワークの動作を改善できます。 UDP をブロックしてもすべての RDP ログインが防止されるわけではありませんが、セッションが遅くなったり、安定性が低下したりする可能性があります。ゲートウェイとエンタープライズ ポリシーではこれが異なる方法で処理される場合があるため、実際のクライアント パスをテストしてください。

ポート 3389 を開く前に、リモート デスクトップを意図的に有効にし、ネットワーク レベルの認証を要求し、サインインを許可されているユーザーを確認し、クリップボード、ドライブ、プリンター、およびデバイスのリダイレクトを許可するかどうかを決定します。これらのポリシーの選択は、ファイアウォール ルールと同じくらい重要です。

ポート チェッカーは、インターネットから TCP 3389 に到達できるかどうかを表示できますが、RDP ログイン フロー、ゲートウェイ ポリシー、ユーザー権利、MFA、またはセッション制限が正しく構成されていることを確認することはできません。ネットワークの到達可能性と実際のリモート デスクトップの動作の両方をテストします。

Windows Server または Windows Pro では、リモート デスクトップを有効にし、ネットワーク レベルの認証を要求し、Windows Defender ファイアウォールで受信 TCP 3389 を許可します。ユーザーが許可されたリモート デスクトップ グループに属していること、およびローカル セキュリティ ポリシーがリモート サインインをブロックしていないことを確認します。

クラウド サーバーの場合は、クラウド セキュリティ グループまたはファイアウォール ポリシーの信頼できるソース IP 範囲に対してのみ 3389 を開きます。可能であれば、VPN、プライベート サブネット、要塞、またはリモート デスクトップ ゲートウェイを使用して、VM 自体がパブリック インターネットから直接アクセスできないようにします。

RDP は主に Windows プロトコルですが、ゲートウェイを介して macOS、Linux、iOS、Android、およびブラウザー用のクライアントが存在します。サーバー側の公開とセキュリティ モデルは、引き続き Windows ホストまたはゲートウェイで制御する必要があります。

パブリック ホスト名または IP アドレスとポート 3389 に対する外部ポート チェックから開始します。ポートが開いている場合は、RDP サービスへの TCP パスに到達できます。次に、Microsoft リモート デスクトップ、mstsc.exe、またはゲートウェイ クライアントを使用してテストし、ログイン ポリシーとセッション ポリシーを確認します。

Windows ホストで、リモート デスクトップ サービスが実行されていること、および Windows Defender ファイアウォールに予期される受信ルールがあることを確認します。クラウド環境では、ホスト ファイアウォールとクラウド セキュリティ グループを比較してください。どちらでもアクセスがブロックされる可能性があるためです。

ポート 3389 が閉じられている場合は、リモート デスクトップが無効になっているか、サービスが停止しているか、ポートが変更されているか、Windows ファイアウォールが受信接続をブロックしている可能性があります。チェックがタイムアウトした場合、クラウド ファイアウォール ルール、ルーター NAT、VPN ポリシー、ISP フィルタリング、または送信元 IP 許可リストによってパケットがドロップされている可能性があります。

ポートは開いているがサインインに失敗する場合は、ユーザー権限、NLA 要件、期限切れのパスワード、アカウントのロックアウト、ドメイン接続、MFA ポリシー、ゲートウェイ ルール、およびイベント ログを検査します。動作中のポートは、ユーザーがセッションを作成する権限を持っていることを保証するものではありません。

RDP をインターネットに直接公開することは避けてください。リモート デスクトップ ゲートウェイ、VPN、プライベート ネットワーク、要塞ホスト、またはゼロトラスト アクセスを使用します。可能な限り MFA を要求し、アカウントのロックアウトを強制し、未使用のアカウントを無効にし、失敗したサインインと異常なソースの場所を監視します。

Windows に定期的にパッチを適用し、ローカル管理者のメンバーシップを制限し、不要なリダイレクト機能を無効にし、アイドル セッション タイムアウトを設定し、セキュリティ イベント ログを収集します。高リスクのシステムの場合は、個人デバイスからの直接 RDP ではなく、特権アクセス ワークステーションまたは管理された管理パスを優先します。