> 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/enterprise-guide/jp/keeper-msp/on-boarding.md).

# 導入

## ホワイトグローブ・プロビジョニング

以下のセクションでは、将来的にクライアントへインスタンスを引き渡して管理を委ねるのではなく、MSPが管理対象企業を作成して管理する手順を説明します。

### スキーマ設計

設計を始める際は、すべてのアカウントにわたる顧客基盤を確認し、できるだけ多くの共通点を抽出することをお勧めします。すべての管理対象企業に共通する要件を洗い出します。管理対象企業同士の設計が近いほど、全体の管理が容易になります。目標は、将来の管理対象企業でも再利用できるテンプレート化された手順を作成することです。

以下の表では、すべてのMCで「ボルトの移管が必要」という名前のロールを使用します。一見すると、各MCごとに異なる2要素要件を扱うために、「2要素認証 (2FA)」という名前のロールを作成したくなるかもしれません。しかし、Keeperには10を超える2要素認証オプションがあるため、この名前は曖昧です。プラットフォームを長期的に管理するには、ロールに適用する設定を具体的に示す名前を付けることをお勧めします。目標は、すべての管理対象企業で一貫したロール命名と結果を保つことです。

ロールはプラットフォーム管理に関するものであるため、MC間で多くの共通性があります。一方、ビジネス要件の違いにより、チームや共有フォルダはMCごとに異なる傾向があります。以下の表では、特定のMCに存在する各チームに1つの共有フォルダを作成しています。表の例にとらわれず、すべての管理対象企業で共通の命名規則を使用してください。ある管理対象企業で「AP」チームを作り、別の管理対象企業で「Accounts Payable (買掛金)」チームを作るような使い分けは避けてください。

|  MC |                          ロール                          | チーム                         | 共有                          |
| --: | :---------------------------------------------------: | --------------------------- | --------------------------- |
| MC1 |    <p>ボルトの移管が必要<br>2要素認証が必要</p><p>マスターパスワードの複雑さ</p>   | <p>IT</p><p>HR</p><p>AP</p> | チームごとの共有                    |
| MC2 | <p>ボルトの移管が必要<br>2要素認証はオプション</p><p>モバイルデバイスのアクセスなし</p> | <p>買掛金部門</p><p>AP</p>       | チームごとの共有                    |
| MC3 |          <p>ボルトの移管が必要</p><p>Officeアクセスのみ</p>          | N/A                         | <p>営業</p><p>IT</p><p>AP</p> |

### 新しい管理対象企業の作成

コンソールインターフェースから、新しい管理対象企業を作成し、プロビジョニング方法を決定し、必要なロールとチームを作成します。

