パスキーとは？現代の認証の基礎

パスキーとは？

攻撃者が従業員のパスワードをフィッシングで盗み、SMSによる二要素認証を回避して、ネットワーク内を横方向に移動します。Verizon DBIRによると、認証情報を利用した攻撃パターンによる侵害の88%に盗まれた認証情報が関与し、ソーシャルエンジニアリング事案の57%でフィッシングが使われていました。

パスキーは、この攻撃経路そのものを断ちます。秘密鍵がユーザーのデバイスから離れない、暗号技術を用いたパスワードレス認証により、認証情報の窃取は事実上不可能になります。

パスキーは公開鍵暗号方式を使用します。デバイスは固有の鍵ペアを生成します。秘密鍵はTrusted Platform ModuleやSecure Enclaveなど、デバイス内のハードウェアで保護された領域に保持され、公開鍵はサービスプロバイダーに渡されます。認証時には、サービスから送られたチャレンジにデバイスが秘密鍵で署名します。パスワードはネットワーク上を流れません。これにより、フィッシング、クレデンシャルスタッフィング、パスワードの使い回しを利用した攻撃を防ぎます。秘密鍵はデバイスから離れず、再利用可能な秘密情報も送信されないためです。

パスキーはFIDO2規格（WebAuthn + CTAP）に準拠し、プラットフォーム、ブラウザー、サービスをまたいで一貫したセキュリティを確保します。デバイスに紐づくパスキーは、最高水準の保証を得るため、秘密鍵をハードウェアセキュリティモジュールに保存します。同期型パスキーは鍵を暗号化し、プラットフォームのエコシステム間で同期することで、より幅広い環境で利用できます。

パスキーと従来のパスワードの違いを知れば、セキュリティ上の改善点が明確になります。

パスキーとサイバーセキュリティの関係

パスキーは暗号技術によってフィッシングを阻止します。攻撃者がユーザーを狙ってフィッシングを仕掛けても、WebAuthnプロトコルによるオリジンへの紐づけが、偽装ドメインでの認証を防ぎます。ユーザーがフィッシングリンクをクリックしてログインを試みても、正規ドメインとの暗号学的な紐づけによって認証は完了しません。

ハードウェアセキュリティモジュールに保存された秘密鍵は、ソフトウェアを使った攻撃では取り出せません。データベースが侵害されても再利用可能な認証情報は漏えいせず、パスキーはサービスごとに固有であるため、クレデンシャルスタッフィングも通用しません。

実際の事案は、この対策の重要性を示しています。2023年9月、MGM Resortsはソーシャルエンジニアリング攻撃を受けました。攻撃者は従業員を装ってITヘルプデスクに接触し、認証情報を入手しました。その結果、 ランサムウェアが展開され、推定 1億ドルの損失が生じました。2022年には、大手IDプロバイダーが、侵害された外部委託先を経由した認証情報の窃取に遭い、数百の顧客が影響を受けました。

パスキーで保護されたアカウントでは、認証情報の窃取を初期アクセスに利用できません。こうした侵害の多くに共通する攻撃経路を断ちます。この保護の強さは、複数の技術要素が連携することで生まれます。

パスキーとパスワードの違い

パスワードは共有する秘密情報です。ユーザーが作成し、サーバーに送信すると、サーバーはハッシュ化した値を保存します。この一連のどの段階も攻撃対象になります。ユーザーは弱いパスワードを選び、サービス間で使い回し、リアルタイムでパスワードを盗むフィッシングページに入力してしまいます。ハッシュ化されたパスワードのデータベースも侵害され、オフラインで解読される可能性があります。

パスキーは、あらゆる段階で仕組みが異なります。デバイスが暗号鍵ペアを生成し、秘密鍵はデバイスから離れません。サーバーが保存するのは公開鍵だけです。対応する秘密鍵がなければ、公開鍵は攻撃者の役に立ちません。認証には署名付きチャレンジを使用するため、再利用可能な情報はネットワーク上を流れません。

実務上の違いも大きくなります。パスワードでは、複雑な文字列を覚えて定期的に変更する必要があります。その負担が、使い回しや弱いパスワードの選択につながります。パスキーは生体認証またはデバイスのPINでロックを解除するだけで、記憶する必要がありません。企業全体のITヘルプデスクへの問い合わせのうち、パスワードのリセットは 20～50%を占めます。パスキーは、この問い合わせをなくします。

