# コマンドラインポリシータイプ

## 概要 macOSおよびLinuxシステムでは、コマンドラインポリシーが標準ユーザーによる `sudo` の使用を管理します。デフォルトで、Keeperは標準ユーザーが `sudo` で昇格実行できる特定のLinuxコマンドのリストを定義しています。リクエストがこのリスト内のコマンドと一致した場合、Keeperはポリシーを適用し、その内容に基づいて承認、多要素認証 (MFA)、実行理由の入力を求めます。コマンドラインポリシーにより、コマンドラインからのアプリケーション実行を、コマンド引数やサブコマンドの単位で細かく制御できます。管理者が許可または拒否する引数を定義すると、実行が許可されたプログラムであっても、承認された範囲を超えた実行は抑止されます。 ## 仕組みコマンドが承認されると、Keeperサービスは一時的に、そのユーザーの `sudoers` ファイルに指定されたコマンドを追加します。 ### Extensionsセクションのないポリシー #### ワイルドカードの昇格のみポリシー `Extensions` セクションを設定していないコマンドラインポリシーは、既定では**昇格したコマンドだけ**に一致します。対象は、macOSおよびLinuxでは `sudo` 経由で実行されたコマンド、WindowsではUAC昇格で実行されたコマンドです。コマンドの範囲を絞る設定がないため、適用対象のユーザーとマシンについては、この種の昇格コマンドが**すべて**対象になります。ワイルドカードの `sudo` ポリシーと同様に、ポリシーエンジンに到達した昇格コマンドはこのポリシーに一致します。より狭い範囲のポリシーを重ねる前の土台として、たとえば任意の昇格コマンドに先立って正当化や承認を求めるといった、広いガバナンスの出発点に向いています。 **例:** 以下のポリシーは、対象マシンですべての昇格コマンドに承認を求めます。どのコマンドを実行するかは制限しません。 ```json { "PolicyName": "Require approval for all sudo commands", "PolicyType": "CommandLine", "Status": "enforce", "Actions": { "OnSuccess": { "Controls": ["APPROVAL"] } }, "UserCheck": ["*"], "MachineCheck": [""] } ``` `Extension` セクションがないため、このポリシーはすべての昇格コマンドに一致します。特定のコマンドにだけ適用範囲を絞る場合や、昇格していないコマンドにもポリシーを適用する場合は、以下の各節をご参照ください。 ## 使用方法コマンドラインポリシーが適用されると、KeeperはPAMモジュールを利用して `sudo` コマンドを上書きし、新しい `keepersudo` コマンドとして動作させます。ユーザーは `keepersudo` を実行することで、承認リクエストの送信、多要素認証 (MFA) による昇格、または実行理由の入力を行うことができます。ユーザーが `sudo` を使用しようとすると、以下のように新しいコマンドの使用を案内されます。 ``` ubuntu@ip-172-31-8-134:/home$ sudo systemctl restart nginx ERROR: To run sudo, use keepersudo ``` 昇格ポリシーが適用されている場合、ユーザーは以下のように `keepersudo` でコマンドを実行します。 ``` ubuntu@ip-172-31-8-134:/home$ keepersudo systemctl restart nginx Your Keeper Administrator requires approval for this action. Please enter the reason for this request: Ticket SYS-4432 I need to restart nginx Approval request has been submitted. To refresh approval status run: keeperagent --refresh After approval run: keeperagent --approval ``` 管理者は、この昇格リクエストを受信して承認を行います。

リクエストが承認されると、ユーザーは以下のコマンドを実行して承認済みのリクエストを実行できます。 ``` ubuntu@ip-172-31-8-134:/home$ keeperagent --approval You have 1 approved command: 1: /usr/bin/sudo /usr/bin/systemctl restart nginx (expires in 23 hours and 57 minutes) To run an approved command, enter the number. To see pending requests, type 'p' To refresh approvals, type 'r' Choose an option or 'e' to exit: 1 ``` ## sudo昇格の管理管理コンソールで **\[エンドポイント特権マネージャー] > \[ポリシー]** に移動し、新しいポリシーを作成します。ポリシータイプとして **\[コマンドライン]** を選択し、次に **\[適用]** を選択します。

