← ブログに戻る
RUENESZHARPTDEFRJAKOITTRIDVIFAHI

2026年のパスキーとマルチアカウント管理：アクセスキーでアカウントを結びつけない方法

2026年9月から、Microsoftはデフォルトでパスキーを導入し、2027年2月からはその登録を延期することができなくなります。実際にキーがどこに保存されているのか（Windows Hello、iCloud、Google、パスワードマネージャー）、なぜそれがアンチデテクトのプロファイルの隔離を突破するのか、そして「アカウント — プロファイル — ストレージ — IP」というスキームをどのように構築するかを解説します。自動化のための仮想認証器CDPも含まれます。

📅2026年9月26日
2026年のパスキーとマルチアカウント管理：アクセスキーでアカウントを結びつけない方法

2026年9月1日から、MicrosoftはEntra IDへのデフォルトのサインイン方法としてパスキーを導入し、2027年2月1日からはSMSおよび音声コードの独自配信を停止します。Googleは2023年10月に個人アカウントの主要なサインインオプションとしてパスキーを導入しました。1つのアカウントを持つ個人には便利ですが、アンチデテクトで数十のアカウントを管理する人にとって、パスキーは隔離されたプロファイルを結ぶ目立たない糸となります。以下では、これがどのように行われるか、そしてアカウント間で「漏れ」ないようにするための仕組みを構築する方法を解説します。

なぜ今この問題が浮上したのか

パスキーは2022年から存在していますが、2026年には「有効にすることができる」から「要求される」ものに変わりました。具体的な理由は3つあります：

  • Microsoft Entra ID。 2026年9月から、SMSまたは電話でのサインインを確認したユーザーには自動的にパスキーが有効化されます。次回のMFAチェック時にキーを登録する提案が表示されます。2027年1月31日までは延期できますが、2027年2月1日以降は延期できません。Microsoftは、AIを使用したフィッシングキャンペーンが54%のクリックを得ているのに対し、通常のキャンペーンは12%であるという数字を根拠に挙げています。
  • Google。 2023年10月から、個人アカウントではデフォルトで「可能な場合はパスワードの入力をスキップする」オプションが有効になっています。キーが作成されると、Googleはそれを使用してサインインすることを提案します。
  • キーのマネージャー間の移行。 FIDO AllianceはCredential Exchangeの標準（CXFおよびCXPフォーマット）を発表しました。iOS 26およびmacOS 26では、Apple Passwords、1Password、Bitwarden、Dashlaneなどのアプリ間でパスキーを暗号化された状態でファイルをエクスポートせずに転送できます。キーはもはや1つのストレージに固定されていません。マルチアカウント管理にとって、これは機会でもありリスクでもあります。

パスキーの仕組みとプロファイルの隔離を破る理由

パスキーは、公開鍵と秘密鍵のペアです。公開鍵はウェブサイトに保存され、秘密鍵は「認証者」に保存されます。鍵はドメインに結び付けられているため（仕様ではrpId）、フィッシングサイトはそれを取得できません。マルチアカウント管理における主な問題は秘密鍵が物理的にどこにあるかです。アンチデテクトはクッキー、localStorage、IndexedDB、フィンガープリンティングを隔離します。キーのストレージはしばしばブラウザプロファイルの外部にあります：

  • Windows Helloは、Windowsアカウントのレベルでキーを保存します。このアカウントの下で、どのブラウザでもどのプロファイルでも同じストレージにアクセスします。
  • macOSのiCloudキーのバンドルはApple IDに属しています。ChromeとSafariは同じMac上で同じキーセットを表示します。
  • Googleパスワードマネージャーは、ブラウザまたは電話でログインしたGoogleアカウントに結び付けられています。1つの業務用Googleアカウントが20のプロファイルに対して1つの共有セーフを持っています。
  • 拡張機能マネージャー（Bitwarden、1Passwordなど）は、アカウントのストレージにキーを保存します。すべてのプロファイルに対して1つのストレージが機能し、すべてが見える単一のポイントとして機能します。