セキュリティの観点では、パスワードはフィッシング、ブルートフォース攻撃、クレデンシャルスタッフィング、データベース侵害に対して脆弱です。パスキーは、この4つすべてに耐性があります。

• フィッシング — ドメインへの紐づけにより、偽装サイトで認証情報を使用できません
• ブルートフォース攻撃とクレデンシャルスタッフィング — 推測したり再利用したりできるパスワードが存在しません
• データベース侵害 — サーバーに保存されるのは公開鍵だけで、秘密鍵がなければ役に立ちません
• 認証情報の使い回し — サービスごとに鍵が固有のため、1つのアカウントが侵害されても、ほかのアカウントにはアクセスできません

パスワードが単一の認証要素（知っているもの）に依存するのに対し、パスキーは2つの要素を組み合わせます。秘密鍵を保存したデバイス（持っているもの）と生体認証（本人の身体的特徴）です。これにより、多要素認証を1回の手順で実現します。

こうした違いは、パスキーが実際の攻撃に直面したとき、測定可能なセキュリティ上の成果に直結します。

パスキーを構成する主な要素

パスキー認証は、フィッシングに強い認証を実現する5つの技術要素に基づいています。

• 暗号鍵ペアが基盤です。各パスキーは、数学的に対応する公開鍵と秘密鍵で構成されます。公開鍵はサービスプロバイダーのサーバーに置かれ、秘密鍵はユーザーのデバイス内のハードウェアで保護された領域に保持されます。
• 認証器はパスキーを生成・保存します。プラットフォーム認証器は、TPM、Secure Enclave、Trusted Execution Environment（TEE）を介してデバイスに統合され、秘密鍵を特定のハードウェアに紐づけます。持ち運び可能な認証器には、USBセキュリティキーやBluetoothトークンがあります。どちらもCTAPとWebAuthnの仕様に準拠し、ドメインへの紐づけ、フィッシングへの耐性、秘密鍵を保持していることの暗号学的な証明を実現します。
• WebAuthn APIは、Webアプリケーションやブラウザーと認証器の連携を実現します。このW3C標準は登録と認証の実行方法を定義し、プラットフォームを問わず一貫した実装を確保します。
• リライングパーティとは、パスキー認証を実装するサービスです。チャレンジの生成、応答の検証、公開鍵レジストリの管理を担います。
• ユーザー検証では、生体認証、デバイスのPIN、またはパターンを通じて、正規のユーザーが認証器を操作していることを確認します。検証はデバイス上で行われ、生体認証データがデバイスの外に出ることはありません。

これらの要素は、登録と認証という2つの主要なプロセスで連携します。

パスキーの仕組み

どちらのプロセスも暗号学的なチャレンジレスポンスを使用し、認証情報の送信を不要にします。

登録プロセス

登録時、リライングパーティはユーザーのブラウザーに要件を送信し、ブラウザーがWebAuthnを呼び出します。認証器は、そのドメインに限定された固有の鍵ペアを生成します。このオリジンへの紐付けにより、認証情報の再利用とフィッシングを防ぎます。

秘密鍵はハードウェアで保護されたメモリに保存されます。デバイスに紐付く方式では、ハードウェアセキュリティモジュール、TPM、Secure Enclave、またはセキュリティキーのチップが使われます。同期方式では、エクスポートできない暗号化されたクラウドストレージに保存されます。認証器は公開鍵と認証情報のメタデータをリライングパーティに返します。登録は数秒で完了し、パスワードを作成せずにログインできるようになります。

認証プロセス

ユーザーが認証する際、リライングパーティはランダムなチャレンジを生成し、認証情報IDとともに送信します。生体認証、PINの入力、またはデバイスのロック解除によるユーザー検証後、認証器が秘密鍵でチャレンジに署名します。

署名されたチャレンジはリライングパーティに返され、検証されます。署名が一致すると認証が完了します。チャレンジは数分以内に失効し、再利用できません。

デバイスをまたぐ認証のシナリオ

