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