> 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/deployment/recommended-deployment-phases.md).

# 推奨デプロイフェーズ

<figure><img src="/files/4rsGp348SzhZwb6ffsxc" alt=""><figcaption></figcaption></figure>

特権昇格および委任管理 (PEDM) を成功させるには、セキュリティと業務継続のバランスを取った段階的なアプローチが必要です。本ガイドでは、組織全体にKeeperエンドポイント特権マネージャーを導入する際の推奨戦略を取り扱います。

## フェーズ1: **本番に近いテスト環境での検証** <a href="#phase-1-validate-in-a-production-like-test-environment" id="phase-1-validate-in-a-production-like-test-environment"></a>

KEPMを広く展開する前に、**本番エンドポイントに近い少数のテストマシン** (同一OSバージョン、デバイスタイプ、セキュリティベースライン、インストール済みアプリケーション) へデプロイしてください。このパイロットで、KEPMが問題なくインストールできること、ポリシー適用が想定どおりに動くこと、**既存のセキュリティツールや管理ツール** (EDR/XDRエージェント、アンチウイルス、アプリケーション制御、DLP、VPNクライアント、デバイス管理ユーティリティなど) との**競合がない**ことを確認します。

多くの環境では、KEPMコンポーネントが正常に動作するよう、他のセキュリティツール側で**除外/許可リスト**を設定する必要があります (フォルダ、プロセス、ネットワーク、スクリプト実行の除外など)。このフェーズで必要な除外を特定して文書化し、KEPMを追加エンドポイントへ広げる**前に**、既存のセキュリティ管理基盤を通じて標準化して配布してください。

## フェーズ2: 基盤構築と検出 <a href="#phase-2-foundation-and-discovery" id="phase-2-foundation-and-discovery"></a>

### 監視モードから開始 <a href="#start-with-monitor-mode" id="start-with-monitor-mode"></a>

デプロイは、すべてのポリシーを**監視**モードに設定することから始めます。ユーザーの業務を中断せずに、特権利用のベースラインを把握できます。

* パイロットグループ (環境の10〜20%) のエンドポイントにKeeperエージェントをデプロイする
* 初期ポリシーはすべて「監視」モードにし、特権昇格のパターンを観測する
* 1〜2週間、十分なデータ収集の時間を確保する
* 開発者ワークステーション、標準ユーザーマシン、サーバーなど、多様なエンドポイントタイプを対象にする

<figure><img src="/files/FO9t6ROG8DwuQYFeGPhn" alt="" width="563"><figcaption></figcaption></figure>

### 特権利用パターンの分析 <a href="#analyze-privilege-usage-patterns" id="analyze-privilege-usage-patterns"></a>

監視フェーズでは、ダッシュボードで以下を確認します。

* **頻繁な昇格要求:** 管理者権限を定期的に必要とするアプリケーションとプロセス
* **ユーザー行動パターン:** どのユーザーがいつ昇格アクセスを必要とするか
* **正当な業務プロセス:** 正当な業務目的で管理者権限が必要な操作
* **異常なアクティビティ:** セキュリティリスクを示す可能性のある、通常と異なる特権要求

<figure><img src="/files/PEUyp8Snpnuj4J4XLu2M" alt="" width="563"><figcaption></figcaption></figure>

### コレクションと組織構成の整備 <a href="#establish-collections-and-organizational-structure" id="establish-collections-and-organizational-structure"></a>

分析結果に基づき、意味のあるコレクションを作成します。

* **ユーザーグループ:** ロール別 (開発者、IT担当、標準ユーザー、経営層)
* **マシンコレクション:** 用途別 (開発ワークステーション、サーバー、キオスク)
* **アプリケーションコレクション:** 業務クリティカルなアプリと管理ツールを分類
* **カスタムコレクション:** 組織固有の要件向けのグループ

## フェーズ3: 段階的なポリシー実装 <a href="#phase-3-gradual-policy-implementation" id="phase-3-gradual-policy-implementation"></a>

### 監視&通知への移行 <a href="#begin-with-monitor-notify" id="begin-with-monitor-notify"></a>

重要なポリシーを監視から**監視&通知**モードへ移行します。

* 重要度の低いアプリケーションとユーザーグループから始める
* 監視中に一貫したパターンが確認できたポリシーから着手する
* 適用を始める前に、ユーザーが通知に慣れる時間を確保する
* 影響を受けるユーザーへ、変更内容を事前に周知する

### 基本コントロールの導入 <a href="#implement-basic-controls" id="implement-basic-controls"></a>

ユーザー負担を抑えつつ、基礎的なセキュリティ対策を導入します。

* **正当な理由の要求:** 標準的な昇格要求から、シンプルな正当な理由ポリシーを適用する
* **時間帯による制限:** 業務時間外はより厳しいポリシーを適用する
* **アプリケーション別ポリシー:** 高リスクまたは不要な管理ツールへのアクセスを制御する

### 承認ワークフローのテスト <a href="#test-approval-workflows" id="test-approval-workflows"></a>

機微な操作向けに、承認ベースのポリシーを導入します。

* 信頼できる少数の承認者グループから始める
* まず重要度の低いアプリケーションで承認ワークフローを試す
* 明確なエスカレーション手順と期限を定める
* 業務クリティカルな承認について24時間365日体制を整える

## フェーズ4: 適用と最小権限 <a href="#phase-4-enforcement-and-least-privilege" id="phase-4-enforcement-and-least-privilege"></a>

### 最小権限の段階的導入 <a href="#implement-least-privilege-gradually" id="implement-least-privilege-gradually"></a>

