多要素認証とは｜自社システムにどこまで入れるかの判断基準

取引先から届いたセキュリティチェックシートに「重要システムへの多要素認証の適用状況」という欄がある。サイバー保険の更新案内にも、加入条件として多要素認証の実施が書かれている。クラウドサービス側は設定画面のスイッチを入れるだけで済んだものの、10 年前に外部発注で作った社内の業務システムは ID とパスワードだけ。上司に「うちはどこまでやる必要があるの？いくらかかるの？」と聞かれて、言葉に詰まった——。こうした場面は、情報システムを兼任で担当している中堅・中小企業で起こりがちです。

困るのは、技術そのものではありません。多要素認証という言葉の意味も、知識・所持・生体の 3 要素という分類も、検索すればいくらでも解説が見つかります。それでも答えが出ないのは、「自社のどこまでに入れれば妥当だと言えるのか」という線引きの判断と、その根拠の説明が必要になるからです。全社員・全システムに一斉に入れれば安全側に振れますが、現場からの反発と問い合わせ対応で情シス 1〜2 名の体制が先に破綻します。かといって「やっていません」とチェックシートに書くわけにもいきません。

結論から言えば、多要素認証は「全部に入れる／入れない」の二択で考えるものではありません。アカウントの権限・アクセス経路・扱うデータの機微性という 3 つの軸で対象を切り分ければ、「ここまでは必須、ここからは第 2 段階」という線を根拠つきで引けます。さらに方式ごとの費用と運用負荷を突き合わせれば、「安いが有事対応が重い方式」と「初期費用は重いが問い合わせが減る方式」のトレードオフも見えてきます。

本記事では、定義と方式の整理は必要最小限に押さえたうえで、適用範囲を決める 3 つの判断軸、方式別の費用と運用負荷の比較、自社開発システムに後付けする際の実装 3 パターン、そして兼任体制でも回る運用設計までを順に解説します。読み終えたときに「自社はここまで入れる、理由はこれ」と上司と取引先に説明できる状態を目指します。

—Free Download / 資料ダウンロード

システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き

この資料でわかること

発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。

こんな方におすすめです

• システム開発の発注を初めて担当する方
• 複数社の見積もりを比較・評価したい方
• IT投資の社内稟議を通す根拠を固めたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

多要素認証とは｜知識・所持・生体から2要素以上を組み合わせる認証

多要素認証（MFA: Multi-Factor Authentication）とは、性質の異なる複数の認証要素を 2 つ以上組み合わせて本人確認を行う認証方式です。従来の「ID + パスワード」は知識という 1 種類の要素だけに依存しているため、パスワードが漏れた時点で誰でもなりすませます。ここに別の種類の要素を足すことで、1 つが漏れても突破されない状態をつくるのが多要素認証の目的です。

なお本記事の主眼は、この定義そのものではありません。用語の整理は手短に済ませ、「自社のどのシステム・どのユーザーに、どこまで適用するか」という適用範囲の決定と、そのための費用・運用負荷の見積もりに紙幅を割きます。定義だけを確認したい方は、このあとの「多要素認証と二要素認証・二段階認証の違いを整理する」まで読んでいただければ十分です。

3つの認証要素（知識・所持・生体）とそれぞれの具体例

認証要素は、大きく次の 3 種類に分類されます。

この 3 分類に加えて、コンテキスト情報と呼ばれる補助的な判断材料もあります。アクセス元の IP アドレス・国・時刻・端末の種類・普段と異なる操作パターンなどです。これらは単独で認証要素として数えられるものではありませんが、「普段と違うアクセスのときだけ追加認証を求める」といった制御に使えます。この考え方はのちほど段階導入の話で再登場します。

「要素が異なる」ことが強度を生む理由と、同一要素の重ね合わせが多要素にならない理由

多要素認証で本質的に重要なのは、要素の数ではなく「種類が異なること」です。

たとえば「パスワードを入力したあとに、秘密の質問に答える」という流れは、画面が 2 つに増えていても、どちらも知識情報です。パスワードと秘密の質問の答えが同じ流出リストに含まれていれば、両方まとめて突破されます。一方で「パスワード（知識）+ スマートフォンの認証アプリに表示されるコード（所持）」であれば、攻撃者はパスワードを盗むだけでなく、物理的に端末を手に入れるか、端末上のコードを横取りする必要が生じます。突破に必要な手口が 1 つ増えるのではなく、種類の違う手口を同時に成立させる必要が出てくるため、難易度が跳ね上がります。

ここが、自社の実態をチェックシートに書く際に誤認しやすいポイントです。「ログイン後にもう 1 画面挟んでいるから多要素認証をやっている」と回答してしまうと、監査で詳細を問われた際に説明が崩れます。次の「多要素認証と二要素認証・二段階認証の違いを整理する」で、この用語の整理を実務ベースで確認します。

多要素認証と二要素認証・二段階認証の違いを整理する

