Keeperの信念：認証情報とデータ保護への徹底した取り組み

概要

Keeper Security, Inc. は、Keeper モバイルおよびデスクトップ・セキュリティ・ソフトウェアで顧客の情報を保護することに情熱を注いでいます。何百万もの消費者と企業がパスワードと個人情報の保護およびアクセスにおいて Keeper を信頼しています。

ユーザーのみな様へ最新テクノロジーと保護機能を提供すべく、Keeper ソフトウェアは随時改善ならびにアップデートされています。当ページには、現時点で公開されているバージョンの Keeper セキュリティアーキテクチャ、暗号化方式、ホスティング環境の概要が掲載されています。本文書には暗号化ならびにセキュリティ方式を含む技術的詳細に関する概要が記載されています。

当社の個人情報保護方針および利用規約については、以下のリンクから当社ウェブサイトでご覧いただけます：

ゼロトラスト・プラットフォーム

Keeper ではゼロトラストアーキテクチャを利用することにより、ウェブサイト、アプリケーション、またはシステムにアクセスする前に、すべてのユーザーが検証および認証される必要があります。

Keeper Enterprise Password Management (EPM) では、パスワード使用状況をモニタリングし、セキュリティのベストプラクティスを強制する権限を IT 管理者に与えることで、従業員のパスワード習慣を完全に可視化し、コントロールすることができます。

Keeper Secrets Manager (KSM) は、SDK と CI/CD 統合により、インフラシークレット、SSH 鍵、API 鍵、証明書を含むすべてのクレデンシャルを管理するためのプラットフォームをエンジニアリングチームに提供します。

Keeper Connection Manager (KCM) は、DevOps と IT チームに、ウェブブラウザを通して簡単に RDP、SSH、データベース、内部ウェブアプリケーションと Kubernetes エンドポイントへのゼロトラスト・ネットワーク・アクセス (ZTNA) を提供する、リモートデスクトップ・ゲートウェイです。

Keeperによるクラス最高のセキュリティの詳細

ボルトデータの暗号化

Keeper は最小特権に基づく多層暗号化モデルを提供します。256 ビット AES 記録レベルの鍵とフォルダレベルの鍵がクライアントデバイス上で生成され、保管された各ボルト記録を暗号化します。ログイン、ファイル添付、TOTP コード、支払い情報、URL、カスタムフィールドを含む、ボルト記録およびそのコンテンツのすべてが完全に暗号化されます。

暗号鍵は、ゼロ知識を維持し、記録やフォルダの共有などの高度な機能をサポートするために、デバイス上でローカルに生成されます。ゼロ知識とは、各ユーザーが Keeper ボルト内のすべての個人情報の暗号化と復号を完全にコントロールできることを意味し、保管された情報は本人以外の誰にも（Keeper の従業員でさえも）アクセスできません。

記録鍵とフォルダ鍵は、各ユーザーに固有のもので、ユーザーのデバイス上で生成される 256 ビット AES データキーによって暗号化されます。

ユーザーのデバイス上では、ローカルのオフラインキャッシュを暗号化するための別の 256 ビット AES クライアント鍵が生成されます（企業の管理者がオフラインアクセスを許可している場合）。最後に、次のセクションで説明するように、256 ビットの AES データ鍵が別の鍵で暗号化されます。

ボルト暗号化のメソッド

Keeper はユーザーのログイン方法によって、異なる方法でデータを暗号化します。消費者と家族プランのメンバーには、マスターパスワードと生体認証が使用されます。SSO でログインするビジネスおよびエンタープライズユーザーでは、安全でパスワードレスな体験のために楕円曲線暗号化を利用します。

マスターパスワードでログインするユーザーの場合：データキーを復号および暗号化するための鍵は、password-based key variation function（PBKDF2）を利用し、ユーザーのマスターパスワードから 1,000,000 回の反復で導出されます。ユーザーがマスターパスワードを入力した後、鍵はローカルで導出され、その後データ鍵がアンラップされます。データキーは復号され、個々の記録鍵とフォルダ鍵をアンラップするために使用されます。各鍵の復号により、記録コンテンツがユーザーのデバイスにローカルに保管されます。

SSO またはパスワードレス技術でログインするユーザーの場合： デバイスレベルでのデータの暗号化と復号には、楕円曲線暗号が使用されます。ローカル ECC-256 (secp256r1) 秘密鍵は、データキーの復号に使用されます。データキーが復号された後、個々の記録鍵とフォルダ鍵をアンラップするに使用されます。その後、記録鍵が、保存されている各記録のコンテンツを復号します。暗号化されたデータキーは、プッシュシステムまたは鍵交換サービス（「デバイス承認」と呼ばれる）を通じて、ユーザーのデバイス間で送信されます。ゼロ知識を維持するため、「デバイス承認」はエンドユーザーによりローカルで管理されます。

SSO復号化モデル

初回デバイスフロー (新規ユーザーのオンボーディング)

1. データ鍵、共有鍵ペア、デバイス EC 秘密鍵/公開鍵ペアが生成される
2. データ鍵がデバイス EC 公開鍵で暗号化され、クラウドに保存される（DEDK）
3. ユーザがアイデンティティプロバイダ（IdP）でログインする
4. IdP ログイン後、署名された SAML アサーションが Keeper によって検証される
5. ボルトが作成され、ユーザがオンボーディングされる

既存のデバイスフロー

1. ユーザがアイデンティティプロバイダ（IdP）でログインする
2. IdP ログイン後、署名された SAML アサーションが Keeper によって検証される
3. Keeper がデバイスで暗号化されたデータキー (DEDK) をユーザーに送信する
4. デバイス EC 秘密鍵でデータ鍵が復号される
5. データキーがフォルダ鍵と記録鍵を復号する
6. 記録鍵が記録のコンテンツを復号する

新規または未認識のデバイスフロー

1. 新規デバイスごとに、EC 秘密鍵と公開鍵のペアが生成される
2. ユーザがアイデンティティプロバイダ（IdP）でログインする
3. IdP ログイン後、署名された SAML アサーションが Keeper によって検証される
4. デバイスは、Keeper Push、管理者承認、またはKeeper Automator サービス経由で「承認」される (*下記のデバイス承認を参照のこと)
5. 承認プロセス中、データキーは新規デバイスの公開鍵で暗号化される
6. デバイスで暗号化されたデータキー（DEDK）がユーザーに送信される

デバイス承認

• デバイス承認は、ゼロ知識を維持しながら、ユーザーのデータキーを新しいデバイスに安全に送信するメカニズムです
• ユーザーは、新規デバイスの公開鍵でデータキーを暗号化することで、そのデバイスを承認することができます
• 管理者は管理コンソール、Commander またはKeeper Automator サービスからデバイスを承認することができます
• 管理者はユーザーのデータキーを復号し、新規デバイスの公開鍵でデータキーを再暗号化します
• Keeper Automator サービスは、顧客のインフラ上で自動デバイス承認を実行することができます
• Keeper Automator は、SAML 署名をチェックし、データキーをアンラップし、新規デバイスの公開鍵でデータキーを暗号化します

詳細については、Keeper Automator サービスをご覧ください。

SSOコネクトクラウドのデバイスレベルのセキュリティ

SSO Connect Cloud ユーザーに対しては、楕円曲線秘密鍵が生成され、各デバイスでローカルに保存されます。最新のウェブブラウザと Electron ベースの Keeper デスクトップアプリケーションでは、Keeper ボルトはローカルデバイスの EC 秘密鍵（「DPRIV」）をエクスポート不可能な CryptoKey（暗号鍵）として保存します。iOS と macOS デバイスでは、キーチェーンに保存されます。Android デバイスでは、鍵は Encrypted Shared Preferences を利用し、Android Keystore で暗号化されます。利用可能な場合は各オペレーティングシステムの安全なストレージメカニズムを利用します。

デバイス秘密鍵は、ボルトデータの暗号化または復号に直接使用されることはありません。アイデンティティプロバイダからの認証に成功すると、ボルトデータを復号するのに（保存されていない）別の鍵が使用されます。したがって、ローカルのデバイス秘密鍵をオフラインで抽出しても、ユーザのデータボルトを復号することはできません。

保存データの暗号化

Keeper は Keeper プラットフォームとアーキテクチャをホストするために AWS を使用しています。弊社の AWS データセンターは複数の地域に位置しており、顧客は Keeper テナントを任意の主要地域でホストすることができます。これにより、顧客のデータとプラットフォームへのアクセスは、特定の地域に隔離されます。

ボルトの保存データは、AES-256 GCM を使用してユーザーのデバイス上でローカルに暗号化され、転送中の暗号化されたデータは、ペイロードに暗号化レイヤーを追加した TLS 1.3 で暗号化されます。顧客データは、記録レベルの暗号化により隔離されています。

Keeper の暗号化モデルは、以下のような構造に従います：

• すべてのデータボルトは、GCM モードでクライアント側で生成された独自の 256 ビット AES 鍵によって暗号化されます。
• 共有フォルダ内のすべての記録レベル鍵は、256 ビット AES 共有フォルダ鍵でラップされます。
• ボルトユーザーの記録鍵とフォルダ鍵は、データキーと呼ばれる別の 256 ビット AES 鍵で暗号化されます。
• KSM（Keeper Secrets Manager）の場合、ユーザーの記録鍵とフォルダ鍵は 256 ビット AES アプリケーション鍵で暗号化されます。
• マスターパスワードでログインするユーザーの場合は、データを復号および暗号化するための鍵がマスターパスワードから導出されます。
• SSO またはパスワードレス技術でログインする場合、デバイスでデータを暗号化および復号するために楕円曲線暗号が使用されます。
• すべての暗号化されたペイロードは Keeper サーバーに送信され、MITM（中間者）攻撃から保護するために、TLS で 256 ビットの AES 送信鍵でラップされます。鍵はクライアント上で生成され、サーバーの公開楕円曲線鍵を介して ECIES 暗号化を使用して転送されます。
• 2026年第1四半期より、送信キーをさらに保護する追加の暗号化レイヤーとして、量子耐性暗号 (QRC) の導入を開始しました。
• ユーザー間の安全なシークレット共有には楕円曲線暗号鍵配布が使用されます。

レコードのバージョン管理

Keeper は、ユーザーのボルトに保存されたすべての記録の完全に暗号化されたバージョン履歴を維持し、重要なデータが失われることはないという信頼を提供します。Keeper クライアントアプリケーションから、ユーザーは記録の履歴を調査し、個々のボルト記録を復元することができます。Keeper に保存されたパスワードまたはファイルが変更または削除された場合、ユーザーは常にポイントインタイムリストアを実行することができます。

