Just‑Enough‑Administration (JEA) を使用した PowerShell のセキュア リモート処理

PowerShellリモートの使用は、あらゆる環境でほぼ不可欠になっています。 Windows 現代的ではありますが、制御なしにリモートアクセスを許可するのは、データセンターの鍵をテーブルの上に置き忘れているようなものです。ここでゲームの出番です。 十分な行政（JEA）管理者権限を他人に譲り渡すことなくタスクを委任できるセキュリティ レイヤーです。

JEAを使用すると、特定のユーザーのみが実行できる非常に限定されたリモートアクセスポイントを設定できます。 コマンド より多くの権限を持つアカウントで承認したが、 本当の資格を知らずに、または台本から逸脱することができずにそして、これらすべては記録に残され、 ログ これにより、誰が何をいつどこから実行したかを監査できるようになります。

Just-Enough-Administration (JEA) とは何ですか? なぜ重要なのですか?

Just-Enough-AdministrationはPowerShellベースのセキュリティ技術です 必要最小限の権限で委任管理モデルを実装します。実際には、JEA を使用すると、ユーザーが定義したコマンドレット、関数、スクリプト、外部コマンドのセットのみが利用可能なリモートエンドポイントを公開できます。

このアプローチのおかげで、 昇格された権限を持つアカウントの数を大幅に削減する サーバーでは、標準ユーザーに代わって特権アクションを実行する仮想アカウントまたはグループ管理サービスアカウント（gMSA）を使用できます。ユーザーは通常の資格情報でログインし、JEAセッションを介して、バックグラウンドでより高い権限で実行されるコマンドを実行します。

JEAのもう一つの重要な柱は、 各役割が何ができるかを正確に定義するロール機能ファイルは、表示されるコマンドレット、カスタム関数、外部コマンド、またはPowerShellプロバイダーを定義します。残りの部分はユーザーにとって存在しません。つまり、スクリプトを即興で作成したり、ファイルシステムを自由に操作したり、指定されていないサービスやプロセスにアクセスしたりすることはできません。

さらに、すべてのJEAセッションは、 完全なトランスクリプトと監査イベントコマンド、パラメータ、出力、エラー、ユーザー ID、実行時間をキャプチャすることは、規制要件を満たすのに役立つだけでなく、セキュリティ インシデントや運用上の障害を調査する際にも非常に役立ちます。

特権アカウントのリスクとJEAによるリスク軽減方法

昇格された権限を持つローカル、ドメイン、またはアプリケーションの管理者アカウントは、 あらゆる組織における最も深刻なリスク要因の1つ攻撃者がこれらの資格情報のいずれかを入手すると、ネットワーク内を横方向に移動して権限を昇格し、重要なデータや主要なサービスにアクセスしたり、システム全体をダウンさせたりすることさえ可能です。

権限の剥奪は必ずしも簡単ではありません。典型的な例としては、 DNSとActive Directoryドメインコントローラの両方をホストするサーバーDNSチームはDNSサービスの問題をトラブルシューティングするためにローカル管理者権限を必要としますが、Domain Adminsグループに追加することで、事実上フォレスト全体の制御権と、そのマシン上のあらゆるリソースへのアクセス権限を付与されてしまいます。これは、運用上の利便性のためにセキュリティを犠牲にする典型的な例です。

JEAは、このジレンマを、 最小権限の原則DNS管理者をドメイン管理者にする代わりに、キャッシュのクリア、サービスの再起動、ログの確認などのタスクに必要なコマンドレットのみを公開する専用のDNS JEAエンドポイントを作成できます。これにより、オペレーターはActive Directoryの確認、ファイルシステムの参照、ランダムなスクリプトの実行、潜在的に危険なユーティリティの実行といった煩わしい作業を行うことなく、業務を遂行できます。

JEAセッションを設定する場合 一時的な権限を持つ仮想アカウントこの動きはさらに興味深いものです。ユーザーは権限のない認証情報で接続し、そのセッションから通常は管理者権限を必要とするタスクを実行できます。これにより、多くのユーザーをローカルまたはドメインの管理者グループから除外することができ、業務を維持しながら攻撃対象領域を大幅に強化することができます。

JEAを支えるセキュリティ概念

