次の方法で共有

JEA セキュリティの考慮事項

  • [アーティクル]

JEA はコンピューターの常駐管理者の数を減らし、セキュリティに対する姿勢を改善します。 JEA では、ユーザーがシステムを管理するための新しいエントリ ポイントを作成するために、PowerShell のセッション構成が使用されます。 管理タスクを実行するために、マシンに対して管理者特権の無制限ではないアクセスを必要とするユーザーには、JEA エンドポイントへのアクセスを許可することができます。 JEA を使用すると、このようなユーザーが完全な管理者アクセス権を持たずに管理者コマンドを実行できるので、このようなユーザーを高い特権のセキュリティ グループから削除することができます。

実行アカウント

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

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

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

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

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

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

コンピューターの種類 仮想アカウント グループ構成 ローカル ユーザー コンテキスト ネットワーク ユーザー コンテキスト
ドメイン コントローラー 既定値 ドメイン ユーザー、<DOMAIN>\Domain Admins のメンバー コンピューター アカウント
ドメイン コントローラー ドメイン グループ A と B ドメイン ユーザー、<DOMAIN>\A、<DOMAIN>\B のメンバー コンピューター アカウント
メンバー サーバーまたはワークステーション 既定値 ローカル ユーザー、BUILTIN\Administrators のメンバー コンピューター アカウント
メンバー サーバーまたはワークステーション ローカル グループ C と D ローカル ユーザー、<COMPUTER>\C および <COMPUTER>\D のメンバー コンピューター アカウント

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

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

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

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

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

JEA エンドポイント上では RunAsCredential を使用するべきではありません。アクションを特定のユーザーまでさかのぼって追跡することが困難であり、ユーザーをロールにマップするためのサポートが欠けているためです。

WinRM エンドポイント ACL

通常の PowerShell リモート処理エンドポイントと同様に、各 JEA エンドポイントに個別のアクセス制御リスト (ACL) が与えられます。そのリストにより、JEA エンドポイントで認証できるユーザーを制御します。 構成が不適切な場合、信頼されているユーザーが 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 エンドポイントにアクセスするには、少なくとも呼び出し権限が必要になります。

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

最小特権ロール

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

たとえば、次のロール機能エントリを考慮してください。

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

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

次は、同じロール機能をより安全にしたものです。

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

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

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

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

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

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

警告

FileSystem プロバイダーを許可しないでください。 ユーザーがファイル システムの任意の場所に書き込むことができる場合、セキュリティを完全にバイパスすることが可能です。

Certificate プロバイダーを許可しないでください。 このプロバイダーを有効にすると、ユーザーは保存されている秘密キーにアクセスできます。

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

警告

*-Job コマンドレットは、制限なしで新しい実行空間を作成できます。

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

警告

Trace-Command を使用すると、トレースされたすべてのコマンドがセッションに取り込まれます。

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

PowerShell には、コマンドが制限されたシナリオ用のプロキシ コマンドのセットがあります。 これらのプロキシ コマンドは、入力パラメーターがセッションのセキュリティを侵害することがないことを保証します。 以下のコマンドでは、プロキシが制限されています。

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

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

JEA には管理者に対する防御がない

JEA の主要な原則の 1 つは、管理者以外のユーザーが管理タスクを実行できることです。 JEA には、管理者特権が既に与えられているユーザーに対する防御がありません。 Domain Admins、ローカルの Administrators、またはその他の特権の高いグループに属するユーザーは、別の方法で JEA の防御を回避することができます。 たとえば、RDP でサインインし、リモート MMC コンソールを利用したり、制約のない PowerShell エンドポイントに接続したりする可能性があります。 また、システムのローカル管理者は JEA 構成を変更し、さらに追加ユーザーを許可したり、ロール機能を変更し、JEA セッションでユーザーに許可する範囲を拡大することを許可したりできます。 JEA ユーザーのアクセス権の拡大状況を見て、システムの特権アクセスを得る他の手法がないか調べることが重要です。

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