RDPに到達できる人を制限し、サポートされる場合はネットワークレベル認証を有効にし、個人用の強力な資格情報を使い、管理権限を最小化します。現在の接続を閉じる前に、2つ目のセッションと復旧アクセスをテストします。
デスクトップを管理境界として扱う
RDPセッションはリモートシステムへの対話型アクセスを提供するため、それに使うアカウントは価値ある標的になり得ます。まず、誰がアクセスを必要とし、どの作業を行う必要があるかを決めます。共有管理者ログインは、1人のアクセスを削除したり設定変更を理解したりする必要が生じるまでは便利です。個人アカウントはこれらの運用タスクを明確にします。
ソフトウェアが許す場合は、日常業務と特権変更を分離します。業務アプリケーションを必要とするユーザーが、無制限のシステム管理を必要とするとは限りません。管理者のエンドポイントも維持します。リモートマシンを保護しても、感染した、または共有されたローカルデバイスから入力された資格情報は保護されません。アクセス設計ではセッションの両端を考慮します。
ログイン保護に頼る前に到達可能性を制限する
どのネットワークまたは承認されたデバイスがセッションホストに到達できるべきかを決めます。アーキテクチャがサポートする場合は、管理を広く露出させるのではなく、制御されたVPNまたはリモートデスクトップゲートウェイを使います。MicrosoftはRD Gatewayを、接続とリソース承認ポリシーを備えた内部リソースへの経路として文書化しています。その適合性は環境によります。プランがRDPをサポートするからといって含まれる機能ではありません。
ファイアウォールルールを意図した経路に制限し、動的クライアントアドレスをどう扱うかを確認します。復旧オプションなしで唯一の管理者を即座に切断する制限ルールを作らないでください。既存のセッションを開いたまま、別のセッションから新しい経路をテストし、古いアクセス経路を削除する前に承認された復旧メカニズムを文書化します。
認証と信頼を明示的に保つ
Microsoftは、サポートされるほとんどの環境でネットワークレベル認証を推奨しています。NLAは完全なリモートセッションを確立する前に認証を要求し、その段階で保護を追加します。ファイアウォール、アカウントポリシー、システム更新を置き換えるものではありません。クライアント互換性を確認し、最初の対応として設定を恒久的に弱めるのではなく、認証問題をトラブルシューティングします。
可能な場合は、サポートされるアクセスアーキテクチャを通して一意の資格情報と第二要素を使います。特に再構築やホスト名変更後に、期待されるリモートIDと証明書の挙動を検証します。証明書警告は調査に値します。予期しないIDを繰り返し受け入れると、有用な信頼チェックが無視されるダイアログになります。復旧資格情報は承認された非公開ストアに保管します。
| 層 | 判断 | 検証 |
|---|---|---|
| ネットワーク | どのクライアントがホストに到達できるか？ | 予期しないソースは接続できない |
| 認証 | どのアカウントと要素が必要か？ | 許可された2つ目のセッションが成功する |
| 特権 | どのタスクに管理が必要か？ | 通常ユーザーはシステム設定を変更できない |
| 復旧 | 誤りの後でアクセスはどう復旧されるか？ | 文書化された復旧経路が利用可能 |
セッションが運べるものを減らす
実際のワークフローに対して、クリップボード、ドライブ、プリンターなどのリダイレクト機能を見直してください。管理者がすべてのローカルリソースをリモートホストに公開する必要があるとは限りません。逆に、代替手段なしに必要な転送経路を無効にすると、安全でない回避策を促す可能性があります。ファイル移動の許可された方法を文書化し、機密情報を通常のデスクトップメモや共有ダウンロードディレクトリに置かないようにしてください。
適切なドメインベース環境では、MicrosoftはRDP接続中の資格情報露出を減らすためにRemote Credential Guardを提供しています。互換性のあるクライアントとKerberos認証が必要で、ターゲットマシンへの直接接続をサポートします。Remote Desktop GatewayやConnection Brokerを経由した接続はサポートされません。スタンドアロンのホスト型Windowsマシンに対する万能な保護として扱うのではなく、実際のアクセス経路の要件を確認してください。
マシンと必要な証拠を維持する
意図的な再起動プロセスを含め、オペレーティングシステムとアプリケーションの更新をスケジュールしてください。更新に再起動が必要かどうかを確認し、その後サービスを検証します。無人または切断された作業のための適切なセッションポリシーを設定しますが、実行し続ける必要があるアプリケーションも考慮してください。タイムアウトポリシーは、別の環境から任意の数値を単にコピーするのではなく、セキュリティまたは運用上のニーズに応えるものであるべきです。
文書化されたポリシーの下で、有用なアクセスおよびインシデント情報を保持してください。不必要なコンテンツを収集することなく、繰り返される認証失敗や予期しない管理アクティビティを監視します。診断記録を読める人を制限し、それらがどれだけの期間必要かを決定します。正確なログポリシーは、すべてを無期限に保持するか、運用記録が存在し得ないと約束するよりも有意義です。
安全な初回セッションの手順
納品時に、期待されるシステムを確認し、承認されたプロセスを通じて一時的な資格情報を変更し、個別のアクセスを確立してください。ファイアウォールとリカバリ経路を確認し、2つ目の接続をテストします。更新を適用し、リダイレクトを見直し、必要なアプリケーションをインストールします。バックアップを作成し、デスクトップを日常業務に依存する前に、重要な設定の復元を練習してください。
DeskLink RDPおよび選択された専用構成では、SwissOctetカタログでWindows関連の選択肢が提供されています。注文のオペレーティングシステム、ライセンス、アカウント権限、管理責任を確認してください。サポートされたデスクトップ接続は管理計画の始まりにすぎません。設定および検証する制御が、そのアクセスがどのように使用されるかを決定します。
実践チェックリスト。
- 個別のアカウントと適切な権限を使用してください。
- 意図されたRDPアクセス経路を制限してください。
- 互換性のあるシステムではNLAを有効にしてください。
- 現在のアクセスを閉じる前に2つ目のセッションをテストしてください。
- リダイレクト、更新、セッションポリシーを見直してください。
- ライセンスとリカバリ手順を確認してください。
重要な詳細。
NLAは公開されたRDPホストを完全に安全にしますか？+
いいえ。NLAは1つの認証制御です。到達可能性、資格情報、更新、権限には依然として注意が必要です。
すべてのWindowsサーバーでRemote Credential Guardを使用できますか？+
いいえ。クライアント、ホスト、認証環境が、該当するKerberosの取り決めを含め、Microsoftの要件を満たす必要があります。
ファイアウォールを厳格化する前に何をすべきですか？+
リカバリ経路を確認し、動作中のセッションを保持し、2つ目の接続を通じて新しい許可経路をテストしてください。
出典へ。
これらの参考文献は、このガイドの技術的概念をサポートしています。本番システムを変更する前に最新のドキュメントを確認してください。
- Microsoft：リモートデスクトップとネットワークレベル認証を有効にする learn.microsoft.com
- Microsoft：リモートデスクトップゲートウェイアクセス learn.microsoft.com
- Microsoft：Remote Credential Guard learn.microsoft.com
SwissOctetによる編集ガイダンス。例は例示目的です。サービス仕様、利用可能なオプション、契約条件は別途確認する必要があります。