JEA のセキュリティに関する考慮事項

JEA は、コンピューター上の永続的な管理者の数を減らすことで、セキュリティ体制の向上に役立ちます。 JEA は、PowerShell セッション構成を使用して、ユーザーがシステムを管理するための新しいエントリ ポイントを作成します。 管理タスクを実行するためにマシンへの昇格されたアクセスを必要とするが無制限ではないユーザーには、JEA エンドポイントへのアクセス権を付与できます。 JEA を使用すると、これらのユーザーは完全な管理者アクセス権を持たずに管理コマンドを実行できるため、高い特権を持つセキュリティ グループからそれらのユーザーを削除できます。

Run-As アカウント

各 JEA エンドポイントには、接続しているユーザーのアクションを実行するために指定された 実行用 アカウントがあります。 このアカウントは セッション構成ファイルで構成でき、選択したアカウントはエンドポイントのセキュリティに大きな影響を与えています。

仮想アカウントは、実行アカウントを構成するための推奨される方法です。 仮想アカウントは、JEA セッションの期間中に接続ユーザーが使用するために作成される、1 回限りの一時的なローカル アカウントです。 セッションが終了するとすぐに、仮想アカウントは破棄され、使用できなくなります。 接続しているユーザーは、仮想アカウントの資格情報を知りません。 仮想アカウントを使用して、リモート デスクトップや制約のない PowerShell エンドポイントなどの他の方法でシステムにアクセスすることはできません。

既定では、仮想アカウントはマシン上のローカル Administrators グループのメンバーです。 このメンバーシップは、システム上の何かを管理するための完全な権限を付与しますが、ネットワーク上のリソースを管理する権限はありません。 ユーザーが JEA セッションから他のマシンに接続すると、ユーザー コンテキストは仮想アカウントではなくローカル コンピューター アカウントのコンテキストになります。

ドメイン コントローラーは、ローカル の Administrators グループがないため、特殊なケースです。 代わりに、仮想アカウントは Domain Admins に属し、ドメイン コントローラー上のディレクトリ サービスを管理できます。 ドメイン ID は、JEA セッションがインスタンス化されたドメイン コントローラーでの使用が引き続き制限されます。 ネットワーク アクセスは、代わりにドメイン コントローラー コンピューター オブジェクトから取得されているようです。

どちらの場合も、仮想アカウントを特定のセキュリティ グループに割り当てることができます。特に、ローカルまたはドメイン管理者特権なしでタスクを実行できる場合です。 管理者用に定義されたセキュリティ グループが既にある場合は、そのグループに仮想アカウントメンバーシップを付与します。 仮想アカウントのグループ メンバーシップは、ワークステーションおよびメンバー サーバー上のローカル セキュリティ グループに制限されます。 ドメイン コントローラーでは、仮想アカウントはドメイン セキュリティ グループのメンバーである必要があります。 仮想アカウントが 1 つ以上のセキュリティ グループに追加されると、既定のグループ (ローカルまたはドメイン管理者) に属しなくなります。

次の表は、仮想アカウントに対して可能な構成オプションと結果のアクセス許可をまとめたものです。

セキュリティ監査とアプリケーション イベント ログを見ると、各 JEA ユーザー セッションに一意の仮想アカウントがあることがわかります。 この一意のアカウントは、コマンドを実行した元のユーザーに戻って JEA エンドポイントのユーザー アクションを追跡するのに役立ちます。 仮想アカウント名はWinRM Virtual Users\WinRM_VA_<ACCOUNTNUMBER>_<DOMAIN>_<sAMAccountName>形式に従います。たとえば、Contoso ドメインのユーザー Alice が JEA エンドポイントでサービスを再起動すると、サービス コントロール マネージャーイベントに関連付けられているユーザー名がWinRM Virtual Users\WinRM_VA_1_contoso_aliceされます。