多要素認証のまわりには、二要素認証（2FA: Two-Factor Authentication）・二段階認証（2SV: Two-Step Verification）という似た用語が並んでいます。この 3 つの関係を押さえておかないと、対外的な説明の精度が落ちます。

包含関係の整理｜多要素認証と二段階認証は別の概念

3 つの用語の関係は、次のように整理できます。

つまり、二要素認証は多要素認証に含まれる一形態であり、二段階認証は「段階の数」に着目した別の切り口です。「パスワード → SMS のワンタイムパスワード」は二段階かつ二要素なので多要素認証に該当しますが、「パスワード → 秘密の質問」は二段階ではあっても多要素認証ではありません。

要素を 3 つ使う構成（たとえばパスワード + 認証アプリ + 指紋）も多要素認証に含まれますが、要素を増やすほど利用者の手間と運用負荷が増えます。中堅・中小企業の実務では、まず「異なる 2 要素を確実に成立させる」ことを目標に据えるのが現実的です。

社内の実態をチェックシート・監査でどう表現するか

取引先のセキュリティチェックシートやサイバー保険の加入要件に回答する際は、「多要素認証を実施しています」という一文で済ませず、次の 3 点をセットで書けるようにしておくと、追加質問が来たときに崩れません。

1. 組み合わせている要素の種類：「知識情報（パスワード）+ 所持情報（スマートフォンの認証アプリによる TOTP）」のように、種類名と具体的な手段を併記します
2. 適用している範囲：「社外からアクセスする全ユーザーおよび管理者権限アカウントに適用。社内 LAN からの一般利用者は 20XX 年 X 月までに適用予定」のように、対象と未適用部分、そして適用計画を明示します
3. 未適用部分の代替策：未適用の範囲については「IP アドレス制限により社内 LAN からのアクセスに限定」「端末証明書による端末制限を実施」など、何で補っているかを書きます

ここで「範囲を正直に書くと評価が下がるのではないか」と心配になるかもしれません。ただ、未適用部分を伏せた回答よりも、範囲と理由と計画が書かれた回答のほうが評価につながりやすいと考えられます。リスクを把握して優先順位をつけられている状態を示せるからです。そして、その「範囲と理由」をどう組み立てるかが本記事の核になります。

多要素認証の方式の種類｜SMS・認証アプリ・ハードウェアトークン・生体認証

適用範囲を決める前に、選択肢になる方式とその強度差を把握しておきます。方式ごとに「突破されうる攻撃」が違うため、必要な強度を満たす範囲のなかで安い方式を選ぶという順序で考える必要があります。

所持要素系の方式（SMS・メールOTP・認証アプリ・プッシュ通知・ハードウェアトークン）

実務で候補になる所持要素系の方式は、主に次の 5 つです。

SMS ワンタイムパスワードは、登録した携帯電話番号に 6 桁程度のコードを送る方式です。利用者にとって追加アプリのインストールが不要で導入ハードルが最も低い一方、通信事業者をだまして SIM を再発行させる SIM スワップ攻撃や、SMS の内容を読み取るマルウェアによる横取りのリスクがあります。送信ごとに費用が発生する従量課金のため、ログイン回数が多い業務システムでは月額が読みにくくなる点にも注意が必要です。

メール OTP は、登録メールアドレスにコードを送る方式です。SMS と同様に手軽ですが、そのメールアカウントがパスワードだけで守られている場合、実質的に「知識情報の二段階」に近くなり、要素が独立していません。メール OTP を所持情報として扱うなら、メールアカウント側の多要素認証が前提になります。

認証アプリ（TOTP） は、Microsoft Authenticator や Google Authenticator などのアプリが 30 秒ごとに生成する 6 桁コードを使う方式です。通信費がかからず、端末内で完結するためネットワーク経路での横取りが起きません。スマートフォンの認証アプリを使う構成ではデバイス購入費が発生しないため、費用と強度のバランスが最も取りやすい標準的な選択肢になります（IT トレンド）。ただし利用者側でアプリをインストールし、QR コードを読み取って初期登録する作業が発生します。

プッシュ通知承認は、スマートフォンに届く通知で「承認」をタップする方式です。コードの打ち込みが不要で利用者の負担が小さい一方、通知を大量に送りつけて誤タップを誘う「MFA 疲弊攻撃」が知られています。対策として、画面に表示された番号をアプリ側で選ばせるナンバーマッチングが普及しています。

ハードウェアトークンは、コードを表示する専用デバイスや、USB・NFC で接続する FIDO セキュリティキーを配布する方式です。スマートフォンを持たない・持ち込めない利用者にも配れるという大きな利点があります。特に FIDO 準拠のセキュリティキーは、後述するフィッシング耐性の面で他方式より一段強い位置にあります。一方で、デバイス本体の購入費と紛失時の再発行対応が発生します。

生体要素系の方式とパスキー（フィッシング耐性の観点）

生体要素は、スマートフォンや PC に内蔵された指紋センサー・顔認証を使う形で実務に入ってきます。ここで重要なのは、生体情報そのものがネットワークを流れるわけではないという点です。多くの実装では、生体認証は「端末内に保管された秘密鍵を取り出すためのロック解除」として機能し、サーバーに送られるのは生体データではなく電子署名です。

