# ポリシー: 段階的ロールアウトの計画
## 段階的ロールアウトの考え方
段階的ロールアウトでは、コントロールを適用する前に、実運用でのポリシー評価結果 (何がブロックされ、許可され、監視対象として記録されるか) を把握できます。正当な業務ができなくなるリスクを抑えられます。最初に**監視**モードから始めると、挙動のベースラインが取れるため、フィルターやルールを事前に推測で書くより、精度の高いポリシーを用意しやすくなります。適用に進む頃には、管理者も利用者も内容を把握し、結果に自信を持てる状態になっています。
いずれのポリシーを**適用**にする前にも、ポリシーのステータスのライフサイクルを使い、利用者への影響を出さずに挙動だけを検証してください。
* **監視** — ポリシーは評価されログに残りますが、コントロールはかかりません。利用者への影響はありません。挙動のベースラインを取り、フィルターが意図どおりのユーザー、マシン、アプリケーションに一致しているか確認するときに使います。
* **監視&通知** — **監視**と同じですが、操作が観測されている旨をユーザーへ通知します。業務を止めずに周知を進め、のちの**適用**に備えられます。
* **適用** — **許可**、**拒否**、**MFA必須**、**正当な理由が必要**、**承認が必要**といったコントロールが実際にかかります。前段階で挙動を確認してから**適用**に切り替えてください。
## 段階的ロールアウトの例
### ファイルアクセスポリシーの段階的ロールアウト
ファイルアクセスポリシーは、どのアプリケーションがファイルやフォルダを読み取り・書き込み・実行できるかを制御します。影響範囲が広いため、段階的に広げることが重要です。
**フェーズ1 — 監視**では、**すべてのユーザー、すべてのマシン、すべてのアプリケーション**を対象とするファイルアクセスポリシーを作成し、**監視**に設定します。監査ログを確認し、環境全体でどのようなファイルアクセスが起きているか把握します。保護が必要な機微なパスを洗い出し、`{userprofile}` などの変数を含むフォルダ指定が意図どおり解決されているか確認します。
制御したい実行ファイル (PowerShell、コマンドプロンプト、DMG、pkg、ダウンロードやホームフォルダ内のアプリなど) が特定できたら以下のとおり進めます。
* 保護されたパスにない実行ファイルにはワイルドカードを使います。
* 追加のコントロールが必要な機微な領域にはコレクションを作ります。
* ダウンロードやホームフォルダなど管理外領域を制限し承認を求めるポリシーを作ります。これらは承認 (ACK) なしで**監視&通知**にします。
**フェーズ2 — 監視&通知**では、**監視&通知**に切り替え、ACKを求めます。ユーザーにはファイル操作が観測されていること、将来は実行に追加のコントロールが必要になる旨の通知が届きます。**適用**の前に周知を進め、想定外の支障を洗い出せます。
**フェーズ3以降 — 適用**では、**適用**に切り替え、リスクに応じたコントロールを設定します。
* 禁止パスには**拒否**。
* 機微なディレクトリには**正当な理由が必要**。
* 高リスク操作には**承認が必要**。
監視フェーズで観測した内容に合わせてフィルターを調整します。いきなり**拒否**にせず、まず**正当な理由が必要**や**承認が必要**から始めることも検討してください。
{% hint style="info" %}
**注:** 対象範囲の洗い出しでは、まずワイルドカードを使うのことを推奨します。一方、組織の要件によっては、特定の実行ファイルだけを明示的に**許可**したり、厳格に**拒否**したりする方が適切な場合もあります。そのようなケースは、必要に応じて粒度の細かい別ポリシーで定義できます。
{% endhint %}
#### **推奨事項**
* `{userprofile}`、`{systemroot}`、`{programfiles}` などの変数で、クロスプラットフォームで移植しやすいポリシーを書きます。
* すべてを広くブロックするのではなく、認証情報ストアや構成フォルダなど機微なディレクトリを明示的に対象にします。
* 機微なパスにアクセスしそうなグループにコレクションで適用範囲を絞り、組織全体へ広げる前に検証します。
* 機微な内容を含む非実行ファイルは個別に対象にします (例: キー、パスワード、アカウント名を含む構成ファイル。`hosts.inf` や `/etc/hosts` など)。
***
### 特権昇格ポリシーの段階的ロールアウト
特権昇格ポリシーは、ユーザーまたはプロセスが昇格した (管理者) 権限でいつどう実行できるかを決めます。ソフトウェアのインストール、システム設定の変更、管理ツールの実行に直結するため、適用前の検証が不可欠です。
**フェーズ1 — 監視**では、**すべてのユーザー、すべてのマシン、すべてのアプリケーション**を対象とする特権昇格ポリシーを作成し、**監視**に設定します。監査ログで以下の点を把握します。
* どの昇格要求が最も多いか。
* どのアプリケーションが昇格して実行されているか。
* どのユーザーまたはマシンで活動が集中しているか。
**フェーズ2 — 監視&通知**では、**監視&通知**に切り替えます。昇格要求を行ったユーザーには、操作が追跡されている旨の通知が出ます。利用者への周知や、適用時にコントロールが必要になる要求の量を見積もる機会になります。
**フェーズ3以降 — 適用**では、**適用**に切り替え、操作のリスクに応じたコントロールを設定します。よくある最初の構成例は以下のとおりです。
* 既知で安全かつ業務に不可欠なアプリケーションには**許可**。
* 頻度が低い、または監査証跡が必要な昇格要求には**正当な理由が必要**。
* 高リスクや例外的な昇格には**承認が必要**。
* 機微性の高い管理ツールには**MFA必須**または**承認が必要 + MFA必須**。
#### **推奨事項**
* より広い適用の前に、コレクションで高リスクなユーザー層 (開発者、IT担当者など) を先に対象にします。
* 広い**拒否**を適用する前に、既知で承認済みのアプリケーション向けの**許可**ポリシーを用意します。正当な業務の妨げを減らせます。
* 特権昇格ポリシーと最小権限ポリシーを組み合わせ、管理者権限の統制を一体で運用します。
***
### コマンドラインポリシーの段階的ロールアウト
コマンドラインポリシーは、ユーザーが実行できるコマンド、スクリプト、シェル操作を制御します。コマンドラインは攻撃経路になりやすい一方、正当な業務でも欠かせないため、適用前にベースラインを慎重に取る必要があります。
**フェーズ1 — 監視**では、**すべてのユーザー、すべてのマシン、すべてのシェルアプリケーション** (例: `cmd.exe`、`powershell.exe`、`pwsh.exe`、`bash`) を対象とするコマンドラインポリシーを作成し、**監視**に設定します。監査ログで以下の点を確認します。
* どのコマンドが、誰が、どのマシンから実行しているか。
* `format`、`rm -rf`、`net user`、`reg`、スクリプト実行パターンなど、高リスクになりうるコマンド。
**フェーズ2 — 適用**では、**適用**に切り替え、コントロールを設定します。よくある構成例は以下のとおりです。
* 既知の危険なコマンド (破壊的なファイル操作、ユーザーアカウント操作、承認されたフロー外のレジストリ変更など) には**拒否**。
* ときどき正当だが監査証跡が欲しいコマンドには**正当な理由が必要**。
* 上司またはセキュリティチームの明示的な許可が必要なコマンドには**承認が必要**。
**ポリシー適用範囲の理解**
コマンドラインポリシーを書く前に、適用範囲がどう決まるかを押さえておいてください。
* `Extensions` セクションがないポリシーは **昇格時のみ対象のワイルドカードポリシー** です。`sudo` のワイルドカード指定に相当する扱いで、昇格したコマンドすべてに適用されます。
* **昇格していないコマンド** にポリシーを当てるには、`Extensions` に `"IsElevated": false` を明示的に含める必要があります。
* `Extensions` に `AllowCommands` セクションがないポリシーは **ワイルドカードのコマンドラインポリシー** で、すべてのコマンドに適用されます。`AllowCommands` にコマンドを列挙すると、列挙したコマンドにだけ適用されます。
* ワイルドカードより具体的なポリシーが優先されます。標準のポリシー評価ルールと同じです。
* コマンドが `AllowCommands` に **許可** コントロールで載っていれば、ワイルドカード側が **MFA必須** などを要求していても許可されます。
* 逆に、ある具体的なポリシーが **正当な理由が必要** を求めている場合、同じコマンド用の別の具体的ポリシーが **許可** でも、**正当な理由が必要** の要件は適用されます。
**推奨事項**
* 定義済みポリシーをベースラインにしてから調整します。
* いきなりすべてをホワイトリスト化するのではなく、リスクの高いコマンドだけを列挙した**拒否**リストから始めます。
* 広い制御に進む前に、初期のコマンドラインポリシーは昇格コンテキスト (`sudo`、`runas`、昇格シェルなど) に適用範囲を絞ります。
* 1つのシェルアプリケーション内で、`AllowCommands` と `DenyCommands` を組み合わせて細かく定義します。
* ポリシーは具体的に保ちます。コマンドパターンに広すぎるワイルドカードを使うと意図しない一致が起きます。コマンドパターンを書く前にワイルドカードのリファレンスを確認してください。
***
### 最小権限ポリシーの段階的ロールアウト
最小権限ポリシーは、ユーザーから恒常的な管理者権限を外し、横移動や権限濫用の攻撃面を小さくします。端末上でできることが変わるタイプのため、混乱の可能性が最も高く、展開前の計画が最も重要です。
**フェーズ1 — 適用**に移る前に、以下を確定させます。
* 除外リスト (IT担当、ブレークグラス用アカウント、恒常的な管理者が必要なサービスアカウントなど)。
* 降格後にユーザーが必要になりうる操作 (承認済みソフトのインストール、管理ツールの実行など) に対する特権昇格ポリシーがすでに用意され、試験済みであること。
* 想定外の不具合が起きた利用者を救済するヘルプデスク経路があること。
上記が確認できたら**適用**に切り替えます。ポリシーは一致したユーザーからローカル管理者権限の除去を始めます。
#### **推奨事項**
* 最小権限を**適用**する前に、必ず特権昇格ポリシーを構成します。昇格の道を用意せずに管理者権限だけを外すと、すぐに支障が生じます。
* サービスアカウント、ローカルIT管理者、恒常的な管理者権限に業務上の根拠があるユーザーを除外で守ります。
* 組織全体に広げる前に、小さく重要度の低い配布グループでパイロット適用し、昇格の流れが問題ないことを確認してから範囲を広げます。
* 部門やマシングループ単位での展開も検討します。管理者権限への依存が比較的少ないユーザーから始めます。
* 技術設定だけでなく変更管理として扱います。利用者への説明と上長の合意は、ポリシー構成と同じくらい重要です。
---
# 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/jp/keeperpam/endpoint-privilege-manager/policies/policy-phased-rollout-planning.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.