MFAツールの「信頼性」に不安を感じる5つの疑問
MFAツールの導入前に「本当に信頼できるのか」と疑問を感じる担当者が気になる点は、主に5つのカテゴリーに整理できます。
信頼性の不安が生まれる背景と確認すべきポイント
MFAツールは「セキュリティを強化するための製品」ですが、そのツール自体のサービス品質や安全性が担保されていなければ、逆に業務リスクや情報漏えいリスクになりかねません。特にクラウド型のMFAツールは、ベンダーのクラウド基盤の安定性・セキュリティ体制・長期的なサービス継続性に自社の認証インフラが依存する構造になっています。このため「ベンダー自体の信頼性」は製品の機能と同等に重要な評価基準です。
信頼性に関する不安が生まれやすい5つの疑問として、(1) ベンダーのクラウド基盤がダウンした場合に全社員がログインできなくなる障害リスクはあるか、(2) MFAベンダー自体がサイバー攻撃を受けて顧客情報が漏えいした事例はあるか、(3) 利用していた無料MFAアプリが突然終了する可能性があるか、(4) 「〇万ユーザー導入」という実績表示は信頼できるのか、(5) 実際に利用しているユーザーからの悪い口コミには何があるか、が挙げられます。これらを一つずつ確認することで、信頼性リスクを客観的に評価できます。
- ■クラウド障害による業務停止リスク
- ベンダーのSLA（稼働率保証）を確認する。99.9%（月間ダウンタイム約44分）と99.99%（約4.4分）では年間の影響度が大きく異なる
- ■ベンダーへのサイバー攻撃リスク
- ISO 27001などのセキュリティ認証取得状況・脆弱性情報の公開・インシデント発生時の報告方針を確認する
- ■サービス終了・アプリ削除リスク
- ベンダーの設立年・資本関係・上場状況・サービスの継続年数などで長期安定性を評価する
- ■実績数値の誇大表示リスク
- 「〇万ユーザー」が企業ユーザー数か個人ユーザー数か・有料ユーザー数か無料含む数かを問い合わせて確認する
- ■実際の口コミ・障害報告の確認
- ITツール比較サイトのレビューやSNSで、ログイン障害・設定のしづらさ・サポート対応の遅さなどの悪い口コミが継続的に見られないか確認する
信頼性を評価するための事前確認リスト
MFAツールの信頼性を製品選定前に確認するには、無料トライアル申し込み前にベンダーに対して具体的な質問を書面（メール）で問い合わせる方法が有効です。書面での回答を求めることで、曖昧な回答を避けて正確な情報を引き出せます。確認すべき事項として、(1) SLAの稼働率保証値と補償内容（補償がない場合はその理由）、(2) 直近1年間の障害発生回数とその対応履歴が公開されているか（障害ステータスページのURLを教えてもらう）、(3) ISO 27001・SOC 2などのセキュリティ認証の取得状況と最新の審査日、(4) セキュリティインシデントが発生した場合の顧客への通知方法と通知までの目標時間、(5) サービス終了時のデータ移行支援の提供有無と期間を具体的に確認しましょう。
これらの質問に対して「詳細は契約後に開示」「個別のケースによる」という回答しか得られない場合は、透明性に課題があるベンダーと判断できます。回答の内容と回答速度の両方が、ベンダーの信頼性を示す重要な指標となります。無料トライアル期間中に問い合わせを行い、レスポンスの誠実さと正確さを確認してから導入を判断してください。
クラウドMFAの大規模障害リスクと業務停止への備え
クラウド型MFAツールを全社導入した場合、そのサービスが停止すると全社員がSaaSにもVPNにもログインできなくなる「単一障害点」のリスクがあります。この対策を事前に整備しておくことが重要です。
クラウドMFAで発生しうる大規模障害のパターン
クラウド型のIDaaS・MFAサービスは、ベンダーが運用するクラウド基盤（AWS・Azure・GCPなどのパブリッククラウドや自社データセンター）の上で動作しています。このクラウド基盤で障害が発生すると、そのサービスを利用している企業全体でMFA認証が機能しなくなります。過去に複数のクラウドサービスで、ベンダーのインフラ障害によって数時間から半日程度のサービス停止が発生した事例が報告されています。MFAが停止した場合の影響は、社内外のSaaSサービス（グループウェア・チャットツール・会計システムなど）へのログイン不能・VPN接続の停止・社内システムへのアクセス停止など、業務の全面停止に直結します。
この障害リスクを軽減するための対策として、(1) MFAツールのSLA（Service Level Agreement：稼働率の保証値）を確認し、99.9%以上の保証と補償内容を明確にする、(2) 障害発生時のフォールバック認証（緊急時に使える代替認証手段：バックアップコード・管理者が一時的に認証をバイパスできる手順など）の有無と手順を事前に整備する、(3) 複数の認証基盤を組み合わせる（例：クラウドMFAが停止してもオンプレミスADでの認証を維持できる構成にする）という3点が重要です。MFAツールの選定段階で「障害時の代替手段」を必ず確認してください。
SLAと障害ステータスページで信頼性を事前確認する方法
ベンダーのSLA（Service Level Agreement）は、サービスの月間稼働率を保証する契約上の基準です。SLA 99.9%は月間約44分・週間約10分のダウンタイムが許容範囲です。SLA 99.99%は月間約4.4分・週間約1分とより厳格な保証になります。また「稼働率99.9%を下回った場合のサービスクレジット（利用料の返還）の有無と条件」も確認が必要です。SLAの数値は高くても、補償がない場合はリスクが担保されていないことになります。
あわせて確認したいのが「障害ステータスページ（ステータスページ）」の公開有無です。信頼性の高いクラウドサービスは、「status.{ドメイン名}」のようなURLで現在の稼働状況と過去の障害履歴をリアルタイムで公開しています。このページが存在し、過去の障害記録が具体的な日時・原因・影響範囲・対応内容の形式で公開されているベンダーは、障害対応の透明性が高いと評価できます。障害ステータスページが存在しない・または障害記録が非公開のベンダーは、信頼性の透明性という点で慎重に評価することをおすすめします。
MFAベンダーへのサイバー攻撃と情報漏えいリスク
「セキュリティを守るためのMFAツールのベンダー自体がサイバー攻撃の被害を受ける」という事態は、現実に発生しうるリスクです。国内外のITセキュリティニュースでも、IDaaS・認証サービスベンダーへのサイバー攻撃の事例が報告されています。
MFAベンダーへのサイバー攻撃と顧客データへの影響
2022年には、大手IDaaSベンダーのOktaがサイバー攻撃者集団（Lapsus$グループ）による不正アクセスを受け、顧客企業のサポート情報が一部閲覧された可能性があることを公表しました。また2023年にも、Oktaはサポートシステムへの不正アクセスがあったとして、顧客企業のHTTPリクエストログが一部外部に流出した可能性があることを公表しています。このような事例は、MFAベンダー自体がサイバー攻撃のターゲットになり、顧客企業の情報に影響を与えた実例として広く報道されています。
MFAベンダーがサイバー攻撃を受けた場合の顧客への影響として、(1) 顧客企業のユーザーID・メールアドレスなどの個人情報が漏えいするリスク、(2) TOTP認証のシード値（認証アプリが6桁のOTPを生成するための元となる値）が外部に漏えいした場合、そのシード値を使って正規のOTPが生成され不正ログインに悪用されるリスク、(3) セッション情報・アクセストークンが漏えいして認証をバイパスされるリスクが考えられます。こうしたリスクを踏まえ、ベンダーのセキュリティ体制を選定段階で確認することが重要です。
ベンダーのセキュリティ体制を見極める方法
MFAベンダーのセキュリティ体制を評価するには、(1) ISO 27001（情報セキュリティマネジメントシステムの国際規格）・SOC 2（サービス組織のセキュリティ・可用性・機密性などを評価するアメリカの審査基準）・CSマーク（クラウド情報セキュリティ監査制度にもとづくマーク）などのセキュリティ認証の取得状況を確認する、(2) 脆弱性情報（CVE）が公開・報告された際にベンダーがどのような対応を行い、どのように顧客へ通知したかの履歴（セキュリティアドバイザリ）を確認する、(3) ベンダー自社のセキュリティポリシー・ペネトレーションテスト（侵入テスト）の実施状況がWebサイトで公開されているかを確認する、という3つのアプローチが有効です。
特にISO 27001の取得は、第三者機関による定期的な情報セキュリティ管理の審査を受け続けていることを意味するため、信頼性の目安になります。ただし「認証を取得している＝完全に安全」ではなく、インシデントが発生した際の対応の透明性と顧客への情報提供の速さも合わせて評価することが重要です。選定候補のベンダーに「直近で発生したセキュリティインシデントと対応内容を教えてください」と問い合わせ、回答の誠実さで信頼性を確認することをおすすめします。
無料MFAアプリの終了リスクと「導入実績」の正しい読み方
無料のMFAアプリを業務で利用している場合のサービス終了リスクと、ベンダーが主張する「〇万ユーザー導入」という実績数値の信頼性についても、導入前に確認しておきましょう。
無料MFAアプリの突然終了リスクと移行の現実
無料で提供されているMFA認証アプリは、開発元の判断によってApp StoreやGoogle Playからの削除・開発終了・有料化への移行が予告なく行われる場合があります。特に認知度の低い無料アプリや個人開発のアプリは、サポート体制・長期継続性のリスクが高い傾向があります。業務で利用しているMFAアプリが削除・終了した場合、登録済みの認証情報を新しいアプリに移行する作業が必要になります。この移行作業では、登録しているサービスごとに「MFAを一旦無効化して新しいアプリで再登録する」という作業が必要なため、登録サービスが多いほど移行工数が増大します。
この終了リスクを避けるには、(1) 大手テクノロジー企業が提供する認証アプリ（Microsoft Authenticator・Google Authenticatorなど）を選ぶ（終了リスクが比較的低く、バックアップや同期機能を利用できる場合もある）、(2) 業務用MFAとして利用するアプリは「ベンダーが管理する企業向け認証アプリ」を選び、個人が任意に選んだ無料アプリに依存しない体制を作る、(3) 認証アプリが変更になった場合の社内移行手順を事前に文書化しておくという3点が有効です。業務で使用するMFAアプリは、個人利用と同じ基準で選定せず、継続性・サポート体制・バックアップ機能を優先してください。
「〇万ユーザー導入」という実績表示を正しく読む方法
MFAツールの製品ページや営業資料で「〇万ユーザー導入」と表記されている場合、その数値が「企業ユーザー数」なのか「個人ユーザーを含む総アカウント数」なのか・「有料契約ユーザー数」なのか「無料版のアカウント数を含む数」なのかによって、信頼性の評価が大きく変わります。無料版の個人利用アカウントや試用目的のテストアカウントを含む合計数を「〇万ユーザー」と表示している場合、実際の企業導入件数はその数値よりも大幅に少ないことがあります。
実績数値の信頼性を確認するには、(1) 「ユーザー数」が企業・組織ユーザー数か個人ユーザーを含む総数かをベンダーに直接問い合わせる、(2) 「導入企業数」（アカウント数でなく法人単位の数）を確認する、(3) 「自社と同規模・同業種の導入事例を3件教えてください」と依頼して具体的な事例の有無を確認する、という方法が有効です。事例の公開に同意している企業が多いベンダーほど、実際の導入実績と顧客満足度が高い傾向があります。実績数値は参考情報として捉え、具体的な導入事例と照合して判断してください。
まとめ
多要素認証（MFA）ツールの「信頼性」への不安は、クラウド障害・ベンダーへのサイバー攻撃・無料アプリの終了・実績数値の誇大表示・悪い口コミの5つの観点から整理できます。SLA・セキュリティ認証・障害ステータスページ・具体的な導入事例を事前に確認し、信頼性の高いベンダーを選定することで、長期にわたって安全・安定なMFA運用が実現します。無料トライアル期間を活用して、サポートの誠実さも含めて評価してから導入を判断してください。
