# MSP向けベストプラクティス

## 概要 <a href="#overview" id="overview"></a>

本ページでは、Keeper MSPテナントのセットアップおよび構成に関するベストプラクティスをご紹介します。

## 管理者アクセス <a href="#administrative-access" id="administrative-access"></a>

#### MSP (マネージドサービスプロバイダ) <a href="#msp" id="msp"></a>

Keeper管理コンソールに対して、ルートノード内にフル管理者権限を持つユーザーを少なくとも2名維持することが重要です。管理者がパスワード忘れ、シングルサインオンサービスの障害、ポリシー設定などの理由で管理画面にログインできなくなった場合、もう一方のアカウントが復旧対応に必要となります。\
Keeperはゼロ知識暗号化モデルを採用しているため、MSPのルート管理者全員がログインできない状態では、Keeperのサポート担当者による復旧対応は行えません。

#### クライアント (管理対象企業) <a href="#client-managed-company" id="client-managed-company"></a>

一部の設定では、管理対象企業 (MC) テナント内に管理者アカウントが必要となります。たとえば、クラウドSSOコネクトやKeeperブリッジでは、管理対象企業内で管理者権限を持つアカウントを使用します。このアカウントは、プロビジョニング方式をMCインスタンスに関連付けるために必要です。

## ロール <a href="#roles" id="roles"></a>

### 命名 <a href="#naming" id="naming"></a>

ロールは必要最小限に作成し、その機能が分かる名称を付けることが推奨されます。たとえば、出張の多い営業担当者にオフラインアクセスを付与する場合、「出張営業担当者」という名称ではなく、「オフラインアクセスを有効化」のように機能を示す名前にします。このようにしておくことで、半年後にアクセスに関する問題が発生した場合でも、各ロールが誰向けかではなく何を行うロールかをすぐに把握できます。

### ロールの重ね合わせ <a href="#stacking-roles" id="stacking-roles"></a>

同一のユーザーやチームに対して、複数のロールを割り当てる運用は一般的です。ただし、適用される権限は、ルール全体の中で最も制限の厳しい設定となる点に注意してください。

### デフォルトロール <a href="#default-role" id="default-role"></a>

新しくプロビジョニングされたユーザーを割り当てるためのデフォルトロールを作成しておくことが推奨されます。これは、ジャストインタイムの高度なプロビジョニング方式を使用する場合に特に有効です。\
デフォルトロールを用意しておくことで、新規ユーザー作成時にどの強制設定が適用されるかを明確に把握できます。一般的な設定には、マスターパスワードの複雑さや2要素認証の要件などがあります。これにより、すべてのユーザーのボルトが初回ログイン時から適切に保護されます。

### ロールテンプレート <a href="#role-templating" id="role-templating"></a>

管理対象企業 (MC) やユーザー数が増えるにつれて、アクセス制御の管理負荷も高まります。そのため、クライアント全体で共通して使用できる標準化されたロールのセットをあらかじめ作成しておくことが推奨されます。この運用により、どのMCを管理する場合でも、組織全体で一貫したアクセス制御を維持できます。

## アカウント移管 <a href="#account-transfer" id="account-transfer"></a>

アカウント移管はオプション機能であり、Keeperの初期導入段階において、Keeper管理者が設定しておくことが推奨されます。これは、アカウント移行が、移行を実行する権限を持つユーザー間での暗号鍵の共有に基づいて動作するためです。鍵の交換は、Keeperのゼロ知識インフラストラクチャを維持する目的で、ユーザーが自身のボルトにログインした際に行われます。そのため、ユーザーのアカウントを移行する前に、アカウント移行の設定を完了させておく必要があります。

アカウント移管を正常に実行するには、対象ユーザーが少なくとも一度はログインしていることが条件となります。ユーザーが組織を離れる場合、適切な管理者権限を持つ管理者は、そのユーザーのボルトを組織内の別のユーザーに移行できます。この機能を使用すると、組織内のロールベースの階層構造を維持したまま、ユーザーのボルト内コンテンツの管理権限を安全に引き継ぐことができます。

アカウント移管について、詳しくは[こちらのページ](/enterprise-guide/jp/account-transfer-policy.md)をご参照ください。

## チーム共有とフォルダの共有 <a href="#team-sharing-share-folders" id="team-sharing-share-folders"></a>

ボルトのバージョン16.8より前では、MSPユーザーは管理対象企業内の個々のユーザーに対してのみ、レコードやフォルダを共有できました。ボルトのバージョン16.8以降では、MSPボルトから管理対象企業内のチーム全体に対して、フォルダを直接共有できるようになっています。

MSPボルトでは、ルートレベルに「クライアント」などのプライベートフォルダを作成することが推奨されます。そのプライベートフォルダ内に、共有対象とする管理対象企業ごとに共有フォルダを追加します。\
さらに、各共有フォルダの中にサブフォルダを作成し、情報を用途別やカテゴリ別に整理します。

以下は、MSPボルト内におけるフォルダ構成の一例です。

<figure><img src="https://3468650114-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeJwa6ByNJ2qindnPknCW%2Fuploads%2Ffuco7ECF0SmWFYTw6QSp%2FJP_MSP1.png?alt=media&#x26;token=f79bb72f-c196-4246-8fb4-8578cd009b05" alt=""><figcaption><p>推奨されるMSPボルトの構造</p></figcaption></figure>

