セキュリティ

「パスキーにしたのに破られた」その手法。Vaultjacking／パスキー登録ヴィッシングに学ぶセキュアなパスキー設計

Shinji Saito
Shinji Saito

代表取締役社長 / 文部科学省 最高情報セキュリティアドバイザー

シンジです。パスワードレスって素晴らしいですよね。社内の認証、とりあえず安全そうだからという理由でパスキーを展開していませんか？もちろん、以前の方式よりだいぶマシ、とりあえずでも入れといた方が良さそう、というケースも多いでしょう。その点についてはシンジも賛成です。さて、セキュリティには万能かつ完璧はありません。改めてパスキーの脆弱なポイントや実際の攻撃例から、パスキーの注意点を学びます。

エグゼクティブサマリー

  • パスキーの強さは「ログイン時のフィッシング耐性」に集中しています。攻撃者はそこを正面突破せず、登録（enrollment）・同期（sync）・復旧（recovery）という「ログインの外側」の3レイヤーへ回り込み始めました。
  • 同期レイヤー：PhishUが2026年5月に公開した「Vaultjacking」は、通常サインイン中にGoogle Password Manager（GPM）の6桁PINをAiTM（中間者）で一度奪い、後から同期パスキー・パスワードの保管庫全体を攻撃者インフラ上で復号・複製できると報告しています。ポイントは「SDSがマスター鍵であること」と「Googleにはクロスデバイス承認が無いこと」です。
  • アーキテクチャの前提：Palo Alto Networks Unit 42（研究者 Arie Olshtein、CyberArkのパスキー研究シリーズ Part 2、2026年3月）は、GPMの同期パスキーがクラウド認証器（enclave.ua5v[.]com）・Security Domain Secret（SDS）・TPM由来の鍵に依存するハイブリッド構造であることをコード解析で公開しました。この集中点が新たな攻撃面になり得ると位置づけ、具体的な攻撃ベクトルは続編（Part 3）で扱うと予告しています。
  • 登録レイヤー：Oktaの脅威インテリジェンスは2026年7月、脅威アクターO-UNC-066（Unit 42呼称「Pink」）が2026年4月以降、Microsoft 365向けにパスキー登録プロセスそのものを騙すパネル制御型フィッシングキットとヴィッシング（電話勧誘）を展開していると報告しました。動機はデータ恐喝で、専用リークサイトも運用されています。
  • 「同期パスキー」はひとつではない：1Password・Keeper・Bitwardenなどのサードパーティ保管庫は、サーバーが知り得ない鍵素材や既存デバイスの明示的関与を新規参加の関門にしており、PIN1つのフィッシングで保管庫全体が抜けるVaultjacking型の対象外です。ただし保管庫マスターパスワードという別の集中点は残ります。またFIDO2セキュリティキー（デバイスバウンドパスキー）は同期レイヤーが構造的に存在せず、attestation（構成証明）により登録レイヤーの統制手段にもなります。
  • 情シスがやるべきは「パスキー導入の可否」の議論ではなく、同期パスキーの制御・登録／復旧の本人確認強化・複数登録による冗長化・登録／デバイス参加イベントの監査という運用設計です。

攻撃面は「ログイン」ではない

パスキーは、公開鍵暗号を使い、認証情報をサイトのオリジンに暗号的に紐づけることで、偽サイトでは使えない＝フィッシング耐性を実現します。ログイン単体の防御力は従来のパスワード＋OTPより明確に高くなります。問題は、攻撃者がその強い部分（WebAuthnのハンドシェイク）を避け、周辺のワークフローを突き始めたことです。

いま実際に狙われているのは次の3レイヤーです。

レイヤー攻撃者の狙い関連する公開情報（2026年）効く対策の性質
登録（enrollment）まだパスキーが無いユーザーを狙い、偽の登録画面で足止めしている隙に、攻撃者が被害者の正規アカウントへ自分のパスキーを直接登録するO-UNC-066「Pink」がMicrosoft Entra登録を標的（Okta, 2026年7月）登録時の本人確認・登録キャンペーンの運用・監査
同期（sync）クラウド同期の集中点（PIN／SDS）を突き、保管庫全体を一括で奪うVaultjacking（PhishU, 2026年5月）／構造解析（Unit 42, 2026年3月）同期の許可範囲設計・デバイス参加の監視
復旧（recovery）紛失・機種変更の復旧経路に残る弱い認証（パスワード／SMS／口頭確認）へ落とす各社の復旧設計の一般的課題（Microsoft Learn 等が対策を明示）復旧の本人確認・冗長化・循環依存の排除

どのサービスを・どの保存先で・どのブラウザで使ったときが対象か

ここでいったん、多くの読者がつまずく点を先に整理します。「Vaultjackingの対象になるのは、自分のどのパスキーなのか」という点です。対象を決めるのは『どのサービスにログインするか』でも『どのブラウザを使うか』でもなく、『パスキーの秘密鍵がどのプロバイダに保存・同期されているか（保存先＝クレデンシャルマネージャ）』です。

この3つを混同しないことが肝心です。

  • サービス（RP＝Relying Party）：ログインする先。GitHub、Microsoft 365、そして社内のOktaポータルなど。同期層（Vaultjacking）の対象可否については、RPは決めません。 同じOktaポータルへのログインでも、そのパスキーの保存先次第で同期層の対象かどうかが変わります。ただし後述のとおり、登録層はRP／IdP側の登録ポリシーが大きく影響します（WebAuthnでは登録セレモニーをRPが開始し、attestationやAAGUID許可リストで許可する認証器を制御できます）。
  • ブラウザ：WebAuthnの仲介役。ChromeもEdgeもSafariも、パスキーを「作成・利用する窓口」であって、原則として秘密鍵そのものを保持しません（後述のブラウザ論点も参照）。
  • 保存先（クレデンシャルマネージャ／認証器）：秘密鍵が実際に保管される場所。GPM、iCloudキーチェーン、Windows Hello、1Password等の拡張、FIDO2セキュリティキーなど。ここが対象可否を決めます。

Chromeでパスキーを作るとき、実は保存先を選んでいます。Chromeでパスキー対応サイトを訪れると「Google Password Managerにパスキーを作成しますか」と尋ねられ、選べば秘密鍵はGoogleアカウントに同期されます。しかし同じChrome上でも、保存先としてWindows Hello（端末のTPMに束縛）やiCloudキーチェーン、1Password等を選べば、その鍵はGPMのSDS／GPM PINの仕組みを一切通りません。つまり「Chromeを使っている＝Vaultjackingの対象」ではありません。逆に、AndroidアプリでGPMに保存したパスキーは、Chromeを使っていなくても対象です。

パスキーの保存先（認証器）典型的な作成・利用シーンVaultjacking型（同期層）の対象登録層（O-UNC-066型）の対象復旧層の対象
Google Password Manager（GPM）ChromeでGPMを選択／Androidで作成対象（本稿前半の直接対象）該当（RP非依存）該当
Windows Hello（このデバイスに保存）Windows端末・Edge/Chrome対象外（端末バインド・同期に載らない）該当（RP非依存）該当
Apple iCloudキーチェーンSafari／Apple端末Vaultjacking型の直接対象外（別構造。前述の承認・エスクロー参照）該当（RP非依存）該当
1Password／Keeper／Bitwarden等各ブラウザ拡張・アプリVaultjacking型の対象外（各社構造。マスターパスワードは別の集中点）該当（RP非依存）該当
FIDO2セキュリティキー（YubiKey等）USB/NFCで抜き差し対象外（同期レイヤーが存在しない）該当だがattestationで統制可能紛失＝復旧不能。複数登録が前提

つまり同期層（Vaultjacking）は保存先で対象可否が分かれますが、登録層と復旧層は保存先に関係なくほぼ全員が該当します。登録ヴィッシング（O-UNC-066型）はRPの登録フローを騙す攻撃なので、PingOneでも社内IdPでも同型の攻撃が成立し得ますし、復旧の弱い迂回路（パスワード／SMS）はどの保存先でも設計課題として残ります。

