情報漏洩が日常化した時代における、個人を狙うサイバー攻撃に対する防衛術

Posted at 2026-11-02

はじめに

情報漏洩が日常化したことで、流出した情報を悪用した偽の連絡や偽サイトが、本物と見分けにくくなった。偽サイトだと気付かずにパスワードやワンタイムパスワードを入力すると、それらがその場で本物のサイトに転送され、不正ログインに使われることがある。注意して見分けるだけでは、もう被害を防ぎきれない。

連絡やサイトが本物かどうかを判断するための手がかりも、いまでは偽装できる。生成 AI を使えば、本物らしい文面も画像も声も、以前より少ない時間と手間で作れる。

これまでの手がかり	偽装できるようになった理由
相手が自分の個人情報や取引の内容を知っている	攻撃者は、流出した情報と公開情報を組み合わせれば、住所や取引の内容まで把握できる
声が知っている人のものに聞こえる	攻撃者が、家族などの声をまねた音声を使い、その人を装った電話をかけてくる
差出人や発信番号が正しい	SMS の送信元も、電話の発信番号も偽装できる
ブラウザのアドレスバーに鍵のマークが表示されている	認証局の秘密鍵が漏れると、攻撃者が、正規のものに見える偽の証明書を発行できる
本物のサイトやアプリを使っている	正規のサイトが改竄されたり、正規のアプリに悪意のある更新が配布されたりすることもある

偽物を見分けることには限界がある。そこで、企業のセキュリティで使われる「ゼロトラスト」の考え方を、個人の対策にも取り入れることを検討する。相手を無条件には信用せず、信頼できるかどうかを常に確かめ続けるという考え方である。

例えば、届いた連絡に書かれたリンクは開かず、ブックマークから正規のサイトを開く。電話も、自分で調べた番号にかける。あわせて、認証の一部を突破されても不正ログインを許さず、万が一ログインされても被害が広がらないように、どのアカウントにどの役割を持たせるかを決めておく。

本記事の姉妹編の 2 本（「AIコーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術」、「続・AIコーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術」）では、ソフトウェアサプライチェーン攻撃への対策を整理した。個々の対策が破られることを前提に複数の対策を重ねるという考え方は、本記事にも共通している。

一方で姉妹編と本記事で違うのは、誰が対策を続けるかという点だ。開発の現場なら、対策をチームのルールとして定めたり、開発環境に組み込んで自動で適用したりできる。しかし私生活では、本人や家族が自分で対策を続ける必要がある。技術に詳しくない人もいるため、手間のかかる対策は長続きしない。そのため、個人では手軽さと安全性のバランスをどこで取るかが問題になる。このバランスを取るうえで、特に重要な判断が 3 つある。

アカウントは、そのサービス自体の重要度ではなく、乗っ取りや利用停止によって、ほかのアカウントにどこまで被害が及ぶかを基準に分類する。再設定用のメールアドレスや携帯キャリアのアカウントは、重要だと意識されにくいが、被害がほかのアカウントに広がるかどうかを左右していることが多い
メールや SSO に使っているアカウントでパスワードマネージャーも使うと、管理が手軽になる。ただし、そのアカウントが停止されたり乗っ取られたりすると、保存していたパスワードやパスキーも、まとめて使えなくなったり、盗まれたりするおそれがある。どこまで 1 つのアカウントにまとめるかは、手軽さと危険の大きさを比べて決める
保管庫を開くのに必要な認証情報や機器（物理キーなど）は、保管庫とは別に管理する。認証情報を保管庫の中に保存せざるを得ないときは、攻撃者が不正に追加したパスキーや端末を、定期的に確認し見つけたら削除する

複数人で 1 つのアカウントを共有しているなど、ここで挙げた 3 つの判断どおりにアカウントを組み立てられない場合もある。そのときは、どのリスクを受け入れ、どの対策で補うかを先に決めておく。

本記事は次の順に進む。

とにかくやること: 誰もが実施すべき対策
アカウントは連鎖している: 被害が連鎖する仕組みと、本記事で使う用語
攻撃の流れと対策: 攻撃の段階ごとの脅威と対策
アカウントの組み立て方を決める 4 つの問い: 組み立て方によって対策の効果が変わる点
アカウントの組み立て方を見直す: 見直しの手順
異変に気付く方法と、被害を受けたときの対処

扱うのは、私生活で使うアカウント・決済手段・端末だ。端末は Windows・Mac・iPhone・Android・iPad、ブラウザは Chrome・Safari・Edge を想定する。なお、個別の設定手順までは扱わない。業務環境は直接の対象外だが、基本的な考え方は共通しているので、参考になる部分もある。ただし、実際の運用では勤務先のポリシーを優先する。

こんな方におすすめ

情報漏洩のニュースが続いて不安に思っているが、何から手を付ければよいか分からない
パスキーが大事だとは聞いたが、なぜ大事なのか、どこまでやれば最低限なのかを知りたい
パスキーや多要素認証を導入したものの、どこまで安全になり、どんな危険や不便さが残るのか分からない
自分や家族の乗っ取り・不正利用・詐欺の被害を、注意力ではなく仕組みで減らしたい

本記事では必要な対策を一通り説明するが、扱う範囲が広く、技術的な説明も多い。そこで、読者の知識に応じて 2 通りの読み方ができるようにしている。

技術的な仕組みに詳しい人は、攻撃の流れと 4 つの問いを通じて全体像を把握し、自分に合ったアカウントの組み立て方を決めてほしい。そうでない人は、まず「とにかくやること」に挙げた項目を実施すればよい。最低限必要な対策をまとめてある。さらに対策を強化したい場合は、仕組みや設定について AI に質問したり、詳しい人に相談したりしながら進めるとよい。

とにかくやること

次の 12 項目は、誰にとっても基本となる対策だ。アカウントをどう組み立てる場合でも実施する。上にある項目ほど優先度が高い。

パスワードを使い回さない。すべてのパスワードをパスワードマネージャーに保存し、サービスごとに異なるパスワードを生成して設定し直す。使い回していると、攻撃者が、1 つのサービスから流出したパスワードを使って、ほかのアカウントにも不正ログインできるからだ。どのパスワードマネージャーを使うか迷ったら、端末に標準で入っているものを使う。後述の「問 3」で改めて選べる
パスキーが使えるサービスでは、パスキーでログインする。パスワードや、SMS・認証アプリのコードは、偽サイトに入力すると、本物のサイトへ転送されて不正ログインに使われることがある。パスキーは本物のサイトのドメインに結び付いているため、偽サイトでは使えない。メール、Google や Apple のアカウント、パスワードマネージャー、携帯キャリアのアカウントから先に設定する
届いたリンクからログインしない。ブックマークか広告を除いた検索、公式のアプリからログインする。リンク先の画面を開いたとき、パスワードマネージャーに保存したログイン情報の自動入力の候補が表示されなければ、何も入力せずに閉じる
電話やメッセージで指示されても、認証コードを伝えたり、送金したり、アプリをインストールしたりしない。電話ならいったん切って、自分で調べた番号にかけ直す。メッセージなら返信せず、自分で調べた連絡先から確かめる。家族を名乗る連絡に備えて、家族とは合言葉を決めておく
ネットで買い物をするときは、Apple Pay が使えれば Apple Pay、使えなければ決済サービス経由のカード払いを選び、サイトにカード番号を直接入力する場面を減らす。どの方法で払う場合も、ネットで使うカードは別に用意して利用上限を下げ、Apple Pay や決済サービスにもそのカードを登録する
OS・ブラウザ・アプリの更新は、自動更新を設定し配信されたら速やかに適用する
端末のロック解除には生体認証を使い、人前でパスコードを入力しない
アプリとブラウザの拡張機能は、必要なものだけを、それぞれ OS とブラウザの公式ストアからインストールする。検索結果の広告から配布サイトを開かない
ログインや新しい端末の登録があったときに、通知が届くよう設定する。身に覚えのないログインや登録の通知が来たら、後述の「アカウントを乗っ取られたとき」の手順に従う
公衆 Wi-Fi は使わず、スマホの回線かテザリングを使う
失うと困るデータは、クラウドの同期だけに頼らず、別の場所にもバックアップを保存する。同期では、誤って消した状態や、マルウェアに暗号化された状態も、そのままほかの端末に反映される
パスワードの再設定に SMS を使う設定は、代わりの復旧手段（予備の物理キー、別の端末に保存したパスキー、紙の復旧コードのいずれか）を用意できたアカウントから無効にしていく。電話番号は、SIM の再発行で乗っ取られることがあるからだ。予備の物理キーや復旧コードを自分で管理するのが難しい人（IT 機器の操作に不慣れな家族など）は、SMS による再設定を残しておく

