IDaaSで一歩進んだWebAuthn活用を～WebAuthnがおすすめな理由 #3～

Webアプリケーションにおける認証に、WebAuthnをおすすめする連載の第三回です。

最終回の今回は、WebAuthnを導入する際に考慮すべきことと、それらをまとめて解決できる手段についてご説明します。

WebAuthn導入時に考慮すべきこと

これまでの連載をご覧いただいた方の中で、提供中のサービスのプラットフォームがデフォルトの状態でWebAuthnをサポートしているのかと、開発ベンダーに確認したくなった方もいるのではないでしょうか。確認した結果、サポートしていれば一安心です。デフォルトではサポートしていないとの回答だとしても、WebAuthnのためのライブラリや、各種Webアプリケーション用フレームワークのプラグインなどもあるようなので、それらを利用することによりWebAuthnを提供中のサービスに組み込むことも不可能ではないと思います。

しかし、WebAuthnを導入する際に考慮しなくてはいけないことがあります。それは、WebAuthnによる認証ができなくなる場合があるということです。WebAuthnの登録時に、鍵ペアを作ることを第二回の連載で説明しました。秘密鍵などの情報が、ラップトップPCやスマートフォンの中に保存されるということです。ですので、例えばそのデバイスを買い替えたり、故障したりした場合、WebAuthnによる認証ができなくなります。もう一歩進んで「パスキー（Passkeys）」^※を使えばいいのではと考える方もいるでしょう。それも解決策の一つと言えます。そこまでいかなくても、逆光が強いシチュエーションで顔が認識されにくい、手指の乾燥やその時のコンディションで指紋が認識されにくいということはあります。

※ Passkeys：認証資格情報を複数の端末間で同期できる仕組みとして規格化されたもの

つまり、認証ができなくなった場合に備えて、補完的な認証手段をあらかじめ用意しておく必要があるということです。実はデモの動画でSMSを登録していたのはそのためです。補完的な手段はSMSと決まっているわけではありませんので、その点についてはご留意ください。なお、SMSはサービス提供者側にとっては通信料負担の課題があり、ユーザにとってはスミッシングの脅威という課題があります。そういう場合には、スマートフォンにインストールする認証アプリケーションも補完的手段になります。時間ベースのワンタイムパスワードが表示されるタイプや、認証が必要になったらサーバ側からプッシュして手元のアプリケーションで承認すると認証が完了するタイプなどがあります。これまでの連載で説明した突破される可能性がある手段ではありますが、パスワードだけの認証よりはるかに安全です。

とはいえ、様々なタイプのMFAに対応するのは煩雑です。加えて、提供しているサービスは一つだけではないかもしれません。そのすべてのサービスでWebAuthn、その他のMFAに個別で対応し運用を継続するのは、コストを考えると全然ハッピーではないですね。セキュリティのため、ということで投資できるのであればもちろん問題ありませんが、それらをサービスのライフサイクル全般にわたって保守し続けるとなると、そうやすやすとは受け入れられないかもしれません。サービスそのものの機能強化に加え、コンプライアンス対応、脆弱性対応、各種ソフトのバージョンアップ対応など、その他の課題も多数ある中ではなおさらです。

IDaaSにできること

これらの課題を解決するために、IDaaS^※が有効です。理由として2点挙げられます。

※ Identity as a Service：複数のサービスのIDやパスワードなどをクラウド上で一元的に管理する認証基盤

セキュリティ対策レベルを向上することができる

IDaaSをおすすめしたいポイントとしては、複数のMFAを使えるのはもちろんのこと、MFA以外のセキュリティ対策もセットになっていることです。

例えば、Okta Customer Identity Cloud（旧Auth0）では以下のタイプのMFAが利用可能です。（2023年2月現在）