自分のパスキーが対象かどうか

  1. そのパスキーの保存先はどこか？（プロンプトで判別できます。Chromeで「Google パスワード マネージャー」のシートが出る→GPM／Windows Helloのダイアログ→端末バインド／拡張機能のオーバーレイ→サードパーティ保管／キーを挿すよう促される→FIDO2セキュリティキー）
  2. GPMに保存なら → Vaultjacking型の同期層の対象。加えて登録層・復旧層も該当。
  3. Windows Hello／FIDO2キーなら → 同期層は対象外。ただし登録層（他人が勝手に登録する手口）と復旧層は該当。
  4. iCloud／1Password／Keeper／Bitwardenなら → Vaultjacking型は対象外だが、各プロバイダのマスターパスワード・復旧フローという別の関門が該当（本文「『同期パスキー』はひとつではない」参照）。登録層・復旧層も該当。

棚卸ししたい場合は、個人利用なら chrome://settings/passkeys や passwords.google.com、Windowsは「設定→アカウント→パスキー」で保存先ごとに確認できます。管理者視点では、IdP（PingOne・Entra・Okta等）に登録された認証器のAAGUIDを集計すれば、どの保存先のパスキーが使われているかを一括で把握できます。

GPMに保存していれば、攻撃者が狙うのはIdPのログイン画面ではなくGoogleアカウント側で、そこをAiTMで釣ってGPM PINを取ればVaultjackingの手順でIdP用パスキーも巻き込まれ得ます。Windows HelloやFIDO2キーに保存していれば同期層の対象外です。

ブラウザを変えれば回避できるのか（Chrome／他ブラウザ／セキュアブラウザ）

「Chromeが問題なら、別のブラウザやエンタープライズ向けのセキュアブラウザを使えば回避できるのか」という疑問は当然湧きます。ここも「ブラウザではなく保存先」という原則から整理できます。

  • 他ブラウザ（Edge・Firefox・Safari）に変えても、保存先がGPMのままなら対象は変わりません。Vaultjackingが突くのはブラウザではなくGPMの同期構造（SDS・GPM PIN）だからです。Edgeに乗り換えてもChromeプロファイルのGoogleアカウントでGPMを使い続ければ、同じ同期ドメインに乗ったままです。逆に、ブラウザはChromeのままでも保存先をWindows HelloやFIDO2キーに寄せれば同期層の対象から外れます。「回避したいなら変えるべきはブラウザではなく保存先」というのが本質です。
  • ただしブラウザの選択が無意味というわけではありません。Vaultjackingの手順3では、攻撃者は最終的にChromeのセキュリティドメイン参加（TPM構成証明）を悪用します。また悪性ブラウザ拡張を使うBrowser Syncjacking型の攻撃は、拡張機能のガバナンスが効くブラウザほど成立しにくくなります。つまりブラウザ層の統制は「同期構造そのもの」ではなく「その周辺（拡張・プロファイル同期・端末の状態）」に効きます。
  • Chrome Enterprise（管理対象Chrome・Enterprise Premium）：ChromeはEnterprise向けにポリシー管理が可能で、管理者はプロファイル同期の可否、パスワードマネージャの有効化、拡張機能の許可リストなどをグループポリシー／Adminコンソールで制御できます。個人Googleアカウントのプライマリ化を禁止し、業務プロファイルを強制すれば、GPMを通じた個人アカウントへの資格情報流出（Chromeプロファイル衛生の問題）を大きく減らせます。Enterprise Premiumはこれに高度な脅威防御・DLP・URLフィルタリング等を上乗せしたエディションです。なお、具体的なポリシー名（例：SyncDisabled／PasswordManagerEnabled／RestrictSigninToPattern）を設定に使う場合は、公開前にChrome Enterprise Policy Listで最新の名称・挙動を個別確認してください。
  • 専用ブラウザ型／ブラウザ置換型のセキュアブラウザ（Island・Palo Alto Prisma Access Browser・Netskope One Enterprise Browser・Mammoth Cyber Enterprise Browser 等）：これらは管理対象のブラウザ環境として、プロファイル同期やパスワード保存、データ操作、セッション制御を管理者ポリシーで制御できる製品群です。
    Islandはブラウザ内蔵のパスワードマネージャについてゼロナレッジ型アーキテクチャと文脈制御（ユーザー／グループ・デバイスポスチャ・地理・ネットワーク・宛先アプリ）を公式に説明しています。
    Prisma Access Browserは、Enterprise Password Manager・保存ログインの管理・プロファイル同期に加え、資格情報の表示／コピー／自動入力時に管理者ポリシーでステップアップMFAを要求できることを公式ドキュメントで確認できます。
    Netskope One Enterprise BrowserはNetskope One SSEのSWG／CASB／NPA／Threat Protection／DLPなどをBYOD・非管理端末・委託先ユーザーのブラウザ利用に拡張し、自己完結型の企業ワークスペースとして個人ブラウザから業務アクセスを分離します。公式資料では、コピー／ペースト／印刷／スクリーンキャプチャ／画面共有／透かしなどに対するブラウザ内データ保護ポリシーも説明されています。（Chromiumベースであることや拡張機能ガバナンスの詳細は、採用時に別途管理者ガイドで確認してください。）
    Mammoth Cyberは既存のSSO／IdP／MFA基盤と連携し、ロール・属性、デバイスポスチャ、ネットワーク信頼、IDコンテキストに基づくブラウザセッション制御を提供すると公式に説明しています。これらを使うと、業務パスキーを個人GPMに保存させない運用や、業務トラフィックを管理下のブラウザに閉じ込める運用が取りやすくなります。
    各製品の細かい機能（例：個人アカウントへのアクセス制御、DOM監視による特定サービスのブロック、ゼロナレッジの有無）は製品・エディション・時期で異なるため、採用時は各社の管理者ガイドで個別に確認してください。
  • クラウドブラウザ分離・拡張型（Menlo Security 等）：Menloのように、ブラウザを置き換えずに既存のChrome／Edgeに拡張（Secure Extension）＋クラウド分離（Menlo Cloud）を被せる方式もあります。高リスクな閲覧をクラウド側でレンダリングしてゼロデイフィッシングや資格情報窃取を遮断する（HEAT Shield等）もので、AiTMフィッシングの入口を減らす点ではVaultjackingの初手（PINを釣るAiTM）に対して意味があります。ただしこれは「保存先を管理下に寄せる」統制とは軸が異なり（フィッシングページ自体を見せないアプローチ）、ユーザーが個人端末・個人GoogleアカウントでGPMに保存してしまえば、その保存先自体は別途制御が必要です。
  • ただしセキュアブラウザも万能ではありません。第一に、Vaultjacking型で狙われるGPMの同期構造は、ユーザーが個人のChromeやスマホで個人Googleアカウントにパスキーを保存していれば、業務用セキュアブラウザの外側で成立します（だからこそMammothのような個人アカウント・個人端末側の統制があわせて必要になります）。第二に、Edgeの同期をめぐる公開知見が示すとおり、同期を後から無効化しても『すでに同期済みの資格情報』は残り続けるという重要な限界があります（Microsoftの解説では、同期を止めても既に同期された資格情報は取得可能で、確実に断つには条件付きアクセスで同期そのものをブロックするしかないとされています）。導入は「これから保存されるもの」には効きますが、「すでに個人アカウントに載ってしまったもの」の棚卸しは別途必要です。

まとめると、ブラウザ／セキュアブラウザの選択は保存先を管理下に寄せ、拡張・プロファイル同期を統制するという点で有効な打ち手ですが、それ自体がVaultjackingの同期構造を無効化するわけではありません。効くのはあくまで「業務パスキーの保存先を管理下（デバイスバウンドや管理対象保管庫）に寄せる」設計であり、ブラウザ統制はその一部を実現・強制する手段、という位置づけになります。実際の強制はブラウザ単体では完結せず、IdP側の登録ポリシー（attestation／AAGUID制御）、OS／MDMポリシー、ブラウザプロファイル統制を組み合わせて設計する必要があります。