この仕組みを標準化し、パスワード自体をなくす方向に進めたのがパスキーです。パスキーは公開鍵暗号を使い、アクセスしているサイトのドメインと署名を暗号的に結びつけるため、偽サイトに認証情報を渡してしまう事故が原理的に起きにくくなります。認証基盤の刷新を検討する段階にある場合は、パスキーの導入判断を扱った記事も参考になります。本記事では「既存のパスワード認証に要素を足す」ケースを主に扱うため、パスキーは強度の最上位にある選択肢として位置づけておきます。

方式別のフィッシング耐性マップ（SMSが弱い理由／FIDOベースが強い理由）

「多要素認証を入れれば乗っ取られない」という理解は、現在の攻撃手法に対しては正確ではありません。近年広がっている AiTM（Adversary-in-the-Middle）攻撃は、攻撃者が本物のサイトと利用者の間にリバースプロキシを置き、入力されたパスワードとワンタイムパスワードをその場で本物のサイトに中継します。利用者は正しくコードを入力しているため異常に気づかず、攻撃者は認証後のセッション Cookie を奪ってログイン状態を引き継ぎます（トレンドマイクロ セキュリティトレンド）。

この攻撃に対して、方式ごとの耐性は次のように整理できます。

FIDO ベースの方式が AiTM に強いのは、署名の対象にアクセス先のドメイン情報が含まれ、偽サイト経由では署名が成立しないためです。コードを読み上げて渡す余地がない設計になっている、と言い換えてもよいでしょう。この性質を「フィッシング耐性のある MFA」と呼びます。マイクロソフトは、特権管理者ロールを持つアカウントが攻撃者の頻繁なターゲットになることを踏まえ、グローバル管理者・セキュリティ管理者などのロールに対してフィッシング耐性のある MFA を要求することを推奨しています（Microsoft Learn: 管理者ロールに対してフィッシングに強い多要素認証が必要）。

ただし注意点もあります。FIDO を導入していても、「セキュリティキーが使えない場合は SMS に切り替える」というフォールバックを残していると、攻撃者がその弱い方式へ誘導する手口（認証方式のダウングレード）が成立しえます。この手口については、現時点で実環境での悪用は観測されていないと報告されている一方、技術的には実行可能であることが検証で示されています（Proofpoint）。強い方式を入れるときは、弱い方式をどこまで残すかも同時に決める必要があります。

ここまでの整理で、「どの方式が強いか」の序列は見えました。問題は、強い方式が同時に高コストでもあるという点です。次に費用と運用負荷を並べて見ていきます。

方式別の費用と運用負荷を比較する

多要素認証の導入が止まる理由は、ライセンス費用そのものよりも「導入後に情シスへ跳ね返る工数が読めない」ことにあります。ここでは費用と運用負荷を分けて見積もり、最後に両方を並べた比較表に落とします。

費用の内訳（ライセンス費・初期費用・認証デバイス費）と1〜3年総費用での比較

多要素認証ツールの費用は、大きく 3 つの要素に分解できます。「1 ユーザーあたりの月額 × 利用ユーザー数」という従量制が主流のライセンス費用、セットアップ費・環境構築費として発生する初期費用（数万円〜数十万円の場合もあれば無料の場合もある）、そしてハードウェアトークンやセキュリティキーを使う場合に発生する認証デバイス費用です。スマートフォンの認証アプリを使う構成ではデバイス費はかかりません。加えて、ユーザー数増加時のライセンス追加費、デバイス紛失時の再購入費、サポート契約費も継続コストとして発生します（IT トレンド）。

金額の目安を押さえておきましょう。クラウド型 IDaaS を採用する場合、ライセンス費用は 1 ユーザーあたり月額数百円〜1,500 円程度が目安とされており、50 名規模なら月額数万円〜7 万円程度、100 名規模なら月額数万円〜15 万円程度というレンジが示されています。基本的な多要素認証だけか、シングルサインオン連携やリスクベース認証まで含むか、サポートレベルがどこまでかによって差が生じます（IT トレンド）。

公開価格の一例として、通信事業者が提供する端末管理サービスでは、基本サービスが初期費用無料・iOS / Android が月額 300 円/ID・Windows / Mac が月額 400 円/ID で、オプションの多要素認証が月額 500 円/ID、多要素認証 Pro が月額 1,000 円/ID という体系が公開されています（いずれも税抜。ソフトバンク「デバイスマネジメント」料金）。これはあくまで 1 サービスの公開価格であり相場そのものではないため、自社の必要機能・ユーザー数で必ず個別に見積もりを取って確認してください。