グループ管理サービス アカウント (gMSA) は、メンバー サーバーが JEA セッションのネットワーク リソースにアクセスする必要がある場合に便利です。 たとえば、JEA エンドポイントを使用して、別のコンピューターでホストされている REST API サービスへのアクセスを制御する場合などです。 REST API を呼び出す関数は簡単に記述できますが、API で認証するにはネットワーク ID が必要です。 グループ管理サービス アカウントを使用すると、アカウントを使用できるコンピューターを制御しながら、2 番目のホップが可能になります。 gMSA のセキュリティ グループ (ローカルまたはドメイン) メンバーシップは、gMSA アカウントの有効なアクセス許可を定義しました。

JEA エンドポイントが gMSA を使用するように構成されている場合、すべての JEA ユーザーのアクションは同じ gMSA から取得されているように見えます。 特定のユーザーにアクションをトレースし直す唯一の方法は、PowerShell セッション トランスクリプトで実行されるコマンドのセットを識別することです。

パススルー資格情報は、実行するアカウントを指定しない場合に使用されます。 PowerShell では、接続しているユーザーの資格情報を使用して、リモート サーバーでコマンドを実行します。 パススルー資格情報を使用するには、接続しているユーザーに特権管理グループへの直接アクセスを許可する必要があります。 この構成は JEA には推奨 されません 。 接続しているユーザーが既に管理者特権を持っている場合は、JEA をバイパスし、他のアクセス方法を使用してシステムを管理できます。

標準の実行アカウント を使用すると、PowerShell セッション全体を実行する任意のユーザー アカウントを指定できます。 固定 実行 アカウント ( -RunAsCredential パラメーターを使用) を使用するセッション構成は、JEA に対応していません。 ロール定義が期待どおりに機能しなくなりました。 エンドポイントにアクセスする権限を持つすべてのユーザーには、同じロールが割り当てられます。

JEA エンドポイントで RunAsCredential を使用しないでください。これは、アクションを特定のユーザーにトレースし直すのが難しく、ユーザーをロールにマッピングするためのサポートがないためです。

WinRM エンドポイント ACL

通常の PowerShell リモート処理エンドポイントと同様に、各 JEA エンドポイントには、JEA エンドポイントで認証できるユーザーを制御する個別のアクセス制御リスト (ACL) があります。 正しく構成されていない場合、信頼されたユーザーが JEA エンドポイントにアクセスできず、信頼されていないユーザーがアクセスできる可能性があります。 WinRM ACL は、JEA ロールへのユーザーのマッピングには影響しません。 マッピングは、エンドポイントの登録に使用されるセッション構成ファイルの RoleDefinitions フィールドによって制御されます。

既定では、JEA エンドポイントに複数のロール機能がある場合、マップされたすべてのユーザーへのアクセスを許可するように WinRM ACL が構成されます。 たとえば、次のコマンドを使用して構成された JEA セッションは、 CONTOSO\JEA_Lev1 と CONTOSO\JEA_Lev2へのフル アクセスを許可します。

$roles = @{ 'CONTOSO\JEA_Lev1' = 'Lev1Role'; 'CONTOSO\JEA_Lev2' = 'Lev2Role' }
New-PSSessionConfigurationFile -Path '.\jea.pssc' -SessionType RestrictedRemoteServer -RoleDefinitions $roles -RunAsVirtualAccount
Register-PSSessionConfiguration -Path '.\jea.pssc' -Name 'MyJEAEndpoint'

Get-PSSessionConfiguration コマンドレットを使用して、ユーザーのアクセス許可を監査できます。

Get-PSSessionConfiguration -Name 'MyJEAEndpoint' | Select-Object Permission

Permission
----------
CONTOSO\JEA_Lev1 AccessAllowed
CONTOSO\JEA_Lev2 AccessAllowed

アクセス権を持つユーザーを変更するには、対話型プロンプトの Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -ShowSecurityDescriptorUI を実行するか、 Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -SecurityDescriptorSddl <SDDL string> を実行してアクセス許可を更新します。 ユーザーは、JEA エンドポイントにアクセスするために、少なくとも Invoke 権限が必要です。

定義されたロールをアクセス権を持つすべてのユーザーにマップしない JEA エンドポイントを作成できます。 これらのユーザーは JEA セッションを開始できますが、既定のコマンドレットにのみアクセスできます。 Get-PSSessionCapabilityを実行することで、JEA エンドポイントのユーザーアクセス許可を監査できます。 詳細については、 JEA の監査とレポートを参照してください。