Keeper Business

Keeper Business を購入したお客様には、ユーザーとデバイスをコントロールするための特別なレイヤーが提供されます。Keeper 管理者はクラウドベースの管理コンソールへのアクセスを利用でき、ユーザーのオンボーディング、オフボーディング、ロールベースの許可、委任管理、チーム、Active Directory/LDAP 統合、二要素認証、シングルサインオン、およびセキュリティ強制ポリシーについて完全に制御することができます。Keeper のロールベースの強制ポリシーは完全にカスタマイズ可能で、どんな規模の組織にも拡張可能です。

保存データの超暗号化

デバイスで暗号化された暗号文のみを AWS インフラに保存することに加え、エクスポート不可能な鍵を使用して、マルチリージョンのハードウェアセキュリティモジュール（HSM）で超暗号化を実行します。

バックアップの暗号化と保護

製品/ユーザーレベルでは、Keeper のソフトウェアはすべての記録の完全なリビジョン履歴を保持します。そのため、ユーザーが復旧を必要とする場合、ユーザーインターフェイスを通じて、保存された Keeper 記録の以前のバージョンをいつでも無制限に表示し、元に戻すことができます。

Keeper の暗号化データベースとファイルオブジェクトは、システムレベルでは災害復旧のために複数の地理的な地域に複製され、バックアップされています。すべてのバックアップは、デバイスが生成した暗号文の超暗号化に加え、AES-256 で暗号化されています。

法人のお客様でリカバリー支援が必要な場合 (例: 誤ってボルトや共有フォルダを削除してしまったケースなど)、Keeperのサポートチームが30日以内であれば任意の時点 (分単位) へのリカバリーを支援します。有料オプションとして、ユーザー復元、ボルト復元、エンタープライズ全体の復元など、あらゆるリカバリーに対応可能です。

アカウントの復元

マスターパスワードを紛失または忘れた場合、24 文字のリカバリーフレーズで Keeper ボルトへのアクセスを回復することができます。

Keeper は暗号化ウォレットを保護するために使用される同様の BIP39 単語リストを使用してリカバリーフレーズを実装しました。BIP39 で使用される単語リストは、256 ビットのエントロピーで暗号鍵を生成するために使用される 2048 文字のセットです。この復元方法は、一般的なビットコインや暗号通貨のウォレットでよく使用されているものです。BIP39 リストの各単語は、可視性を向上させ、復元プロセスのミスを少なくするために慎重に選択されています。ユーザーはリカバリーフレーズを書き留め、ボルトなどの安全な場所に保管する必要があります。

リカバリーフレーズは、ユーザーのデータキーのコピーを暗号化する 256 ビット AES 鍵を生成します。アカウントを復元してマスターパスワードをリセットするには、リカバリーフレーズと電子メール認証および二要素認証（2FA）が必要となります。

エンタープライズ管理者は、ロール強制ポリシーレベルでアカウント回復を無効にすることができます。

エンタープライズ暗号鍵

Keeper Enterprise と Business のお客様は、ロールベースのアクセスポリシー、プロビジョニング、認証、管理など、Keeper プラットフォームで利用できる様々な異なる機能を管理することができます。

管理機能は Keeper プラットフォームによって暗号化と認証の両方で保護されています。認証は、指定されたユーザーのみが特定の機能を実行できることを保証します。暗号化は、指定された管理者はボルトデータまたは企業で管理された鍵を含む機能のみを物理的および暗号的に実行できるようにすることを保証します。この例としては、以下のようなものがあります：

• Keeper のプラットフォームは事実上の鍵管理プラットフォームであり、ユーザーと管理者は自分の秘密鍵を完全にコントロールすることができます。
• 公開鍵と秘密鍵のペアは、デバイス、ユーザー、チームの作成に使用されます。
• ボルトの移転とデバイス承認のロールポリシーで、公開鍵と秘密暗号鍵が使用されます。
• 楕円曲線（EC）鍵ペアは、ユーザー間および個人ユーザーからエンタープライズレベルの管理者へのデータ共有に使用されます。
• 記録パスワードの強度など、機密性の高い利用データは、管理者だけが復号できるエンタープライズ公開鍵で暗号化されます。
• 各エンタープライズユーザーのボルト記録の記録タイトル、URL、記録タイプフィールドは、エンタープライズ公開鍵で暗号化され、コンプライアンスレポート特権を割り当てられた管理者により、Keeper 管理コンソール内で復号することができます。

デバイス承認

ユーザーがアカウントにログインする前には、デバイス承認と検証ステップを通過する必要があります。デバイス承認はアカウントの列挙を防ぎ、ブルートフォース攻撃から保護します。

マスターパスワードでログインするお客様は、次に挙げられるいくつかのメソッドを使用してデバイス認証を実行することができます：

• メール認証コード
• TOTP またはテキストメッセージからの 2FA コード入力
• Keeper Push^™ を使って承認されたデバイスにメッセージを送信

SSO Connect Cloud で認証するお客様の場合、デバイス承認は鍵転送で行われ、ユーザーの暗号化データ鍵がデバイスに配信され、ユーザーの楕円曲線秘密鍵を使用してローカルで復号されます。デバイス承認メソッドは以下のとおりです：

• 既存のユーザーデバイスへの Keeper Push（プッシュ通知を使用）
• Keeper 管理コンソールを介した管理者承認
• Keeper Automator サービスによる自動承認
• Commander CLI による自動承認

デバイス承認の詳細をご覧ください

データのプライバシー

Keeper は GDPR に準拠しており、欧州連合および世界中のお客様に向けて、当社のプロセスと製品が GDPR コンプライアンスを維持することをお約束します。 弊社は、米国商務省が定めるEU-米国データプライバシーフレームワーク (EU-U.S. DPF)、EU-U.S. DPFの英国拡張版、ドイツ連邦データ保護法 (BDSG)、およびスイス-米国データプライバシーフレームワーク (Swiss-U.S. DPF) に準拠しています。

Keeper の GDPR プライバシーポリシーをご覧ください。

Keeper のアプリケーションには、トラッカーまたはトラッキングを実行するサードパーティのライブラリは含まれていません。例として、本レポートは Keeper の Android アプリに関する情報を提供し、トラッカーがインストールされていないことを示しています。

データの分離

Keeperは完全管理型のSaaSプラットフォームで、地理的に分離された複数のAWSデータセンターにデータをホストしています。組織はご希望のリージョンでKeeperテナントをホストすることができます。顧客データとプラットフォームへのアクセスは、その特定のリージョン内で隔離されています。

利用可能なリージョン：

• アメリカ合衆国 (US)
• 米国政府クラウド (US_GOV)
• ヨーロッパ (EU)
• オーストラリア (AU)
• 日本 (JP)
• カナダ (CA)

通信中のデータの暗号化

Keeper ボルトは API によって保護されており、ユーザーのデバイス上での認証を通して確認されます。

• ユーザーはログイン時にセッショントークンを取得し、各 API コールで送信します。
• セッショントークンはバックエンドサーバーで管理、制御されます。
• ログインは、マスターパスワード、生体認証、セッション再開、または SAML 2.0 SSO 認証で実行されます。

マスターパスワードを使用する場合、ユーザーデバイスは、PBKDF2-HMAC_SHA256 を 1,000,000 回反復と、ランダムなソルトを使用して 256 ビットの認証鍵を導出します。認証ハッシュは、SHA-256 を使用して認証鍵をハッシュ化することで作成されます。ログインする際、認証ハッシュは Keeper ボルトに保存されている認証ハッシュと比較されます。ユーザーがログインした後、セッショントークンがサーバー上で作成され、ユーザーに送信されます。クライアントとサーバー間の通信を継続的に使用するには、セッションがアクティブである必要があります。

• Keeper は 256 ビットと 128 ビットの TLS を使用して、ユーザーアプリと Keeper の安全なファイルストレージに保管されたデータを 100%暗号化します。
• Keeper は SHA2 アルゴリズムで署名された TLS 証明書を展開します。SHA2 は現在、商用認証局で利用可能な最も安全性の高い署名アルゴリズムです。SHA2 を使用することで、攻撃者がウェブサイトになりすますために使用できる偽造証明書から保護されます。

Keeperフォースフィールドによるメモリ保護

Keeperフォースフィールドは、Windowsエンドポイント上の機密アプリケーションに対するリアルタイムのメモリ保護により、Keeperのゼロ知識セキュリティモデルを拡張します。保存時および通信中の暗号化に加え、実行中にメモリ上へ復号されたデータへの不正アクセスを防止し、認証情報窃取型マルウェアによる攻撃を阻止します。

従来の暗号化は保存データや通信を保護しますが、実行時メモリは依然として攻撃対象です。Windowsでは同一ユーザーコンテキストで動作するプロセス間のメモリ参照が可能なため、マルウェアが認証情報やセッショントークンなどを抽出するリスクがあります。Keeperフォースフィールドは、OSカーネルレベルで厳格なメモリアクセス制御を行うことで、こうした脆弱性を悪用する不正なアクセスを遮断します。

詳しくはこちらのページをご覧ください。

量子耐性暗号

Keeperは、ストア・アンド・クラック攻撃のような将来的な量子コンピューティングの脅威に備え、ボルトを保護するために量子耐性暗号 (QRC) を採用しています。具体的には、Kyberハイブリッド鍵カプセル化メカニズム (KEM) を実装しています。このハイブリッド方式は、従来型の暗号技術と量子耐性アルゴリズムを組み合わせることで、ユーザー認証およびTLS内での暗号化通信を保護します。実装には実績あるKyberライブラリを活用しており、クライアント単位での段階的な展開が可能で、ブラウザ固有のサポートにも依存しません。これにより、将来的な量子攻撃に対してもユーザーデータを保護します。

量子耐性セキュリティ: 将来の量子攻撃に備え、KyberハイブリッドKEMを統合し、機密データを保護。

ハイブリッド方式: 従来の暗号技術と量子耐性アルゴリズムを組み合わせ、多層防御と後方互換性を実現。

重点的な実装: Keeperの認証プロトコルとTLS内部の暗号化通信を保護。

柔軟な展開: 実績あるKyberライブラリを活用し、クライアント単位で段階的な導入が可能。

ストア・アンド・クラック攻撃への対策: 現在傍受されたデータが、将来の量子解読機能によって解読されることを防止。

クラウド認証