同期パスキーはどう動いているのか

まず「なぜ同期レイヤーが弱点になり得るのか」を理解するには、同期パスキーの内部構造を押さえる必要があります。Unit 42（Arie Olshtein）は2026年3月、GoogleのGPM同期パスキーが、デバイス内で完結する古典的なハードウェア認証器とも、単純なソフトウェア鍵とも違うハイブリッド構造であることを、Chromiumのソースコードとネットワーク挙動から明らかにしました。要点は次のとおりです。

  • クラウド認証器（Google Cloud Authenticator）：GPMのパスキー操作は、デスクトップ（Windows/macOS/Linux/ChromeOS）で enclave.ua5v[.]com というクラウド上のコンポーネントに接続して行われます。鍵の生成・署名・同期といった機微な暗号処理が、このクラウド側に置かれています。Unit 42は「世界中のログインを支えているのに、このドメインの役割を説明する公開情報がほとんど無い」と指摘しています。
  • 2種類のTPM鍵：新しいデバイスがオンボードするとき、Chromeは端末のTPMに紐づく鍵ペアを2つ作ります。Identity key（something you have＝端末の所持）と、UV key（something you know/are＝Windows Hello や PIN でユーザー検証したときだけ使える鍵）です。以後の各リクエストは、文脈に応じてどちらかの鍵で署名されます。
  • Security Domain Secret（SDS）と GPM PIN：最初のデバイスは、アカウント単位の対称マスター鍵SDS（全同期パスキーを暗号化する鍵）と、ユーザーが決める6桁のGPM PINを生成します。新しいデバイスがこの「セキュリティドメイン」へ参加する際の関門が、このGPM PIN の入力です。PINが検証されると、クラウド認証器がそのデバイス向けにSDSをラップ（暗号化）して渡し、デバイスは全パスキーを同期できるようになります。
  • 保護された通信路：Chromeとクラウド認証器の通信は、Noise Protocol（Noise_NK_P256_AESGCM_SHA256）で暗号化され、各リクエストはTPM鍵で署名されてセッションに束縛されます。クラウド側は Oak 実行環境のattestation（構成証明）署名を返しますが、Unit 42は「Chromeがこの構成証明を検証している箇所を確認できなかった」と明記しています。ここは設計上の検証点として留意すべきポイントです。

この構造の意味は、「ハードウェア鍵の強さ（TPM由来の端末バインド）」と「クラウド同期の利便性（複数デバイス・復旧）」を両立させる代わりに、SDSとGPM PINという集中点が生まれた、ということです。Unit 42自身はこの記事（Part 2）を構造解説にとどめ、「同期済みデバイスになりすまして正規のパスキー認証を得る」タイプの攻撃ベクトルは続編（Part 3）で扱うと予告しています。その集中点への攻撃を、別の研究者が実際に組み上げて公開したのが次のVaultjackingです。

同期レイヤーへの攻撃：Vaultjacking（PIN 1つで保管庫全体）

PhishUが2026年5月20日に公開した「Vaultjacking」は、WebAuthnのハンドシェイク（サイトごとのログイン層）ではなく、その下の同期層を標的にします。研究者は実際のGPMアカウントに対してエンドツーエンドで検証したと述べています。攻撃は概ね4段階です。

  1. PINを釣る：攻撃者は通常のAiTMサインイン（accounts.google.com への中間者プロキシ）でパスワードとセッションCookieを奪う流れに、「GPMの6桁PINを確認してください」という偽モーダルを1枚差し込みます。Googleの本物のPIN画面を模した見た目で、多くのユーザーは正規フローで見慣れているため入力してしまいます。PINはセッションCookieと同じ行に保存されます。
  2. 永続化のため攻撃者のパスキーを登録：キャプチャ直後、攻撃者は乗っ取ったセッションで自分の管理下のパスキーをユーザーのGoogleアカウントに登録します。これはユーザー自身が追加したパスキーと区別がつかない正規の資格情報で、パスワードリセット・Cookie失効・リフレッシュトークンのローテーション・将来のDBSC適用を生き延びます。
  3. 攻撃者インフラからセキュリティドメインに参加：Chromeのセキュリティドメイン参加は、端末のTPMに封じた鍵で enclave.ua5v[.]com に対して構成証明を行う必要があり、標準的なLinux基盤では自動化が難しい設計です。PhishUはこれを仮想TPMを備えたコンテナ化Windows VMで満たし、手順2の攻撃者パスキーでサインイン（プッシュもSMSも発火しない）→ キャプチャ済みPINをSDS解錠ダイアログに入力 → SDSが解放され、保管庫全体が攻撃者のマシンへ同期されます。
  4. 保管庫を使う：同期されたパスワードはディスクから読み出してDPAPIで復号。パスキーは、参加済みVMのChromeセッションからそのまま各サイトへ再生（リプレイ）します。

この攻撃が効いてしまう構造的な理由は3点です。

  • Googleにはクロスデバイス承認が無い：Apple iCloudキーチェーンは新しいデバイスが参加するたびに既存の全デバイスへ承認プロンプトを出しますが、Googleは出しません。Googleは復旧UX（デバイス紛失時の使い勝手）を優先し、プッシュ承認方式ではなく「6桁PIN＋サーバー側の低いリトライ上限」を選び、フィッシング可能性を許容したトレードオフとして評価した、とPhishUは説明しています。これは未パッチのバグではなく設計上の選択であり、防御側のレバーはパッチではなくポリシーと監視にあります。
  • SDSはマスター鍵であって、資格情報ごとの鍵ではない：セキュリティドメイン参加時にPINが1回通れば、ユーザーがこれまで同期してきた全パスキーが一括で解放されます。サイトごとの再試行も、Relying Partyごとのレート制限もありません。「1回のフィッシングで N 個の資格情報」です。
  • ハードウェアバウンドのパスキーも再生され得る：Chrome 148以降、アカウントバック方式のGPMパスキーは秘密鍵の生バイトをローカルに書き出さず、署名はGoogleのenclaveがサーバー側で行います。このenclave経由の署名は、参加済みデバイスであれば、元がハードウェアバックのパスキーでも成立します。つまり「ハードウェアバウンドだから安全」は同期層の参加が済んだ後には当てはまりません。

補足すべき点も2つあります。

第一に、DBSC（Device Bound Session Credentials）はAiTMを防ぎません。DBSCは盗まれたCookieを別マシンで使えなくする対策ですが、AiTMではプロキシがサーバーから見て正規クライアントとして振る舞うため、W3C仕様上そもそもAiTMの防御ではない、とPhishUは整理しています。

第二に、外部に出る唯一の兆候は「新しいパスキーを追加しました」「Windowsで新しいサインインがありました」という通知メール2通だけで、AiTMでメールボックスを掌握していれば攻撃者はこれを抑止できます。なお、同種の同期層攻撃として悪性ブラウザ拡張を使う「Browser Syncjacking」が別にありますが、Vaultjackingは端末への足場も拡張も不要で、標準的なAiTMの延長線上にある点が異なります。

「同期パスキー」はひとつではない、1Password・Keeper・Bitwardenの構造