同期型パスキーは、クラウドのキーチェーン（iCloud KeychainまたはGoogle Password Manager）で秘密鍵を暗号化し、同じエコシステム内の複数のデバイスからアクセスできるようにします。アクセスは便利ですが、アテステーションへの対応が限られるため、組織は使用中のセキュリティハードウェアを暗号学的に常に検証できるとは限りません。デバイスに紐づくパスキーは、ログインのたびに物理的な認証器を必要とします。完全なアテステーション機能により、組織は使用されたセキュリティキーの正確なモデルやハードウェアセキュリティモジュールを検証でき、より高い信頼性を確保できます。

企業が同期方式とデバイスに紐付く方式のどちらを選ぶかは、許容できるリスクによって決まります。特権管理者アカウントなど、高いセキュリティが求められる環境にはデバイスに紐付く方式が適しています。一方、利便性が導入を後押しする一般従業員の認証には、同期方式が適しています。

仕組みを踏まえ、次はパスキーが組織にもたらすメリットを見ていきます。

パスキーの主なメリット

パスキーは、セキュリティ、運用、コンプライアンスにわたり、パスワード認証と比べて測定可能な4つの改善をもたらします。

1. 暗号技術によるフィッシング耐性：SMSコードを併用するパスワード認証は、攻撃者が偽サイトを介してリクエストを中継するリアルタイムのフィッシングに脆弱です。パスキーはドメインへの紐付けによってこれを防ぎます。WebAuthn APIは認証前に接続先のドメインを検証し、ドメインが一致しなければ認証を失敗させます。SMSコード、プッシュ通知、TOTPも、中間者攻撃、SIMスワッピング、プッシュ通知疲れに脆弱です。暗号技術に基づく認証情報には、このような脆弱性はありません。
2. 認証情報の窃取防止： 秘密鍵はユーザーのデバイスから外に出ません。サーバーに保存されるのは公開鍵だけなので、サーバーが侵害されても再利用可能な認証情報は流出しません。情報窃取型マルウェアは、カーネルレベルのアクセス権があってもハードウェアセキュリティモジュールから鍵を抽出できません。パスキーは、攻撃者が多用する 認証情報の収集手法に対抗します。
3. 運用効率の向上：パスキーを導入すると、暗号技術に基づく認証情報をユーザーが忘れることはないため、パスワードのリセット依頼が減ります。たとえば、米国農務省のFIDO実装では、約40,000人のユーザーが パスワードレス認証を導入し、ヘルプデスクへの問い合わせを一種類なくしました。SentinelOneのSingularity Identityのようなアイデンティティセキュリティプラットフォームは、パスキーによる予防を補完し、認証基盤を狙う認証情報ベースの脅威に自律的に対応します。
4. コンプライアンスと保証レベルへの適合： パスキーは、フィッシング耐性のある多要素認証に関するNIST SP 800-63 AAL3の要件に適合します。CISAはFIDO/WebAuthnパスキーを MFAのゴールドスタンダードと位置付けています。ドメインに紐付く認証情報を使用するため、偽サイトでは利用できないからです。前述のとおり、認証情報が関わる侵害の大多数には盗まれた認証情報が使われます。パスキーはこの種の侵害を根本から防ぎます。

公開鍵暗号方式には、パスワードポリシーでは実現できない、監査可能なセキュリティ特性もあります。ドメイン固有の認証を示す暗号学的証明、ネットワーク上で共有する秘密情報がないこと、ハードウェアを信頼の起点とする鍵生成です。これらの特性は監査時に検証可能な証拠となり、SOC 2、HIPAA、PCI DSSなどのフレームワークに沿ったコンプライアンス文書の作成を簡素化します。

こうしたセキュリティと運用上のメリットを背景に、さまざまなプラットフォームや業界で導入が急速に進んでいます。

パスキーのプラットフォーム対応と業界での導入

Apple、 Google、 MicrosoftはいずれもOSとブラウザーでパスキーをネイティブにサポートしており、企業で使われる大半のデバイス環境をプラットフォームを問わずカバーできます：

• AppleはiCloudキーチェーンを通じて、iOS、iPadOS、macOSでパスキーを利用できます
• GoogleはGoogle パスワード マネージャーを通じて、AndroidとChromeでパスキーをサポートしています
• Microsoft Windows HelloとEntra IDによるパスキー認証に対応しています

プラットフォームベンダーに加え、主要な消費者向けサービスや企業向けサービスでもパスキーログインが採用されています。Amazon、PayPal、GitHub、Shopify、eBayは、顧客認証でパスキーに対応しています。FIDO Alliance Passkey Directoryでは、銀行、医療、政府機関における採用の拡大を追跡しています。FIDO Allianceによると、53%の人が少なくとも1つのアカウントでパスキーを有効にしています。

