# セキュリティの推奨設定

<figure><img src="https://3468650114-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeJwa6ByNJ2qindnPknCW%2Fuploads%2FddSS6zdrckRQ9PQeUGzu%2Fspaces_-LO5CAzpxoaEquZJBpYz_uploads_9Pm5TUgCRUuRIf4QXc6S_recommended%20security%20settings.webp?alt=media&#x26;token=1fadb8bd-6e6b-456d-99fa-509ae471aaea" alt=""><figcaption></figcaption></figure>

## Keeper Securityのセキュリティ指標 <a href="#keeper-security-benchmarks" id="keeper-security-benchmarks"></a>

Keeperのセキュリティ指標によって、最先端のゼロトラストおよびゼロ知識セキュリティを実現するためのセキュリティの推奨設定、ポリシー、コントロールに対する組織のコンプライアンス適合度が測定されます。

## 共有セキュリティモデル <a href="#shared-security-model" id="shared-security-model"></a>

Keeperは顧客データを保護するためのポリシーとコントロールを備えた暗号化プラットフォームで、管理者が設定した制約内で運用されます。この共有セキュリティモデルでは、ユーザー自身が最小限の権限、緊急アクセス、最高レベルのデータ保護を確保するために推奨ポリシーを適用します。

このページでは、ユーザーの使いやすさはそのままに、Keeperに保存されたデータを保護する助けとなる重要な推奨事項とポリシーについて解説します。

### 1. Keeper管理者を2人作成 <a href="#id-1.-create-at-least-two-keeper-administrators" id="id-1.-create-at-least-two-keeper-administrators"></a>

Keeper管理者は、管理コンソールへのアクセスに使用する暗号化鍵を保持し、ユーザーのプロビジョニング、強制適用ポリシーの管理、日常のユーザー管理を実行します。

「Keeper管理者」ロールには少なくとも**2人**が必要となります。Keeperサポートからは、ユーザーを管理者ロールに昇格させることも、管理者のマスターパスワードをリセットすることもできませんので、一方のアカウントが失われたり、アクセスできなくなったりした場合に備えて、副管理者を設定しておきましょう。

{% hint style="warning" %}
仕様上、Keeper管理者全員がアクセスを失った場合、Keeperのサポートチームは権限を昇格できず、SSOユーザーデバイスの承認もできません。ルートレベルのKeeper管理者アクセス権を持つ緊急アクセス用アカウントが設定しておきましょう。
{% endhint %}

### 2. Keeper管理者ロールに2FAを適用する <a href="#id-2.-enforce-2fa-on-the-keeper-administrator-role" id="id-2.-enforce-2fa-on-the-keeper-administrator-role"></a>

Keeper管理者には多くの権限が付与されているため、外部攻撃、IDプロバイダへの攻撃、内部関係者による攻撃から護られる必要があります。そのため、Keeper管理者ロールおよび管理者権限が付与されたその他のロールには2FAの使用が適用されているようにしてください。

管理者がSSOプロバイダを介してKeeperにログインしている場合でも、管理者ロールにはKeeper側で2FAを追加しておきましょう。これにより、IDプロバイダアカウントの乗っ取りやその他の内部関係者の脅威から護られます。

### 3. SSOの外部で管理者が存在するようにする <a href="#id-3.-ensure-an-administrator-exists-outside-of-sso" id="id-3.-ensure-an-administrator-exists-outside-of-sso"></a>

KeeperクラウドSSOコネクトを使用することでご利用のSAML 2.0 IDプロバイダからプロビジョンニングおよびユーザー認証が可能となります。

管理者はSSOを使用してKeeper管理コンソールにログインできますが、少なくとも管理者アカウントの1つではマスターパスワードでKeeperにログインできる状態にしておきましょう。すべての管理者がSSOに依存すると、新しいデバイスを承認する管理者が存在しない状況が発生する可能性があるためです。SSOプロバイダが機能停止状態に陥ると、全員がアクセスできなくなる可能性があります。SSOがダウンした場合に備えて、SSOログインなしの「緊急用管理者アカウント」を作成しておきましょう。このアカウントには強力なパスワード、2FA、任意で接続IPをホワイトリストするなど多くの保護を追加しておきましょう。

管理者全員がSSOを使用していて、さらに新しいデバイスを使用している状態でそれらのデバイスを承認できない状況では、Keeperのサポートからアクセス回復のためのお手伝いはできません。仕様上、Keeperはゼロ知識のプラットフォームであり、弊社サポートチームはSSO対応デバイスの承認や、ユーザーのデバイス暗号化データキーの回復には対応できません。

### 4. 権限を縮小する <a href="#id-4.-reduce-administrator-privilege" id="id-4.-reduce-administrator-privilege"></a>

Keeperのロール強制ポリシーによりノードおよびサブノード内に管理者ロールを作成できます。管理者には最小限の権限を付与するようにしましょう。

* 効率を考えて管理者の総数を最小限に減らします。
* 管理ロール内の権限を削減します。たとえば、管理者がロールの管理権限を必要としない場合は、その権限を削除します。
* ボルトの内容を転送するために元メンバーの古い管理者アカウントを必要以上に長くロック状態にしないようにします。

