【Powershell】Just Enough Administration（JEA）の仕組み・概念・構成要素を解説＜理論編＞

PowerShell
2025.12.07

今回はWindows Powershellに関する記事です。
掲題にあるJust Enough Administration（JEA）について
どういうものなのかを解説していきます。

本記事は以下JEAの動作検証記事に対する、補足解説的な位置づけの記事です。
＜理論編＞として深堀りしていますので、
実践手順だけ見たい方は以下の＜入門編＞をどうぞ！

➡【Powershell】Just Enough Administration（JEA）をマイPC1台で動作検証してみた＜入門編＞

主に以下を説明する記事を書いていきます。

  • JEA とは
  • PowerShell JEA
  • JEA 仕組み
  • Just Enough Administration
  • 権限委譲 PowerShell

【Powershell】Just Enough Administration（JEA）の仕組み・概念・構成要素を解説＜理論編＞

JEAとは何か

まず何の略称なのかを説明します。
Just Enough Administration 略してJEA 、直訳すると「十分な管理」です。

似たような用語でJust In Time 「ちょうど今、まさにその時に」というものがあり
前職自動車業界出身の筆者はこちらに近いのかな？とイメージしていました。

違いは、Just In Time が時間軸視点の考え方であることに対して、
JEA は「最小限の管理権限だけ与える仕組み」 であり、
管理制御視点の考え方である、ということです。

ものすごくざっくりいうと
sudo / least privilege の Windows 版 とお考え下さい。

なぜ JEA が必要なのか？

Windows OSのCMDやPSなどコマンドラインツールは非常に強力なツールとなっていますが、
操作に「管理者権限」を要求されるものが多く、十分な操作を行うために
原則「管理者としてログインする」ことが求められがちです。

オペレータへの「権限渡しすぎ問題」へダイレクトにつながってしまい、
誤操作や横展開の事故へ直結してきます。

このリスクをコントロールしつつ、コマンドラインツールもしっかり利用した運用を行いたい、
そういうときにこのJEA の仕組みが役に立ちます。

モジュールをユーザが構築する必要があり、導入難易度は高いのですが
代わりにカスタマイズの融通も利くようになっており、
操作の監査ログを取得するように構成することも可能です。

操作権限に対する制約は、大規模な企業システムなどでは検討必須の要素となっていることが多く
JEAを理解しておくと、日常運用に対する「安全なコマンドライン」なる選択肢が増えます。

JEA の構成要素

モジュールを構成する、というと難しく聞こえるかもしれませんが、
ひとつのロール（役割）に対して構成要素は3つしかありません。
これらを構成することで、JEAエンドポイント として指定できるようになります。

【1】Role Capability（.psrc）— 何を許可するか
【2】Session Configuration（.pssc）— 誰に割り当てるか
【3】モジュール（.psd1）— ロールを入れる箱

構成要素の図解

フォルダ構成のサンプル

C:\Program Files\WindowsPowerShell\Modules\
 └─MyJEA\
 　　└─MyJEA.psd1
 　　└─ RoleCapabilities\
 　　　　└─ BasicAdmin.psrc 
C:\ProgramData\JEA_Demo.pssc

フォルダ構成には最適な配置場所があります。
これはPowershellのデフォルト動作ともつながりがあります。

.psrc最初からPATHが通っている場所にフォルダを作成＆格納
C:\Program Files\WindowsPowerShell\Modules\
.psscC:\ProgramData\ 配下が安定
.psd1 (モジュールマニフェスト).psrcファイル配置フォルダと同階層に置く
■どこに置けば PowerShell が自動認識するか（PSModulePath）

Powershell巧者の方は以下のような選択肢を想定されると思います。

  • C:\Program Files\WindowsPowerShell\Modules\（システム全体）
  • C:\Users\<USER>\Documents\WindowsPowerShell\Modules\（ユーザー環境）

ただし、JEA は “システム全体” に置くのが原則です。
理由としては、RunAsVirtualAccount がユーザー環境パスを参照しないため。

JEA が 「モジュール」 を前提にしている理由

箇条書きしますので、順序に沿ってご一読くださいませ。

  • RoleCapability（.psrc）は単体では使えない
  • PowerShell は RoleCapabilities を “モジュールの一部” としてしか認識しない
  • だから .psd1（モジュールマニフェスト） が必要
  • モジュール名／フォルダ名と RoleCapabilities のパスが規約になっている
  • まとめると　モジュール + .psd1 が必要

JEA がどう動くか

PSを介したJEAの使い方、使用感はこんな感じになります。

①ユーザは一般権限のままPSを起動します。

②Enter-PSSession コマンドでJEAエンドポイントを指定します。

③指定されたJEAエンドポイントがセッションを作成します。

④セッション内では VirtualAccount（または指定ユーザ）で昇格します。
　ただし、使用できるコマンドは.psrc内へ定義したコマンドだけです。

⑤パスの通っていないコマンド、特に外部exeなどは許可しない限り弾かれます。
　外部exeはCMDで打鍵するnetshやhostnameなどのことです。
　管理者権限不要そうなもの　もすべて許可設定が必要。

