# セキュリティとユーザーフロー ### ゼロ知識アーキテクチャ Keeperはゼロ知識セキュリティプロバイダです。ゼロ知識は、以下の原則を守ることで、最高レベルのセキュリティとプライバシーを保証するシステムアーキテクチャです (SSOクラウドモデル)。 * データは、(サーバー上ではなく) デバイスレベルで暗号化および復号化します * アプリケーションはプレーンテキスト (人間が読める) データを保存しません * サーバーはプレーンテキストのデータを受信しません * Keeperの従業員または第三者が暗号化されていないデータを見ることはできません * データを復号化および暗号化する鍵は、ユーザー (および企業の管理者) が管理します * マルチレイヤー暗号化により、ユーザー、グループ、管理者レベルでアクセス制御します * データの共有には公開鍵暗号を使用し、安全な鍵配布を実現します データは、ユーザーのデバイス上でローカルに暗号化されてから、Keeperのクラウドボルトに送信されて保存されます。データが他のデバイスに同期されると、そのデバイスで復号化されるまでデータは暗号化されたままになります。 Keeperは、認証取得や第三者による検証・監査を経たうえで世界でも屈指の安全性を誇るパスワードセキュリティプラットフォームです。業界で唯一SOC 2およびISO 27001の認証を取得したパスワード管理ソリューションであり、米国商務省のEU-米国間プライバシーシールドにも適合し、データ保護に関する欧州委員会の指令にも沿った運用が可能です。最高水準の暗号化を実装するとともに、第三者による継続的な監査のもとで厳格な社内規範を守り、安全なソフトウェア開発と世界水準のサイバーセキュリティプラットフォームを維持するよう努めています。 ### クラウドSSOコネクトの暗号化モデル KeeperクラウドSSOコネクトは、完全なクラウド環境で標準のSAML 2.0プロトコルを用いるサードパーティのIDプロバイダ (IdP) による認証を通じてユーザーを認証し、ゼロ知識暗号化ボルトに保存されたデータを復号化する、Keeperエンタープライズ向けの仕組みです。 この実装では、ユーザーはSSO IDプロバイダで認証したうえで、ローカルのユーザーデバイス上で自分のボルトの暗号文を復号化できます。デバイスごとに独自のEC (楕円曲線) 公開鍵/秘密鍵のペアと暗号化されたデータキーが生成されます。ユーザーごとにデータキーが1つあります。新しいデバイスでサインインするには、ユーザーが既存のデバイスで承認するか、権限を持つ管理者が新しいデバイスを承認します。 この新機能の重要性は、ユーザーがKeeperクラウドに保存された暗号鍵を使用して、自分のボルトを復号化できることにあります。 Keeperクラウドはユーザーのデバイス上でユーザーのデータキーを復号化できないため、ゼロ知識が維持されるのです。ユーザーのデータキー (「DK」) はデバイスの秘密鍵 (「DPRIV」) で復号化されます。暗号化されたデータキー (「EDK」) をユーザーが利用できるのは、指定されたIDプロバイダ (Okta、Azure、AD FSなど) による認証に成功した場合のみです。 ![KeeperクラウドSSOコネクトの暗号化モデル](https://1914737032-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Mfd2v-YT48Ljtykb8qm%2Fuploads%2FZqKSgRZc7MQA2ARWTn3j%2Fsso-connect-cloud-encryption-model-v2.jpg?alt=media\&token=3f885511-9fea-4b8e-a481-33279deea0e5) ### クラウドSSOコネクトのセキュリティ クラウドSSOコネクトを利用する場合、デバイスごとに楕円曲線の秘密鍵が生成され、ローカルに保存されます。Chromiumベースのウェブブラウザでは、ローカルデバイスの楕円曲線秘密鍵 (「DPRIV」) は、エクスポートできない暗号鍵としてKeeperボルトに保管されます。iOSおよびMacデバイスでは、鍵はデバイスのキーチェーンに保存されます。利用できる環境では、安全なストレージ機構を用います。 デバイスの秘密鍵がボルトデータの暗号化や復号化に直接使用されることはありません。IDプロバイダによる認証が成功すると、ボルトデータの復号化には (保管されていない) 別の鍵が使われます。ローカルデバイスの秘密鍵をオフラインで抽出しても、ユーザーのボルトは復号化できません。 デバイス/プラットフォームによってセキュリティレベルが異なるため、最適なセキュリティを提供するには、最新のChromiumベースのウェブブラウザの使用をお勧めします。 不正アクセスされたデバイスによる攻撃に対する一般的な防御として、すべてのデバイス (デスクトップコンピュータなど) をディスクレベルの暗号化と最新のマルウェア対策ソフトウェアで保護することもお勧めします。 ### デバイス承認 新しいデバイスにサインインするには、ユーザーが既存のデバイスで承認するか、権限を持つ管理者が新しいデバイスを承認します。新しいデバイスでは公開鍵/秘密鍵のセットが新たに生成されます。承認側のデバイスは、新しいデバイスの公開鍵でユーザーのデータキーを暗号化します。新しいデバイス向けの暗号化データキー (EDK) が要求元のユーザーまたはデバイスに渡ると、ユーザーはデータキーを復号化でき、ボルトデータも復号化できます。復号化されたボルトデータのなかで、レコード鍵、フォルダ鍵、チーム鍵などの秘密鍵も復号化できます。 この機能の重要性は、ユーザーがKeeperクラウドに保存された暗号鍵を使用して自分のボルトを復号化できるという点と、暗号鍵を管理するためにオンプレミスのサービスもユーザーがホストするアプリケーションサービスも必要としないという点にあります。 Keeperクラウドはユーザーのデバイス上でユーザーのデータキーを復号化できないため、ゼロ知識が維持されるのです。ユーザーのデータキーはデバイスの秘密鍵 (DPRIV) で復号化されます。EDKをユーザーが利用できるのは、指定されたIDプロバイダ (Okta、Azure、AD FSなど) による認証に成功した場合のみです。 管理者の目から見たメリットは、Keeperの現行SSO Connectの暗号化モデルで説明されている通り、設定が簡単で、暗号鍵の管理にホスト型のソフトウェアが必要ないことです。 オンプレミスのKeeper SSOコネクトと比べたこのモデルでのワークフローの違いは、ユーザーが使用中のデバイスで新規デバイスを承認するか、Keeper管理者にデバイス承認を任せる必要がある点だけです。 ### ログインフロー KeeperクラウドSSOコネクトでは、以下に示すSP起点とIdP起点のログインフローを利用できます。 1. **SPが起点となるログイン (「企業ドメイン」を使用)** * ユーザーは、Keeperボルトのログイン画面で「企業ドメイン」を入力します。 * Keeperは、Keeper SSOクラウドインスタンスに設定されたSAMLログインURLを取得します ( * ユーザーはこのSAMLログインURLにリダイレクトされます。 * Keeperは、エンティティIDとKeeperの公開鍵、およびセッションを識別する「Relay State」を含むエンコードされたSAMLリクエストをIdPに送信します。 * ユーザーは通常どおりIdPのログイン画面にサインインします。 * IdPへのサインインに成功すると、ユーザーは事前に定義された「ACS URL」でKeeperにリダイレクトされます (これは、IdPの設定に応じて「Redirect」または「Post」を使用できます）。 * IdPからKeeperへのSAMLメッセージには、ユーザーがIdPで正常に認証されたことを検証した署名付きアサーションが含まれています。 Keeperはこの署名付きアサーションを検証します。 * SAML属性「First」、「Last」、「Email」は、IdPからKeeperに送信されます。 * KeeperクラウドSSOコネクトは、ユーザーをボルトにリダイレクトします。 * ユーザーのデバイスを認識できない場合、Keeperはデバイスの検証を実行します (「Keeperプッシュ通知」または「管理者承認」を使用)。 * デバイスの検証と鍵交換が成功すると、Keeperは暗号化されたデータキーをユーザーに送信します。 * ユーザーは、自分のデバイスの秘密鍵を使用して、デバイスでデータキーを復号化します。 * ユーザーはこのデータキーを使用してボルトを復号化します。 2. **SPが起点となるログイン (メールを使用)** * Keeperのボルトログイン画面から、ユーザーは自分のメールアドレスを入力します。 * ユーザーが認証済みのデバイスを使用している場合は、メールが検索されて、SAMLログインURLに変換されます。 * デバイスが認識されていない場合、Keeperはドメイン部 (@company.com) を確認し、Keeper SSOクラウドインスタンスに設定されたSAMLログインURLを取得します ( * ユーザーはこのKeeperログインURLにリダイレクトされます。 * 後は、前述のSPが起点となるログインと同じ手順に従います。 3. **IdPが起点となるログイン** * ユーザーは、IDプロバイダのウェブサイト () にログインします。 * ユーザーは、IDプロバイダのポータルでKeeperアイコンをクリックします。 * ユーザーは事前に定義された「ACS URL」でKeeperにリダイレクトされます (これは、IdPの設定に応じて「Redirect」または「Post」を使用できます）。 * IdPからKeeperへのSAMLメッセージには、ユーザーがIdPで正常に認証されたことを検証した署名付きアサーションが含まれています。 Keeperは、IdPの公開鍵で署名付きアサーションを検証し、アサーションが改ざんされていないことを確認します。 Keeperは、メッセージがKeeperの公開鍵で署名されていることも検証します。 * SAML属性「First」、「Last」、「Email」は、IdPからKeeperに送信されます。 * KeeperクラウドSSOコネクトは、ユーザーをボルトにリダイレクトします。 * ユーザーのデバイスを認識できない場合、Keeperはデバイスの検証を実行します (「Keeperプッシュ通知」または「管理者承認」を使用)。 * デバイスの検証と鍵交換が成功すると、Keeperは暗号化されたデータキーをユーザーに送信します。 * ユーザーは、自分のデバイスの秘密鍵を使用して、デバイスでデータキーを復号化します。 * ユーザーはこのデータキーを使用してボルトを復号化します。 ### セキュリティに関する詳細補足情報 Keeper暗号化モデルの詳細は、[こちら](/jp/enterprise-guide/keeper-encryption-model.md)のページをご参照ください。 ## セキュリティモデルに関する質問と回答 **質問1. 管理者がKeeperウェブコンソールを使用して新しいユーザーデバイスを承認する場合、ユーザーの暗号化されたデータキーはどのような方法で新しいデバイスに転送されますか。**\ 各デバイスは、一意の楕円曲線 (EC) 公開鍵と秘密鍵のペアをデバイス内で生成します。公開鍵はサーバーに保管されています。 ユーザーがデバイス承認を要求すると、新しいデバイスの公開鍵がサーバーに送信されます。「デバイス承認」権限を持つ管理者は、デバイスの承認処理中にユーザーのデータキーを復号化できます。管理者がデバイスを審査して承認すると、ユーザーのデータキー (DK) は新しいデバイスの (EC) 公開鍵で再度暗号化され、暗号化されたデータキーはそのユーザーのデバイスに関連付けられたサーバーに保管され、新しいデバイスにも送信されます。新しいデバイスは、デバイスの (EC) 秘密鍵でデータキーを復号化します。 **質問2. データキーを復号化するのは、新しいデバイスの公開鍵で再暗号化するためですか。**\ 管理者は承認時に、メモリ上でデータキーを復号化し、管理コンソール内で新しいデバイスの公開鍵を使って再暗号化します。ユーザーがSSOにサインインすると、サーバーが認証を確認したうえで暗号化されたデータキーが新しいデバイスに渡り、デバイスはローカルのEC秘密鍵でデータキーを復号化します。ログインのたびにIDプロバイダの認証を確認すると、暗号化されたキーがデバイスに渡り、メモリ上で復号したうえでレコード鍵やフォルダ鍵などの暗号化・復号に使われます。 **質問3. データキーは、復号化された状態でどこに保管されていますか。**\ データキーは、復号化された状態で保管されることはありません。データキーは、デバイスの公開鍵で暗号化されてクラウドに保管されています。つまり、ユーザーが10台のデバイスを保有している場合、各デバイスの公開鍵で暗号化された10個のデータキーを保管しているということです。データキーの再暗号化は、ゼロ知識を維持するために、ユーザーまたは管理者によって必ずデバイス内で行われます。 **質問4. オートメーターが新しいユーザーデバイスを承認する場合、同じ質問になりますが、ユーザーのデータキーの暗号化処理はどこで行われているのですか。**\ オートメーターが実行する処理は同じです。リクエスト時にユーザーのデータキーを復号化し、認証を確認したうえで、新しいデバイスのEC公開鍵でデータキーを再暗号化し、暗号化されたデータキーをユーザーのデバイスへ送ります。 **質問5. ボルト内のデータは暗号化されている一方で、ユーザーのデータキーを共有できるデバイスがない場合はどうなりますか。**\ オートメーターと管理者は、ユーザーがすべてのデバイスを紛失した場合でも、常にデバイス承認を実行できます。 **質問6. 新しいデバイスを追加するには、新しいユーザーデバイスと古いユーザーデバイスの両方がオンラインである必要がありますか。**\ いいえ、承認は非同期で実行できます。 **質問7. データキーがデバイス上でしか復号化されないのであれば、データキーを新しいデバイスの公開鍵で暗号化するには、古いデバイスがオンラインでなければならないように思われます。**\ 承認プロセス全体は、リアルタイムで実行することも段階を分けて実行することもできます。アプリは、ログイン時にユーザーに承認を求め、データキーを新しい公開鍵で暗号化して、サーバーに送信します。その過程を以下のビデオでご紹介します。 {% embed url="" %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.keeper.io/jp/sso-connect-cloud/security-and-user-flow.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.