次の方法で共有

WinRM を使用した PowerShell リモート処理のセキュリティに関する考慮事項

  • [アーティクル]

PowerShell リモート処理は、Windows システムを管理するための推奨される方法です。 PowerShell リモート処理は、Windows Server 2012 R2 以降では既定で有効になっています。 このドキュメントでは、PowerShell リモート処理を使用するときのセキュリティ上の懸念事項、推奨事項、ベスト プラクティスについて説明します。

PowerShell リモーティングとは

PowerShell リモート処理では、Windows リモート管理 (WinRM) を使用して、ユーザーがリモート コンピューターで PowerShell コマンドを実行できるようにします。 WinRM は、Web Services for Management (WS-Management) プロトコルの Microsoft 実装です。 PowerShell リモート処理の使用の詳細については、リモート コマンドの実行に関するページを参照してください。

PowerShell リモート処理は、コマンドレットの ComputerName パラメーターを使用してリモート コンピューターで実行するのと同じではなく、リモート プロシージャ コール (RPC) を基になるプロトコルとして使用します。

PowerShell リモート処理の既定の設定

PowerShell リモート処理 (および WinRM) は、次のポートをリッスンします。

  • HTTP: 5985
  • HTTPS: 5986

既定では、PowerShell リモート処理では Administrators グループのメンバーからの接続のみが許可されます。 セッションはユーザーのコンテキストで起動されるため、個々のユーザーとグループに適用されるすべてのオペレーティング システム アクセス制御は、PowerShell リモート処理経由で接続されている間も引き続き適用されます。

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

警告

パブリック ネットワークのファイアウォール規則は、悪意のある外部接続の試行からコンピューターを保護するためのものです。 この規則を削除する場合は注意が必要です。

プロセスの分離

PowerShell リモート処理では、コンピューター間の通信に WinRM が使用されます。 WinRM はネットワーク サービス アカウントでサービスとして実行され、ユーザー アカウントとして実行されている分離されたプロセスを生成して、PowerShell インスタンスをホストします。 あるユーザーとして実行されている PowerShell のインスタンスは、別のユーザーとして PowerShell のインスタンスを実行しているプロセスにアクセスできなくなります。

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

FireEye は、PowerShell リモート処理セッションによって生成されたイベント ログとその他のセキュリティ証拠の概要を提供しています。これは、PowerShell 攻撃の調査で入手できます。

暗号化とトランスポート プロトコル

PowerShell リモート処理接続のセキュリティは、初期認証と継続的な通信の 2 つの観点から検討すると便利です。

使用されるトランスポート プロトコル (HTTP または HTTPS) に関係なく、WinRM では、初回認証後にすべての PowerShell リモート処理通信が常に暗号化されます。

初期認証

認証は、クライアントからサーバーへのクライアントの ID を確認します。理想的には、サーバーからクライアントへの ID を確認します。

クライアントがコンピューター名を使用してドメイン サーバーに接続すると、既定の認証プロトコルは Kerberosされます。 Kerberos は、再利用可能な資格情報を送信することなく、ユーザー ID とサーバー ID の両方を保証します。

クライアントが IP アドレスを使用してドメイン サーバーに接続したり、ワークグループ サーバーに接続したりすると、Kerberos 認証は実行できません。 その場合、PowerShell リモート処理は、NTLM 認証プロトコルに依存します。 NTLM 認証プロトコルは、委任可能な資格情報を送信することなく、ユーザー ID を保証します。 ユーザー ID を証明するために、NTLM プロトコルでは、クライアントとサーバーの両方が、パスワード自体を交換することなく、ユーザーのパスワードからセッション キーを計算する必要があります。 通常、サーバーはユーザーのパスワードを認識しないため、ユーザーのパスワードを認識し、サーバーのセッション キーを計算するドメイン コントローラーと通信します。

ただし、NTLM プロトコルでは、サーバー ID は保証されません。 認証に NTLM を使用するすべてのプロトコルと同様に、ドメインに参加しているコンピューターのコンピューター アカウントにアクセスできる攻撃者は、ドメイン コントローラーを呼び出して NTLM セッション キーを計算し、サーバーを偽装する可能性があります。

NTLM ベースの認証は既定では無効になっていますが、ターゲット サーバーで SSL を構成するか、クライアントで WinRM TrustedHosts 設定を構成することで許可される場合があります。

NTLM ベースの接続中に SSL 証明書を使用してサーバー ID を検証する

NTLM 認証プロトコルではターゲット サーバーの ID を確保できないため (パスワードが既に認識されている場合のみ)、PowerShell リモート処理に SSL を使用するようにターゲット サーバーを構成できます。 ターゲット サーバーに SSL 証明書を割り当てる (クライアントも信頼する証明機関によって発行された場合) は、ユーザー ID とサーバー ID の両方を保証する NTLM ベースの認証を有効にします。

NTLM ベースのサーバー ID エラーの無視

NTLM 接続用のサーバーに SSL 証明書を展開できない場合は、サーバーを WinRM TrustedHosts リストに追加することで、結果の ID エラーを抑制できます。 NTLM 認証プロトコルでは実際に接続先のホストに接続していることを保証できないため、サーバー名を TrustedHosts リストに追加することは、ホスト自体の信頼性に関する記述としては考慮しないでください。 代わりに、TrustedHosts 設定を、サーバーの ID を確認できないことによって生成されるエラーを抑制するホストの一覧と見なす必要があります。

継続的なコミュニケーション

初期認証が完了すると、WinRM は進行中の通信を暗号化します。 HTTPS 経由で接続する場合、TLS プロトコルを使用して、データの転送に使用される暗号化をネゴシエートします。 HTTP 経由で接続する場合、メッセージ レベルの暗号化は、使用される初期認証プロトコルによって決まります。

  • 基本認証では、暗号化は提供されません。
  • NTLM 認証では、128 ビット キーを持つ RC4 暗号が使用されます。
  • Kerberos 認証の暗号化は、TGS チケット内の etype によって決定されます。 これは、最新のシステムの AES-256 です。
  • CredSSP 暗号化では、ハンドシェイクでネゴシエートされた TLS 暗号スイートが使用されます。

2 番目のホップの作成

既定では、PowerShell リモート処理では認証に Kerberos (使用可能な場合) または NTLM が使用されます。 どちらのプロトコルも、資格情報を送信せずにリモート コンピューターに対して認証を行います。 これは最も安全な認証方法ですが、リモート コンピューターにはユーザーの資格情報がないため、ユーザーの代わりに他のコンピューターやサービスにアクセスすることはできません。 これは"第 2 ホップの問題" と呼ばれます。

この問題を回避するには、いくつかの方法があります。 これらの方法の説明と、それぞれの長所と短所については、「PowerShell リモート処理での第 2 ホップの作成 」を参照してください。

参照