2段階認証でフィッシングを完全に防ぎきれない理由
AiTMフィッシングによる認証情報のリアルタイム窃取
フィッシングは、偽のログイン画面にパスワードを入力させる攻撃だけではありません。利用者と正規のサービスの間に攻撃者が入り、入力内容をリアルタイムで中継する「AiTM(Adversary-in-the-Middle)フィッシング」という手法があります。
AiTMフィッシングは、偽のログイン画面を通じて、利用者と正規サービスの通信をリアルタイムで中継します。利用者が入力したパスワードや確認コードを正規サービスへ中継し、認証後に発行されるセッションCookieを盗むことで、ログイン済みの状態を悪用する攻撃です。

独立行政法人情報処理推進機構(IPA)が公開する「情報セキュリティ白書2024」は、主に2023年の動向をまとめた内容ですが、Microsoft 365やGoogle Workspaceなどのクラウドサービスでは多要素認証の活用が重要だとしたうえで、多要素認証を設定していても、AiTMフィッシングによって認証を突破される被害が確認されていると記載しています。つまり、パスワードに続いて入力した確認コードも攻撃者に利用される可能性があるということです。
例えば、利用者が偽サイトにパスワードを入力すると、攻撃者がその情報を正規のログイン画面に送ります。続いて利用者が確認コードを入力すると、そのコードも中継され、認証が成立してしまうという流れです。コードの有効期間が短くても、その場で使われれば防御にはなりません。
スマートフォンに届く通知を承認する方式についても、リアルタイムの中継攻撃に対する限界があります。つまり、確認の手順を増やすことがフィッシングの被害を完全に抑えることにはつながりません。
2段階認証をやめるという意味ではない
ここまで読むと、2段階認証は役に立たないのかと感じるかもしれませんが、そうではありません。パスワードだけで利用する状態に比べて、追加の本人確認は重要な防御になります。そのうえで、企業ではフィッシングに強い方式への移行を目指すことが重要です。私は、2段階認証の導入をセキュリティ対策の到達点にするのではなく、認証方式を見直すための出発点として捉えることが重要だと考えています。
パスキーとセキュリティキーは何が違うのか
パスキーは認証情報
パスキーは、FIDOの標準仕様に基づく認証情報です。スマートフォンやパソコン、ハードウェアセキュリティキーに保存でき、指紋認証、顔認証、PINなど、デバイスのロックを解除する操作を使ってログインします。公開鍵暗号を利用した、フィッシングに強い認証方式です。
身近な言葉でいうと、パスキーは「パスワードの代わりに使うデジタルな鍵」です。利用者がパスワードを覚えて入力する代わりに、スマートフォンやパソコンが鍵を使ってログインの手続きを行います。
この仕組みでは、対になる「秘密鍵」と「公開鍵」を使います。秘密鍵は利用者側で保管し、公開鍵はログイン先のサービスに登録します。ログインするときは、秘密鍵で「このアカウントの持ち主であることを示す証拠」を作り、サービスが公開鍵でその証拠を確認します。秘密鍵そのものをログイン先に送る必要はありません。これが「公開鍵認証」です。

指紋認証、顔認証、PINは、利用者がこの鍵を使うことを許可するための確認です。指紋や顔の情報、PINがログイン先に送られるわけではありません。
また、パスキーは登録した正規のサイトで使うように設計されています。見た目がそっくりな偽サイトに誘導されても、そのサイトでは使えないため、パスワードをだまし取るようなフィッシングに強いという特徴があります。
パスワードを入力しなくても本人確認は行われる
Google Workspaceでは、管理者が許可した場合、パスキーを使ってパスワード入力を省略できます。このとき、パスキーが第1・第2の認証要素を担うため、パスワードと確認コードを順番に入力する必要がなくなります。指紋や顔認証に使用する生体情報は、デバイスから外部に共有されません。
画面上の操作が少なくなると、認証が簡略化されて不安に感じる方もいると思います。ただ、セキュリティを評価する際に重要なのは、入力画面の数ではありません。どのような仕組みで本人を確認し、どの攻撃に対応できるかです。パスキーの導入では、この違いを社員にも説明しておく必要があります。
Google Workspaceで管理者が押さえたい設定
2段階認証の必須化と、許可する方式を確認する
2段階認証は、管理コンソールの[セキュリティ]→[認証]→[2段階認証プロセス]から設定します。組織部門や設定グループを対象に、必須化と利用可能な方式を指定できます。

方式には、すべてを許可する設定、SMS・音声通話による確認コードを除外する設定、セキュリティキーのみに制限する設定があります。ただし、現在の[セキュリティキーのみ]では、セキュリティキーに加えてパスキーも2段階認証の方式として許可されます。この設定だけで物理キーに限定できるわけではありません。

「すべて」の設定は、SMS・音声通話の確認コード、Googleからのメッセージ、認証アプリ、セキュリティキー、パスキーなど、あらゆる方式を許可する設定です。
企業としては、まずフィッシングに強い認証を必須にしたいのか、それに加えて認証情報の保存先も物理キーに限定したいのかを決める必要があります。設定名だけで判断せず、実際に許可される認証手段まで確認することが重要です。
パスワードの省略と、パスキーの保存先を別々に管理する
パスキーによるパスワード入力の省略は、[セキュリティ]→[認証]→[パスワードレス]で設定します。管理者側の許可に加えて、利用者側でもパスキーの登録とパスワード省略の設定が必要です。

