>
>
公開日
パスキーは「パスワードより安全な認証手段」として企業導入が進んでいますが、2026年8月、その前提を揺るがす脆弱性が報告されました。米セキュリティ企業Palo Alto NetworksのUnit 42は、マルウェアに感染した端末上でGoogleパスワードマネージャーとGoogle Chromeの挙動を模倣することで、パスキーで保護されたアカウントを乗っ取れる攻撃手法「Pass-ta-key」を公表しています。本記事では、情シスがこのニュースをどう受け止め、自社の認証基盤にどう向き合うべきかを整理します。
Googleパスワードマネージャーに何が起きたのか
今回の脆弱性は、パスキーの暗号技術そのものが破られたわけではなく、Googleパスワードマネージャーの実装とオンボーディング・復旧フローの隙を突いたものです。まずは何が報告されたのかを正確に把握することが、社内への説明や対応判断の土台になります。
Palo Alto NetworksのセキュリティチームUnit 42は2026年8月3日、TPM（Trusted Platform Module）を搭載したWindows PC上のGoogle ChromeとGoogleパスワードマネージャーを対象に検証を行い、端末がマルウェアに感染している場合に成立する3種類の攻撃手法を発見・報告しました。これらは総称して「Pass-ta-key」と呼ばれています。
重要なのは、この攻撃はいずれも「対象端末が事前にマルウェアに感染していること」を前提条件としている点です。パスキーの公開鍵暗号方式自体に脆弱性が見つかったわけではなく、Chromeがパスキーの秘密鍵やマスターキーをローカル環境でどう保護しているか、また新規デバイス登録・復旧フローをどう検証しているか、という「実装と運用の境界」が突かれた形です。Unit 42はこの内容を、パスワードマネージャーとは？仕組みとメリット・デメリットでも触れている「パスキー普及の流れ」の中で読み解くと理解しやすくなります。パスワードマネージャーは近年、単なる文字列の保管庫から「パスキーの管理ハブ」へと役割を変えており、今回の脆弱性はまさにそのハブ機能の内部で起きた問題です。
Unit 42はこの調査結果を、責任ある開示（Responsible Disclosure）の方針のもとGoogleに報告済みであり、脆弱性を悪用した実証実験（PoC）レベルの検証にとどめていると説明しています。
「Pass-ta-key」3つの攻撃手法を仕組みから理解する
3つの攻撃は難易度も影響範囲も異なり、「マルウェア感染=即アカウント乗っ取り」という単純な話ではありません。段階的に検証条件が緩和されていく構造を理解すると、自社にとってのリスクの大きさを判断しやすくなります。
① Pass-ta-key（本体）：正規の認証フローをマルウェアが模倣
最初の攻撃は、Chromeが認証時に行う正規の挙動をマルウェアがそのまま模倣するというものです。ChromeはWindows端末のTPMから取得したID鍵（デバイス識別キー）をローカルに暗号化保存しており、マルウェアがこのデータを抽出できれば、ユーザーの同意・生体認証・デバイスロック解除のいずれも経ずに認証を完了できてしまいます。攻撃には管理者権限は不要で、対象デバイス上でマルウェアを実行できていれば十分だとされています。
ただしこの攻撃は、サービス側がWebAuthnの「userVerification」フラグを厳格に「required（必須）」として検証している場合には失敗します。Unit 42の検証では、この設定が甘い（preferredのまま運用している）オンラインサービスの一つで実際に攻撃が成功したと報告されています。
② Silver Pass-ta-key：ユーザー検証キーそのものを偽装
2つ目の攻撃は、より影響が大きい手法です。マルウェアが既存のユーザー検証キーを無効化し、次回のパスキー利用時にデバイスを「再登録が必要な状態」に強制的に持ち込みます。この再登録待ちの隙を突き、攻撃者が自分で生成した公開鍵を「正規のユーザー検証キー」として登録してしまいます。
この手法が厄介なのは、一度キーの偽装に成功すると、被害者の端末がオフラインであっても、攻撃者は自分の環境から有効な認証情報（アサーション）を生成できてしまう点です。つまり、マルウェアが端末上で動作し続けている必要はなく、認証情報が窃取された後は攻撃者側で持続的に悪用できる「再利用可能なアクセス」に変わります。
③ Golden Pass-ta-key：パスキー全体を復号するマスターキーの窃取
3つ目は最も影響範囲が広い攻撃です。パスキーの秘密鍵はSDS（Security Domain Secret）と呼ばれるマスターキーによって保護されていますが、Silver Pass-ta-keyと同様の手法でデバイスの再登録を強制した際、このSDSがChromeのプロセスメモリ上に一時的に平文で展開されるタイミングが存在します。攻撃者はこのタイミングを狙ってメモリからSDSを抽出します。
SDSを取得できると、被害者が同期しているパスキーの暗号化レコードをすべて復号できるようになります。さらに深刻なのは、現行のGoogleの実装ではSDSをローテーション（更新）または失効させる手段が用意されていないため、攻撃成功後に作成される新しいパスキーも、同じSDSによって保護され続けてしまうという点です。これは単発の情報漏洩ではなく、情報漏洩はなぜ起こる？原因や予防策・対策まで解説で扱うような「継続的な侵害状態」に近い構造だと捉えるべきでしょう。
なぜ情シスがこの脆弱性を「他人事」にできないのか
「うちはまだパスキーを本格導入していないから関係ない」と考えるのは早計です。パスキーは従業員が個人アカウントで既に日常的に使っており、業務端末の管理範囲と密接に関わっているためです。
まず、社用PCの多くはBYOD的な使い方も含め、従業員がGoogleアカウントにログインしてChromeを日常的に利用しています。プライベートのGoogleアカウントや、取引先とのやり取りに使うSaaSアカウントがパスキーで保護されていれば、その端末がマルウェアに感染した時点で、Pass-ta-keyの前提条件が成立してしまいます。つまり、パスキー自体を業務システムで採用していなくても、従業員個人の認証情報が業務端末経由で危険にさらされるリスクは既に存在しています。
次に、3つの攻撃はいずれも「マルウェア感染」を出発点としています。裏を返せば、エンドポイントセキュリティとは？種類や製品の選定ポイントを解説やEDRとは？導入メリットや選び方をわかりやすく解説で扱っているような「端末レベルでの検知・防御」こそが、この種の攻撃に対する最も効果の高い一次防衛線になります。パスキーという認証方式単体の話ではなく、情シスが実践すべきセキュリティ対策とは？2026年最新動向を網羅で示されるような端末・認証・監視を組み合わせた統制の一部として捉える必要があります。
さらに、Silver・Golden Pass-ta-keyは「一度の侵害が長期化する」タイプの攻撃です。特にGolden Pass-ta-keyは、SDSのローテーション手段が現状ないという実装上の制約により、検知が遅れた場合の被害が時間とともに拡大しやすい構造を持っています。IPA（情報処理推進機構）が毎年公表する情報セキュリティ10大脅威2026｜実務対策と最新事例解説でも、認証基盤を狙った攻撃は継続的に上位項目として扱われており、今回の脆弱性はその延長線上にある事例として社内共有する価値があります。
情シスが今すぐ確認すべき対策とチェックリスト
Unit 42が提示した対策の多くはサービス提供者（relying party）やブラウザ開発者向けのものですが、情シスが自社の運用として今すぐ着手できる項目も少なくありません。まずは「今すぐ」「今期中」の2段階で整理します。
すぐに確認したいこと
社用PCおよびBYOD端末に、EDR等のマルウェア検知・プロセスメモリ保護機能が有効な状態で導入されているか
業務で利用するSaaSのうち、WebAuthn認証を採用しているサービスで「ユーザー検証（userVerification）」が「required」に設定されているか（自社がIdPやSaaSベンダーである場合は特に確認必須）
パスキーの初回登録・復旧（リカバリー）操作が発生した際に、通常と異なるタイミングでの再登録要求や、想定外のWindows Hello・PINプロンプトが表示されていないか、従業員に注意喚起できているか
社用PCでGoogleパスワードマネージャーを使ってパスキーを保存している従業員がいる場合、TPM搭載端末かどうか、Chromeが最新版に保たれているかを棚卸しできているか
今期中に検討したいこと
端末台帳とセキュリティパッチ適用状況を紐づけて可視化し、MDMとは？仕組みと選び方・主要製品比較を解説で扱うようなMDMによる一元管理下に置けているか
法人向けに認証情報の共有・権限管理を行う場合、ブラウザ標準機能ではなく【2026年最新】1Passwordの料金プランと安く買う方法のような専用パスワードマネージャー・SSO連携基盤への移行を検討できているか
過去にパスワードリスト攻撃とは？企業がすべき対策で解説したような認証情報の窃取インシデントが発生していないか、監査ログの保持範囲を確認できているか
未把握のSaaS・端末が社内に存在しないか、シャドーITの発見方法とは？効率的な検知手順と情シスが導入すべきツールを解説を参考に可視化を進められているか
中長期的な統制設計：パスキー運用をガバナンスに組み込む
今回の脆弱性から得られる最大の教訓は、「パスキーだから安全」という単純な図式では認証基盤を評価できないということです。中長期的には、パスキーを含む認証方式全体を、端末・アカウント管理と一体化した統制フレームワークの中に位置づける必要があります。
Unit 42自身も報告の結論で、パスキーは「攻撃の経済性を変える大きな前進」であると同時に、エンドポイントの侵害が依然として脅威モデルの中核であり続けると指摘しています。これは、パスキーとは？仕組みやメリット、設定方法を解説で紹介しているようなパスキーの利便性・安全性の高さを否定するものではなく、「端末が汚染されていれば認証方式を問わず突破され得る」という原則の再確認です。したがって情シスに求められるのは、パスキー移行を推進しつつも、ゼロトラストセキュリティとは？仕組み・導入の進め方を徹底解説の考え方に沿って「端末の健全性」を認証プロセスの前提条件として扱う設計です。
具体的には、①社内で利用するSaaS・IdPのuserVerification設定を定期的に点検する運用の定着、②MDM・EDRによる端末の健全性モニタリングとパスキー運用の連携、③従業員向けの「想定外の再認証プロンプトに気づいたら報告する」という簡易なインシデント一次対応フローの整備、の3点が現実的な出発点になります。これらはいずれも、SaaS・デバイス・アカウントを横断して可視化する基盤があることで実行可能性が大きく高まります。マネーフォワード Adminaでは、セキュリティ機能でSaaSアカウントの認証設定状況を可視化し、ID管理の機能でアカウントのライフサイクル管理と組み合わせることで、こうした認証基盤の統制を情シスの実務に落とし込みやすくしています。
よくある質問（FAQ）
Q：Pass-ta-key攻撃を受けるには、どんな条件が必要ですか？
A：対象デバイスに事前にマルウェアが感染していることが必須の前提条件です。マルウェアが存在しない、あるいは端末が適切にマルウェア対策で保護されていれば、この攻撃は成立しません。裏を返せば、エンドポイントのマルウェア対策が最も重要な防衛線になります。
Q：パスキーを使うのをやめて、パスワードに戻すべきですか？
A：その必要はありません。パスキーはフィッシングやパスワードリスト攻撃に対して依然として高い耐性を持ちます。今回の脆弱性は「マルウェア感染済みの端末」という限定的な条件下での実装上の課題であり、パスキーの基本的な安全性の優位性を損なうものではないとUnit 42自身も結論づけています。
Q：自社が使っているSaaSがこの攻撃の影響を受けるか、どう確認すればよいですか？
A：SaaSベンダー側にWebAuthnのuserVerificationパラメータの設定状況（required/preferred）を確認するのが基本です。自社が開発・運用するサービスがある場合は、開発チームと連携してこの設定と新規デバイス登録時のキー検証ロジックを見直すことが推奨されます。
Q：Googleはこの脆弱性にどう対応していますか？
A：Unit 42はGoogleに責任ある開示のプロセスで報告済みで、SDSがログに出力される問題など一部は既に修正されています。ただし本記事執筆時点では、SDSのローテーション機能など、より根本的な対応の実装状況は確認できていません。今後の公式アナウンスを継続的に確認することを推奨します。
まとめ
Googleパスワードマネージャーの脆弱性「Pass-ta-key」は、パスキーの暗号技術そのものではなく、実装とオンボーディング・復旧フローの隙を突いた攻撃です。マルウェア感染を前提条件とする以上、情シスにとっての最優先課題は目新しいものではなく、トロイの木馬とは？最新の感染経路と企業がすべき対策手順で解説されるようなエンドポイントのマルウェア対策の徹底と、認証・端末・アカウントを横断した可視化の強化という、これまでの情シス業務の延長線上にあります。パスキー移行を止める理由にはなりませんが、「認証方式を導入したら終わり」ではなく、端末の健全性と合わせて継続的に点検する運用を今のうちに設計しておくことが、次の同種インシデントへの備えになります。
今日からできるアクション
✅ 社用PC・BYOD端末のEDR/マルウェア対策の導入状況を棚卸しする
✅ 自社が運用するSaaS・サービスのuserVerification設定を開発チームに確認する
✅ パスキーの想定外の再登録プロンプトに気づいた際の報告フローを従業員に周知する
✅ MDM・SaaS管理ツールで端末とアカウントの状態を一元的に可視化できているか確認する
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