コマンドラインポリシーは、特定のユーザーおよびマシンコレクションに適用できます。ポリシーを適用するマシンコレクションを選択します。

## 高度な構成許可される `sudo` コマンドの一覧は、`ExecutableAllowlist.json` というファイルで設定します。 macOSの場合、ファイルの場所は以下です。 {% code overflow="wrap" %} ``` /Library/Keeper/sbin/Plugins/bin/KeeperLeastPrivilegeEnforcer/Configuration/ExecutableAllowlist.json ``` {% endcode %} Linuxの場合、ファイルの場所は以下です。 {% code overflow="wrap" %} ``` /opt/keeper/sbin/Plugins/bin/KeeperLeastPrivilegeEnforcer/Configuration/ExecutableAllowlist.json ``` {% endcode %} 管理者が追加のコマンドを許可したい場合は、このファイルを各エンドポイントで編集する必要があります (今後のリリースでは、許可コマンドの一覧がフロントエンドUIに組み込まれ、ポリシーへ同期される予定です)。 ## 昇格コンテキストの制御: `IsElevated` フィールド既定では、コマンドラインポリシーは昇格したコマンドだけを対象にします。昇格なしで実行されるコマンド (たとえばユーザーが `sudo` を使わずに直接実行する標準のシェルコマンド) にもポリシーを当てるには、`Extension` セクションで `"IsElevated": false` を明示的に設定する必要があります。 `IsElevated` フィールドは、以下の3つのいずれかになります。

値	挙動
未設定 (省略)	ポリシーは昇格したコマンドのみに一致
`true`	ポリシーは昇格したコマンドのみに一致 (未設定と同じ)
`false`	ポリシーは昇格していないコマンドに一致 (昇格したコマンドにも一致)

**例:** 以下のポリシーは、昇格していない `ls` の実行を対象とします (特定の引数の組み合わせを想定した例です)。 ```json { "PolicyName": "Audit non-elevated ls usage", "PolicyType": "CommandLine", "Status": "monitor", "Actions": { "OnSuccess": { "Controls": ["AUDIT"] } }, "UserCheck": ["*"], "ApplicationCheck": ["*"], "Extension": { "IsElevated": false } } ``` `Extension` に `"IsElevated": false` がない場合、このポリシーは昇格していないコマンドには一致せず、監査や制御の対象にもなりません。 ## 特定のコマンドにスコープを絞る: `AllowCommands` `Extension` に `AllowCommands` 配列がないコマンドラインポリシーは**ワイルドカードのコマンドポリシー**です。`IsElevated` のコンテキストに従い、対象ユーザーが対象マシンで実行する**すべて**のコマンドに一致します。広いガバナンスの土台として適切なパターンです。 `Extension.AllowCommands` に1つ以上のエントリを追加すると、ポリシーの適用範囲は狭まり、**コマンドラインに、リストしたパターンのいずれかが含まれる場合にのみ**一致します。いずれのパターンにも当てはまらないコマンドは、このポリシーの評価から外れ、ほかの該当ポリシー (またはシステムの既定) に委ねられます。コマンドパターンは大文字小文字を区別しない部分一致です。`/usr/bin/passwd` というパターンは `sudo /usr/bin/passwd testuser` や `SUDO /USR/BIN/PASSWD admin` に一致します。


`AllowCommands` の有無	ポリシーの適用範囲
いいえ	すべてのコマンドに一致 (ワイルドカード)
はい	列挙したパターンを含むコマンドだけに一致