⑥ログはPowerShell トランスクリプトとして自動的に取得できます。
　※.psscへの設定必要

■実行ポリシーは原則 RemoteSigned 以上が必要です

かなり重要なポイントですので、最初にこれを実行するようにしてください。
これをしないとほぼ動きません。

Set-ExecutionPolicy RemoteSigned

JEA自体は署名不要ですが、環境によっては Module 読み込みが制限されるためです。

VirtualAccount の概要

VirtualAccountには以下の特徴があります。

  • ローカル管理者権限相当
  • 一時的な仮想アカウント
  • 権限昇格はするが、許可された操作しかできない

RoleCapability(.psrc) の書き方

コマンドの許可設定をする際は、RoleCapability(.psrc)　に対して以下のように記述します。
　※説明用の部分記述です。
　　これだけだと記述不足で動作しないため、このまま使わないようにしてください

青文字はPowershellコマンドレットの記述となっており、
赤文字はCMD(コマンドライン)の記述となっています。
このように、CMD(コマンドライン) はフルパスを記述する必要があることに注意が必要です。

@{
    VisibleCmdlets = @(
        'Get-Service',
        @{ Name = 'Restart-Service'; Parameters = @{ Name='Name'; ValidateSet='Spooler' } }
    )

    VisibleExternalCommands = @(
        'C:\Windows\System32\netsh.exe'
    )

    VisibleProviders = @('FileSystem','Registry')
}
■利用可能コマンドは 許可モデル（ホワイトリスト方式）

設計するうえで重要です。本文中にもしばしば登場しますが、混乱したときは
以下を見て落ち着きましょう。

  • コマンドレット は単純に許可するだけでなく、必要なパラメータや動作範囲まで明示できる
  • 外部コマンドはフルパス指定しないと動かない Microsoft Learn+1

SessionConfiguration (.pssc) の役割

.psrcファイルで定義した利用コマンドを「誰の名義で」実行するかを記述します。
JEAOPSは「ユーザー定義のローカルグループ」です。予め作成しましょう。

RoleDefinitions = @{
    'BUILTIN\JEAOPS' = @{ RoleCapabilities = 'BasicAdmin' }
}
RunAsVirtualAccount = $true

なおサンプルはワークグループ環境での定義方法です。
ドメイン環境の場合は、

    'addache-ad\JEAOPS' = @{ RoleCapabilities = 'addacheAdmin' }

などのようにドメインに合わせた記述に変更する必要があります。
ローカルグループもドメインのセキュリティグループとして作成します。
またドメインの管理ユーザ(例：addacheAdmin)　を呼び出すことにより、
管理者権限が必要なAD関連コマンドを一律実行することが可能となります。
　※ただし、.psrcで定義したコマンドだけ。

Microsoft公式ドキュメント

公式資料のリンクを抜粋して記載します。

What is JEA?

RoleCapabilities

SessionConfiguration

JEA のメリット・デメリット

JEAは必ず実装しなければいけないようなものではありません。
小規模なWindows ワークグループ環境で実装するにはいささか過剰な構成でもあります。
一方で、大規模システムや大手企業の基盤担当としては、セキュリティの観点からコマンド実行権限整理／ユーザー分割など求められることがしばしば発生するので、
本概念を熟知しておくことに価値が生まれます。

メリット

  • 過剰な管理者権限を避けられる（最小権限）
  • 操作ログが必ず残る
  • コマンドレット単位の制御が可能
  • AD/サーバ管理に向く

デメリット

  • 設計がやや面倒
  • 外部コマンド制御はフルパス指定が必要
  • 一部の複雑な管理作業はそもそも向かない
  • GUIツールはコントロール不可（MMC スナップイン操作など）

忘れがちな要素

以下のコマンドを打鍵して、ローカルグループをJEA エンドポイントACLへ追加する
作業を忘れず実施しましょう。
これがないと呼び出すことができません。

Set-PSSessionConfiguration -Name JEA-Demo -ShowSecurityDescriptorUI

※基盤単位です。ドメイン環境でも同様で、ローカル設定としてしか定義できません。

結論

JEAは「Windows版sudo」であり管理者権限の適正化手段です。

進化し続けるWindows Server OSに対する適正な管理手段として、
皆さまも導入を検討されてはいかがでしょう？

用語の整理

用語説明
SessionConfiguration (.pssc)JEA エンドポイントの設定。誰がどのロールを使えるかなどを定義。
RoleCapability (.psrc)実行可能な Cmdlet／外部コマンドなどを定義するファイル。
RunAsVirtualAccountJEA セッション内で仮想管理者権限を使うためのオプション。

関連記事のご紹介

我が家のPC1台から手軽に検証できる手順

➡【Powershell】Just Enough Administration（JEA）をマイPC1台で動作検証してみた＜入門編＞

JEAっていつから存在するの？というさりげない疑問に対する筆者のアンサー

➡【Powershell】Just Enough Administration（JEA）っていつから存在するの？＜歴史編＞

それでは！

コメント

タイトルとURLをコピーしました