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

1. はじめに：なぜパスキーの実装がゴールではないのか#

パスキーの実装は認証セキュリティにおける画期的な飛躍を意味しますが、それが完全な道のりというわけではありません。すでにパスキーを展開しているなら、おそらくセキュリティ指標の向上を喜んでいることでしょう。しかし、パスキーを導入している状態から、真に完全なパスワードレス認証を達成するには、実際にどのように移行すればよいのでしょうか？

パスキーは、特定のドメインに紐づいた公開鍵暗号を使用するフィッシング耐性のある設計を通じて、重要なセキュリティ上の利点を提供します。これにより、攻撃者がユーザーを騙して不正なサイトで認証させることを不可能にします。また、各パスキーは特定のサービスに対して固有であるため、認証情報の使い回しを排除し、あるサービスでの漏洩が他のサービスに影響を与えません。さらに、記憶に基づく秘密情報を推測や解読が不可能な暗号鍵に置き換えることで、ブルートフォース攻撃に対する免疫を提供します。

しかし、ユーザーがパスキー認証を回避してパスワードでログインできるようになった瞬間に、これらの強力な利点は消え去ります。ここで重要な疑問が浮かびます。なぜパスキーだけでは完全なセキュリティとして不十分なのでしょうか？ その答えは、パスワードというドアが開いている限り、攻撃者がそこを通ろうとすることを理解する点にあります。さらに重要な疑問は、アカウントリカバリーが、パスキーの実装全体を損なう可能性のある隠れた脆弱性になるのはなぜか？ ということです。最近の注目を集めたデータ侵害は、攻撃者がプライマリ認証ではなく、リカバリーフローを標的にする傾向が強まっていることを示しています。

この記事では、パスキーの実装から真のパスワードレスセキュリティの達成に至るまでの完全な道のりをご案内し、これらの重要な疑問のそれぞれに実践的なソリューションと現実世界の事例を交えてお答えします。

「パスワードレス」の本当の意味とは？#

真のパスワードレス認証とは、セキュリティアーキテクチャからパスワードを完全に排除することを意味します。 パスワードレスシステムでは、ユーザーは認証プロセスのどの時点でもパスワードを設定、リセット、または使用することができません。代わりに、認証は完全にパスキーのような暗号化手法に依存します。

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

2. パスキーのセキュリティを損なう2つのバックドア#

真のパスワードレスセキュリティには、プライマリ認証からのパスワードの排除と、リカバリープロセスが同様にフィッシング耐性を持つことの確保の両方が必要です。

2.1 フォールバック選択肢としてのパスワードが重大なセキュリティリスクをもたらす理由#

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

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

2.2 アカウントリカバリーのバックドア#

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

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

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

3. パスワードレスへの道のり#

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

3.1 フェーズ 1: パスキーの追加#

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

主な実装ステップ:

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

成功の指標:

• 少なくとも1つのパスキーを作成したユーザーの割合が50%以上
• パスキー作成の成功率が95%以上
• 認証のための初期のパスキー利用率が20〜30%に到達

3.2 フェーズ 2: パスキーの普及を促進する#

パスキーが利用可能になったら、焦点は普及を促進し、パスキーを推奨される認証方法にすることに移ります。このフェーズでは、戦略的なユーザーエンゲージメントと最適化を通じて、パスキーを代替の選択肢から主要な認証の選択肢へと変革します。

主な実装ステップ:

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

成功の指標:

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

3.3 フェーズ 3: パスワードレスへの移行#

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

主な実装ステップ:

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

成功の指標:

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

3.4 フェーズ 4: フィッシング耐性のあるリカバリー#

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

主な実装ステップ:

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

リカバリーの選択肢に関する注意: Digital Credentials APIとハードウェアセキュリティキーは強力なセキュリティを提供しますが、まだ広く普及しているわけではありません。前者は依然として新しい技術であり、後者はユーザーが物理デバイスを購入する必要があります。

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

成功の指標:

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

4. パスワードの削除を開始した企業の事例#

テクノロジー業界全体でパスワードレスの動きが勢いを増しており、主要な企業がパスワードから離れつつあります。

4.1 完全にパスワードレスな組織#

一部の企業は、社内運用においてすでにパスワードの完全な排除を達成しています。Okta、Yubico、Cloudflareは社内で事実上パスワードの利用ゼロに到達しており、そのログインフローではパスワードを一切受け付けません。

4.2 移行を積極的に進めている企業#

テクノロジー大手のGoogle、Apple、Microsoft、Xは積極的にパスワードの非推奨化を進めていますが、完全には排除していません。これらの企業のアプローチは、移行期間中におけるセキュリティの向上とユーザーの選択のバランスを取っています。

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

