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

コマンドラインポリシーの設定と使用

概要

macOSおよびLinuxシステムでは、コマンドラインポリシーが標準ユーザーによる sudo の使用を管理します。

デフォルトで、Keeperは標準ユーザーが sudo で昇格実行できる特定のLinuxコマンドのリストを定義しています。リクエストがこのリスト内のコマンドと一致した場合、Keeperはポリシーを適用し、その内容に基づいて承認、多要素認証 (MFA)、実行理由の入力を求めます。

コマンドラインポリシーにより、コマンドラインからのアプリケーション実行を、コマンド引数やサブコマンドの単位で細かく制御できます。管理者が許可または拒否する引数を定義すると、実行が許可されたプログラムであっても、承認された範囲を超えた実行は抑止されます。

仕組み

コマンドが承認されると、Keeperサービスは一時的に、そのユーザーの sudoers ファイルに指定されたコマンドを追加します。

Extensionsセクションのないポリシー

ワイルドカードの昇格のみポリシー

Extensions セクションを設定していないコマンドラインポリシーは、既定では昇格したコマンドだけに一致します。対象は、macOSおよびLinuxでは sudo 経由で実行されたコマンド、WindowsではUAC昇格で実行されたコマンドです。コマンドの範囲を絞る設定がないため、適用対象のユーザーとマシンについては、この種の昇格コマンドがすべて対象になります。ワイルドカードの sudo ポリシーと同様に、ポリシーエンジンに到達した昇格コマンドはこのポリシーに一致します。

より狭い範囲のポリシーを重ねる前の土台として、たとえば任意の昇格コマンドに先立って正当化や承認を求めるといった、広いガバナンスの出発点に向いています。

例: 以下のポリシーは、対象マシンですべての昇格コマンドに承認を求めます。どのコマンドを実行するかは制限しません。

{
  "PolicyName": "Require approval for all sudo commands",
  "PolicyType": "CommandLine",
  "Status": "enforce",
  "Actions": {
    "OnSuccess": {
      "Controls": ["APPROVAL"]
    }
  },
  "UserCheck": ["*"],
  "MachineCheck": ["<machine-collection-uid>"]
}

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の場合、ファイルの場所は以下です。

/Library/Keeper/sbin/Plugins/bin/KeeperLeastPrivilegeEnforcer/Configuration/ExecutableAllowlist.json

Linuxの場合、ファイルの場所は以下です。

/opt/keeper/sbin/Plugins/bin/KeeperLeastPrivilegeEnforcer/Configuration/ExecutableAllowlist.json

管理者が追加のコマンドを許可したい場合は、このファイルを各エンドポイントで編集する必要があります (今後のリリースでは、許可コマンドの一覧がフロントエンドUIに組み込まれ、ポリシーへ同期される予定です)。

昇格コンテキストの制御: IsElevated フィールド

既定では、コマンドラインポリシーは昇格したコマンドだけを対象にします。昇格なしで実行されるコマンド (たとえばユーザーが sudo を使わずに直接実行する標準のシェルコマンド) にもポリシーを当てるには、Extension セクションで "IsElevated": false を明示的に設定する必要があります。

IsElevated フィールドは、以下の3つのいずれかになります。

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

例: 以下のポリシーは、昇格していない ls の実行を対象とします (特定の引数の組み合わせを想定した例です)。

{
  "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 コマンドに正当化を求めます。

{
  "Extension": {
    "IsElevated": true
  },
  "Actions": { "OnSuccess": { "Controls": ["JUSTIFY"] } }
}

例 — 特定コマンドに限定: passwd コマンドに限り、正当化なしでパスワード変更を許可します。

{
  "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 を課す:

{
  "ApplicationCheck": ["*"],
  "UserCheck": ["*"],
  "Extension": { "IsElevated": true },
  "Actions": { "OnSuccess": { "Controls": ["MFA"] } }
}

ポリシーB — 具体。パスワード変更だけコントロールなしで許可:

{
  "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 なしでコマンドが許可されます。

重要: 具体性は AllowCommands の有無ではなく、UserCheck、ApplicationCheck、MachineCheck で決まります。AllowCommands があっても ApplicationCheck: ["*"] のままならワイルドカード扱いのままであり、別のワイルドカードポリシーより自動的に優先されることはありません。具体ポリシーとして優先させるには、ApplicationCheck (または UserCheck / MachineCheck) を "*" 以外の名前付きアプリケーションやコレクションに向けてください。

組み込みユーザーの動作

Keeperは、 ubuntu や ec2-user などの組み込みユーザーの sudo 権限を変更しません。したがって、ユーザーが既に sudo 権限を持つグループのメンバーである場合、 ExecutableAllowlist.json のリストに限定されることなく、 sudo コマンドを実行できます。言い換えると、Keeperのサービスは可能な範囲でポリシーを適用しますが、システム管理者によってすでに昇格権限が付与されている場合には制限が及ばないことがあります。

完全な昇格制御を行うには、ユーザーが既存の sudo グループのメンバーになっていないことを確認してください。

他のポリシータイプとの連携

コマンドラインポリシーは、特権昇格ポリシーおよび最小権限ポリシーを補完します。昇格後の実行と標準ユーザーとしての実行のどちらでも、コマンド引数の単位で同じ制約が適用され、特権の有無にかかわらず制限内容をそろえて運用できます。