Keeper は最高レベルのプライバシー、セキュリティ、信頼性および透明性を備えた高度なクラウド認証とネットワーク通信モデルを作成しました。この認証モデルの主な特徴は以下の通りです：

あらゆるSAML 2.0プロバイダーとの統合

Keeper は Okta、Microsoft Entra ID (Azure)、AD FS、Google Workspace、Centrify、OneLogin、Ping Identity、JumpCloud、Duo、Auth0 など、すべての SAML 2.0 対応のアイデンティティプロバイダと統合できます。

当社の製品は、2 つの異なる SSO タイプを提供しています： SSO Connect Cloud と SSO Connect On-Prem です。どちらの実装でも、ユーザーにシームレスな認証を提供するゼロ知識アーキテクチャを提供します。

ユーザーのマスターパスワードはネットワーク層を通じて送信されることはありません

ほとんどの SaaS サービスとは異なり、Keeper ユーザーのログイン情報がデバイスを離れることはありません。ユーザーがマスターパスワードを使って Keeper にログインする際、復号のための 256 ビット AES 鍵を導出するためにローカルデバイス上で PBKDF2 が利用されます。追加の PBKDF2 鍵はデバイスレベルで生成され、認証トークンを作成するために HMAC_SHA256 でハッシュ化されます。Keeper はユーザーの復号鍵に対する知識を一切持ちません。

クライアントデバイスとKeeperクラウド間の通信は、傍受や復号化ができないよう保護されています

Keeper のサーバーに送信されるすべての暗号化されたペイロードは、中間者（MITM）攻撃から保護するために、256 ビットの AES 送信鍵と TLS によってラップされます。送信鍵はクライアントデバイス上で生成され、サーバーの公開 EC 鍵を介して ECIES 暗号化を使用してサーバーに転送されます。

新しいデバイスでアカウントにログインするには承認作業が必要です

ユーザーが新規デバイスを使用する場合、承認メソッドを使用せずに Keeper アカウントにログインすることはできません。Keeper は認証スキームに応じて、いくつかのタイプの承認メソッドをサポートしています。

デバイスの承認後、ユーザーがマスターパスワードを入力する前に多要素認証 (MFA) を実施します

ユーザーが MFA を設定または強制している場合、マスターパスワードを入力する前に、まずこのステップを通過する必要があります。

デバイス承認と多要素認証のステップが成功するまではマスターパスワードの入力は行えません

承認メソッドが設定されていない場合、ユーザーはマスターパスワードの入力に進むことができません。この高度な認証は、ブルートフォース攻撃、パスワードスプレー、列挙攻撃、MITM などのよくある攻撃メソッドからユーザーを保護します。

多要素認証 (MFA)

お客様のアカウントへの不正アクセスから保護するために、Keeper は知識要素、所有要素および/または生体要素のうち 2 つ以上の認証要素を必要とする認証へのアプローチである多要素認証（MFA）を提供しています。Keeper で MFA を設定する方法については、こちらをご覧ください。

Keeper は、マスターパスワードまたはデバイスのいずれかが侵害された場合、マスターパスワードと所持しているデバイスを使用して追加のセキュリティレイヤーを提供します。Keeper は FIDO2 WebAuthn ハードウェアキーと TOTP や SMS のようなソフトウェアベースのソリューションをサポートしています。

TOTP MFA/2FAメソッドを使用する場合、Keeperは乱数生成機能を使用して10バイトの秘密鍵を生成します。このコードは約1分間有効で、一度認証が成功すると再利用はできません。Google AuthenticatorやMicrosoft AuthenticatorなどのTOTPアプリケーションに対応しており、DuoやRSA SecurIDのようなMFAサービスとも直接統合できます。

モバイルデバイス上で Google Authenticator、Microsoft Authenticator、またはその他の TOTP アプリケーションなどの MFA 認証機能を使用する場合、Keeper サーバーは秘密鍵を含む QR コード内部的にを生成します。ユーザーが MFA を有効にするたびに、新しい鍵が生成されます。

MFA を有効にするには、Keeper ウェブアプリ、デスクトップアプリまたは iOS/Android アプリの設定画面にアクセスしてください。Keeper Business の管理者は、Keeper 管理コンソールを介して、MFA またはサポートされている MFA メソッドの使用を強制することもできます。

FIDO2 互換の WebAuth のサポートは Keeper を通じて提供され、YubiKey や Google Titan キーのようなハードウェアベースのセキュリティキーデバイスを追加要素として使用できます。パスキーも物理デバイスまたはウェブブラウザを使用する 2FA 方法としてサポートされています。セキュリティキーは、ユーザーが手動でコードを入力することなく、MFA を実行できる安全な方法を提供します。

Android Smart Watch Apple Smart Watch DUO Entrust Google Authenticator Microsoft Authenticator RSA SecureID SMS テキストメッセージ Titan Security Key TOTP Yubico

Keeper Active Directory ／ LDAP Bridge

Keeper Bridge は、ユーザーのプロビジョニングとオンボーディングのために、Active Directory および LDAP サーバーと統合されています。Keeper Bridge の通信は、まずブリッジを管理する特権を持つ管理者によって認証されます。通信キーが生成され、その後のすべての通信のために Keeper と共有されます。通信キーを使用するのは、ブリッジの初期化を除く、ブリッジによって実行されるすべての操作の認証です。通信キーはいつでも再生成することができ、30 日ごとに自動的にローテーションされます。

通信キーは通信専用であり、危殆化したキーはデータや許可を失うことなく、再初期化または失効される可能性があることを意味します。

Keeper Bridge は、ロールまたはユーザーに特権を与えることはできません強制鍵が必要ない限り、特権を持つロールにユーザを追加することができます。Keeper Bridge は、それ自体またはユーザーを、管理しているツリーの部分より上位に昇格させることはできません。すべての操作がブリッジで利用できるわけではありません。つまり、ブリッジはアクティブなユーザーを無効にすることはできますが、ユーザーを削除することはできません。管理者は、ユーザーを削除するか移転するかを選択する必要があります。

MFAを利用したSSO認証

Keeperを、Entra ID / Azure AD、Okta、Ping、Google Workspaceやその他のSAML 2.0 IDプロバイダーを利用して導入する場合、IdPログインのプロセス中にMFAを完全に管理できます。また、Keeperはすべてのデバイスタイプとアプリケーションに対してAzureの条件付きアクセスポリシーをサポートしています。

0MFA は ID プロバイダ側と Keeper 側の両方で実施することができます。例えば、ユーザーが ID プロバイダで MFA ステップを通過した後、Keeper インターフェイスで 2 つ目の MFA ステップを通過するように強制することができます。このポリシーは Keeper 管理者が強制することができます。

Amazon Web Services CAS Centrify DUO F5 Google Workplace IBM Security JumpCloud Microsoft ADFS Onelogin Okta Ping Identity

SSOコネクトクラウドによるSAML 2.0認証

Keeper SSO Connect Cloud により、エンタープライズのお客様は Keeper を SAML 2.0 準拠の ID プロバイダと完全に統合し、ユーザーに暗号化ボルトを展開することができます。

KeeperのSAML実装により、ユーザーはSSOのIDプロバイダを通じて認証を行い、その後自身のデバイス上でボルトの暗号文を復号できます。各ユーザーのデバイスには、それぞれ固有の楕円曲線 (EC) 鍵ペアと、デバイスで暗号化されたデータキーが存在します。さらに、各ユーザーには専用の256ビットAESデータキーが割り当てられています。新しいデバイスでKeeperにサインインする際には、既存のデバイスによる承認が必要です。もしくは、管理者や権限を持つ自動化サービスによって承認される場合もあります。デバイスが承認されると、安全な方法でデータキーが共有され、新しいデバイスでもボルトを復号できるようになります。

この機能により、ユーザーはマスターパスワードやパスワードキー導出を必要とせず、自身のデバイス上でローカルにボルトを復号できます。クラウド側ではユーザーのデータキーを復号できないため、ゼロ知識が維持されます。代わりに、デバイスで暗号化されたデータキー (DEDK) は、IDプロバイダ (Okta、Azure、Google Workspace、AD FS、Ping、Duo、JumpCloudなど) による認証が成功した後にユーザーへ渡されます。ユーザーのデータキーは、楕円曲線暗号に基づくデバイスの秘密鍵を用いて、デバイス上でローカルに復号されます。Keeperはこの技術に関して米国実用特許を取得しており、2015年から本番環境で運用されています。

Keeper Automatorはオプションのサービスで、SSO IDプロバイダーからのログインに成功すると、チームの承認、デバイスの承認、チームユーザーの割り当てを即時に実行します。

Automatorが稼働している場合、ユーザーがIDプロバイダーによる認証に成功すれば、以前に承認されていない新規デバイスからでも、追加の承認ステップなしでKeeperアカウントにスムーズにアクセスできます。

Keeper SSOコネクト (オンプレミス)

ほとんどのお客様はKeeperクラウドSSOコネクトを導入していますが、オンプレミスのソリューションを必要とするお客様はオンプレミスSSOコネクトを導入することができます。これは、WindowsまたはLinuxでホストされるアプリケーションサーバーを必要とするセルフホスト型の統合ソリューションです。ゼロ知識セキュリティを維持し、ユーザーによるスムーズなSSO体験を実現するには、Keeper SSOコネクトをお客様のサーバーにインストールする必要があります。Windows、Mac、Linux環境に完全対応しており、高可用性 (HA) ロードバランス運用モードとハードウェアセキュリティモジュールによる超暗号化が適用されています。

Keeper SSO Connect はプロビジョニングされた各ユーザーのマスターパスワードを自動的に生成し、保持します。このマスターパスワードは SSO 鍵で暗号化されます。SSO 鍵はツリーキーで暗号化されます。SSO 鍵は Keeper SSO Connect サービス起動時にサーバーから取得され、ツリーキーを使用して復号されます。ツリーキーは、サービスの自動起動をサポートするためにサーバー上にローカルに保存されます。 SSO Connect と Keeper のクラウドセキュリティボルト間の通信は通信キーで保護されます。SAML 通信は暗号署名され、顧客によって提供された暗号鍵（RSA または ECC）のタイプに応じて、RSA-SHA256 または ECDSA-SHA256 署名アルゴリズムによって保護されます。

共有

Keeper はユーザー間、内部チーム間、または組織外（Keeper 管理者が許可した場合）でも安全に記録を共有する機能をサポートしています。

レコードの共有

Keeper ユーザーはお互いに直接記録を共有することができます。これを行うために、Keeper は最初にボルトからユーザーの楕円曲線公開鍵をリクエストします。各記録は受信者の楕円曲線公開鍵で暗号化された記録鍵を持ち、ユーザーの Keeper ボルトに同期されます。