Microsoftはさらに一歩進んでおり、将来的に「最終的にパスワードのサポートを完全に削除する」という計画とともに、現在ユーザーがアカウントからパスワードを完全に削除できるようにしています。この明確なロードマップは、パスワードの寿命が近づいていることをユーザーに示し、パスワードレス手法の早期導入を促しています。

Appleはエコシステム全体にパスキーを統合し、その利用を積極的に推進していますが、Apple IDのパスワードはフォールバックの選択肢として利用可能です。同社のアプローチは、Appleデバイス間のシームレスな同期を活用し、パスキーの導入を可能な限り摩擦のないものにしています。

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

5. いつパスワードの削除を開始すべきか？#

パスワードを削除する決定は、急いで行うべきでも、一律に適用すべきでもありません。代わりに、ユーザーの行動、デバイスの機能、リスクプロファイルを考慮したデータ駆動型かつ段階的なアプローチを採用してください。

5.1 すぐにパスワードレスへの道のりを開始すべき対象#

現在深刻なフィッシング攻撃を経験しているハイリスクな分野は、すぐにパスワードレスへの移行を開始すべきですが、それでも段階的かつ戦略的なロールアウトに従う必要があります:

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

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

5.2 段階的なロールアウト戦略#

小規模なサブグループから始める: 一貫したパスキーの利用を示しているユーザーからパスワードレスへの移行を開始します。これらのアーリーアダプターは、広範な展開の前に潜在的な問題を特定するのに役立ちます。

ユーザーの行動パターンの分析:

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

これらのパターンに基づくパスワード無効化の対象ユーザー:

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

6. Corbadoの支援方法#

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

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

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

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

おわりに#

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

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

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

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

Corbadoについて

Corbadoは、大規模なconsumer認証を運用するCIAMチームのためのPasskey Intelligence Platformです。IDPのログや一般的なanalyticsツールでは見えないものを可視化します。どのデバイス、OSバージョン、ブラウザ、credential managerがpasskeyに対応しているか、なぜ登録がログインにつながらないのか、WebAuthnフローのどこで失敗するか、OSやブラウザのアップデートがいつ静かにログインを壊すか — Okta、Auth0、Ping、Cognito、あるいは自社IDPを置き換えることなく、すべてを把握できます。2つのプロダクト：Corbado Observeは passkeyとその他あらゆるログイン方式のobservabilityを提供します。Corbado Connectは analytics内蔵のmanaged passkeyを追加します（既存のIDPと併用）。VicRoadsはCorbadoで500万人超のユーザーにpasskeyを提供しています（passkey有効化率+80%）。 Passkeyエキスパートに相談する →

よくある質問#

パスワードレスの導入において、ユーザーがパスワード無効化の対象となる条件は何ですか？#

ユーザーが複数のデバイスで一貫してパスキーを通じて認証しており、過去30〜60日間パスワードやリカバリーフローを使用していない場合、パスワード無効化の対象となります。このコホートから無効化を開始することで、リスクを軽減し、広範な展開の前に問題を表面化させることができます。フェーズ3では、対象ユーザーの30%以上が自発的にパスワードを削除することを目指します。

バックアップパスキーが利用できない場合、アカウントリカバリーのためのフィッシング耐性のある選択肢は何ですか？#

4つのフィッシング耐性のあるリカバリーファクターが存在します。サブデバイス上のバックアップパスキー、ハードウェアセキュリティキー（物理的なFIDO2トークン）、Digital Credentials API（W3C標準であり現在普及中）、およびライブネス検知を伴う身分証明書確認です。従来のSMS OTPやメールマジックリンクは、フィッシング、SIMスワップ、中間者攻撃に対して脆弱であり、安全なリカバリーフローとしては不十分です。

なぜMGMリゾーツのデータ侵害は、堅牢なプライマリ認証が導入されていたにもかかわらず成功したのですか？#

2023年のMGMリゾーツの侵害は、プライマリログインシステムではなく、ソーシャルエンジニアリングを通じてアカウントリカバリープロセスを標的とすることで、すべてのプライマリセキュリティ対策を完全に回避しました。これは、リカバリーフローを保護せずにパスキーを実装することが、鋼鉄のドアを設置しながら窓を開けっ放しにするのと同じように、重大なバックドアを開いたままにすることを示しています。

パスキーをオプションとする段階からパスワードを完全に削除する段階に進む前に、チームはどのような導入指標を達成すべきですか？#

フェーズ3に入る前に、チームはアクティブユーザーの60%以上が少なくとも1つのパスキーを持っていること、パスキー対応アカウントでのログインの80%以上がパスキーを使用していること、そしてパスキー作成の失敗率が2%未満であることを達成すべきです。フェーズ3の成功は、対象ユーザーの30%以上が自発的にパスワードを削除し、アカウントロックアウト率が一切増加しないことで測定されます。