自分や家族のアカウントの組み立て方まで見直すなら、ここから先を読んでほしい。

アカウントは連鎖している

個人が使う複数のアカウントは、ログインやアカウント復旧の仕組みを通じて、互いにつながっている。ほかのアカウントのパスワード再設定用のメールは、登録したメールアドレスに届く。電話番号には、SMS で認証コードが届く。Google や Apple のアカウントは、「Google でログイン」のように、1 つのアカウントで複数のサービスにログインする仕組み（SSO）の起点にもなる。パスワードマネージャーには、多数のパスワードやパスキーが保存されている。

よくあるのは、1 つの Google アカウントを、メール、パスワードの保存、「Google でログイン」、ほかのサービスの再設定先のすべてに使っている例だ。このアカウントが乗っ取られると、攻撃者はメールを読めるようになる。

さらに、攻撃者は、そのメールアドレスを再設定先にしているサービスのパスワードを次々と変更できる。保存したパスワードや SSO を使って、ほかのサービスにも不正ログインできる。このアカウント自体が停止された場合も、ログインや再設定をこのアカウントに頼っている複数のサービスに、まとめてログインできなくなる。乗っ取られたアカウントは 1 つでも、被害は多数のアカウントに広がる。

この連鎖を前提にすると、守りについて次のことが言える。

アカウントで使える認証方式のうち、最も弱い方式が攻撃の突破口になる。強い方式を追加しても、弱い方式を無効にしなければ、攻撃者は弱い方式を使う
パスワードやパスキーを複数の端末で同期すると便利だが、その同期に使うアカウント（Google アカウントなど）も攻撃の対象になる
被害がアカウントの間で連鎖していることに気付けるのは、基本的には本人だけだ。企業とは異なり、個人にはアカウントの異常を監視する担当者がいない

本記事では、アカウントを次の 3 つに分類している。

Tier 1: 乗っ取りや利用停止によって、ほかのアカウントにも被害が及ぶアカウント（パスワードマネージャー、再設定先のメールアドレス、SSO 元、携帯キャリア。ソースコードやドメインを持つなら、それを公開・変更できるアカウントも）
Tier 2: 不正利用されると、金銭的な被害や、周りの人への被害が出るアカウント（金融・決済、SNS・メッセージ）
Tier 3: 被害がそのサービスの中にとどまるアカウント

用語もここで決めておく。

鍵: ログインやアカウントの復旧に使う情報や機器の総称（パスワード、パスキー、認証アプリがワンタイムパスワードを生成するのに使う秘密の値、復旧コード、物理キー）
パスワードマネージャー: パスワードやパスキーを保存し、ログインのときに自動入力するサービス（1Password、Google パスワードマネージャー、iCloud キーチェーンなど）
保管庫: パスワードマネージャーに保存した鍵の集まり。保管庫を開くと、保存した鍵をまとめて使える。一方、中身が漏れると、すべての鍵が盗まれるおそれがある
同期用のアカウント: 保管庫を端末の間で同期するのに使うアカウント（Google アカウント、Apple アカウント、1Password のアカウント）
保管庫の外にある鍵: 保管庫の中身が漏れても、それだけでは攻撃者の手に渡らない鍵。覚えているパスワード、1Password の Secret Key（アカウントパスワードとは別に要る、端末に保存される鍵）、サインイン済みの別の端末での承認、物理キー、保管庫とは別の場所に保存したパスキー、同期を無効にした認証アプリ
ログイン方式を限定する: パスワードや SMS などの認証方式を無効にし、パスキーや物理キーだけでログインできるようにすること。サービス側に設定があるときだけできる
SSO 元: 「Google でログイン」のように、ほかのサービスへのログインに使っているアカウント

攻撃の流れと対策

攻撃者が侵入する経路は多いが、最終的に狙うものは、アカウント・カード番号・データの 3 種類に大別できる。この章では、下の図の 4 段階ごとに、脅威の内容、主な対策、対策を突破されたときの対処を表にまとめる。

右端の列には、技術的な対策だけでは防ぎきれない場合に、本人の判断や注意で被害を抑える方法も含めている。仕組みで守る目的は、本人が注意して判断しなければならない場面を減らすことにある。「自動入力の候補が表示されなければ入力しない」「普段と違ってパスワードを求められたら操作をやめる」といった、少数のルールだけを守ればよい状態を目指す。

図の 3 つの狙いは、それぞれ次のように守る。

アカウント: Tier ごとに適した認証方式を選ぶ。図の攻撃経路の多くは、次の 2 つで防げる
- パスキー: 通常のフィッシングサイトだけでなく、偽の Wi-Fi から誘導された偽サイトを経由する不正ログインも防ぐ
- パスワードを使い回さない: 流出したパスワードを別のサービスで試す攻撃が成り立たなくなる
カード番号: 偽サイトに入力したカード番号は、パスキーでは守れない。サイトにカード番号を入力しない支払い方法と利用上限で守る
データ: 同期とは別のバックアップで守る

段階 1: 材料を集める

攻撃者は、まず標的に関する情報を集める。この段階で、サービスからの情報流出そのものを利用者が防ぐことは難しい。そのため、情報が流出しても、攻撃に使われにくい状態にしておく。

脅威	内容	主な対策	対策を突破されたときの対処
サービスからの流出	パスワードと、登録したメールアドレス・電話番号・住所が漏れる	パスワードを使い回さず、サービスに登録する情報を減らす	流出は防げないが、使い回していなければ、ほかのサービスには被害が広がらない
名寄せ	攻撃者が、流出したメールアドレスや電話番号を手がかりに、別の流出情報や SNS の公開情報を組み合わせ、本物らしく見える連絡を作る	サービスの重要度に応じて、登録するメールアドレスを分ける	それらしい話で連絡が来ても応じず、自分で調べた番号や連絡先から確かめる

段階 2: 侵入する

攻撃者は、集めた情報を使って、さまざまな経路からアカウントや端末への侵入を試みる。代表的な手口の 1 つが、中継型のフィッシングだ。

中継型のフィッシング（AiTM、adversary-in-the-middle）では、本人と本物のサイトの間に偽サイトを挟み、通信を中継する。偽サイトは、本物のサイトから取得したページを、その場で本人に表示する。本人が入力したパスワードや使い捨てのコードは、本物のサイトに転送される。

その結果、攻撃者は、ログインした状態を保つためのセッション Cookie を手に入れる。有効なセッション Cookie を盗まれると、多くの場合、攻撃者は 2 要素目（パスワードに加えて求められる認証）を経ずにログインできる。そのため、SMS や認証アプリのコードも、プッシュ通知による承認も、攻撃者に悪用されるおそれがある（出典: Microsoft「From cookie theft to BEC」、「Inside Tycoon2FA」）。

