このブログはこちらの英語ブログの機械翻訳です。
はいまたはいいえの答えだけが必要な質問もあります。レストランに電話して、「午後2時に予約できますか？」と尋ねると、妥当な回答は「はい」、「いいえ」、または「屋外席しかありません。大丈夫ですか？
おそらく、次のようなことを聞くと驚かれるでしょう。「はい、ただし、奇数のグループはレストランの正面の席を予約し、偶数のグループは奥の席を予約する必要があります。」また、白い服を着て、左足でレストランに入ってください。そうしないと、入店を拒否されます。」
ここで驚くのは二重の意味で、まず、これほど長い答えを期待していなかったこと、そして、そもそもそのような条件が存在するはずがないように思えることです。
多要素認証（MFA）の実施も同様の働きをすることがわかります。「このアカウントはMFAで保護されていますか？」という質問に対して、単純なYes / Noの答えを期待するかもしれませんが、現実はそれよりもはるかに複雑であることがよくあります。多くの場合、一部のシナリオではアプリへのアクセスにMFAが適用されますが、別のシナリオではMFAなしでアクセスが許可されます。意図的な場合もあれば、そうでない場合もあります。
断片化の問題点
Okta Identity Security Posture Management のようなソリューションで注目すべき主要な機能の 1 つは、SaaS アプリ内のすべてのアカウントにつながるすべての認証シナリオを追跡し、それぞれが伴う保護ステータスを理解する機能です。
これは、単一のIDプロバイダーのみを許可してアプリケーションを認証する場合に簡単なタスクです。ただし、さまざまな認証ポリシー、以前のIDソリューションからの移行、ハブアンドスポークモデル、および直接サインインとMFAの実施に異なるルールを適用するさまざまなSaaSアプリを追加すると、はるかに複雑になります。これらすべてにより、複数のサインインシナリオが発生し、それらすべてを追跡および保護することがより困難になります。
このブログ投稿では、これらの断片化の多くの原因をより深く掘り下げ、それらが潜在的に与える影響を探ります。
認証ポリシー
認証ポリシー（多くの場合、条件付きアクセス ポリシーと呼ばれます）は、ユーザーがアプリにサインインしたり、特定のアクションを実行したりする際に、要素の要件を適用するために使用されます。
さまざまな種類の要素を許可する（またはMFAなしでサインインを許可する）理由はたくさんあります:
- プラットフォームが異なると、さまざまな要素を使用できます（その結果、一部のプラットフォームは特定のアプリケーションでのみアクセスできる場合があります）。
- 会社所有デバイスとBYODの区別
- サービスアカウントと非ヒューマンアイデンティティの免除
- MFAの疲労を軽減するために、機密性の低いリソースにアクセスする際にMFAを要求しない
当然ながら、アカウントの実施状況を表示する際には、要件の相違点を考慮する必要があります。
ポリシー構成の偶発的なギャップ
IDプロバイダーが異なると、認証ポリシーをさまざまな方法で構成できます。
Oktaでは、認証ポリシーの設定に優先順位ベースのモデルを使用していますが、他のプロバイダーでは、「最も厳しい」アクションが有効になる「グローバル」ポリシーを設定します。
どちらの方法も表面上は同じように聞こえますが、2番目の方法では、すべてのポリシーから例外を切り出すことがはるかに難しくなり、多くの場合、セキュリティギャップが生じます。
この例は単純で、少数のポリシーのみを構成する場合はありそうにありませんが、覚えておく価値があります。
- 大規模な組織では、多くの場合、数十ものポリシーが実施されており、そのようなケースを見落とす可能性があります（他のIDプロバイダーで設定された条件付きアクセスポリシーを分析する際に、実際にそのようなギャップが頻繁に見られます）。
- サインイン時に一般的でないプラットフォームを使用する可能性は低いですが、プラットフォームの条件はユーザーエージェントを使用して評価されます。ユーザーエージェントは、クレデンシャルスタッフィングキャンペーン中に簡単かつ一般的にスプーフィングされます。
代替ログイン方法
シングルサインオン（SSO）の推進力は、すべてのアプリケーションへのアクセスを1つの場所から管理できることですが、特定のアプリケーションの特定のアカウントにアクセスする方法は複数あることがよくあります。これらのケースのいくつかを確認しましょう。
ダイレクトログイン
多くの場合、SSO経由でアプリケーションにアクセスできるアカウントは、(ユーザー名とパスワードの組み合わせを使用するか、アクセスキーを使用して)アプリケーションに直接ログインすることもできます。
多くの場合、意図的な選択(たとえば、緊急管理者アクセスを許可したり、アプリケーションのセットアップ時)ですが、意図せずに発生することがあります。一部のサービスでは、SSOが設定されていても、パスワードアクセスをユーザーごとに無効にする必要がある場合があります。他のサービスでは、管理者アカウントは常に直接ログインできます。オフにするオプションはありません。
重要なことは、各アプリケーションの動作が異なり、依存できる普遍的な動作はないことを理解することです。MFAがアカウントに構成されている場合でも、一部のアプリケーションでは、ユーザーがSSO経由でサインインした場合でも、MFAを要求しますが、ユーザーが直接サインインした場合にのみMFAを要求するアプリケーションもあります。他のサービスでは、どちらの動作が発生するかを構成できる場合もあります。
複数のSSOプロバイダー
多くの場合、アプリケーションの一部のユーザーアカウントには、複数の Identity Provider を使用してアクセスできます。このようなケースは、次の理由で発生する可能性があります。
- 異なるIDプロバイダーを使用する異なる子会社または部門があり、重複が発生する可能性があります
- 移行によって新しいIDプロバイダーが有効になったが、古いIDプロバイダーが無効になっていない、以前のIDソリューションからの残り物
- 特定のアカウントで使用される、または組織全体を登録する前に使用されるテスト構成
場合によっては、これらの複数のプロバイダーが既知で説明されていることがあります。また、これらの設定が隠されていて見落としやすいこともあります。
要素の強度
これまで説明してきたことはすべて、「MFA/No-MFA」を二項対立の問題として扱ってきましたが、現実はそれよりも複雑です。
SMS メッセージは乗っ取りやフィッシング攻撃を受けやすいため、組織はフィッシング耐性のある要素のみを強制するか、パスワードレスに移行することを好む場合があります。
そのような取り組みには、さまざまな認証シナリオを精査する必要があります。それは、それぞれの認証強度を理解することにつながるからです。
このブログ記事では、MFA の強制の背後にある複雑さを明らかにしました。認証ポリシー、複数の SSO プロバイダー、アプリケーションの動作の違いなどの要因により、単純な yes/no ステータスとは言えません。
この複雑さがもたらす課題に対処するために、組織の認証標準を維持し、すべてのアカウントが適切に保護されていることを定期的に確認するための包括的な戦略を採用することをお勧めします。Okta Identity Security Posture Managementは、予期しない認証フローを可視化し、組織全体の認証の一貫した標準を保証するのに役立ちます。
このブログ投稿について質問がありますか？eng_blogs@okta.comまでご連絡ください。
Oktaのより洞察力に富んだエンジニアリングブログを読んで、知識を広げましょう。
優秀なエンジニアで構成された情熱的なチームに参加しませんか？採用ページをご覧ください。
組織の最新かつ高度な Identity Management の可能性を解き放ちます。詳細については、セールスにお問い合わせください。
このブログおよびブログ内の推奨事項は、法的、プライバシー、セキュリティ、コンプライアンス、またはビジネスに関するアドバイスではありません。このブログは、一般的な情報提供のみを目的としており、最新のセキュリティ、プライバシー、法的な展開、または関連するすべての問題が反映されているとは限りません。本資料の利用者は、自身の責任において、自身の弁護士またはその他の専門アドバイザーから法律、セキュリティ、プライバシー、コンプライアンス、またはビジネスに関する助言を得るものとし、本書に記載された推奨事項に依存すべきではありません。本資料に記載された推奨事項を実施した結果生じるいかなる損失または損害に対しても、Oktaは責任を負いません。Oktaは、これらの資料の内容に関して、いかなる表明、保証、またはその他の保証も行いません。