コアとなる最小権限モデルを段階的に展開します。

* **パイロットグループ:** ITまたはセキュリティチームから10〜20名のボランティアで開始
* **低リスクユーザー:** 管理者権限の必要性が少ないユーザーへ拡大
* **標準ユーザー:** 一般従業員からローカル管理者権限を外す
* **パワーユーザー:** 開発者やIT担当と協力し、個別の要件を調整する

### MFA要件の展開 <a href="#deploy-mfa-requirements" id="deploy-mfa-requirements"></a>

機微な操作に多要素認証を追加します。

* 高リスクなアプリケーションとシステム変更を優先してMFAを要求する
* ユーザーが適切な2FA方式でKeeperボルトに登録済みであることを確認する
* 設定手順とサポートリソースを明確に提供する
* 時間外や緊急時のMFAワークフローをテストする

### 高度なポリシーコントロールの整備 <a href="#establish-advanced-policy-controls" id="establish-advanced-policy-controls"></a>

より高度なポリシーの組み合わせを導入します。

* **多層ポリシー:** 同一リソースに複数ポリシーを重ね、多層防御を実現する
* **条件付きアクセス:** 日時範囲でセキュリティレベルを変える
* **アプリケーション別コントロール:** アプリケーションの挙動に合わせてポリシーを調整する
* **ファイルアクセス制御:** 機微な実行ファイルとシステムファイルを保護する

## フェーズ5: 最適化と本番展開 <a href="#phase-5-optimization-and-full-deployment" id="phase-5-optimization-and-full-deployment"></a>

### 環境全体へのスケール <a href="#scale-to-full-environment" id="scale-to-full-environment"></a>

エンドポイント全体へ展開を広げます。

* 週100〜200台ずつバッチでデプロイする
* システム性能とユーザーフィードバックを監視する
* 運用要件に合わせてポリシーを調整する
* 重大事態向けのブレークグラス手順を維持する

### 継続的な監視と改善 <a href="#continuous-monitoring-and-refinement" id="continuous-monitoring-and-refinement"></a>

継続的な運用体制を整えます。

* **週次レビュー:** 昇格要求とポリシーの有効性を分析する
* **月次評価:** 業務変化に合わせてポリシーを見直し調整する
* **四半期監査:** 特権管理の効果を包括的に評価する
* **年次ポリシーレビュー:** 組織の変化を反映してポリシーを更新する

***

## 成功のための重要要素 <a href="#key-success-factors" id="key-success-factors"></a>

### 周知とトレーニング <a href="#communication-and-training" id="communication-and-training"></a>

* 新しいプロセスと期待事項を明確に文書化する
* 新しい特権モデルについてエンドユーザー向けトレーニングを実施する
* 特権関連の問い合わせ向けにヘルプデスク手順を整備する
* 一般的な昇格要求向けのセルフサービスリソースを用意する

### 技術面の考慮事項 <a href="#technical-considerations" id="technical-considerations"></a>

* エージェント通信のためのネットワーク接続を確保する
* オフライン時のポリシー評価能力を計画する
* セキュリティイベント向けのログとアラートを整備する
* 重要システムアクセス向けのバックアップ手順を整備する

### ポリシー設計のベストプラクティス <a href="#policy-design-best-practices" id="policy-design-best-practices"></a>

* **最初は制限的に:** 複数ポリシーが競合する場合は、より制限の強いポリシーを適用する
* **粒度の細かい制御:** 広いポリシーより、特定のアプリケーションとユーザーへの適用範囲の指定を使う
* **業務との整合:** 実際の業務プロセスとリスク許容度に合わせてポリシーを設計する
* **定期的な更新:** 業務ニーズと脅威の変化に合わせてポリシーを最新に保つ

### 緊急時手順 <a href="#emergency-procedures" id="emergency-procedures"></a>

* 重要システムアクセス向けの緊急ブレークグラス手順を維持する
* 緊急の特権要求向けエスカレーション経路を文書化する
* 一時的なポリシー停止の明確な基準を定める
* 緊急承認向けの24時間365日体制の連絡先を確保する

### 避けるべき一般的な落とし穴 <a href="#common-pitfalls-to-avoid" id="common-pitfalls-to-avoid"></a>

* **導入を急ぎすぎる:** ポリシーを適用する前に利用パターンを十分理解する
* **過度な複雑化:** シンプルに始め、段階的に複雑さを増やす
* **周知不足:** デプロイ全体を通じてユーザーに情報を共有し続ける
* **業務への影響の軽視:** ポリシー設計時に運用要件を考慮する
* **監視の欠如:** 実運用の利用状況に基づいて継続的に監視し調整する

***

## 成功指標 <a href="#measuring-success" id="measuring-success"></a>

デプロイの効果を評価するため、以下の主要指標を追跡します。

* **常時管理者権限の削減:** ローカル管理者グループから外したユーザーの割合
* **ポリシー遵守:** 定めた特権管理ポリシーへの適合状況
* **ユーザー満足度:** プロセスの効率とユーザー体験に関するフィードバック
* **セキュリティインシデント:** 特権関連セキュリティイベントの減少
* **運用効率:** 正当な特権要求の解決までの時間

この段階的アプローチに従うことで、業務継続性とユーザー満足度を保ちながら、エンドポイント特権マネージャーを組織に導入できます。重要なのは、段階的に進め、継続的に監視し、実運用の利用パターンとフィードバックに基づいて調整することです。


---

# 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/deployment/recommended-deployment-phases.md?ask=<question>&goal=<endgoal>
```

`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.