セキュリティの推奨設定

Keeperのセキュリティポリシーと設定に関する管理上の推奨事項

共有セキュリティモデル

Keeper は、Keeper 管理者が設定した制約内で顧客データを保護するためのポリシーと制御を備えた暗号化プラットフォームです。 この共有セキュリティモデルでは、最小限の権限、緊急アクセス、および最高レベルのデータ保護を確保するために推奨ポリシーを実装する責任はお客様にあります。

このドキュメントでは、対象ユーザーに可能な限り最高のエクスペリエンスを確保しながら、保存されたデータを保護するのに役立つ重要な推奨事項とポリシーについて概要を説明します。

1. Keeper管理者を2人作成

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

「Keeper管理者」ロールには、そのロールのユーザーが少なくとも2人必要です。一方のアカウントが失われたり、アクセスできなくなったりした場合に備えて、副管理者をこのロールに追加することを強くお勧めします。 Keeperの従業員は、ユーザーを管理者ロールに昇格させることも、管理者のマスターパスワードをリセットすることもできません。

仕様上、すべてのKeeper管理者がアクセスを失った場合、Keeperのサポートチームは権限を昇格できず、KeeperサポートチームはSSOユーザーデバイスを承認できません。ルートレベルのKeeper管理者アクセス権を持つ緊急アクセス用アカウントがあることを確認してください。

2. Keeper管理者ロールに2FAを適用する

Keeper管理者はプラットフォーム内で高い権限を持っており、外部攻撃、IDプロバイダー攻撃、および内部関係者による攻撃ベクトルの両方から保護する必要があります。Keeper管理者ロールおよび管理者権限を持つその他のロールが2FAの使用を強制していることを確認してください。

管理者がSSOプロバイダーを使用してKeeperにログインしている場合でも、管理ロールのKeeper側に2FAを付加的なレイヤーとして追加することをお勧めします。これにより、IdPアカウントの乗っ取りやその他の内部関係者の脅威から保護されます。

3. SSOの外部で管理者が存在することを確認

Keeper SSO Connect Cloudは、SAML 2.0アイデンティティプロバイダを使用してユーザーをプロビジョニングおよび認証する機能をお客様に提供します。

Keeperは管理者がSSOでKeeper管理コンソールにログインする機能をサポートしていますが、少なくとも1つの管理者アカウントがマスターパスワードでKeeperにログイン可能にすることが重要です。これは、すべての管理者がSSOに依存している状況が発生してしまい、新しいデバイスを承認する管理者がいなくなってしまうと困るためです。または、SSOプロバイダが停止し、すべての人がロックアウトされる可能性もあるでしょう。SSOがダウンした場合に備えて、SSOログインなしの「緊急用管理者アカウント」を持つことを推奨します。 そして、このアカウントに強力なパスワード、2FA、オプションでIPホワイトリスト化などの多くの保護を追加することを提案します。

すべての管理者がSSOを使用している状況で、すべての管理者が新しいデバイスを使用している(承認できない)場合、Keeperのサポートチームは回復支援をすることができません。設計上、Keeperはゼロ知識のプラットフォームであり、私たちのサポートチームはSSO対応デバイスを承認したり、ユーザーのためにデバイス暗号化データキーを回復する機能は持ち合わせていません。

4. 権限を減らす

Keeperのロール強制ポリシーにより、顧客はノードおよびサブノード内に管理ロールを作成できます。管理者には最小限の権限を常に確保することが重要です。

  • 効率的に運用するために管理者の総数を最小限に減らす。

  • 管理ロール内の権限を削減します。たとえば、管理者がロールを管理する機能を必要としない場合は、その権限を削除します。

  • 元従業員の古い管理者アカウントを、ボルトの内容を転送するために必要以上に長くロック状態にしておかないでください。

5. SSOプロバイダをロックダウンする

KeeperをSSO IDプロバイダと統合する場合は、IdPがMFAポリシーでロックダウンされ、権限が制限されていることを確認してください。IDプロバイダのガイダンスとベストプラクティスに従って、管理アカウントがジョブの実行に必要な最小限の特権で最小化されていることを確認します。

6. 適切な場合にアカウントの回復を無効にする

あらゆるSaaSプラットフォームと同様に、Keeperのアカウント回復機能は、主要な認証方法が失われたり、忘れたりした場合に、アカウントへのアクセスを回復するための手段をエンドユーザーに提供します。Keeperでは、デフォルトで、ユーザーはリカバリーフレーズ(Keeperボルトへのアクセスを回復するために使用できる24語のシンプルな自動生成セット)を設定する機能を備えています。リカバリーフレーズは、マスターパスワードと同様の鍵派生方式を使用して、ユーザーのデータキーを暗号化します。

AzureやOktaのようなシングルサインオン製品を使用しているユーザーに展開する場合、認証はアイデンティティプロバイダに委ねられるため、本機能の必要性や有用性がない場合があります。その場合はアカウント回復をオプションとして持たないようにするのが最善です。

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

該当するユーザーがリカバリーフレーズを安全な場所に保管する場合、アカウント回復を有効にすることができます。

7. 強固なマスターパスワードを強制