最小特権の役割

JEA ロールを設計するときは、バックグラウンドで実行されている仮想サービス アカウントとグループ管理サービス アカウントがローカル コンピューターに無制限にアクセスできることに注意することが重要です。 JEA ロール機能は、その特権コンテキストで実行できるコマンドとアプリケーションを制限するのに役立ちます。 ロールが不適切に設計されている場合、ユーザーが JEA の境界から抜け出したり、機密情報へのアクセスを取得したりできる危険なコマンドが許可される可能性があります。

たとえば、次のロール機能エントリを考えてみましょう。

@{
    VisibleCmdlets = 'Microsoft.PowerShell.Management\*-Process'
}

このロール機能を使用すると、ユーザーは Microsoft.PowerShell.Management モジュールの名詞プロセスを使用して任意の PowerShell コマンドレットを実行できます。 ユーザーは、 Get-Process などのコマンドレットにアクセスして、システムで実行されているアプリケーションを確認し、応答していないアプリケーションを強制終了するために Stop-Process する必要がある場合があります。 ただし、このエントリでは、完全な管理者権限で任意のプログラムを起動するために使用できる Start-Processも許可されます。 プログラムをシステムにローカルにインストールする必要はありません。 接続されたユーザーは、ユーザーにローカル管理者特権を付与したり、マルウェアを実行したりするファイル共有からプログラムを開始できます。

この同じロール機能のより安全なバージョンは、次のようになります。

@{
    VisibleCmdlets = 'Microsoft.PowerShell.Management\Get-Process',
                     'Microsoft.PowerShell.Management\Stop-Process'
}

ロール機能ではワイルドカードを使用しないでください。 有効なユーザーのアクセス許可を定期的に監査して、ユーザーがアクセスできるコマンドを確認してください。 詳細については、JEA に関する監査とレポートに関する記事の有効な権限の確認に関するセクションを参照してください。

ベスト プラクティスの推奨事項

JEA エンドポイントのセキュリティを確保するためのベスト プラクティスの推奨事項を次に示します。

PowerShell プロバイダーの使用と機能を制限する

許可されたプロバイダーを使用して、構成されたセッションに脆弱性が作成されないようにする方法を確認します。

新しい実行空間を作成できるコマンドは許可しないでください。

Trace-Command コマンドレットは許可しないでください。

制限されたコマンドに対して独自のプロキシ実装を作成しないでください。

PowerShell には、制限されたコマンド シナリオ用の一連のプロキシ コマンドがあります。 これらのプロキシ コマンドにより、入力パラメーターによってセッションのセキュリティが損なわれることはありません。 次のコマンドでは、プロキシが制限されています。

• Exit-PSSession
• Get-Command
• Get-FormatData
• Get-Help
• Measure-Object
• Out-Default
• Select-Object

これらのコマンドの独自の実装を作成すると、JEA プロキシ コマンドで禁止されているコードの実行がユーザーに誤って許可される可能性があります。

JEA は管理者から保護しない

JEA の主要な原則の 1 つは、管理者以外のユーザーが管理タスクを実行できることです。 JEA は、既に管理者特権を持っているユーザーから保護しません。 ドメイン管理者、ローカル管理者、またはその他の高い特権を持つグループに属しているユーザーは、他の方法で JEA の保護を回避できます。 たとえば、RDP でサインインしたり、リモート MMC コンソールを使用したり、制約のない PowerShell エンドポイントに接続したりできます。 また、システムのローカル管理者は、JEA 構成を変更してユーザーを追加したり、ロール機能を変更して、ユーザーが JEA セッションで実行できる操作の範囲を拡張したりできます。 JEA ユーザーの拡張アクセス許可を評価して、システムへの特権アクセスを取得する他の方法があるかどうかを確認することが重要です。

JEA を使用して日常的なメンテナンスを行うだけでなく、Just-In-Time 特権アクセス管理システムを使用するのが一般的です。 これらのシステムを使用すると、指定されたユーザーは、それらのアクセス許可の使用を文書化するワークフローが完了した後にのみ、一時的にローカル管理者になります。