# 導入

<figure><img src="/files/YjOFJgahl76mCtO0MYT5" alt=""><figcaption></figcaption></figure>

特権昇格および委任管理 (PEDM) を本番に近い形で確実に展開するには、セキュリティと業務継続性のバランスを取った段階的なアプローチが必要です。本ガイドでは、組織全体にKeeperのエンドポイント特権マネージャー (KEPM) を導入する際の推奨方針をまとめます。

### 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週間確保する
* 開発者ワークステーション、一般ユーザーマシン、サーバーなど、多様なエンドポイント種別を対象にする

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

監視期間中はダッシュボードで次を確認します。

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

#### コレクションと組織構造の整備 <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: 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/keeperpam/jp/endpoint-privilege-manager/best-practices/deployment.md?ask=<question>
```

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.