Keeper SSO Connect Cloudの技術的説明
Keeperはゼロ知識セキュリティプロバイダです。ゼロ知識は、以下の原則を守ることで、最高レベルのセキュリティとプライバシーを保証するシステムアーキテクチャです（SSO Cloudモデル）。
データは、（サーバー上ではなく）デバイスレベルで暗号化および復号化します
アプリケーションはプレーンテキスト（人間が読める）データを保存しません
サーバーはプレーンテキストのデータを受信しません
Keeperの従業員または第三者が暗号化されていないデータを見ることはできません
データを復号化および暗号化する鍵は、ユーザー（および企業の管理者）が管理します
マルチレイヤー暗号化により、ユーザー、グループ、管理者レベルでアクセス制御します
データの共有には公開鍵暗号を使用し、安全な鍵配布を実現します
データは、ユーザーのデバイス上でローカルに暗号化されてから、Keeper's Cloud Security Vaultに送信されて保存されます。データが他のデバイスに同期されると、そのデバイスで復号化されるまでデータは暗号化されたままになります。
Keeperは、世界で最も多くの認証、テスト、監査を受けた、最も安全なパスワードセキュリティプラットフォームです。Keeperは、業界で唯一のSOC 2およびISO 27001認証パスワード管理ソリューションであり、米国商務省のEU-米国間プライバシーシールドプログラムに準拠し、データ保護に関する欧州委員会の指令にも適合しています。最も安全なレベルの暗号化を実装するだけでなく、第三者によって絶えず監査される極めて厳格な社内規範を遵守し、安全なソフトウェアの開発と、世界で最も安全なサイバーセキュリティプラットフォームの提供を確実に継続できるように努めています。
Keeper SSO Connect Cloudは、完全なクラウド環境で標準のSAML 2.0プロトコルを使用するサードパーティのIDプロバイダ（IdP）を利用して認証することによって、ユーザーを認証し、ゼロ知識暗号化ボルトに保存されたデータを復号化する方法をKeeper Enterpriseのお客様に提供します。
この実装では、ユーザーはSSO IDプロバイダを使用して認証を受け、ローカルのユーザーデバイス上で自分のボルトの暗号文を復号化できます。デバイスごとに独自のEC（楕円曲線）公開鍵/秘密鍵のペアと暗号化されたデータキーを設定します。 ユーザーごとに独自のデータキーを設定します。新しいデバイスにサインインするには、ユーザーが既存のデバイスを利用して承認を実行するか、または特権を持つ管理者が新しいデバイスを承認する場合もあります。
この新機能の重要性は、ユーザーがKeeperクラウドに保存された暗号鍵を使用して、自分のボルトを復号化できることにあります。 Keeperクラウドはユーザーのデバイス上でユーザーのデータキーを復号化できないため、ゼロ知識が維持されるのです。ユーザーのデータキー（「DK」）はデバイスの秘密鍵（「DPRIV」）で復号化されます。暗号化されたデータキー（「EDK」）をユーザーが利用できるのは、指定されたIDプロバイダ（Okta、Azure、AD FSなど）による認証に成功した場合のみです。
SSO Connect Cloudのユーザーの場合、デバイスごとに楕円曲線の秘密鍵が生成されて、ローカルに保存されます。Chromiumベースのウェブブラウザの場合、Keeperボルトは、ローカルデバイスの楕円曲線秘密鍵（「DPRIV」）をエクスポートできない暗号鍵として保管します。 iOSおよびMacデバイスでは、鍵はデバイスのキーチェーンに保存されます。 利用可能な場合、Keeperは安全なストレージメカニズムを利用します。
デバイスの秘密鍵がボルトデータの暗号化や復号化に直接使用されることはありません。 IDプロバイダによる認証が成功すると、ボルトデータの復号化には（保管されていない）別の鍵が使用されます。 ローカルデバイスの秘密鍵をオフラインで抽出しても、ユーザーのボルトは復号化できません。
デバイス/プラットフォームによってセキュリティレベルが異なるため、最適なセキュリティを提供するには、最新のChromiumベースのウェブブラウザの使用をお勧めします。
不正アクセスされたデバイスによる攻撃に対する一般的な防御として、すべてのデバイス（デスクトップコンピュータなど）をディスクレベルの暗号化と最新のマルウェア対策ソフトウェアで保護することもお勧めします。
新しいデバイスにサインインするには、ユーザーが既存のデバイスを利用して承認を実行するか、または特権を持つ管理者が新しいデバイスを承認する場合もあります。 新しいデバイスで公開鍵/秘密鍵のセットが新たに生成されます。承認デバイスは、この新しいデバイスの公開鍵でユーザーのデータキーを暗号化します。 新しいデバイスの暗号化されたデータキー（EDK）が要求元のユーザーやデバイスに送信されると、ユーザーはこのデータキーを復号化できるため、自分のボルトデータも復号化できます。 ユーザーは復号化されたボルトデータ内で、記録鍵、フォルダ鍵、チーム鍵などの他の秘密暗号鍵を復号化できます。
この機能の重要性は、ユーザーがKeeperクラウドに保存された暗号鍵を使用して自分のボルトを復号化できるという点と、暗号鍵を管理するためにオンプレミスのサービスもユーザーがホストするアプリケーションサービスも必要としないという点にあります。 Keeperクラウドはユーザーのデバイス上でユーザーのデータキーを復号化できないため、ゼロ知識が維持されるのです。ユーザーのデータキーはデバイスの秘密鍵（DPRIV）で復号化されます。EDKをユーザーが利用できるのは、指定されたIDプロバイダ（Okta、Azure、AD FSなど）による認証に成功した場合のみです。
管理者の目から見たメリットは、Keeper の現行SSO Connectの暗号化モデルで説明されている通り、設定が簡単で、暗号鍵の管理にホスト型のソフトウェアが必要ないことです。
Keeper SSO Connectのオンプレミス実装に対する、このモデルのワークフローの唯一の違いは、ユーザーが有効なデバイスで新しいデバイスの承認を実行するか、またはKeeper管理者にデバイス承認を実行する責務を委任する必要があるという点です。
Keeper SSO Connect Cloudは、以下に記載した、SPが起点となるログインフローとIdPが起点となるログインフローの両方をサポートしています。
1) SPが起点となるログイン（「企業ドメイン」を使用）
ユーザーは、Keeperボルトのログイン画面で「企業ドメイン」を入力します。
Keeperは、Keeper SSO Cloudインスタンスに設定されたSAMLログインURLを取得します（https://keepersecurity.com/api/rest/sso/saml/login/12345678など）。
ユーザーはこの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 Connect Cloudは、ユーザーをボルトにリダイレクトします。
ユーザーのデバイスを認識できない場合、Keeperはデバイスの検証を実行します（「Keeper プッシュ通知」または「管理者承認」を使用）。
デバイスの検証と鍵交換が成功すると、Keeperは暗号化されたデータキーをユーザーに送信します。
ユーザーは、自分のデバイスの秘密鍵を使用して、デバイスでデータキーを復号化します。
ユーザーはこのデータキーを使用してボルトを復号化します。
2) SPが起点となるログイン（メールを使用）
Keeperのボルトログイン画面から、ユーザーは自分のメールアドレスを入力します。
ユーザーが認証済みのデバイスを使用している場合は、メールが検索されて、SAMLログインURLに変換されます。
デバイスが認識されていない場合、Keeperはドメイン部（@company.com）をチェックして、Keeper SSO Cloudインスタンスに設定されたSAMLログインURLを取得します（https://keepersecurity.com/api/rest/sso/saml/login/12345678など）。
ユーザーはこのKeeperログインURLにリダイレクトされます。
後は、前述のSPが起点となるログインと同じ手順に従います。
3) IdPが起点となるログイン
ユーザーは、IDプロバイダのウェブサイト（https://customer.okta.comなど）にログインします。
ユーザーは、IDプロバイダのポータルでKeeperアイコンをクリックします。
ユーザーは事前に定義された「ACS URL」でKeeperにリダイレクトされます（これは、IdPの設定に応じて「Redirect」または「Post」を使用できます）。
IdPからKeeperへのSAMLメッセージには、ユーザーがIdPで正常に認証されたことを検証した署名付きアサーションが含まれています。 Keeperは、IdPの公開鍵で署名付きアサーションを検証し、アサーションが改ざんされていないことを確認します。 Keeperは、メッセージがKeeperの公開鍵で署名されていることも検証します。
SAML属性「First」、「Last」、「Email」は、IdPからKeeperに送信されます。
Keeper SSO Connect Cloudは、ユーザーをボルトにリダイレクトします。
ユーザーのデバイスを認識できない場合、Keeperはデバイスの検証を実行します（Keeperプッシュ通知または管理者承認を使用）。
デバイスの検証と鍵交換が成功すると、Keeperは暗号化されたデータキーをユーザーに送信します。
ユーザーは、自分のデバイスの秘密鍵を使用して、デバイスでデータキーを復号化します。
ユーザーはこのデータキーを使用してボルトを復号化します。
Keeper暗号化モデルの詳細は、以下のリンクをご参照ください。 https://docs.keeper.io/enterprise-guide/keeper-encryption-model
質問:管理者がKeeper Webコンソールを使用して新しいユーザーデバイスを承認する場合、ユーザーの暗号化されたデータキーはどのような方法で新しいデバイスに転送されますか。 各デバイスは、一意の楕円曲線（EC）公開鍵と秘密鍵のペアをデバイス内で生成します。公開鍵はサーバーに保管されています。 ユーザーがデバイス承認を要求すると、新しいデバイスの公開鍵がサーバーに送信されます。「デバイス承認」権限を持つ管理者は、デバイスの承認処理中にユーザーのデータキーを復号化できます。管理者がデバイスを審査して承認すると、ユーザーのデータキー（DK）は新しいデバイスの（EC）公開鍵で再度暗号化され、暗号化されたデータキーはそのユーザーのデバイスに関連付けられたサーバーに保管され、新しいデバイスにも送信されます。新しいデバイスは、デバイスの（EC）秘密鍵でデータキーを復号化します。
質問:データキーを復号化するのは、新しいデバイスの秘密鍵で暗号化するためですか。 管理者は、承認を実行する際に、メモリ内のデータキーを復号化し、管理コンソール内で新しいデバイスの公開鍵を使用して再度暗号化します。ユーザーがSSOにサインインすると、サーバーは認証を検証して、暗号化されたデータキーを新しいデバイスに送信します。すると、新しいデバイスは、デバイス内のEC秘密鍵でデータキーを復号化します。ユーザーがログインしてIDPの認証を受けるたびに、暗号鍵がデバイスに送信され、メモリ内で復号された後、記録鍵、フォルダ鍵などの暗号化/復号化に使用されます。
質問:データキーは、復号化された状態でどこに保管されていますか。 データキーは、復号化された状態で保管されることはありません。データキーは、デバイスの公開鍵で暗号化されてクラウドに保管されています。つまり、ユーザーが10台のデバイスを保有している場合、各デバイスの公開鍵で暗号化された10個のデータキーを保管しているということです。データキーの再暗号化は、ゼロ知識を維持するために、ユーザーまたは管理者によって必ずデバイス内で行われます。
質問:Automatorが新しいユーザーデバイスを承認する場合、同じ質問になりますが、ユーザーのデータキーの暗号化処理はどこで行われているのですか。 Automatorが実行する処理はまったく同じです。リクエスト時にユーザーのデータキーを復号化し、認証を検証して、新しいデバイスのEC公開鍵でデータキーを再度暗号化した後、暗号化されたデータキーをユーザーのデバイスに転送します。
質問:ユーザーがデータをボルトに暗号化しているにもかかわらず、ユーザーのデータキーの共有を実行できるデバイスがない場合はどうなりますか。 Automatorと管理者は、ユーザーがすべてのデバイスを紛失した場合でも、常にデバイス承認を実行できます。
質問:新しいデバイスを追加するには、新しいユーザーデバイスと古いユーザーデバイスの両方がオンラインである必要がありますか。 いいえ、承認は非同期で実行できます。
質問:データキーがデバイス上でしか復号化されないのであれば、データキーを新しいデバイスの公開鍵で暗号化するには、古いデバイスがオンラインでなければならないように思われます。 承認プロセス全体は、リアルタイムで実行することも段階を分けて実行することもできます。アプリは、ログイン時にユーザーに承認を求め、データキーを新しい公開鍵で暗号化して、サーバーに送信します。その過程を以下のビデオでご紹介します。