あなたのMFA適用状況に潜む意外な事実
このブログはこちらの英語ブログ（2025年7月11日公開）の機械翻訳です。
ある質問には、単純に「はい」か「いいえ」で答えるのが一番です。たとえばレストランに電話して「午後2時に予約できますか？」と聞いたとき、返ってくる妥当な答えは「はい」か「いいえ」、もしくは「外の席ならご案内できますが、よろしいですか？」でしょう。
しかし、もしこう返ってきたら驚きませんか？ 「はい、ただし奇数人数のグループは店の前の席を、偶数人数は奥の席を予約してください。それと、白い服を着て、左足から入店してください。でないとお断りします。」
この場合、驚く理由は2つあります。1つ目は、「はい・いいえ」だけを期待していたのに長々とした答えが返ってきたこと。2つ目は、そもそもその条件が存在すること自体が変だということです。
実は、多要素認証（MFA）の適用状況もそれと似ています。「このアカウントはMFAで保護されていますか？」という問いに対し、誰もが「はい」か「いいえ」で答えられると思いがちです。しかし実際には、それほど単純な話ではありません。
あるケースでは、アプリにアクセスする際にMFAが求められますが、別の状況ではMFAなしでもアクセスできることがあります。これは意図的なこともあれば、気づかずに設定されてしまっている場合も多いのです。
問題の本質は「分断」にある
OktaのIdentity Security Posture Management（ISPM）のようなソリューションを選ぶ際に重要な機能の1つが、SaaSアプリ内のすべてのアカウントに対する認証シナリオと、それぞれの保護状態を追跡できることです。
単一のアイデンティティプロバイダーだけを使ってアプリを認証している場合は、これは簡単な作業です。しかし、以下のような要素が絡んでくると話は複雑になります：
- 様々な認証ポリシー
- 以前のアイデンティティソリューションからの移行
- Hub＆Spoke型の構成
- アプリごとに異なるログインルールやMFA適用ルール
こうした要因が複数のログインパターンを生み出し、それぞれを追跡・保護することがますます難しくなります。
このブログでは、そのような「分断」の原因となる要素と、その影響について詳しく掘り下げていきます。
サインイン時に存在する様々な認証方法
認証ポリシー（条件付きアクセスポリシー）は、ユーザーがアプリにサインインする際や特定の操作を行う際に、どの認証要素を要求するかを定義します。
MFAを要求しない理由はいくつかあります：
- プラットフォームによって利用できる認証要素が異なるため（結果として、特定アプリでしか使えないものも）
- 社用デバイスとBYODを区別するため
- サービスアカウントや非人間アイデンティティを例外とするため
- 機密性の低いリソースにアクセスする際は、MFA疲労を避けるために省略する
こうした理由により、アカウントがMFAで保護されているかという判断は、単純には決められないのです。
ポリシー設定ミスによる意図しない抜け穴
アイデンティティプロバイダーによって、認証ポリシーの設定方法は異なります。
- Oktaでは優先順位ベースでポリシーが適用されます。
- 一方、他のアイデンティティプロバイダーでは、グローバルポリシーの中で最も厳しいものを適用する方法が取られることがあります。
一見似ているように見えても、後者の方法では例外設定が非常に難しくなり、結果としてセキュリティ上のギャップが生まれやすくなります。
例は単純ですが、大規模な組織では数十のポリシーが設定されていることが多く、このような抜け穴が発生するのは珍しくありません（実際、他社の設定を分析していると頻繁に見つかります）。
また、一般的ではないプラットフォームでサインインすることは少ないですが、プラットフォームの判別はUser Agentをもとに行われるため、クレデンシャルスタッフィング攻撃では簡単に偽装される可能性があります。
代替ログイン手段
SSO（シングルサインオン）を導入する目的は、すべてのアプリへのアクセスを一元管理することですが、実際には同じアカウントに複数の方法でアクセスできることがあります。
直接ログイン
多くの場合、SSO（シングルサインオン）を通じてアプリケーションにアクセスできるアカウントは、ユーザー名とパスワードの組み合わせやアクセスキーを使って、アプリケーションに直接ログインすることも可能です。
これは、たとえば緊急時の管理者アクセスやアプリケーションのセットアップ中などの理由で、意図的にそのように設定されていることも多いですが、意図せずそうなってしまうこともあります。一部のサービスでは、SSOが設定されていても、ユーザーごとにパスワードアクセスを無効にする必要がある場合があります。また、別のサービスでは、管理者アカウントは常に直接ログインでき、無効化するオプションが用意されていない場合もあります。
ここで重要なのは、アプリケーションごとに動作が異なり、頼れる共通の挙動は存在しないという点です。あるアカウントにMFAが設定されていたとしても、SSO経由でログインした場合にもMFAを求めるアプリもあれば、ユーザーが直接ログインしたときにだけMFAを求めるアプリもあります。さらに、どちらの挙動を採用するか管理者が設定可能なサービスもあります。
複数のSSOプロバイダー
1つのアプリに対して複数のアイデンティティプロバイダーからログインできるケースもあります。これは以下のような理由で発生します：
- 部署やグループごとに異なるアイデンティティプロバイダーを使用しており、一部で重複している
- 古いアイデンティティソリューションの移行途中で、新しいアイデンティティプロバイダーは有効だが旧プロバイダーが無効化されていない
- 特定のアカウントやテスト環境用に設定されている構成
これらの構成は意図して設定されている場合もありますが、気づかれずに放置されている場合もあります。
認証要素の強度
これまでに述べてきた内容では、「MFAがあるか／ないか」を二択の問題として扱ってきましたが、実際はもっと複雑です。
SMSメッセージが乗っ取られやすく、フィッシング攻撃も蔓延している中で、組織によってはフィッシング耐性のある要素のみを強制する、あるいは従来のMFAそのものをやめてパスワードレス認証へ移行するという選択をすることもあるでしょう。
そのような取り組みを進めるには、各認証シナリオを精査する必要があります。なぜなら、それぞれのシナリオにおける認証の強度を正しく把握することが求められるからです。
このブログ記事では、MFA適用の背後にある複雑性を明らかにしました。認証ポリシー、複数のSSOプロバイダー、アプリケーションごとの動作の違いなど、単純な「はい／いいえ」では済まない要素が多く存在します。
このような複雑さに対処するには、組織全体で認証の標準を維持するための包括的な戦略を採用し、すべてのアカウントが適切に保護されているかを定期的に検証することが必要です。
OktaのIdentity Security Posture Management（ISPM）は、予期しない認証フローを可視化し、組織全体で一貫した認証基準の適用を実現するのに役立ちます。
※本ブログおよびその中の推奨事項は、法的・プライバシー・セキュリティ・コンプライアンスまたはビジネス上の助言を目的としたものではありません。最新の法令や状況を反映していない場合があります。実行の際は、必ず専門家にご相談ください。Oktaは、本内容を実行したことによる損害について責任を負いません。
以上の内容は、原文（英語）の機械翻訳であり、原文と内容に差異がある場合は、原文が優先されます。
