完全なパスワードレスを実現する方法

パスキーの実装は、認証セキュリティにおける記念碑的な飛躍ですが、それで旅が終わるわけではありません。すでにパスキーを導入している場合、セキュリティ指標の改善を実感しているかもしれませんが、実際にパスキーを導入した状態から、完全なパスワードレス認証へと移行するにはどうすればよいのでしょうか？

パスキーは、特定のドメインに紐付けられた公開鍵暗号方式を用いた**フィッシング耐性のある設計**により、攻撃者がユーザーを騙して不正なサイトで認証させることが不可能になるという、重要なセキュリティ上の利点を提供します。各パスキーは特定のサービスに対して一意であるため、認証情報の再利用を排除し、あるサービスが侵害されても他のサービスに影響が及ぶことはありません。さらに、記憶に頼る秘密情報を、推測や解読が不可能な暗号鍵に置き換えることで、ブルートフォース攻撃に対する耐性も備えています。

しかし、ユーザーがパスキー認証を迂回してパスワードでログインできる限り、これらの強力な利点は失われてしまいます。ここで重要な疑問が浮かび上がります。なぜパスキーだけでは完全なセキュリティに不十分なのでしょうか？ その答えは、パスワードという扉が開いている限り、攻撃者はそこを通り抜けようとするという点を理解することにあります。さらに重要なのは、**アカウントリカバリーが、パスキー実装全体を台無しにしかねない隠れた脆弱性となるのはなぜか？**という問いです。最近の注目を集めた侵害事例では、攻撃者がプライマリ認証ではなく、リカバリーフローを標的にするケースが増えています。

この記事では、パスキーの実装から真のパスワードレスセキュリティを実現するまでの完全な道のりを、これらの重要な問いに実践的な解決策と実例を交えながら解説します。

**真のパスワードレス認証とは、セキュリティアーキテクチャからパスワードを完全に排除することです。**パスワードレスシステムでは、ユーザーは認証のどの段階においても、パスワードの設定、リセット、使用ができません。代わりに、認証は完全にパスキーのような暗号化方式に依存します。

多くの組織は、フォールバックオプションとしてバックグラウンドでパスワードを維持しながらも、「パスワードレス」であると主張しています。これは真のパスワードレスではなく、単にパスワードが任意であるにすぎません。この違いは重要です。なぜなら、リカバリーフローを含め、システム内のどこかにパスワードが存在する限り、それらは攻撃者が標的とする悪用可能な脆弱性として残り続けるからです。

真のパスワードレスセキュリティを実現するには、プライマリ認証からパスワードを排除するだけでなく、リカバリープロセスも同様にフィッシング耐性を持つようにする必要があります。

フォールバックオプションとしてパスワードを維持することは、パスキーが排除しようとしているすべての攻撃ベクトルを温存することになります。攻撃者はフィッシングキャンペーンの標的をパスワード入力に切り替えるだけで済み、他の侵害で盗まれた認証情報を使ったクレデンシャルスタッフィングやパスワードスプレー攻撃も依然として有効です。また、ユーザーを騙して偽のサポート担当者にパスワードを教えさせるソーシャルエンジニアリングも効果を発揮し続けます。

パスワードが存在する限り、それは最も弱い環であり続け、パスキーのフィッシング耐性のあるセキュリティを完全に迂回する単一の侵入点となります。

ログイン体験だけを見るのも不十分です。重要でありながら見過ごされがちな攻撃ベクトルが、アカウントリカバリーフローです。パスキーを実装している組織でさえ、リカバリープロセスがSMS OTPやメールのマジックリンクといったフィッシング可能な方法に依存している場合、脆弱なままとなります。

2023年に注目を集めたMGMリゾーツの侵害事件を考えてみましょう。この事件では、攻撃者はプライマリ認証システムを標的にするのではなく、ソーシャルエンジニアリングを通じてアカウントリカバリープロセスを悪用し、すべての主要なセキュリティ対策を迂回しました。同様に、Oktaのサポートシステム侵害事件は、リカバリーフローが最も弱い環となり、攻撃者が認証情報をリセットして顧客環境への不正アクセスを可能にしてしまうことを示しました。