JEA は何も無いところから生まれたわけではありません。 これは、いくつかの確立されたセキュリティ原則とモデルに基づいています。 これにより、一貫性と堅牢性が確保されます。まず、前述の最小権限の原則があります。これは、ユーザーとプロセスの両方に、それぞれの機能に必要な権限のみを与えることを規定するものです。

2つ目の大きな柱は、 ロールベースのアクセス制御 (RBAC)JEAはロール機能ファイルを通じてRBACを実装します。ロール機能ファイルでは、リモートセッション内で特定のロールが実行できる操作を定義します。例えば、ヘルプデスクロールはサービスの一覧表示、イベントの表示、特定のサービスの再起動が可能ですが、SQL Server管理ロールは…に関連するコマンドレットのみを実行できます。 データベース そしてもう少し。

La JEAの技術的基盤はPowerShellとそのリモートインフラストラクチャですPowerShell は言語、コマンドレット、リモート通信層 (WinRM/WS-Management) を提供し、JEA は制限されたエンドポイント、仮想アカウント、および使用可能なコマンドの詳細な制御のシステムを追加します。

もう一つの重要な概念は 制限された管理、に似ています Windows 11 キオスク モードで割り当てられたアクセスJEAは、オペレーターに完全なシェルを提供する代わりに、スクリプト言語が制限されたセッション（デフォルトではNoLanguage）を構築し、新しい関数や変数の作成をブロックし、ループや条件文を禁止し、承認されたコマンドレットセットのみを実行できるようにします。これにより、攻撃者がそのセッションにアクセスできたとしても、その能力は大幅に制限されます。

主要コンポーネント: .psrc および .pssc ファイル

JEA 展開の中心となるのは、次の 2 種類のファイルです。 ロール機能ファイル (.psrc) とセッション構成ファイル (.pssc)これらを組み合わせることで、汎用シェルが特定のユーザー向けに完全にカスタマイズされたエンドポイントに変換されます。

ロール機能ファイルでは、 ロールで使用できるコマンドを正確に最も重要な要素は次のとおりです。

• 表示されるコマンドレット: 許可されたコマンドレットのリスト。パラメータを制限することもできます。
• 表示機能: セッションにロードされるカスタム関数。
• 表示可能な外部コマンド: アクセスされる特定の外部実行可能ファイル。
• 表示プロバイダー: セッションで表示される PowerShell プロバイダー (FileSystem や Registry など)。

一方、.psscセッション構成ファイルは、 JEA エンドポイントをそのように記述し、それをロールにリンクします。ここでは次のような要素が宣言されます。

• 役割の定義: ユーザーまたはセキュリティ グループをロール機能にマッピングします。
• セッションタイプ: ここで、'RestrictedRemoteServer' は通常、セッションを強化するために設定されます。
• トランスクリプトディレクトリ: 各セッションのトランスクリプトが保存されるフォルダー。
• 仮想アカウントとして実行 仮想アカウントを特定のグループに追加するかどうかなどの関連オプションもあります。

JEAは次のような形で実現する システムに登録された PowerShell リモート エンドポイントこれらのエンドポイントは、次のようなコマンドレットで作成され、有効化されます。 新しいPSSessionConfigurationFile, PSSessionConfigurationの登録 または、JEA ヘルパー ツールなどのグラフィカル ツールを使用すると、構文にあまり苦労せずに .pssc ファイルや .psrc ファイルを簡単に生成できます。

JEAセッションライフサイクル

完全なJEA環境を構築する場合、プロセスは通常、一連の論理的な手順に従います。 オープンなリモート システムを厳密に管理されたシステムに変換します。一般的なシーケンスは次のとおりです。

まず、 セキュリティグループまたは複数のグループ 委任したい役割を表すグループを作成します（例：ヘルプデスクDNS、Webオペレーター、SQLオペレーター）。グループの使用は必須ではありませんが、環境の拡大に伴い管理が大幅に簡素化されます。

その後、1つまたは複数が準備されます ロール機能ファイル .psrc 許可されるアクション（コマンドレット、関数、スクリプト、外部コマンド、エイリアス、プロバイダー、および追加の制限（特定のパラメーター、許可されたパスなど））が一覧表示されます。例えば、Get-で始まるすべてのコマンドレットを許可し、Restart-ServiceをSpoolerサービスに制限し、FileSystemプロバイダーのみを承認することができます。

