IT用語集 2022/05/06

多要素認証とは？二段階認証や二要素認証との違いなど

はじめに

クラウドサービスやWebサービスが普及し、業務の利便性が高くなる一方で懸念されるのが、IDとパスワードの不正利用です。パスワードが盗まれると、不正アクセスや情報漏えいなどのセキュリティリスクは一気に高まります。

そこで近年、ログインの信頼性を高める手段として注目されているのが多要素認証（MFA：Multi-Factor Authentication）です。多要素認証は「MFA」と略されたり、文脈によっては「二要素認証（2FA）」や「二段階認証」と同列に語られたりしますが、これらは似ているようで意味が異なるため、最初に整理しておくと読み進めやすくなります。

さらに近年は、認証情報そのものの漏えいだけでなく、フィッシングやマルウェアなどによって「正規のIDとパスワードが攻撃者に渡る」ケースも増え、パスワードだけで安全性を担保することが難しくなっています。特にクラウドは社外からのアクセスが前提になりやすく、攻撃者から見ても狙いやすい入口になりがちです。

実務の感覚としても、業務で使う入口は増え続けています。メール、SaaSの管理画面、ファイル共有、ワークフロー、経費精算など、ログインの先に重要な操作がぶら下がるサービスが増えるほど、「入口を突破されないこと」の価値は高くなります。入口が増えるほど、1つのIDとパスワードの失敗が、複数の被害につながる構造になりやすいからです。

本記事では、多要素認証の定義と意味、認証に用いられる3要素、代表的な方式、導入時の注意点を整理し、二要素認証や二段階認証との違いも含めて解説します。用語の理解だけで終わらせず、導入や運用で「どこでつまずきやすいか」まで押さえることを目指します。

なお、多要素認証は“入れれば万能”という種類の対策ではありません。方式の選び方や、復旧・例外対応の設計が弱いと、現場では回避策が増え、想定した効果が出ないことがあります。その前提も踏まえ、現実に導入しやすい整理にしていきます。

多要素認証とは

多要素認証は、認証に使う3要素（知識情報・所持情報・生体情報）のうち、異なる要素を2つ以上組み合わせて本人確認する認証方式です。英語ではMulti-Factor Authenticationと呼ばれ、略してMFAと表記されます。

ポイントは「手順が増えること」ではなく、異なる種類の根拠で本人確認することです。IDとパスワード（知識情報）だけに依存すると、漏えい・推測・使い回し・フィッシングなどの影響を受けやすいため、別の要素を追加して突破されにくくします。

仮にパスワードが流出しても、所持情報や生体情報が求められる設計にしておけば、攻撃者がそのまま侵入する難度が上がります。これは「侵入を絶対に防ぐ」発想というより、侵入に至るまでの条件を増やし、失敗しやすい状態にする考え方だと言えます。

現在では、多くのクラウドサービスやWebサービスで多要素認証が標準機能として提供され、導入のハードルは下がっています。一方で、方式によって強みと弱み、運用負荷（端末紛失時の復旧やヘルプデスク対応など）が変わるため、要件に合わせた選定が重要です。

また、導入を成功させるには「誰に」「どの操作に」追加認証を求めるかを決める必要があります。たとえば、管理者アカウントや重要データにアクセスできる権限には強い方式を適用し、一般利用者は利便性を保った方式から始めるなど、運用の現実に合わせて段階的に設計することが定着の鍵になります。

設計の判断軸は、複雑にしすぎず短く持っておくと運用に落とし込みやすくなります。代表的には、①権限（管理者か一般か）、②操作（設定変更やデータのダウンロードなど重要操作か）、③場所（社外アクセスか）、④端末（管理端末か未管理端末か）といった軸です。これらを基準に「どこに強い認証を掛けるか」を決めると、過剰な負担を避けつつ、守るべきところに強度を集中させやすくなります。