パスキーの場合、ブラウザは、偽サイトのドメインに対して本物のサイト用のパスキーを使わない。そのため、ログイン方式をパスキーだけに限定すれば、偽サイトを経由したログインは認証の時点で拒否される。ただし、サービス提供元の窓口でのなりすまし、アカウント復旧手続きの悪用、セッションの窃取、端末への侵入は、パスキーだけでは防げない。これらへの対策は、次の表とそれ以降の段階の表にまとめた。

脅威	内容	主な対策	対策を突破されたときの対処
使い回しの試行	流出したメールアドレスとパスワードの組み合わせを、ほかのサービスでも使えるか試す	パスワードマネージャーで、サービスごとに違うパスワードを生成して使う	ログインの通知で気付き、そのサービスのパスワードを変更する
フィッシング	偽サイトがパスワードと認証コードを本物のサイトへ中継し、ログイン後に発行されるセッション Cookie まで盗む	パスキーでログインする	ログインの通知で気付き、決済の上限で被害を抑える
フィッシング: パスキーより弱い方式への誘導	偽サイトに「パスキーが使えません」と表示し、パスワードと認証コードを入力させる	ログイン方式をパスキーだけに限定する	ログイン方式を限定していないなら、普段パスキーでログインしているサービスでパスワードを求められた時点で、入力をやめる
フィッシング: パスキーの登録を装う	「パスキーを登録しましょう」と表示し、パスキーの登録画面に進む前に、パスワードと認証コードを入力させる	リンクから開いた画面では入力しない	攻撃者が不正ログインの後に登録したパスキーを、通知や棚卸しで見つけて削除する
SIM の再発行	攻撃者が、偽造書類で店頭の担当者をだまして再発行させるか、キャリアのアカウントを乗っ取ってオンラインで eSIM を再発行する（出典: 総務省、楽天モバイル）	SMS による復旧を無効にし、キャリアのアカウントにパスキーを登録する	SIM の再発行そのものを、利用者が防ぐことは難しい。急に圏外になったら SIM の不正な再発行を疑い、キャリアに連絡して回線を停止してもらう
マルウェア・拡張機能・広告	偽のアプリ、乗っ取られた拡張機能への悪意のある更新、検索結果の広告から誘導される偽の配布サイトを通じて、端末にマルウェアを感染させる	アプリや拡張機能に与える権限を必要最小限にし、新しいアプリを試す端末を普段使いの端末と分ける	重要なサービスを使う端末やブラウザを分けていれば、侵入されたときの被害の範囲を限定できる。マルウェアに感染した疑いのある端末はネットワークから切断し、初期化する
本物のサイトやアプリの改竄	正規のサイトやアプリが改竄される。アクセス先のドメインもアプリの配布元も正規のものなので、利用者には見分けられない	利用者には防げない	不審なログインや鍵の追加に、通知と棚卸しで気付き、「アカウントを乗っ取られたとき」の手順で復旧する
偽の Wi-Fi・家のルーター	不正なアクセスポイントを設置したり、ルーターの設定を書き換えたりして、利用者を攻撃者の用意したサイトへ誘導する	公衆 Wi-Fi を使わない。偽サイトへ誘導された場合は、フィッシングと同じ対策で防ぐ。ルーターは管理画面のパスワードを初期値から変え、メーカーによる更新の提供が終わった機種は買い替える	ルーターの設定が変わっていたら、初期化して設定し直す
警察や家族などを装った連絡	攻撃者が警察・銀行・キャリア・家族などを名乗り、認証コードを聞き出したり、送金させたり、遠隔操作のアプリをインストールさせたりする	その場では応じず、自分で調べた番号や連絡先から確かめる。家族とは合言葉を決めておく	応じてしまったら、「アカウントを乗っ取られたとき」の手順に従う
紛失・盗難	パスコードを盗み見られた後に、端末を盗まれる	生体認証でロックし、人前でパスコードを入力しない	遠隔で紛失としてマークし、データを消去する

段階 3: 奪う

攻撃者は、侵入したアカウントや端末から、セッション Cookie・保管庫の中身・カード番号・データなどを盗み出す。この段階では、盗まれても悪用されにくい状態にしておくことと、盗まれた認証情報などを速やかに無効にすることが重要だ。

脅威	内容	主な対策	対策を突破されたときの対処
セッション	ログイン時に発行されたセッション Cookie を盗まれると、多くの場合、攻撃者はパスワードも 2 要素目も使わずに、ログインした状態でサービスを利用できる（出典: Microsoft「From cookie theft to BEC」）。パスキーが守るのは、ログイン時の認証まで	重要なサービスを使う端末やブラウザを、ほかの用途に使うものと分ける。使い終わったらログアウトする	全端末・全セッションからログアウトさせる
保管庫	保管庫を開いている端末に侵入されると、中に保存した鍵をまとめて盗まれる	保管庫を開く端末をほかの用途の端末と分け、使い終えたら保管庫を閉じる。保管庫を開くのに必要な認証情報を保管庫の外で管理すれば、中身を盗まれても、攻撃者はそれを使って保管庫を開き直せない	まず、保管庫を開くのに必要な認証情報（アカウントパスワードなど）を変更する。次に、保管庫に保存していたパスワードやパスキーを、Tier 1 のアカウントから順に変更する
カード番号	カード番号は特定のサイトに結び付いていないので、偽サイトで盗まれた番号は、ほかのサイトでそのまま不正に使われる	サイトにカード番号を入力しない支払い方法を選ぶ。ネット用のカードを分け、利用上限を下げる	すべての利用で通知を受け、身に覚えのない利用に気付いたらカードを停止する
データ	マルウェアによってデータを暗号化されたり、乗っ取られたアカウントから削除されたりする	同期とは別に、過去の版を残すバックアップを取る	バックアップから復元する

普段あまり意識しないが、支払い方法によって、カード番号をどこに入力するかが変わる。上から順に、使えるものを選ぶ。

Apple Pay: カード番号を入力しない。カードを登録すると、カード発行会社がその端末用の番号を発行する。支払いでは、その番号と取引ごとに異なるセキュリティコードをお店に渡し、カード発行会社がそのコードを確かめてから承認する。カード発行会社は、この番号を磁気カードや電話、Web サイトでの支払いには使えないようにできるので、お店から漏れても本物のカード番号のようには使いにくい。本物のカード番号は、お店にも Apple にも渡らない（出典: Apple Pay のセキュリティ）
決済サービス経由のカード払い: カード番号は決済サービスに登録しておき、購入先のサイトには入力しない。決済サービスのアカウントを乗っ取られると登録したカードで支払われるので、Tier 2 として守る。Chrome の Google Pay はこれに当たらない。保存したカードの番号そのものがお店に渡り、番号を隠す仮想カードの機能は米国でしか提供されていない（出典: Google Pay API、Chrome の仮想カード）
サイトにカード番号を入力する: 入力するページが偽サイトだったり改竄されていたりすれば、その場で盗まれる

どの方法で払う場合も、ネットで使うカードは日常の支払いに使うカードと分け、利用上限を下げ、利用の通知を受け取る。Apple Pay や決済サービスに登録するのも、このカードにする。

情報漏洩のニュースでは「カード番号の下 4 桁が流出」のように、漏れたものが限られることもある。カード情報の漏れ方と、漏れたときに起こり得ることは次のとおりだ。