1. Push notifications：Auth0 Guardian（スマホアプリ）にプッシュするタイプ
2. SMS notifications：ワンタイムパスワードをSMSで送信するタイプ
3. Voice notifications：ワンタイムパスワードを電話してくれるタイプ
4. One-Time passwords：Google AuthenticatorやMicrosoft Authenticatorなどのワンタイムパスワードを使うタイプ
5. WebAuthn with security keys：YubikeyやGoogle Titanなどのセキュリティキーを使うタイプ
6. WebAuthn with device biometrics：一連の記事で説明したもの
7. Email notifications：ワンタイムパスワードをEメールで送信するタイプ
8. Cisco Duo security：Ciscoが提供するサービスを利用するタイプ
9. Recovery codes：MFAを登録したデバイスが利用できない時の代替としてのコードを利用するタイプ

また、次のようなセキュリティ機能も利用可能です。

1. Bot Detection：ボットの利用が疑われるIPアドレスからのアクセスの場合、CAPTCHAを表示する
2. Suspicious IP Throttling：短時間に一か所から多数のユーザ／パスワードの組み合わせによるアクセスの場合にブロックする
3. Brute Force Protection：一定の時間内に特定のユーザに対するログインを試みるようなアクセスの場合に対象のユーザをロックアウトする。対象ユーザにメールを送信し、ユーザ自身でロックアウトを解除することも可能。
4. Breached Password Detection：漏洩したパスワードが使用された場合に対象のユーザをロックアウトする。対象ユーザにメールを送信し、パスワードの変更を促すことも可能。

これらをすべて独自に実装するのは現実的ではありませんが、IDaaS製品を提供する認証の専業メーカが継続的に改善・強化してくれるのは心強いですね。

このようにしてセキュリティ対策をセットで買ってしまうことにより、認証周りのセキュリティにまつわるエンドレスのいたちごっこをIDaaSに任せることが可能になり、それによって利用可能になったリソースをサービス本来の機能強化や新機能の開発に集中できます。これも大きなメリットではないでしょうか。

柔軟な運用が可能

IDaaS導入後、管理画面を操作するだけで、利用できるMFAの種類を増やすことも可能です。例えば、導入当初は一般的でなじみがあるSMSだけ利用できるようにしておいて、後からWebAuthnを利用可能にするなどです。また、連載第一回の動画を見ていただいた方はお気づきかもしれませんが、パスワードレスも既に実現できています。動画のリンクを掲載しておきますので、まだご覧になっていない方はぜひ確認してみてください。

デモ用のアプリケーションにWebAuthnを使ってログインする動画（ラップトップPC編）

デモ用のアプリケーションにWebAuthnを使ってログインする動画（スマートフォン編）

とても簡単な操作ですよね。メールアドレスを入力した後、生体認証だけでログインが完了します。このようなパスワードレス機能も、管理画面で設定を変更するだけで使えるようになります。

さらに、守りの面だけではありません。IDaaSを導入することにより、これまでばらばらのサービスごとに分散していたお客様データを統合管理することが可能になります。このことにより、お客様のサービス利用履歴などをマーケティングやデータ分析に活用することも可能です。そのあたりについては、下記の記事をご参照ください。

さいごに

さて、ここでこれまでの連載のおさらいです。

WebAuthnをおすすめするポイント

• 操作がとても簡単
• 管理対象が増えない
• フィッシング対策がされたセキュリティ

WebAuthn導入の課題解決に、IDaaSをおすすめするポイント

• 複数のMFAを使えるのはもちろん、その他のセキュリティ対策もカバーできる
  →本来のサービスの機能強化、新機能の開発などにリソースを振り向けられる
• 運用途中で簡単にMFAの種類を増やすなど、柔軟な運用もできる
  →統合管理したデータを使って攻めのマーケティングに取り組める

WebAuthn、IDaaSの魅力が伝わりましたでしょうか？
もし興味を持っていただけたら、ぜひラックへお問い合わせください。今回の記事が、サービスを提供する皆さまのお役に立てると幸いです。