### 5. SSOプロバイダを保護する

KeeperをSSO IDプロバイダと連携させる場合は、IDプロバイダに多要素認証ポリシーが設定され、権限が制限されているようにしてください。IDプロバイダからの指示と最善の対応策に従い、管理者アカウントには必要最低限の特権のみ付与されているようにします。

[Keeperオートメイターサービス](https://docs.keeper.io/sso-connect-cloud/device-approvals/automator)を使用すると、クラウドSSOを使用するユーザーが新しいデバイスまたは未承認のデバイスでボルトにアクセスする際の処理がスムーズになります。これにより利便性は向上しますが、SSO IDプロバイダを不正アクセスから保護する必要もあります。Keeperオートメーターサービスを有効にすると、IDプロバイダによる認証とユーザープロビジョニング処理を完全に信頼することになりますので、セキュリティを強化するために自動デバイス承認を特定のIP範囲に制限したり、無効の状態にしてユーザーに新しいデバイスを手動で承認させることもできます。

### 6. 適宜アカウント復元機能を無効にする <a href="#d-6.-disable-account-recovery-when-appropriate" id="d-6.-disable-account-recovery-when-appropriate"></a>

他のSaaSプラットフォームと同様、アカウント復元機能は、主要な認証方法が失われたり忘れられた場合にアカウントへのアクセスを復元する手段となります。Keeperではデフォルトでリカバリフレーズ (自動生成された24語のセット) を作成して、ボルトへのアクセスを復元できます。リカバリフレーズによりマスターパスワード方式と同様のキー導出方式を使用してユーザーのデータキーが暗号化されます。

AzureやOktaのようなシングルサインオン製品を使用しているユーザーにデプロイする場合は認証がIDプロバイダに委ねられるため、アカウント復元機能は必要がないか動作が保証されない場合があります。そのため、そのような場合はオプションとしてアカウント復元機能を使用しないのが最善となります。

アカウント回復を無効にするには、**\[ロール] > \[強制ポリシー] > \[アカウント設定] > 「アカウント復元のためのリカバリーフレーズを無効にする」**&#x3092;選択します。

アカウントへのアクセスを失った場合でもリカバリフレーズが安全な場所に保存されていると、アカウント復元を実行できます。

### 7. 強力なマスターパスワードを適用 <a href="#id-7.-enforce-a-strong-master-password" id="id-7.-enforce-a-strong-master-password"></a>

マスターパスワードでログインするユーザーの場合、データキーを復号化および暗号化するためのキーは、ユーザーのマスターパスワードからパスワードに基づくキー導出関数 (PBKDF2) を使用して導出されます (デフォルトでは100万回反復)。ユーザーがマスターパスワードを入力すると、キーがローカルで導出されてからデータキーが復号化されます。その後データキーが個々のレコードキーとフォルダキーの復号化するために使用されます。その後、レコードキーによって保存されている各レコードの内容がローカルで復号化されます。

Keeperには、AWS環境における不正アクセスに対する対策として、デバイス承認、スロットリングなどの保護策が実装されています。複雑なマスターパスワードを適用することで、ユーザーのボルトへのオフラインでの総当たり攻撃のリスクを大幅に軽減します。

米国国立標準技術研究所 (NIST) からは、[Special Publication 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html)にてパスワードのガイドラインが提供されており、使いやすさと安全性のバランスが提唱されています。つまり、パスワードは覚えやすく、かつ推測されにくいものでなければなりません。NISTの資料では、最低8文字が推奨されていますが、文字数を増やすとパスワードの推測や解読がもっと難しくなります。Keeperでは最低12文字を適用していますが、さらに16文字以上に増やすと良いでしょう。

パスワードの複雑さはロールごとに設定できます。ユーザーガイドの[マスターパスワードの複雑さ](https://docs.keeper.io/enterprise-guide/roles/enforcement-policies#masutpasuwdonosa)のページをご参照ください。

### 8. エンドユーザーに対する二要素認証の適用 <a href="#id-8.-enforce-two-factor-authentication-for-end-users" id="id-8.-enforce-two-factor-authentication-for-end-users"></a>

二要素認証 (2FA) は多要素認証 (MFA) とも呼ばれ、認証に2つ目の要素を加えることにより、ボルトヘアクセスする際の安全性が向上します。最初の要素は知的要素と呼ばれ、マスターパスワード (またはSSO) が該当します。2つ目の要素は所有要素となり、携帯端末 (SMSテキストやTOTPアプリ) やYubiKey、Google Titanキーなどのハードウェアデバイスを使用できます。

Keeperのクラウドインフラストラクチャにはブルートフォース攻撃に対する緩和策が実装されていますが、2つ目の認証要素を追加すると、攻撃者がユーザーのボルトにアクセスすることが非常に困難となります。ロール単位の適用を使用すると、組織内の全ユーザーに対してボルトへのログインに2FAの使用を義務付けることができます。

SSOを使用するユーザーの場合、少なくともIDプロバイダで2FAが設定されているようにする必要があります。Keeperでは、SSO認証中にIDプロバイダからの署名付きアサーションがチェックされます。セキュリティを強化するために、IDプロバイダだけでなくKeeper側でも2FAを有効にすることもできます。\
\
二要素認証の設定については、ユーザーガイドの[二要素認証](https://docs.keeper.io/jp/enterprise-guide-jp/two-factor)のページをご参照ください。

### 9. IPのホワイトリストを設定 <a href="#id-9.-configure-ip-allowlisting" id="id-9.-configure-ip-allowlisting"></a>

ユーザーが承認された場所やネットワーク以外からボルトにアクセスできないようにするには、IPアドレスのホワイトリストを有効にします。デバイスが承認されたネットワーク上にある際にのみ指定のユーザーがボルトにアクセスできるようにするロール単位の適用項目として設定します。

{% hint style="warning" %}
最低でもKeeperで管理者権限を持つユーザーは特定のIPまたはIP範囲からのみアクセスできるようにしておきましょう。これにより、悪意のある内部関係者からの攻撃やIDプロバイダによる乗っ取り攻撃を防止できます。IPの限定が不可能な場合は、MFAを適用します。
{% endhint %}

この機能を使用するロールの設定の詳細は、[IPのホワイトリストのページ](https://docs.keeper.io/enterprise-guide/roles/enforcement-policies#allow-ip-list)をご覧ください。

### 10. 必要に応じてアカウント移管ポリシーを有効にする <a href="#id-10.-enable-account-transfer-policy-when-necessary" id="id-10.-enable-account-transfer-policy-when-necessary"></a>

アカウント移管機能は、メンバーが組織を去った場合に管理者がそのメンバーのボルトの内容を回復するための仕組みとなります。この機能は任意でご利用になれ、ユーザーの暗号化キーを受け渡すための特定の手順が必要となるため、Keeper導入の初期段階でKeeper管理者が設定しておく必要があります。

詳しい手順については、[アカウント移管ポリシー](https://docs.keeper.io/enterprise-guide/account-transfer-policy)のページをご参照ください。

ユーザーがマスターパスワードを使って認証する場合や、組織が特定のユーザーのボルトが失われる心配がある場合には、アカウント移管ポリシーを設定しておきましょう。

アカウント移管ポリシーにより、管理者には管理対象のユーザーのボルトを移管する権限が付与されます。重役やルートレベルの管理者など、状況のいかんに関わらずボルトの移管を希望しないユーザーがいる場合は、アカウント移管ポリシーが有効になっていないロールに配置することも可能です。

### 11. アラートの作成 <a href="#id-11.-create-alerts" id="id-11.-create-alerts"></a>

Keeperの高度なレポートシステムにはアラート機能が搭載されており、重要なイベントが発生した場合はユーザーと管理者に通知されます。最善の対応法として、Keeper管理者向けに[推奨アラートの一覧](https://docs.keeper.io/enterprise-guide/recommended-alerts)をご用意しました。外部と内部の両方で不審なアクティビティが通知されるよう、主要な管理イベントのアラートを有効にしておきましょう。

### 12. 未承認の拡張機能のインストールを禁止 <a href="#id-12.-prevent-installation-of-untrusted-extensions" id="id-12.-prevent-installation-of-untrusted-extensions"></a>

一般的なセキュリティ対策として、エンドユーザーには未承認のサードパーティ製ブラウザ拡張機能をインストールできないようにしておきましょう。通常より多くのアクセス許可を持つブラウザ拡張機能は、ウェブサイトまたはブラウザベースのアプリケーション内のあらゆる情報にアクセスできる可能性があります。デバイス管理ソフトウェアを参照して、Keeperが許可されていること、および未承認の拡張機能がブロックまたは削除されているようにしてください。

### 13. ブラウザ内蔵のパスワードマネージャーを無効にする <a href="#id-13.-disable-built-in-browser-password-managers" id="id-13.-disable-built-in-browser-password-managers"></a>

ブラウザには通常、独自のパスワードマネージャーが搭載されています。このようなパスワードマネージャーはKeeperほど高度なものではなく安全ではない上、Keeperと競合してログインの問題やセキュリティの不統一が発生する可能性があります。そのため、ブラウザ内蔵のパスワードマネージャーを無効にするようにしましょう。

### 14. 組織全体に展開 <a href="#id-14.-deploy-across-your-entire-organization" id="id-14.-deploy-across-your-entire-organization"></a>

様々なデバイス、アプリケーション、ウェブサイトにわたってユーザーを保護するには、特権認証情報を扱う組織全体のユーザーにKeeperを導入する必要があります。安全なパスワードマネージャーを使用しない管理者または特権ユーザーは、組織を危険にさらす可能性があります。

### 15. 最小権限ポリシーを適用

すべての管理対象デバイスに最小権限アクセス制御を適用し、攻撃対象領域を最小化して不正なシステムアクセスを防ぎます。[Keeperエンドポイント特権マネージャー](https://docs.keeper.io/keeperpam/endpoint-privilege-manager/overview)の「最小権限」ポリシーは、横方向への移動、特権昇格、データ侵害のリスクを低減しながら、SOC 2、NIST、ISO 27001といったコンプライアンス基準への対応を支援します。