企業のセキュリティチームにとって、この採用拡大は、パスワードレス認証がもはや将来の検討事項ではないことを意味します。Microsoft Entra ID、Okta、Ping IdentityなどのIDプロバイダーはFIDO2/WebAuthnとのネイティブ統合に対応しており、今すぐ組織全体への導入を進められます。

ただし、対応プラットフォームが増えても、導入の複雑さが解消されるわけではありません。

パスキーの課題と制約

企業でのパスキー導入には、計画と投資を要する主な障壁が4つあります。

1. レガシーシステムとの統合に関する制約: 最新の認証サービスと連携できないレガシーアプリケーションが、導入の最大の障壁です。多くの組織はレガシーシステムの制約から、パスワードと暗号学的な認証情報を併用するハイブリッドシステムに依存しています。そのため、複数の認証基盤を同時に維持する運用上の複雑さが生じます。メインフレームアプリケーション、産業制御システム、組み込みデバイスには、WebAuthnプロトコルを実装するためのリソースが不足していることが少なくありません。パスワード認証のみを使う領域を維持するか、認証ゲートウェイに投資するか、特定のシステムをパスキーの適用対象外とするか、判断が必要です。こうしたギャップを早期に計画へ織り込めば、導入時のセキュリティ上の盲点を防げます。
2. プラットフォーム間での実装の不一致: WebAuthnで標準化されていても、実装はプラットフォームやブラウザーによって異なります。同期されたパスキーは、単一のプラットフォームエコシステム内でしか機能しません。iCloud Keychainで同期された秘密鍵は、Google Password Managerを使用するAndroidデバイスからは利用できず、その逆も同様です。こうした不一致により認証フローが予測しにくくなり、企業での導入が複雑になります。
3. アカウント復旧の複雑さ: デバイスの紛失やハードウェアの故障によってアカウントにアクセスできなくなるため、確実な復旧手段が必要です。アクセスを失うことへの不安は、導入を妨げる心理的な障壁にもなります。復旧を後回しにする組織では、サポートへの問い合わせが増え、採用率が下がります。そのため、計画段階から復旧手段の設計を重視する必要があります。
4. 組織の変更管理: セキュリティ上の利点を理解していなければ、ユーザーは慣れない認証フローに抵抗を感じることがあります。導入前に、サポート担当者にはトラブルシューティング、復旧手順、プラットフォーム固有の動作に関するトレーニングが必要です。パスキーを純粋な技術課題として扱うよりも、UX、開発、製品チームが連携するほうが、採用の障壁に効果的に対処できます。

こうした課題を理解することで、よくある導入ミスを避けられます。

パスキー導入時によくあるミス

パスキーの導入を入念に計画しても、ユーザー体験、エラー対応、代替認証の安全性を見落とすと失敗しかねません。特によく見られるのは、次の4つのミスです。

• 導入前のユーザー教育を省く: ユーザーの懸念に対処せずに導入を告知すると、混乱や抵抗を招きます。説明のないまま見慣れない認証画面に直面したユーザーの多くは、パスワードのリセットを依頼したり、サポートに問い合わせたりします。デバイス紛失時の対応と復旧手順を事前に説明し、iOS、Android、Windowsそれぞれの操作フローを示す必要があります。
• 汎用的なエラーメッセージを使う: 対処方法を示さずに「問題が発生しました」と表示する認証フローは、ユーザーの信頼を損ないます。「この認証情報は別のアカウントに紐づいています」「デバイスポリシーの更新が必要です」といった具体的なメッセージなら、問題の解決に導き、エラー発生時にも信頼を維持できます。
• 復旧手順のテスト不足: 復旧手順を十分にテストせずにパスキーを導入すると、ユーザーがアカウントにアクセスできなくなるおそれがあります。デバイスの紛失は予告なく起こり、予備の認証器が故障したり、クラウド同期に障害が発生したりすることもあります。実際の障害を想定し、段階的な手順と視覚的な案内を使って復旧手順をテストしてください。
• 安全性の低い代替認証を残す: 脆弱な単一要素認証（メールまたはSMSのワンタイムパスコードのみ）を代替手段にすると、パスキーが防ぐはずの攻撃に対する脆弱性が残ります。代替認証には多要素認証を必須としてください。また、緊急時のアクセスを確保しつつ、日常的な利用を抑えるため、復旧フローは通常の認証より意図的に手間がかかるように設計します。