暗号化された共有記録の所有者は、自分の楕円曲線秘密鍵で記録鍵を復号します。その記録鍵もユーザーのデータキーで再暗号化され、暗号文は受信者のボルトに保存されます。

ワンタイム共有

Keeper ワンタイム共有では、パスワード、クレデンシャル、シークレット、接続、ドキュメント、またはその他の機密情報などの記録を、Keeper アカウントを持っていない誰とでも期間限定で安全に共有することができます。Keeper ワンタイム共有暗号化モデルは、クラウドインフラを保護するためのゼロ知識およびゼロトラストプラットフォームである Keeper Secrets Manager (KSM) と同じテクノロジーを使用しています。

1. ユーザーの Keeper ボルト内で、共有元はワンタイム共有をクリックすることでワンタイムアクセスを生成します。256 ビット AES 記録鍵はワンタイムアクセストークンで暗号化され、暗号化された値は Keeper ボルトに保存されます。
2. ワンタイムアクセストークンを受信者に共有するユーザーは、単純な URL または QR コードを使用します。アクセストークンを含む URL の部分は、URL の「フラグメント識別子」部分に保持され、Keeper のサーバーに送信されることはありません。そのため、Keeper が情報にアクセスしたり、解読したりすることができず、ゼロ知識が保持されます。
3. URL はユーザーのブラウザで開き、ボルトアプリケーションはデバイスにロードされます。トークンはローカルのボルトアプリケーションに直接引き渡され、サーバーには送信されません。
4. その後、受信者はデバイスを使用してエンドユーザー側の EC 鍵ペアを生成し、秘密鍵はデバイス上のローカルでブラウザの CryptoKey ストレージに保管されます。
5. 受信者の最初の使用時に際し、SDK ライブラリはワンタイムアクセストークンのハッシュで認証します。その後、Keeper のサーバーは暗号化された記録暗号文と暗号化記録鍵で応答します。
6. デバイスはワンタイムアクセストークンで記録鍵を復号し、コンテンツが復号されます。鍵はクライアントデバイスのブラウザの CryptoKey ストレージまたは他のストレージに保管されます。
7. 指定されたデバイスの暗号化記録鍵は削除され、そのトークンは二度と使用できません。その後、クライアントリクエストは秘密鍵で署名されなければなりません。
8. 同じデバイスに対する更なるコールは、デバイスを定義する識別子と、クライアントの秘密鍵で署名されたリクエストで送られます。指定されたデバイス識別子に対するリクエストは、ECDSA 署名によって、デバイスのクライアント公開鍵を使用し、サーバーによってチェックされます。Keeper はリクエストを処理し、サーバーは暗号化された記録をユーザーのデバイスに暗号文で返します。
9. 記録レベルの暗号化に加えて、クライアントデバイスはランダムに生成された AES-256 ビットの通信キーを作成し、Keeper クラウド API の公開鍵で暗号化されます。クライアントデバイスは、送信キーでサーバーからの応答を復号し、記録鍵で暗号文応答ペイロードを復号し、記録の内容を復号します。

共有管理

Keeper の共有管理者機能は、管理者に組織の共有フォルダと記録に対する昇格した権限を与える、ロールベースのアクセス制御（RBAC）許可です。共有管理者はアクセス権を持つすべての共有記録に対して、完全なユーザーと記録の特権を持ちます。

シークレットマネージャーの暗号化モデル

Keeperシークレットマネージャー (KSM) は、ITおよびDevOpsの専門家のためのゼロ知識プラットフォームで、チームがソフトウェア開発とデプロイメントのライフサイクルを通じて機密情報を管理できます。

シークレットマネージャーは以下の暗号化モデルを使用します

• 暗号化と復号はデバイス上でローカルに行われます（サーバー上ではありません）。
• 平文がデバイスに保存されることはありません。
• 平文がサーバーで受信されることはありません。
• Keeper の従業員、サードパーティーまたは仲介者を含め、何者もシークレットを復号することはできません。
• クライアントデバイスが、ユーザーの管理下で、シークレットを暗号化および復号するための鍵を管理します。
• すべてのシークレットが、クライアント側で生成された 256 ビットの AES 暗号鍵によって GCM モードで暗号化されます。
• シークレットが共有フォルダ内に含まれる場合、記鍵は共有フォルダ鍵でラップされます。
• 256 ビットの AES アプリケーション鍵がクライアント側で生成され、共有フォルダ鍵および記録鍵の復号に使用されます。その後、記録鍵が個々のシークレットを復号します。
• Keeper サーバーは MITM 攻撃から保護するために、TLS で 256 ビットの AES 鍵でラップされています。
• 通信キーはクライアントデバイス上で生成され、サーバーの公開 EC 鍵を介して ECIES 暗号化を使用してサーバーに転送されます。
• 楕円曲線暗号は、安全な鍵配布のためにユーザー間でシークレットを共有するために使用されます。
• 多層暗号化により、ユーザー、グループ、管理者レベルでのアクセス制御が可能です。
• ボルト内で管理されるシークレットは、記録とフォルダへのアクセスを許可された、定義された Secrets Manager デバイスにセグメント化され、隔離されます。

Keeperシークレットマネージャーのパスワードローテーションモデル

• ゲートウェイと呼ばれる独自の Keeper Secrets Manager (KSM) クライアントが顧客の環境にインストールされます。
• ゲートウェイは Keeper ルーターへの安全なアウトバウンド接続を確立します。
• ルーターは Keeper の AWS 環境でホストされているクラウドサービスで、Keeper バックエンド API、エンドユーザーアプリケーション（ウェブボルト、デスクトップアプリなど）とユーザー環境にインストールされているゲートウェイ間の通信を円滑にします。
• Websockets（ウェブソケット）は、現在のセッショントークンを使用して、エンドユーザーデバイス（ウェブボルトなど）と Keeper ルーターの間で確立されます。
• Keeper ルーターはセッショントークンを検証し、セッションを認証します。Keeper ルーターに送信されるすべての暗号化されたペイロードは、MITM 攻撃から保護するために、TLS に加えて、256 ビットの AES 鍵でラップされます。
• 256 ビット AES 鍵はエンドユーザーデバイス上で作成され、ルーターの公開 EC 鍵を介して ECIES 暗号化を使用してサーバーに転送されます。
• ローテーションとディスカバリーのリクエストは、確立された WebSocket 通信チャネルを介して、エンドユーザーのデバイス（または Keeper スケジューラ）とゲートウェイの間で発行されます。
• ローテーションの間、ゲートウェイが Keeper ボルトからのシークレットを必要とする場合、Keeper Secrets Manager API を使用してそのシークレットの認証と復号を行い、ゼロ知識を維持します。
• 他のシークレットマネージャーデバイスと同様に、暗号化と署名プロセスに加えて、IP アドレスに基づいてアクセスを制限することもできます。

ゼロトラスト接続とトンネルセキュリティ

ゼロトラストのKeeperPAM^®は、クラウドおよびオンプレミスの特権セッションの構築、トンネルの作成、インフラストラクチャへの直接アクセスの確立、VPNなしでのリモートデータベースへのアクセスを保護する機能を実現します。

接続は、ウェブブラウザを使用した視覚的なリモートセッションです。ユーザーとターゲットデバイス間のやり取りは、ウェブブラウザのウィンドウ内またはKeeperデスクトップアプリ内で行われます。

トンネルは、ローカルのボルトクライアントからKeeperゲートウェイを経由してターゲットのエンドポイントに確立されるTCP/IP接続です。ユーザーはターゲットエンドポイントと通信するために、コマンドラインターミナル、GUIアプリケーション、MySQL Workbenchといったデータベース管理アプリケーションなどのあらゆるネイティブアプリケーションを利用できます。

ユーザーが接続またはトンネルを確立すると次のようになります。

1. ボルトクライアントアプリケーションがKeeperルーターインフラストラクチャと通信し、WebRTC接続を開始します。この接続は、関連するKeeperレコード内に保存されたECDH対称鍵によって保護されています。
2. Keeperゲートウェイは、アウトバウンド専用のWebSocketを通じてKeeperルーターと通信します。
3. Keeperゲートウェイは、KeeperシークレットマネージャーAPIを利用し、ECDH対称鍵を含む必要な機密情報をボルトから取得します。
4. 接続の場合、ボルトクライアント (アパッチワカモレプロトコルを使用) は、WebRTC接続を通じてKeeperゲートウェイにデータを渡します。その後、Guacdを使用してKeeperレコードに記録されている宛先に接続します。
5. トンネル機能 (ポート転送) の場合、Keeperデスクトップアプリを実行しているローカルデバイス上でローカルポートが開かれます。ローカルポートに送られたデータは、WebRTC接続を通じてKeeperゲートウェイに転送され、その後Keeperレコードに定義されたターゲットエンドポイントに転送されます。
6. 接続のセッション録画は、各セッションにおいてKeeperゲートウェイ上で生成されるAES-256暗号鍵 (録画鍵) で保護されます。この録画鍵はさらに、HKDFに基づいて生成されたAES-256リソース鍵によってラップされています。

リモートブラウザ分離セキュリティ

Keeperのリモートブラウザ分離技術によって、KeeperコネクションマネージャーのDockerコンテナまたはKeeperゲートウェイを通じて、組織内部のウェブアプリケーションやその他のウェブベースのリソースへのアクセスの保護を実現します。

コネクションマネージャーのDockerコンテナ方式を利用する場合：

1. ユーザーは、Dockerコンテナでユーザーが所属する組織がホストするKeeperコネクションマネージャーのウェブサービスに認証してログインします。
2. ユーザーはターゲットのウェブアプリケーションに対してリモートブラウザ分離セッションを開始します。ユーザーのブラウザと、ホストされたKeeperコネクションマネージャーのウェブサービス間の通信は、Let's Encryptまたはお客様が指定した証明書によってHTTPSで保護されます。
3. KeeperコネクションマネージャーのDockerコンテナ上では、組み込み版Chromiumがサンドボックス内で実行され、対象のウェブサイトがローカルのディスプレイドライバーを使用してレンダリングされます。この表示内容はアパッチワカモレプロトコルを使用して、リアルタイムでユーザーのウェブブラウザにストリーミングされます。

KeeperウェブボルトまたはデスクトップアプリでKeeperゲートウェイを使用する場合：

