Windows PowerShell のリモート処理のセキュリティ機能を確認する

完了

既定では、Windows PowerShell で作成されるエンドポイントでは、特定のグループのメンバーによる接続のみが許可されます。 Windows Server 2016 および Windows 10 以降、これらのグループには、emote Management Users グループとローカルの Administrators グループが含まれます。 Active Directory Domain Services (AD DS) ドメインでは、後者には Domain Admins ドメイン グローバル グループのメンバーも含まれます。そのグループは、ドメインに参加しているすべてのコンピューターのローカル Administrators グループのメンバーであるためです。 Windows Server 2016 および Windows 10 より前の既定では、ローカルの Administrators グループのメンバーのみに PowerShell リモート処理が許可されていました。 ただし、既定値は変更できます。 各エンドポイントにはシステム アクセス制御リスト (SACL) があり、それを変更することで、接続できるユーザーを正確に制御できます。

PowerShell リモート処理と WinRM では、次のポートをリッスンします。

• HTTP: 5985
• HTTPS: 5986

リモート処理の既定の動作では、サインイン資格情報がリモート コンピューターに委任されますが、接続時に代替の資格情報を指定することもできます。 接続先のリモート コンピューターで、それらの資格情報を使用して偽装が行われ、指定したタスクがそれらの資格情報を使用して実行されます。 監査を有効にした場合、ユーザーが実行するタスクに加えて、PowerShell リモート処理でユーザーに代わって実行されるタスクも監査されます。 実際には、リモート処理はセキュリティ透過的であり、環境の既存セキュリティは変更されません。 リモート処理を使用すると、物理的にローカル コンピューターの前にいるときに実行するのと同じタスクをすべて実行できます。

注意

プライベート ネットワークの場合、PowerShell リモート処理の既定の Windows ファイアウォール規則は、すべての接続を受け入れるようになっています。 パブリック ネットワークの場合、既定の Windows ファイアウォール規則で許可されるのは、同じサブネット内からの PowerShell リモート処理接続のみです。 パブリック ネットワーク上のすべての接続に対して PowerShell リモート処理を可能にするには、その規則を明示的に変更する必要があります。

セキュリティ リスクと相互認証

資格情報をリモート コンピューターに委任することには、セキュリティ上のリスクが伴います。 たとえば、攻撃者が既知のリモート コンピューターを偽装することに成功した場合、その攻撃者に高い特権を持つ資格情報が送信され、悪意のある目的に使われる可能性があります。 このリスクがあるため、リモート処理には既定で "相互認証" が必要です。つまり、リモート コンピューターに対して自分自身を認証する必要があり、リモート コンピューターからもそれ自体の認証が行われる必要があります。 この相互認証により、確実に意図したコンピューターのみに接続できます。

相互認証は、Active Directory Kerberos 認証プロトコルのネイティブ機能です。 信頼されたドメイン コンピューター間で接続すると、相互認証が自動的に行われます。 ドメインに参加していないコンピューターに接続する場合は、事前に設定する必要がある SSL 証明書と HTTPS プロトコルの形式で、別の形式の相互認証を指定する必要があります。 もう 1 つのオプションは、リモート コンピューターをローカルの TrustedHosts リストに追加して、相互認証の要件をオフにすることです。 ただし、TrustedHosts では Windows NT LAN Manager (NTLM) 認証が使用されるため、サーバー ID は保証されません。 認証に NTLM を使用する任意のプロトコルと同様に、ドメインに参加しているコンピューターの信頼されたアカウントにアクセスできる攻撃者は、ドメイン コントローラーに NTLM セッション キーを作成させ、サーバーを偽装できる可能性があります。

注意

NTLM 認証プロトコルでターゲット サーバーの ID は保証できません。パスワードが既に認識されていることを確認することしかできません。 そのため、PowerShell リモート処理に SSL を使用するようにターゲット サーバーを構成する必要があります。 クライアントが信頼している、信頼された証明機関が発行した SSL 証明書を取得し、それをターゲット サーバーに割り当てると、NTLM ベースの認証のセキュリティが強化され、ユーザー ID とサーバー ID の両方を検証できます。

コンピューター名に関する考慮事項