これらの事件は、重要な真実を浮き彫りにしています。リカバリーフローを確保せずにパスキーを実装するのは、頑丈な鋼鉄のドアを設置しながら窓を開けっ放しにするようなものです。

真のパスワードレス認証の達成は、単一のステップではありません。慎重な計画、段階的な実装、そして継続的な最適化を必要とする戦略的な道のりです。

最初のフェーズでは、既存の選択肢をフォールバックとして維持しつつ、追加の認証方法としてパスキーを導入することに焦点を当てます。この基盤構築の段階では、ユーザーが新しい技術を理解し信頼するための時間を与え、同時に使い慣れた方法を利用可能にしておくことで、摩擦を減らします。

主な実装ステップ：

• 既存の認証フローにパスキー認証を統合する
• 新規および既存ユーザーのパスキー作成を有効にする
• パスワードやその他の認証方法を代替手段として維持する
• パスキー作成率と利用パターンを追跡する

成功の指標：

• 少なくとも1つのパスキーを作成したユーザーの割合が50%を超える
• パスキー作成の成功率が95%を超える
• 認証における初期のパスキー利用率が20～30%に達する

パスキーが利用可能になったら、次は導入を促進し、パスキーを優先的な認証方法にすることに焦点を移します。このフェーズでは、戦略的なユーザーエンゲージメントと最適化を通じて、パスキーを代替オプションから主要な認証選択肢へと変えていきます。

主な実装ステップ：

• ログインフローでパスキー認証をデフォルトの選択肢にする
• パスワードでのログイン成功後にパスキー作成を促すインテリジェントなプロンプトを実装する
• アプリ内メッセージングを通じて、セキュリティと利便性のメリットについてユーザーを教育する
• パスキー導入のためのインセンティブ（より速いチェックアウト、限定機能など）を提供する
• コンバージョンを最大化するために、異なるメッセージングやUIアプローチでA/Bテストを実施する
• 機密性の高い操作にはパスキーを要求する条件付きアクセスポリシーを実装する

成功の指標：

• アクティブユーザーの60%以上が少なくとも1つのパスキーを所有
• パスキー対応アカウントのログインの80%以上がパスキーを使用
• パスキー作成の失敗率が2%未満

ここが真のセキュリティ変革が起こる場所です。**一貫してパスキーを使用するユーザーに対して、パスワードを完全に削除します。**このフェーズでは、パスキー導入に成功したユーザーのパスワードを無効化することで、主要な攻撃ベクトルを排除します。

主な実装ステップ：

• インテリジェントな監視システムを使用してユーザーの認証パターンを分析する
• パスキーのみを使用し、複数のパスキー対応デバイスを持つユーザーを特定する
• 明確なセキュリティ上のメリットを伝えて、パスワードの無効化を提案する
• バックアップパスキーの可用性（クラウド同期または複数デバイス）を確認する

成功の指標：

• 対象ユーザーの30%以上が自発的にパスワードを削除
• アカウントロックアウト率の増加がゼロ
• ユーザー満足度スコアを維持または向上

最終フェーズでは、最後の脆弱性に対処します。それはアカウントリカバリーをフィッシング耐性のあるプロセスへと変革することです。このフェーズでは、リカバリーフローがプライマリ認証と同等のセキュリティレベルを持つようにし、バックドア攻撃を防ぎます。

主な実装ステップ：

• 少なくとも1つのフィッシング耐性のある要素を含む多要素認証を実装する
• 利用可能なフィッシング耐性のある要素：
  • バックアップパスキー：セカンダリデバイスやクラウドサービスに保存されたリカバリー用パスキー。暗号学的に本人性を証明します（最も広く利用可能な選択肢）。
  • Digital Credentials API：信頼できるプロバイダーからの暗号学的に検証された本人アサーションのためのW3C標準（新興技術であり、まだ普及していません）。
  • ハードウェアセキュリティキー：リカバリー要素として登録された物理的なFIDO2トークン。フィッシングや複製が不可能です（ユーザーは物理デバイスを購入・管理する必要があります）。
  • ライブネス検知付きの本人確認書類検証：政府発行のIDスキャンとリアルタイムの生体認証アクションを組み合わせ、物理的な存在を証明します。

