Table of contents

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

Ryan Puffer|最終更新日: 2017/01/11
|
1 投稿者

適用先: Windows PowerShell 5.0

JEA はコンピューターの常駐管理者の数を減らし、セキュリティに対する姿勢を改善します。 ユーザーがシステムを管理するための新しい入口を作成し (PowerShell セッション構成)、それを既定で厳しく施錠し、誤用を防止します。 管理タスクを実行するために、無制限ではない、一部のアクセス許可を必要とするユーザーに JEA エンドポイントのアクセス許可を与えることができます。 JEA では管理アクセス許可を直接持たなくても管理コマンドを実行できるため、高い特権を与えるセキュリティ グループからユーザーを削除できます (標準ユーザーにします)。

このトピックでは、JEA セキュリティ モデルとベスト プラクティスについて詳しく説明します。

実行アカウント

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

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

既定では、仮想アカウントは、コンピューターのローカル管理者グループに属します。 それにより、システム上のあらゆるものを管理する完全な権限が与えられますが、ネットワーク上のリソースを管理する権限は与えられません。 他のコンピューターで認証を行うと、ユーザー コンテキストは、仮想アカウントではなく、ローカル コンピューター アカウントになります。

Active Directory ドメイン コントローラーでは、仮想アカウントに既定でドメイン管理者権限が与えられます。 これは、ドメイン コントローラーにはローカル管理者のグループがないという事実に起因します。 そのため、ドメイン コントローラーの仮想アカウントはドメイン アカウントであり、他のコンピューターで利用できます。 ドメイン コントローラーで JEA セッションを構成するとき、コマンドを公開しないように注意する必要があります。ネットワークの他のコンピューターの操作に利用される可能性があります。

いずれの場合でも、仮想アカウントが属するセキュリティ グループを明示的に定義できます。 ローカル/ドメイン管理者特権なしでタスクを実行できるとき、明示的に定義することをお勧めします。 管理者にセキュリティ グループを既に定義している場合、そのグループに仮想アカウントのメンバーシップを与えることで必要なアクセス許可を与えることができます。 仮想アカウント グループ メンバーシップはワークステーションとメンバー サーバーのローカル セキュリティ グループに限定されますが、ドメイン コントローラーでは、ドメイン セキュリティ グループのメンバーだけになることができます。 仮想アカウントにそれが属する 1 つ以上のセキュリティ グループを指定すると、既定のグループ (ローカル管理またはドメイン管理) から削除されます。

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

コンピューターの種類仮想アカウント グループ構成ローカル ユーザー コンテキストネットワーク ユーザー コンテキスト
ドメイン コントローラー既定ドメイン ユーザー、'DOMAIN\Domain Admins' のメンバードメイン ユーザー、'DOMAIN\Domain Admins' のメンバー
ドメイン コントローラードメイン グループ A と Bドメイン ユーザー、'DOMAIN\A'、'DOMAIN\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 アカウントが属するセキュリティ グループ (ローカルまたはドメイン) により定義されます。

gMSA アカウントを使用するように JEA エンドポイントを構成すると、あらゆる JEA ユーザーのアクションが同じグループの管理されたサービス アカウントから行われたように表示されます。 アクションを特定のユーザーまでさかのぼって追跡する唯一の方法は、PowerShell セッション トランスクリプトで実行されたコマンド セットを特定することです。

パススルー資格情報 実行アカウントを指定しない場合、PowerShell は接続ユーザーの資格情報を利用してリモート サーバーでコマンドを実行します。 この構成は JEA には推奨されません。特権のある管理グループの直接アクセス許可を接続ユーザーに与える必要があるためです。 接続ユーザーに管理者特権が既に与えられている場合、JEA を完全に回避し、制約のない他の手法でシステムを管理できます。 詳細については、JEA で管理者に対する防御がないことに関する下のセクションをご覧ください。

標準の実行アカウントでは、PowerShell セッション全体を実行するユーザー アカウントを指定できます。 これは重要な特徴です。(-RunAsCredential パラメーターで) 固定の実行アカウントを使用するように設定されているセッション構成は JEA に対応していないためです。 つまり、ロールの定義が予想どおり機能することがなくなり、エンドポイントにアクセスする許可が与えられているすべてのユーザーに同じロールが割り当てられます。

JEA エンドポイントでは RunAsCredential を使用しないでください。特定のユーザーまでさかのぼって追跡することが難しく、ユーザーをロールにマッピングできないためです。

WinRM エンドポイント ACL

通常の PowerShell リモート処理エンドポイントと同様に、各 JEA エンドポイントに個別のアクセス制御リスト (ACL) が与えられ、WinRM 構成に設定されます。そのリストにより、JEA エンドポイントで認証できるユーザーを制御します。 構成が不適切な場合、信頼されているユーザーが JEA エンドポイントにアクセスできなかったり、信頼されていないユーザーがアクセスできたりすることがあります。 ただし、WinRM ACL は JEA ロールへのユーザーのマッピングに影響を与えません。 それは、システムに登録されたセッション構成ファイルの RoleDefinitions フィールドで制御されます。

既定では、セッション構成ファイルと 1 つ以上のロール機能を利用して JEA エンドポイントを登録するとき、WinRM ACL は、1 つ以上のロールにマッピングするすべてのユーザーにエンドポイントのアクセスを許可するように構成されます。 たとえば、次のコマンドで構成された JEA セッションには CONTOSO\JEA_Lev1CONTOSO\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 コマンドレットでユーザー アクセス許可を監査できます。

PS C:\> 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 ロール機能を利用すれば、特権コンテキストを利用して実行できるコマンドとアプリケーションを制限することで、アカウントの用途を制限できます。 ロールが不適切に設計されると、危険なコマンドの実行が許可され、ユーザーが 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 には、管理者特権が既に与えられているユーザーに対する防御がありません。 環境で "ドメイン管理者"、"ローカル管理者"、その他の高い特権を持つグループに属するユーザーは、別の手段でコンピューターにサインインし、JEA の防御を避けることができます。 たとえば、RDP でサインインし、リモート MMC コンソールを利用するか、制約のない PowerShell エンドポイントに接続できます。 また、システムのローカル管理者は JEA 構成を変更し、追加ユーザーにシステムの管理を許可したり、ロール機能を変更し、JEA セッションでユーザーに許可する範囲を拡大することを許可したりできます。 そのため、JEA ユーザーのアクセス権の拡大状況を見て、システムの特権アクセスを得る他の手法がないか調べることが重要です。

一般的な慣行としては、日常的な保守管理に JEA を利用し、"just in time " (必要なときに必要な許可だけを与える) の特権アクセス管理ソリューションを用意して緊急の場合にのみ一時的にローカル管理者になることをユーザーに許可します。 ユーザーはシステムの常駐管理者ではなくなるが、必要なときにのみ、管理者特権が与えられます。ワークフローを完了すると、アクセス許可の使用が記録されます。

© 2017 Microsoft