AD DS ベースの認証を機能させるには、PowerShell リモート処理で Active Directory Domain Services (AD DS) コンピューター オブジェクトを検索して取得できる必要があります。 つまり、完全修飾ドメイン名 (FQDN) を使用してターゲット コンピューターを参照する必要があります。 たとえば、IP アドレスまたはドメイン ネーム システム (DNS) エイリアスは、リモート処理に必要な相互認証を提供しないため、機能しません。 IP アドレスまたは DNS エイリアスによってコンピューターを参照する必要がある場合は、HTTPS を使用して接続する必要があります。つまり、そのプロトコルを受け入れるようにリモート コンピューターを構成する必要があります。 または、ローカルの TrustedHosts リストに IP アドレスまたは DNS エイリアスを追加する必要があります。

注意

コンピューター名 localhost は特別な例外として扱われます。これを使用すると、他の構成を変更せずにローカル コンピューターに接続できます。 クライアントベースのオペレーティング システムを使用しているローカル コンピューターの場合は、WinRM を構成する必要があります。

TrustedHosts リスト

"TrustedHosts リスト" はローカルに構成される設定であり、グループ ポリシー オブジェクト (GPO) を使用して構成することもできます。 TrustedHosts リストは、相互認証が不可能なコンピューターを列挙したものです。 コンピューターは、実際のコンピューター名、DNS エイリアス、IP アドレスのいずれであっても、接続に使用するのと同じ名前でリストされている必要があります。 ワイルドカードを使用して SRV* を指定できます。これにより、名前または DNS エイリアスが SRV で始まるすべてのコンピューターが接続できるようになります。 ただし、このリストは注意して使用してください。 TrustedHosts リストを使用すると、HTTPS を設定しなくても非ドメイン コンピューターに簡単に接続できるようになりますが、重要なセキュリティ対策がバイパスされます。 これにより、そのコンピューターが実際に意図した接続先のコンピューターであるかどうかを判断することなく、リモート コンピューターに資格情報を送信することが可能になります。 TrustedHosts リストは、セキュリティで保護されたデータセンターに格納されているサーバーなど、侵害されていないことがわかっているコンピューターを指定する場合にのみ使用する必要があります。 また、TrustedHosts を使用して、プロビジョニング プロセスが行われる新しいコンピューターなど、制御されているネットワーク サブネット上の非ドメイン コンピューターへの接続を一時的に有効にすることもできます。

注意

ベスト プラクティスとして、絶対に必要な場合を除き、TrustedHosts リストの使用は避ける必要があります。 HTTPS を使用するように非ドメイン コンピューターを構成することは、より安全な長期的なソリューションです。

プライバシー

既定では、リモート処理には HTTP が使用され、通信の内容のプライバシーや暗号化は提供されません。 ただし、Windows PowerShell は既定でアプリケーションレベルの暗号化を適用可能であり、また、実際に適用します。 これは、ある程度のプライバシーと保護が通信に提供されることを意味します。 内部ネットワークの場合、組織のセキュリティ要件を満たすためには、通常はこのアプリケーションレベルの暗号化で十分です。

既定の Kerberos 認証プロトコルを使用するドメイン環境では、資格情報は、パスワードを含まない暗号化された Kerberos チケットの形式で送信されます。

HTTPS を使用して接続すると、リモート コンピューターの SSL 証明書の暗号化キーを使用してチャネル全体が暗号化されます。 そのため、基本認証を使用しても、パスワードはクリア テキストで送信されません。 ただし、HTTPS 用に構成されていないコンピューターに HTTP 認証と基本認証を使用して接続すると、資格情報 (パスワードを含む) がクリア テキストで送信されます。 これは、たとえば、ローカルの TrustedHosts リストに追加した非ドメイン コンピューターに接続するときに発生する可能性があります。 さらに、ホスト名ではなく IP アドレスを指定して、ドメインに参加しているコンピューターを使用する場合にも発生する可能性があります。

そのシナリオでは資格情報がクリア テキストで送信されるため、新しいコンピューターのプロビジョニング用に特別に指定されたものなど、制御されている保護されたネットワーク サブネット上の非ドメイン コンピューターにのみ接続する必要があります。 非ドメイン コンピューターに日常的に接続する必要がある場合は、HTTPS をサポートするように構成する必要があります。