Windows PowerShell でマルチホップ リモート処理を有効にする

  • 15 分

リモート処理のもう 1 つの課題は、複数のリモート接続間での資格情報の委任に関連しています。 既定では、資格情報を委任できる範囲は 1 つの接続または "ホップ" のみです。 この委任制限により、リモート コンピューターは資格情報をさらに委任できなくなります。これにより、追加のセキュリティ リスクが発生する可能性があるためです。

一般に、対処する必要があるシナリオは次のようなものです。

  1. ServerA にサインインしています。
  2. ServerA からリモート PowerShell セッションを開始して ServerB に接続します。
  3. PowerShell リモート処理セッションを介して ServerB で実行するコマンドは、ServerC 上のリソースにアクセスを試みます。
  4. PowerShell リモート処理セッションの作成に使った資格情報は ServerB から ServerC に渡されないため、ServerC 上のリソースへのアクセスが拒否されます。

運用環境では、複数ホップ (つまり "マルチホップ") の委任を実行することが必要になる可能性がしばしばあります。 たとえば、組織によっては、管理者がクライアント コンピューターからデータセンター内のサーバーに直接接続することが許可されていない場合があります。 代わりに、中間ゲートウェイまたはジャンプ サーバーに接続し、そこから管理しようとするサーバーに接続する必要があります。 既定の構成では、リモート処理でこの方法は許可されません。 リモート コンピューターに接続した後は、資格情報をリモート コンピューターより先に移動できません。 そのコンピューターに配置されていないリソースにアクセスしようとすると、通常、アクセスに資格情報が付属していないため、エラーが発生します。 解決策は、Credential Security Support Provider (CredSSP) を有効にすることです。

CredSSP を有効にする

CredSSP は、リモート サーバー (前の例では ServerB) に資格情報をキャッシュします。 このため、CredSSP を使用すると、潜在的な資格情報の盗難攻撃が発生する可能性があることに注意する必要があります。 リモート コンピューターが侵害されると、攻撃者はユーザーの資格情報にアクセスできます。 CredSSP は、既定では、クライアント コンピューターとサーバー コンピューターの両方で無効になっています。 CredSSP は、最も信頼性の高い環境でのみ有効にしてください。 たとえば、ドメイン コントローラーは信頼性が高いため、ドメイン コントローラーに接続しているドメイン管理者が CredSSP を有効にしている可能性があります。

CredSSP プロトコルは、"クライアント" と呼ばれる開始側コンピューターと、"サーバー" と呼ばれる受信側コンピューターの両方で有効にする必要があります。 これを行うと、受信側のコンピューターは資格情報に 1 つの追加ホップを委任できます。

クライアントを構成するには、"servername" を資格情報を再委任できるサーバーの名前に置き換えて、次のコマンドを実行します。

Enable-WsManCredSSP –Role Client –Delegate servername

サーバー名にはワイルドカード文字を含めることができます。 ただし、アスタリスク (*) ワイルドカードを単独で使用すると、許可されていないユーザーであっても、任意のコンピューターで資格情報の再委任を有効にできるため、制限が少なすぎます。 そうではなく、*.ADATUM.com などの限定的なワイルドカード パターンを検討してください。これにより、再委任がそのドメイン内のコンピューターに制限されます。

サーバーを構成するには、Enable-WsManCredSSP –Role Server を実行します。 サーバーに、委任されたコンピューターの一覧は必要ありません。 グループ ポリシー経由でもこれらの設定を構成できます。これにより、企業全体でより一元的で一貫性のある構成がもたらされます。

注意

CredSSP の使用中の多数のセキュリティ違反が文書化されているため、これは推奨される選択肢ではなくなりました。 代わりに、制約付き委任を使用する必要があります。

リソースに基づく Kerberos の制約付き委任

Windows Server 2012 以降では、CredSSP を使用せず、代わりに制約付き委任を使用できます。 "制約付き委任" では、サーバー名の許可リストではなく、セキュリティ記述子を使用してサービス チケットの委任を実装します。 これにより、リソースは、別のユーザーに代わってチケットを要求できるセキュリティ プリンシパルを判定できます。 リソースベースの制約付き委任は、ドメインの機能レベルに関係なく、正しく機能します。

制約付き委任は、次を必要とします。

  • Windows PowerShell リモート処理コマンドの実行元のホスト コンピューターと同じドメイン内のドメイン コントローラーへのアクセス。
  • 中間リモート サーバーからアクセスしようとしているリモート サーバーをホストしているドメイン内のドメイン コントローラーへのアクセス。

アクセス許可を設定するコードには、Active Directory PowerShell リモート サーバー管理ツール (RSAT) を使用して Windows Server を実行しているコンピューターが必要です。 次の 2 つのコマンドを実行することで、RSAT を Windows 機能として追加できます。

Add-WindowsFeature RSAT-AD-PowerShell
Import-Module ActiveDirectory