実証済みのベストプラクティスに従うことで、こうした落とし穴を避け、障害に強い導入を実現できます。

パスキーのベストプラクティス

企業での導入を成功させるには、導入順序、対象ユーザーの選定、復旧設計、プラットフォーム統合に共通する実践方法があります。

段階的な導入戦略を実施する

段階的に導入します。まず、アプリベースの認証器で多要素認証の基盤を確立し、パスキー導入前に組織としての対応力を高めます。次に、移行期間中はパスワードによる代替認証を維持しながら、機密性の高いアプリケーションに フィッシング耐性のあるMFA を備えたパスキーを導入します。

採用が進んだら、ライフサイクルと復旧のプロセスを正式に定めます:

• デバイスのリモートロック解除と認証情報の発行
• コンプライアンスに対応する完全な監査証跡を伴う失効手順
• 組織全体にわたる認証情報の一元管理
• パスワード認証を緊急時の代替手段のみに移行

次の段階に進む前に、各段階で明確な成功基準を満たす必要があります。

リスクの高いユーザー層から導入する

まず、特権ユーザー、IT管理者、経営幹部に導入します。こうした重要な標的は、認証情報の窃取リスクが最も高く、 Verizon DBIR によると、ソーシャルエンジニアリングのインシデントの57%にフィッシングが関与し、すべての侵害の16%でフィッシングが初期アクセスの手段として使われています。機密性の低いサービスより先に、メール、VPN、人事システム、財務ツールなどの事業に不可欠なアプリケーションを保護します。

確実な復旧基盤を構築する

パスワードによる抜け道を作らずに、複数の復旧手段を実装します。主要なプラットフォーム認証器に加えて予備のハードウェアセキュリティキーの登録を必須とし、デバイスを1台失っても完全にアクセス不能にならないようにします。

管理者による復旧では、写真付き身分証明書の確認、上司による確認、セキュリティ質問への回答の検証など、複数の方法で本人確認を行います。クラウド同期型パスキーなら、ユーザーが同じプラットフォームのアカウントで代替デバイスにログインすると、自動的に復旧できます。デバイスに紐づくパスキーは、ハードウェアによる認証の証明が必要な特権アクセスに限定します。

IDプラットフォームと統合する

条件付きアクセスポリシーを使い、Microsoft Entra ID などの企業向けIDプラットフォームと連携します。リスクベースの認証では、リスクが高い場合にフィッシング耐性のあるパスキー認証を必須とし、リスクが低い場合は簡便な認証を適用できます。IDプラットフォームとの統合により、パスキー認証をアプリケーションへのアクセスやユーザーの行動と関連付けた、一元的な監査証跡も得られます。

継続的な改善プロセスを確立する

登録率、認証成功率、復旧の頻度、ヘルプデスクへのエスカレーション件数を追跡します。プラットフォームの対応状況や組織の成熟度の変化に合わせ、運用データとユーザーのフィードバックに基づいて認証フローを改善します。

パスキーは認証の防御を強化します。しかし、攻撃者が狙うのは認証情報だけではありません。

組織全体のアイデンティティリスクを軽減

Active DirectoryとEntra IDの総合的なソリューションにより、リアルタイムで攻撃を検知し、対応します。

デモを見る

主なポイント

パスキーは暗号技術を用いた認証により、認証情報の窃取やフィッシングを防ぎます。秘密鍵はユーザーのデバイスから外に出ません。パスワードもネットワークを通過せず、攻撃者が初期侵入に最も頻繁に 悪用する手段を排除します。企業への導入は、リスクの高いユーザーと事業に不可欠なアプリケーションから段階的に進める必要があります。レガシーシステムの制約、プラットフォーム間の不整合、ユーザーへの定着を妨げる要因も計画的に対処します。

ユーザー教育の省略、画一的なエラーメッセージ、脆弱な代替認証を放置すれば、パスキーによるセキュリティ強化の効果が損なわれます。アイデンティティセキュリティプラットフォームは、認証情報の保護にとどまらず、Active Directoryへの侵害、権限昇格、横展開など、認証基盤を狙う攻撃を検出してパスキーを補完します。