PowerShell リモート処理のセキュリティに関する考慮事項PowerShell Remoting Security Considerations

PowerShell リモート処理は、Windows システムの管理に推奨されている方法です。PowerShell Remoting is the recommended way to manage Windows systems. Windows Server 2012 R2 では、PowerShell リモート処理が既定で有効になっています。PowerShell Remoting is enabled by default in Windows Server 2012 R2. このドキュメントでは、PowerShell リモート処理を使用する場合のセキュリティ上の問題、推奨事項、およびベスト プラクティスを取り上げています。This document covers security concerns, recommendations, and best practices when using PowerShell Remoting.

PowerShell リモート処理とはWhat is PowerShell Remoting?

PowerShell リモート処理は、Windows リモート管理 (WinRM) を使用しています。これは、ユーザーがリモート コンピューター上で PowerShell コマンドを実行できるように、Microsoft によって Web Services for Management (WS-Management) プロトコルが実装されたものです。PowerShell Remoting uses Windows Remote Management (WinRM), which is the Microsoft implementation of the Web Services for Management (WS-Management) protocol, to allow users to run PowerShell commands on remote computers. PowerShell リモート処理の使用方法の詳細については、「リモート コマンドの実行」を参照してください。You can find more information about using PowerShell Remoting at Running Remote Commands.

PowerShell リモート処理は、コマンドレットの ComputerName パラメーターを使用してリモート コンピューターでコマンドを実行することとは異なります。この場合は、基盤となるプロトコルとしてリモート プロシージャ コール (RPC) が使用されています。PowerShell Remoting is not the same as using the ComputerName parameter of a cmdlet to run it on a remote computer, which uses Remote Procedure Call (RPC) as its underlying protocol.

PowerShell リモート処理の既定の設定PowerShell Remoting default settings

PowerShell リモート処理 (および WinRM) は、次のポートをリッスンします。PowerShell Remoting (and WinRM) listen on the following ports:

  • HTTP: 5985HTTP: 5985
  • HTTPS: 5986HTTPS: 5986

既定では、PowerShell リモート処理で許可されている接続は、Administrators グループのメンバーからのもののみです。By default, PowerShell Remoting only allows connections from members of the Administrators group. セッションはユーザーのコンテキストで開始されるため、PowerShell リモート処理を介して接続されている間は、個々のユーザーとグループに適用されているオペレーティング システムのアクセス制御がすべて、そのセッションに引き続き適用されます。Sessions are launched under the user's context, so all operating system access controls applied to individual users and groups continue to apply to them while connected over PowerShell Remoting.

プライベート ネットワークの場合、PowerShell リモート処理の既定の Windows ファイアウォール規則はすべての接続を受け入れます。On private networks, the default Windows Firewall rule for PowerShell Remoting accepts all connections. パブリック ネットワークの場合、既定の Windows ファイアウォール規則で許可されるのは、同じサブネット内からの PowerShell リモート処理接続のみです。On public networks, the default Windows Firewall rule allows PowerShell Remoting connections only from within the same subnet. パブリック ネットワーク上のすべての接続に対して PowerShell リモート処理を可能にするには、その規則を明示的に変更する必要があります。You have to explicitly change that rule to open PowerShell Remoting to all connections on a public network.

警告

パブリック ネットワークのファイアウォール規則は、悪意のある外部接続からコンピューターを保護することを目的としています。The firewall rule for public networks is meant to protect the computer from potentially malicious external connection attempts. この規則を削除する際は注意してください。Use caution when removing this rule.

プロセスの分離Process isolation

PowerShell リモート処理によって、コンピューター間の通信に WinRM が使用されます。PowerShell Remoting uses WinRM for communication between computers. WinRM は Network Service アカウントでサービスとして実行されており、ユーザー アカウントとして実行される分離プロセスを生成して、PowerShell インスタンスをホストします。WinRM runs as a service under the Network Service account, and spawns isolated processes running as user accounts to host PowerShell instances. 1 ユーザーとして実行されている PowerShell のインスタンスは、別のユーザーとして PowerShell のインスタンスを実行しているプロセスにアクセスすることはできません。An instance of PowerShell running as one user has no access to a process running an instance of PowerShell as another user.

