ポリシー評価

ポリシー評価の仕組み

Keeper EPMは、適用対象のすべてのポリシータイプで共通の評価モデルを使います。本ページでは、そのモデルの概要、主要ポリシータイプの関係、パス変更やツールのコピー、AIエージェントによる子プロセス起動でもコントロールが効き続けるためのレイヤー型の推奨アプローチを取り扱います。

ハッシュのみとパス＋ハッシュのメンバーの違いや、競合の具体例など、ファイルアクセスの一致の詳細については、ファイルアクセスポリシー評価ガイドをご参照ください。作成ワークフローについては、ポリシータイプ、ポリシーコントロール、ポリシーステータスをご参照ください。

ポリシータイプ一覧

適用対象のポリシータイプは、いずれも同じフィルターモデル (ユーザー、マシン、アプリケーション、証明書、スケジュール、コントロール) と、同じ競合ルールを共有します。異なるのは、どのイベントに結び付くかと、そのイベントにおける「アプリケーション」の意味 (起動するアプリ、昇格対象、元のエージェント、子プロセス) です。

ポリシータイプ	評価されるタイミング	統制する内容
ファイルアクセス	プロセス起動	ユーザーがこのアプリケーションを実行できるか (ベースラインの実行制御)
特権昇格	昇格リクエスト	ユーザーがこのアプリケーションを昇格実行できるか
エージェント型AI	AIまたはエージェントアプリのプロセス起動	ユーザーが当該AIアプリケーションを直接起動できるか
エージェント型アクセス	AIエージェントからの子プロセス	AIエージェントがサブプロセスとして生成またはアクセスしてよいもの
エージェント型特権昇格	AIに帰属するプロセスからの昇格	AIに帰属するプロセスが昇格してよいもの

評価中に起きること

1. エージェントがイベントを観測します (起動、昇格、またはエージェントの子プロセス / エージェントによる昇格)。
2. 誰が (ユーザー)、どこで (マシン)、何を (パス、必要に応じてファイルハッシュまたは発行元証明書) を解決します。エージェント関連のイベントでは、該当する場合に元のAIエージェントも解決します。
3. フィルターに一致する、関連タイプの適用ポリシーを選びます。
4. 複数のポリシーが一致する場合、具体性とコントロール優先度により1つの結果にまとめます (ポリシーが競合する場合をご参照ください)。
5. AI関連の経路では、ファイルアクセスまたは特権昇格からのベースラインの拒否が、より緩いエージェントポリシーに勝ちます (AI経路の権限上限をご参照ください)。

監視モードのポリシーは監査できますが、適用中の決定を上書きしません。

ポリシーが一致する条件

ポリシーが適用されるのは、スコープが現在のイベントに一致する場合のみです。

• ユーザーまたはグループおよびマシン (または「すべて」)
• アプリケーション (パス、ファイル名パターン、コンテンツハッシュ、および/または発行元証明書)。エージェント型アクセスとエージェント型特権昇格では、アプリケーションスコープは多くの場合エージェントと子プロセスまたは昇格対象に分かれます。
• 任意のスケジュールおよびポリシーのルール
• エージェント型タイプでは、アプリが十分な確信度でAIと認識されたときだけ適用する任意のAI確信度ゲート

パスベースのアプリケーションエントリは、評価対象のプロセス (または対象) のパスに一致します。バイナリを別フォルダへコピーすると別パスになるため、System32のみのポリシーはそのコピーに一致しません。これはパスコレクションでは想定どおりの挙動です。耐久性のある設計では、単一のパス一覧ではなく、後述のレイヤー (より広いアプリケーションスコープ、ハッシュ識別、証明書) を使います。

ファイルアクセス、特権昇格、エージェント型のいずれのポリシータイプでも、一致の考え方は同じです。特定パス、ワイルドカード / すべてのアプリケーション、ハッシュ、証明書は共通の構成要素です。

推奨するレイヤー型アプローチ

LOTLの緩和、昇格制御、ソフトウェアの許可リスト、AIの封じ込めを、狭いポリシー1本に頼らないでください。最小権限の基盤から始め、広いものから具体的なものへポリシーを積み上げ、イベントごとに適切なポリシータイプを使います。