ハードウェアトークンを採用する場合は、認証デバイス費用が別枠で乗ります。製品シリーズによって単価の幅が大きく、スマートフォンの認証アプリと違って人数分の本体代が発生するため、全員配布を前提にすると予算が通りにくい構造になります。セキュリティキーのベンダーであるユビコは、強力な認証を全従業員に広げる場合のコスト試算の考え方を自社ブログで公開していますが（Yubico ブログ）、これはデバイスを販売する立場からの発信である点を割り引いて読む必要があります。実際の調達単価は、購入数量と販売代理店によって変わるため見積もりで確認してください。だからこそ、適用範囲の線引きを費用計算より先に済ませる必要があるわけです。

比較の作法として押さえておきたいのが、1 年ではなく 1〜3 年の総費用で並べることです。

SMS は単価が安く見えますが、ログイン回数の多い業務システムでは送信件数が積み上がり、年間費用が事前の想定を超えやすい方式です。逆にハードウェアトークンは初年度の負担が集中し、2 年目以降は紛失時の再購入分だけに落ち着きます。電池式のトークンを使う場合は数年後の一斉交換も予算に織り込む必要があります。

運用負荷を3フェーズ（初期設定／継続運用／有事対応）に分けて見積もる

運用負荷を「なんとなく重い／軽い」で語ると、上司への説明にも自分の判断にも使えません。次の 3 フェーズに分けて、それぞれ件数 × 1 件あたりの時間で見積もると、必要な工数が数字になります。

フェーズ 1: 初期設定

• 対象ユーザー全員の登録作業（認証アプリの QR コード読み取り、トークンの紐づけ）
• 利用者向けマニュアルの作成と説明会・個別フォロー
• 管理者側のポリシー設定（適用範囲、例外設定、セッション有効期間）

ここは「1 人あたり 5〜10 分 × 対象人数 + マニュアル作成の固定工数」として見積もれます。対象 50 名なら登録作業だけで 4〜8 時間、説明と個別フォローを含めると数日分の工数になります。段階導入にする最大のメリットは、この初期工数を一度に抱え込まずに分散できることです。

フェーズ 2: 継続運用

• 入社・異動・退職にともなう登録と解除
• 利用者からの「コードが合わない」「アプリが消えた」といった日常的な問い合わせ
• ポリシーの見直し、ログの定期確認

年間の入退社件数と「毎月何件の問い合わせを想定するか」で見積もります。一般に認証アプリは利用者が自分で解決できる範囲が広く、SMS は通信状況に依存する問い合わせが出やすい傾向があります。

フェーズ 3: 有事対応

• 端末の紛失・故障・機種変更による再登録
• ロックアウト解除（本人確認を含む）
• 退職者の端末返却前の権限停止

ここが兼任体制で最も怖いフェーズです。スマートフォンの機種変更は本人の都合で起きるため、繁忙期と重なることもあります。「対象 50 名 × 年間の機種変更率 3 割 = 年 15 件、1 件 20 分」と置けば年間 5 時間程度と見積もれますし、この数字があれば「セルフサービスの再登録機能がある製品を選べばこの 5 時間が減る」という判断もできます。有事対応の件数を先に見積もることが、導入をためらう不安を具体的な計画に変える一番の近道です。

方式別の費用×運用負荷とデメリットの比較表

ここまでの内容を 1 枚に統合します。各方式のデメリット（弱点）も、費用と運用負荷と切り離さずこの表のなかで扱います。方式を単独で「良い／悪い」と評価するのではなく、「この費用と運用負荷を払って、この弱点を受け入れるか」という形で見るためです。

この表から読み取れる重要な非対称性は、費用の安さと運用負荷の軽さ、そしてデメリットの小ささが一致しないことです。SMS は初期費用が最も軽い一方で強度が最も低く、送信費が読めません。ハードウェアトークンは初期費用が最も重いものの、配布後の問い合わせは少なく済みます。したがって「とりあえず安い方式で全体に入れる」という選び方は、強度の面でも運用の面でも最適解になりにくいのです。

では、どう組み合わせるか。答えは「対象範囲ごとに違う方式を割り当てる」です。次の「自社システムにどこまで多要素認証を入れるか｜範囲を決める3つの判断軸」で、その範囲の切り方を扱います。

—Free Download / 資料ダウンロード

システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き

この資料でわかること

発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。

こんな方におすすめです

• システム開発の発注を初めて担当する方
• 複数社の見積もりを比較・評価したい方
• IT投資の社内稟議を通す根拠を固めたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

自社システムにどこまで多要素認証を入れるか｜範囲を決める3つの判断軸

ここが本記事の中心です。多要素認証の適用範囲は、アカウントの権限・アクセス経路・扱うデータの機微性という 3 つの軸で切り分けます。この 3 軸は、どれも「侵害されたときの影響の大きさ」と「攻撃を受ける確率」のどちらかに対応しているため、優先順位の根拠として説明できます。

判断軸①権限｜特権アカウントを最優先する理由と「特権」の棚卸し方法

最初に手を付けるべきは、管理者権限を持つアカウントです。理由は単純で、一般利用者のアカウントが 1 つ侵害された場合の被害がそのユーザーの権限範囲に限られるのに対し、管理者アカウントが侵害されると、ほかのアカウントのパスワード変更・権限付与・ログ削除まで実行できてしまい、1 件の侵害がシステム全体の掌握につながるからです。管理者アカウントに対しては最低 2 要素の認証を必須とすることが、主要なクラウド事業者のベストプラクティスとしても明示されています（Google Cloud 特権管理者アカウントのベストプラクティス）。