PowerShell リモート処理によって生成されたイベント ログEvent logs generated by PowerShell Remoting

FireEye は、PowerShell リモート処理セッションによって生成されたイベント ログやその他のセキュリティ証拠をまとめたものを提供しています。これは、概要をまとめられています。これについては、「Investigating PowerShell Attacks」(PowerShell 攻撃の調査) を参照してください。FireEye has provided a good summary of the event logs and other security evidence generated by PowerShell Remoting sessions, available at Investigating PowerShell Attacks.

暗号化とトランスポート プロトコルEncryption and transport protocols

PowerShell リモート処理の接続のセキュリティについては、初期認証と進行中の通信という 2 つの観点から考慮することをお勧めします。It is helpful to consider the security of a PowerShell Remoting connection from two perspectives: initial authentication, and ongoing communication.

使用されているトランスポート プロトコル (HTTP または HTTPS) に関係なく、WinRM により、常にすべての PowerShell リモート処理の通信が、初期認証後に暗号化されます。Regardless of the transport protocol used (HTTP or HTTPS), WinRM always encrypts all PowerShell remoting communication after initial authentication.

初期認証Initial authentication

認証では、サーバーに対するクライアントの ID と、理想的にはクライアントに対するサーバーを確認します。Authentication confirms the identity of the client to the server - and ideally - the server to the client.

クライアントがコンピューター名を使用してドメイン サーバーに接続する場合、既定の認証プロトコルは Kerberos です。When a client connects to a domain server using its computer name, the default authentication protocol is Kerberos. Kerberos では、再利用可能な資格情報を送信しなくても、ユーザー ID とサーバー ID の両方が保証されます。Kerberos guarantees both the user identity and server identity without sending any sort of reusable credential.

クライアントが IP アドレスを使用してドメイン サーバーに接続する場合、またはワークグループ サーバーに接続する場合は、Kerberos 認証を使用できません。When a client connects to a domain server using its IP address, or connects to a workgroup server, Kerberos authentication is not possible. その場合は、PowerShell リモート処理は NTLM 認証プロトコルを利用します。In that case, PowerShell Remoting relies on the NTLM authentication protocol. NTLM 認証プロトコルでは、委任可能な資格情報を送信しなくてもユーザー ID が保証されます。The NTLM authentication protocol guarantees the user identity without sending any sort of delegable credential. NTLM プロトコルは、ユーザー ID を証明するために、クライアントとサーバーの両方でユーザーのパスワードからセッション キーを計算することを要求します。パスワード自体は交換しません。To prove user identity, the NTLM protocol requires that both the client and server compute a session key from the user's password without ever exchanging the password itself. サーバーは、通常ユーザーのパスワードを知らないため、ドメイン コントローラーと通信します。ドメイン コントローラーがユーザーのパスワードを知っていて、サーバー用にセッション キーを計算します。The server typically does not know the user's password, so it communicates with the domain controller, which does know the user's password and calculates the session key for the server.

一方、NTLM プロトコルでは、サーバー ID が保証されません。The NTLM protocol does not, however, guarantee server identity. ドメインに参加しているコンピューターのコンピューター アカウントにアクセスできる攻撃者は、認証に NTLM を使用するプロトコルと同様にドメイン コントローラーを呼び出して NTLM セッション キーを計算することで、サーバーになりすます場合があります。As with all protocols that use NTLM for authentication, an attacker with access to a domain-joined computer's machine account could invoke the domain controller to compute an NTLM session-key and thereby impersonate the server.

NTLM ベースの認証は既定では無効になっていますが、ターゲット サーバーで SSL を構成するか、クライアントで WinRM TrustedHosts 設定を構成することで許可できます。NTLM-based authentication is disabled by default, but may be permitted by either configuring SSL on the target server, or by configuring the WinRM TrustedHosts setting on the client.

NTLM ベースの接続時に SSL 証明書を使用してサーバー ID を検証するUsing SSL certificates to validate server identity during NTLM-based connections