共有フォルダの編集画面で **\[ユーザー]** タブをクリックし、MSPユーザー、または必要に応じて管理対象企業とフォルダを共有します。**\[メールアドレスまたはチーム名]** フィールドでは、MSPテナント内のチームや管理対象企業テナント内のチームを選択できます。

<figure><img src="https://3468650114-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeJwa6ByNJ2qindnPknCW%2Fuploads%2F3vLQ1SdiXoXL3PVCKxS0%2FJP_MSP2.png?alt=media&#x26;token=97adcab1-1536-4d03-87f0-df0c09f69dd3" alt=""><figcaption><p>マネージド企業のチームと共有する</p></figcaption></figure>

## 強制適用ポリシー <a href="#enforcement-policies" id="enforcement-policies"></a>

以下は、推奨される強制ポリシーの一覧です。これらの設定は、MSP運用担当者および管理対象企業のエンドユーザーに適用されます。

<table><thead><tr><th>場所</th><th width="258.2421875">ポリシー名</th><th width="135.1015625">推奨設定</th><th>備考</th></tr></thead><tbody><tr><td>2要素認証</td><td>2要素認証を必須とする</td><td>有効 (オン)</td><td>-</td></tr><tr><td>ボルト機能<br>(ページ下部)</td><td><p>削除したレコードの保持期間</p><p>削除済みアイテムの完全削除ができない期間<br><br>削除済みアイテムが自動的に完全削除されるまでの期間</p></td><td>両方とも有効</td><td>保持期間は365日に設定(推奨)</td></tr><tr><td>インポートとエクスポート</td><td>ボルトからエクスポート</td><td>無効 (オフ)</td><td>退職時のパスワード持ち出し防止</td></tr><tr><td>アカウント移管</td><td>アカウント移行を有効にする</td><td>有効 (オン)</td><td>非常に重要。ロールに関係なくすべてのユーザーに推奨</td></tr></tbody></table>

ロールベースのポリシーについて、詳しくは[こちらのページ](/enterprise-guide/jp/roles/enforcement-policies.md)をご覧ください。

{% hint style="danger" %}
MSPとして運用する場合、アカウント移管ポリシーを必ず有効化することが重要です。このポリシーが無効になっていると、ユーザーがマスターパスワードやアカウント復旧用の質問を忘れた際に、プラットフォームへログインできなくなり、自身のボルトにアクセスできなくなるリスクがあります。
{% endhint %}

## レポート・アラートモジュール (ARAM) <a href="#advanced-reporting-and-alerts-aram" id="advanced-reporting-and-alerts-aram"></a>

<table><thead><tr><th width="259.8359375">名称</th><th>イベントタイプの設定内容</th></tr></thead><tbody><tr><td>管理対象企業の変更 (レポート)</td><td><strong>「イベントタイプ」</strong>→<strong>「MSP」</strong><br>すべてのイベントを選択</td></tr><tr><td>管理者アクティビティ (レポート)</td><td><p><strong>「イベントタイプ」</strong>→<strong>「セキュリティ」</strong><br>2FAを無効化、ユーザーを作成、ユーザーを招待、ボルトを移管、ユーザーをロールに追加<br><br><strong>「イベントタイプ」</strong>→<strong>「ポリシー変更」</strong></p><p>ノードを作成、ノードを削除、チームを作成、チームを削除、レポートを作成、レポートを削除、アラートを作成、アラートを削除<br><br><strong>「イベントタイプ」</strong>→<strong>「一般的な操作」</strong><br>ごみ箱をクリア、レコードのインポート、レコードのエクスポート<br><br><strong>「イベントタイプ」</strong>→<strong>「MSP」</strong></p><p>座席数の増加、座席数の減少、MCプランを変更、管理対象企業を一時停止、管理対象企業を消去、管理対象企業の削除<br><br><strong>「ユーザー」</strong>→ すべての管理者を選択</p></td></tr><tr><td>BreachWatch (アラート)</td><td><strong>「イベントタイプ」</strong>→<strong>「BreachWatch」</strong><br>BreahWatchが脆弱なレコード内パスワードを検知、脆弱なレコード内パスワード検出を無視<br><br><strong>「属性」</strong><br>メールアドレス → すべて選択<br>アラート頻度 → 各イベント発生時 (推奨)</td></tr><tr><td>ブルートフォース攻撃の監視 (アラート)</td><td><p><strong>「イベントタイプ」</strong>→<strong>「セキュリティ」</strong><br>コンソールへのログイン失敗<br><br><strong>「イベントタイプ」</strong>→<strong>「ログイン」</strong></p><p>ログインの失敗<br><br><strong>「属性」</strong></p><p>メールアドレス → すべて選択<br>アラート頻度 → 5回ごと</p></td></tr><tr><td>一時停止中の管理対象企業 (アラート)</td><td><p><strong>「イベントタイプ」</strong>→<strong>「MSP」</strong><br>管理対象企業を一時停止</p><p><br><strong>「属性」</strong></p><p>メールアドレス → すべて選択<br>アラート頻度 → 各イベント発生時 (推奨)</p></td></tr></tbody></table>

Keeperのイベントレポートおよびアラートについて、詳しくは[こちらのページ](/enterprise-guide/jp/event-reporting.md)をご参照ください。

{% hint style="info" %}
これらのレポートおよびアラートは、必要に応じて管理対象企業 (MC) レベルでも設定できます。ただし、MCがARAMを含むプランに属していることが条件となります。対象となるのは、ビジネスPlusおよびエンタープライズPlusライセンスのみです。
{% endhint %}


---

# 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/enterprise-guide/jp/keeper-msp/best-practices.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.