セキュリティポリシーのピラミッド

1

レイヤー1: 最小権限 (基盤)

標準ユーザーが既定でエンドポイント上のローカル管理者権限を持たないよう、最小権限ポリシーを作成します。上位のすべてのレイヤーは、このベースラインを前提とします。

• 持つべきでないユーザーから常設のローカル管理者を取り除き、昇格は既存権限の静かな行使ではなく、特権昇格ポリシーを通じてリクエストされるようにします。
• 起動や昇格イベントの評価より前に効き、実行してよい内容ではなく、ユーザーが最初に持つ権限を形作ります。
• この基盤がないと、レイヤー1〜4は起動と昇格リクエストをゲートしても、すでにローカル管理者を持つユーザーは、標準ユーザー文脈を前提とする多くのコントロール (レジストリ書き込み、サービスインストール、ドライバー読み込みなど) を迂回できます。
• 権限削除後も承認済みの管理作業に経路が残るよう、特権昇格 (昇格イベント上のレイヤー1、2、3) と組み合わせます。
• 作成の指針は最小権限ポリシーをご参照ください。

2

レイヤー2: 既知の場所 (承認)

通常のインストールパス上の高リスクツール (例: {system32}\cmd.exe、System32配下のPowerShell) に対し、承認を要求します (任意でMFAまたは正当な理由を併用)。

• ファイルアクセスで使い、レビューなしの昇格を許さない場合は特権昇格でも使います。
• 実パスの安易な利用をゲートしつつ、承認後の正当な利用は残します。
• 単独では、別フォルダから起動したコピーを止められません。

3

レイヤー3: 広い姿勢 (すべてのアプリケーション)

受け皿としてすべてのアプリケーション (*) 向けの承認ポリシーを作成し、チケット不要とすべき業務承認済みアプリ (および信頼できる発行元) を許可します。

• レイヤーAを外れる再配置、名前変更、予期しない起動または昇格対象を捉えます。
• 未知のソフトウェアをレビュー可能にしたい場合は承認を優先し、承認経路なしで拒否すべき場合にのみハードな拒否を使います。
• 昇格を既定でゲートしたい場合は、特権昇格でも同じ考え方を適用します。

4

レイヤー4: 既知の不正コンテンツ (ハッシュ拒否)

どこに現れても止めなければならない特定の不正バイナリには、ハッシュのみの拒否 (パスを結び付けないSHA256) を使います。

• 内容に一致するため、名前変更や再配置でも拒否されます。
• パス＋ハッシュのメンバーは両方の一致が必要であり、グローバルなコンテンツブロックではありません。「このバイト列をどこでもブロック」にはハッシュのみを優先します。
• ファイルアクセスと特権昇格に適用できます。エージェント経路では、ベースラインの拒否がそのバイナリのエージェント駆動の利用もブロックします。

5

レイヤー5: 信頼できる発行元 (証明書による許可)

信頼するベンダーや製品向けの許可ポリシーで、発行元証明書を使います。

• 署名済みソフトウェアの許可リストに適しています。
• レイヤーBと組み合わせ、それ以外には引き続き承認を要求する (または拒否する) ようにします。

6

レイヤー6: AI固有のコントロール

AIワークフロー向けにエージェント型ポリシーを追加します。ベースラインのレイヤーをこれだけで置き換えないでください。

• エージェント型AI: 誰がAIアプリケーションを起動でき、どのようなコントロールか。
• エージェント型AIアクセス: それらのエージェントが生成してよいもの (シェル、パッケージマネージャー、ブラウザーなど)。エージェント＋子 (サブプロセス) のスコープによる。
• エージェント型AI特権昇格: AIに帰属するプロセスが昇格してよいもの。

ユーザーやエージェントがコピーしたツールの起動や昇格でベースラインの拒否を迂回できないよう、レイヤー1〜4はそのまま残します。エージェント型ポリシーはAI固有のゲートを追加するものであり、広いファイルアクセスと特権昇格の姿勢の必要性をなくすものではありません。

レイヤーの連携