漏れ方	漏れるもの	起こり得ること
お店が保持している一部の情報の流出	下 4 桁や有効期限など。お店は、表示や照合のために番号の一部だけを保持できる（出典: PCI SSC）	番号としては使えない。ただし、「下 4 桁が 1234 のカードで不正利用が…」のような、本物らしい連絡の材料になる
保持してはいけない情報の流出	実装の不備で意図せず保存していたカード番号（出典: クレジットカード・セキュリティガイドライン 6.1 版）。セキュリティコードは、決済の承認後に保存すること自体が禁じられている（出典: PCI SSC）	そのまま不正利用される
入力中の窃取	改竄された決済画面や入力フォームに入力した、カード番号とセキュリティコード。お店がカード番号を保持していなくても起きる（出典: IPA、EC 加盟店におけるセキュリティ対策導入ガイド）	そのまま不正利用される
偽サイトへの入力	入力したものすべて	そのまま不正利用される
漏えいのない割り出し	カード番号の採番の規則から番号を機械的に生成し、EC サイトで実際に使えるかを試す（クレジットマスター、出典: クレジットカード・セキュリティガイドライン 6.1 版）。セキュリティコードも 3〜4 桁しかないので、試せるサイトが多ければ割り出されるおそれがある。生成 AI を使えば、こうした試行を自動化する手間も小さい	どこにも入力していない番号でも使われ得る

利用者の側でできるのは、カード番号を入力する場面を減らすことと、利用の通知と上限で早く気付き、被害を抑えることだ。

段階 4: 広げる

攻撃者は、盗んだ認証情報やセッションを使って、ほかのアカウントに侵入したり、周りの人をだましたりする。被害の連鎖の起点になるアカウントを Tier 1 として重点的に守っておけば、ほかのアカウントへの侵入や周りの人へのなりすましの多くを防げる。

脅威	内容	主な対策	対策を突破されたときの対処
再設定先	メールアドレスや電話番号を乗っ取り、それを再設定先にしているアカウントのパスワードを次々に変更する	再設定先のメールアドレスを Tier 1 として守り、SMS による復旧を無効にする	乗っ取られたメールアドレスや電話番号を再設定先にしているアカウントも、「アカウントを乗っ取られたとき」の手順に従って確認する
SSO と連携	SSO 元のアカウントを乗っ取り、そのアカウントと連携しているサービスにも不正ログインする	SSO 元を Tier 1 として守り、SSO を使う範囲を絞る	SSO 経由で使っているサービスも、「アカウントを乗っ取られたとき」の手順に従って確認する
認証手段の追加	攻撃者は、不正ログインしたアカウントに自分の認証アプリなどの 2 要素目を追加し、パスワードをリセットされてもログインし続けられるようにすることがある（出典: Microsoft Security Blog 2026-01-21）。ログインできれば、攻撃者は自身のパスキーや復旧用のメールアドレスも同じように追加できる	追加そのものを防ぐのは難しいので、追加に早く気付けるようにする	通知と棚卸しで見つけて削除する
なりすまし	乗っ取った SNS やメッセージアプリから、家族や友人を狙う	家族を名乗る連絡は、自分の知っている番号や連絡先で本人に確かめる。家族とは合言葉を決めておく	周りの人に知らせる

どの段階でも使われる、利用者を操る手口

どの段階でも、攻撃者は、利用者を誘導し、利用者自身の操作で対策を回避させる手口も使う。そのため、相手から連絡を受けても、その場では指示に従わず、別の経路で事実を確認することが共通の対策になる。

脅威	内容	主な対策	対策を突破されたときの対処
急がせる	「今すぐ」「口座が止まる」などと急がせて、別の経路で確かめる時間を与えない	相手からの連絡には、その場で応じない	応じてしまったら、行った操作（コードを伝えた、送金した、アプリをインストールした）に対応する上の表の行を見て、その対処をとる
承認させる	攻撃者がログインを試み、本人の端末に届いた承認の通知を押させる	パスキーに切り替え、プッシュ通知による承認に頼らないようにする。自分が始めた操作でなければ押さない	押してしまったら、「アカウントを乗っ取られたとき」の手順に従う
気付かせない	メールの転送設定やフィルタを追加し、通知や警告を本人に届かなくする	通知を Tier 1 として守るメールアドレスで受け、復旧用のメールアドレスも棚卸しのときに確認する	メールの転送設定とフィルタを確認し、攻撃者が追加したものを削除する

利用者には防げない攻撃

利用者自身では防げない攻撃もある。こうした攻撃には、被害を小さくする備えをしておくしかない。

攻撃	自分で防げない理由	被害を小さくする手段
証明書の偽造	ブラウザやパスキーによるドメインの確認は、サイトの証明書が正規のものであることを前提にしている	OS とブラウザの更新を早めに適用する
提供元による停止	アカウントを停止されると、そのアカウントに保存した鍵やデータに、まとめてアクセスできなくなる	停止されて困るものを 1 つのアカウントにまとめず、データは提供元の外にも残す
サービス提供元によるアカウント復旧	ログイン方式を強い方式に限定しても、提供元の復旧手続きは残ることがある	復旧用の連絡先を Tier 1 の範囲に限り、通知と棚卸しで変更がないかを確認する

アカウントの組み立て方を決める 4 つの問い

ここからは、前の章の表で示した対策のうち、アカウントや端末の組み立て方によって効果が変わる部分を詳しく見ていく。問 1 では、どのアカウントが被害の連鎖の起点になるかを扱う。問 2 では認証方式を、問 3 ではパスワードマネージャーの選び方と保管庫の開け方を扱う。問 4 では、端末に侵入されたときの被害を、環境の分け方でどう限定するかを扱う。どう組み立てるのがよいかは、対策にかけられる手間によって人それぞれ違う。

1. どのアカウントが被害の連鎖の起点になるか

Tier は、アカウント自体の重要性や知名度ではなく、乗っ取りや停止によって被害がどこまで連鎖するかを基準に決める。重要性だけで分類すると、普段あまり使わない再設定用のメールアドレスや携帯キャリアのアカウントが、実際には影響が大きいにもかかわらず、低い Tier に分類されてしまう。

まず優先して対策すべきなのは、Tier 1 のアカウントだ。Tier 2・3 をどれだけ強く守っても、Tier 1 が乗っ取られ、そこから Tier 2・3 のパスワードを再設定されれば意味がない。

特に見落とされやすいのは、メールアドレスが 2 つの異なる用途で使われることだ。

普段使いのメールアドレス: ほかのサービスのパスワード再設定用のメールや通知を受け取るのに使う。多くの人は、複数のサービスの再設定先に同じメールアドレスを登録しているので、このメールアドレスは Tier 1 に分類される
復旧用のメールアドレス: 普段使いのメールアドレスやパスワードマネージャーのアカウントを取り戻すために使う、予備のメールアドレス

復旧用のメールアドレスに、家族のメールアドレスや、ほかのサービスの登録にも使っているメールアドレスを設定していると危険だ。Tier 2・3 のサービスからそのメールアドレスが流出すると、攻撃者に Tier 1 のアカウントの復旧経路を悪用されるおそれがある。そのため、復旧用のメールアドレスには、ほかの用途に使わないものを用意し、そのメールのアカウントもパスキーで守る。このアカウントを復旧するときは、普段使いのメールアドレスを使わず、紙の復旧コードか物理キーを使う。

SSO は便利だが、その分だけ危険も抱える。SSO でログインするサービスが増えるほど、SSO 元のアカウントが乗っ取られたり停止されたりしたときに、使えなくなるサービスも増える。SSO 元を Tier 1 として守ったうえで、その危険を受け入れるかを決める。

SMS を使ってアカウントを復旧できるサービスが 1 つでもあるなら、携帯キャリアのアカウントは Tier 1 に分類される。携帯キャリアのアカウントと SIM については、利用者自身にできる対策が限られる。SIM PIN を設定すれば、SIM を抜き取られて別の端末に挿されても、PIN を入力しなければ通信に使えない（出典: Apple）。

