JEA セキュリティの考慮事項
JEA はコンピューターの常駐管理者の数を減らし、セキュリティに対する姿勢を改善します。 JEA では、ユーザーがシステムを管理するための新しいエントリ ポイントを作成するために、PowerShell のセッション構成が使用されます。 管理タスクを実行するために、マシンに対して管理者特権の無制限ではないアクセスを必要とするユーザーには、JEA エンドポイントへのアクセスを許可することができます。 JEA を使用すると、このようなユーザーが完全な管理者アクセス権を持たずに管理者コマンドを実行できるので、このようなユーザーを高い特権のセキュリティ グループから削除することができます。
実行アカウント
各 JEA エンドポイントには、指定された 実行 アカウントがあります。 これは、接続ユーザーのアクションの実行に使用されるアカウントです。 このアカウントはセッション構成ファイルで構成できます。選択したアカウントは、エンドポイントのセキュリティに大きく関係します。
仮想アカウント は、実行 アカウントを構成するときに推奨される方法です。 仮想アカウントは 1 回限りの一時的なローカル アカウントです。JEA セッションの間、接続ユーザーが使用するために作成されます。 セッションが終了すると同時に仮想アカウントは破棄され、その後は使用できません。 接続ユーザーは、仮想アカウントの資格情報を知りません。 リモート デスクトップや制約のない PowerShell エンドポイントなど、他の手段から仮想アカウントを使用してシステムにアクセスすることはできません。
既定では、仮想アカウントは、コンピューターのローカル 管理者 グループに属します。 それにより、システム上のあらゆるものを管理する完全な権限が与えられますが、ネットワーク上のリソースを管理する権限は与えられません。 他のコンピューターで認証を行うと、ユーザー コンテキストは、仮想アカウントではなく、ローカル コンピューター アカウントになります。
ローカルの 管理者 グループはないため、ドメイン コントローラーは特殊なケースです。 代わりに、仮想アカウントは Domain Admins に属しており、ドメイン コントローラー上のディレクトリ サービスを管理できます。 JEA セッションがインスタンス化されたドメイン コントローラー上では、ドメイン ID はまだ使用に制限があります。 ネットワーク アクセスは、代わりにドメイン コントローラー コンピューター オブジェクトから行われているように見えます。
いずれの場合も、仮想アカウントがどのセキュリティ グループに属するかを明示的に定義できます。 ローカルまたはドメインの管理者特権なしでタスクを実行できる場合は、この方法をお勧めします。 管理者用にセキュリティ グループが既に定義されている場合は、そのグループに仮想アカウントのメンバーシップを付与します。 仮想アカウント グループのメンバーシップは、ワークステーションおよびメンバー サーバー上のローカル セキュリティ グループに制限されています。 ドメイン コントローラー上では、仮想アカウントはドメイン セキュリティ グループのメンバーである必要があります。 仮想アカウントは、1 つ以上のセキュリティ グループに追加されると、既定のグループ (ローカルまたはドメイン管理者) には属さなくなります。
次の表は、仮想アカウントに対して構成できるオプションとその結果として与えられるアクセス許可をまとめたものです。
| コンピューターの種類 | 仮想アカウント グループ構成 | ローカル ユーザー コンテキスト | ネットワーク ユーザー コンテキスト |
|---|---|---|---|
| ドメイン コントローラー | Default | ドメイン ユーザー、'DOMAIN\Domain Admins' のメンバー | コンピューター アカウント |
| ドメイン コントローラー | ドメイン グループ A と B | ドメイン ユーザー、'DOMAIN\A'、'DOMAIN\B' のメンバー | コンピューター アカウント |
| メンバー サーバーまたはワークステーション | Default | ローカル ユーザー、'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 を回避し、制約のない他の手法でシステムを管理できます。 詳細については、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 の中心的原則の 1 つは、管理者以外のユーザーに一部の管理者タスクの実行を許可するというものです。 JEA には、管理者特権が既に与えられているユーザーに対する防御がありません。 Domain Admins、ローカルの Administrators、またはその他の特権の高いグループに属するユーザーは、別の方法で JEA の防御を回避することができます。 たとえば、RDP でサインインし、リモート MMC コンソールを利用したり、制約のない PowerShell エンドポイントに接続したりする可能性があります。 また、システムのローカル管理者は JEA 構成を変更し、追加ユーザーを許可したり、ロール機能を変更し、JEA セッションでユーザーに許可する範囲を拡大することを許可したりできます。 JEA ユーザーのアクセス権の拡大状況を見て、システムの特権アクセスを得る他の手法がないか調べることが重要です。
一般的な慣行としては、日常的な保守管理に JEA を利用し、just-in-time (必要なときに必要な許可だけを与える) の特権アクセス管理ソリューションを用意して緊急の場合にのみ一時的にローカル管理者になることをユーザーに許可します。 ユーザーはシステムの常駐管理者ではなくなるが、必要なときにのみ、管理者特権が与えられます。ワークフローを完了すると、アクセス許可の使用が記録されます。
フィードバック
フィードバックの送信と表示