また、会社ロゴやカスタマイズしたメール招待など、必要な[MCカスタマイズ](/enterprise-guide/jp/user-and-team-provisioning/custom-invite-and-logo.md#customized-email-invitations)を作成します。

### ノードおよびプロビジョニング方法

「MC」を作成したら、[ノード](/enterprise-guide/jp/nodes-and-organizational-structure.md)の構造に影響するため、プロビジョニング方法を選択する必要があります。 [シングルサインオン (Single Sign-On)](/enterprise-guide/jp/user-and-team-provisioning/single-sign-on-saml-2.0-authentication.md#keeper-sso-connect-tm-cloud) または[高度なプロビジョニング (Advance Provisioning)](/enterprise-guide/jp/user-and-team-provisioning.md) を使用する場合、プロビジョニング方法をホストにするには、ノードを追加する必要があります。この例では、基本的なマスターパスワードアクセスと手動プロビジョニングを使用しているため、ノードの追加は必要ありません。

{% hint style="danger" %}
オンプレミスSSOコネクトおよびADブリッジでは、サービスをバインドするために管理対象企業内の管理者アカウントが必要です。これらのサービスを設定する際、管理者のメールアドレスによってバインド先のインスタンスが決まります。
{% endhint %}

### ロールの作成

管理コンソールで必要なロールをすべて作成します。ロールは重ね合わせ可能です。ユーザーは複数のロールに所属でき、適用されるのはすべてのロールを合算したうえで最も制限の厳しい結果です。Keeperは、事業部門や地域名ではなく、ロールの機能に基づいて名前を付けることを推奨しています。ボルト移管を強制するロールには「ボルト移管」という名前を付けてください。

{% hint style="info" icon="comment-question" %}
**MSP管理者向けボルト移管パススルー** 構成が正しければ、MSPのデフォルト最上位「Keeper管理者」ロールのメンバーが、管理対象企業内に専用の管理者アカウントを用意せずに、当該管理対象企業のボルト移管を実行できます。管理者向けボルト移管パススルーは、以下の手順で有効化できます。

1. デフォルト最上位「Keeper管理者」ロールの「管理上の許可」で「アカウント移管」オプションを有効化します。
2. 管理対象企業内のデフォルト「Keeper管理者」ロールでも、同じ操作を実行します。
3. 管理対象企業のユーザーアカウント移管ロールで、「対象ロール」として「Keeper管理者」を選択します。

クライアントの管理対象企業が、ボルト移管機能を組織の特定メンバーに限定し、MSPによる実行を防ぎたい場合は、デフォルトの「Keeper管理者」以外のロールを作成し、「対象ロール」として使用します。MSPパススルーは、Keeperが提供するデフォルト管理者ロールでのみ機能します。ローカルの移管権限のみを設定する場合は、以下の手順を実行します。

1. 管理対象企業内に新しいロールを作成します。
2. 新しいロールの「管理上の許可」で「アカウント移管」オプションを有効化します。
3. アカウント移管を有効化するユーザーロールの「対象ロール」として、新しいロールを使用します。

ボルト移管の設定について詳しくは、[アカウント移管ポリシー](/enterprise-guide/jp/account-transfer-policy.md)をご参照ください。
{% endhint %}

「ノードとサブノードのデフォルトロールとして設定」および「チームの作成」オプションが有効なロールは、新規ユーザーに自動的に割り当てられます。ロールにはユーザーとチームの両方を含められるため、チームメンバーシップ経由でユーザーを間接的にロールに追加することもできます。

小規模な会社では、多くの場合、管理者用ロールと一般ユーザー用ロールの2つで十分です。Keeperは、以下の最小限の「ロール強制」ポリシーを有効化することを推奨します。

#### 「Keeper管理者」ロール (事前定義)

| グループの設定 | 設定              | 値             |
| ------- | --------------- | ------------- |
| ログイン設定  | 長さ              | 12文字以上        |
| ログイン設定  | 有効期限            | 90日           |
| 2要素認証   | 2要素認証の使用が必要     | オン            |
| 2要素認証   | すべてのプラットフォーム    | ログインごとにコードを要求 |
| アカウント設定 | 「ログイン状態を維持」の解除  | オン            |
| アカウント設定 | ログアウトタイマー (すべて) | 10分           |
| アカウント設定 | 許可IPリスト         | 以下の注記を参照      |
| アカウント移管 | アカウント移管を有効化     | オン            |

管理者アクセスは、「許可IPリスト」を作成することで、管理対象企業の公開送信IPアドレスに制限できます。管理者は、管理対象企業のLANまたはVPN上からプラットフォームを管理する必要があります。

#### 「デフォルト」のユーザーロール

| グループの設定   | 設定                | 値         |
| --------- | ----------------- | --------- |
| ログイン設定    | 長さ                | 10文字以上    |
| ログイン設定    | 有効期限              | 90日       |
| 2要素認証     | 2要素認証の使用が必要       | 以下の注記を参照  |
| 2要素認証     | すべてのプラットフォーム      | 以下の注記を参照  |
| 共有＆アップロード | エンタープライズ以外の共有を禁止  | オン        |
| 共有＆アップロード | レコードのエクスポートを禁止    | オン        |
| アカウント設定   | ユーザーのメールアドレス変更を禁止 | オン        |
| アカウント設定   | 「ログイン状態を維持」の解除    | オン        |
| アカウント設定   | ログアウトタイマー (すべて)   | 15～90分    |
| アカウント移管   | アカウント移管を有効化       | オン        |
| アカウント移管   | 対象ロール             | Keeper管理者 |

通常、2要素認証はマスターパスワード認証向けに構成します。特にモバイル端末では、「ログインごとにコードを要求」ポリシーの利用をクライアントに推奨してください。デスクトップクライアントでは、「30日ごとにコードを要求」がよく使われます。IdPで2要素認証が有効なSSO認証を利用している場合は、オフまたは未設定にできます。デフォルトでは、強制ポリシーで「利用可能な」方法をすべて明示的に無効化していない限り、ユーザーは2要素認証を設定して利用できます。

{% hint style="info" icon="pencil-line" %}
デフォルトでは、ユーザー招待はアカウント作成時に送信されます。後日まで招待を抑制する場合は、以下の手順を実行してください。

1. 管理対象企業内で新しいロールを作成します。この例では、ロール名を「メール招待の抑制」とします。
2. ロールの「強制適用ポリシー」ダイアログを開きます。
3. 「アカウント設定」を選択します。
4. 「メール招待を無効化」オプションを有効化し、「完了」をクリックします。
5. 「ノードとサブノードのデフォルトロールとして設定」オプションを有効化します。初回ログイン時にユーザーへロールが適用されます。
   {% endhint %}

### チームの作成

チームを使うと、共有対象のユーザーをグループ化したり、追加の共有オプションを適用したりできます。SCIMプロビジョニングを使用する場合は、チームからロールへの割り当て経由で、ユーザーを間接的にロールに追加できます。

1. 必要なすべての[チーム](/enterprise-guide/jp/teams.md)を作成します。
2. 必要に応じて、適用するロールマッピングを追加します。

### Keeperアプリケーションおよび拡張機能の事前展開

ユーザーを登録する前に、特定のKeeperのブラウザ拡張、デスクトップアプリ、およびモバイルアプリを配布できます。ソフトウェアの一元的な配布方法の詳細は[こちら](/enterprise-guide/jp/deploying-keeper-to-end-users.md)をご参照ください。

### 「Plus」ライセンスの管理対象企業のレポートとアラートを構成する

「Plus」ライセンスタイプの管理対象企業は、Keeperのレポート・アラートモジュールにアクセスできます。必要に応じて、SIEMログの転送、アラート、カスタムレポートを作成してください。詳しくは [MSPのレポートとアラートのベストプラクティス](/enterprise-guide/jp/keeper-msp/best-practices.md#advanced-reporting-and-alerts-aram) をご参照ください。

### ユーザー登録

Keeperには、ユーザー登録のための複数のオプションが用意されています。複数の方法を並行して使用できます。

* 管理コンソールを利用した手動入力
* 管理コンソールを利用したCSVインポート
* Keeperの[AD Bridge](https://docs.keeper.io/keeper-bridge/)エージェントを利用したActive Directoryのプロビジョニング
* Keeperの[クラウドSSOコネクト](https://docs.keeper.io/sso-connect-cloud/jp/)または[オンプレミスSSOコネクト](https://docs.keeper.io/sso-connect-on-prem/jp/)を利用した[ジャストインタイム](/enterprise-guide/jp/user-and-team-provisioning/single-sign-on-saml-2.0-authentication.md) (JIT) プロビジョニング
* IDプロバイダ (IdP) を利用した[SCIMプロビジョニング](/enterprise-guide/jp/user-and-team-provisioning.md)
* APIを利用した[SCIMプロビジョニング](/enterprise-guide/jp/user-and-team-provisioning/automated-provisioning-with-scim.md)
* ドメイン入力による[Eメールプロビジョニング](/enterprise-guide/jp/user-and-team-provisioning/email-auto-provisioning.md)
* [Keeperコマンダーの](https://github.com/Keeper-Security/commander) API/CLIインターフェースによる高度な[自動プロビジョニング](/enterprise-guide/jp/user-and-team-provisioning/cli-provisioning-with-commander-sdk.md)

### アカウントの回復

Keeperのゼロ知識アーキテクチャにより、アカウント復旧には追加の構成が必要になる場合があります。SSOを利用している場合、管理者はIdPのユーザー管理画面からエンドユーザーのパスワードリセットを実行できます。マスターパスワード方式のユーザーにはこの方法が使えないため、必要に応じて復旧を可能にする追加手順が必要です。マスターパスワード方式のユーザー向けの第一の手段は、リカバリーフレーズによるセルフサービス復旧です。リカバリーフレーズは、ボルト設定時に構成される24語の自動生成フレーズです。ユーザーがリカバリーフレーズを忘れた場合でも、管理者がボルト移管ポリシーを設定し、エンドユーザーがそれを承諾していれば、ボルト移管機能でボルトを復旧できます。

### ログおよびカスタムレポートとアラートの構成

「Plus」ライセンスタイプの管理対象企業は、Keeperのレポート・アラートモジュール (ARAM) を利用できます。SIEMおよびSyslog転送の設定については、[レポートとアラート (SIEM)](/enterprise-guide/jp/event-reporting.md)をご参照ください。ベストプラクティスとサンプルのレポートとアラートについては、[ベストプラクティス](/enterprise-guide/jp/keeper-msp/best-practices.md#advanced-reporting-and-alerts-aram)をご参照ください。


---

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