ここから典型的な失敗が生じます。アカウント№7のプロファイルで「パスキーでサインイン」をクリックすると、システムは同じサイトでアカウント№3および№12のキーを表示します。このサイトはそのリストを見ません：選択されたキーのみを取得します。しかし、1回の誤ったクリックで、アカウント№3がアカウント№7のプロファイル、IP、およびフィンガープリンティングからサインインします。このような接続はもう取り消せません。

サイトがパスキーでのサインイン時に実際に知ること

パスキーはリスクスコアリングを無効にするわけではなく、単にパスワードの代わりになります。サインイン時、プラットフォームは依然としてIP、ブラウザのフィンガープリンティング、セッションの履歴を確認します。さらに、いくつかの独自のWebAuthn信号を受け取ります：

  • キーの識別子（credential ID）。これは「アカウント - 認証者」のペアに対して一意です。
  • AAGUID — 認証者のモデル識別子。これにより、Googleなどのサイトはアカウント設定でキーに署名します：「iCloudキーチェーンで作成」、「Googleパスワードマネージャーで作成」など。これはデバイスの一意の番号ではありませんが、プロファイルの伝説と一致する必要がある別の特性です。
  • BEおよびBSフラグ（バックアップ適格性およびバックアップ状態）は、このキーが同期されているか、デバイスに結び付けられているかを示します。

結論：Windows Helloからのキーでサインインする「モバイル」プロファイルは、ブラジルのタイムゾーンとドイツのIPを持つiPhoneのように不合理に見えます。キーはプロキシやフィンガープリンティングと同じ伝説に一致する必要があります。

ステップバイステップのスキーム：1つのアカウント — 1つのプロファイル — 1つのストレージ — 1つのIP

  1. インベントリを実施します。 アカウントにすでにパスキーがあるか、作成する提案があるサイトをリストアップします：Google、Microsoft、大手マーケットプレイス、ソーシャルネットワーク。各アカウントのセキュリティ設定では、登録されているキーの数とそれが作成された場所が表示されます。「Windows Hello」や「iCloudキーチェーン」の予期しない記録は削除候補です。
  2. 業務プロファイルのためのシステムキーの保存を無効にします。 プロファイルが動作するブラウザで、組み込みのマネージャーにパスワードやパスキーの保存を無効にします。業務用マシンでは、Windows HelloやiCloudのバンドルでキーを作成しないでください。キー作成ウィンドウが「このコンピュータ」を提案する場合は、別の方法を選択してください。
  3. 各アカウントのためのストレージを選択します。 ルールはシンプルです：ストレージはプロファイルと同様に分ける必要があります。オプション：
    • アカウントごとのパスワードマネージャーの個別ストレージ、または1人のクライアントのアカウントグループ用;
    • 最も価値のあるアカウントのためのハードウェアキー（FIDO2）;
    • 自動化のために — プログラム認証者、これについてはステップ6で説明します。
    すべてのプロファイルに対して1つのストレージを使用することは、アカウントを自分で結びつける最も一般的な方法です。
  4. 「ネイティブ」プロファイルからのみキーを登録します。 同じプロファイル、同じフィンガープリンティング、同じプロキシで固定されたセッション、通常のアカウント操作時と同じ地理的場所。キーの登録は敏感な行動であり、プラットフォームはそれを注意深く見ています。手続きの途中でIPが変更されると、追加の確認が必要になることがよくあります。プロファイルに対して1つのアドレスを保持する方法については、stickyセッションまたはプロファイルのためのプロキシのローテーションの記事で詳しく説明しました。
  5. バックアップのサインインを残します。 ストレージが失われると、アカウントが失われます。各アカウントには、別のストレージにある別のパスキー、TOTPパスワード、またはキーとは別に保存されている復旧コードが必要です。MicrosoftはEntraで、2027年2月までにユーザーをフィッシングに強い方法に移行するよう求めています。登録ウィンドウが閉じるのを待たないでください。
  6. 自動化には仮想認証者を使用します。 Chrome DevTools ProtocolにはWebAuthnドメインがあります。メソッドaddVirtualAuthenticatorは、ctap2プロトコルとinternal（プラットフォーム）またはusb/hybridのトランスポートを持つプログラム認証者を作成します。パラメータhasResidentKeyとhasUserVerificationは、認証者にキーを保存し、ユーザーを確認することを含みます。getCredentialsは登録後にキー全体を返します：credentialId、rpId、userHandle、signCount、およびPKCS#8形式の秘密鍵。次回の実行時にaddCredentialがそれを元に戻します。これにより、あなたの秘密ストレージにのみ存在し、特定のアカウントのセッションに接続されるキーが得られます。2つの注意点：ドメインは実験的としてマークされ、WebAuthnのテスト用に作成されており、エクスポートされた秘密鍵はパスワードレベルの秘密であり、それに応じて保存する必要があります。
  7. 手動ではなくCredential Exchangeを介してキーを移動します。 マネージャーを変更する場合やアカウントを異なるストレージに分散させる場合は、FIDO標準に従った組み込みのエクスポートを使用してください：Apple Passwords、1Password、Bitwarden、Dashlane、DuckDuckGo、Devolutionsでサポートされています。macOSでは、一部のアプリがこのメカニズムをまだ実装していないことに注意してください。