以下が生成されます セッション構成ファイル .pssc New-PSSessionConfigurationFileを使用します。SessionType = RestrictedRemoteServer、TranscriptDirectoryパス、仮想アカウントの使用の有無、グループとロール機能をリンクするRoleDefinitionsブロック（例：'DOMAIN\HelpdeskDNS' = @{ RoleCapabilities = 'HelpdeskDNSRole' }）などのオプションを定義します。

.psscファイルがすでに準備されているので、エンドポイントは次のように登録されます。 Register‑PSSessionConfiguration -Name JEASession Name -Path Path\File.psscその瞬間から、使用可能な構成が Get-PSSessionConfiguration でリストされている場合、新しい接続ポイントは接続を受け入れる準備ができているように見えます。

ユーザーは、自分のコンピュータからこのエンドポイントに接続します。 Enter‑PSSession -ComputerName Server -ConfigurationName JEASession名 または、New-PSSession と Invoke-Command を使用します。セッションに入ると、ユーザーに関連付けられたロール機能で定義された制限が自動的に適用されます。

セッション中、 PowerShell リモート処理は暗号化されたチャネルで WinRM を使用します統合認証（通常はドメイン内のKerberos）と、サービスに定義されたファイアウォールルール。この基盤として、RunAsVirtualAccountが有効になっている場合、一時的な仮想アカウントが作成され、必要なグループに追加され、セッション終了時に破棄されます。

最後に、JEAセッションの終了にあたり、 監査記録とイベントは保存されます これらのログは、実行されたコマンド、結果、およびユーザーコンテキストの明確な痕跡を残します。これらのログは、SIEMシステムに送信したり、SIEMシステム内で相関分析したりすることで、アラートやさらなる分析に活用できます。

PowerShell リモート処理、アクセス制御、および強化

サービスでサポートされている PowerShell リモート処理 Windows リモート管理 (WinRM) WS-Managementプロトコルは、リモートコンピュータ上でコマンドやスクリプトを集中的に実行することを可能にします。自動化、大規模なサーバー管理、デバッグ、リモートサポートのための強力なツールです。

デフォルトでは、 ローカル管理者とリモート管理ユーザーグループのメンバー 標準のPowerShellエンドポイントを使用できます。多くの環境では、この機能を利用して管理者以外のユーザーがリモートタスクを実行できるようにしています。これは本質的に危険ではありませんが、適切に制御されていない場合、悪用される大きな可能性を秘めています。

セキュリティ体制を強化するための一般的な戦略は、 リモート PowerShell アクセスを管理者アカウントのみに制限します。 あるいは、さらに良い方法として、特定のユーザーに厳密に必要なアクセスのみを許可するJEAエンドポイントとこの制限を組み合わせることができます。これは以下の方法で実現できます。

• WinRM を使用できるグループと既定のエンドポイントを定義する GPO。
• サブネットまたは管理コンピューターからのみ WinRM を許可するファイアウォール ルール。
• 標準エンドポイントの ACL からリモート管理ユーザー グループを削除します。

さらに、 管理者以外のユーザーに対して PowerShell を完全にブロックする AppLockerなどのソリューションを使用します。これにより、標準ユーザーによる悪意のあるスクリプトのローカル実行を防ぎながら、特権アカウントがPowerShellを使用して管理タスクや自動化タスクを実行できるようになります。

JEA と他の PowerShell 制限方法の比較

PowerShellリモート処理でユーザーが実行できる操作を制限する方法はいくつかあります。 JEAはより薄く、より柔軟な選択肢として適しています 次のような幅広いアプローチを含む範囲内で:

一方では、 デフォルトの PowerShell エンドポイントに誰がアクセスできるかを制御する GPOMicrosoft PowerShell は管理者のみに制限することも、すべてのユーザーを登録解除して特定のエンドポイントのみの使用を強制することもできます。これは「ブルートフォース」方式でアクセスを制限するのに便利ですが、粒度の問題は解決されません。アクセス権を取得すれば、事実上何でも実行できてしまうからです。

一方、次のようなアプリケーション制御ツールがあります。 AppLockerまたはソフトウェア制限ポリシーこれらの方法を使用すると、パス、発行元、またはハッシュを使用して、標準ユーザーによるPowerShell.exeまたはpwsh.exeの実行を拒否できます。この方法は、ワークステーションを強化し、すべてのユーザーによるPowerShellの起動を阻止するのに役立ちますが、ユーザーアカウントから限定的な管理タスクを実行させたい場合には制限があります。