ただし、店頭やオンラインでの SIM の再発行は防げない。大手キャリアの公式情報を確認した限りでは、利用者自身が SIM の再発行や他社への転出を制限する設定も見つからなかった（2026-11 時点）。そのため、次の対策をとる。効果が大きい順に並べる。

ほかのアカウントで、SMS による再設定を無効にしていく。電話番号を奪われても、ほかのアカウントまで被害が連鎖しなくなる
キャリアのアカウントがパスキーに対応していれば、パスキーを登録する
対応していなければ、契約の暗証番号を使い回さず、ログインと手続きの通知を受け取る

2. Tier ごとにどの認証方式で守るか

Tier ごとの基本は次のとおりだ。

Tier 1 のうち、ログイン方式を限定できるアカウント: パスキーだけでログインできるように設定する。端末をすべて失っても復旧できる手段（後述）を、端末とは別の場所に用意しておく
Tier 1 のうち、ログイン方式を限定できないアカウント: パスワードを残したままパスキーを追加する
Tier 2・3: パスワードを無効にせず、パスキーを追加するだけでよい
パスキーにまだ対応していないサービス: 使い回さないパスワードを設定し、ログインの通知を有効にする

ログイン方式を限定できるかどうかは、サービスによって異なる。Google アカウントは、高度な保護機能プログラムに登録すると、ログイン方式をパスキーか物理キーだけに限定できる。物理キーがなくても、パスキーだけで登録できる（出典: Google の FAQ）。Apple アカウントには、パスキーだけに限定する設定は見当たらなかった（2026-11 時点）。物理キーを登録すると、物理キーか、サインイン済みの Apple 製品での承認が必要になるが、パスワードも引き続き要る（出典: Apple）。

認証方式の安全性は、フィッシングへの耐性によって大きく異なる（出典: NIST SP 800-63B-4）。

方式	偽サイトで悪用されるか	弱点
端末固有のパスキー（YubiKey などの物理キー、Windows Hello で端末内に保存するパスキー）	使われない	予備の登録と保管に手間がかかる
同期するパスキー（Google パスワードマネージャー、iCloud キーチェーン、1Password）	使われない	同期用のアカウントが攻撃の対象になる
認証アプリのコード	使われる（中継される）	コードの生成に使う秘密の値を同期すると、同期先のアカウントが侵害されたときに、その値も漏れるおそれがある
プッシュ通知の承認	使われる（中継される）	攻撃者のログインの承認を、本人に押させられる
SMS のコード	使われる（中継される）	SIM を不正に再発行されると、攻撃者にコードを受け取られる
パスワードだけ	使われる（入力させられる）	サービスから流出することもあり、使い回していれば、ほかのサービスでも使われる

SMS や認証アプリのコード（OTP、ワンタイムパスワード）は有効期間が短いが、利用者が画面に入力する以上、偽サイトはそのコードをその場で本物のサイトに転送できる。

パスキーがフィッシングに強いのは、ログインのときに、利用者が秘密の情報をサイトに入力する必要がないからだ。パスキーは秘密鍵と公開鍵の組で、サービスには公開鍵だけを登録し、秘密鍵は端末やパスワードマネージャー、物理キーの中に残る。ログインでは、端末が秘密鍵で署名を作ってサービスに送り、サービスは公開鍵でその署名を確かめる。

署名の元になるデータには、いま開いているサイトのドメインも含まれる。ブラウザは、いま開いているサイトのドメインに結び付いたパスキーだけを使うので、本物のサイト用のパスキーが偽サイトで使われることはない。仮に偽サイト上で署名が作られたとしても、その署名には偽サイトのドメインが含まれるため、本物のサービスは受け付けない（出典: W3C Web Authentication Level 3、passkeys.dev）。

パスワードや OTP と比べると、偽サイト以外の攻撃にも強い（出典: passkeys.dev、FIDO Alliance）。

攻撃	パスワード・OTP	パスキー
偽サイト	偽サイトに入力した値を、攻撃者が本物のサイトへ中継する	偽サイトでは、本物のサイト用の鍵で署名を作れない
サービスからの流出	漏れたパスワードで不正ログインされる。使い回していれば、ほかのサービスにも	サービスが持つのは公開鍵だけで、漏れてもログインには使えない
盗み見	盗み見た値をそのまま使われる（OTP は有効期間内に限る）	送るのはそのログインで受け取った乱数への署名だけで、次のログインには使えない
生体情報の流出	該当しない	顔や指紋は端末の中で鍵を使う許可に使うだけで、サービスには送らない

米国のサイバーセキュリティ・インフラストラクチャ安全保障庁（CISA）も、組織の IT 担当者向けの資料で、パスキーと物理キーの規格である FIDO/WebAuthn を、広く使えるフィッシング耐性のある唯一の方式としている（出典: CISA「Implementing Phishing-Resistant MFA」）。

ログイン方式の組み合わせは、大きく 3 通りに分けられる。下の表で使う 2 つの言葉の意味は次のとおりだ。

同期用のアカウントを突破される: 同期用のアカウントへのログインに加えて、新しい端末で同期済みのパスキーを使うのに要る確認（既存の端末の画面ロックや PIN、1Password なら Secret Key と 2 段階認証など）まで突破されること
保管庫の外の 2 要素目: 物理キー、または、コードのもとになる秘密の値をクラウドに同期しない設定にした認証アプリ

組み合わせ（パスキーは同期するものとする）	偽サイトに対して	同期用のアカウントを突破されたとき、または停止されたとき	向いている人
パスキーだけに限定する	強い。パスキーより弱い方式に誘導されない	同期用のアカウントを突破されると、攻撃者は同期済みのパスキーを使って不正ログインできる。同期用のアカウントを停止されても、保管庫の外にある復旧手段（後述）があればログインできる	保管庫を何で開くか（問 3）を決めており、端末をすべて失ったときの復旧手段も用意している人
パスキーを追加し、パスワードも残す	パスワードは偽サイトから中継されるおそれがある。ただし、普段パスキーでログインしているサービスでパスワードを求められれば、不審な画面だと判断できる	同期用のアカウントを突破されただけで不正ログインされる	パスワードを無効にできない人、または無効にしたくない人
パスワードと保管庫の外の 2 要素目のまま	パスワードと認証アプリのコードは中継されるおそれがある。物理キーは中継されない	同期用のアカウントを突破されても、それだけでは不正ログインできない	保管庫の外の 2 要素目を管理でき、保管庫の中身が漏れるリスクを特に重く見る人

Tier 1 では、3 つ目の組み合わせは勧めない。認証情報が偽サイト経由で盗まれると、ほかのアカウントにも被害が連鎖するためだ。Tier 2・3 では、パスキーを追加すると 2 要素目の認証が省略され、同期用のアカウントを突破されただけで不正ログインできるようになるサービスがある。実際にパスキーでログインして確かめ、省略されるなら、フィッシング耐性を優先して使い続けるか、パスキーを削除するかを決める。

ログイン方式を限定するなら、端末をすべて失ってもアカウントを復旧できる方法を、少なくとも 1 つは確保しておく。すべて失うと提供元の復旧手続きに頼ることになり、Google の高度な保護機能プログラムでは数日かかることがある（出典: Google）。

物理キー: 端末とは別の場所に保管する。Apple アカウントの物理キーは 2 本以上の登録が前提なので、1 本ずつ別の場所に保管する（出典: Apple）
紙の復旧コード: 提供元が発行するものを印刷するか書き写して保管する。それだけでログインできる鍵として扱う。Google の高度な保護機能プログラムに登録している間は取得できない（問 3）
サインイン済みの別の端末: 1 台をなくしたときには使えるが、すべての端末を失ったときには使えない