ところが実務でつまずくのは、「自社に特権アカウントがいくつあるか把握できていない」という点です。多要素認証の設定を始める前に、次の観点で棚卸しをしてください。

• 業務システムの管理者アカウント：システム管理画面にログインできるアカウント（ベンダー保守用の共有アカウントを含む）
• OS・インフラの管理者アカウント：サーバーの root / Administrator、VPN 機器や NAS の管理画面
• クラウドサービスのテナント管理者：Microsoft 365・Google Workspace・勤怠 SaaS などの全体管理者
• 業務上の強い権限を持つ一般アカウント：マスタデータを変更できる、全社員の個人情報を閲覧できる、支払処理を承認できるアカウント
• 退職者・異動者の残存アカウント：棚卸しの過程でほぼ必ず見つかる、無効化されていないアカウント

ここで見落としやすいのが最後の 2 つです。システム上の肩書きが「管理者」でなくても、実質的に被害が大きい操作ができるアカウントは特権として扱うのが安全です。逆に、棚卸しをすると「管理者権限が不要な人に付いたまま」という状態も見つかります。多要素認証を入れる前に不要な権限を外せば、対象アカウント数そのものが減り、費用と運用負荷も下がります。権限の棚卸しは、多要素認証の前工程であると同時にコスト削減策でもあります。

なお、ベンダー保守用の共有アカウントは多要素認証と相性が悪い（担当者が複数いるため所持要素を共有できない）ため、「作業時のみ有効化する」「アクセス元 IP を保守委託先に限定する」といった別の統制で補うのが実務的です。

判断軸②アクセス経路｜社外アクセスと社内LANを分けて考える

2 つ目の軸は、どこからアクセスするかです。同じアカウントでも、社外のインターネット経由でログインできる状態と、社内 LAN からしかログインできない状態では、攻撃を受ける確率が大きく違います。パスワードが漏れたとき、社外からログインできるシステムは即座に侵入されますが、社内 LAN に限定されているシステムは「まず社内ネットワークに入る」という追加の壁が残ります。

この軸で切り分けると、優先順位は次のようになります。

VPN 経由のアクセスには、注意すべき構造があります。VPN は「入口を通れば中は自由」という設計になりがちで、VPN の認証がパスワードのみだと、その 1 枚の壁が破られた時点で内部の全システムが社内 LAN 相当として見えてしまいます。したがって業務システム単体よりも先に、VPN の認証に多要素認証を入れるほうが効果が大きいケースが少なくありません。自社開発システムの改修に数か月かかる見込みなら、先に VPN 側を固めるのが実務的な順序です。

判断軸③データの機微性｜どのシステムから着手するかの決め方

3 つ目の軸は、そのシステムが扱うデータの性質です。漏えいや改ざんが起きたときの影響が大きいデータを扱うシステムから着手します。目安は次のとおりです。

• 最優先：個人情報（従業員・顧客）、取引先の非公開情報、設計図・レシピなどの営業秘密、入出金・支払処理に関わるデータ
• 次に優先：受発注・在庫・原価など、改ざんされると業務が止まるデータ
• 後回し可：社内の掲示板、公開前提の資料、個人情報を含まない共有ファイル

この軸を入れる理由は、権限と経路の 2 軸だけでは「どのシステムから手を付けるか」が決まらないことがあるためです。たとえば社外アクセス可能なシステムが 3 つある場合、個人情報を扱うシステムを先に対応させるほうが、インシデント時の影響を抑えられます。取引先のチェックシートで問われるのも多くは「重要情報を扱うシステムへの適用状況」であり、この軸での説明が回答に直結します。

リスクベース認証の考え方と3軸を組み合わせた段階導入プラン

3 軸で優先順位を決めたあと、「優先度の低い範囲を適用対象にするかどうか」で判断が止まりがちです。ここを解くのがリスクベース認証（アダプティブ認証）の考え方です。

リスクベース認証とは、ログイン試行ごとのリスクを評価し、リスクが高いときだけ追加の認証を要求する仕組みです。評価に使うのは、前に触れたコンテキスト情報です。アクセス元の IP アドレスや国、使っている端末が登録済みかどうか、アクセス時刻が普段と同じか、短時間に遠く離れた場所からログインしていないか——こうした条件を組み合わせて、普段どおりのアクセスは追加認証を省略し、見慣れないアクセスのときだけ認証アプリやセキュリティキーを求めます。

この考え方を取り入れると、適用範囲の判断が「入れる／入れない」の二択から解放されます。たとえば社内 LAN からの一般利用者には追加認証を省略し、同じアカウントが社外から使われたときだけ追加認証を要求する、という設計が可能になります。適用範囲は全利用者に広げながら、日常的な認証回数の増加は抑えられるわけです。多くの IDaaS に「条件付きアクセス」などの名称で搭載されている機能なので、製品選定の段階で対応状況と対応プランを確認してください。なお「アクセスごとに状況を検証して認可を判断する」というこの発想は、ゼロトラストの設計思想と地続きです。多要素認証は、ゼロトラストを構成する一要素という位置づけになります。

