認証フローV3
Keeperのログインおよび認証フローのバージョン3: 高度な認証とボルトセキュリティ
Keeperのエンジニアリングチームは、進化するセキュリティ環境とお客様の要件に合わせて、ボルト認証システムのセキュリティと機能を継続的に改善しています。
2020年、私たちは「ゼロ知識」認証システムのセキュリティ面を大きく進化させる「Login API version 3」の提供を開始しました。 このLogin APIは、現在の機能にさらなるセキュリティとユーザビリティの利点を提供し、将来的には新しいエキサイティングな機能の可能性を広げます。
操作性、セキュリティ、および機能のアップデート
最新リリースのログインAPIに含まれる新機能と操作性の改善点は次の通りです。
新しいログイン画面
ログイン画面が簡略化され、メールアドレスから開始するか、法人SSOログインを選択できます。
SSOユーザーの場合: ユーザーのメールドメインがSSO対応のアカウントとして認識されると、ユーザーは法人ドメイン文字列を入力する必要なく、自動的にIDプロバイダにルーティングされます。なお、自動ルーティングは、SSOノードでジャストインタイム（JIT）プロビジョニングが有効になっている場合にのみ実行されます。
「法人SSOログイン」について、「法人ドメイン」名を使用してログインする既存のSSOユーザーは引き続き使用できます。
「マスターパスワードログイン」は、ボルトで代替マスターパスワードを作成したSSOユーザーのログインパスです。 この機能（SSOマスターパスワード）は、Keeper管理者がロールポリシーで有効にする必要があります。
マスターパスワード入力前の二要素認証
マスターパスワードユーザーの場合: デバイスが認識され、二要素認証が有効になっている場合、ユーザーはマスターパスワードを入力する前にプロンプトを受け取ります。マスターパスワードを使用したログインの試行は、ユーザーが二要素認証の手順を通過するまで拒否されます。
注意: 認識されたデバイスを持つユーザーのみが、二要素認証の手順を実行できます。 権限のないデバイスでは二要素認証を要求されません。 Keeperは、デバイスの承認や認識がない場合、ユーザーアカウントの存在を開示しません。
注意: この新しい方法では、ユーザー体験が若干異なります。 マスターパスワードの手順の前に、二要素認証方式を求めるプロンプトが表示されます。
デバイスの承認
Keeperのデバイス検証は、デバイスが承認されていない場合に、ユーザーがボルトをロードできないようにする重要なセキュリティ機能です。次のいずれかの基準に従ってデバイスが「承認」され、ログイン試行を実行できます。
ユーザーが以前にこのデバイスでのログインを承認している
WAN IPアドレスをユーザーが承認済み（設定（Settings） > セキュリティ（Security） > IPアドレスで識別された自動承認デバイス（Auto-Approve Devices from Recognized IP）で制御）*
ユーザーが、チームのメンバーによって事前に承認されたデバイスにあるEnterpriseの一員である
ユーザーがSAML IDプロバイダに正常にログインしている
ユーザーが登録したデバイスから二要素認証コードを入力する
ログインの試行は、デバイスが承認されるまで拒否されます。
デバイスの検証が実行された後、二要素認証が有効になっているKeeperユーザーは、マスターパスワードによるログインを試行する前に、二要素認証の検証手順を通過する必要があります。 デバイスの承認と二要素認証の後、ユーザーはマスターパスワードによるログインに進みます。マスターパスワードの入力前にデバイスの承認と二要素認証の検証を行うことで、ユーザーは不正なログイン試行やパスワードテスト試行から保護されます。 さらに、パスワードの試行回数は10回に制限されており、それ以降は認証の試行回数が制限されます。
(*) IPアドレスの承認は、マスターパスワードでログインするユーザーに対してのみ機能します。 SSO Connect Cloudでログインするユーザは、新しいデバイスすべてにおいて、Keeper Pushまたは管理者承認を実行する必要があります。
その他のデバイス検証方法 ユーザーは、デバイス検証の手順を実行しない場合、アカウントにログインできません。 現在、次のような新しい方法を使用してデバイス検証を実行できます。
メール認証コード
TOTPまたはSMS通知から二要素認証コードを入力する
認識されたデバイスにKeeper Push™メッセージを送信する
自動IPデバイス承認制御
IPアドレスによるデバイスの承認は、ボルトから設定 > セキュリティ > 確認済みIPアドレスからのデバイスを自動承認でユーザーが制御します。
デバイス承認機能Keeper Push™の導入
独自の通知ベースのシステムであるKeeper Pushを介した新しいデバイス承認システムを導入します。 デフォルトでは、ユーザーはメールを使用して認識されないデバイスを承認するよう求められます。 メールが利用できない場合は、新しいオプションがいくつかあります。
マスターパスワードでログインするユーザーは、Keeper Pushを使用して新しいデバイスを承認できます。メールは不要です。
新しいSSO Connect Cloud™機能を使用してログインするEnterpriseユーザーの場合、Keeper Pushを使用すると、ユーザーのデバイス間で安全なデバイス認証と秘密鍵の転送が可能です。 Keeper Pushにより、ユーザーへ既存のIDプロバイダとのシームレスな統合と、デバイス上でゼロ知識暗号化の両立が可能です。
また、Keeper Pushを使用すると、Enterprise SSOユーザーは、他のすべてのデバイスにアクセスできなくなった場合に、Keeper管理者から新しいデバイスの承認を要求できます。 Keeper管理者は、管理コンソールからデバイスを承認できます。
ユーザーがKeeperアカウントのログインを有効化しているデバイスでのみ、Keeper Pushでの承認が可能です。
Keeper Pushのデモ動画
Keeper Pushを使用したマスターパスワードでのログイン:
Keeper Pushを使用したSSOでのログイン:
SSOドメインのルーティング
Enterpriseユーザーが「SSOドメイン」を覚えておく必要性の軽減
ユーザーは自分のメールアドレスを入力するだけで、Keeperはユーザーを適切なIDプロバイダにルーティングします。 これは、Enterpriseのお客様から強く要望されていた機能です。セキュリティ上の理由から、Keeperは、個々のユーザーのメールではなく、ドメイン名に基づいてIdPにルーティングします。
SSOインスタンスがジャストインタイム（JIT）プロビジョニングを使用してKeeper管理コンソールで設定されており、SSOプロビジョニングされたノードにユーザーが追加されている場合、IDプロバイダへのユーザーの自動ルーティングがデフォルトで発生します。
オフライン作業モード
「オフライン作業」モードを選択して、インターネットに接続せずにボルトにログインする機能が追加されました（Enterprise管理者の許可が必要）。 オフラインで作業は、Businessのユーザーのみが利用できます。
オンラインモードに戻すには、右上の「オンラインモードへ変更」をクリックします。
Keeper SSO Connect Cloud™のサポート
マスターパスワードへの依存度の低減
新しいログインAPIは、認証ハッシュを導出するためにユーザーのマスターパスワードをローカルに要求する代わりに、サーバー制御状態でメモリーに動的に格納されるセッショントークンの使用を改善します。 この根本的な変更によって、次のような使いやすくするための機能の可能性を広げます。
マルチデバイスでのセッション管理
ブラウザとコンピュータの再起動の間のセッション再開（「ログイン状態を維持」）
デバイス間リンク（デスクトップアプリとブラウザ拡張機能に同時にログインするなど）
セッション管理、セッション再開、セッション再認証におけるマスターパスワードへの依存を軽減します。
楕円曲線暗号のサポート
ユーザー体験
一連の手順を、フローチャートを交えて以下に示します。ユーザーのパスは、SSO / SAMLシステム（IDプロバイダまたはIdPとも呼ばれる）を使用しているかどうかによって異なります。OktaやMicrosoft Azure、Keeperなどが例として挙げられます。SSOが組織で使用されている場合、ユーザーのパスにはKeeper用の個別のマスターパスワードはありません。代わりに、SSOの認証情報を使用してボルトにアクセスします。
アカウント作成フロー
（既存アカウントへの）ログインフロー
FAQ
Q: ログインできません A: ログインに問題がある場合は、次の操作を試してください。
Webページをハード再読み込み（Shift+再ロードまたはキャッシュのクリア）して、最新のWebボルトまたは管理コンソールをロードしていることを確認します。
正しいデータセンターからKeeperにログインしていることを確認します。 以下に例を示します。
ボルト/USデータセンター: https://keepersecurity.com/vault ボルト/米国政府クラウドデータセンター: https://govcloud.keepersecurity.us/vault ボルト/EUデータセンター: https://keepersecurity.eu/vault ボルト/AUデータセンター: https://keepersecurity.com.au/vault ボルト/カナダデータセンター: https://keepersecurity.ca/vault ボルト/日本データセンター: https://keepersecurity.jp/vault
コンソール/USデータセンター: https://keepersecurity.com/console コンソール/米国政府クラウドデータセンター: https://govcloud.keepersecurity.us/console コンソール/EUデータセンター: https://keepersecurity.eu/console コンソール/AUデータセンター: https://keepersecurity.com.au/console コンソール/カナダデータセンター: https://keepersecurity.ca/console コンソール/日本データセンター: https://keepersecurity.jp/console 間違ったデータセンターにログインしようとすると、アカウントが存在しませんというメール受信やエラー表示がされることがあります。 Q: ログイン画面でIDプロバイダにルーティングされますが、SSOは使いたくありません。 A: ユーザーアカウントがSSO用に設定されたノードの管理コンソールにある場合、Keeperログイン画面からSSOを使用したログインにルーティングされてしまいます。
Keeperに未使用または設定ミスのSSOノードがある場合、ユーザーがリダイレクトされる可能性があります。 この問題を解決するには、Enterpriseサポートにお問い合わせください。
WebボルトにSSOマスターパスワードでログインするには、「法人 SSOログイン」をクリックし、「マスターパスワードログイン」をクリックします。 この画面では、SSOマスターパスワードでログインできます（ロールポリシーで許可されている場合、およびこれが事前に設定されている場合）。
Q: マスターパスワードの前の二要素認証で、ユーザーアカウントを使用できますか？ A: いいえ。承認されたデバイスと外部IPアドレス（IPベースのデバイス承認が有効な場合）のみが、ログイン手順に進むことができます。
Q: 外部の誰かがアカウントにログインして、二要素認証コードでスパムを送ることはできますか？ A: いいえ。承認されたデバイスと外部IPアドレス（IPベースのデバイス承認が有効な場合）のみが、ログイン手順に進んで二要素認証コードを要求できます。 また、Keeperのデバイス承認も二要素認証方式で行えますが、その方法はユーザーに開示しておらず、アカウントの存在を示すものではありません。
Q: IPベースのデバイス承認を無効にする方法を教えてください。 A: Keeperボルト設定（Keeper Vault settings） > セキュリティ（Security）画面で、自動IP承認をオフにします。
Q: マスターパスワードの前に二要素認証を置くことで、セキュリティにどのような影響がありますか？ A: 承認されたデバイスのみがログインを試行できます。 承認されたデバイスは、マスターパスワードをテストする前に、二要素認証手順を通過する必要があります。 Amazon AWSのような極めて安全なサービスも、パスワードと二要素認証に関して同様のフローを実装しています。 パスワードテストとユーザー列挙攻撃の防止は、非常に安全な手法です。 ユーザーの皆様には、すぐに新しいフローに適応していただけると確信しています。
Q: 外部ユーザーとして新しいログインフローをテストするにはどうすればよいですか？ A: 新しいログインフローが外部のユーザーにどのように見えるかを把握するには、自分のアカウントまたはEnterpriseアカウントで使用されていない、認識されていない新しいデバイスおよびネットワーク上にあるボルトを開くだけです。 たとえば、携帯電話のワイヤレスネットワークに接続し、デバイス上でシークレットモードのブラウザウィンドウを開きます。
お問い合わせ
システムのステータスを監視し、リアルタイムのアラートに登録するには、以下にアクセスしてください。 https://statuspage.keeper.io/ サポートが必要な場合は、以下にお問い合わせください。 business.support@keepersecurity.com または、以下のサポートページのチケットを開いてください。 https://www.keepersecurity.com/support.html
Last updated