同期するパスキーと物理キーでは、本人が認証手段を持っていることの確かめ方が違う。新しい端末で同期済みのパスキーを使うときに確かめられるのは、同期用のアカウントと、既存の端末の画面ロックや PIN を知っていることだ（Google と Apple の条件は問 3 の表）。物理キーは、端末からも同期用のアカウントからも独立している。そのため本記事では、同期するパスキーは、本人が特定の機器を持っていることを、物理キーほど直接には確かめられない方式だと考える。パスキーでログインすると 2 要素目の認証を省くサービスもある（出典: Google）ので、この違いは不正ログインのリスクにも影響する。

3. 保管庫をどのサービスに預け、何で開くか

どのパスワードマネージャーを選ぶかは、鍵の管理を、メールや SSO などとどこまで同じアカウントに集めるか（一元化）で決まる。1 つのアカウントに多くの機能を集めるほど管理は手軽になるが、そのアカウントが乗っ取られたり停止されたりしたときの被害も大きくなる。

Google パスワードマネージャー・iCloud キーチェーン: OS に標準で入っていて、初期設定のままでパスキーも同期される。ただし、Google や Apple のアカウントが停止されたり乗っ取られたりすると、メールや SSO だけでなく、そこに保存した鍵にもアクセスできなくなったり、鍵を盗まれたりするおそれがある
1Password のような他社製のパスワードマネージャー: Google や Apple とは別のアカウントで鍵を管理できるので、メールや SSO に使うアカウントが停止されても、保管庫には影響しない。一方で、利用料金やアカウント管理の手間が増える

一元化によるリスクの大きさは、そのアカウントを鍵の管理以外にどれだけ多くのサービスに使っているかで変わる。用途が広いほど、関係のないサービスでのトラブルが原因で、アカウントが停止されたり乗っ取られたりする可能性が高まる。Google アカウントは、Gmail・Drive・YouTube・Google Cloud・Google 広告など、Google の多数の製品で使うため、用途が広くなりやすい。Google は、そのどれかの規約に違反した場合にアカウントを停止することがあるとしている（出典: Google、Google Drive のポリシー）。Apple アカウントは、使うサービスの種類が比較的限られる。

パスワードマネージャー	新しい端末で保管庫を開くのに必要な認証	端末のパスコードだけで保管庫を開けるかどうか	鍵をまとめて失う場合
Google パスワードマネージャー	Google アカウントへのログイン。パスキーは、既存の Android 端末の画面ロックか Google パスワードマネージャーの PIN も要る。パスワードは、オンデバイス暗号化を設定していなければ、多くの場合ログインだけで使える（出典: Google、Google）	Android は本人確認の機能を有効にすれば、信頼できる場所の外では生体認証が必要。ただし Chrome での自動入力は画面ロックの PIN でも使える（出典: Google）	Google アカウントの停止・復旧不能・乗っ取り。どれも、メールや SSO と同じアカウントで起きる
iCloud キーチェーン	Apple アカウントへのサインインと、既存の端末での承認。既存の端末がない場合は、登録した電話番号への SMS と端末のパスコード（出典: Apple）。初期設定でエンドツーエンドで暗号化される（出典: Apple）	iPhone では、「盗難デバイスの保護」を「常に」に設定すると生体認証が必要になる（出典: Apple）	Apple アカウントにアクセスできなくなった場合
1Password	アカウントパスワードと Secret Key。2 段階認証を有効にしていれば、その認証コードなども（出典: 1Password）	端末のロック解除と連動して開く設定を選べる（出典: 1Password）	アカウントパスワードを忘れ、Secret Key を確認できる手段（サインイン済みの端末、印刷した Emergency Kit）もすべて失った場合。復旧コードかファミリーの管理者による復旧があれば戻せる（出典: 1Password）

選び方の目安は次のとおりだ。

iPhone・iPad・Mac が中心なら、iCloud キーチェーンに鍵をまとめても、リスクは比較的受け入れやすい範囲に収まる。認証を強化するには、Apple アカウントに物理キーを登録する（2 本以上が前提、問 2）。既存の端末がないときの復旧には SMS が使われるので、電話番号と携帯キャリアのアカウントも Tier 1 として扱う
Android で、すべての鍵を Google パスワードマネージャーに集めるのは勧めにくい。選択肢は 3 つある
- 普段使いの Google アカウントのまま使う: 管理の手間が最も少ない。携帯キャリアや復旧用のメールアドレスなど、ほかの Tier 1 の鍵は、Google パスワードマネージャーの外にも保管する。高度な保護機能プログラムでログイン方式を限定するのは、物理キーを用意できる場合に限る。登録中は紙の復旧コードを取得できず（出典: Google）、同期したパスキーだけで登録すると、端末をすべて失ったときに手元に残る復旧手段がないためだ
- Google パスワードマネージャー専用の Google アカウントを作る: 用途の広い普段使いのアカウントと、保管庫を管理するアカウントを分けられる
- 他社製のパスワードマネージャーを使う: Google アカウントの用途の広さによるリスクを、最も小さくできる
OS を問わず、特定のアカウントへの依存を最小限にしたいなら、他社製のパスワードマネージャーを使う。その代わり、利用料金と管理の手間を受け入れる

選んだら、保管庫を開くのに必要な認証情報を保管庫の外で管理する。中に保存していると、端末に侵入されたときに中身と一緒に盗まれ、攻撃者が自分の端末から保管庫を開けるようになるおそれがある。端末をすべて失ったときに、自分でも開けなくなる。

1Password: アカウントパスワードは保管庫に保存せず覚えておき、2 段階認証のコードは別の認証アプリで管理する。1Password も、2 段階認証のコードを同じ保管庫に保存することは「金庫の鍵を金庫に入れるようなもの」だとしている（出典: 1Password）
iCloud キーチェーン: Apple アカウントのパスワードを覚えていて、キーチェーンに保存していなければ、外で管理できている
Android の Google パスワードマネージャー: Android で作ったパスキーは多くの場合 Google パスワードマネージャーに保存されるので（出典: Google）、Google アカウント自身のパスキーも保管庫の中に入ることがある。外に出すには、他社製のパスワードマネージャーへの移行か物理キーが要り、手間が大きい。そのため、これは受け入れ、不審なパスキーや端末が追加されていないかを定期的な棚卸しで確認する

人前でパスコードを入力する機会がある場合や、家族とパスコードを共有している場合は、表の「端末のパスコードだけで保管庫を開けるかどうか」を見て、パスコードだけでは開けない設定にする。できなければ、人前でパスコードを入力しないことと、生体認証による端末のロックで補う。

4. 端末に侵入されたときの被害をどう限定するか

マルウェアなどによる端末への侵入を、完全に防ぐことは難しい。端末に侵入されると、ログイン中のセッションを盗まれるおそれがある。保管庫を開いていれば、中に保存した鍵もまとめて盗まれ得る。どのパスワードマネージャーを選んでも、このリスクは残る。対策は大きく 2 つある。

不正なプログラムを取り込むおそれのある操作（アプリのインストールやリンクを開くことなど）をする環境と、重要なサービスを使う環境を分け、使い終わったらログアウトする。侵入されたときの被害を限定できる
アプリや拡張機能に与える権限を絞り、侵入されにくくする