別のオプションは 完全なJEAに到達しない制約されたエンドポイントコマンドレット、関数、モジュールを制限するカスタムセッション構成を作成できますが、JEAが提供するロールモデル、仮想アカウント、構造化RBACに大きく依存する必要はありません。これは、シンプルなシナリオには適していますが、大規模環境ではスケーラビリティが低くなる中間的な選択肢です。

JEA はさまざまな分野の最高のものを組み合わせています。 厳格なコマンド制限、RBAC、制御された昇格権限の実行、包括的なログ記録これは、管理者以外のユーザーに対して PowerShell リモート処理を有効にする必要があるものの、完全な管理環境を提供したくない場合に推奨されるソリューションになります。

高度な機能: 別のアカウントとして実行してログイン

JEAの最も強力な機能の一つは 資格情報を公開せずに、別のより権限のあるアカウントとしてコマンドを実行するこれにより、「このサービスのパスワードを教えるから、X が実行できる」という典型的な問題が解決されますが、このパスワードはその後変更されず、大きなリスクになってしまいます。

ドメインシナリオは一般的に使用される グループ管理サービス アカウント (gMSA) これにより、JEAエンドポイントは、一元管理されたサービスIDの下でアクションを実行できます。パスワードは自動的にローテーションされ、オペレーターが秘密情報を知ることはありません。それ以外の場合は、マシンのローカルにある一時的な仮想アカウントが使用されます。このアカウントは、ユーザーが接続した際にアドホックに作成され、セッション終了時に破棄されます。

監査の観点から、各JEAセッションは次のように構成できます。 PowerShell トランスクリプトと豊富なイベント ログ エントリの両方を生成します。通常収集される情報には次のようなものがあります。

• 入力されたコマンドとパラメータの完全な履歴。
• 生成されたメッセージとエラー メッセージを出力します。
• セッションの開始と終了のタイムスタンプ、およびセッションの継続時間。
• ログインしたユーザーの ID と割り当てられたロール/容量。

これらの痕跡を以下の機能と組み合わせると PowerShellモジュールのログ記録と スクリプト GPO経由でログをブロックするログをSIEMに送信することで、管理エンドポイントで何が起こっているかを強力に可視化できます。これは、コンプライアンス（SOX監査、ISO 27001など）とインシデントの検知・対応の両方にとって重要です。

実世界環境における典型的なJEAの使用例

JEAは特に必要なときに役立ちます 管理者ではないチームに非常に具体的なタスクを委任する実際によくある例は次のとおりです。

技術サポート分野では、トップレベルの技術者に JEA アクセスによるサービスの再起動、イベント ログの表示、プロセス ステータスの確認 サーバー上で操作できますが、ソフトウェアのインストール、重要な構成の変更、Active Directoryへのアクセスはできません。一般的なヘルプデスクの役割には、特定のサービスに対するGet-Service、Restart-Service、読み取り専用モードのGet-EventLogなどのコマンドレットや、一部のネットワーク診断コマンドレットが含まれます。

運用チームや開発チームでは、 IIS管理やウェブサイトのメンテナンスなどの特定のタスクに重点を置いた役割たとえば、アプリケーション プール管理コマンドレット、Web サイトの再起動、制限されたディレクトリからのログのクエリ、特定のサービスの証明書管理へのアクセスを許可しますが、サーバー全体を再起動したり、セキュリティ ポリシーを変更したりする機能は除外します。

ハイブリッド環境やクラウド環境では、JEAは次のような用途でよく使用されます。 各チームの行動を制限する 仮想マシン, ストレージ またはネットワークエンドポイントを公開することで、部門の VM のみを管理したり、特定のセグメントのファイアウォール ルールを変更したり、特定のサービス アカウント セットを管理したりしながら、インフラストラクチャの残りの部分からアクセスを分離することができます。

同時に、JEAは 特権アクセス管理（PAM）戦略特権セッションが一時的に許可され、ログに記録され、個人の ID に関連付けられるため、アカウントの共有が回避され、各特権アクションに関連するリスクが最小限に抑えられます。