# セキュリティ

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

**対象:** Keeperエンドポイント特権マネージャーのお客様。本ページでは、**Keeper特権マネージャーがどのようにセキュリティを確保しているか**をまとめます。開発者向けや社内ドキュメントを読まなくても、製品がエンドポイント、データ、ユーザーをどう守るかを理解できるようにしています。

***

### 概要

Keeper特権マネージャーは、**リスクを抑えつつ**、必要な操作を**可能にする**ことを目的に設計されています。セキュリティは、エージェントの動作、通信、ポリシー適用、操作の監査の各面に組み込まれています。以下では、環境を安全に保つ主な仕組みを整理します。

### ゼロスタンディング特権と最小権限

* **ユーザーはローカル管理者である必要がありません。** 常時付与の特権を減らす方向で設計されています。既定は標準アカウントとし、昇格や機微なファイルアクセスが必要なときに要求します。**お客様のポリシー**が、許可するか、MFA・承認・正当化を求めるか、拒否するかを決めます。
* **昇格とアクセスには時間と範囲の上限があります。** ポリシーで許可された操作に対して、**一時的**な昇格やファイルアクセス (例: 特定アプリやパス、一定時間) を付与できます。時間または範囲が終われば特権は解消され、日常利用で「常に管理者」のままになりません。
* **最小権限の適用**により、状況に応じて常時の管理者権限を外しつつ、制御された例外だけを残せます。誰が何をしてよいかを定義した内容は、エージェントによって一貫して適用されます。

**意義:** 常時管理者が少ないほど攻撃対象領域は小さくなります。侵害されたユーザーアカウントに内在する権限も抑えられ、機微な操作はポリシーで制御され、必要に応じてMFAや承認も挟めます。

### ポリシーに基づく制御

* **許可の内容と手順はお客様が決めます。**&#x4B;eeperのダッシュボード上のポリシーで、どのアプリ、ユーザー、マシン、パスを許可/拒否するか、MFA・正当化・承認を必須にするかを定義します。初期状態からすべてを許可するわけではなく、設定した内容がエージェントに適用されます。
* **きめ細かい適用範囲の指定**により、アプリ、コマンドライン、フォルダ、ユーザー、マシン (変数やワイルドカードを含む) で範囲を絞れます。あるツールだけ許可して別を拒否したり、高リスクの操作にだけ承認を求めたりできます。
* **リダイレクト**により、制御された形で「許可」できます。例: **\[ネットワーク設定]** を、OSの画面全体ではなくポリシーで承認した代替UIへ誘導し、不要な特権なしに必要な機能だけ使わせます。
* **MFA、承認、正当化**は、機微な操作の前に追加の確認を挟みます。いずれもポリシーごとに設定でき、リスクに合わせて制御の強さを調整できます。

**意義:** 機微な操作はすべてお客様のルールのもとで制御されます。想定外のアプリやコマンドがそのまま通ることはなく、同じポリシー集合で評価されます。

### ローカル限定の公開: エージェントはネットワークで待ち受けない

* **管理用APIとメッセージバスはlocalhostにのみバインド**されます (例: 127.0.0.1)。エージェントのHTTP/HTTPS APIとMQTTブローカーはネットワークに公開されず、**同一マシン上からだけ**到達できます。
* **エージェントの制御面ではネットワークポートを開きません。** 外部からネットワーク越しにエージェントのAPIやメッセージバスを直接呼び出すことはできません。エージェントと通信する管理や自動化 (スクリプト、監視など) は、通常そのエンドポイント上で動かすか、バックエンド経由の安全な仕組み (例: セキュアな同期) を使います。

**意義:** エージェントの中核 (ポリシーエンジン、ジョブ実行、プラグイン) はネットワークサービスではありません。遠隔からの攻撃対象を大きく減らせます。

### 信頼できるコンポーネントだけがサービスと通信できる

* **Keeper特権マネージャーが起動したプロセス** (かつ有効なアイデンティティを示すもの) だけが、エージェントのメッセージバスへの接続や、機微な操作向けのローカルAPIの利用が許されます。任意のアプリやスクリプトが勝手に接続できるわけではなく、製品の要件を満たす場合 (例: サービスが起動したプロセス、認可された管理者コンテキスト) に限られます。
* **多段階の認可**により、呼び出し元ごとにできることが分かれます。例: ヘルスチェックは監視向けに認証なしでもよい一方、設定変更やジョブ実行は認可された (例: 管理者またはプラグイン) コンテキストが必要です。侵害や誤用されたクライアントの影響を抑えられます。

**意義:** マルウェアや一般ユーザーアプリが、エージェントのAPIを不正に呼び出してポリシーを変えたり特権操作を起こしたりすることは単純にはできません。製品自身のコンポーネントと、正しく認可された呼び出し元に限られます。

### 暗号化とデータの保護

* ローカル管理APIには**HTTPS**を使います (証明書付き。localhost向けに自己署名であることが多い)。ローカルMQTTメッセージバスには**TLS**を使います。同一マシン上のエージェント各パーツ間の通信は暗号化されます。
* **保存される機微なデータ** (ポリシー、設定、監査関連データなどエージェントのストレージ内) は**暗号化**されます。シークレットや機微な構成が、アクセスされやすいファイルに平文のまま保存されないよう設計されています。
* **証明書と検証**により、エージェントは起動・通信する相手のアイデンティティを確認できます。プラグインや署名付きコンポーネントは、実行前に検証されます。