**例 — ワイルドカード (`AllowCommands` なし):** 任意の `sudo` コマンドに正当化を求めます。 ```json { "Extension": { "IsElevated": true }, "Actions": { "OnSuccess": { "Controls": ["JUSTIFY"] } } } ``` **例 — 特定コマンドに限定:** `passwd` コマンドに限り、正当化なしでパスワード変更を許可します。 ```json { "Extension": { "IsElevated": true, "AllowCommands": ["/usr/bin/passwd"] }, "Actions": { "OnSuccess": { "Controls": ["ALLOW"] } } } ``` コマンドラインに `/usr/bin/passwd` が含まれないコマンドは、この2つ目のポリシーの影響を受けず、1つ目のポリシーどおりに扱われます。 ## ポリシーの優先順位コマンドラインポリシーでも、KEPMのほかのポリシータイプと同様に、**具体**ポリシーと**ワイルドカード**ポリシーの優先順位規則が使われます。複数のポリシーが要求に一致するときは、まず**具体**と**ワイルドカード**に分類し、より絞り込まれた側だけを評価します。 `UserCheck`、`ApplicationCheck`、`MachineCheck` のいずれかにワイルドカード以外の値が1つ以上あるポリシーは**具体**ポリシーです (名前付きのユーザー、名前付きのアプリケーション、名前付きのマシンを対象とし、`"*"` だけではない場合)。3つすべてが `"*"` であるか空である場合は**ワイルドカード**ポリシーです。 **優先規則は以下のとおりです。** * 一致する具体ポリシーが1つでもあれば、**その具体ポリシーのみ**が評価の対象となり、同一の要求に対してワイルドカードポリシーは無視されます。 * 具体ポリシーが1つも一致しなければ、ワイルドカードポリシーが評価されます。このため、特定アプリケーション向けの**許可**を定めた具体ポリシーは、すべてのコマンドに**MFA**を課すワイルドカードポリシーがあっても適用されます。具体ポリシーが先に採用され、ワイルドカードは評価から外れるためです。同様に、同一の要求に2つの具体ポリシーが両方あてはまり、一方が**正当化**、他方が**許可**を課す場合は、**正当化**が求められます。衝突する具体ポリシー同士は積み上げで組み合わされ、正当化は許可より優先されます。 **コントロールの優先順位 (高い順):** `DENY` → `APPROVAL` → `MFA` → `JUSTIFY` → `ALLOW` **例** *ポリシーA — ワイルドカード。すべての昇格コマンドに MFA を課す:* ```json { "ApplicationCheck": ["*"], "UserCheck": ["*"], "Extension": { "IsElevated": true }, "Actions": { "OnSuccess": { "Controls": ["MFA"] } } } ``` *ポリシーB — 具体。パスワード変更だけコントロールなしで許可:* ```json { "ApplicationCheck": ["sudo", "/usr/bin/sudo"], "UserCheck": ["*"], "Extension": { "IsElevated": true, "AllowCommands": ["/usr/bin/passwd"] }, "Actions": { "OnSuccess": { "Controls": ["ALLOW"] } } } ``` ユーザーが `sudo passwd testuser` を実行すると、ポリシーBは `ApplicationCheck` が `sudo` を明示しているため具体ポリシーであり、ポリシーAはワイルドカードです。評価ではポリシーBだけが使われ、MFA なしでコマンドが許可されます。 {% hint style="info" %} **重要:** 具体性は `AllowCommands` の有無ではなく、`UserCheck`、`ApplicationCheck`、`MachineCheck` で決まります。`AllowCommands` があっても `ApplicationCheck: ["*"]` のままならワイルドカード扱いのままであり、別のワイルドカードポリシーより自動的に優先されることはありません。具体ポリシーとして優先させるには、`ApplicationCheck` (または `UserCheck` / `MachineCheck`) を `"*"` 以外の名前付きアプリケーションやコレクションに向けてください。 {% endhint %} ## 組み込みユーザーの動作 Keeperは、 `ubuntu` や `ec2-user` などの組み込みユーザーの `sudo` 権限を変更しません。したがって、ユーザーが既に `sudo` 権限を持つグループのメンバーである場合、 `ExecutableAllowlist.json` のリストに限定されることなく、 `sudo` コマンドを実行できます。言い換えると、Keeperのサービスは可能な範囲でポリシーを適用しますが、システム管理者によってすでに昇格権限が付与されている場合には制限が及ばないことがあります。完全な昇格制御を行うには、ユーザーが既存の `sudo` グループのメンバーになっていないことを確認してください。 ## 他のポリシータイプとの連携コマンドラインポリシーは、特権昇格ポリシーおよび最小権限ポリシーを補完します。昇格後の実行と標準ユーザーとしての実行のどちらでも、コマンド引数の単位で同じ制約が適用され、特権の有無にかかわらず制限内容をそろえて運用できます。 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.keeper.io/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/command-line-policy-type.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.