# 導入

## 詳細なプロビジョニング

次のセクションでは、将来的に管理や運用を担うクライアントにインスタンスを引き渡すのではなく、MSPが管理対象企業を作成し管理することについて説明します。

### スキーマ設計

設計を開始する前に、すべてのアカウントの全体的な顧客ベースを把握し、できるだけ多くの共通点を抽出することをお勧めします。 すべての管理対象企業に共通する要件を探します。すべての管理対象企業が互いに近いほど、全体として管理しやすくなります。 目標は、将来の管理対象企業に再利用可能なテンプレート化した手順を作成することです。

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

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

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

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

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

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

### ノード&プロビジョニング方法

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

{% hint style="danger" %}
オンプレミスSSO接続 (On-Prem SSO Connect) およびAD Bridgeは、サービスをバインドするために、管理対象企業内の管理者アカウントが必要です。前述のサービスのいずれかを設定する場合、管理者のEメールによって、バインドするインスタンスがサービスに通知されます。
{% endhint %}

### ロールの作成

管理コンソール内で必要なすべてのロールを作成します。ロールは積み重ねることができます。ユーザーは複数のロールに属することが可能で、合計したロールの最も厳しい結果が適用されます。Keeperは、事業部門や地理的な位置ではなく、提供する機能に合わせたロールの名前を付けることを推奨しています。ボルトの移管のロールを適用する場合、「ボルトの移管」という名前を付けます。

{% hint style="info" %}
**MSP管理者のボルトの移管プロセス**

プラットフォームの構成が適切な場合、MSPのデフォルトのトップレベルの「Keeper管理者」ロールのメンバーは、管理対象企業のボルトの移管を実行することが可能で、管理対象企業内に一意の管理者アカウントを持つ必要はありません。管理者ボルト移管プロセスを有効化するには、以下を行います。

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

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

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

ボルト移管の設定の詳細については、[こちら](https://github.com/Keeper-Security/gitbook-jp-enterprise-guide/blob/main/account-transfer-policy/README.md)を参照してください。
{% endhint %}

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

小規模な会社の場合、必要なロールは2つのみです。プラットフォーム管理に使用する管理者ロール、および一般ユーザーベース用のロールです。Keeperは、以下のように最小の「ロール強制」ポリシーを有効化することを推奨します。

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

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

管理者アクセスは、「IPのホワイトリスト化」を作成することで、公開されている管理対象企業の送信IPアドレスに制限することができます。これを行うには、管理者は、管理対象企業のLANまたはVPNにアクセスしてプラットフォームを管理する必要があります。

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

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

通常、二要素認証は、マスターパスワードベースの認証を目的に構成されます。特に、モバイル端末の場合、「ログインごとにコードを要求」ポリシー設定を利用するよう、クライアントに促してください。デスクトップクライアントには、「30日ごとにコードを要求」がしばしば使用されます。 SSO認証を使用しており、IDプロバイダ (idP) の二要素認証が有効な場合、オフまたは設定を解除することができます。デフォルトでは、強制ポリシー内で「利用可能な」すべての方法が明示的に無効化されている場合を除き、ユーザーは引き続き二要素認証を設定し使用することができます。

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

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

### チームの作成

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

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

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

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

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

「Plus」ライセンスタイプを持つ管理対象企業は、Keeperの高度なレポートとアラート (Advanced reporting and Alerts) モジュールにアクセスできます。必要に応じて、SIEMログの転送、アラートやカスタムレポートの作成を行う必要があります。以下を参照してください [MSPのレポートとアラートのベストプラクティス](https://github.com/Keeper-Security/gitbook-jp-enterprise-guide/blob/main/best-practices/README.md#nareptotoartoaram)

### ユーザー登録

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

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

### アカウントの回復

Keeperのゼロ知識アーキテクチャにより、アカウントの復旧には追加の設定が必要となる場合があります。SSO (シングルサインオン) を使用している場合、管理者はIdP (アイデンティティプロバイダ) のユーザー管理インターフェースからエンドユーザーのパスワードリセットを実行できます。一方、マスターパスワード方式のユーザーにはこの方法が利用できないため、復旧を可能にするためには追加の手順が必要です。

マスターパスワード方式のユーザー向けの第一の手段は、自己対応型のリカバリー方法です。これは、ボルトの初期設定時に構成された24語の自動生成フレーズ (リカバリーフレーズ) を使用します。ユーザーがこのリカバリーフレーズを忘れてしまった場合でも、管理者によってアカウント移管ポリシーが設定され、かつエンドユーザーによってそのポリシーが受諾されていれば、アカウント移管機能を用いてボルトの復旧が可能です。

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

「Plus」ライセンスタイプを持つ管理対象企業は、Keeperの高度なレポートとアラート (Advanced reporting and Alerts) モジュール (ARAM) を利用できます。SIEMおよびSyslog転送の設定については、こちらをご覧ください [レポートとアラート (SIEM)](https://docs.keeper.io/enterprise-guide/event-reporting)。ベストプラクティスとサンプルのレポートとアラートについてはこちらをご覧ください [ベストプラクティス](https://docs.keeper.io/enterprise-guide/keeper-msp/best-practices)。