Vaultjackingを読むと「同期パスキーは危険だ」と一般化したくなりますが、それは不正確です。Vaultjackingが突いたのはGPM固有の設計、つまりSDSというアカウント単位のマスター鍵、6桁PINという単一の関門、クロスデバイス承認の不在です。同期パスキーの安全性を決めるのは「新しいデバイスを信頼する根拠（トラストアンカー）をどこに置くか」という同期アーキテクチャであり、これはプロバイダごとに異なります

  • 1Password：従来の保管庫は「アカウントパスワード＋128ビットのSecret Key」の組み合わせで暗号化されます。Secret Keyはユーザーのデバイス上で生成されサーバーへ渡らない鍵素材で、サーバーが侵害されてもデータを復号できない設計です。パスキーで1Password自体を解錠するモードでは、サインインする各デバイスが固有のデバイスキーを生成して資格情報を暗号化し、新しいアプリ／ブラウザを追加するには既存のリンク済みアプリ／ブラウザが生成する検証コードの入力と、既存端末からのcredential bundleの転送が必要です。つまり新規参加には既存デバイスの明示的な関与が構造的に要求されます。
  • Keeper：ゼロナレッジ設計で、暗号化・復号はすべてユーザーのデバイス上で行われます。マスターパスワードからPBKDF2で導出した256ビットAES鍵で保管庫を復号し、この鍵はKeeperのサーバーへ送信・保存されません。加えて新しいデバイスはデバイス検証ステップを通過しない限りログイン試行自体ができない設計です。パスキーは保管庫レコードとして保存され、他のレコードと同様にフォルダ管理やvault-to-vault共有ができます。
  • Bitwarden：同じくゼロナレッジで、マスターパスワードからPBKDF2-SHA256でマスターキーを導出し、AES-CBC 256ビットでクライアント側暗号化します。保管庫内のパスキーはES256アルゴリズムで生成され、他の保管庫データと同じエンドツーエンド暗号化で保護されます。新規クライアントの「Log in with device」では、既存の登録済みデバイスが認証リクエストを承認し、承認側クライアントがマスターキーを暗号化して渡すフローになっています。PRF対応パスキーによる保管庫復号ログインもサポートします。

GPMとの構造的な違いを一言で言えば、「AiTMで釣れる短い秘密1つ」では保管庫に到達できないことです。

GPMの関門は6桁PIN（＋サーバー側のリトライ制限）でしたが、上記3社はいずれも、

(a) サーバーが知り得ない鍵素材（Secret Key／デバイス上で導出される鍵）か、

(b) 既存デバイスの明示的関与（検証コード・デバイス承認・デバイス検証）を要求します。

PhishUが「Googleのセキュリティドメイン／SDSに依存しない専用パスワードマネージャはVaultjackingの対象外」と指摘した根拠は、この設計差にあります。なおAppleについて補足すると、新しいデバイスがiCloudキーチェーンの同期サークルに参加する経路は「既存デバイスによるスポンサー」と「iCloudキーチェーン復旧」の2つがあります。つまりAppleにも承認プロンプトを経由しない参加経路（復旧エスクロー）は存在し、その代わりHSMクラスタが10回の試行制限（10回目の失敗でエスクローレコードを永久破棄）で守っています。「Appleは承認があるから安全、Googleは無いから危険」という単純化ではなく、「承認を経由しない経路がどう守られているか」が本質的な差です。

プロバイダ保管庫を守る鍵（トラストアンカー）新規デバイス参加の関門Vaultjacking型攻撃との関係
Google Password ManagerSDS（アカウント単位の対称マスター鍵）6桁GPM PINの入力のみ（クロスデバイス承認なし）直接の標的（前節）
Apple iCloudキーチェーン「circle of trust」各デバイスがsyncing identity（P-384鍵ペア）をデバイスのキーチェーンに保持し、同期アイテムはサークル内のデバイスだけが復号できるよう暗号化（Apple公式）(1) 既存デバイスによるスポンサー（ペアリング・承認）、または (2) iCloudキーチェーン復旧（HSMクラスタ背後のエスクロー。SRPでセキュリティコードを検証し、10回失敗でレコードを破棄）承認プロンプトが障壁。ただし承認を経由しない復旧経路も存在し、そちらはHSMの試行制限で保護
1Passwordアカウントパスワード＋Secret Key（サーバーが知らない128ビット鍵）。パスキー解錠時はデバイスごとのデバイスキー既存リンク済みアプリが生成する検証コード＋credential bundleの転送PIN1つのフィッシングでは保管庫に到達できない構造
Keeperデバイス上でPBKDF2導出される256ビットAES鍵（サーバーへ送信されない）デバイス検証ステップを通過しない限りログイン試行不可同上（ゼロナレッジ構造）
BitwardenマスターパスワードからPBKDF2-SHA256で導出されるマスターキー（クライアント側暗号化）マスターパスワード＋2段階認証。「Log in with device」は既存登録デバイスの承認が必要同上（ゼロナレッジ構造）

ただし、これを「サードパーティ製なら安全」という新しい神話にしないための注意点が3つあります。

  1. マスターパスワードは依然として集中点：保管庫のマスターパスワード自体はAiTMフィッシングの標的になり得ます。「1つ破られればN個の資格情報」という構造はSDSと同型で、集中点が消えたのではなく関門の性質が変わっただけです。保管庫自体の認証を2要素認証、できればFIDO2セキュリティキーで守ることが前提になります（Keeper・BitwardenともFIDO2キーによる2段階認証をサポートしています）。
  2. パスキー共有は「秘密鍵はデバイスから出ない」という前提を変える：Keeperのvault-to-vault共有のように、保管庫型プロバイダではパスキーを他ユーザーと共有できます。利便性の裏で、「誰がどのパスキーを誰と共有したか」という新しい統制・監査論点が生まれます。加えてFIDO AllianceはCredential Exchange（CXP／CXF）仕様の策定を進めており、プロバイダ間のパスキー移行（可搬性）も現実になりつつあります。「そのパスキーがどこに存在し得るか」は今後さらに動的になります。
  3. ブラウザ拡張・端末侵害のリスクは残る：これらのプロバイダは主にブラウザ拡張・アプリとして動作するため、端末そのものの侵害や悪性拡張（Browser Syncjacking型）への耐性は、同期アーキテクチャとは別の問題として残ります。

企業視点では、「どのプロバイダのパスキーを許可するか」をユーザー任せにせず、IdP側で技術的に強制できます。Microsoft Entra IDのパスキープロファイルは、attestation（構成証明）の要求・パスキー種別（デバイスバウンド／同期）・AAGUID制限をグループ単位で定義でき、管理者とフロントライン職員に別のポリシーを適用できます。「高リスク層はデバイスバウンドのみ、一般ユーザーは特定プロバイダの同期パスキーまで許可」という段階設計を、教育ではなくポリシーとして実装できるということです。

登録レイヤーへの攻撃：O-UNC-066「Pink」（登録フローそのものを騙す）

同期層とは別に、攻撃者が被害者の正規アカウントに自分のパスキーを登録してしまう攻撃も現実化しています。Oktaの脅威インテリジェンスは2026年7月、脅威アクターO-UNC-066（Unit 42は「Pink」と呼称）が2026年4月以降、Microsoft 365利用者のパスキー登録を標的にしていると報告しました。手口は次のように整理できます。

  • ヴィッシング＋パネル制御型キット：攻撃者は文字列「passkey」を含むドメイン（例：setpasskey[.]com、deploypasskey[.]com など）を登録し、標的に電話をかけて「新しいパスキーを登録する必要がある」と信じ込ませます。誘導先のキットは、頻用される透過型AiTMプロキシではなく、オペレーターが操作するPHP製パネルで、1秒間隔のハートビートで被害者の画面を準リアルタイムに切り替えます。オペレーターは被害者のMFA要件（TOTP／番号照合プッシュ／SMS OTP）に合わせて出す画面を都度選べます。
  • 前提：Microsoftは2026年5月、Entra IDの登録キャンペーン（サインイン時にパスキー登録をナッジする機能）がパスキーに対応してGAしました（Oktaによれば2026年5月時点で利用可能で、一部条件では既定で有効化される場合があるとされます）。攻撃者はこの善意のセキュリティ強化を、そのままヴィッシングの口実に転用しています。
  • パスキー画面は目くらまし：キットのパスキー登録ページは、実際にはパスキーを1つも登録しません。被害者に「登録している感」を与えている間に、攻撃者が被害者の正規Microsoftアカウントに自分のパスキーを直接登録します。さらに、暗号通貨アプリのシードフレーズを模した偽の復旧鍵（BIP-39フレーズ）を保存させる画面まで用意されていますが、これはEntraのパスキー登録とは無関係で、被害者を作業に集中させるための注意そらしです。
  • 正規の通知が隠れ蓑になる：パスキーが登録されるとMicrosoftから正規の通知メールが届きますが、登録したのは攻撃者であり、攻撃者はそのパスキーに無害に見える名前（被害者が選んだシードフレーズの語を借りることも）を付け、完了画面を出すタイミングも操れます。

