株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
MFAとは？認証の要素と確認の回数を区別する
MFA（Multi-Factor Authentication、多要素認証）は、異なる種類の認証要素を組み合わせて本人を確認する仕組みです。パスワードだけが漏れた場合にも、別の要素が必要な状態を作れます。ただし、すべての方式が同じ攻撃を防ぐわけではありません。利用者が行う操作の回数、使う要素、認証器の仕組みを分けて理解することが、導入の出発点になります。
| 要素 | 例 | 確認する点 |
|---|---|---|
| 知識・記憶 | パスワード、PIN | 本人が知っている秘密。ただし使う場所や役割を区別する |
| 所持 | 認証アプリや秘密鍵を保持する端末、セキュリティキー | 端末の所有だけでなく、認証に必要な秘密を使えることを確認する |
| 生体 | 指紋、顔などによる利用者検証 | 単独の画像判定と、認証器を使うための検証を混同しない |
二要素認証は、異なる二種類を使うMFAの一種です。一方、二段階認証という表現は確認を二回行う流れを指す場合があり、二つの画面が必ず二要素になるとは限りません。例えばパスワードと秘密の質問は、いずれも知識に属します。IPAの不正ログイン対策も、記憶・所持・生体の異なる要素による認証を説明しています。
逆に、一度の操作の中で複数要素を確認する方式もあります。パスキーでは、認証器の秘密鍵を使い、その使用にPINや生体による利用者検証を求める構成があります。画面を一回操作したから単要素と決めつけず、サービスが要求・検証する条件を確認します。端末のロック解除と、サイトへの認証結果の検証も別の処理です。
認証方式の名称と実際の設定を台帳で対応付けると、対象範囲や例外の点検に使えます。
組織で「MFAを設定済み」と記録するときは、登録した認証器があることと、対象ログインで実際に必要とされることを区別します。管理画面、一般利用、復旧、古い接続方式に別の経路がないかを調べます。パスワードそのものの保管と変更は、安全なパスワード管理も合わせて見直し、認証の追加だけで使い回しを放置しない運用にします。
認証方法の比較｜OTP・プッシュ通知・パスキー
方式を選ぶ際は、利用できる端末と、想定する攻撃を揃えて比較します。SMSや認証アプリはパスワード単独の運用へ加える対策になりますが、利用者がコードを偽サイトへ入力する攻撃への耐性は別に考える必要があります。NIST SP 800-63B-4では、OTPや帯域外認証とフィッシング耐性のある暗号認証を区別しています。米国政府向けの技術指針を、日本の民間企業に一律の法的義務があるものとして扱わないようにします。
| 方法 | 特徴 | 注意点 |
|---|---|---|
| SMSなどのコード | 対応する電話番号を利用 | 偽サイトへの入力、回線・番号の変更、受信できない場合を考える |
| 認証アプリのTOTP | 共有秘密と時刻からコードを生成 | 偽サイトへ入力させる攻撃は残る。時計のずれと移行・復旧も確認する |
| プッシュ通知 | 認証アプリで要求を承認 | 要求の内容、番号の照合、身に覚えのない通知への対応を決める |
| パスキー・FIDO2キー | 対象サイトに結び付く公開鍵暗号による認証 | 利用者検証、保存先、端末固定・同期、紛失時の復旧を確認する |
TOTPのコード更新間隔はすべて同じではありません。RFC 6238は30秒を既定の推奨値としていますが、実際の設定と受け入れ条件はサービスによって異なります。コードの残り時間だけでなく、認証器を替えるときに共有秘密をどう扱うか、旧端末の登録をどう失効させるかも確認してください。
プッシュ通知も、承認ボタンだけを押す方式と番号照合を伴う方式を同一視しません。例えばMicrosoft Authenticatorの番号照合には、接続方式や利用画面に応じた動作の説明があります。身に覚えのない通知は承認せず、社内窓口へ報告する手順を用意します。報告の練習と窓口の対応を確かめる方法は、セキュリティ教育とフィッシング訓練の進め方でも整理しています。番号照合があることだけで、パスキーと同じフィッシング耐性になるとは判断しません。
Microsoftの2023年研究は、対象データでMFA利用によるアカウント侵害リスクの推定減少を99.22%と報告しています。これは調査対象と方法に基づく結果で、あらゆる攻撃を一定割合で遮断する保証ではありません。より詳しい方式の比較は、パスキーの仕組みと企業導入を参照してください。
企業で導入する手順と、ライセンス・費用の見方
導入では、先に対象サービスと利用者を棚卸しします。メール、管理者、顧客情報に触れる業務、遠隔接続など、侵害時の影響が大きい経路を確認し、社員・委託先・外部利用者を分けて対象を決めます。SSOを使う場合は、認証を担当するIdPだけでなく、連携する各アプリの設定、直接ログイン、復旧、既存セッションまで確認する必要があります。
- 対象アカウント、権限、端末、接続方式と責任者を整理する。
- 利用できる認証器と、必要なフィッシング耐性・管理条件を決める。
- 試行対象を限定し、登録、通常利用、端末交換、紛失時の復旧を試す。
- 例外と緊急用アカウントの条件を決め、対象ログインへ適用する。
- 実際の認証記録、未適用の経路、問い合わせと復旧の結果を点検する。
全員に同じスマートフォンを使わせられるとは限りません。私物端末を使えない人、共用端末、ネットワークの制限、アクセシビリティ、委託終了時の返却を考慮します。認証器の配布費だけでなく、予備、交換、サポート、登録支援と運用者の工数を含めて比較します。短い標準期間を一律に示すより、未解決の利用条件を試行で確認し、展開の判断材料にします。
Microsoft Entraの公式ライセンス説明では、基本的なMFAを使うセキュリティ既定値と、P1の条件付きアクセス、P2のリスクベース条件が区別されています。「MFAなら全部無料」「すべての会社に同じ有料プランが必要」という説明は正確ではありません。既存契約に含まれる機能、必要な制御、対象ユーザーのライセンスを確認して見積もります。
管理ツールにTOTP生成をまとめる場合は、保管庫へのログイン認証と、接続先へ入力するコードの生成を分けます。便利さと、一つの保管庫が侵害された場合の影響を比較し、重要アカウントで別の認証器を使うかを決めます。無料・有料の機能差は、パスワードマネージャーの比較を参考にしてください。認証だけでアクセス権が適切になるわけではないため、ゼロトラストの権限管理も合わせて整理します。
復旧・失効と、自社システムの実装を検証する
MFAは、通常ログインが強くても、復旧が容易に悪用されると迂回される可能性があります。紛失、故障、電話番号の変更、機種変更を想定し、予備の認証器やバックアップコード、本人確認を伴う再登録の手順を決めます。問い合わせ窓口が、連絡してきた人の申告だけで認証器を解除しない仕組みも必要です。復旧の条件、承認者、記録をあらかじめ明確にしておきます。
認証器を失った際は、新しい端末でログインできたことと、失った認証器を使えなくしたことを分けて確認します。認証器の登録削除、ログイン済みセッション、接続先の権限、復旧先の変更を点検します。退職や委託終了時も、IdPの停止だけで各サービスのすべてのセッションが直ちに消えると仮定せず、連携と失効の実際の動作を確かめてください。
自社Webシステムでは、画面にMFAの入力欄があるだけでは十分ではありません。サーバー側で認証状態を確認するか、追加認証前に業務APIを呼べないか、再登録に必要な本人確認があるかを、許可された検証環境で調べます。管理者・一般利用者・外部利用者の権限も含め、認証と認可を区別して確認します。認証できた人が他人の情報へアクセスできないことも、別の検証項目です。
運用の指標には、認証器の登録率に加えて、対象ログインでの適用状況、例外の理由と期限、復旧の所要時間、紛失・不審通知への対応を含めます。試行前後で同じ対象と期間を使い、利用者が困っている経路や、回避されている設定を調べます。数字だけを上げるために本人確認を省略したり、適用除外を無期限に残したりしないようにします。
自社アプリの認証・復旧・権限チェックを点検する場合は、renueのAI脆弱性診断支援で、コード分析や合意した環境での検証範囲を相談できます。IdP製品のライセンス購入と、アプリ側の実装を調べる診断は対象を分けて考えます。セキュリティ診断の進め方も参照し、診断結果、改善の優先順位、改修後の確認をどう扱うかを決めて進めます。
