Google・Appleのパスキー導入に始まり、個人向けの証券・銀行口座などでも、パスキーによるセキュリティ強化の波が進んでいます。
パスキーは、FIDOアライアンスなどの業界団体が推進する技術に基づき、覚える必要がない「暗号の鍵」をデバイス内に安全に保存する仕組みです。
ただ、あまりこういった説明を見かけませんが、基本的にパスキーは、利用するデバイス上で本人確認を行い、そのデバイスからパスキーを使ってサービスへ認証する仕組みです。
そのため、誰がどのデバイスでパスキーを利用できるようにするのか、つまり「信頼できるデバイス」に正しくパスキーを登録することが重要になります。
しかし、使っていくと、機器の購入や機種変更、故障・紛失など、デバイスを変更する機会は必ず発生します。
新しいデバイスでパスキーを利用できるようにするためには、事前に何らかの方法でユーザー（本人）確認を行い、そのデバイスからサービスへアクセスできる状態にする必要があります。
こうした新しいデバイスを登録する際の本人確認や、アカウント回復まで含めた運用全体がFIDOによって標準化されているわけではなく、サービスごとに異なる開発・運用仕様となります。
そうなると、パスキーの仕組み自体は完成度が高いものなので、フィッシング詐欺などが次に狙うのは、パスキーを不正なデバイスで利用できるように誘導することや、パスキーを登録するために用意された別の認証方法を突破することです。ここが新たな攻防ラインになります。
「パスキーは安全です」とパスキーの利用を勧めるサービスの中で、パスキーの仕組みだけでなく、運用する上での注意事項まで説明しているところは、まだ多くありません。
サーバー側でパスワードを管理するという、システム側が持つリスクを減らしてくれるのは良いことですが、その後に利用者側へ回ってくる運用リスクについては、フォローが足りないのが現状です。
パスキーは認証の標準化ですが、運用の標準化ではありません。
その運用設計はサービスごとに異なり、それらを利用者側がサービスごとに理解・運用していくことは負担となります。
パスキーの普及は、言わば、クラウドサービスで定着した、
「Anytime, Anywhere, Any Device」
を、
「Anytime, Anywhere, My Device」（個人向け）
もしくは、
「Anytime, Anywhere, Trusted Device」（企業向け）
に変えていく作業です。
そこで発生する運用リスクをきちんと考慮しないと、導入後に「こんなはずではなかった」と詰まる原因になります。
パスキーはパスワード方式を置き換える強力な認証技術であり、フィッシング耐性の向上という大きなメリットがあります。
しかし、現実の運用では、
・新しい端末をどう信頼するのか
・紛失・故障時にどう復旧するのか
・アカウント回復を誰が承認するのか
・パスキーの設定が必要なサービスが増えてきたら、どう管理するのか
といった課題が残ります。
セキュリティの安全性は、パスキーという認証方式そのものだけではなく、その前後に存在する「端末登録」と「アカウント回復」の運用設計と、それをいかに標準化・共通化していくかにあります。
パスキー時代の本当のテーマは、「パスワードをなくすこと」ではなく、「信頼できるデバイスと認証基盤をどう管理するか」、そして、それをいかにわかりやすく定着させるのか、なのかもしれません。
最近は、パスワードマネージャーなどによるクラウド同期パスキーを利用して複数の端末でパスキーを管理したり、企業であればSSOを導入したりすることで、サービスごとに異なる端末登録やアカウント回復の方法を集約しようという流れがあります。
それによるコンセプトの変化や利点・弊害もあるわけですが、そこまで話を広げると一気に複雑になります。
まずは、パスキーの基本形とデバイス管理の問題について、ここまで。
クラウド同期パスキーやSSOによって、この考え方がどう変わるのかについては、また別の記事で掘り下げてみたいと思います。