なお、多要素認証は「認証（本人確認）」を強くする仕組みです。一方で、実務の対策は認証だけで完結しないことも多く、アクセスを許可する条件（場所、端末、権限など）を設計して制御する発想と組み合わせると、より現実的な運用になります。本記事ではまず認証の整理に集中しつつ、必要な範囲で運用設計の勘所も補足します。

認証における3つの要素

多要素認証で使われる「3要素」を整理します。多要素認証は、このうち異なる要素を組み合わせることで成立します。英語では知識情報が「Something You Know」、所持情報が「Something You Have」、生体情報が「Something You Are」と表現されることがあります。

知識情報

知識情報とは、その人が記憶している情報です。代表例はIDやパスワード、PINコード、秘密の質問の答えなどです。本人だけが知っていることが前提ですが、漏えい・推測・使い回し・フィッシングなどのリスクがあり、本人の管理とサービス側の対策だけに頼りやすい点が課題になります。

知識情報の代表例

パスワード：最も一般的だが、使い回しや漏えいの影響を受けやすい
PIN：端末ロック解除や承認操作の補助として使われることがある
秘密の質問：運用が楽に見える一方、推測されやすい設計だと弱点になりやすい
パターン認証：主に端末側のロック解除で利用され、覗き見や痕跡から推測される場合がある

設計・運用面では、パスワードポリシーやロックアウト、漏えい検知などの対策を重ねても、利用者行動（使い回し、メモ保存など）に影響されやすいことが現実的な弱点です。特にクラウド利用が増えるほど「同じ人が多くのサービスを使う」状況になり、知識情報だけに依存した運用は破綻しやすくなります。

また、「パスワードを強くする」だけでは限界がある点にも注意が必要です。フィッシングのように利用者が自分で入力してしまう攻撃では、複雑なパスワードであっても“正しい情報”がそのまま攻撃者に渡り得ます。知識情報は便利でありながら、攻撃側の成功条件を満たしやすい要素だと言えます。

運用でつまずきやすい例としては、定期変更が形骸化する、共有アカウントが残る、退職者アカウントの整理が遅れる、といった問題が挙げられます。知識情報は仕組みだけでなく運用状況に左右されるため、追加要素を組み合わせて前提を補うことが現実的です。

所持情報

所持情報とは、その人が所持している「物」から得られる情報です。例として、スマートフォン、ワンタイムパスワード（OTP）トークン、ICカード、セキュリティキー（ハードウェアキー）などが挙げられます。物理的な「物」が関わるため、紛失・盗難・複製のリスクはありますが、知識情報だけより突破の難度を上げやすいのが特徴です。

所持情報の代表例

認証アプリ：コード表示や承認操作など、スマートフォンを所持要素として使う
ワンタイムパスワードトークン：物理デバイスに表示されたコードを用いる
ICカード：入退室や端末ログインなどと連動することがあり、管理ルールが重要になる
セキュリティキー：端末に接続して利用するタイプがあり、フィッシング耐性に寄与する場合がある

実務では、紛失や機種変更が必ず起こる前提で、予備手段や本人確認フロー、再発行の運用を整備しておくことが重要です。ここが弱いと、セキュリティよりも業務継続が優先され、例外運用が増えやすくなります。特に「緊急だから一時的に回避する」という運用が常態化すると、設計上の前提が崩れてしまいます。

また「所持情報＝スマートフォン前提」になりやすい点も、導入時の落とし穴です。業務用スマートフォンの有無、私物端末をどこまで許容するか、海外出張や圏外環境での利用など、運用条件によっては方式選択や代替手段が必要になります。

最低限としては、復旧設計を「決めるべき項目」として整理しておくと運用が安定します。たとえば、復旧コードの発行と保管、予備要素（別端末や予備トークン）の扱い、本人確認の手順、緊急解除を行う場合の期限とログ管理などです。これらが曖昧だと、結局「最も弱い抜け道」が常用される状態になりかねません。