リカバリーオプションに関する注意点：Digital Credentials APIやハードウェアセキュリティキーは強力なセキュリティを提供しますが、まだ広く採用されていません。前者はまだ新興技術であり、後者はユーザーが物理デバイスを購入する必要があります。

バックアップパスキーが利用できない場合、ライブネス検知付きの本人確認書類検証が有効な代替手段となります。IDの物理的な所有なしにライブネスチェックを回避する回避策の可能性はありますが、これらの方法は、フィッシング、SIMスワッピング、中間者攻撃によって容易に傍受される可能性のある従来のOTPよりも、はるかに強力なセキュリティを提供します。

成功の指標：

• リカバリーフローの100%にフィッシング耐性のある要素が含まれる
• リカバリープロセスを通じたアカウント乗っ取りの成功事例がゼロ
• リカバリー完了率が90%以上を維持

パスワードレスの動きはテクノロジー業界全体で勢いを増しており、主要企業がパスワードからの脱却を進めています。

いくつかの企業は、すでに社内業務において完全なパスワード廃止を達成しています。Okta、Yubico、Cloudflareは、社内でのパスワード使用を事実上ゼロにしており、彼らのログインフローではパスワードを一切受け付けません。

テクノロジー大手のGoogle、Apple、Microsoft、Xは、積極的にパスワードの廃止を進めていますが、まだ完全には排除していません。彼らのアプローチは、移行期間中、セキュリティ向上とユーザーの選択の自由とのバランスを取るものです。

Googleは、すべてのアカウントで「可能な場合はパスワードをスキップ」をデフォルトでオンにするという積極的な姿勢を取り、パスキーを優先的な認証方法としつつ、必要であればユーザーがオプトアウトできるようにしています。このオプトアウト方式は、パスワードレスへの強力な勢いを生み出しながら、まだ移行の準備ができていないユーザーに柔軟性を提供します。

Microsoftはさらに一歩進んで、ユーザーが今日から自分のアカウントからパスワードを完全に削除できるようにしており、将来的には「最終的にパスワードのサポートを完全に削除する」計画です。この明確なロードマップは、パスワードが終わりを迎えることをユーザーに示唆し、パスワードレス方式の早期導入を促します。

Appleは、自社のエコシステム全体にパスキーを統合し、その使用を積極的に推進していますが、Apple IDのパスワードはフォールバックオプションとして依然として利用可能です。彼らのアプローチは、Appleデバイス間でのシームレスな同期を活用し、パスキー導入をできるだけ摩擦なく進めるものです。

これらの企業は、即時の変更を強制しているわけではありませんが、導入がクリティカルマスに達すればパスワードはなくなるという明確なメッセージを送っています。彼らの戦略には、パスキーをデフォルトにし、メリットについてユーザーを教育し、徐々にパスワードの機能を減らしていくことが含まれています。

パスワードを廃止する決定は、急いだり一律に適用したりすべきではありません。代わりに、ユーザーの行動、デバイスの能力、リスクプロファイルを考慮したデータに基づいた段階的なアプローチを採用すべきです。

今日、深刻なフィッシング攻撃に直面している高リスクセクターは、直ちにパスワードレスへの移行を開始すべきですが、それでも段階的かつ戦略的な展開に従う必要があります。

• 銀行・金融機関： 認証情報窃盗の主要な標的です。欧州の銀行にとって、パスキーはPSD2の強力な顧客認証（SCA）要件とも整合し、規制遵守を満たしながらユーザーエクスペリエンスを向上させるフィッシング耐性のあるMFAを提供します。
• 決済プロバイダー・フィンテック： 顧客の資金に直接アクセスできるため、組織的なサイバー犯罪にとって魅力的です。
• 暗号通貨取引所： 取引が不可逆であるため、認証情報が盗まれると永久的な損失につながります。
• ヘルスケア・保険： 医療IDの盗難によるコンプライアンス要件と患者の安全リスクの両方に直面しています。
• 政府・重要インフラ： 高度なスピアフィッシングキャンペーンを行う国家主体に狙われています。