1. ボルトクライアントアプリケーションでKeeperルーターインフラストラクチャと通信し、WebRTC接続を開始します。この接続は、関連するKeeperレコード内に保存されたECDH対称鍵によって保護されています。
2. Keeperゲートウェイは、アウトバウンド専用のWebSocketを通じてKeeperルーターと通信します。
3. KeeperゲートウェイによってKeeperシークレットマネージャーAPIを利用し、ECDH対称鍵を含む必要な機密情報をボルトから取得します。
4. ボルトクライアントでアパッチワカモレプロトコルを使用し、WebRTC接続を通じてKeeperゲートウェイにデータを送信し、その後HTTPまたはHTTPSを使用してKeeperレコードに記載された宛先に接続します。
5. 接続のセッション録画は、AES-256暗号鍵 (録画鍵) で保護され、セッションごとにKeeperゲートウェイ上で生成されます。この録画鍵はさらに、HKDFに基づいて生成されたAES-256リソース鍵によってラップされています。

ブラウザ分離保護

リモートブラウザ分離プロトコルを使用することで、以下のセキュリティ対策が有効になります。

1. 保護対象であるウェブアプリケーションのエンドポイントは、KeeperコネクションマネージャーのゲートウェイからユーザーのローカルデバイスまでTLS暗号化レイヤーでラップされます。これにより、ゲートウェイとエンドポイント間でTLSが使用されていない場合でも、ユーザーのローカルネットワークでのMITM攻撃やパケット検査から保護されます。
2. リモートブラウジングセッションでは、キャンバスとグラフィカルレンダリングを使用してユーザーのローカルデバイスに操作やシステムとのやり取りを視覚的に映し出します。対象ウェブサイトのJavaScriptコードやHTMLは、ユーザーのローカルマシン上で実行されることはありません。
3. 対象ウェブサイトのコードがローカルで一切実行されず、ローカルブラウザは基盤となるアプリケーションコードに直接アクセスできません。このため、隔離されたウェブアプリケーションは、反射型クロスサイトスクリプティングの脆弱性、クロスサイトリクエストフォージェリ、APIの悪用といった攻撃から保護されます。
4. URLとリソースリクエストのフィルタリングによって、ユーザーの対象エンドポイントからのデータの持ち出しが制限される場合があります。ファイルのアップロードとダウンロードは、対象のウェブアプリケーションがその操作を許可していても制限の対象になります。
5. 監査やコンプライアンスのために、ブラウジングセッションやキーストロークを記録することが可能で、ウェブベースのセッションに対するフォレンジック分析を実施できます。
6. ゲートウェイから対象のウェブアプリケーションへと自動入力される認証情報はユーザーのデバイスには送信されず、ユーザーがローカルデバイス上でアクセスできないため、認証情報の漏洩を防ぎます。
7. ファイアウォールポリシーを介して、ユーザーはリモートブラウザ分離セッションを通じてのみ対象のウェブアプリケーションにアクセスするように求められるため、ブラウザの脆弱性やローカルデバイスのマルウェアによる脅威を軽減できます。
8. 標準では機能に対応していない場合でも、対象のウェブアプリケーションはシングルサインオンや多要素認証 (MFA) によって保護されます。このドキュメントで説明されている高度な認証方法によって、Keeperボルトおよびリモートブラウザ分離セッションへのアクセスを保護します。

BreachWatch^®

Keeper は BreachWatch と呼ばれる AWS 上のマネージドで、自己完結型のアーキテクチャを実行しています。BreachWatch は Keeper API およびユーザー記録からは物理的に分離されています。

BreachWatch サーバー上の物理的なハードウェアセキュリティモジュール（HSM）は、ダークウェブのデータ漏洩から数十に及ぶ独自のパスワードを処理、ハッシュ化、保管するために使用されます。すべてのパスワードは、HMAC_SHA512 ハッシュメソッドを使用して Keeper のサーバー上で処理され、エクスポート不可能な鍵を使用して HSM でハッシュ化されます。

クライアントデバイス上で BreachWatch が有効化されると、すべての記録に基づいて HMAC_SHA512 ハッシュが生成され、サーバーに送信されます。サーバーでは、エクスポート不可能な鍵を使用し、HSM 経由で HMAC_SHA512 を使用して 2 番目のハッシュが作成されます。「Hashes-of-Hashes（ハッシュ内のハッシュ）」が比較され、クレデンシャルが侵害されたかどうかが確認されます。

BreachWatch アーキテクチャは、データ漏洩の規模に関係なく、漏洩したパスワードとユーザーのボルト内のパスワードとの相関を防止するために構築されました。漏洩したパスワードの検出は、物理的な HSM を利用し、ハッシュがオンラインでのみ実行できるようにすることで、データに対するブルートフォース攻撃を防止しています。

• パスワードは HMAC_512 で 2 回ハッシュ化されます。1 回は「ペッパー」を使ってクライアントデバイスで、もう 1 回はエクスポート不可能な鍵を持つハードウェア・セキュリティ・モジュールを使って AWS CloudHSM でハッシュ化されます。
• HMAC_512 が利用されるのは、強力なハッシュ関数とエクスポート不可能な秘密鍵を利用するためです。したがって、ハッシュに対するオフライン攻撃は実行不可能になります。
• 暗号ハッシュ関数の結果を用いたメッセージ認証コード（MAC）は、ハッシュ関数の利用を拡大するものです。その結果は、メッセージだけでなく、秘密鍵であるかもしれない第 2 のインプットにも依存します。

BreachWatch は SpyCloud データフィードを使用して、100％ Keeper によって構築されていますが、Keeper はサードパーティーにデータを送信することはありません。

ドメインのスキャン

BreachWatch のお客様は漏洩したドメインのリストをダウンロードし、ローカルでチェックを実行します。

ユーザー名とパスワードのスキャン

クライアントデバイスは BreachWatch に接続し、ハッシュ化されたユーザー名（またはパスワード）のリストを、クライアントが選択したランダムな識別子（ユーザー名チェックサービスとパスワードチェックサービス用の別々の識別子）とともにアップロードします。これらのパスワードハッシュは、アップロード時に、ハードウェアセキュリティモジュール（HSM）と、エクスポート不可能（HSM はローカルでのみ HMAC を処理し、鍵は抽出できないという意味）とマークされた HSM に保管された秘密鍵を使用して、HMAC で処理されます。これらの HMAC 化された入力（ユーザー名またはパスワード）は、同じ HMAC と鍵で処理された違反データセットと比較されます。一致したものはすべてクライアントデバイスにレポートされます。一致しない値は、クライアントの匿名化された ID と一緒に保管されます。

新しく漏洩したユーザー名とパスワードがシステムに追加されると、それらは HSM で HMAC 処理され、BreachWatch データセットに追加され、保管されたクライアント値と比較されます。一致した場合、そのクライアント ID のアラートがキューに表示されます。

クライアントは定期的に BreachWatch へチェックインし、それぞれの BreachWatch ID を提出します。送信待ちメッセージがすべてダウンロードされ、クライアントは同様に処理された新しいあるいは変更されたユーザー名やパスワードをアップロードします。

BreachWatch サービスのセキュリティは trust-on-first-use（TOFU）です。つまり、クライアントがハッシュ値をアップロードする際に、クライアント側は BreachWatch サーバー側に悪意がない（攻撃者に侵入された状態ではない）ことを前提としなければなりません。HSM で処理されたハッシュ値はオフラインのクラッキング攻撃に対して安全です。言い換えるならば、攻撃者が保管されたクライアント値のデータセットを盗んだとしても、HSM 上の HMAC キーがないために、オフラインでこれらの数値をクラッキングすることは不可能となります。

パスワードの漏洩が検知されると、クライアントデバイスから BreachWatch サーバーに対してユーザー名とパスワードのコンビネーションハッシュが送信され、サーバーはそこで同様の HMAC ハッシュ比較を実行することで、ユーザー名とパスワードのコンビネーションが漏洩したかを確認します。漏洩していたとみなされた場合、漏洩に関連するドメインが返還され、それによりクライアントデバイスはユーザー名とパスワードとドメインが一致するかどうかを確認することができます。3 つのすべての情報がクライアントデバイスで一致した場合、ユーザーは漏洩の重度について警告を受けます。

ビジネス・エンタープライズのお客様向けのBreachWatchの機能

Business と Enterprise のお客様向けに BreachWatch が有効化されると、ユーザーが Keeper でログインするたびに、エンドユーザーボルトが自動的にスキャンされます。ユーザーのデバイス上でスキャンされた BreachWatch サマリーデータはエンタープライズ公開鍵で暗号化され、Keeper 管理コンソールにログインする際にエンタープライズ管理者によって復号されます。この暗号化された情報には、メールアドレス、ハイリスクな記録の数、解決された記録数、無視された記録数が含まれます。Keeper 管理者は、管理コンソールのユーザーインターフェイス内でユーザーレベルのサマリー統計を表示することができます。

イベントログとレポート

「高度なレポートとアラート」と統合された場合、Keeper エンドユーザーデバイスは、サードパーティの SIEM ソリューションと Keeper 管理コンソールレポートインターフェイスに詳細なリアルタイムイベントを送信するようにオプションで設定することもできます。イベントデータには、メールアドレス、記録 UID、IP アドレスおよびデバイス情報が含まれます（Keeper はゼロ知識プラットフォームであり、ユーザーデータを復号することはできないため、イベントには復号された記録データは含まれません）。

デフォルトでは、詳細な BreachWatch イベントデータは、高度なレポートとアラートモジュールまたは接続された外部ログシステムに送信されることはありません。高度なレポートとアラートモジュールへの BreachWatch データのイベントレベルレポートを有効にするには、「特定のロール > 強制ポリシー > ボルト機能」画面の下でイベントロール強制ポリシーを有効にする必要があります。有効化すると、エンドユーザー・クライアント・デバイスはこのイベントデータの送信を開始します。サードパーティの SIEM ソリューションとの統合は、Keeper バックエンドからターゲット SIEM に送信されるため、このイベント情報はターゲット SIEM によって読み取られ、組織内のどの記録とどのユーザーがリスクの高いパスワードを使用しているかを識別するために使用される場合があります。Keeper 管理者が記録レベルのイベントデータを Keeper 高度なレポートとアラートモジュールに送信したくない場合、この設定は無効のままにしておくことができます。

Splunk Sumo Logic LogRhythm Syslog Push IBM QRadar Azure Sentinel AWS S3 Bucket Devo Datadog Logz.io Elastic Crowdstrike

オフラインモード