生体情報

生体情報とは、身体的特徴に基づく情報です。指紋・顔・虹彩などが代表例で、声紋や静脈を使う方式もあります。知識情報より利用者負担が小さく、所持情報より紛失のリスクが小さい点がメリットです。一方で、生体情報は変化や誤認識が起こり得ること、また生体情報そのものが漏えいすると変更が難しい点には注意が必要です。

生体情報の代表例

指紋認証：端末ロック解除で広く普及し、使いやすい一方で代替手段の扱いが重要になる
顔認証：利便性が高いが、読取条件や端末要件に左右されることがある
虹彩認証：高い識別性が期待される一方で、導入環境や運用設計が前提になる
静脈認証：専用機器を用いることが多く、運用・設置要件とセットで検討される

運用上は、誤認識や読取不良を想定し、代替手段（PINなど）を用意することが一般的です。代替手段の扱いが緩いと、結果的に最も弱い経路から突破される可能性があります。生体認証を導入する場合は、代替手段も含めて「どこが最終的な入口になるか」を意識して設計することが重要です。

また、生体認証は「端末のロック解除」として利用されることが多く、利用者には“押せば通る便利な機能”として認識されがちです。一方で、サービス側のログイン設計は別に存在する場合があり、端末側の生体認証だけで本人確認が完結するとは限りません。どこで生体認証を使い、どこで代替手段に落ちるのかを、端末管理のルールと併せて整理しておくと誤解が減ります。

多要素認証の代表的な方式

多要素認証は「組み合わせ」が本質です。ここでは、現場でよく使われる方式を整理します。なお、同じ方式名でも、サービスの実装や運用設計によって安全性と使い勝手は変わります。

方式を比較する際は、評価軸を短く揃えておくと判断しやすくなります。代表的には、①フィッシング耐性、②復旧のしやすさ、③利用者負担、④端末やネットワークの要件、⑤監査・ログの取りやすさといった観点です。どれか1つが優れていれば正解、というより「自社で守りたい対象と運用条件」に合うかで選ぶのが現実的です。

IDとパスワードにワンタイムパスワードを追加する方式

多くのサービスで利用される代表例です。ワンタイムパスワードは一度きり、または短い時間で変化するパスコードを用います。

アプリ型：スマートフォンアプリに表示されるコードを入力する
物理トークン型：キーホルダー型、カード型など、専用機器に表示されたコードを入力する

導入しやすい一方で、偽サイトがコードまで入力させるリアルタイム中継型の攻撃では突破される可能性があります。たとえば、利用者が偽サイトに入力したコードが、その場で正規サイトへのログインに転用されるようなケースです。重要なシステムでは、フィッシング耐性の観点で方式を見直す判断も必要です。

運用面では、利用者の端末変更や紛失の対応に加え、時刻ずれや入力ミスなどの問い合わせが発生することがあります。導入前に、ヘルプデスクの対応手順や、復旧コードの配布・保管方法を決めておくと運用が安定します。

IDとパスワードにSMS認証を追加する方式

SMSで届くコードを入力する方式です。手軽で普及していますが、SIMの乗っ取り（SIMスワップ）や携帯回線側の事情、端末・番号の管理状況によってリスクが変動します。社内利用など要件が高い場合は、SMS以外の選択肢（認証アプリ、承認型、セキュリティキー等）も比較検討しましょう。

また、電波状況や海外利用などでコードが届かないケースもあり得ます。業務で利用する場合は、番号変更時の手続き、海外出張や回線不通時の代替手段など、「使うなら押さえるべき運用条件」を事前に決めておくことが重要です。

IDとパスワードに承認型のプッシュ通知を追加する方式

ログイン時にスマートフォンへ通知が届き、ユーザーが承認して認証する方式です。入力の手間が少なく利便性が高い一方で、通知を大量に送って誤承認を狙う攻撃が問題になります。