また、同じ管理領域には、パスキーをハードウェアセキュリティキーに限定する設定があります。有効にすると、スマートフォンやパソコンなどに保存されたパスキーは利用できなくなります。

今回は、セキュリティキーではなく、利用者自身がデバイスでパスキーを作れるようにするため、「すべてのデバイスまたはプラットフォームでパスキーを許可します」にチェックを入れます。
企業で導入する際の進め方
管理者や重要な情報を扱う社員から始める
導入を進める際は、管理者アカウントや機密情報を扱う社員を優先することが重要です。メールやファイル保管などの業務システムを対象に、利用可能な方式の中から強い認証を選ぶことが基本になります。
そのうえで、私は少人数での試行を通じて、日常業務に必要な操作を確認する進め方がよいと考えています。通常のログインだけでなく、別のパソコンを使う場合、スマートフォンを使えない場合、キーを持ち忘れた場合まで確認すると、全社展開前に運用上の課題を整理できます。
物理キーを配布する場合も、購入して渡すだけでは導入は完了しません。登録方法、普段の使い方、利用できないときの連絡先までを一つの手順として用意することが大切です。
登録と動作確認を済ませてから必須化する
利用者が準備できていない状態で認証方式を制限すると、業務用アカウントにログインできなくなる可能性があります。導入前には、利用目的、対象となる認証方式、登録期限を周知し、登録状況を確認する手順が必要です。
パスキーを登録する場合は、対象の業務用アカウントで[パスキーとセキュリティキー]の設定画面を開き、画面の指示に従って作成します。

なお、2段階認証専用のセキュリティキーとして登録する場合は、パスキーとして登録する場合と手順が異なります。管理者による登録も可能ですが、そのキーを使うログインではパスワードが必要です。詳しくはGoogleの公式サイトをご確認ください。
導入後に見落としたくない運用上の注意点
共有端末へのパスキー登録を避ける
パスキーを登録したデバイスでは、その画面ロックを解除できる人であれば誰でもアカウントへアクセス可能になります。そのため、共有デバイスにパスキーを登録することは避ける必要があります。アカウントからログアウトするだけでは、登録したパスキーは削除されません。
この性質を踏まえると、企業では登録を許可する端末の範囲と、画面ロックの管理を併せて考える必要があります。特に、複数人で使うパソコンと個人に割り当てたパソコンでは、登録ルールを分けて整理することをお勧めします。
紛失時の復旧手順も認証設計の一部になる
キーや端末を紛失した場合に備えて、代替の認証手段を準備することが案内されています。企業運用では、予備キーの登録や、管理者へ連絡して復旧する手順を検討しておくとよいでしょう。
管理者は、利用者に登録されたパスキーやセキュリティキーを削除できます。また、セキュリティキーのみを必須にする運用では、管理者が発行したバックアップ確認コードを使うための猶予期間を設定できます。
私は、復旧時の本人確認も、通常のログインと同じくらい重要だと考えています。誰が依頼を受け、どのように本人と確認し、いつ元の認証方式に戻すかまで決めておくことが、継続的な運用につながります。
パスキーを登録しても、既存の認証方法は消えない
パスキーを登録しても、それまでの認証要素やアカウント復元のための情報は、自動的に削除されません。パスキーを登録したことと、利用可能なログイン経路を制限したことは別です。
したがって、導入後も管理者側の認証ポリシーを確認する必要があります。新しい方式の登録を進めるだけでなく、組織としてどの方式を許可するかを明確にしておきましょう。
パスキーでも、ログイン後の安全まで保証されるわけではない
最後に押さえておきたいのが、セッション情報の窃取です。ブラウザには、ログイン済みの状態を維持するためのCookieが保存されます。端末がマルウェアに感染し、こうした情報が盗まれると、攻撃者がパスワードを知らなくてもアカウントへアクセスできる場合があります。
パスキーやセキュリティキーは認証を強くする手段ですが、端末の安全性まで保証するものではありません。2026年には、認証した端末にセッションを結び付けるDBSCが、Windows版ChromeでGoogle Workspace向けに一般提供されています。マルウェア感染の対策も実施する場合、ログイン後のセッション保護も、別の対策として必要です。
企業での活用では、認証方式の改善とともに、端末やブラウザの管理も継続することが必要です。強い認証を導入したからといって、その他の対策を不要と考えないことが重要です。
まとめ
近年、フィッシングやランサムウェアなどのサイバー攻撃による被害が相次ぎ、企業の情報や業務を守るための対策がますます重要になっています。攻撃の手口も巧妙化しており、今回紹介したように、2段階認証を設定していても認証情報を盗まれる可能性があります。「設定済みだから安心」と考えず、対策を継続的に見直す姿勢が必要です。
これは、大企業だけの課題ではありません。中小企業でも、業務用アカウントへの不正アクセスが、顧客や取引先の情報漏えい、業務の停止、信用の低下につながり得ます。「自社も被害を受ける可能性がある」という認識を経営者と社員が共有し、セキュリティへの意識を高めていくことが大切です。
その具体的な取り組みとして、Google Workspaceでのパスキーやセキュリティキーの設定は重要です。フィッシングに強い認証方式を取り入れることで、認証情報を狙う攻撃への備えを強化できます。まずは管理者や重要な情報を扱う社員から導入し、利用方法や紛失時の対応を整えながら対象を広げていきましょう。社員への教育や端末の管理も続け、意識と仕組みの両面から対策を積み重ねることが、自社と取引先の信頼を守ることにつながります。