以上を踏まえ、3 つの軸とリスクベース認証を掛け合わせて段階導入プランに落とします。以下は 150 名規模・情シス兼任 1〜2 名という条件を想定した組み立て例です。自社の状況に合わせて境界を動かしてください。

段階導入プランをつくるうえで大切なのは、各段階の「完了条件」と「次の段階に進む判断基準」を決めておくことです。たとえば「第 1 段階の適用後 1 か月で、ロックアウト問い合わせが週 1 件以下に収まったら第 2 段階に進む」と決めておけば、運用が回らない状態で範囲を広げてしまう事故を避けられます。この進め方そのものが、取引先のチェックシートに書く「適用計画」の中身になります。

自社開発システムへの多要素認証の導入方法｜実装3パターンの選び方

ここまでで「どこまで入れるか」は決まりました。次は、クラウドサービスのように設定画面で有効化できない自社開発システムにどう後付けするかです。実装の選択肢は大きく 3 つあります。

パターン①アプリに自前実装する（改修範囲とメンテナンス責任）

アプリケーションのコードに TOTP の検証処理を組み込み、ユーザーごとの秘密鍵を保存して、ログイン画面のあとにコード入力画面を追加する方式です。

• 改修範囲：ログイン処理、ユーザーテーブルへの秘密鍵カラム追加、初期登録画面（QR コード表示）、コード入力画面、リカバリーコードの発行・検証、管理者によるリセット機能
• 保守委託先への発注が必要な作業：上記すべて。既存ログイン処理の改修が入るため、回帰テストの範囲も広くなります
• 向いているケース：対象システムが 1 つだけで、ほかにシングルサインオン化したいシステムがない。外部サービスへの月額費用を発生させたくない
• 注意点：実装後のメンテナンス責任が自社（と保守委託先）に残ります。将来 FIDO やパスキーに対応したくなった場合、そのたびに改修費が発生します。また、リカバリーコードの保管や管理者リセット機能の権限設計を誤ると、そこが新たな侵入経路になります

対象システムが 1 つで、当面は TOTP で足りるという見通しが立っているなら合理的な選択です。逆に「ほかの社内システムにも将来入れたい」という前提があるなら、システムごとに同じ実装を繰り返すことになり、割高になります。

パターン②IdPに認証を委譲する（SSO基盤への集約）

認証処理そのものをアプリから切り離し、SAML や OIDC といった標準プロトコルでIdP（Identity Provider: ID 基盤）に任せる方式です。アプリ側は「IdP が本人確認を終えた」という結果を受け取るだけになり、多要素認証の方式・適用条件は IdP のポリシー設定で一元管理できます。

• 改修範囲：ログイン処理を IdP へのリダイレクトに置き換え、IdP からの応答を検証してセッションを張る処理を実装。ユーザー情報の突き合わせ（IdP 側の識別子と自社システムのユーザーの紐づけ）も必要です
• 保守委託先への発注が必要な作業：上記の認証連携部分。多要素認証の方式ごとの実装は不要になるため、パターン①より改修範囲が狭くなるケースが多くあります
• 向いているケース：すでに Microsoft 365 や Google Workspace を契約しており、IdP が手元にある場合。対象システムが複数ある場合
• 注意点：IdP のライセンス体系によっては、条件付きアクセスなどの高度な機能が上位プランに含まれている場合があります。既存契約でどこまで使えるかを先に確認してください

このパターンの最大の利点は、将来の方式変更が改修なしで済むことです。TOTP からセキュリティキーに切り替えたい、特定部門だけ条件を厳しくしたい、といった変更は IdP 側のポリシーで完結します。対象システムが 2 つ以上あるなら、1 システムあたりの連携工数は増えても、全体では有利になりやすい選択です。認証を 1 か所に集約するかどうかの判断そのものを整理したい場合は、シングルサインオン（SSO）の導入判断基準も参考にしてください。

パターン③MFAツール・認証ゲートウェイを前段に置く

アプリのコードに手を入れず、アクセス経路の手前に認証を行う仕組み（リバースプロキシ型のゲートウェイ、VPN 側の多要素認証オプション、ZTNA 系サービスなど）を置く方式です。

• 改修範囲：原則としてアプリの改修は不要。ネットワーク構成とアクセス経路の変更が中心になります
• 保守委託先への発注が必要な作業：アプリ改修が不要なため、ネットワーク側の設定作業が主になります
• 向いているケース：アプリを改修できない事情がある場合（保守契約が切れている、開発会社との連絡が取りづらい、コードの保守性に不安がある）。社外アクセス経路だけを固めたい場合
• 注意点：ゲートウェイを通らない経路（社内 LAN からの直接アクセスなど）が残っていると、そこが抜け道になります。経路を確実に 1 本化できるかが前提条件です。また、アプリ内部の権限管理とは連動しないため、「ログインは防げるが、ログイン後の権限は従来どおり」という点を理解しておく必要があります