落とし穴

  • デフォルトの同期。 「このデバイスで作成された」キーは、すぐにiCloudまたはGoogleのクラウドに移動し、このアカウントのすべてのデバイスに表示される可能性があります。あなたの個人電話も含まれます。
  • QRによるクロスデバイスサインイン。 「電話でQRをスキャンしてください」というシナリオ（ハイブリッドトランスポート）は、実際の電話をプロファイルのセッションに接続します。業務プロファイルには余計な接続です。
  • 全ファームで同じAAGUIDは正常です。 数百万人が同じマネージャーを使用しています。同じプロバイダーが危険なのではなく、共通のキーや共通のストレージが危険です。
  • パスキーは「汚れた」サインインを治療しません。 アカウントがすでに隣接するアカウントで露出したIPや、プラットフォームが好まないデータセンターからサインインする場合、強力な暗号化は役に立ちません。リスクは信号の総合的な評価によって判断されます。
  • 第二の要素も隔離する必要があります。 バックアップのサインインがTOTPの場合、秘密はアカウントごとに分散され、個人電話の1つのアプリに保存されているわけではありません。2FAとプロキシを結びつける方法については、プロキシを介した二要素認証に関する資料で説明しました。

どのプロキシが必要で、なぜか

パスキーでのサインインには、一貫性が最も重要です：アカウントはキーを登録し、その後同じネットワーク、同じ地理的場所からサインインする必要があります。したがって：

  • アンチデテクトのウェブプロファイルには、アカウントの国で固定されたセッションを持つレジデンシャルプロキシが必要です。これは家庭のプロバイダーのアドレスであり、「普通のユーザーが自宅にいる」という伝説と一致します。
  • モバイルプラットフォームおよびモバイル伝説のアカウントには、モバイルプロキシが必要です。家庭のネットワークから国の反対側でキーを登録するモバイルプロファイルは、その履歴から外れます。
  • 各リクエストごとのローテーションはパーシングには適していますが、アカウントへのサインインには適していません。作業セッション全体に余裕を持たせた間隔を設けてください。

結論

パスキーはフィッシングに対してサインインを強化しますが、アカウント間の接続点をクッキーやパスワードからキーのストレージに移動させます。この接続点はしばしばアンチデテクトのプロファイルの外にあります：Windows Hello、iCloud、Googleアカウント、またはマネージャーの共通ストレージに。作業スキームは次のようになります：各アカウントには独自のプロファイル、独自のキーのストレージ、独自の固定IP、およびバックアップのサインイン方法があります。自動化のためにはCDPに仮想認証者があります。2027年2月までにこれに取り組んでください。Microsoftが登録の延期を停止した後は、急いで実際のアカウントで対処しなければならなくなります。