> For the complete documentation index, see [llms.txt](https://docs.keeper.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.keeper.io/keeperpam/jp/endpoint-privilege-manager/policies/policy-phased-rollout-planning.md).
# ポリシー: 段階的ロールアウトの計画
## 段階的ロールアウトの考え方
段階的ロールアウトでは、コントロールを適用する前に、実運用でのポリシー評価結果 (ブロック、許可、監視対象としての記録) を把握できます。正当な業務ができなくなるリスクを抑えられます。最初に**監視**モードから始めると、挙動のベースラインが取れるため、フィルターやルールを事前に推測で書くより、精度の高いポリシーを用意しやすくなります。**適用**に進む頃には、管理者も利用者も内容を把握し、結果に自信を持てる状態になっています。
いずれのポリシーを**適用**にする前にも、ポリシーのステータスのライフサイクルを使い、利用者への影響を出さずに挙動だけを検証してください。
* **監視:** ポリシーは評価しログに残しますが、コントロールはかかりません。利用者への影響はありません。挙動のベースラインを取り、フィルターが意図どおりのユーザー、マシン、アプリケーションに一致しているか確認するときに使います。
* **監視&通知:** **監視**と同じですが、操作を観測している旨をユーザーへ通知します。業務を止めずに周知を進め、のちの**適用**に備えられます。
* **適用:** **自動許可**、**自動拒否**、**MFA**、**正当な理由**、**管理者承認**といったコントロールが実際にかかります。前段階で挙動を確認してから**適用**に切り替えてください。
***
## 段階的ロールアウトの例
### エージェンティックAIポリシーの段階的ロールアウト
エージェンティックAIポリシーは、AIエージェントや自律プロセスをエンドポイント上でどう識別、統制、監査するかを制御します。エージェンティックなワークロードは動的に起動し、人間が直接操作していなくても機微なリソースに触れることがあるため、**適用**前に挙動のベースラインを取ることが不可欠です。
{% stepper %}
{% step %}
#### フェーズ1 - 監視
**すべてのユーザー**、**すべてのマシン**、**すべてのエージェンティックAIコレクション**を対象とするエージェンティックAIポリシーを作成し、**監視**モードに設定します。監査ログで以下を確認します。
* どのAIエージェントが、どのマシン上で、どのユーザーコンテキストで実行されているか。
* エージェントが行っている操作 (ファイルアクセス、コマンド実行、ネットワーク呼び出し、特権昇格の試行)。
* 承認済みワークフロー外で現れる、管理外または想定外のエージェントプロセス。
{% endstep %}
{% step %}
#### フェーズ2 - **監視&通知**
**監視&通知**に切り替えます。エージェンティックなワークロードを実行しているユーザーには、エージェントのアクティビティを追跡している旨の通知が届きます。今後の統制変更を周知し、**適用**時にコントロールが必要になるエージェント活動の量を見積もる機会になります。
{% endstep %}
{% step %}
#### フェーズ3以降 - **適用**
**適用**に切り替え、リスクに応じたコントロールを設定します。
* 承認済みのエージェントランタイムや既知の安全な自律ワークフローには**自動許可**。
* 管理外または未承認のエージェントプロセスには**自動拒否**。
* ときどき正当だが監査証跡が必要なエージェント操作には**正当な理由**。
* 昇格、システム状態の変更、機微なパスへのアクセスなど、高リスクなエージェント操作には**管理者承認**。
* 続行前に監督アカウントのステップアップ認証が必要なエージェント操作には**MFA**。
{% endstep %}
{% endstepper %}
{% hint style="info" %}
エージェンティックAIポリシーは、エージェンティックアクセスポリシーやエージェンティック特権昇格ポリシーと重なることがよくあります。単独ではなく一体で計画し、コントロールを一貫して重ねてください。
{% endhint %}
#### **推奨事項**
* ポリシーを書く前に、承認済みAIエージェントと想定される挙動を棚卸ししてください。ベースラインがないと、管理対象と管理外の活動を区別しにくくなります。
* 最初の**適用**は、エージェンティックワークロードを実行するユーザーとチーム (例: エンジニアリング、データサイエンス) にコレクションで適用範囲を絞り、組織全体へ広げる前に検証します。
* エージェンティックAIポリシーに対応するアクセスポリシーと特権昇格ポリシーを組み合わせ、エージェントが到達できる範囲と実行できる操作を包括的にカバーします。
***
### エージェンティックアクセスポリシーの段階的ロールアウト
エージェンティックアクセスポリシーは、AIエージェントが到達できるリソース (ファイル、パス、ネットワークエンドポイント ※Keeper EPM v2.2で対応予定、アプリケーション) を制御します。エージェントはマシン速度で、想定外の組み合わせでリソースにアクセスすることがあるため、**適用**前に実際のアクセスパターンを監視することが重要です。
{% stepper %}
{% step %}
#### フェーズ1 - 監視
**すべてのユーザー**、**すべてのアプリケーション**、**すべてのマシン**、**すべてのエージェンティックAIコレクション**を対象とするエージェンティックアクセスポリシーを作成し、**監視**モードに設定します。監査ログで以下を確認します。
* エージェントが到達しているリソース (機微なディレクトリ、認証情報ストア、構成ファイル、外部エンドポイント)。
* 正当なワークフローを示すアクセスパターンと、想定外または過剰な到達の区別。
* 頻繁にアクセスされるが到達すべきでないリソース (**自動拒否**や**管理者承認**コントロールの候補)。
{% endstep %}
{% step %}
#### フェーズ2 - **監視&通知**
**監視&通知**に切り替えます。追跡対象リソースにアクセスしているエージェントを持つユーザーには、情報通知が届きます。このフェーズで、今後のアクセス境界を周知し、**適用**前に想定外の支障を洗い出します。
{% endstep %}
{% step %}
#### フェーズ3以降 - **適用**
**適用**に切り替え、リスクに応じたコントロールを設定します。
* エージェントアクセスが承認されているリソースには**自動許可**。
* エージェントが到達してはならない機微なパス (認証情報ストア、セキュリティツール、システムディレクトリ) には**自動拒否**。
* ときどき正当だが監査証跡が必要なリソースアクセスには**正当な理由**。
* エージェントの要求を実行前にエンドユーザーが承認する必要があるリソースアクセスには**エンドユーザー承認** (エージェントのアクセス試行は、エンドユーザーが明示的に許可するまで一時停止)。
* 監督アカウントではなく、上司またはセキュリティチームによるレビューが必要な高リスクなリソースアクセスには**管理者承認**。
* エージェントが続行する前に、監督アカウントのステップアップ認証が必要なリソースアクセスには**MFA**。
{% endstep %}
{% endstepper %}
{% hint style="info" %}
`{userprofile}`、`{systemroot}`、`{programfiles}` などの[パス変数](/keeperpam/jp/endpoint-privilege-manager/policies/path-variables.md)を使うと、移植しやすいクロスプラットフォームのエージェンティックアクセスポリシーを書けます。
{% endhint %}
#### **推奨事項**
* 広い**自動拒否**を**適用**する前に、承認済みワークフローでエージェントが必要とするリソースの許可リストを明確に定義します。
* 認証情報ストア、秘密情報を含む構成ファイル、セキュリティツールを明示的に対象にします。エージェントの到達から保護すべき価値が最も高いリソースです。
* 最初はエージェンティックワークロードを実行するチームにコレクションで適用範囲を絞り、その後組織全体へ広げます。
***
### エージェンティック特権昇格ポリシーの段階的ロールアウト
エージェンティック特権昇格ポリシーは、AIエージェントがいつ、どのように昇格 (管理者) 権限で実行できるかを制御します。昇格したエージェント操作は、人間が直接監督していなくてもマシン速度でシステム状態を変えられるため、**適用**前の慎重なベースライン取得が重要です。ヒューマンインザループを実現するため、エージェンティック特権昇格ポリシーでは**エンドユーザー承認**コントロールの導入を推奨します。
{% stepper %}
{% step %}
#### フェーズ1 - 監視
**すべてのユーザー**、**すべてのアプリケーション**、**すべてのマシン**、**すべてのエージェンティックAIコレクション**を対象とするエージェンティック特権昇格ポリシーを作成し、**監視**モードに設定します。監査ログで以下を確認します。
* どのエージェントプロセスが昇格を要求しているか、その頻度。
* 昇格後にエージェントが行っている操作 (インストール、構成変更、サービス制御、レジストリ編集)。
* 正当な自動化と異常な挙動を区別できる昇格パターン。
{% endstep %}
{% step %}
#### フェーズ2 - **監視&通知**
**監視&通知**に切り替えます。エージェントが昇格を要求しているユーザーには、昇格を追跡している旨の通知が届きます。今後のコントロールを周知し、**適用**時にレビューが必要になる昇格要求の量を見積もる機会になります。
{% endstep %}
{% step %}
#### フェーズ3以降 - **適用**
**適用**に切り替え、各操作のリスクレベルに応じたコントロールを設定します。
* 既知で安全な承認済み昇格ワークフロー (例: 信頼済みエージェントによる定期パッチ適用) には**自動許可**。
* 明示的に禁止する昇格エージェント操作には**自動拒否**。
* まれだが監査証跡が必要な昇格要求には**正当な理由**。
* エージェントの昇格を実行前にエンドユーザーが承認する必要がある場合には**エンドユーザー承認** (エージェントの昇格試行は、エンドユーザーが明示的に許可するまで一時停止)。
* 監督アカウントではなく、上司またはセキュリティチームによるレビューが必要な、高リスクまたは異例の昇格操作には**管理者承認**。
* 機微性の高い管理操作を試みるエージェントには**MFA**または**管理者承認 + MFA**。
{% endstep %}
{% endstepper %}
{% hint style="info" %}
エージェンティック特権昇格は、[最小特権](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/least-privilege-policy-type.md)ポリシーと組み合わせてください。エージェントが恒常的な管理者権限を持たず、昇格を明示的に要求する構成にします。
{% endhint %}
#### **推奨事項**
* ユーザー昇格よりエージェント昇格を厳しく扱ってください。エージェントは人間より速く、大量に操作できるため、許可設定のミスによる影響範囲が大きくなります。
* 広い**自動拒否**を**適用**する前に、既知で承認済みのエージェントワークフロー向けの**自動許可**ポリシーを用意します。
* エージェンティック特権昇格ポリシーとエージェンティックアクセスポリシーを組み合わせ、エージェントが**何を**、**どこで**実行できるかの両方を制御します。
***
### コマンドラインポリシーの段階的ロールアウト
コマンドラインポリシーは、ユーザーが実行できるコマンド、スクリプト、シェル操作を制御します。コマンドラインは攻撃経路になりやすい一方、正当な業務でも欠かせないため、**適用**前にベースラインを慎重に取る必要があります。
{% stepper %}
{% step %}
#### フェーズ1 - 監視
**すべてのユーザー**、**すべてのアプリケーション** (例: `cmd.exe`、`powershell.exe`、`pwsh.exe` など)、**すべてのマシンコレクション**を対象とするコマンドラインポリシーを作成し、**監視**モードに設定します。監査ログで以下を確認します。
* どのコマンドが、誰が、どのマシンから実行しているか。
* `format`、`rm -rf`、`net user`、`reg`、スクリプト実行パターンなど、高リスクになりうるコマンド。
{% endstep %}
{% step %}
#### フェーズ2 - 監視&通知
**適用**に切り替え、コントロールを設定します。よくある構成例は以下のとおりです。
* 既知の危険なコマンド (破壊的なファイル操作、ユーザーアカウント操作、承認されたフロー外のレジストリ変更など) には**自動拒否**。
* ときどき正当だが監査証跡が欲しいコマンドには**正当な理由**。
* 上司またはセキュリティチームの明示的な許可が必要なコマンドには**管理者承認**。
{% endstep %}
{% step %}
#### フェーズ3以降 - 適用
**適用**に切り替え、コントロールを設定します。よくある構成例は以下のとおりです。
* 対象ユーザー向けに明示的に承認されたコマンドには**自動許可** (例: 安全と分かっている管理ユーティリティ)。
* 既知の危険なコマンド (破壊的なファイル操作、ユーザーアカウント操作、承認されたフロー外のレジストリ変更など) には**自動拒否**。
* ときどき正当だが監査証跡が必要なコマンドには**正当な理由**。
* 上司またはセキュリティチームの明示的な許可が必要なコマンドには**管理者承認**。
* ステップアップ認証が必要な機微性の高いコマンドには**MFA**または**管理者承認 + MFA**。
**ポリシー適用範囲の理解**
コマンドラインポリシーを書く前に、適用範囲がどう決まるかを押さえておいてください。
* `Extensions` セクションがないポリシーは、昇格時のみ対象のワイルドカードポリシーです。`sudo` のワイルドカード指定に相当する扱いで、昇格したコマンドすべてに適用します。
* **昇格していないコマンド**にポリシーを当てるには、`Extensions` に `"IsElevated": false` を明示的に含める必要があります。
* `Extensions` に `AllowCommands` セクションがないポリシーは、ワイルドカードのコマンドラインポリシーで、すべてのコマンドに適用します。`AllowCommands` にコマンドを列挙すると、列挙したコマンドにだけ適用します。
具体的なポリシーはワイルドカードより優先されます。標準のポリシー評価ルールと同じです。
* コマンドが `AllowCommands` に**自動許可**コントロールで載っていれば、ワイルドカード側が**MFA**などを要求していても許可されます。
* 逆に、特定のポリシーで**正当な理由**が要求されている場合、同じコマンド向けの別の特定ポリシーが**自動許可**になっていても、そのコントロールが優先されます。
{% endstep %}
{% endstepper %}
{% hint style="info" %}
コマンドラインポリシーは、親シェルプロセスではなく、実行されるコマンドに対して評価します。1つのシェルセッションでも、ユーザーが実行するコマンドごとに異なるポリシーが当てはまることがあります。
{% endhint %}
#### **推奨事項**
* 定義済みポリシーをベースラインとして始め、内容を見直しながら調整します。
* いきなりすべてをホワイトリスト化するのではなく、リスクの高いコマンドだけを列挙した**自動拒否**リストから始めます。
* 広い制御に進む前に、初期のコマンドラインポリシーは昇格コンテキスト (`sudo`、`runas`、昇格シェルなど) に適用範囲を絞ります。
* 1つのシェルアプリケーション内で、`AllowCommands` と `DenyCommands` を組み合わせて細かく定義します。
* ポリシーは具体的に保ちます。コマンドパターンに広すぎるワイルドカードを使うと意図しない一致が起きます。コマンドパターンを書く前にワイルドカードのリファレンスを確認してください。
***
### ファイルアクセスポリシーの段階的ロールアウト
ファイルアクセスポリシーは、どのアプリケーションがファイルやフォルダを読み取り・書き込み・実行できるかを制御します。影響範囲が広いため、段階的に広げることが重要です。
{% stepper %}
{% step %}
#### フェーズ1 - 監視
**すべてのユーザー**、**すべてのアプリケーション**、**すべてのマシンコレクション**を対象とするファイルアクセスポリシーを作成し、**監視**モードに設定します。監査ログを確認し、環境全体でどのようなファイルアクセスが起きているか把握します。保護が必要な機微なパスを洗い出し、`{userprofile}` などの変数を含むフォルダ指定が意図どおり解決されるか確認します。
制御したい実行ファイル (PowerShell、コマンドプロンプト、DMG、pkg、ダウンロードやホームフォルダ内のアプリなど) が特定できたら以下のとおり進めます。
* 保護されたパスにない実行ファイルにはワイルドカードを使います。
* 追加のコントロールが必要な機微な領域にはコレクションを作ります。
* ダウンロードやホームフォルダなど管理外領域を制限し承認を求めるポリシーを作ります。これらは承認 (ACK) なしで**監視&通知**にします。
{% endstep %}
{% step %}
#### フェーズ2 - **監視&通知**
**監視&通知**に切り替え、ACKを求めます。ユーザーにはファイル操作を観測していること、将来は実行に追加のコントロールが必要になる旨の通知が届きます。**適用**の前に周知を進め、想定外の支障を洗い出せます。
{% endstep %}
{% step %}
#### フェーズ3以降 - **適用**
**適用**に切り替え、リスクに応じたコントロールを設定します。
* アクセスが明示的に承認されているパスとアプリケーションには**自動許可**。
* 禁止パスには**自動拒否**。
* 機微なディレクトリには**正当な理由**。
* 高リスク操作には**管理者承認**。
* ステップアップ認証が必要な機微性の高いパス上のファイル操作には**MFA**。
監視フェーズで観測した内容に合わせてフィルターを調整します。いきなり厳格な**自動拒否**にせず、まず**正当な理由**や**管理者承認**から始めることも検討してください。
ワイルドカードは対象範囲の洗い出しの出発点として推奨しますが、組織の要件によっては特定の実行ファイルだけを明示的に**自動許可**または厳格な**自動拒否**にする方が適切な場合もあります。必要に応じて粒度の細かい別ポリシーで定義できます。
{% endstep %}
{% endstepper %}
{% hint style="info" %}
ワイルドカードは対象範囲の洗い出しの出発点として推奨しますが、組織の要件によっては特定の実行ファイルだけを明示的に許可または厳格に拒否する方が適切な場合もあります。必要に応じて粒度の細かい別ポリシーで定義できます。
{% endhint %}
#### **推奨事項**
* `{userprofile}`、`{systemroot}`、`{programfiles}` などの変数で、クロスプラットフォームで移植しやすいポリシーを書きます。
* すべてを広くブロックするのではなく、認証情報ストアや構成フォルダなど機微なディレクトリを明示的に対象にします。
* 機微なパスにアクセスしそうなグループにコレクションで適用範囲を絞り、組織全体へ広げる前に検証します。
* 機微な内容を含む非実行ファイルは個別に対象にします (例: キー、パスワード、アカウント名を含む構成ファイル。`hosts.inf` や `/etc/hosts` など)。
***
### 最小権限ポリシーの段階的ロールアウト
最小権限ポリシーは、ユーザーから恒常的な管理者権限を外し、横移動や権限濫用の攻撃面を小さくします。端末上でできることが変わるタイプのため、混乱の可能性が最も高く、展開前の計画が最も重要です。
{% stepper %}
{% step %}
#### フェーズ1 - 監視
最小権限ポリシーを作成し、**監視**モードに設定します。監査ログで以下を確認します。
* どのユーザーが恒常的な管理者権限を持っているか、その権限が実際にどれだけ使われているか。
* どのアプリケーションとワークフローが、恒常的な管理者権限に依存しているか。
* 管理操作を頻繁に行うユーザーとマシン (最小権限を安全に**適用**する前に、例外処理や特権昇格ポリシーの組み合わせが必要になりやすい対象)。
{% endstep %}
{% step %}
#### フェーズ2 - **監視&通知**
**監視&通知**に切り替えます。降格の対象となるユーザーには、恒常的な管理者権限を見直し、今後削除する旨の情報通知が届きます。このフェーズで変更内容を明確に周知し、影響を受けるワークフローに関するフィードバックを集め、**適用**前の最終的なギャップを洗い出します。
{% endstep %}
{% step %}
#### フェーズ3以降 - **適用**
**適用**に切り替えます。最小権限ポリシー自体では操作ごとのコントロールは設定できません。**適用**すると、対象ユーザーの恒常的な管理者権限を外します。**自動許可**、**自動拒否**、**正当な理由**、**管理者承認**、**エンドユーザー承認**、**MFA** は最小権限ポリシーでは構成しません。
降格後の特定の管理操作を制御するには、1つ以上の[特権昇格](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/privilege-elevation-policy-type.md)ポリシーを重ねます。個別の昇格要求に対する**自動許可**、**自動拒否**、**正当な理由**、**管理者承認**、**MFA** は特権昇格ポリシー側で設定します。
{% endstep %}
{% endstepper %}
{% hint style="info" %}
最小権限は、[特権昇格](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/privilege-elevation-policy-type.md)ポリシーと組み合わせたときに最も効果を発揮します。昇格の道を用意せずに管理者権限だけを外すと、正当なワークフローが壊れ、問い合わせが増えます。
{% endhint %}
#### **推奨事項**
* パワーユーザー、開発者、IT担当より、リスクの低い標準ユーザーから先に最小権限を**適用**します。
* **適用**前に特権昇格ポリシーを組み合わせ、正当な管理操作のための承認済み経路を用意します。
* 組織全体を一度に切り替えるのではなく、部門、チーム、マシングループ単位でコレクションを使い段階的に**適用**します。
* 十分に前もって周知してください。最小権限は、ユーザーが最もすぐに気づくポリシータイプです。
***
### 特権昇格ポリシーの段階的ロールアウト
特権昇格ポリシーは、ユーザーまたはプロセスが昇格 (管理者) 権限でいつどう実行できるかを決めます。ソフトウェアのインストール、システム設定の変更、管理ツールの実行に直結するため、**適用**前の検証が不可欠です。
{% stepper %}
{% step %}
#### フェーズ1 - 監視
**すべてのユーザー**、**すべてのアプリケーション**、**すべてのマシンコレクション**を対象とする特権昇格ポリシーを作成し、**監視**モードに設定します。監査ログで以下を確認します。
* どの昇格要求が最も多いか。
* どのアプリケーションが昇格して実行されているか。
* どのユーザーまたはマシンで活動が集中しているか。
{% endstep %}
{% step %}
#### フェーズ2 - 監視&通知
**監視&通知**に切り替えます。昇格要求を行ったユーザーには、操作を追跡している旨の通知が出ます。利用者への周知や、**適用**時にコントロールが必要になる要求の量を見積もる機会になります。
{% endstep %}
{% step %}
#### フェーズ3以降 - 適用
**適用**に切り替え、操作のリスクレベルに応じたコントロールを設定します。よくある最初の構成例は以下のとおりです。
* 既知で安全かつ業務に不可欠なアプリケーションには**自動許可**。
* いかなる状況でも昇格してはならないアプリケーションには**自動拒否**。
* 頻度が低い、または監査証跡が必要な昇格要求には**正当な理由**。
* 高リスクや例外的な昇格には**管理者承認**。
* 機微性の高い管理ツールには**MFA**または**管理者承認 + MFA**。
{% endstep %}
{% endstepper %}
{% hint style="info" %}
特権昇格ポリシーは、ユーザーのセッションではなく、昇格対象のアプリケーションに対して評価します。同じユーザーでも、昇格しようとするアプリケーションによって受けるコントロールは異なります。
{% endhint %}
#### **推奨事項**
* より広い**適用**の前に、コレクションで高リスクなユーザー層 (例: 開発者、IT担当者) を先に対象にします。
* 広い**自動拒否**を**適用**する前に、既知で承認済みのアプリケーション向けの**自動許可**ポリシーを用意します。正当な業務の妨げを減らせます。
* 特権昇格ポリシーと最小権限ポリシーを組み合わせ、管理者権限の統制を一体で運用します。
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## 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, and the optional `goal` query parameter:
```
GET https://docs.keeper.io/keeperpam/jp/endpoint-privilege-manager/policies/policy-phased-rollout-planning.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.