端末への侵入は、脆弱性を外部から直接攻撃される場合よりも、利用者自身の操作をきっかけに起きる場合が多い。たとえば、アプリや拡張機能のインストール、検索結果の広告や届いたリンクからのアクセス、第三者の指示によるアプリのインストールなどだ。正規のアプリに悪意のある更新が配布されることもある。利用者が自分でインストールしたアプリや拡張機能を通じて悪意のあるコードが入り込む点は、ソフトウェアサプライチェーン攻撃と共通している。こうした操作を完全に避けることは難しいので、環境を分けておく。

環境を分ける方法には、分離の強さに応じていくつかの段階がある。強い順に並べる。3 と 4 は、同じユーザーに侵入したマルウェアによる被害は防げない。

専用の端末: 銀行・証券などの利用や Tier 1 のアカウントの管理に、専用の端末を使う
別の OS のユーザー: Mac や Windows で、銀行・証券などに使うユーザーを別に作る。ファイルやアプリのログイン状態もユーザーごとに分かれる。普段使いのユーザーを管理者権限なしで使うことが前提になる。Windows の管理者はすべてのファイルにアクセスできるので（出典: Microsoft）、普段使いのユーザーが管理者だと、分けた意味が薄れる。iPhone・iPad では、個人で使う場合はユーザーを分けられない（複数のユーザーで使える「共有 iPad」は組織向けの機能。出典: Apple）
別のブラウザ: 同じ端末でも、別のブラウザを使い分ければ、それぞれの拡張機能や閲覧履歴を分けられる。たとえば、Windows なら Edge と Chrome、Mac なら Safari と Chrome を使い分ける
同じブラウザの別のプロファイル: 同じブラウザの中で、プロファイルを切り替えて使い分ける。別のブラウザを使い分ける方法よりも、いまどちらの環境を使っているかを間違えやすい

新しいアプリやツールは、重要なアカウントの認証情報を保存していない端末で試す。

使い終わった後の処理も、被害を抑えるのに有効だ。

一時的にしか使わないサイトは、プライベートブラウジングで開く。ウィンドウを閉じると、Cookie や閲覧履歴が端末に残りにくくなる（出典: Chrome のシークレットモード）。ただし、ダウンロードしたファイルやサービス側の記録は残り、マルウェアへの感染を防ぐ効果もない
重要なサービスを使う環境では、使い終わったらログアウトする
OS やブラウザで Google や Apple のアカウントに常にサインインしている場合は、端末のロックを徹底し、定期的な棚卸しで不審な端末や設定がないかを確認する

端末への侵入を防ぎ、侵入された後の被害を抑えるうえで特に重要なのは、拡張機能の権限を絞ることだ。すべてのサイトのデータを読み書きできる拡張機能が乗っ取られると、各サイトのページやセッションにアクセスされるおそれがある。開発元が買収されたり、悪意のある更新が配布されたりすることを、利用者自身が防ぐのは難しい。そのため、次のように設定する。

拡張機能がサイトのデータにアクセスできる範囲は、「拡張機能をクリックしたときだけ」か「特定のサイトだけ」に制限する
パスワードマネージャーだけは、すべてのサイトへのアクセスを許可しておく。正規のサイトのはずなのに自動入力の候補が表示されなければ、偽サイトの可能性があると判断できるからだ
広告を経由した偽サイトへの誘導に備え、ブラウザ内蔵のトラッキング防止機能の設定を強める
広告ブロックの拡張機能を追加する場合は、すべてのサイトのデータを読み取ったり変更したりする権限を求めないものを選ぶ

アカウントの組み立て方を見直す

「とにかくやること」まで実施すれば、誰にとっても最低限必要な対策はできる。ただし、パスワードを Google パスワードマネージャーにまとめている場合は、まず「なくすべき構成」の表の 1 行目を確認してほしい。アカウントの組み立て方まで見直す場合は、共通する 3 つの基本から押さえる。家族のアカウントも見直す場合は、どのリスクを受け入れ、どの対策で補うかを決める。余力があれば、さらに対策を追加する。

誰もが押さえる 3 つの基本

Tier 1 のアカウントを特定する
次の表に挙げた構成をなくす。いずれも、1 つのアカウントや端末の侵害・停止によって、複数のアカウントに被害が及ぶものだ。なくせない場合の対策は、「代わりに」の列に示した
通知は、Tier 1 として守っている普段使いのメールアドレスで受け取る。通知では分からない登録内容や設定の変化は、定期的な棚卸しで確認する（詳しくは後述の「異変に気付く方法と、被害を受けたときの対処」）

なくすべき構成	理由	代わりに
1 つの Google アカウントでメール・SSO・Drive を使い、ほかの Tier 1 の鍵も Google パスワードマネージャーだけに保存する	鍵の管理と関係のない用途がきっかけで停止や乗っ取りが起きると、保管庫の鍵もまとめて失うおそれがある（問 3）	携帯キャリアや復旧用のメールアドレスなど、ほかの Tier 1 の鍵は、紙などに控えて、保管庫の外にも残しておく。パスワードマネージャーを分ける選び方は、問 3 の目安を参照
Tier 1 のアカウントを、偽サイトで中継されるおそれのある認証方式（パスワードと認証コード、プッシュ通知、SMS）だけで守る	認証情報を中継されてアカウントを乗っ取られると、ほかのアカウントにも被害が連鎖する	パスキーか物理キーを登録する。さらに、ログイン方式を限定でき、端末をすべて失ったときの復旧手段も用意できるアカウントでは、ログイン方式を限定する
保管庫を開くのに必要な認証情報を、その保管庫の中に保存する	保管庫を開いた状態で端末に侵入されると、この認証情報まで盗まれ、攻撃者が再び保管庫を開けるようになるおそれがある。端末をすべて失うと、自分でも保管庫を開けなくなる	保管庫の外で管理する。外で管理する手間が大きい場合の扱いは問 3 を参照
Tier 1 のアカウントを復旧するためのメールアドレスを、ほかのサービスの登録にも使う	Tier 2・3 のサービスからそのメールアドレスが漏れると、攻撃者に Tier 1 の復旧経路を悪用されるおそれがある	ほかの用途に使わない、復旧専用のメールアドレスに変える
すべてのサイトのデータを読み書きできる権限を持つ拡張機能を常用する	拡張機能が 1 つ乗っ取られるだけで、使っているサイト全体に被害が及ぶおそれがある	パスワードマネージャー以外は、権限を絞るか、インストールしない

家族のアカウントで、基本どおりにできないとき

IT 機器の操作に不慣れな家族のアカウントは、上の 3 つの基本どおりに組み立てられないことが多い。ここでは、その場合に何を受け入れ、何で補うかを決める。

よくあるのは、1 つの Google アカウントや Apple アカウントに、メール、パスワードの保存、ほかのサービスへのログインを集めている状態だ。用途ごとにアカウントを分けたり、物理キーや紙の復旧コードを管理したりするよう勧めても、続かないことが多い。その場合は、次の 2 つを受け入れる。

1 つのアカウントへの依存: 上の表の 1 行目の構成が残る。そのアカウントが停止されたり乗っ取られたりすると、保存した鍵もまとめて使えなくなったり盗まれたりする
SMS による復旧: 本人が自分で使える復旧手段は、自分の電話番号に届く SMS しかないので、無効にしない。そのぶん、電話番号を奪われると、アカウントも乗っ取られるおそれがある

そのぶん、次の対策で補う。詳しい家族は設定と確認を手伝うだけにし、物理キーや紙の復旧コードを預かって代わりに復旧することはしない。

そのアカウントはパスキーで守る。復旧用の電話番号とメールアドレスには、本人がいまも使っている連絡先を登録しておく
携帯キャリアのアカウントの認証を強化する。急に圏外になったら SIM の不正な再発行を疑い、すぐキャリアに連絡するよう家族と決めておく
電話やメッセージで何かを指示されたら、その場では応じず、知っている番号や連絡先で確かめることを、家族と決めておく
ログインや新しい端末の登録の通知が、本人に届くように設定する。詳しい家族が本人と一緒に、登録済みのパスキーとログイン中の端末をときどき確認する