マスターパスワードでログインしたユーザーの場合、データキーの復号化および暗号化のための鍵は、パスワードベースの鍵導出関数(PBKDF2)を用いてユーザーのマスターパスワードから導出され、デフォルトでは1,000,000回の繰り返しが行われます。ユーザーがマスターパスワードを入力した後、ローカルで鍵が導出され、データキーの暗号化が解除されます。データキーが復号化された後、個々の記録キーとフォルダキーを復号化するために使用されます。記録キーはその後、保存された各記録内容をローカルで復号化します。

Keeperは、Amazon AWS環境において、不正アクセス、デバイス検証、スロットリングおよびその他の保護に対するいくつかの緩和策を実装しています。強力なマスターパスワードの複雑性を強制することで、ユーザーの暗号化されたボルトに対するオフラインの総当たり攻撃のあらゆるリスクを大幅に軽減します。

米国国立標準技術研究所(NIST)は、パスワードのガイドラインを提供しています。Special Publication 800-63B. このガイドラインは、ユーザビリティとセキュリティのバランスを促進するもので、言い換えれば、パスワードは覚えやすいが推測されにくいものでなければなりません。NISTのガイドラインでは、最低8文字が推奨されていますが、これ以上の文字数は最終的に推測/クラックされにくいパスワードになります。Keeperは少なくとも12文字を強制していますが、16文字以上にすることをお勧めします。

パスワードの複雑さは、ロール(役割)ごとに設定することができます。ガイドのマスターパスワードの複雑さの強制設定を参照してください。

8. エンドユーザーに対する二要素認証の強制

二要素認証(2FA)は、一般に多要素認証(MFA)とも呼ばれ、ボルトにアクセスするためのセキュリティレイヤーをもう1つ追加します。最初のレイヤーはユーザーが知っている情報で、マスターパスワードまたはSSOです。 2番目のレイヤーはユーザーが所有する物です。これはモバイルデバイス(SMSテキストやTOTPアプリケーション)、またはYubiKeyやGoogle Titanキーのようなハードウェアデバイスを使用することができます。

Keeperのクラウドインフラストラクチャはブルートフォース攻撃に対するいくつかの緩和策を実装していますが、第2の認証手段を追加することで、攻撃者がユーザーのボルトにアクセスすることがかなり難しくなります。ロールベースの強制を使用することで、企業の全ユーザーに自分のボルトアカウントでの二要素認証の設定を確実に強制できます。 SSOに対応するユーザーは、少なくともIdPで二要素認証が設定されていることを確認する必要があります。 KeeperはSSO認証中にIDプロバイダからの署名されたアサーションをチェックします。さらにセキュリティを強化するために、IdPに加えてKeeperアカウントでも二要素認証を有効にすることができます。 二要素認証を設定するには、ガイドのこちらのセクションをご参照ください。

9. IPのホワイトリスト化を設定

ユーザーが承認された場所やネットワーク以外から業務用ボルトにアクセスできないようにするには、管理者がIPアドレスホワイトリスト化を有効にするべきです。 これはロールベースの強制設定で、デバイスが承認されたネットワーク上にある場合にのみ、ユーザーがボルトにアクセスできるようにします。

少なくとも、Keeperの管理者権限を持つユーザーは、特定のIPまたはIP範囲にロックダウンする必要があります。これにより、悪意のある内部関係者による攻撃やIDプロバイダの乗っ取り攻撃ベクトルが防止されます。これが不可能な場合は、MFAが強制されていることを確認してください。

この機能を使用するロールの設定の詳細は、IPのホワイトリスト化のセクションをご覧ください。

10. 必要に応じてアカウント移管ポリシーを有効にする

アカウント移管は、従業員が突然退職または解雇された場合に、指定された管理者がユーザーのボルトの内容を回復するためのメカニズムを提供します。これは、ユーザーの暗号化キーをエスクローするための特定の手順が必要なため、Keeperロールアウトの最初の展開段階でKeeper管理者が構成する必要があるオプションの機能です。

詳しい手順については、アカウント移管ポリシーガイドをご覧ください。

ユーザーがマスターパスワードで認証している場合、および企業が特定のユーザーのボルトの損失について懸念がある場合は、アカウント移管ポリシーをお勧めします。

アカウント移管ポリシーでは、管理者に、管理対象ユーザーのKeepeボルトの転送を実行する権限が割り当てられます。 いかなる状況であってもボルトの転送を希望しないユーザー (経営幹部やルートレベルの管理者など) がいる場合、これらのユーザーを移管ポリシーが有効になっていないロールに配置することができます。

11. アラートの作成

Keeperの高度なレポートシステムは、重要なイベントをユーザーと管理者に通知する組み込みのアラート機能を提供します。ベストプラクティスとして、Keeper管理者が設定できる推奨アラートリストを作成しました。主要な管理イベントに対してアラートを有効にして、外部と内部の両方の脅威による不審なアクティビティを通知する必要があります。

12. 信頼されていない拡張機能のインストールを禁止

一般的なセキュリティ対策として、Enterpriseユーザーには、エンドユーザーが未承認のサードパーティ製のブラウザ拡張をインストールする機能を制限することを推奨します。 権限が昇格されたブラウザ拡張を使用すると、任意のウェブサイトまたはブラウザベースのアプリケーション内のすべての情報にアクセスできる可能性があります。 デバイス管理ソフトウェアを調べて、Keeperが許可され、未承認の拡張機能がブロックまたは削除されていることを確認してください。

13. 組織全体に展開

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

Last updated