改修の難しい既存システムに対しては、このパターンが現実的な唯一の選択肢になることもあります。先ほど触れた「VPN 側に先に多要素認証を入れる」という順序も、実質的にはこのパターンの応用です。

対象システム数・保守体制から3パターンを選ぶ判断表

3 つのパターンは、次の条件で切り分けられます。

判断に迷う場合は、「今後 3 年以内に多要素認証を入れたいシステムが 2 つ以上あるか」を自問してください。答えが「ある」なら、パターン②を軸に検討するほうが総費用で有利になりやすく、方式変更への追従も楽になります。実装方式を決める前に、保守委託先に「それぞれのパターンで概算工数を出してほしい」と依頼し、3 パターンの見積もりを並べて比較することをおすすめします。上司への説明資料としても、この 3 列の比較は説得力を持ちます。

多要素認証の運用設計｜ロックアウト・端末紛失・例外ユーザーへの備え

多要素認証の導入をためらう最大の理由は、技術でも費用でもなく「入れたあとが怖い」という点にあります。ここを設計しておけば、兼任体制でも運用は回ります。

端末紛失・ロックアウト時のリカバリー設計

多要素認証を入れると、「本人なのにログインできない」という状況が必ず発生します。端末の紛失・故障・機種変更・アプリの誤削除・海外出張中の圏外などが典型です。導入前に次の 3 点を決めておいてください。

1. 予備の認証手段を最初から登録させる

認証アプリを登録する際に、同時に次のいずれかを用意させます。これがないと、端末を失った瞬間に情シスへの個別対応が発生します。

• リカバリーコード（一度しか使えない使い切りコードを複数発行し、本人が印刷して保管）
• 第 2 の所持要素（予備のハードウェアトークン、別端末の認証アプリ）
• 社内 LAN からのみ有効な代替ログイン経路

2. 本人確認の手順を文書化する

「ログインできません」という連絡が来たとき、相手が本人であることをどう確認するかを決めておきます。電話での口頭確認だけでは、なりすましの入口になります。上司の承認を介する、社員番号と別の情報を照合する、対面での確認を必須にするなど、自社の規模に合った手順を決め、手順書に落としてパート担当者でも実行できる状態にしておくことが重要です。

3. ロックアウト解除の承認フローを決める

解除作業を誰が実行でき、誰の承認が必要かを定めます。情シス担当 1 名しかいない状況で、その 1 名が不在のときに業務が止まらないよう、代替の実行者と手順も用意してください。

あわせて、退職・異動時の登録解除も手順に組み込みます。退職者の認証要素が残ったままだと、パスワード無効化の漏れと組み合わさって侵入経路になり得ます。入退社手続きのチェックリストに「多要素認証の登録解除」を追加するだけで防げる種類のリスクです。

スマートフォン未支給者・例外ユーザーをどう扱うか

工場や店舗の現場社員に業務用スマートフォンを支給していない企業では、「認証アプリを標準にする」という方針がそのまま使えません。選択肢は次の 4 つです。

実務上は、対象範囲ごとに方式を使い分けるのが現実的な解になります。管理者・社外アクセス者には認証アプリまたはセキュリティキー、スマートフォンを持たない現場社員は社内 LAN 限定の代替統制、どうしても社外アクセスが必要な現場担当者にはハードウェアトークンを個別配布する、という組み合わせです。

ここで注意したいのは、方式を増やしすぎると運用が破綻することです。方式が 4 つあれば、マニュアルも 4 種類、トラブル対応の手順も 4 系統になります。「標準方式を 1 つ + 例外方式を 1 つ」の 2 系統に収めることを目標に設計してください。私物端末への認証アプリ導入は、業務利用を強制する形になると現場の反発を招きやすいため、代替手段を用意したうえでの選択肢として提示するほうが導入は進みます。

問い合わせを減らす仕組みと利用者への周知

兼任体制で運用を回す鍵は、情シスを経由せずに利用者が自己解決できる範囲をどれだけ広げられるかです。

セルフサービス機能の有無を製品選定の基準に入れる

利用者が自分で予備要素を登録し直せる、機種変更時に自分で再登録できる、リカバリーコードを自分で再発行できる——こうしたセルフサービスポータルがあるかどうかで、情シスへの問い合わせ件数は大きく変わります。前に見積もった「有事対応の年間工数」が、この機能の有無で数時間単位で動きます。製品比較の際は、ライセンス単価だけでなくセルフサービス機能の範囲を必ず確認してください。

事前周知で初期の問い合わせを平準化する

適用開始の 2 週間前に告知し、画面つきの手順書を配布し、適用の数日前にリマインドする。この 3 ステップを踏むだけで、適用初日に集中する問い合わせがかなり減ります。周知文には次の 3 点を入れてください。