余力があれば追加する対策

ここから先の対策は、導入と運用にかかる手間と、得られる効果を比べて選ぶ。表の上にある対策ほど、より広い範囲のリスクを減らせる。

追加の対策	得られる効果	引き受ける手間
Tier 1 のうちログイン方式を限定できるアカウントは物理キーだけに限定し、Apple アカウントには物理キーを登録する	保管庫の中身が漏れても、Tier 1 のアカウントへの不正ログインを防ぎやすくなる。ログインのときに、本人が物理キーを実際に持っていることも確かめられる	予備の鍵の管理
保管庫に保存した鍵を他社製のパスワードマネージャーに移し、Google や Apple のアカウントは物理キーで守る	Google や Apple のアカウントが停止されても、他社製のパスワードマネージャーに保存した鍵は使い続けられる（そのアカウントを再設定先にしていたサービスは、別に復旧する）。Apple アカウントに鍵をまとめている人も、特定のアカウントへの依存を最小限にできる	利用料金と、物理キーの管理
端末のパスコードだけでは保管庫を開けない設定にする	端末のパスコードを知られても、保管庫を開かれずに済む	パスワードマネージャーや設定を選ぶ手間
Tier 2 のアカウントで、パスキー以外のログイン方式を無効にする	パスキーより弱い方式へ誘導する攻撃を防げる	同期用のアカウントを突破されると不正ログインされる危険を引き受ける
銀行・証券などの利用に専用の端末を使う	普段使いの端末が乗っ取られても、銀行・証券などのアカウントへの被害を防ぎやすくなる	端末を 1 台増やす
サービスの重要度に応じて、普段使いのメールアドレスも使い分ける	メールアドレスを手がかりにした名寄せや、Tier 2・3 のサービスから漏れたメールアドレスを使ったパスワードの再設定を防ぎやすくなる	複数のメールアドレスと、それぞれの認証情報を管理する手間

異変に気付く方法と、被害を受けたときの対処

通知と棚卸しで異変に気付く

個人にはアカウントを監視する担当者がいない。そのため、不審な操作に自分で気付けるよう、通知を設定しておく。ただし、通知の有無や送信先はサービスによって異なり、すべての異常が通知されるとは限らない。通知だけに頼らず、定期的な棚卸しでも登録内容や設定の変化を確認する。

通知を設定する対象: アカウントへのログイン、新しい端末の登録、パスキーや物理キーの追加、復旧用の連絡先の変更、出金先の変更、カードの利用（少額も含む全件）。通知先を選べるものは、Tier 1 として守っている普段使いのメールアドレスにする
棚卸し: 登録済みのパスキーや物理キー、ログイン中の端末、連携済みのアプリを確認し、身に覚えのないものは削除する。月に一度に加え、新しい端末やパスキーを登録した後にも確認する
復旧用のメールアドレス: 普段使いのメールアドレス（Gmail など）が乗っ取られると、そこに届く通知を攻撃者に削除されるおそれがある。そのため、ほかの用途に使わない復旧用のメールのアカウントにも、棚卸しのときにログインし、不審な設定や通知がないかを確認する。Google のように、不審な動きを復旧用のメールアドレスに知らせるサービスもある（出典: Google）
身の回りの異変: スマホが急に圏外になる（SIM が不正に再発行された兆候）、身に覚えのない転居届についての確認書が届く

アカウントを乗っ取られたとき

身に覚えのない引き落としがあったときや、偽サイトにカード番号を入力したときは、何よりも先にカード会社や金融機関に連絡し、決済を止めてもらう。言われるままに送金してしまったときも、すぐに金融機関に連絡する。連絡先は、カードの裏面か、自分で開いた公式サイトで調べる。

そのうえで、次の点に気を付けて、下の 1〜6 の順に復旧する。

侵入された疑いのない端末から作業する。侵入された疑いのある端末で作業すると、新しく設定したパスワードなども盗まれるおそれがある
手元にそうした端末がなければ、家族や詳しい人から端末を借り、まず Tier 1 のアカウントを復旧する。借りた端末では、ブラウザに認証情報を保存せず、作業が終わったら必ずログアウトする
侵入された疑いのある端末は、ネットワークから切断する。初期化は、アカウントの復旧とパスワードの変更が終わってから行う。初期化する端末にしか保存されていない鍵は失われるので、予備の鍵や復旧コードで実際にログインできることを先に確かめる

アカウントを取り戻す: 予備の物理キーやパスキー、復旧コードを使ってログインする。それでログインできない場合は、登録してある電話番号やメールアドレスでパスワードを再設定する。それでもログインできなければ、サービス提供元の復旧手続きを利用する。復旧用の連絡先を Tier 1 として守っておくのは、この復旧手続きを安全に進めるためだ
攻撃者を締め出す: パスワードを変更するだけでは不十分だ。中継型のフィッシングでは、パスワードだけでなくセッション Cookie も盗まれるので、すべての端末からログアウトさせ、発行済みのセッションを無効にする（出典: Microsoft Security Blog 2026-01-21）。保管庫に保存していた鍵が漏れた疑いがあれば、保管庫を開くのに必要な認証情報も変更する
追加された認証手段を削除する: 攻撃者が不正に追加したパスキーや物理キーを削除し、認証アプリの登録を解除し、復旧用の連絡先も削除する
追加された設定を削除する: 攻撃者が不正に追加したメールの転送設定やフィルタを削除し、不審なアプリとの連携を解除する。身に覚えのない振込先の登録も削除する
被害の連鎖を止める: 乗っ取られたアカウントが、ほかのサービスの再設定先や SSO 元として使われていた場合は、それらのサービスについても手順 2〜4 に従って確認する
記録して知らせる: ログイン履歴や操作履歴を保存し、金融機関への報告や被害の届け出に使う。自分になりすました投稿やメッセージがあれば、周りの人に知らせる

端末をなくしたとき

遠隔で紛失としてマークし、キャリアに回線を止めてもらう
端末が盗まれ、パスコードも知られた可能性がある場合は、上の「アカウントを乗っ取られたとき」の手順も並行して進める
端末を取り戻せない場合は、遠隔でデータを消去する
各サービスのログイン中の端末の一覧から、なくした端末を削除する
なくした端末にしか保存していなかった鍵（同期を無効にした認証アプリなど）は、予備の鍵でログインした後、新しい端末に登録し直す。すべての端末を失ったなら、保管しておいた物理キーか紙の復旧コードを使って復旧する。どちらも用意していなければ、提供元のアカウント復旧の手続きに進む

おわりに

本記事では、偽物を見分ける注意力に頼らず、アカウントの組み立て方で被害を抑える方法を扱った。ただし、いまの仕組みのままでは、物理キーの予備や紙の復旧コードの管理といった手間を、利用者が引き受けることになる。技術に詳しくない家族にまで、それを求めるのは難しい。

同期するパスキーは、同期用のアカウントと既存の端末の画面ロックを突破されると使われてしまう点で、物理キーより弱いと考える。サービスや OS の提供者には、フィッシング対策にはパスキーを使い、2 要素目には同期しない認証アプリのコードを使う仕組みを実現してほしい。偽サイトでは本物のサイト用のパスキーを使えないので、コードを中継されても不正ログインは成立しない。同期用のアカウントを突破されても、手元の端末にしかないコードがなければログインできない。物理キーを持ち歩く必要もないため、より多くの人が使いやすくなる。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up