**意義:** エージェント内部の通信は同一ホスト上の盗み見から守られ、保存データも安易な読み取りから守られます。

### 監査と可視性

* **特権昇格、ファイルアクセス、ポリシー評価、承認、拒否**を**監査**できます。何が要求されたか、どのポリシーに一致したか、許可/拒否の結果、承認者とユーザーのやり取りが記録されます。これらのイベントはKeeperバックエンドへ送れ、レポートやSIEM・監査ツールとの連携に使えます。
* **ログ**は詳しさや保持期間を調整でき、トラブルシュートやコンプライアンスに合わせられます。ポリシーが期待どおり動いているかの確認やインシデント調査に役立ちます。

**意義:** 誰が何をし、ポリシー上許可されたか拒否されたかの記録が残ります。コンプライアンス、インシデント対応、ルールの継続的な改善に役立ちます。

### 制御されたプラグインとジョブ

* **プラグイン** (例: ポリシーエンジン、バックエンド同期、ロガー) は、既知の場所と構成から**エージェントが読み込み・起動**します。実行前に検証 (例: パスとアイデンティティの確認) されます。エージェントがヘルスを監視し、設定に応じて再起動もします。
* **ジョブ**は構成 (例: 管理下ディレクトリのJSON、またはAPI経由) で定義され、エージェントの管理下で動きます。タスク実行も、システム全体と同じ認可と監査の対象です。どのジョブを置くか、いつ動かすか (スケジュール、イベント、手動) はお客様が制御します。

**意義:** エージェントの自動化やポリシーエンジンとして動くのは、お客様が展開し製品が検証したコードに限られ、ネットワークから取った任意のスクリプトや実行ファイルではありません。

### 安全な登録とバックエンド通信

* **エージェントの登録**には、**Keeper管理コンソールでお客様が作成・管理するトークン**を使います。登録は安全な経路で行われます (例: HTTPSでローカルエージェントへ、その後エージェントからバックエンドへ)。トークンはシークレットとして扱い、安全に保管・伝送してください。
* **Keeperバックエンドとの通信** (ポリシー同期、承認データ、監査、インベントリなど) は**安全なチャネル** (例: HTTPS) を使います。認証情報や機微なデータは平文で送られません。

**意義:** 有効なトークンで明示的に登録したエージェントだけがテナントに参加します。バックエンドとの通信も保護され、ポリシー、承認、監査データが転送中に第三者に読まれにくくなります。

### 運用上のセキュリティ

* **監視**および**監視と通知**モードでは、ユーザーをブロックせずに**ポリシーを試せます**。本番の**適用**に切り替える前に、許可/拒否の結果がどうなったか (通知付きで) を確認できます。誤設定で利用者を締め出したり、逆に開きすぎたりするリスクを下げられます。
* **ダッシュボードからの構成** (ポリシー、承認者、展開グループ、多くの場合はプラグインやジョブの設定) は、安全な同期でエージェントへ配布されます。全マシンのファイルを直接編集する代わりに、一元からセキュリティとコンプライアンスを管理できます。

**意義:** ポリシーを安全に展開・調整でき、構成の一貫性と追跡可能性を保ちやすく、厳しいネットワークやコンプライアンス要件にも対応しやすくなります。

### まとめ

Keeper特権マネージャーは、デフォルトで安全であり、お客様の制御下に置けるよう設計されています。

| 領域         | 製品の役割                                                        |
| ---------- | ------------------------------------------------------------ |
| **特権**     | 常時付与のゼロ、ポリシーでゲートした時間/範囲限定の昇格とファイルアクセス、最小権限の適用                |
| **制御**     | ポリシーに基づく許可/拒否/MFA/承認/正当化、きめ細かい適用範囲の指定、制御された形での「許可」のためのリダイレクト |
| **ネットワーク** | エージェントAPIとメッセージバスはlocalhostのみ、制御面をネットワークに晒さない                |
| **信頼**     | Keeper特権マネージャーが起動し検証したコンポーネントのみが機微なAPIを利用でき、多段階の認可が適用されます    |
| **データ**    | ローカル通信にHTTPS/TLS、機微な保存データの暗号化、証明書に基づく検証                      |
| **可視性**    | 昇格・ファイルアクセス・ポリシー・承認の監査イベント、設定可能なログ、バックエンドとSIEM連携             |
| **運用**     | 検証済みプラグインとジョブ、安全な登録とバックエンド同期、監視モード、一元構成、エアギャップ向けオプション        |

日々の設定やベストプラクティスは、[アーキテクチャ](/keeperpam/jp/endpoint-privilege-manager/reference/architecture.md)および本ガイドの他章をご参照ください。本ページは、**Keeperエンドポイント特権マネージャーがどのようにセキュリティを確保しているか**を、お客様の視点で把握するための整理です。


---

# 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/setup/security.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.