• なぜ入れるのか：取引先の要求やサイバー保険の条件といった具体的な理由を書くと、「情シスが勝手に面倒を増やした」という受け取り方を避けられます
• いつから何が変わるのか：適用日、対象者、ログイン手順の変化を明示します
• 困ったときの連絡先と自己解決の方法：まずどこを見れば解決するかを先に案内します

最初の段階で問い合わせ実績を測る

第 1 段階（特権アカウントと社外アクセス）を適用したら、1 か月間の問い合わせ件数と対応時間を記録してください。この実績値があれば、第 2 段階以降の工数を人数比で推定でき、「全社展開すると月何時間必要か」を数字で示せます。段階導入は、範囲を分割するだけでなく自社固有の運用コストを実測する仕組みとしても機能します。

まとめ｜多要素認証の導入範囲は「権限・経路・データ」で決める

多要素認証とは、知識・所持・生体という性質の異なる要素を 2 つ以上組み合わせて本人確認を行う仕組みです。ただし実務の論点は定義ではなく、「自社のどこまでに入れるか」という範囲の線引きと、その根拠を説明できるかにあります。本記事の要点を整理します。

適用範囲は 3 つの軸で決める

• 軸①権限：管理者・特権アカウントを最優先する（1 件の侵害がシステム全体の掌握につながるため）。導入前に権限の棚卸しを行い、不要な権限を外して対象数を減らす
• 軸②アクセス経路：インターネット経由・VPN 経由を最優先し、社内 LAN 限定は第 2 段階以降に回す。業務システムより先に VPN 側を固めるほうが効果が大きい場合がある
• 軸③データの機微性：個人情報・取引情報・支払処理を扱うシステムから着手する

方式は「必要な強度を満たす範囲で安いもの」を選ぶ

• SMS は導入が最も手軽だが SIM スワップに弱く、送信費が読みにくい
• 認証アプリ（TOTP）が費用と強度のバランスを取りやすい標準的な選択肢
• AiTM 攻撃に耐えられるのは FIDO ベースの方式（セキュリティキー・パスキー）。重要度の高いアカウントに優先的に割り当てる
• 強い方式を入れるときは、弱い方式をどこまでフォールバックとして残すかも同時に決める

費用は 1〜3 年総額、運用負荷は 3 フェーズで見積もる

• 費用はライセンス費用・初期費用・認証デバイス費用の 3 項目（+ サポート費）に分解し、1〜3 年の総額で比較する
• 運用負荷は初期設定・継続運用・有事対応の 3 フェーズに分け、件数 × 1 件あたりの時間で数値化する
• 有事対応の件数を先に見積もると、「怖さ」が計画に変わる

自社開発システムへの後付けは 3 パターンから選ぶ

• 対象 1 システム + IdP 未契約なら自前実装、対象 2 システム以上または IdP 契約済みなら IdP への委譲、アプリを改修できないならゲートウェイ方式
• 「今後 3 年以内に対象システムが 2 つ以上あるか」が判断の分かれ目

明日取りかかる最初の一歩

1. 特権アカウントの棚卸し：管理者権限を持つアカウントと、実質的に強い権限を持つアカウントを一覧化する（不要な権限はこの機会に外す）
2. 第 1 段階の範囲確定：棚卸し結果と社外アクセス経路を突き合わせ、「管理者 + 社外アクセス全ユーザー」の対象人数を数える
3. 方式ごとの概算比較：対象人数をもとに、認証アプリ・ハードウェアトークンの 2 案で 3 年総費用と運用工数を並べ、保守委託先に実装 3 パターンの概算工数を依頼する

この 3 ステップを終えれば、「自社は管理者と社外アクセスに多要素認証を必須とし、社内 LAN 内の一般利用者は◯月までに段階適用する。方式は認証アプリを標準とし、スマートフォン未支給者にはハードウェアトークンを配布する」という 1 行を、根拠つきで書けるようになります。取引先のチェックシートにも、上司への説明にも、そのまま使える形です。

なお、中小企業全体のセキュリティ対策の優先順位を整理したい場合は、IPA（情報処理推進機構）が「中小企業の情報セキュリティ対策ガイドライン」を無償で公開しています（IPA 中小企業向けガイド）。多要素認証を含む対策全体のなかでの位置づけを確認する際の参考になります。

関連情報：セキュリティ強化・システム改修のご検討に

既存システムへの認証強化やセキュリティ対策の進め方を整理した資料をご用意しています。社内検討・要件整理の段階からお役立ていただけます。詳しくは お役立ち資料一覧 をご覧ください。

自社開発システムへの多要素認証の後付けや、実装パターンごとの工数感の初期相談をご希望の方は、お問い合わせフォーム からご相談ください。適用範囲の整理や既存システムの改修可否の検討段階からご一緒します。

—Free Download / 資料ダウンロード

システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き

この資料でわかること

発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。

こんな方におすすめです

• システム開発の発注を初めて担当する方
• 複数社の見積もりを比較・評価したい方
• IT投資の社内稟議を通す根拠を固めたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。