セキュリティの推奨設定
Keeperのセキュリティポリシーと設定に関する管理上の推奨事項
共有セキュリティモデル
Keeperは、管理者が設定した制約内で顧客データを保護するためのポリシーと制御を備えた暗号化プラットフォームです。この共有セキュリティモデルでは、ユーザー自身が最小限の権限、緊急アクセス、最高レベルのデータ保護を確保するために推奨ポリシーを適用します。
このページでは、使いやすさはそのままに、Keeperに保存されたデータを保護する助けとなる重要な推奨事項とポリシーについて解説します。
1. Keeper管理者を2人作成
Keeper管理者は、管理コンソールへのアクセスに使用する暗号化鍵を保持し、ユーザーのプロビジョニング、強制適用ポリシーの管理、日常のユーザー管理を実行します。
「Keeper管理者」ロールには少なくとも2人が必要となります。Keeperサポートからは、ユーザーを管理者ロールに昇格させることも、管理者のマスターパスワードをリセットすることもできませんので、一方のアカウントが失われたり、アクセスできなくなったりした場合に備えて、副管理者を設定しておきましょう。
仕様上、Keeper管理者全員がアクセスを失った場合、Keeperのサポートチームは権限を昇格できず、SSOユーザーデバイスの承認もできません。ルートレベルのKeeper管理者アクセス権を持つ緊急アクセス用アカウントが設定しておきましょう。
2. Keeper管理者ロールに2FAを適用する
Keeper管理者には多くの権限が付与されているため、外部攻撃、IDプロバイダへの攻撃、内部関係者による攻撃から護られる必要があります。そのため、Keeper管理者ロールおよび管理者権限が付与されたその他のロールには2FAの使用が適用されているようにしてください。
管理者がSSOプロバイダを介してKeeperにログインしている場合でも、管理者ロールにはKeeper側で2FAを追加しておきましょう。これにより、IDプロバイダアカウントの乗っ取りやその他の内部関係者の脅威から護られます。
3. SSOの外部で管理者が存在するようにする
KeeperクラウドSSOコネクトを使用することでご利用のSAML 2.0 IDプロバイダからプロビジョンニングおよびユーザー認証が可能となります。
管理者はSSOを使用してKeeper管理コンソールにログインできますが、少なくとも管理者アカウントの1つではマスターパスワードでKeeperにログインできる状態にしておきましょう。すべての管理者がSSOに依存すると、新しいデバイスを承認する管理者が存在しない状況が発生する可能性があるためです。SSOプロバイダが機能停止状態に陥ると、全員がアクセスできなくなる可能性があります。SSOがダウンした場合に備えて、SSOログインなしの「緊急用管理者アカウント」を作成しておきましょう。このアカウントには強力なパスワード、2FA、任意で接続IPをホワイトリストするなど多くの保護を追加しておきましょう。
管理者全員がSSOを使用していて、さらに新しいデバイスを使用している状態でそれらのデバイスを承認できない状況では、Keeperのサポートからアクセス回復のためのお手伝いはできません。仕様上、Keeperはゼロ知識のプラットフォームであり、弊社サポートチームはSSO対応デバイスの承認や、ユーザーのデバイス暗号化データキーの回復には対応できません。
4. 権限を縮小する
Keeperのロール強制ポリシーによりノードおよびサブノード内に管理者ロールを作成できます。管理者には最小限の権限を付与するようにしましょう。
効率を考えて管理者の総数を最小限に減らします。
管理ロール内の権限を削減します。たとえば、管理者がロールの管理権限を必要としない場合は、その権限を削除します。
ボルトの内容を転送するために元メンバーの古い管理者アカウントを必要以上に長くロック状態にしないようにします。
5. SSOプロバイダをロックダウンする
KeeperをSSO IDプロバイダと連携させる場合は、IDプロバイダにMFAポリシーが設定され、権限が制限されているようにしてください。IDプロバイダからの指導と最善の対応策に従い、管理者アカウントにはジョブの実行に必要な最小限の特権のみ付与されているようにします。
6. 適宜アカウント復元機能を無効にする
他のSaaSプラットフォームと同様、アカウントリカバリ機能は、主要な認証方法が失われたり忘れられた場合にアカウントへのアクセスを復元する手段となります。Keeperではデフォルトでリカバリフレーズ (自動生成された24語のセット) を作成して、ボルトへのアクセスを復元できます。リカバリフレーズによりマスターパスワード方式と同様のキー導出方式を使用してユーザーのデータキーが暗号化されます。
AzureやOktaのようなシングルサインオン製品を使用しているユーザーに展開する場合、認証はアイデンティティプロバイダに委ねられるため、本機能の必要性や有用性がない場合があります。その場合はアカウント回復をオプションとして持たないようにするのが最善です。
AzureやOktaのようなシングルサインオン製品を使用しているユーザーにデプロイする場合は認証がIDプロバイダに委ねられるため、アカウントリカバリ機能は必要がないか動作が保証されない場合があります。そのため、そのような場合はオプションとしてアカウント復元機能を使用しないのが最善となります。
アカウント回復を無効にするには、[ロール] > [強制ポリシー] > [アカウント設定] > 「アカウント復元のためのリカバリーフレーズを無効にする」を選択します。
アカウントへのアクセスを失った場合でもリカバリフレーズが安全な場所に保存されていると、アカウント復元を実行できます。
7. 強力なマスターパスワードを適用
マスターパスワードでログインするユーザーの場合、データキーを復号化および暗号化するためのキーは、ユーザーのマスターパスワードからパスワードに基づくキー導出関数 (PBKDF2) を使用して導出されます (デフォルトでは100万回反復)。ユーザーがマスターパスワードを入力すると、キーがローカルで導出されてからデータキーが復号化されます。その後データキーが個々の記録キーとフォルダキーの復号化するために使用されます。その後、記録キーによって保存されている各記録の内容がローカルで復号化されます。
Keeperには、AWS環境における不正アクセスに対する対策として、デバイス承認、スロットリングなどの保護策が実装されています。複雑なマスターパスワードを適用することで、ユーザーのボルトへのオフラインでの総当たり攻撃のリスクを大幅に軽減します。
米国国立標準技術研究所 (NIST) からは、Special Publication 800-63B にてパスワードのガイドラインが提供されており、使いやすさと安全性のバランスが提唱されています。つまり、パスワードは覚えやすく、かつ推測されにくいものでなければなりません。NISTの資料では、最低8文字が推奨されていますが、文字数を増やすとパスワードの推測や解読がもっと難しくなります。Keeperでは最低12文字を適用していますが、さらに16文字以上に増やすと良いでしょう。
パスワードの複雑さはロールごとに設定できます。ユーザーガイドのマスターパスワードの複雑さのページをご参照ください。
8. エンドユーザーに対する二要素認証の適用
二要素認証 (2FA) は多要素認証 (MFA) とも呼ばれ、認証に2つ目の要素を加えることにより、ボルトヘアクセスする際の安全性が向上します。最初の要素は知的要素と呼ばれ、マスターパスワード (またはSSO) が該当します。2つ目の要素は所有要素となり、携帯端末 (SMSテキストやTOTPアプリ) やYubiKey、Google Titanキーなどのハードウェアデバイスを使用できます。
Keeperのクラウドインフラストラクチャにはブルートフォース攻撃に対する緩和策が実装されていますが、2つ目の認証要素を追加すると、攻撃者がユーザーのボルトにアクセスすることが非常に困難となります。ロール単位の適用を使用すると、組織内の全ユーザーに対してボルトへのログインに2FAの使用を義務付けることができます。
SSOを使用するユーザーの場合、少なくともIDプロバイダで2FAが設定されているようにする必要があります。Keeperでは、SSO認証中にIDプロバイダからの署名付きアサーションがチェックされます。セキュリティを強化するために、IDプロバイダだけでなくKeeper側でも2FAを有効にすることもできます。 二要素認証の設定については、ユーザーガイドの二要素認証のページをご参照ください。
9. IPのホワイトリストを設定
ユーザーが承認された場所やネットワーク以外からボルトにアクセスできないようにするには、IPアドレスのホワイトリストを有効にします。デバイスが承認されたネットワーク上にある際にのみ指定のユーザーがボルトにアクセスできるようにするロール単位の適用項目として設定します。
最低でもKeeperで管理者権限を持つユーザーは特定のIPまたはIP範囲からのみアクセスできるようにしておきましょう。これにより、悪意のある内部関係者からの攻撃やIDプロバイダによる乗っ取り攻撃を防止できます。IPの限定が不可能な場合は、MFAを適用します。
この機能を使用するロールの設定の詳細は、IPのホワイトリストのページをご覧ください。
10. 必要に応じてアカウント移管ポリシーを有効にする
アカウント移管機能は、メンバーが組織を去った場合に管理者がそのメンバーのボルトの内容を回復するための仕組みとなります。この機能は任意でご利用になれ、ユーザーの暗号化キーを受け渡すための特定の手順が必要となるため、Keeper導入の初期段階でKeeper管理者が設定しておく必要があります。
詳しい手順については、アカウント移管ポリシーのページをご覧ください。
ユーザーがマスターパスワードを使って認証する場合や、組織が特定のユーザーのボルトが失われる心配がある場合には、アカウント移管ポリシーを設定しておきましょう。
アカウント移管ポリシーにより、管理者には管理対象のユーザーのボルトを移管する権限が付与されます。重役やルートレベルの管理者など、状況のいかんに関わらずボルトの移管を希望しないユーザーがいる場合は、アカウント移管ポリシーが有効になっていないロールに配置することも可能です。
11. アラートの作成
Keeperの高度なレポートシステムにはアラート機能が搭載されており、重要なイベントが発生した場合はユーザーと管理者に通知されます。最善の対応法として、Keeper管理者向けに推奨アラートの一覧をご用意しました。外部と内部の両方で不審なアクティビティが通知されるよう、主要な管理イベントのアラートを有効にしておきましょう。
12. 未承認の拡張機能のインストールを禁止
一般的なセキュリティ対策として、エンドユーザーには未承認のサードパーティ製ブラウザ拡張機能をインストールできないようにしておきましょう。通常より多くのアクセス許可を持つブラウザ拡張機能は、ウェブサイトまたはブラウザベースのアプリケーション内のあらゆる情報にアクセスできる可能性があります。デバイス管理ソフトウェアを参照して、Keeperが許可されていること、および未承認の拡張機能がブロックまたは削除されているようにしてください。
13. 組織全体に展開
様々なデバイス、アプリケーション、ウェブサイトにわたってユーザーを保護するには、特権認証情報を扱う組織全体のユーザーにKeeperを導入する必要があります。安全なパスワードマネージャーを使用しない管理者または特権ユーザーは、組織を危険にさらす可能性があります。
Last updated