オフラインモードは、Keeper または SSO アイデンティティプロバイダにオンライン接続できないユーザーが自分のボルトにアクセスできるようにします。この機能は Keeper のモバイルアプリ、デスクトップアプリケーション、およびウェブボルトのすべてのブラウザで利用可能です。

この機能はユーザーのローカルデバイスにボルトのコピーを作成することで機能します。オフラインで保存されたボルトデータは、ランダムに生成され、1,000,000 回の反復回数とランダムなソルトを持つ PBKDF2-HMAC-SHA512 で保護された 256 ビットの「クライアント鍵」で AES-GCM 暗号化されます。ソルトと反復はローカルに保存されます。ユーザーがマスターパスワードを入力するか、生体認証を使用すると、ソルトと反復を使用して鍵が生成され、クライアント鍵の復号が試みられます。クライアント鍵は、保管された記録キャッシュを復号するために使用されます。ユーザーのボルトで自己破壊保護が有効になっている場合、ログインに 5 回失敗すると、ローカルに保管されているすべてのボルトデータが自動的に消去されます。business のお客様の場合、オフラインアクセスは Keeper 管理者によるロール強制ポリシーに基づいて制限することができます。

緊急アクセス (デジタル遺産)

Keeper の個人および家族プランでは、ユーザーが死亡または別の緊急事態が発生した場合に、ボルトへのアクセスを許可する緊急連絡先を最大 5 人まで追加することができます。ユーザーは待ち時間を指定し、この待ち時間が経過すると、その緊急連絡先でユーザーのボルトにアクセスできるようになります。緊急連絡先でボルトを共有することはゼロ知識であり、ユーザーのマスターパスワードが共有されることはありません。さらに、256 ビット AES 鍵で 2048 ビット RSA 暗号化が使用されます。緊急連絡先は情報を受け入れるために、Keeper アカウントを持っている必要があります。

ネットワークアーキテクチャ

Keeper は北米（商用または GovCloud）、ヨーロッパ、オーストラリア、日本、およびカナダで AWS を利用し、ローカライズされたデータプライバシーと地理的分離を実現し、Keeper ソリューションとアーキテクチャをホストし、運用しています。AWS を利用することで、Keeper はリソースをオンデマンドでシームレスに拡張し、お客様に最速かつ安全なクラウドストレージ環境を提供することができます。Keeper は稼働時間を最大化し、お客様に最速の応答時間を提供するために、マルチゾーンとマルチリージョン両方の環境を運用します。エンタープライズのお客様は Keeper テナントを任意のプライマリーリージョンでホストすることができます。顧客データとプラットフォームへのアクセスはその特定の地域に隔離されます。

クラウド認証

Keeper は、最高レベルのプライバシー、セキュリティおよび信頼のために構築された高度なクラウド認証とネットワーク通信モデルを作成しました。認証モデルの主な特徴は以下の通りです：

• マスターパスワードがネットワークレイヤー上に送信されることはない。 多くの SaaS サービスとは異なり、ログイン情報がデバイスから外に出ることはありません。PBKDF2 は、復号に使用される 256 ビットの AES 鍵を導き出すためにローカルデバイス上で利用されます。2つ目の PBKDF2 鍵はローカルで生成され、HMAC_SHA256 でハッシュ化され、認証トークンを導きます。Keeper のクラウドセキュリティボルトは、ユーザーの復号鍵に対する知識を全く持ちません。
• クライアントデバイスと Keeper クラウド間のトラフィックを傍受または解読することはできない。 Keeper は、MITM 攻撃を確実に防止するために、デバイスと Keeper サーバー間でKey Pinning（鍵ピンニング）と追加レイヤーのネットワークレベルの暗号化（通信キー）を利用します。
• 新規デバイスは、デバイス承認ステップなしでアカウントにログインすることはできない。 このステップを通過せずにアカウントへのログインを試みることはできません。Keeper は使用されている認証スキームに依存するいくつかのタイプのデバイス承認メソッドをサポートしています。
• 2FA はデバイス承認の後、マスターパスワード入力の前に実行される。 ユーザーが 2FA を設定または強制している場合、このステップはマスターパスワード入力の前に通過する必要があります。
• デバイス承認と 2FA ステップが成功するまで、マスターパスワード入力は実行できない。 ユーザーは、最初にデバイス認証と 2FA 認証を実行しなければ、マスターパスワード入力ステップに進むことができません。この高度な認証フローは、ブルートフォース攻撃、パスワードスプレー、列挙攻撃、MITM を含むいくつかの攻撃ベクトルに対する保護を提供します。

通信中のデータの暗号化

Keeper Cloud Security Vault は、クライアントデバイスによる認証を通じて検証される API によって保護されています。クライアントは、ログイン時にセッショントークンを取得し、各 API コールでそれを送信します。セッショントークンはサーバー上で追跡されます。ログインは、マスターパスワード、セッション再開、または SAML 2.0 SSO 認証のいずれかによって実行されます。

マスターパスワードを使用する場合、クライアントデバイスは PBKDF2-HMAC-SHA256 を 1,000,000 回反復し、128 ビットのランダムソルトを使用して 256 ビットの「認証鍵」を導出します。「認証ハッシュ」は、SHA-256 を使用して認証鍵をハッシュ化することで生成されます。ログインするために、認証ハッシュはクラウド・セキュリティ・ボルトに保存されている認証ハッシュと比較されます。ログイン後、セッショントークンがサーバー上で生成され、クライアントに送信されます。クライアントからサーバーへの通信を継続的に使用するには、セッションがアクティブである必要があります。

Keeper はクライアントアプリケーションと Keeper のクラウドベースのストレージ間のすべてのデータ転送を暗号化するために 256 ビットと 128 ビットの TLS をサポートしています。

Keeper は、現在最も安全な署名アルゴリズムである SHA2 アルゴリズムを使用して DigiCert によって署名された TLS 証明書を採用しています。SHA2 は、より広く使用されている、アルゴリズムに特定された数学的弱点のために悪用される可能性のある SHA1 よりも大幅に安全性が高くなっています。SHA2 は、攻撃者がウェブサイトになりすますために使用できる偽造証明書の発行からの保護に役立ちます。

Keeper はまた、認証局によって署名された証明書の公開監査可能な記録を作成する、Google のイニシアチブである証明書の透明性（CT）をサポートしています。CT は無許可のエンティティによる証明書の発行を防ぐのに役立ちます。CT は現在、Chrome、Safari、Brave ウェブブラウザの最新バージョンでサポートされています。証明書の透明性についての詳細は、https://certificate.transparency.dev/ をご覧ください。Keeper は以下の TLS 暗号スイートをサポートしています：

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-ECDSA-AES128-SHA256
• ECDHE-RSA-AES128-SHA256
• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-ECDSA-AES256-SHA384
• ECDHE-RSA-AES256-SHA384

iOS と Android の Keeper クライアントデバイスでは、不正なデジタル証明書を使用する攻撃者によるなりすましを防止するセキュリティメカニズムである鍵ピンニングも実装しています。

クロスサイトスクリプティング (XSS) 攻撃の予防

クロスサイトスクリプティング攻撃のベクターをできる限り削減あるいは除外するために、Keeper ウェブボルトには厳格なコンテンツセキュリティポリシーが実装されています。Keeper が明確に情報源を明示している対象を除き、インライン（埋め込み）スクリプトやイベントハンドラ HTML 属性を含め、外部送信されるリクエストの発信元情報は表示されず、すべてのスクリプトは実行が禁止されています。

Keeper ドメイン名へのアクセスは TLS 1.3 の HTTPS に制限され、HTTP Strict Transport Security によって強制されます。これにより、パケット盗聴、データ改ざん、中間者攻撃を幅広く防ぐことができる。

Keeper ブラウザ拡張機能内では、Keeper がページフレームエリア内からユーザーにボルトのクレデンシャルを要求することはありません。拡張機能へのログインは、ブラウザのブラウザ拡張ツールバーエリア内で行われます。ウェブブラウザのボルトへのログインは、常に keepersecurity.com、 keepersecurity.eu、 keepersecurity.com.au、 keepersecurity.jp、 keepersecurity.ca または govcloud.keepersecurity.us ドメイン、もしくはコンテンツページの外側に存在する Keeper ブラウザ拡張ツールバーから行われます。

Keeper ブラウザ拡張機能は、悪意のあるウェブサイトが注入されたコンテンツにアクセスできないように、ウェブページのログインフォームに iFrame を配置します。iFrame に注入された記録コンテンツはまた、ターゲットウェブサイトのドメインと一致するユーザーのボルトに保管されているボルト記録に制限されます。Keeper は、ウェブサイトドメインが Keeper ボルト記録のウェブサイトドメインフィールドと一致しない限り、ログインまたはパスワードデータの自動入力を提供しません。拡張機能は、記録がウェブサイトのアドレスルートドメインと一致しない限り、記録を表示しません。

サードパーティのブラウザ拡張機能は、ウェブブラウザで昇格された許可を持ち、ページ内の情報にアクセスできる可能性があります。そのため、Keeper 管理者はユーザーがブラウザの各アプリストアからサードパーティのブラウザ拡張機能をインストールできないようにすることをお勧めします。

生体認証

Keeper は Windows Hello、Touch ID、Face ID、Android の生体認証をネイティブでサポートしています。通常、マスターパスワードまたはエンタープライズ SSO ログイン（SAML 2.0）を使用して Keeper ボルトにログインするお客様は、生体認証を使用してデバイスにログインすることもできます。生体認証は Keeper 管理者がロールポリシーで有効にする必要があります。この機能が有効になっている場合、マスターパスワードと SSO が有効なユーザーの両方に対して、生体認証でオフラインアクセスすることもできます。

デバイス上で生体認証ログインが有効になっている場合、鍵はローカルでランダムに生成され、デバイスのセキュアエンクレーブ（例：Keychain または Keystore）に保存されます。ユーザのデータキーは、生体認証鍵で暗号化されます。生体認証に成功すると、鍵を取得し、ユーザーは自分のボルトを復号することができます。

iOS キーチェーン、Touch ID、Face ID

iOS デバイスの Touch ID と Face ID により、ユーザーは生体認証を使って Keeper ボルトにアクセスすることができます。この便利な機能を提供するために、ランダムに生成された 256 ビットの「生体認証鍵」が iOS キーチェーンに保存されます。この機能のために作成された iOS キーチェーンアイテムは iCloud キーチェーンに同期するように指定されていないため、iOS モバイルデバイスから離れることはありません。