Oktaは、この活動クラスタが食品・飲料、テクノロジー、ヘルスケア、自動車、建設、航空の各業種を標的にしていること、動機がデータ恐喝であり、Pink関連のリークサイトが2026年5月31日に公開されたことを報告しています。インフラはDDoS-Guard（AS57724, ロシア）とIQWeb FZ-LLC（AS59692, 米国）上にありました。重要な限定として、Oktaは「このキットはOktaのようなサードパーティIdPへのフェデレーションを扱わないため、Microsoftアカウントの直接侵害は観測していない」としています。ただしこれは現時点のこのキットの実装に依存する事実であり、恒久的な防御ではありません。

復旧レイヤー：最弱リンクと循環依存

3つ目のレイヤーが復旧です。ログインと登録をどれだけ固めても、紛失・機種変更時の復旧がパスワード／SMS／ヘルプデスクの口頭確認に落ちれば、そこが人で破られる迂回路になります。Microsoft Learn も、パスワードレスの一般的な課題として復旧計画を挙げ、TAP（一時アクセスパス）は時間制限付きで便利だがフィッシング耐性は無いこと、緊急用のブレークグラス（緊急アクセス）アカウントを最低2つ、条件付きアクセスとパスワードレス強制から除外して維持することを推奨しています。ここで特に危険なのが循環依存（circular dependency）です。自分のアカウントに同期されるパスキーだけで固めると、そのアカウントにサインインできないとパスキーも使えない詰み構造になり、特権管理者ほど致命的になります。

復旧レイヤーの今後の動向として、EVP（Email Verification Protocol）にも短く触れておきます。GoogleはメールOTP／マジックリンクを置き換える仕組みとして、EVPの標準化（IETF Internet-Draft＋W3C／WICG）とChromeでの実験（Origin Trial）を進めています。確認メールを送らずに、ブラウザがメールプロバイダ（issuer）へのログインセッションを利用して「メールアドレスの支配」を暗号学的に証明する仕組みで、トークンはサイトのオリジンに束縛されるため、復旧経路から「釣って転送できるOTP」が消える方向の提案です。

復旧の摩擦を大きく減らすユーザー利便性の向上は明らかで、企業がアカウント登録・復旧のUX改善として導入検討を進めるのは自然な流れでしょう。一方、設計視点では信頼の根が「メールプロバイダへのログインセッション」に集中するため、本稿で述べた集中点の議論がそのまま当てはまります。メールアカウント（issuerセッション）を掌握した攻撃者にとっては、他サービスの復旧を無摩擦で通せる増幅装置にもなり得るということです。導入を検討する際は、前提となるメールアカウント自体をフィッシング耐性MFAで守ることと、復旧イベントの監査をセットで設計してください。なお仕様は策定初期（2026年7月時点でOrigin Trial段階、Chrome以外のブラウザは未対応）であり、細部は今後変わり得ます。

なぜ情報システム・セキュリティ担当者に関係するのか（実務影響）

多くの企業がいま、条件付きアクセスやIdPで「フィッシング耐性MFA必須」を段階適用し、SMS・音声・TOTPを外してパスキーへ寄せています。SaaS側の要件強化（特権ユーザーへのフィッシング耐性MFA必須化など）も進み、パスキー展開はやる/やらないを過ぎてどう運用するかの段階に入りました。

だからこそ、攻撃面がログインから登録・同期・復旧へシフトした影響は直接的です。ログインの強度をいくら上げても、

（1）攻撃者が最初にパスキーを登録できる

（2）同期層のPIN一つで保管庫全体が抜ける

（3）復旧・再登録の本人確認が甘い

のいずれかが残れば、そこが実効的な侵入口になります。パスワードレス化の投資対効果を守るには、認証の瞬間だけでなくライフサイクル全体（登録→同期→復旧）を設計対象にする必要があります。

パスキーとFIDO2セキュリティキーはどう違うのか

FIDO Allianceの定義では、パスキーとはパスワードレスのFIDO資格情報全般を指す総称で、大きく2種類に分かれます。クレデンシャルマネージャに保存されデバイス間で同期される同期パスキー（synced passkey）と、単一のデバイスいわゆる典型的なセキュリティキーに束縛されるデバイスバウンドパスキー（device-bound passkey）です。つまり「パスキー vs FIDO2セキュリティキー」という対立ではなく、セキュリティキーに入っているのも（デバイスバウンドの）パスキーであり、正しい対立軸はsynced vs device-boundです。本稿でここまで「ハードウェアバウンド」「物理キー」と呼んできたものは、FIDO用語ではdevice-bound passkeyに当たります。

この区別を本稿の3レイヤーに重ねると、セキュリティキーの価値がどこにあるかが明確になります。

レイヤー同期パスキー（GPM／iCloud／1Password／Keeper／Bitwarden等）FIDO2セキュリティキー（デバイスバウンド）
ログインフィッシング耐性ありフィッシング耐性あり（同等）
同期攻撃面が存在（プロバイダの設計次第・前節）同期レイヤーが構造的に存在しない（秘密鍵はキーから出ない）
登録attestation非対応。デバイスの出所（provenance）を証明できないFIDOメタデータサービス経由で製造元・FIDO認定レベルを証明可能（attestation）
復旧プロバイダの復旧フローに依存（＝復旧レイヤーの攻撃面）紛失＝その鍵は復旧不能。2本以上の事前登録・別保管が前提

セキュリティキーの真価は「ログインが強い」ことではないという点です。ログイン時のフィッシング耐性は同期パスキーも同等に持っています。差が出るのは、本稿の主題である「ログインの外側」です。

  • 同期レイヤーが存在しない：秘密鍵がキーから出ない以上、Vaultjacking型の同期層攻撃の対象になりようがありません。SDSにもGPM PINにもマスターパスワードにも依存しないというのは、「設定」ではなく「構造」による防御です。
  • 登録レイヤーの統制手段（attestation）を提供する：デバイスバウンドパスキーはFIDOメタデータサービス（MDS）を通じて、認証器の製造元とFIDO認定レベルを暗号学的に証明できます。一方、同期パスキーはattestation非対応で、デバイスの出所を証明できません。Microsoft Entra IDではattestationを強制すると同期パスキーは登録から除外されます。これはO-UNC-066型攻撃（攻撃者が手元のパスキーを被害者アカウントへ登録する手口）への構造的なブロックとして機能します。被害者本人がセキュリティキーを使っていても攻撃者による登録そのものは防げませんが、RP／IdP側がattestationを要求すれば、攻撃者が任意のパスキーを登録すること自体をポリシーで弾けます。セキュリティキーの価値は「自分のログインを守る」ことに加えて、「登録レイヤーに統制をかける手段を組織に与える」ことにあります。
  • 復旧レイヤーでは弱点が反転する：セキュリティキーは紛失すればその鍵は復旧できません。だからこそ「2本以上を別保管で事前登録」が前提であり、これは復旧レイヤーの推奨（複数登録・循環依存の排除）とそのまま接続します。賃貸住宅の家の鍵管理や車の鍵管理に似ていますね。

Microsoft自身も、規制の厳しい業種や特権ユーザーにはFIDO2セキュリティキーを推奨しています。本稿の「高リスク層はデバイスバウンドへ」という対策は、PhishUの推奨とベンダー公式の推奨が一致している領域です。