NTLM 認証プロトコルではターゲット サーバーの ID を保証できないため (パスワードを認識しているだけのため)、PowerShell リモート処理に SSL を使用するようターゲット サーバーを構成できます。Since the NTLM authentication protocol cannot ensure the identity of the target server (only that it already knows your password), you can configure target servers to use SSL for PowerShell Remoting. SSL 証明書をターゲット サーバーに割り当てると (クライアントも信頼している証明機関によって発行されている場合)、ユーザー ID とサーバー ID の両方が保証される NTLM ベースの認証が可能になります。Assigning a SSL certificate to the target server (if issued by a Certificate Authority that the client also trusts) enables NTLM-based authentication that guarantees both the user identity and server identity.

NTLM ベースのサーバー ID を無視するIgnoring NTLM-based server identity errors

SSL 証明書を NTLM 接続用のサーバーに展開できない場合は、そのサーバーを WinRM の TrustedHosts 一覧に追加することで ID エラーの発生を抑制できます。If deploying a SSL certificate to a server for NTLM connections is infeasible, you may suppress the resulting identity errors by adding the server to the WinRM TrustedHosts list. サーバー名を TrustedHosts の一覧に追加することは、ホスト自体の信頼性を表明するいずれの形でもないことにご注意ください。NTLM 認証プロトコルでは、実際に接続先となるホストが、意図する接続先であるとは限らないからです。Please note that adding a server name to the TrustedHosts list should not be considered as any form of statement of the trustworthiness of the hosts themselves - as the NTLM authentication protocol cannot guarantee that you are in fact connecting to the host you are intending to connect to. 代わりに、TrustedHosts の設定を、サーバーの ID を確認できないことが原因で生成されたエラーを抑制するホストの一覧と考える必要があります。Instead, you should consider the TrustedHosts setting to be the list of hosts for which you wish to suppress the error generated by being unable to verify the server's identity.

進行中の通信Ongoing Communication

初期認証が完了すると、WinRM では、進行中の通信が暗号化されます。Once initial authentication is complete, the WinRM encrypts the ongoing communication. HTTPS 経由で接続する場合は、データの転送に使用される暗号化をネゴシエートするために TLS プロトコルが使用されます。When connecting over HTTPS, the TLS protocol is used to negotiate the encryption used to transport data. HTTP 経由で接続する場合、メッセージレベルの暗号化は、使用される初期認証プロトコルによって決定されます。When connecting over HTTP, message-level encryption is determined by initial authentication protocol used.

  • 基本認証では、暗号化は行われません。Basic authentication provide no encryption.
  • NTLM 認証では、128 ビット キーを使用して RC4 暗号が使用されます。NTLM authentication uses an RC4 cipher with a 128-bit key.
  • Kerberos 認証の暗号化は、TGS チケットの etype によって決定されます。Kerberos authentication encryption is determined by the etype in the TGS ticket. これは、最新のシステムでの AES-256 です。This is AES-256 on modern systems.
  • CredSSP 暗号化では、ハンドシェイクでネゴシエートされた TLS 暗号スイートが使用されます。CredSSP encryption is uses the TLS cipher suite that was negotiated in the handshake.

次ホップの実行Making the second hop

PowerShell リモート処理では、既定で、認証に Kerberos (使用可能な場合) または NTLM が使用されます。By default, PowerShell Remoting uses Kerberos (if available) or NTLM for authentication. このどちらのプロトコルも、資格情報を送信することなく、リモート コンピューターに対して認証を行います。Both of these protocols authenticate to the remote machine without sending credentials to it. これは認証方法としては最も安全ですが、リモート コンピューターにユーザーの資格情報がないため、このリモート コンピューターは、ユーザーに代わって他のコンピューターおよびサービスにアクセスすることはできません。This is the most secure way to authenticate, but because the remote machine does not have the user's credentials, it cannot access other computers and services on the user's behalf. これは "次ホップの問題" と呼ばれます。This is known as the "second hop problem".

この問題を回避する方法はいくつかあります。There are several ways to avoid this problem. これらの方法およびその長所と短所については、「PowerShell リモート処理での次ホップの実行」をご覧ください。For descriptions of these methods, and the pros and cons of each, see Making the second hop in PowerShell Remoting.

ReferencesReferences