この種の攻撃は、一般に多要素認証疲労攻撃と呼ばれます。利用者の「面倒だから押してしまう」「通知に慣れて判断が雑になる」といった心理を突き、承認を引き出そうとします。対策としては、番号照合などで承認時に状況判断を挟める設計にすること、利用者教育として身に覚えのない通知は必ず拒否すること、連続通知が発生した場合の報告・一時停止など運用ルールを明確にすることが重要です。

運用では、通知が届かない、端末を置き忘れた、といった問い合わせも想定されます。承認型は「押せば通る」印象になりやすいため、必要に応じてパスワード変更や報告手順とセットで周知すると、誤承認リスクを下げやすくなります。

IDとパスワードに生体認証を追加する方式

端末の生体認証を活用し、本人確認の強度と利便性を両立します。業務端末のロック解除から業務システムのログインまで一貫させると、利用者の抵抗感を下げながら多要素認証を定着させやすくなります。

一方で、生体認証は端末側の設定や代替手段（PINなど）の管理にも依存します。端末管理のルールと併せて運用しないと、想定より弱い経路が残る可能性があります。端末ロックの方針、PIN強度、紛失時の遠隔対処などとセットで整理しておくと、抜け道になりにくくなります。

電子証明書認証

電子証明書（クライアント証明書）を端末に配布し、その証明書を用いて端末やユーザーを確認する方式です。証明書の配布・失効・更新など運用設計は必要ですが、正しい端末からのアクセスであることを条件にできるため、アクセス制御の考え方と相性が良いケースがあります。

実務では、証明書の更新漏れや端末入れ替え時の再配布が運用課題になりやすいポイントです。たとえば「管理端末に限定したい」「端末の健全性とセットで考えたい」といった要件がある場合に採用されやすいため、証明書のライフサイクルを前提に、担当部門や手続きを明確にしておくことが重要です。

フィッシング耐性が高い方式

フィッシング被害の増加を背景に、フィッシング耐性が高い認証方式への移行が注目されています。代表例がFIDO2やWebAuthn（パスキーを含む）です。サイト（ドメイン）と強く結び付いた仕組みで認証するため、偽サイトに情報を入力させるタイプの攻撃に強いとされています。

多要素認証を導入しても、方式によってはフィッシングで突破され得ます。重要なシステムほど、方式選定の評価軸にフィッシング耐性を含めることが重要です。加えて、端末やブラウザの要件、登録フロー、移行期の併用設計などでつまずきやすいため、利用者が迷いにくい導線にすることで、例外運用や問い合わせの増加を抑えやすくなります。

二経路認証

二経路認証は、ログインしている端末とは別の経路で追加確認を行う考え方です。たとえば、PCでログイン操作をしつつ、スマートフォン側で承認やコード受領を行うような形がイメージに近いでしょう。

別経路を使うことで「ログイン端末だけが侵害されても直ちに成立しにくい」状態を作りやすい一方、運用上はスマートフォン紛失時の復旧や、回線不通時の代替手段など、例外設計が重要になります。二経路認証は方式名というよりも、運用設計の方針として理解しておくと整理しやすくなります。

多要素認証が注目される背景

多要素認証が広まった背景には、パスワード認証だけでは十分な強度を確保しにくくなった現実があります。代表的な攻撃には、総当たりのブルートフォース攻撃、よく使われる文字列を狙う辞書攻撃、マルウェア、そしてフィッシングが挙げられます。

また、サービス利用数の増加により「パスワードを覚え切れない」問題が顕在化し、使い回しや弱いパスワード、メモへの保存などが起きやすくなりました。IDとパスワードが流出すると、同じ組み合わせが別サービスでも試されるなど、被害が連鎖しやすい点も大きな課題です。

さらに、スマートフォンの普及によって指紋認証や顔認証などを日常的に体験する人が増え、本人確認を追加する行為への心理的ハードルが下がったことも普及を後押ししました。結果として、業務でも個人でも、追加認証が現実的な選択肢として受け入れられるようになっています。