よくある誤解

  • 「パスキー＝絶対に破られない」：正しくは「ログイン時のフィッシング／リプレイに強い」。登録・同期・復旧は別レイヤーで、そこは設計次第です。
  • 「同期パスキーはクラウドが暗号化しているから安全」：同期の利便性（複数デバイス・復旧・機種変更）は、鍵素材の集中点（クラウド認証器・SDS・PIN）を生み、そこが新たな標的になります。
  • 「PINは6桁でもオフライン総当たりされないから十分」：Vaultjackingは総当たりではなく、正規サインイン中の一度のPINキャプチャを悪用します。桁数の問題ではありません。
  • 「ハードウェアバウンド／セキュリティキーなら同期層攻撃も無関係」：同期パスキーとして参加が済んだ後は、enclave経由の署名でハードウェアバック鍵も再生され得ます。同期に載せない設計そのものが対策です。
  • 「DBSCやデバイスバインドのセッションで防げる」：DBSCは盗Cookieの別マシン再利用対策で、AiTMは防ぎません（プロキシが正規クライアントとして振る舞うため）。
  • 「MFA必須にしたから登録も安全」：登録フローはこれから資格情報を作る局面で、既存MFAの傘の外に置かれやすい。加えてO-UNC-066のように、電話勧誘で被害者にMFAを通過させてから登録を悪用する手口もあり、「MFAを入れた」だけでは登録段階を守れません。
  • 「これはGoogle（GPM）の話か、Microsoft（Entra）の話か、どちらか」：両方です。VaultjackingはGPM同期層、O-UNC-066はEntra登録層という別レイヤーの話で、自社が使うIdP・ブラウザ・パスワードマネージャの組み合わせごとに該当箇所が変わります。
  • 「パスキーにしたのでパスワードは即廃止してよい」：復旧経路として弱いパスワード／SMSが残れば迂回路になります。パスワードやSMSは外し方まで含めて設計が要ります。

実務で問題になりやすいポイント

パスキー展開の現場では、次のような論点が共通して見落とされがちです。

  • 同期パスキーとデバイスバウンドパスキーの混在管理：どのデバイス・どの認証器を許可するか（例：AAGUIDによる制御）を決めないまま「なんでもパスキーOK」で配ると、管理外の同期パスキーが増えます。
  • 登録の入口がゆるい：初回登録用の一時的なパスコード（TAP等）や再登録の導線が、対面・電話などの確実な本人確認とひも付いていない。
  • 復旧が最弱リンク：紛失・機種変更時の復旧が、結局はパスワードやSMS、ヘルプデスクの口頭確認に落ちる。
  • 循環依存（サーキュラー・ディペンデンシー）：自分のアカウントに同期されるパスキーだけで固めると、そのアカウントにサインインできないとパスキーも使えない、という詰み構造になります。特権管理者で特に危険です。
  • 登録イベントの監査が薄い：「新しいパスキーが追加された」「新規デバイスがセキュリティドメインに参加した」ことを検知・アラートできていないと、攻撃者による正規登録の永続化を見逃します。

対応方針：レイヤー別の設計と運用

攻撃が3レイヤーに分かれた以上、対策もレイヤーに対応させます。

登録レイヤー（enrollment）を保護する

  1. 登録を確実な本人確認に紐づける：初回・再登録はTAP等の使い捨て資格情報で行い、その配布を対面・電話など確実な経路に限定する。ただしTAP自体はフィッシング耐性が無いため、配布経路と有効期間・単回使用の設定で守る。登録直後は永続資格情報へ切り替える。
  2. 登録キャンペーンの運用を攻撃者に転用させない：Entraのパスキー登録ナッジを使う場合、社内広報で「いつ・どの画面で登録を促すか」を事前周知し、電話で急かされて登録という導線を異常として弾けるようにする。
  3. ヘルプデスク本人確認の型を決める：Oktaは、ヘルプデスクがユーザーへ連絡する際の本人確認手段を確立・周知・徹底することを推奨しています（T1566対策）。逆方向（ユーザー→ヘルプデスク）の確認手順もセットで定義します。

同期レイヤー（sync）を制御する

  1. 同期の可否と範囲を明示的に制御する：業務アカウントで同期パスキー（GPM・iCloudキーチェーン等）を許容するかを決め、必要ならIdP側で許可する認証器を絞る（AAGUID制御）。共有端末・非管理端末・外部協力会社など用途別に「同期パスキー可／デバイスバウンドのみ」を分ける。PhishUは高リスク層（管理者・IT・財務・役員・ソース管理者）には同期無し・フォールバック無しのハードウェアバウンド／デバイスバウンドのパスキーを強制することを推奨しています。
  2. 高リスク層は専用パスワードマネージャの分離も検討：PhishUは、Googleのセキュリティドメイン／SDSに依存しない専用パスワードマネージャ（1Password・Bitwarden等）は同攻撃の対象外だと指摘しています（各プロバイダの構造の違いは前述「『同期パスキー』はひとつではない」を参照）。資格情報漏えいの影響が致命的な役割では設定ではなく構造で守る選択肢です。
  3. Chromeプロファイル衛生を教育する：業務端末で個人のChromeプロファイルを使う（逆も）と、片方の同期ドメインを通じて他方の資格情報まで露出します。「1プロファイル1アカウント／個人と業務の資格情報を混在させない」を徹底します。

復旧レイヤー（recovery）を冗長化する

  1. 複数のパスワードレス手段を登録し冗長化する：Microsoftも「可能な限り複数の方法（例：PCのWindows Hello＋スマホのAuthenticatorパスキー）を登録する」ことを推奨しています。片方を失っても他方で復旧でき、循環依存を避けられます。
  2. 特権アカウントは物理キーでバックアップ：管理者・緊急用アカウントは、依存技術の少ないFIDO2セキュリティキーを別保管で最低2つ登録し、単一アカウント同期のみの構成を避ける。ブレークグラスは条件付きアクセス／パスワードレス強制から除外して維持します。
  3. 復旧経路の弱い迂回路を塞ぐ：復旧が結局パスワード／SMSに落ちていないかを洗い出し、事前登録した第2のパスキー・物理キーで代替できる設計にしてから外します。

検知・監査（MITRE ATT&CK 対応）

これらの攻撃は「正規に見える登録・参加」を悪用するため、イベント監査こそが最後の防波堤になります。通知メールだけに頼らず、以下を仕組みで拾えるようにします。

ATT&CK着目イベント具体的な監査・統制
T1098（アカウント操作／デバイス登録）新規パスキー登録・新規デバイスのセキュリティドメイン参加Google Workspaceは管理コンソールの監査ログでデバイス追加イベントを可視化し、新規管理者作成と同等にアラート化（PhishU）。Oktaは認証器（factor）ライフサイクルイベントのエンドユーザー通知と、アカウント管理ポリシー（OAMP）による認証器の追加・変更の制約を推奨（Okta）。Entra／Microsoft側は認証方法の登録を監査ログとユーザー通知で捕捉します（「新しいパスキー追加」通知はPhishU・Oktaとも言及）。
T1078（正規アカウントの悪用）見慣れない場所・端末・ASNからのサインイン／機微アプリへのアクセスネットワークゾーン（地理・ASN・IP）でサービス提供外からのアクセスを拒否。機微アプリはEndpoint管理＋EDR保護済み端末に限定（Okta）。
T1566（フィッシング／ヴィッシング）パスキーを含む新規ドメイン・登録を急かす電話強力な認証器（FIDO2・パスキー・スマートカード）を登録しポリシーでフィッシング耐性を強制。ヘルプデスク本人確認手順を確立・周知（Okta）。

加えて、突破後の兆候を拾うために、継続的アクセス評価（CAEP／Shared Signals）やITP的な仕組みで、ログイン後の異常（普段と異なる場所・端末からの操作）も監視対象にします。