暗号化されたKeeperボルトのセキュリティを最高レベルで運用するには、複雑なマスターパスワードを使用し、多要素認証を有効にすることを強く推奨します。iOSモバイル端末でTouch IDやFace IDを使用すると、複雑なマスターパスワードを使用するより簡単かつ安全です。加えて、iOSキーチェーン安全性を確保するため、4桁以上のパスコードを設定することを推奨します。

iOS キーチェーンは、認証情報を安全に保存するために iOS とアプリによって使用されます。iOS アプリは iOS キーチェーンを使用して、ウェブサイトのパスワード、鍵、クレジットカード番号、Apple Pay 情報などの様々な機密情報を保管します。すべての Keeper 記録は 256 ビット AES 暗号化で保護され、Keeper ボルトに安全に保管されます。iOS キーチェーンもデバイスのパスコードを使用して、256 ビット AES 暗号化で暗号化されます。デバイスが紛失または盗難された場合、または攻撃者がモバイルデバイスに物理的にアクセスした場合でも、保存されている Keeper 情報にアクセスすることはできません。iOS キーチェーンはパスコードなしでは復号できず、Keeper ボルトはユーザーの Keeper マスターパスワードなしでは復号できません。

Apple Watch^®

Apple Watchのお気に入り機能により、ペアリングしたApple Watchで指定された記録を見ることが可能です。Apple Watchで記録を見るためには、それらのKeeper記録を事前にWatchお気に入りに登録する必要がります。ペアリングしたApple WatchはKeeperのWatch拡張と通信します。その拡張はiOS Keeperアプリと分離されているサンドボックス環境で透過的に動作しています。iOS Keeperアプリとの安全かつシームレスな通信を実現するため、KeeperのWatch拡張もiOS Keychainを使って、安全にキーを保存したり、アクセスします。

Keeper DNA^®

Keeper DNA はスマートウォッチデバイスを使用した多要素認証方法を提供します。Keeper DNA は、Keeper ボルトに保存されたセキュアトークンを使用して、多要素認証用の時間制限付きコードを生成します。これらの時間制限付きの認証要求は、Apple Watch（または Android Wear デバイス）からウォッチの画面をタップすることで承認され、自動的に送信されるか、またはユーザーが手動で入力することができます。

従業員のオフボーディング (ボルト移転)

ノードに対してアカウント移管ポリシーが有効化されると、ユーザーのデバイス上の管理コンソールで公開鍵/秘密鍵ペアのノードポリシーが作成されます。エンドユーザーのデータキー (強制が適用されるロールを持つユーザーの場合) は、ユーザーがボルトにサインインするときに、ポリシーの公開鍵で暗号化されます。秘密鍵は管理者の公開鍵で暗号化され、管理者はボルト移管でロール強制鍵を復号できます。

ボルト移転を実行する場合、Keeper 管理者はまずユーザのアカウントをロックする必要があります。その後、直ちにボルト移転を実行し、ユーザーのアカウントを削除することができます。これにより、操作が秘密裏に実行されることはありません。移転を実行する際、ユーザのデータ鍵は、まずロール強制秘密鍵をアンラップし、次にユーザのデータ鍵をアンラップすることで取得されます。データキーは、記録鍵、チーム鍵、フォルダ鍵をアンラップするために使用されます。

すべての暗号化は管理コンソール内でクライアント側から実行され、Keeper は共有または転送される情報を復号する能力を一切持ちません。さらに、ユーザーのクライアントデータキーが共有されることも一切ありません。チーム、共有フォルダまたは直接共有から削除されたユーザーは、チーム、共有フォルダ、記録から新しいデータを受け取ることはできません。記録、フォルダ、チームの鍵は、トランザクション中に管理者用にローカルで復号されますが、そのかぎを使用して基礎となる記録やフォルダのデータにアクセスすることはできません。

ボルト移転中、管理者は暗号化されたデータキー、暗号化された記録鍵、暗号化されたフォルダ鍵のみを受け取ります。管理者はこれらの鍵を復号し、移転先のボルトの公開鍵で再暗号化します。管理者が実際の記録データにアクセスできることはありません。Keeper はクライアントが保管したデータをデータキーで直接暗号化することはありません。デバイス上で実行されます。

エアギャップ環境におけるKeeperPAM

概要

Keeper特権アクセス管理 (KeeperPAM) は、特権認証情報および保護対象システムへのアクセスを一元管理するソリューションです。

こちらでは、ネットワーク接続が制限された環境 (いわゆるエアギャップ環境を含む) においてKeeperPAMを導入する方法について説明します。また、KeeperPAMをサポート対象の構成で運用するために必要なインフラ要件についても解説します。

現時点の製品仕様では、KeeperPAMの動作にはAWSクラウドインフラストラクチャが必要です。

エアギャップ環境に関する要件

エアギャップ環境とは、外部ネットワークへの接続が制限または厳格に管理された環境を指します。

KeeperPAMは、完全に切り離された環境やオフラインでの導入には対応していません。通常運用には、顧客環境に展開されたPAMコンポーネントと、Keeperが管理するクラウドサービス間のネットワーク接続が必要です。

必要な接続要件が満たされている場合に限り、ネットワークアクセスが制限または厳しく管理された環境での運用が可能です。

アーキテクチャ概要

KeeperPAMは、Keeper Securityが管理するクラウドベースのアーキテクチャを採用しています。

顧客環境にはPAMコンポーネントが展開され、保護対象システムと連携するとともに、Keeperのクラウドサービスと通信します。

現時点では、KeeperPAMのバックエンドサービスでサポートされているクラウドプロバイダはAWSのみです。

インフラ要件

Keeperクラウドサービス

KeeperPAMは、AWS上でホスティングされているKeeper Securityのクラウドサービスを基盤として動作します。これらのサービスは製品の運用に必須であり、Keeper Securityによって管理されています。顧客側でクラウドサービスを導入または管理する必要はありません。

顧客環境に展開されるPAMコンポーネント

顧客環境には、以下の機能を担うKeeperPAMコンポーネントが展開されます。

• 環境内の保護対象システムとの連携
• AWS上でホストされるKeeperクラウドサービスとの通信

各コンポーネントが正常に動作するには、Keeperクラウドへのネットワーク接続が必要です。

ネットワーク接続要件

KeeperPAMをサポート対象の構成で運用するには、以下の接続要件を満たす必要があります。

• 顧客環境に展開されたPAMコンポーネントから、AWS上でホストされているKeeperクラウドサービスへのネットワーク接続
• PAMコンポーネントとKeeperクラウドサービス間で必要な通信を確保できること

完全にオフラインの環境、または外部ネットワークから切り離された環境には対応していません。

制限付きネットワーク環境における導入

必要なAWS上のKeeperサービスへの接続が確保されている場合に限り、ネットワークアクセスが制限または管理された環境へのKeeperPAMの導入が可能です。

外部ネットワークへの接続を一切許可しない環境は、現時点ではサポート対象外です。

認証とコンプライアンス

Keeperは、セキュリティを最優先に考えています。世界で最も安全性が高く、認証・検証・監査を受けたパスワードセキュリティソリューション兼特権アクセス管理プラットフォームです。SOC 2およびISO認証において業界で最も長い実績を有しています。ISO 27001、27017、27018の認証を取得し、GDPR、CCPA、HIPAAに準拠しています。また、FedRAMP HighおよびGovRAMP Highの認可を取得し、PCI DSS認証およびTrustArcによるプライバシー認証も取得しています。

• Keeper のソフトウェア開発チームは、米国在住のフルタイム従業員で構成されています。
• Keeper はソースコードにパスワード、クレデンシャル、アクセス鍵などの機密情報を保管することはありません。定期的にソースコードをスキャンし、これらの情報を確認しています。
• Keeper のソースコードは GitHub Enterprise に非公開で保管されていますが、データの暗号化はデバイスレベルで行われるため、ユーザーのボルトにアクセスするために必要な情報は提供されません。このコードの多くは、Keeper の Commander とシークレットマネージャー製品の一部として、当社の公開 GitHubリポジトリで公開されています。
• Keeper はサードパーティーの MFA プロバイダのコードを当社のアプリに埋め込むことはありません。Keeper のベンダーは、Keeper が関与する漏洩には依存しません。
• Keeper は AWS データセンターへの管理またはアクセスをサードパーティーに提供していません。すべての管理は、米国に所在する米国市民である Keeper Security の正社員によって行われています。

FIPS 140-3 承認済み

Keeper は、厳格な政府および公共部門のセキュリティ要件に対応するために、FIPS 140-3 検証済みの暗号化モジュールを利用しています。Keeper の暗号化は、NIST 暗号化モジュール認証プログラム（CMVP）によって認定され、認定されたサードパーティの研究所によって FIPS 140 規格に検証されています。

Keeperは、NIST CMVPの認証を受け、証明書#4743を取得したFIPS 140-3準拠の暗号化を使用しています。

ITAR 準拠

Keeper Security Government Cloud (KSGC) は米国国際武器取引規制（ITAR）への準拠をサポートしています。ITAR 輸出規制の対象となる企業は、保護されたデータへのアクセスを米国市民に制限し、保護されたデータの物理的な場所を米国内に制限することで、意図しない輸出を制御する必要があります。

KSGCのFedRAMP High環境は、以下の取り組みによりITAR要件を満たしています。

• 完全準拠のデータストレージは AWS GovCloud 上でホストされ、米国内に限定されています。
• KSGC は、転送中および保存時に安全なデータ暗号化を提供します。
• ゼロ知識、ゼロトラストセキュリティときめ細かなアクセス許可により、企業は承認された担当者のみが機密データにアクセスできるよう保証できます。
• 堅牢なコンプライアンスレポート機能により、実行されたすべてのアクションと入力されたデータに対する追跡可能な電子監査証跡が提供されます。
• 隔離されたカスタマーサクセスチームは、輸出規制および ITAR に準拠したデータの安全な取り扱いについて特別に訓練された米国市民で構成されているので、米国籍以外からのサポートはありません。

Keeper FedRAMP 環境は、顧客の輸出コンプライアンスプログラムをサポートするために適切なコントロールが実施されていることを検証するために、独立した第三者評価機関（3PAO）によって監査されており、コンプライアンスを維持するために必要な監査を毎年継続的に受けています。

ITARの詳細情報。

FedRAMP High (高影響レベル) 認証取得

KSGCは、Keeper Securityの公共機関向けのパスワード管理およびサイバーセキュリティプラットフォームです。AWS GovCloud (米国) 環境で運用されるFedRAMP High認可取得済みプロバイダとして、FedRAMP Marketplaceに登録されています。