このように、攻撃側の手口が多様化し、利用者側の負担も増える中で、パスワード単独の前提を補う仕組みとして多要素認証が位置づけられています。加えて、攻撃と対策の対応関係で見ると理解しやすくなります。たとえばフィッシングが増えるほど、方式選定でフィッシング耐性を重視する必要が高まります。また漏えいの影響が広がるほど、追加要素によって「パスワードが漏れても被害が直ちに成立しない」状態を作ることが重要になります。

多要素認証の活用シーン

多要素認証は、不正アクセスやなりすましを防ぐために重要であり、社内システムへのログイン、クラウドサービスの利用、ネットバンキング、重要データへのアクセスなど、さまざまな場面で活用されています。

多要素認証は、仮にIDとパスワードが漏えいしたとしても、所持情報（スマートフォン等）や生体情報の要素が残るため、攻撃者が突破しにくくなります。特に、社外アクセスが前提の業務や、権限の強いアカウントほど、追加認証の有無がリスクの差として表れやすくなります。

運用の観点では、全利用者に一律で強い方式を求めるのではなく、扱う情報や操作の重要度に応じて、追加認証の要求レベルを調整する考え方もあります。たとえば、ログインだけでなく「重要設定の変更」や「重要データのダウンロード」など、操作の種類によって追加認証を求める設計にすると、利便性と安全性を両立しやすくなります。

さらに「要求レベルの段階」をイメージできると設計がしやすくなります。例として、一般的なログインは中程度、管理操作や重要データ操作は強め、社外や未管理端末からのアクセスは強め、といった具合です。こうした段階付けは、利用者の負担を必要以上に増やさず、守るべき箇所に強度を集中させるうえで有効です。

利用者体験とセキュリティ要件の両立を図るために、活用シーンごとに設計することが重要です。

多要素認証と二要素認証と二段階認証の違い

多要素認証と似た言葉に、二要素認証と二段階認証があります。混同されやすいので整理しておきましょう。ここでは、検索者が「瞬間的に判断」できるよう、まず判断手順を提示します。

要素が異なるかを確認し、異なるなら二要素認証（2FA）であり、多要素認証（MFA）に含まれます。次に、手順が2回かを確認し、2回なら二段階認証です。二段階認証は要素が同じ場合もあるため、名称だけで多要素認証と決めつけないことが重要です。

二要素認証

二要素認証は、認証の3要素のうち異なる2要素を組み合わせて行う認証です。つまり、二要素認証は多要素認証の一種です。

代表例は「IDとパスワード（知識）＋ワンタイムパスワード（所持）」や「IDとパスワード（知識）＋生体認証（生体）」などです。

二段階認証

二段階認証は、2つの段階（手順）を経て行う認証を指します。重要なのは、2段階であっても必ずしも異なる要素とは限らない点です。

たとえば「IDとパスワード入力の後に秘密の質問に回答する」ケースは、どちらも知識情報なので多要素認証ではありません。一方で「IDとパスワードの後にワンタイムパスワードを入力する」なら、二段階認証であり、かつ多要素認証でもあります。

この違いを理解しておくと、サービスの設定画面や資料に「二段階認証」と書かれていても、それが多要素認証に該当するかどうかを判断しやすくなります。整理の仕方としては、「要素が異なるか」を先に確認し、異なるなら二要素認証（広い意味では多要素認証）、「手順が2回か」を見て二段階認証かどうかを判断すると混乱が減ります。

多要素認証の利用における注意点

多要素認証は有効な手段ですが、導入すれば自動的に安全になるわけではありません。方式によって得意・不得意があり、運用設計が弱いと「最も弱い抜け道」が常用される状態になりかねません。主に次の点に注意が必要です。