**これらの組織にとって、即時の行動は不可欠ですが、成功には依然として体系的で段階的な展開アプローチが必要です。**今日から始め、ただし戦略的に展開して、高い導入率を確保し、ユーザーのロックアウトを避けるようにしましょう。

小規模なサブグループから始める： 一貫してパスキーを使用しているユーザーからパスワードレスへの移行を開始します。これらの早期導入者は、より広範な展開の前に潜在的な問題を特定するのに役立ちます。

ユーザーの行動パターンを分析する：

• ログイン頻度と使用された方法
• デバイスの種類とパスキーの互換性
• 認証試行の失敗
• リカバリーフローの使用状況
• クロスデバイス認証パターン

これらのパターンに基づいてパスワード無効化の対象となるユーザー：

• 一貫してパスキーで認証している - この技術に慣れていることを示します。
• 複数のデバイスでパスキーを使用している - バックアップのアクセス方法があることを示します。
• 過去30～60日間にパスワードやリカバリーフローを使用していない - パスワードベースの認証に依存していないことを示します。

Corbadoは、上記で説明したパスワードレスへの道のりの4つのフェーズすべてを通じて組織を導くための包括的なプラットフォームを提供します。最初のパスキー実装から完全なパスワード廃止の達成まで、Corbadoのソリューションは技術的な複雑さを処理し、ユーザー導入を成功させるために必要なツールを提供します。

フェーズ1および2のサポート： Corbadoは、既存の認証スタックとのシームレスなパスキー統合、導入率を最大化するインテリジェントなプロンプト、パスキー作成と利用パターンを追跡するための詳細な分析を提供します。プラットフォームのPasskey Intelligence機能は、デバイスの能力とユーザーの行動に基づいてユーザーエクスペリエンスを自動的に最適化し、スムーズなオンボーディングを保証します。

フェーズ3および4の実装： パスワードを完全に廃止する準備ができた組織のために、Corbadoは、安全でフィッシング耐性のあるリカバリーフローを維持しながら、ユーザーの準備状況に基づいて段階的なパスワード無効化を可能にします。

クロスプラットフォームの互換性、フォールバックメカニズム、ユーザーエクスペリエンスの最適化を処理することで、Corbadoはパスワードレスへの変革を数年から数ヶ月に短縮し、組織がフィッシング耐性のある認証を達成しながらコアビジネスに集中できるようにします。

真のパスワードレス認証への道のりは、冒頭で提起した2つの重要な問いに答えるものです。

なぜパスキーだけでは完全なセキュリティに不十分なのでしょうか？ なぜなら、セキュリティは最も弱い環と同じ強度しかないからです。パスワードがフォールバックとしてでも利用可能な限り、攻撃者はフィッシング、クレデンシャルスタッフィング、またはダウングレード攻撃を通じてそれらを標的にするだけです。システム内のすべてのパスワードが、パスキーのフィッシング耐性の利点を損ないます。

アカウントリカバリーが隠れた脆弱性となるのはなぜですか？ リカバリーフローは、忘れられがちなバックドアです。MGMリゾーツやOktaの侵害事件が示したように、攻撃者はSMS OTPやメールのマジックリンクのような脆弱なリカバリー方法を悪用することで、堅牢なパスキー実装をますます迂回しています。それは、鋼鉄のドアを設置しながら窓を開けっ放しにするようなものです。

真のパスワードレスセキュリティを実現するには、パスキーを実装し、導入を促進し、パスワードを完全に削除し、フィッシング耐性のある方法でリカバリーフローを保護するという、完全な道のりを完了する必要があります。リカバリープロセスに隠されたものを含め、すべてのパスワードの扉を閉じることによってのみ、組織は真に安全な認証を達成できるのです。