管理者権限をコントロールする2つのアプローチ――必要最低限の管理（JEA）と特権アクセス管理（PAM）：vNextに備えよ！次期Windows Serverのココに注目（56）（1/2 ページ）

Windows Server 2016のActive Directoryドメイン環境では、「JEA」「PAM」と呼ばれる2つの特権管理機能が利用可能になります。登場したばかりの新しいセキュリティ機能なので、まだよく知られていないと思います。今回は、JEAとPAMでどんなことができるのかを紹介します。

» 2016年07月28日 05時00分公開

[山市良，テクニカルライター]

連載目次

特権管理のための新たな2つのアプローチ

　Windowsのシステムやネットワークでは「ビルトイングループ」（Administrators、Domain Admins、Enterprise Admins、Backup Operators、Remote Desktop Usersなど）を使用して、ローカル／ドメインユーザー、ドメイングループに対して特権的な権限を付与できます。

　Windowsの役割や機能、その他の製品やサービスでは「役割ベースのアクセス制御（Role-Based Access Control：RBAC）」というアクセス制御機能を持ち、より細かな役割ごとに権限を委任できるものもあります。

　Microsoft AzureやOffice 365のサービスには、文字通りRBACという機能があります。Windows Serverの役割や機能では、Active Directory証明書サービス、Hyper-Vの「承認マネージャー」（ただし、Windows Server 2012以降は非推奨）、IPアドレス管理（IPAM）などに、RBACの考えに基づいたアクセス制御機能が備わっています。

　Windows Server 2016では、RBACとはまた別の、次の2つの特権管理機能が利用可能になります。

Just Enough Administration（JEA）
特権アクセス管理（Privileged Access Management：PAM）

　JEAとPAMはどちらも「特権の委任を管理するセキュリティ機能」ですが、アプローチが異なります。JEAは「Just Enough（必要最低限、必要十分）」な特権だけを、ユーザーやグループに付与します。一方、PAMは通常時には特権を与えず、特権操作が必要な場合にのみ、ユーザーからの要求に基づいて特権を「有効期限付き」で付与します。

　どちらの機能も、ユーザーに必要以上の特権を与えることがなくなり、サインイン中のユーザーが持つ特権を最小限にできるので、マルウェアへの感染などで特権を悪用されるリスクが低減します。

　JEAは2015年12月にリリース（2016年2月に再リリース）された「Windows Management Framework（WMF）5.0」および「Windows PowerShell 5.0」から利用可能です。一方、PAMは2015年8月リリースの「Microsoft Identity Manager 2016（MIM 2016）」が提供する機能であり、Windows Server 2012 R2のActive Directoryドメインでも利用可能です。

　JEA／PAMは、現行のWindows Server 2012 R2でも利用可能であり、“Windows Server 2016の新機能”と説明するのは正しくないかもしれません。しかし、Windows Server 2016には、JEAに対応したWMF 5.1とWindows PowerShell 5.1が最初からビルトインされています。Windows Server 2016は、PAMの前提となるMIM 2016が提供済みという状況下でのリリースになるという視点から見れば、JEAとPAMはWindows Server 2016の新機能に含んでも間違いではないのかもしれません。

PowerShell Remotingと組み合わせて利用するJEA

　JEAは、Windows PowerShellのシェル環境で実行可能な、管理操作を詳細に委任できるセキュリティ機能です。JEAを構成するにはWindows PowerShellを使用する必要があり、少々複雑です。JEAの概念や展開方法を知る早道は、以下のドキュメントの手順に従ってデモ環境を構築し、試してみることでしょう。デモを試してみれば、JEAでできることを体感的に理解できるはずです。

Just Enough Administration（MSDN）

　管理対象のサーバで「Enable-PSRemoting」コマンドレットを実行し、「PowerShell Remoting」を有効化します。JEAは、リモートからPowerShell Remotingで接続したPowerShellセッションに適用されます。

　また、管理対象のサーバでは、「New-PSRoleCapabilityFile」コマンドレットを使用して、「Role Capability File」を作成します。このファイルは、役割でできることを定義するものです。以下の画面1では、「Maintenance」という役割、「Restart-Service」というコマンドレットの使用を許可しています。

画面1　「New-PSRoleCapabilityFile」コマンドレットを使用して、役割でできることを定義したファイル「Role Capability File」を作成する

　さらに、管理対象のサーバでは、「New-PSSessionConfigurationFile」コマンドレットを使用して、管理者権限を持たないドメイングループ（この例では「<ドメイン名>\JEADemo_NonAdminOperators」）に対して、「Maintenance」の役割を与え、PowerShellセッションのエンドポイント（この例では「JEA_Demo」）を作成し、「Register-PSSessionConfiguration」コマンドレットでエンドポイントをサーバに登録します（画面2）。

画面2　「New-PSSessionConfiguration」コマンドレット、「Register-PSSessionConfiguration」コマンドレットを使用して、JEAのエンドポイントを作成し、非管理者のドメイングループに役割を委任する

　これで準備は完了です。Windows PowerShell 5.0以降を実行するリモートコンピュータから次のようなコマンドラインを実行し、PowerShell Remotingを使用して管理対象のサーバのJEAのエンドポイントに接続します。

Enter-PSSession -ComputerName <コンピュータ名> -ConfigurationName <エンドポイント名> -Credential <役割が付与されたドメイングループのメンバーの資格情報>

　通常、Windows ServerにPowerShell Remotingでリモート接続するには、Administratorsローカルグループの権限を持つユーザーで接続する必要があります（一般ユーザーはアクセスが拒否されます）。

　これに対して、JEAで役割が許可されたドメイングループのメンバー（この例では「<ドメイン名>\JEADemo_NonAdminOperators」のメンバー）は、Administratorsローカルグループの権限を持たなくても管理対象のサーバに接続することができます。また、「Get-Command」コマンドレットを実行すると、「Role Capability File」で許可されたコマンドレット（この例では「Restart-Service」のみ）のみを利用できることが分かります（画面3）。

画面3　「Get-Command」コマンドレットを実行すると、利用可能なコマンドレットとして「Restart-Service」だけが表示される。「Restart-Service」以外は実行できない。他の9つのFunctionは、JEAの既定のもの

　「Role Capability File」（拡張子.psrc）はプレーンテキスト形式であり、「メモ帳」などのテキストエディタでカスタマイズすることができます。例えば、以下の画面4のように記述すると、「Restart-Service」コマンドレットで「DNS」（DNSServer）サービスの再起動のみを許可できます。