• ユーザーがSystem32のPowerShellを実行 → レイヤーAのファイルアクセス承認が適用され得る。
• ユーザーがプロファイル配下のコピーを実行 → レイヤーAは一致せず、レイヤーBが引き続き承認を要求する (または拒否する)。
• 既知不正のハッシュ → バイト列が現れる場所での起動または昇格で、レイヤーCが拒否する。
• 信頼できるベンダーのアプリ → レイヤーDが許可し、未知のソフトウェアはレイヤーBでゲートされたまま。
• AIエージェントが cmd.exe の生成を試行 → エージェント型アクセスがオペレーター承認を要求する場合あり。その子プロセスに対するベースラインのファイルアクセス拒否があれば、なおブロックする。
• AIエージェントがツールの昇格を試行 → エージェント型特権昇格が適用され、ベースラインの特権昇格拒否がなお勝つ。

ポリシーが競合する場合

ポリシータイプをまたぎ、同じ評価集合で複数の適用ポリシーが一致する場合:

1. より具体的なものが広いものに勝つ: 「すべてのユーザー」よりユーザーまたはグループ固有、「すべてのアプリケーション」よりアプリケーション固有 (証明書、コマンド、サブプロセス一覧でも同様の具体性)。
2. その集合内では、コントロールの順位は: 拒否 → 承認 → MFA / 正当な理由 / オペレーター承認 → 許可。

承認済みアプリ向けの特定許可は、そのアプリについてすべてのアプリケーション向け承認に勝てます。未知のパスは広いレイヤーに当たります。勝った集合内の拒否は、その操作をブロックします。

拒否は、勝った集合内で最優先のコントロールです。具体性はスコープ間 (特定とワイルドカード) の競合解決に使い、すでに拒否を含む集合内では使いません。

AI経路の権限上限

AIに帰属する起動と昇格では:

• ベースラインの拒否 (ファイルアクセスまたは特権昇格) は、より緩いエージェント型AI、エージェント型アクセス、エージェント型特権昇格の結果に常に勝ちます。
• AIエージェントは、同じリソースについてユーザーのベースラインポリシーが拒否する場所で許可を得られません。
• エージェント経路上のベースラインのMFAと正当な理由は、エージェント型のルール (拒否中心の例外) の下で扱われ、AI固有の承認とオペレーターフローはエージェント型ポリシーが担います。

設計上の含意: エージェント型アクセスポリシーに大きく投資する場合でも、強いベースラインの拒否と承認のレイヤーを維持します。

結果

• 許可: 操作は続行します。
• 承認 / MFA / 正当な理由 / オペレーター承認: コントロールが成功するまで操作を待機します。
• 拒否: 操作はブロックされます。
• 一致する適用ポリシーなし: そのポリシーファミリは介在しません。そのイベントにはOSのデフォルトが適用されます。他のポリシータイプは引き続き適用される場合があります。

Keeper EPM自体は暗黙のデフォルト拒否ではありません。未知のソフトウェアや昇格をゲートまたは拒否するには、すべてのアプリケーション向けの承認または拒否ポリシー (レイヤーB) を作成し、信頼するものを許可します。

設計チェックリスト

• ファイルアクセス: 実行制御向けレイヤーA〜D (パス承認、広い承認、ハッシュのみの拒否、証明書による許可)。
• 特権昇格: 昇格イベント向けに同じレイヤー型の考え方。
• エージェント型AI、エージェント型AIアクセス、およびエージェント型AI特権昇格: AIの起動、生成、昇格向けの明示的なポリシー。
• ベースラインのカバー: ユーザーとエージェントが実行してはならないツールを、ベースラインの拒否がなおカバーしていること。
• コンテンツ識別: 「このバイナリをどこでもブロック」にはハッシュのみのメンバーを優先。
• 検証: 実インストールパス、再配置コピー、 (該当する場合) エージェントが生成した子プロセスをテスト。

関連資料

• ファイルアクセスポリシー評価ガイド: ファイルアクセスの一致、ハッシュのみとパス＋ハッシュ、競合例の詳細。
• ポリシータイプ: 適用対象の各タイプとコントロールの概要。
• ポリシーコントロール: 許可、拒否、MFA、正当な理由、承認、およびオペレーター承認。
• ポリシーステータス: 適用、監視、無効の各モード。
• パス変数と保護パスおよびワイルドカード: アプリケーションスコープの共通構成要素。