対応方針の比較表

論点楽だが危うい設計推奨する設計期待する効果
パスキーの種類同期・デバイスバウンドを無制限に許可用途別に許可範囲を限定（高リスク層はデバイスバウンド／同期無しへ寄せ、非管理は同期を条件付き）管理外の鍵素材集中点を減らす
登録フロー誰でも自己登録・導線任せTAP＋確実な本人確認、登録の追加検証、登録キャンペーンの事前周知攻撃者による正規登録を防ぐ
復旧フローパスワード／SMSに落ちる事前登録した第2のパスキー・物理キーで復旧、ブレークグラス2つ以上最弱リンクと循環依存を塞ぐ
同期層の前提「クラウドが守るから安全」PIN／SDSも攻撃面と認識し、デバイス参加を監視。高リスク層は同期非依存の保管も検討同期層攻撃（Vaultjacking型）に備える
監査通知メール頼み登録・デバイス参加をSIEM/IdP/管理コンソールで検知（ATT&CK T1098）永続化の早期発見

導入・見直し時のチェックリスト

チェックリストは「これから導入する企業（設計フェーズ）」と「既に導入済みの企業（点検フェーズ）」で必要な観点が異なるため、分けて整理します。導入済みの企業も、Aの項目に未実施のものがあれば併せて確認してください。

A. これから導入する企業（設計フェーズ）

方針決定

  • 許可するパスキー種別（同期／デバイスバウンド）を役割別に決めた（高リスク層＝デバイスバウンド・同期なし）
  • 許可する認証器・プロバイダをattestation／AAGUID（Entraならパスキープロファイル）で技術的に強制する設計にした
  • 同期パスキーを許可する場合、どのプロバイダ（GPM／iCloudキーチェーン／1Password／Keeper／Bitwarden等）を許可するか、トラストアンカーの違いを踏まえて選定した
  • サードパーティ保管庫を採用する場合、保管庫自体の認証をFIDO2セキュリティキー等の2段階認証で守る設計にした
  • パスキー共有機能の可否と監査方針を決めた

登録

  • 初回・再登録をTAP等＋確実な本人確認に紐づけた（TAPはフィッシング耐性が無い前提で、配布経路・有効期間・単回使用を制限）
  • 登録キャンペーン（パスキー登録ナッジ）の時期・画面を事前周知し、「電話で急かされる登録」を異常として扱える体制にした
  • ヘルプデスク本人確認の型（ユーザー→ヘルプデスク／ヘルプデスク→ユーザーの双方向）を定義した

復旧

  • 全ユーザーに複数のパスワードレス手段の登録を必須化した
  • 特権・緊急用アカウントはFIDO2セキュリティキーを別保管で2本以上登録した（ブレークグラスは条件付きアクセス／パスワードレス強制から除外）
  • 単一アカウント同期のみによる循環依存を設計段階で排除した
  • 復旧経路がパスワード／SMS／口頭確認に落ちない道筋を先に用意した

監視・教育

  • 「新規パスキー登録」「新規デバイス参加（セキュリティドメイン join）」の検知・アラートを展開初日から有効化した（T1098）
  • Chromeプロファイル衛生（個人／業務の分離）を教育計画に組み込んだ

B. 既に導入済みの企業（点検フェーズ）

今すぐ（今週）

  • 特権・緊急用アカウントの循環依存を点検した（単一アカウント同期のみは即是正、物理キー2本以上）
  • 登録済みパスキーの棚卸しを行った：各ユーザーのアカウントに「本人が登録した覚えのないパスキー」が無いか、監査ログで確認した（O-UNC-066型の永続化の検出）
  • 「新規パスキー追加」「新規デバイス参加」の検知・アラートが実際に動作しているか確認した（通知メール頼みは不可）

今月

  • 登録済み認証器の実態を調査した：AAGUIDを集計し、想定外のプロバイダの同期パスキーが登録されていないか確認した
  • attestation／パスキープロファイル等による種別・プロバイダ強制が可能か確認し、未強制なら段階適用計画を立てた
  • 復旧経路の迂回路を点検した（復旧が結局パスワード／SMS／ヘルプデスクの口頭確認に落ちていないか）
  • 登録・復旧の依頼を電話で受けた場合のヘルプデスク手順の実効性を確認した

四半期

  • 高リスク層（管理者・IT・財務・役員・ソース管理者）のデバイスバウンド移行を計画・実施した
  • サードパーティ保管庫を利用している場合：保管庫の2段階認証の強制状況と、パスキー共有の利用実態・監査を確認した
  • GPM利用がある場合：Google Workspace管理コンソールでデバイス追加イベントをアラート化し、GPM PIN依存の範囲を把握した

継続

  • CAEP／ITP等でセッション後の異常も監視している
  • 教育を更新している（偽PINモーダル・登録ヴィッシングの手口共有、Chromeプロファイル衛生）

経営層・監査部門への説明ポイント

  • 投資の前提を守る話：「パスワードレス化＝安全」ではなく、登録・同期・復旧まで設計して初めて投資効果が出る、という位置づけで説明します。
  • リスクの言い換え：攻撃はログイン正面ではなく手続き（登録・復旧）と裏側（同期）に移っています。ここは技術ではなくプロセスと本人確認の問題であり、運用設計でリスクを下げられる、と伝えます。
  • パッチ待ちではないことの説明：Vaultjackingが突く同期層は、ベンダーが「復旧UXとのトレードオフ」として選んだ設計です。パッチを待つ話ではなく、自社のポリシーと監視で下げる課題だと位置づけます。
  • 監査観点：パスキー登録・デバイス参加の証跡が取れているか、復旧の本人確認手順が定義・記録されているかを、内部統制のチェック項目に加えます（ATT&CK T1098／T1078／T1566にマップ）。
  • 一次情報の裏付け：Unit 42（構造解析）、PhishU（同期層攻撃の実証）、Okta脅威インテリジェンス（登録層攻撃の観測）という公開一次情報を根拠に、過度に煽らず「既知の攻撃面」として説明できます。

実務担当者が次に取るべき対応ステップ

  1. 最優先（今週）：特権・緊急用アカウントの循環依存を点検し、物理キーの別保管バックアップを2つ以上に。単一同期のみは即是正。ブレークグラス2アカウントの除外設定を確認。
  2. 高（今月）：IdP／管理コンソールで「新規パスキー登録」「新規デバイス参加」を検知・通知する仕組みを有効化（T1098）。復旧経路の弱い迂回路（SMS等）を洗い出す。ヘルプデスク本人確認の型を定義。
  3. 中（四半期）：同期パスキーの許容範囲・許可認証器（AAGUID）を用途別に定義し、登録フローをTAP＋本人確認に統一。高リスク層は同期非依存の保管（専用パスワードマネージャ）も比較検討。
  4. 継続：CAEP／ITP等でログイン後の異常も監視し、登録・復旧の手順書と証跡を監査項目に組み込む。Chromeプロファイル衛生を教育に定着。

まとめ（次に取るべき行動）

パスキーは「入れれば安全な魔法のスイッチ」ではなく、正しく設計してこそ効く仕組みです。攻撃の重心はログインから登録・同期・復旧へ移りました。同期層（Vaultjacking）は設計トレードオフゆえパッチではなくポリシーと監視で、登録層（O-UNC-066）は本人確認と登録運用で、復旧層は冗長化と循環依存の排除で下げられます。まずは特権アカウントの循環依存の解消と、登録・デバイス参加の監査から着手してください。難所は「復旧の本人確認」と「同期層の可視化」です。

FAQ

Q. パスキーはフィッシングに強いのに、なぜ破られるのですか？

A. パスキーが強いのはログイン時のフィッシング／リプレイに対してです。攻撃者はそこを避け、パスキーの登録・同期・復旧という別レイヤーを狙います。

Q. Vaultjackingとは何ですか？