紛失や故障時の復旧設計：スマートフォンやトークンを失うとログインできなくなるため、バックアップ手段（予備トークン、復旧コード、ヘルプデスク手順等）が必要です。
フィッシング対策：ワンタイムパスワードやSMSは、偽サイトで入力させられると突破される可能性があります。重要なシステムではフィッシング耐性の観点で方式を選定しましょう。
誤承認の対策：承認型の方式は便利ですが、誤承認を狙う攻撃があります。番号照合など、誤操作を減らす仕組みが有効です。
メール依存の注意：メールでコードを受け取る方式は、メールアカウント自体が乗っ取られると弱点になります。

また、よくある誤解として「多要素認証を入れたのに突破されるのか」という不安があります。結論としては、方式と状況によっては突破に至る経路が残り得ると理解しておく方が現実的です。代表的には、フィッシングで入力させられる、SIMスワップのように番号が奪われる、承認通知を誤って押してしまう、端末が侵害されてセッションが悪用される、といったパターンが考えられます。ここで重要なのは、これらを理由に導入をためらうことではなく、自社の運用条件で起こりやすい経路を前提に設計することです。

方式を選ぶ際は、自社の環境・リスク・運用体制（サポート体制、端末管理、在宅比率など）を踏まえ、方式そのものだけでなく運用まで含めて設計することが重要です。例外運用が増えるほど、実際の安全性が下がりやすい点にも注意が必要です。

運用が定着しない原因として多いのが、利用者が「面倒だから回避したい」と感じる状況です。追加認証の頻度やタイミングを調整したり、復旧手順を簡潔にしたりするなど、利用者の負担を過度に増やさない設計を併せて検討することが現実的です。

特に例外運用は“増やさない”だけでなく、“増えたときに統制できる”形にしておくことが重要です。たとえば緊急解除を行う場合は期限付きにし、実施記録を残す、解除の窓口を一本化する、といったルールがあるだけでも現場の運用は安定しやすくなります。曖昧な例外対応は、結果として最も弱い経路を常用する状態につながりかねません。

復旧と例外対応で最低限決めるべき項目

復旧コード：発行するか、どこに保管するか、再発行の条件
予備要素：予備端末や予備トークンを持つか、配布と回収の手順
本人確認：紛失時に誰が何をもって本人と確認するか
緊急解除：解除の期限、記録、承認フロー、解除後の必須対応

導入の順番を誤らない

導入の順番も、失敗しにくいルートを取ることが現実的です。一般的には、まず管理者アカウントから、次に重要操作（設定変更やデータ出力など）に広げ、最後に全体へ、と段階的に適用範囲を拡大すると、問い合わせや例外の発生を抑えながら定着させやすくなります。

IDとパスワードだけのセキュリティは見直しを

いまや、IDとパスワードだけの認証では、十分なセキュリティ対策ができているとは言いにくい状況です。クラウドサービスの普及により、個人が管理すべきIDとパスワードの数は膨大になり、管理の煩雑さがリスクに直結しやすくなっています。

覚えやすいパスワードを使う、使い回す、メモに残すといった行動は起こりやすく、さらに攻撃者側もフィッシングやマルウェアなど多様な手口を用います。パスワードを使い続けるとしても、多要素認証などを組み合わせて突破されにくい状態にしていくことが現実的です。

多要素認証の導入は難しいものではなく、サービス側で設定できるケースも増えています。まずは利用しているサービスの設定状況を確認し、権限が強いアカウントや重要な操作から優先して多要素認証を適用するなど、必要な範囲から取り入れていきましょう。

行動に落とすためには、チェック項目を小さく持つのが有効です。例として、①管理者アカウントで多要素認証が有効になっているか、②紛失・機種変更時の復旧手順が整っているか、③利用している方式のフィッシング耐性を理解しているか、④緊急解除など例外運用のルールがあるか、といった観点です。これらを押さえるだけでも、導入が“形だけ”になりにくくなります。