FedRAMP（Federal Risk and Authorization Management Program）は米国連邦政府のプログラムで、クラウド製品やサービスのセキュリティ評価、認可、継続的モニタリングのための標準化されたアプローチを提供します。FedRAMP は、セキュリティと連邦情報の保護に重点を置き、政府機関による最新のクラウドベースのソリューションの採用を促進することを目指しています。 FedRAMP の詳細をご覧ください。

GovRAMP High (高影響レベル) 認可取得

GovRAMP は、FedRAMP の約 10 年後に開発されたもので、州および地方政府レベルでの安全なクラウドベースのソリューションの採用を促進することを目的としています。GovRAMP 認可を取得するには、通常 2 年間のプロセスが必要ですが、Keeper は FedRAMP 認可されているおかげで、互恵プログラムを通じて合理化されました。

SOC 2 準拠

お客様のボルトの記録は、厳格かつ厳重に監視された内部統制慣行を使用して保護されています。Keeper は、AICPA のサービス組織管理フレームワークに従い、10 年以上にわたり SOC 2 タイプ 2 に準拠するものとして認定されています。SOC 2 コンプライアンスは、AICPA Trust サービス原則フレームワークで定義された標準化されたコントロールの実装を通じて、ユーザーボルトが安全に保たれていることを保証することに役立ちます。

ISO認証

KeeperはISO 27001、27017、27018の認定を取得しています。これらの認証はKeeperセキュリティ情報管理システムおよびクラウドインフラストラクチャを対象としており、Keeperエンタープライズプラットフォームをサポートしています。KeeperのISO認証には、デジタルボルトとクラウドサービスの管理および運用、クラウドセキュリティ対策、データプライバシー対策、ソフトウェアおよびアプリケーションの開発、デジタルボルトとクラウドサービス両方のデジタル資産の保護が含まれています。

FDA 21 CFR Part 11 準拠

Keeper は、臨床試験を行う研究者を含む、高度に規制された環境で働く科学者に適用される 21 CFR Part 11 に準拠しています。この規制は、電子記録と署名が信頼でき、確実性が高く、手書きの署名付きの紙の記録と同等と見なされる FDA 基準を規定しています。具体的には、科学者は使用するすべてのソフトウェアが、以下に関する 21 CFR Part 11 の規則に準拠していることを保証する必要があります：

ユーザー識別のためのセキュリティ管理 - Keeper は、すべてのユーザーが固有のユーザー名とパスワードを持つこと、不正なシステムアクセスを検出および防止する機能、漏洩したアカウントをロックする機能など、ユーザーアクセスおよびその特権を制限するセキュリティ機能に関する 21 CFR Part 11 要件に準拠しています。

詳細な監査証跡

FDA 査察の際、規制当局は研究者にすべての操作の時系列記録を詳述する監査証跡を提供するよう要求します。Keeper のコンプライアンスレポート機能により、研究者は簡単に追跡可能な電子監査証跡を作成することができます。

電子署名

21 CFR Part 11 は、文書が法的拘束力のある電子署名を必要とする場合、固有のログイン情報とパスワードまたは生体認証に署名が添付されることを要求しています。Keeper では、すべてのユーザーが固有のユーザー名とパスワードを持ち、そのユーザーだけがアクセスできるデジタルボルトへと安全に保管されていることを研究者が保証できることにより、この要件をサポートしています。

21 CFR Part 11 に関する詳細はこちらをご覧ください。

医療データ保護標準に準拠

Keeper ソフトウェアは世界的な医療データ保護標準に準拠し、これに制限されることなく、HIPAA（医療保険の携行性と責任に関する法律）ならびにデータ処理補遺条項（DPA）をカバーしています。

HIPAA コンプライアンスと事業提携契約

Keeper は SOC2 認定および ISO 27001 認定のゼロ知識セキュリティプラットフォームであり、HIPAA に準拠しています。プライバシー、機密性、完全性、および可用性をカバーする厳格な遵守と管理が維持されています。このセキュリティアーキテクチャにより、Keeper はユーザーの Keeper ボルトに保管されている ePHI を含むいかなる情報も解読、閲覧、アクセスすることはできません。上記の理由により、Keeper は医療保険の携行性と責任に関する法律（HIPAA）で定義された業務提携者ではなく、したがって、業務提携契約の対象ではありません。

医療プロバイダーと医療保険会社向けの追加の利点の詳細については、このセキュリティ開示全体をお読みいただき、エンタープライズガイドをご覧ください。

FSQS-NL 認証

Keeper Security EMEA Limited は、オランダでセキュリティ、品質、イノベーションが最高水準を満たしていることを認定する Hellios Financial Services Qualification System-Netherlands (FSQS-NL) の下で認定されています。この規格は、Financial Conduct Authority（金融行動監視機構） と Prudential Regulation Authority （英国の金融監督機関）に準拠していることを示し、大手銀行や金融機関向けの Keeper Enterprise ソフトウェアの信頼性を保証しています。

EAR対象品として 米国商務省の輸出許可取得済み

Keeper は、米国輸出管理規制（EAR）に準拠して、輸出商品分類管理番号 5D992 の下で米国商務省産業安全保障局によって認定されています。
EAR の詳細については、https://www.bis.doc.gov をご覧ください。

24時間365日リモートモニタリング

Keeper は、当社のウェブサイトとクラウドセキュリティボルトが世界中で利用可能であることを保証するために、フルタイムの DevOps スタッフとグローバルサードパーティー・監視ネットワークにより、24 時間 365 日監視されています。

このセキュリティ開示に関するご質問がございましたら、こちらまでご連絡ください。

フィッシングやなりすましメール

Keeper Security から送信されたと称するメールを受信し、それが正規のものであるかどうかわからない場合、送信者のメールアドレスが偽造または「なりすまし」された「フィッシングメール」である可能性があります。その場合、メールには KeeperSecurity.com のように見えても、当社のサイトではないウェブサイトへのリンクが含まれている可能性があります。そのウェブサイトは、Keeper Security マスターパスワードの入力を要求したり、個人情報を盗んだり、コンピュータにアクセスするために、不要なソフトウェアをコンピュータにインストールしようとする可能性があります。その他のメールには、他の潜在的に危険なウェブサイトへリダイレクトするリンクが含まれている可能性があります。また、添付ファイルが含まれている可能性もあります。通常そこには、「マルウェア」と呼ばれる迷惑なソフトウェアが含まれています。受信トレイに届いたメールに確信が持てない場合は、リンクをクリックしたり添付ファイルを開いたりすることなく削除してください。

偽物と思われる Keeper からのメールを報告したい場合、またはその他のセキュリティ上の懸念事項がある場合は、こちらまでご連絡ください。

業界最高基準に認証されたホスティングインフラストラクチャ

Keeperのウェブサイトとクラウドストレージはアマゾンウェブサービス(AWS)の保護されたクラウドコンピューティングインフラストラクチャー上で運営されています。Keeperのシステム設計を提供するAWSクラウドインフラストラクチャーは下記のサードパーティーの認証、報告、証明をもって保証されています。

脆弱性レポートとバグ報奨金プログラム

Keeper Security は市場で最も安全なパスワードと特権アクセス管理ソリューションの開発に専念しています。弊社はお客様のプライバシーと個人データを保護することに尽力しています。Keeper の使命は、世界で最も安全で革新的なセキュリティプラットフォームを構築することであり、セキュリティ研究者の世界的なコミュニティからのバグレポートは、Keeper の製品とサービスのセキュリティを確保するために非常に重要なものとして捉えています。

Keeper は NCC Group と CyberTest による完全なソースコードへのアクセスを伴うペンテストを含む、広範な内部および外部テストを実施しています。Keeper は Bugcrowd と提携して脆弱性開示プログラムを運営しています。全体として、業界全体に利益をもたらし、さらに、社会的利益をサポートしています。

ガイドライン

善意のハッカーと共同作業を実施する際は、Keeper の脆弱性情報開示ポリシーをもとに見積りを掲示し、同様にハッカー側も見積りを出せるものとします。

セキュリティテストとレポートがこのポリシーのガイドラインの範囲内で行われる場合：

• コンピュータ不正利用防止法（Computer Fraud and Abuse Act）に従って許可されたものとみなします。
• DMCA の適用外であると考えてください。セキュリティやテクノロジーの制御を回避したとしても、申し立てが行われることはありません。
• 本プログラムは合法的なものであり、本プログラムに関連するいかなる法的措置も追求、支援しません。
• 問題を理解し、迅速に解決するために協力します。
• 最初に問題を報告し、その問題に基づいてコードや設定を変更した場合、その貢献を公に認めるものとします。

本方針のガイドラインとスコープに矛盾しない方法でのテストについて、ご心配やご不明な点がありましたら、お手続きの前に security@keepersecurity.com までご連絡ください。

善意のセキュリティテストならびに発見した脆弱性の情報開示を奨励するにあたり、弊社から以下のお願いがございます：

• ユーザーのプライバシーを侵害したり、ユーザーエクスペリエンスに害を与えたり、生産システムや企業システムを混乱させたり、データを破壊する行為は避けてください。
• 以下のリンクにある Bugcrowd 脆弱性公開プログラムで定められた範囲内でのみ調査を行い、範囲外のシステムや活動を尊重してください。
• テスト中にユーザーデータを見つけた場合は、直ちに security@keepersecurity.com までご連絡ください。
• 脆弱性の発見を公表する前に、報告された問題を分析、確認、解決するための妥当な時間を弊社に提供してください。

レポートは以下から送信してください：https://bugcrowd.com/keepersecurity

透過性

Keeper はセキュリティにコミットしているだけでなく、それを最重要視しています。そのため、当社は暗号化モデルのすべての詳細を公開しています。弊社では、常に変化するサイバーセキュリティ環境の中で、データが安全であることを保証するために取るすべてのステップを、お客様が知る権利があると信じています。

Keeper のゼロトラストおよびゼロ知識暗号化モデルは、最悪のシナリオであっても Keeper ボルトが保護されることを保証し、お客様の最も貴重なデータを保護するための最良のソリューションであり続けることを約束するために、継続的にセキュリティテストを実施しています。

現代の奴隷制に関する声明

製品関連資料

製品マニュアル、技術情報、リリースノートとエンドユーザーガイドを含む Keeper の資料ポータルは、 こちらのリンクからご利用いただけます。

製品リリースノート

Keeper では、透明性を高めるためにすべてのプラットフォームで詳細なリリースノートを公開しています。

システムステータス

リアルタイムのシステムステータスはこちらからご覧いただけます。