A. PhishUが2026年5月20日に公開したAiTM手法で、通常サインイン中にGoogle Password Managerの6桁PINを奪い、後から同期パスキー・パスワードの保管庫全体を攻撃者側で復号・複製できるとされます。PINが1回通れば保管庫全体が解放される（SDSがマスター鍵）点が核心です。

Q. これはGoogleの話ですか、Microsoftの話ですか？

A. 両方です。VaultjackingはGoogle Password Managerの同期層、O-UNC-066「Pink」はMicrosoft Entraの登録層という別レイヤーの話です。自社が使うIdP・ブラウザ・パスワードマネージャの組み合わせで、どのレイヤーが該当するかが変わります。

Q. ハードウェアバウンドのパスキーやFIDO2セキュリティキーなら安全ですか？

A. ログイン層では強力です。ただしGPMの同期パスキーとして参加が済んだ後は、Googleのenclave経由の署名でハードウェアバック鍵も再生され得ます。一方、独立したFIDO2セキュリティキー（同期に載せないデバイスバウンド運用）であれば同期レイヤー自体が構造的に存在せず、attestationにより登録レイヤーの統制手段にもなります（本文「パスキーとFIDO2セキュリティキーはどう違うのか」参照）。高リスク層ではそもそも同期に載せない設計が有効です。

Q. 1PasswordやKeeper、Bitwardenにパスキーを保存すれば安全ですか？

A. Vaultjacking型（GPMのPINとSDSを突く攻撃）の対象外ではあります。これらはサーバーが知り得ない鍵素材や既存デバイスの明示的な承認を新規参加の関門にしているためです。ただし保管庫のマスターパスワードという別の集中点は残るため、保管庫自体をFIDO2セキュリティキー等の2段階認証で守ること、パスキー共有機能の統制・監査を決めておくことが前提条件です。

Q. DBSCやデバイスバインドのセッションでVaultjackingは防げますか？

A. 防げません。DBSCは盗まれたCookieの別マシン再利用を止める対策で、AiTMではプロキシが正規クライアントとして振る舞うため、W3C仕様上そもそもAiTMの防御ではありません。

Q. 同期パスキーは使ってはいけないのですか？

A. 一律禁止ではありません。利便性（復旧・複数デバイス）と、鍵素材がクラウド（SDS・PIN）に集中するリスクを理解し、用途別に許可範囲を決めるのが現実解です。高リスク層のみ同期を外す、という段階設計が実務的です。

Q. 登録フローが狙われるとはどういうことですか？

A. 攻撃者が電話勧誘（ヴィッシング）とパネル制御型キットで被害者の正規アカウント操作を承認させ、被害者を偽の登録画面で足止めしている間に、攻撃者自身のパスキーをMicrosoftへ直接登録する手口です。O-UNC-066が2026年4月以降、Microsoft 365向けに実施していると報告されています。キットのパスキー画面は目くらましで、実際の登録は攻撃者がMicrosoftに直接行います。

Q. Chromeを使っていれば全部Vaultjackingの対象ですか？別のブラウザやセキュアブラウザなら回避できますか？

A. 対象を決めるのはブラウザではなくパスキーの保存先です。ChromeでもWindows HelloやFIDO2キーに保存していれば同期層の対象外ですし、逆にEdgeやFirefoxに変えても保存先がGPMのままなら対象は変わりません。回避したいなら変えるべきはブラウザではなく保存先です。Chrome Enterpriseやセキュアブラウザ（Island・Prisma Access Browser・Netskope・Mammoth等）は、プロファイル同期や保存先を管理下に寄せる・拡張を統制するという点で有効ですが、パスキー保存先の強制はブラウザ単体では完結せず、IdP側の登録ポリシー（attestation／AAGUID）やOS／MDMポリシーと組み合わせる必要があります。また、ユーザーの個人端末・個人Googleアカウントに載ったパスキーまでは守れず、同期を後から無効化しても既に同期済みの資格情報は残る点に注意が必要です（本文「ブラウザを変えれば回避できるのか」参照）。

Q. 社内IdPで使っているパスキーは対象ですか？

A. 同期層（Vaultjacking）については、IdP／サービス（RP）自体ではなく、そのパスキーの保存先で対象可否が決まります。 GPMに保存していれば、攻撃者はIdPのログイン画面ではなくGoogleアカウント側を狙い、Vaultjacking経由でそのパスキーも巻き込み得ます。Windows HelloやFIDO2キーに保存していれば同期層の対象外です。一方、登録層についてはIdP側の登録ポリシー、attestation／AAGUID制御、再登録本人確認の設計が影響します。まず自分の保存先を確認してください（本文「どのサービスを・どの保存先で・どのブラウザで使ったときが対象か」参照）。

Q. 攻撃を受けたかどうか、何を見れば分かりますか？

A. 「新規パスキー追加」「新規デバイス参加（セキュリティドメイン join）」のイベントです。Google Workspaceは管理コンソールの監査ログ、Entraは認証方法ライフサイクル通知、OktaはOAMPで拾えます。通知メールだけに頼らず監査ログでアラート化してください。

Q. まず何から始めればよいですか？

A. 特権・緊急用アカウントの循環依存の解消（物理キーの別保管バックアップ）と、「新規パスキー登録・新規デバイス参加」の検知から始めるのが効果的です。

Q. パスワードやSMSはすぐ廃止してよいですか？

A. 復旧経路として弱い認証が残ると迂回路になります。復旧を第2のパスキーや物理キーで代替できる設計にしてから外すのが安全です。

Q. 経営層にはどう説明すべきですか？

A. 「パスワードレス化＝完了」ではなく、登録・同期・復旧まで設計して初めて投資効果が出ると位置づけ、同期層はパッチ待ちではなくポリシーと監視の課題であること、登録・復旧の証跡を監査項目に加える旨を伝えます。

セキュリティに銀の弾丸は無いのであった

パスキー／パスワードレスは「有効化」より「登録・同期・復旧まで含めた設計」が必要です。クラウドネイティブでは、Okta・Microsoft Entra ID などを中核に、フィッシング耐性MFAの条件付きアクセス設計、同期／デバイスバウンドの許可範囲設計（AAGUID制御）、特権アカウントの冗長化、登録・復旧の本人確認プロセス、そして登録イベント・デバイス参加・セッションの監視（ATT&CK T1098／T1078／T1566）までを一気通貫で支援しています。「パスキーは入れたが運用設計はこれから」「特権アカウントの復旧設計に不安がある」という段階でも大丈夫です。自社の現状整理からご相談ください。

お問い合わせ | 株式会社クラウドネイティブ 株式会社クラウドネイティブへのお問い合わせはこちらから。製品・サービスに関するご相談、お見積り、資料請求など、お気軽にお問い合わせください。 https://cloudnative.co.jp/contact/

参考情報

タグ

この記事をシェア

Shinji Saito
Shinji Saito

代表取締役社長 / 文部科学省 最高情報セキュリティアドバイザー

株式会社クラウドネイティブ代表取締役社長であり文部科学省 最高情報セキュリティアドバイザー。日本のゼロトラスト領域の第一人者として、SaaS導入・セキュリティ対策のコンサルティングを行う。Okta、Netskope、CrowdStrikeなど30以上の製品を扱い、企業のゼロトラスト実装を支援。

関連記事

セキュリティ

Claude Tag に脆弱性レポートの CVE を自動解説させる仕組みを作った話
セキュリティ

2026年夏、なぜUSBメモリのリスクが再燃しているのか考えてみた
SaaS

自社の Okta がどのセルにあるか、3分で確認する方法
AI

誰もが稼げる課金Webサービスを作れる時代に？Cloudflare「Monetization Gateway」が示す“機械が支払うインターネット”
セキュリティ

NHIの脆弱性に組織はどう向き合うか
SaaS

Jamf Connect はまだ必要？WWDC 2026後のPlatform SSOとmacOSログイン設計を整理する