LON-SVR1 から LON-SVR2 経由で LON-SVR3 までのリソース ベースの Kerberos 制約付き委任を許可するには、次のコマンドを実行します。

Set-ADComputer -Identity LON-SVR2 -PrincipalsAllowedToDelegateToAccount LON-SVR3

このコマンドが失敗する可能性がある問題が 1 つあります。 キー配布センター (KDC) には、15 分間の SPN ネガティブ キャッシュがあります。 LON-SVR2 が LON-SVR3 と既に通信しようとしていた場合は、ネガティブ キャッシュ エントリがあります。 次のいずれかの手法を使用して、LON-SVR2 のキャッシュをクリアする必要があります。

  • コマンド klist purge -li 0x3e7 を実行します。 これは、推奨される最速の方法です。
  • キャッシュが自動的にクリアされるまで 15 分間待ちます。
  • LON-SVR2 を再起動します。

制約付き委任をテストするには、次のコード例を実行します。

$cred = Get-Credential Adatum\TestUser                
Invoke-Command -ComputerName LON-SVR1.Name -Credential $cred -ScriptBlock {Test-Path \\$($using:ServerC.Name)\C$            `
Get-Process lsass -ComputerName $($using:LON-SVR2.Name)
Get-EventLog -LogName System -Newest 3 -ComputerName $using:LON-SVR3.Name            
}

Just Enough Administration

"Just Enough Administration (JEA)" は、PowerShell で管理されるものすべてに対して委任された管理を有効にするセキュリティ テクノロジです。 JEA を使用すると、以下のことを実行できます。

  • 通常のユーザーに代わって仮想アカウントまたはグループ管理サービス アカウントを使用して、特権の必要な操作を実行することで、ご使用のコンピューター上の管理者の数を減らします。
  • ユーザーが実行できる操作を制限します。ここでは、ユーザーが実行できるコマンドレット、関数、および外部コマンドを指定できます。
  • ユーザーがセッション中に実行したコマンドを正確に示すトランスクリプトとログを確認することで、ユーザーの操作を正確に把握します。

サーバーの管理に使用される高い特権を持つアカウントには、深刻なセキュリティ リスクがあります。 そのようなアカウントが攻撃者に狙われた場合、組織全体に横展開の攻撃が始まります。 侵害された各アカウントにより、攻撃者はさらに多くのアカウントやリソースにアクセスできるようになり、会社の機密情報の盗難に一歩近づいて、サービス拒否 (DoS) 攻撃などを開始します。

しかしながら、管理者特権を削除することは簡単なことではありません。 DNS ロールが Active Directory ドメイン コントローラーと同じコンピューターにインストールされるという一般的なシナリオを想定してみましょう。 DNS 管理者には、DNS サーバーでの問題を解決するためにローカル管理者特権が必要です。 しかしそのためには、これらを高い特権を持つ Administrators セキュリティ グループのメンバーにする必要があります。 この方法は、ドメイン全体への制御を取得する機能や、そのマシン上のすべてのリソースへのアクセス権を DNS 管理者に効果的に提供します。

JEA では、最小限の特権の原則を通じて、この問題に対処しています。 JEA を利用すると、DNS 管理者に管理エンドポイントを構成して、これらの管理者が作業を行うのに必要な PowerShell コマンドだけにアクセスできるようにすることができます。 つまり、DNS 管理者に Active Directory への権限を付与しなくても、侵害された DNS キャッシュを修復したり、DNS サーバーを再起動したり、またはファイル システムを参照したり、潜在的に危険性なスクリプトを実行したりできる適切なアクセスを提供できます。 さらに、JEA セッションが一時的な特権仮想アカウントを使用するように構成されているときは、DNS 管理者が管理者以外の資格情報を使用してサーバーに接続でき、それでも一般的には管理者特権を必要とするコマンドを実行できます。 JEA により、幅広い特権が与えられたローカルまたはドメインの管理者ロールからユーザーを削除し、各マシンでユーザーが実行できる操作を慎重に制御できます。

JEA は、PowerShell 5.0 以降に含まれる機能です。 すべての機能のためには、システムで使用できる最新バージョンの PowerShell をインストールする必要があります。 PowerShell リモート処理は、JEA 構築の基盤を提供します。 JEA を使用する前に、PowerShell リモート処理を有効にし、適切にセキュリティで保護されていることを確実にする必要があります。

JEA エンドポイントを作成するときに、JEA セッションでユーザーに許可する操作を説明するロール機能を 1 つ以上定義する必要があります。 "ロール機能" は、拡張子が .psrc の PowerShell データ ファイルであり、接続ユーザーが利用できるすべてのコマンドレット、関数、プロバイダー、外部プログラムがリストされています。

New-PSRoleCapabilityFile コマンドレットで新しい PowerShell ロール機能ファイルを作成できます。 次に、作成したロール機能ファイルを編集して、ロールに必要なコマンドを許可する必要があります。 PowerShell ヘルプ ドキュメントには、ファイルの構成例が含まれています。