>
>
公開日
最終更新日
Pass-ta-keyは、感染したWindows端末上でGoogle ChromeとGoogleパスワードマネージャーの同期・復旧処理を悪用する攻撃手法です。パスキーの暗号自体が破られたわけではなく、対応の軸はマルウェア感染を前提とした同期制御・端末防御・ユーザー検証・デバイス固定型パスキーの組み合わせになります。
この記事で確認したこと（確認日: 2026年8月27日）
Unit 42が公表した基本・Silver・Goldenの成立条件、Googleパスワードマネージャーのパスキー管理への影響、WebAuthnのuserVerification設定、情シスが実行できる端末・認証統制を確認しました。
トレンドマイクロは2026年3月24日付プレスリリース（「パスキーに関する調査」2026年3月24日）で、日本国内のWebサービス利用者を対象とした国内調査の結果として、回答者の91.1％がパスキーを認知し、対応サービス利用者の87.7％が実際に利用していると報告しています。普及が進む今、Chromeのパスワード管理を含む運用範囲を把握する必要があります。
Googleパスワードマネージャーに何が起きたのか
今回の脆弱性は、パスキーの暗号技術そのものが破られたわけではなく、Googleパスワードマネージャーの実装とオンボーディング・復旧フローの隙を突いたものです。まずは何が報告されたのかを正確に把握することが、社内への説明や対応判断の土台になります。
本記事のポイント
Pass-ta-keyは製品名ではなく、同期型パスキーの実装を狙う攻撃手法の総称です。
攻撃の成立には、対象となるWindows端末でマルウェアが実行されていることが前提です。
パスキーの公開鍵暗号そのものが解読されたわけではありません。
情シスの対策は、EDR・MDM、userVerificationの検証、デバイス固定型パスキーの併用です。
Palo Alto NetworksのセキュリティチームUnit 42は2026年8月3日、TPM（Trusted Platform Module）を搭載したWindows PC上のGoogle ChromeとGoogleパスワードマネージャーを対象に検証を行い、端末がマルウェアに感染している場合に成立する3種類の攻撃手法を発見・報告しました（参照：Pass-ta-key攻撃の詳細報告）。これらは総称して「Pass-ta-key」と呼ばれています。
重要なのは、この攻撃はいずれも「対象端末が事前にマルウェアに感染していること」を前提条件としている点です。パスキーの公開鍵暗号方式自体に脆弱性が見つかったわけではなく、Chromeがパスキーの秘密鍵やマスターキーをローカル環境でどう保護しているか、また新規デバイス登録・復旧フローをどう検証しているか、という「実装と運用の境界」が突かれた形です。パスワードマネージャーは近年、単なる文字列の保管庫から「パスキーの管理ハブ」へと役割を変えており、今回の脆弱性はまさにそのハブ機能の内部で起きた問題です（詳細はパスワードマネージャーの仕組みと役割を参照）。
Unit 42はこの調査結果を、責任ある開示（Responsible Disclosure）の方針のもとGoogleに報告済みであり、脆弱性を悪用した実証実験（PoC）レベルの検証にとどめていると説明しています。
▶ 関連記事: パスワードマネージャーとは？安全性やGoogleとの違い・選び方
「Pass-ta-key」3つの攻撃手法を仕組みから理解する
3つの攻撃は成立条件と影響範囲が異なるため、端末上での一時的な不正認証と、同期済みパスキー全体の継続的な侵害を分けて評価します。
攻撃手法 | 主な成立条件 | 攻撃の内容 | 影響範囲 | SDS流出 |
|---|---|---|---|---|
Pass-ta-key | 対象端末でマルウェアが実行され、サービス側のユーザー検証が厳格でない | Chromeの正規処理を模倣して署名を生成する | 対象サービスへの不正ログイン | なし |
Silver Pass-ta-key | マルウェアがデバイスの再登録フローを悪用できる | 攻撃者が生成した検証キーを登録する | 攻撃者環境からの継続的なログイン | なし |
Golden Pass-ta-key | 再登録時にChromeのプロセスメモリへ一時展開されるSDSを取得できる | 同期されたパスキーを保護するマスターキーを抽出する | Googleアカウントに同期された複数のパスキー | あり |
Pass-ta-key：正規の認証フローの模倣
最初の攻撃は、Chromeが認証時に行う正規の挙動をマルウェアが模倣するものです。検証では、感染端末上のマルウェアがWindows APIのCNGを呼び出し、管理者権限や生体認証なしで不正な署名を生成できることが報告されました。
ただし、サービス側がWebAuthnの「userVerification」を「required」に設定し、認証結果でもユーザー検証済みであることを厳格に確認する場合、この基本攻撃は失敗します。Unit 42は、「preferred」のまま運用するオンラインサービスでは攻撃が成功したと報告しています。設定値を送信するだけでなく、サーバー側でauthenticatorData内のUV（userVerified）ビットが立っていない認証結果を拒否する処理を実装することで、防御が完結します。
Silver Pass-ta-key：ユーザー検証キーの偽装
2つ目の攻撃では、マルウェアが既存のユーザー検証キーを無効化し、次回利用時にデバイスを再登録が必要な状態へ移します。攻撃者はそのフローへ自分で生成した公開鍵を登録し、正規の検証キーとして扱わせます。
偽装に成功すると、被害端末がオフラインになった後も、攻撃者は自分の環境から有効な認証情報を生成できます。端末の駆除だけでは不正な登録情報が残る可能性があるため、侵害対応では登録済みデバイスとパスキーの棚卸しまで行います。
Golden Pass-ta-key：SDSの抽出
Golden Pass-ta-keyは、Googleアカウントに同期されたパスキーを保護するSDS（Security Domain Secret）を狙います。デバイスの再登録時にはSDSがChromeのプロセスメモリ上へ一時的に平文で展開されるため、マルウェアはそのタイミングでメモリから32バイトのマスター暗号鍵を抽出します（参照：Unit 42報告 — Pass-ta-key検証内容）。
SDSが漏えいすると、攻撃者はそのSDSで保護されたGoogleアカウント上の同期済みパスキー全体の暗号化レコードを復号できる可能性があります。個別セッションの窃取と異なり、対象端末に登録されているパスキーにとどまらず、同一Googleアカウントに同期されているすべてのパスキーが影響を受け得る点が特徴です。ただし、SDSの取得だけで直ちに全サービスへ不正ログインできるわけではなく、各サービスの認証フローや追加要件によって実際の影響は異なります。復旧時には端末隔離、Googleアカウントのセッション確認、同期済みパスキーの再登録を一体で扱います。SDSのローテーションや失効に関する公式な利用者向け手順は、確認日時点の公開情報では確認できません。
▶ 関連記事: 情報漏洩はなぜ起こる？原因や予防策・対策まで解説
▲ Pass-ta-keyにおける3つの攻撃手法のプロセスと影響範囲の違い
同期型パスキーとデバイス固定型パスキーの違い
特権アカウントにはデバイス固定型、一般業務には管理された端末上の同期型を割り当てると、利便性とPass-ta-key耐性を両立しやすくなります。
比較軸 | 同期型パスキー | デバイス固定型パスキー |
|---|---|---|
主な例 | Googleパスワードマネージャー、iCloudキーチェーンなど | FIDO2ハードウェアキー、Windows Hello for Businessなど |
秘密鍵の扱い | 暗号化した情報をクラウド経由で複数端末へ同期する | 端末のTPMやセキュリティキー内に保持し、原則として外部へ同期しない |
Pass-ta-keyとの関係 | Google同期パスキーを対象とする実証の攻撃面に含まれる | 同期用のSDSを利用しないため、Golden Pass-ta-keyと同じ経路の対象外になる |
利便性 | 複数端末で利用しやすく、端末交換後の復旧が容易 | 利用端末や物理キーが限定され、持ち替え時に手続きが発生する |
コスト | OSやブラウザの標準機能なら追加調達が発生しない場合がある | 物理キーの調達、予備キー、再発行体制が必要 |
運用上の注意 | 個人アカウントとの混在、未許可端末への同期、復旧フローを統制する | 紛失、故障、退職時の回収、緊急時の代替認証を設計する |
適する用途 | 管理端末で利用する一般的な業務アカウント | IdP管理者、クラウド管理者、経理承認者など影響度の高いアカウント |
デバイス固定型も、感染端末上で正規ユーザーのセッションを悪用されるリスクまで消すものではありません。一方、同期型を全面禁止すると端末交換や復旧の負荷が増え、非公式な回避運用を招きます。認証方式はアカウントの権限と端末管理状況で分けます。
Googleは自社のパスキー導入事例ページ（Passkey case studies — Google Identity）で、Dashlaneがパスワードよりもパスキーによるログインコンバージョン率が70％高かったと紹介しています。この数値はDashlane社の測定に基づくGoogleの紹介であり、公開時点の情報である点に留意してください。利便性の効果は大きいため、一般利用まで一律にパスワードへ戻すのではなく、高権限アカウントだけをデバイス固定型へ切り替える設計が現実的です。
▶ 関連記事: EDRとは？EPPとの違いやコスト・選び方を解説
▲ 同期型パスキーとデバイス固定型パスキーの特性と使い分けの対比
なぜ情シスがこの脆弱性を「他人事」にできないのか
Googleパスワードマネージャーを正式導入していない企業でも、業務端末上のChrome同期や個人アカウント利用を把握していなければ攻撃面が生まれます。
社用PCで従業員がGoogleアカウントにログインし、Chromeのパスワード管理やパスキー同期を有効にしている場合、情シスが認識していない認証情報が端末内に存在します。業務システムがパスキーを採用していなくても、取引先のSaaSや業務関連アカウントが同期対象なら、感染端末がPass-ta-keyの起点になり得ます。
3つの攻撃はいずれもマルウェア感染を出発点とするため、端末レベルの検知・防御（エンドポイントセキュリティの概要・EDRの導入と選び方）が一次防衛線になります。ただし、EDRは感染やメモリアクセスを必ず阻止する保証ではありません。MDMで許可端末とChromeポリシーを統制し、IdPの条件付きアクセスや監査ログを組み合わせます。
端末管理では、管理対象ブラウザへの限定、私用Googleアカウントでの同期制御、拡張機能の許可制、OSとChromeの更新、ローカル管理者権限の削減を同じポリシーで扱います。端末の準拠状態をIdPへ渡せるなら非準拠端末からの認証を拒否し、連携できない場合は高権限アカウントへのアクセス端末を固定します。
Silver・Golden Pass-ta-keyでは、一度の感染が端末外で継続する認証情報へ変わる可能性があります。検知後に端末を初期化するだけで対応を終えると、偽装されたキーや同期済みパスキーを見落とします。端末、Googleアカウント、IdP、各SaaSのログを同じインシデントとして調査する体制が必要です。
▶ 関連記事: エンドポイントセキュリティとは？種類や製品の選定ポイントを解説
導入時の注意点と失敗パターン
最も避けたい失敗は、「パスキーだから安全」と判断し、端末防御や復旧手順を省略することです。
同期型パスキーの一律禁止
Pass-ta-keyの報告だけを理由に同期型パスキーを全面禁止すると、端末交換や紛失時の復旧性が下がり、従業員が未承認の認証手段へ移るおそれがあります。特権アカウントをデバイス固定型へ分離し、一般アカウントでは管理端末と同期先を限定する方が統制しやすくなります。
userVerificationの送信設定だけでの完了
WebAuthnの登録・認証要求でuserVerificationをrequiredにしても、サーバー側がユーザー検証済みの結果を検証しなければ防御は完結しません。自社開発サービスでは認証ライブラリの設定、認証結果の検証、回帰テストを組み合わせます。利用企業側で変更できないSaaSは、ベンダーがrequired相当の検証を実施していると回答できれば継続し、回答が得られなければ高権限操作に別の認証制御を追加します。
端末初期化だけでのインシデント完了
Silver Pass-ta-keyでは攻撃者側のキーが残り、Golden Pass-ta-keyでは同期済みデータへの影響が端末外へ及ぶ可能性があります。感染端末の隔離後は、セッション失効、登録デバイスの確認、パスキーの再登録、SaaS監査ログの調査までを完了条件にします。
ハードウェアキーの単独配布
物理キーを配布するだけでは、紛失時に安全性を下げる例外運用が生じます。予備キーの保管、本人確認、再発行、退職時の回収を事前に定義し、代替認証へ切り替えた履歴を監査対象にします。
▶ 関連記事: 情シスが実践すべきセキュリティ対策とは？2026年最新動向を網羅
▲ アカウントと端末の条件に応じたパスキー運用の判断フロー
情シスが今すぐ確認すべき対策とチェックリスト
初動では感染経路と同期範囲を止め、その後に認証設定と高権限アカウントの方式を見直します。
今すぐ実行する一次対応
EDRの稼働状況：社用PCと許可済みBYODでEDRが停止していないかを管理画面で確認します。未導入・未稼働端末はパスキー同期を許可せず、業務アクセスを管理端末へ限定します。
Chrome同期の範囲：業務端末でGoogleパスワードマネージャーのパスキー同期が使われているかを棚卸しします。把握できる場合は許可アカウントと端末を限定し、把握できない場合はブラウザポリシーで私用アカウントの同期を抑制します。
更新状態：OS、Chrome、EDRエージェントのバージョンを端末台帳と突合します。更新が滞る端末は認証基盤へのアクセス対象から外し、更新後に復帰させます。
再登録イベント：想定外のパスキー再登録、Windows HelloやPINの再設定、Googleアカウントへの新規デバイス追加を報告対象として従業員へ周知します。
侵害疑い端末：ネットワークから隔離し、メモリやログの保全前に安易な再起動や初期化を行いません。調査後にセッション失効、登録デバイス削除、パスキー再登録へ進みます。
今期中に整備する運用
WebAuthnの設定：自社開発サービスではuserVerificationをrequiredにし、サーバー側でもユーザー検証済みの結果を必須条件としてテストします。
SaaSベンダーへの照会：利用企業側で設定できない場合は、userVerificationの要求値と検証方法、パスキー再登録時の本人確認、監査ログの取得可否を照会します。厳格な検証を確認できれば運用を継続し、確認できなければ高権限操作を別IdPやデバイス固定型認証へ分離します。
MDMポリシー：端末台帳とパッチ適用状況を紐づけ、MDMとは？仕組みと選び方・主要製品比較を解説で扱うような一元管理下に置きます。未許可端末からの同期を遮断できない場合は、重要SaaSの条件付きアクセスで補完します。
特権アカウント：IdP、クラウド、セキュリティ製品、財務システムの管理者にはFIDO2ハードウェアキーまたはWindows Hello for Businessを割り当てます。
復旧手順：端末隔離、アカウントセッション失効、登録キー確認、パスキー再発行、監査ログ調査、利用再開判定の順序をインシデント対応手順へ追加します。
運用の優先順位は、端末感染の封じ込め、認証情報の継続悪用防止、再発防止の順です。ハードウェアキーの配布から始めるのではなく、まず同期利用と高権限アカウントを特定します。
▶ 関連記事: 情報セキュリティ10大脅威2026｜実務対策と最新事例解説
中長期的な統制設計：パスキー運用をガバナンスに組み込む
パスキーの統制は、認証方式だけでなく、端末の健全性、アカウント権限、復旧フロー、監査ログを一つの運用として設計します。
今回の脆弱性から得られる最大の教訓は、「パスキーだから安全」という単純な図式では認証基盤を評価できないということです。Unit 42の報告（Pass the Passkey: A Novel Attack Surface in Passwordless Authentication）はパスキーのフィッシング耐性を否定するものではなく、同期基盤や感染端末を経由する別の攻撃面を示しています。
FIDO Allianceが2025年10月に公開した「Passkey Index」は、パスキーを導入した主要サービスにおける認証成功率93％、ログイン時間短縮率73％という数値を示しています。利便性と運用負荷の改善が見込めるため、パスワードへ全面回帰する判断ではなく、権限に応じて同期型とデバイス固定型を使い分けます。
具体的には、①SaaS・IdPのuserVerification設定を定期点検する運用、②MDM・EDRによる端末の健全性とアクセス制御の連携、③想定外の再登録プロンプトを報告する一次対応フロー、④特権アカウント向けハードウェアキーの予備・再発行手順を整備します。これはパスキーとは？仕組みやメリット、設定方法を解説で扱う認証方式と、ゼロトラストセキュリティとは？仕組み・導入の進め方を徹底解説で扱う端末評価を接続する運用です。
SaaS・デバイス・アカウントを横断して可視化できれば、侵害時の調査対象を短時間で絞れます。SaaSアカウントの認証設定とIDライフサイクルを一元で把握するツールを選ぶ際は、①SaaSごとのuserVerification対応状況を可視化できるか、②アカウント棚卸しと権限変更の履歴を監査ログとして取得できるか、の2点を確認し、自社のIdP・MDMとの連携可否と照合します。マネーフォワード Adminaについては、セキュリティ機能やID管理機能の詳細を各機能ページで確認し、自社のIdP・MDM連携要件と照合した上で導入可否を判断してください。
▶ 関連記事: MDMとは？仕組みと選び方・主要製品比較を解説【2026最新】
よくある質問
Q：Pass-ta-key攻撃を受けるには、どんな条件が必要ですか？
A：対象のWindows端末で、攻撃に必要なマルウェアが事前に実行されていることが前提です。EDRや抗ウイルスソフトは感染・不正処理のリスクを下げますが、完全には防げないため、同期制御、userVerification、端末準拠性を組み合わせます。
Q：userVerificationとは何ですか？
A：userVerificationは、WebAuthn認証でPINや生体認証などによるユーザー本人の検証を求める設定です。基本攻撃への防御ではrequiredを指定し、サーバー側でもユーザー検証済みの結果を必須条件として扱います。
Q：Golden Pass-ta-keyは何が危険なのですか？
A：Golden Pass-ta-keyは、Googleアカウントに同期されたパスキーを保護するSDSをChromeのプロセスメモリから抽出する攻撃です。個別のログインだけでなく複数の同期済みパスキーへ影響が及ぶ可能性があるため、端末の駆除だけでは復旧を完了できません。
Q：パスキーをやめてパスワードに戻すべきですか？
A：Pass-ta-keyはパスキーの暗号技術自体の破綻を示すものではなく、パスキーはフィッシングやパスワードリスト攻撃に対して引き続き有効です。一般的には、高権限アカウントをデバイス固定型へ切り替え、一般利用は管理端末上の同期型として統制することで、既存のパスワード運用より攻撃面を絞れます。ただし、自組織のリスク評価・端末管理状況・運用体制によって適切な移行方針は異なります。
Q：Googleはこの脆弱性にどう対応していますか？
A：Unit 42はGoogleへ責任ある開示を行い、実証対象となったeBayの問題は報告後に修正されたと報じられています。一方、SDSのローテーションや失効に関する利用者向けの公式手順は、2026年8月27日時点の公開情報では確認できません。
▶ 関連記事: 1Passwordの料金比較！値上げ後に最安で買う方法を解説
まとめ
Pass-ta-keyは、マルウェアに感染したWindows端末でGoogleパスワードマネージャーの同期・再登録処理を悪用する攻撃手法です。パスキーの暗号自体が破られたわけではなく、パスワードへ戻す理由にもなりません。
情シスが最初に行うのは、Googleパスワードマネージャーの利用端末と同期範囲、高権限アカウントを棚卸しすることです。その結果、一般アカウントはEDR・MDM管理下の同期型、高権限アカウントはFIDO2ハードウェアキーなどのデバイス固定型へ分けます。併せてuserVerificationをrequiredにし、端末隔離だけで終わらない復旧手順を整備します。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
