『パスワードレス化に向けた管理者ガイド』ブログシリーズ
この記事は、Tech Lead である Jeremy Erickson によるブログ「Administrator’s Guide, Part 4: Phases of a Passwordless Rollout
」（2021/7/29）の抄訳です。
現在、組織でパスワードレス認証を検討している場合は、全体的な認証戦略の策定も考慮されているでしょう。パスワードレス化すれば、強力で使いやすい認証システムに移行するために実施すべき多くのステップを、大きく進められます。
パスワードレス化プロセスの概要
フェーズ 1：多要素認証の確立とパスワードレスユースケースの特定
多要素認証は、10 年以上にわたって、強力な認証システムの重要なコンポーネントであり続けています。すでに導入されているのが理想ですが、まだであっても、パスワードベースの単一要素認証に対する脅威を軽減できる製品は無数にあります。
フェーズ 2：認証ワークフローの統合
一般的な企業では、何百ものアプリケーションを運用しています。この規模で各アプリケーションの認証方式とセキュリティポリシーを個別に管理していては、管理者はすぐに対応しきれなくなります。フェーズ 2 では、各アプリケーションのセキュリティを個別に強化するのではなく、認証イベントの大半を一元管理できるシステムに、認証ワークフローを統合することに注力します。
シングルサインオン（SSO）方式を採用したり、セキュリティ アサーション マークアップ言語（SAML）や OpenID Connect（OIDC）などの標準プロトコルを利用したフェデレーテッドポータルを導入したりすることで実現できます。SSH クライアントやリモート デスクトップ ソフトウェアなど、Web ベースではないアプリケーションであっても、リバースプロキシとクライアントソフトウェア（パスワードなしの Web プロンプトが開く）を使用することで、パスワードレス化を進めることができます。
さまざまなエクスペリエンスや機能を備えている製品やサービスが多数ありますが、自社で必要な機能と使用しているアプリケーションが対応しているプロトコルの両面
から、どの製品やサービスが適しているかを判断できます。
フェーズ 3：認証の信頼性を高める
次に、より包括的なユーザ認証システムを構築し、環境内の新たな脅威を軽減することに重点を置きます。ここでは、最新のソフトウェアとオペレーティングシステムを導入して、既知の信頼できるデバイスからユーザ認証が行われていることを確認します。また、ユーザの異常なふるまいを検出し、修復フラグを付与します。さらに、安全な状態と危険なふるまいを特定し、セキュリティを損なうことなくユーザの負担を軽減できる、柔軟なポリシーを設定します。これらすべてに対応できるかどうかは、フェーズ 2 での作業と、必要な機能をサポートするベンダーの選択にかかっています。
フェーズ 4：パスワードレス認証を導入（今はこの段階）
パスワードレス化を進めるには、ユーザのアクセスデバイスと SSO ポータルまたはフェデレーテッドシステムの両方での対応が必要です。Microsoft 社、Apple 社、Google 社などのシステムベンダーは、パスワードレス化をサポートするために、アクセスデバイスに優れた機能を提供しています。また、Yubico 社、Feitian 社、SoloKeys 社などのセキュリティキーベンダーは、パスワードレスをネイティブにサポートしていないデバイスでも対応できるような製品を提供しています。SSO およびフェデレーション
プロバイダーは、パスワードレス ソリューションをオンラインで提供し始めています。フェーズ 2 で認証ワークフローを一元化された認証エクスペリエンスに統合できている場合は、スイッチを入れるだけで組織の大部分でパスワードレスを有効にできる可能性があります。既存の認証/認可ポリシー、デバイスの信頼ステータス、設定は、すぐに移行して有効にするのが理想です。
フェーズ 5：パスワードレスの最適化
すべてのアプリケーションで同じフェデレーション ソリューションを使用するように統合できていなければ、パスワードの使用を完全になくすまでには時間がかかるでしょう。この段階では、MFA、設定可能なポリシー、デバイスの信頼ステータス、適応型認証機能を備えた階層型セキュリティモデルを使用することでメリットが得られます。この段階の組織は、最も弱い認証方式と同じレベルのセキュリティしかないため、それぞれの認証方式を強力にすることで、完全パスワードレスに移行する際のリスクを軽減します。ここでの目標は、パスワードレス化に対応した集中型認証ソリューションに認証ワークフローを統合することを続け、パスワードベースの認証を無効にするプロセスを開始することです。
このフェーズは長期間にわたります。パスワードを無効にすると、組織内でパスワードが使用される可能性のあるあらゆる種類のケース（新規ユーザのオンボーディングやアカウントの回復など）や、何か想定外の問題が発生した場合に備えて地下に保管してあるサーバなどが明らかになるからです。特定のアプリケーションやプロトコルは、最初はパスワードレス化できない可能性が高いため、一部のユーザは、該当のシステムで使用するためにしばらくパスワードを保持する必要があります。
パスワードレスは魅力的で、セキュリティと使いやすさの両面でメリットがあります。フェーズ 4 ではユーザビリティ面でのメリットが、フェーズ 5 ではセキュリティ面でのメリットが得られますが、他にもさまざまなメリットがあります。ただし、パスワードがオプションとして残っている限り、現在と同じ攻撃がパスワードベースの認証方式に仕掛けられる可能性があります。オプションとしてパスワードレス認証を追加する場合は、認証を簡単にすることから始めます。パスワードオプションをなくすと、認証がより安全になります。
パスワードを頻繁に使用する場合、それ以外の認証要素を追加すれば、多くの反発が予想されますが、パスワードレスが主な認証方式である場合は、まれにフォールバックするための方式として受け入れられやすくなります。セキュリティ上のメリットは、ユーザの習慣を変えるだけでも得られます。たとえば、パスワードレス認証に慣れたユーザは、パスワードがオプションとして認められていても、予期しないプッシュ通知やパスワード入力フィールドがあると気になってしまいます。これは、より使いやすいオプションの方がより安全だということで、認証テクノロジーにおける画期的な進歩の 1 つです。
しかし、すべてがバラ色だとは言えません。そこで、フェーズ 4 と 5 を掘り下げ、パスワードレス化する際に直面する可能性のあるいくつかの課題と対応方法について説明します。
パスワードレス化の最初の数週間
スイッチをオンにして、パスワードレスでの最初のログインを有効にすると、おそらく不思議な感じがするでしょう。このガイドを読んでいる管理者の方は、オーセンティケータデバイスがクレデンシャルを保存して使用する方法を理解しているので、どのような仕組みになっているかを推測できるでしょう。一方でユーザは、何をすべきかわからないかもしれません。パスワードレスでのログインは、パスワードを使用するよりもすばやく簡単に実行できるはずですが、ほとんどの人はパスワードを数年または数十年に渡って使用してきているため、パスワード入力フォームが表示されないと、どうすればよいかわからない可能性があります。
ユーザはすぐにパスワードレスに慣れますが、最初は、指紋や顔をスキャンする馴染みのないプロンプトが表示されると、不安になるかもしれません。ユーザが Web フォームにシステムパスワードを入力しようと考えている場合、PIN またはローカルシステムのパスワードの入力を求められると混乱し、場合によっては不審に思うこともあります。パスワードレスでのログインフローを管理者自身が評価し、最初のパスワードレスログインでユーザをサポートするための戦略を立てることをお勧めします。
ただし、パスワードレスログインを始める前に、ユーザは、アカウントまたはプロファイルに、クレデンシャルかオーセンティケータデバイスを登録する必要があります。この作業は、最初のログインと同じくらいわかりにくいかもしれません。ただし、MFA の設定によっては、二要素認証方式によってすでにパスワードレス認証に慣れている可能性もあります。
ユーザが Windows Hello、Touch ID、Face ID、Fingerprint/Face Unlock、または FIDO2 認定のセキュリティキーなどの WebAuthn 対応 2FA 方式を採用し、第 2 要素として定期的に使用している場合、認証プロバイダーがユーザ検証をサポートしていれば、パスワードレス認証に同じクレデンシャルを使用できる場合があります。そうでない場合に新しいパスワードレスデバイスを登録する最も簡単な方法は、通常のパスワードベースの認証を利用し、通常のログインプロセスの一貫として、デバイスを登録するようにユーザに求めることです。この方法なら、ユーザがパスワードを入力した後に MFA デバイスを初めて登録した時とほぼ同じように感じられるはずです。次回のログインからは、パスワードなしで使用できるようになります。
次に、パスワードレス化して数週間が経過し、ユーザの 1 人が最初のデバイスを無くした状態を考えみましょう。デバイス上のユーザクレデンシャルは、PIN または生体情報を検証するステップで保護されますが、そのクレデンシャルをすぐに無効にする必要があります。それはもう必要な機能を失っているからです。認証プロバイダーは、コントロールパネルまたは管理コンソールを提供し、管理者が、ユーザや、ユーザが登録したデバイスを確認できるようにしています。このインターフェイスを使用して、紛失したデバイスとクレデンシャルを迅速かつ簡単に無効にできます（各デバイスは、1 ユーザアカウントにつき 1 つのクレデンシャルしか持っていないことになっています）。まだパスワードを無効にしていない場合は、ユーザが次回ログインするときに、自分のパスワードを使用して代わりのオーセンティケータデバイスを登録できます。
パスワードの削除：アプリケーションとユーザ
フェーズ 4 の段階では、パスワードはフォールバックオプションとして引き続き有効です。フェーズ 4 での課題に対応するには多くの時間が必要になる可能性がありますが、技術的な複雑さ自体よりも、ユーザが新しいプロセスに慣れるようにサポートすることに時間がかかります。最初は組織内の小規模なグループから始め、段階的にパスワードレス化していくと、問い合わせがスムーズに対応され、早期導入者がパスワードレスの知識を他の同僚と共有できるようになります。
フェーズ 5 に進み、パスワードオプションを削除し始めると、状況は複雑になってきます。パスワードレスログインに慣れていないユーザは、パスワードベースにフォールバックできなくなると行き詰まってしまいます。フェーズ 5 の目標は、新たな問題を最小限に抑えながら、環境からパスワードを削除してセキュリティを強化することです。ここでは、パスワードを削除する際に発生する可能性のあるいくつかの問題について説明します。
まず、すべてのアプリケーションがパスワードレス化できるわけではありません。たとえば、ワイヤレスネットワークに接続するアプリケーションがあります。クライアント証明書を導入していない限り、メインの WPA2 Personal および Enterprise 認証プロトコルでは、事前共有キーまたはユーザ名/パスワードが必要です。また、Web ベースではないプロトコルもあり、Web ベースのゲートウェイを介してプロキシできるとは限りません。何年も前にリリースされたアプリケーションは、SAML、OIDC などのフェデレーションプロトコルに対応できていない可能性があります。現在または将来、環境に追加されるアプリケーションやユースケースがパスワードレスに対応していない可能性もあります。それでも大丈夫です。アプリケーションからパスワードを削除できれば、セキュリティ上のメリットがあります。
ユーザからパスワードを削除できれば、フィッシングやクレデンシャルの再利用が発生する可能性がその分減ることになります。ただし、ユーザからパスワードを完全に削除することは、アプリケーションからパスワードを完全に削除するよりもはるかに困難です。ユーザからパスワードを削除すれば、オーセンティケータデバイスを紛失してもパスワード方式には戻れません。そのため、各ユーザが複数のオーセンティケータデバイスを登録し、アカウントからロックアウトされないようにすることが重要になります。パスワードが削除されると、ユーザはパスワードレス認証を使用して新しいデバイスを登録する必要があります。
オーセンティケータ管理に関する考慮事項
Touch ID や Windows Hello などのプラットフォーム オーセンティケータは、アクセスデバイスに導入されているので便利ですが、特定のプラットフォームでの使用に限定されます。たとえば、プラットフォーム オーセンティケータを備えた新しいデバイスを登録する必要があるが、パスワードをもう使えないとします。その場合、プラットフォーム オーセンティケータを登録できるシステムにアクセスするために、新しいデバイスで信頼ステータスをブートするにはどうすればよいのでしょうか。
セキュリティキーやモバイルオーセンティケータなどのローミング オーセンティケータには、複数の機器で認証に使用できるというメリットがあります。プラットフォーム オーセンティケータを使用して、あるコンピュータにローミング オーセンティケータを登録し、その後、そのローミング オーセンティケータを別のコンピュータで使用すれば、そのコンピュータのプラットフォーム オーセンティケータを登録できます。
今後パスワードレス化が進むと、多くのデバイスが使用され、プラットフォーム オーセンティケータとローミング オーセンティケータの両方が混在することは明らかです。ただし、オーセンティケータの数が増えると、各オーセンティケータがサイトごとに独自のクレデンシャルを生成しなければならず、さらに複雑になります。複数の Web サイトそれぞれに複数のデバイスを登録するのは面倒です。フェデレーテッドログインを使用すれば、その手間を部分的に省き、限られたサイトにログインを一元化できます。複数のデバイスを登録することのプラス面は、ユーザがデバイスを紛失した場合や盗難にあった場合に、自分のアカウントへのアクセス権を失うことなく、デバイスを自分で修復できるという点です。
ただし、複数のオーセンティケータデバイスを紛失すれば、アカウントにアクセスできなくなるのは避けられません。そのような場合に、リカバリフローが必要になります。リカバリフローには、一時的なパスワード、リカバリリンク、バックアップコードなど、さまざまなものがあります。リカバリフローによって、認証の判断が別のプロバイダー（電子メールホストなど）に委任される場合があります。その場合、ユーザが自分の電子メールアカウントにアクセスできれば、自分で修復できます。アクセスできない場合は、ヘルプデスクに連絡してオーバーライドしてもらう必要があります。リカバリフローは、ローミング オーセンティケータを介さずに、プラットフォーム オーセンティケータ間で信頼ステータスをブートできるオプションでもあります。
複数のリカバリフローを用意することが重要ですが、リカバリフロー、特に自己修復フローは、攻撃ベクトルにもなりうることに注意してください。リカバリフローが最終的に強化されない場合、パスワードベースの認証を削除しても、セキュリティ態勢が実質的に強化されることになりません。
組織は、フェーズ 4 にはすぐに到達する可能性がありますが、フェーズ 5 でパスワードレスを最適化するには何年もかかります。時間をかけることで、パスワードレスの範囲が拡大し、新たなアプリケーションやユースケースがサポートされるようになります。そしていつか、パスワードが過去の遺物となります。
Duo を使用して組織をパスワードレス化する方法については、パスワードレス認証ソリューションの製品ページをご覧ください。
Authors