クイック・ヒント8: サインオン・ポリシーによる認証の管理

※ 本記事は、Paul Toalによる”Quick tip 8: Managing authentication through sign-on policies“を翻訳したものです。

最後のクイック・ヒントで、Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM)内で管理ロールにグループを割り当てる方法について説明しました。この投稿では、IAMのトピックにとどまり、認証に焦点を当てています。OCI IAMアイデンティティ・ドメインを使用して、既存のアプリケーションに簡単にマルチファクタ認証(MFA)を追加する方法について、以前に記事を執筆しました。サインオン・ポリシーは、そのプロセスの主要な要素です。

サインオン・ポリシーを理解して実装するのは比較的簡単ですが、次の例のような一般的な質問をいくつか尋ねます。:

• デフォルトのサインオン・ポリシーとその用途は何ですか。
• サインオン・ポリシー内に新しいルールを作成するのはいつですか。
• 新しいサインオン・ポリシーと新しいルールはいつ作成しますか。

この投稿では、サインオン・ポリシーについて明確に理解しながら、これらの質問に答えます。

まず、サインオン・ポリシーとその用途について簡単に説明します。既存のアプリケーションでMFAを有効にする投稿では、サインオン・ポリシーを使用して、保護されているアプリケーションにアクセスしようとするたびに、OCI IAMにMFAのチャレンジを強制しました。サインオン・ポリシーとは、本質的にそういうものです: ユーザーが認証を許可される状況(条件)と、それらの条件を満たしたときに認証(アクション)にチャレンジされる方法を制御する方法です。次のスクリーンショットは、サインオン・ポリシー内で条件とアクションがどのように連携するかを示しています。

前の投稿で、サインオン・ポリシーに1つ以上のルールを含めることができると説明しました。各OCI IAMアイデンティティ・ドメインには、デフォルトのサインオン・ポリシーが含まれています。

デフォルトのサインイン・ポリシーは何ですか。

デフォルトのサインオン・ポリシーは、独自のOCI IAMアイデンティティ・ドメインへのすべてのユーザー認証を制御するため、重要です。Oracle Cloudコンソールではデフォルトのアイデンティティ・ドメインが標準として使用されるため、コンソールでの認証もそのポリシーによって制御されます。このプロセスは、OCI IAMアイデンティティ・ドメインとOracle Identity Cloud Service (IDCS)のどちらを使用しているかにかかわらず同じです。アイデンティティ・ドメインを使用しないテナンシの場合、デフォルトのサインオン・ポリシーによってIDCS管理コンソールへのアクセスも制御されます。

新しいルールを追加するか、デフォルト・ルールを変更して、デフォルトのサインオン・ポリシーを変更できますが、削除できません。

注意: 変更する場合は注意してください。デフォルトのサインオン・ポリシーを変更し、間違ったIP範囲へのアクセスをロックダウンするなどのミスを犯した場合、テナンシからロックアウトされ、デフォルトのサインオン・ポリシーをリセットするためにサポート・リクエストを発行する必要があります。この問題を回避するために、同じブラウザの新しいタブまたはウィンドウだけでなく、変更をテストしながら、別のブラウザで管理セッションを開いたままにすることをお薦めします。

新しいルールはいつ作成しますか。

では、いつそのポリシー内にさらにルールを作成して、デフォルトのサインオン・ポリシー(または任意のポリシー)を変更しますか? ルールの目的は、処理と一連の条件を照合することです。一般的なユースケースには、次の例があります。:

• すべてのOCI IAM管理者は、MFAで認証する必要があります。
• ユーザーは特定のIP範囲からのみログインできます。
• 低リスクのスコアを持つユーザーのみがMFAなしでログインできます。
• 特定のサード・パーティのアイデンティティ・プロバイダを介して認証するユーザーは、ユーザーがアイデンティティ・プロバイダで完了した認証に加えて、MFAチェックが必要です。

このリストは網羅的ではありませんが、ポリシー内のサインオン・ルールを使用して実装できる様々なユースケースについて考えられます。リストの例を見てみましょう: 低リスク・スコアを持つユーザーのみが、MFAなしでOracle Cloudコンソールに対して認証できます。

最初に、デフォルトのサインオン・ポリシー内に新しいルールを作成します。このルールには、リスク・スコアが中または高のどのユーザーに対しても満たされる条件があります。

次に、その条件が満たされたときにアクションを「Prompt for an additional factor」に設定し、この例では、MFAオプションを特定のファクタのサブセットに制限します。

次に、サイン・オン・ルールの優先度を編集して、より限定的なルールがリストの最上部に表示されるようにします。

現在は、ユーザーがOCI IAMを介して認証しようとすると、認証ユーザーのリスク・スコアが評価されます。ユーザーが中または高のリスク・スコアを持つ場合、最初のルールではユーザーがMFAに対してチャレンジされる必要があり、続行するにはモバイル・オーセンティケータ・アプリケーションを使用する必要があります。

このサインオン・ポリシーはデフォルトであるため、認証のためにOCI IAMアイデンティティ・ドメインと統合されたすべてのアプリケーションに適用されます。

新しいサインオン・ポリシーと新しいルールはいつ作成しますか。

サインオン・ポリシーにルールを追加する理由を理解したので、新しいサインオン・ポリシーを作成する時期も理解する必要があります。サインオン・ポリシーはスコープがあると考えてください。サインオン・ポリシーを作成するときに、それを1つ以上のアプリケーション(スコープ)に割り当てることができます。

サインオン・ポリシーを編集する場合、サインオン・ルールを管理するためのタブに加えて、アプリケーションを管理するための「Apps」というタブがあります。ここでは、ポリシーを1つ以上のアプリケーションに割り当てます。デフォルトのサインオン・ポリシーはどのアプリケーションにも割り当てられず、特定のポリシーが割り当てられていないすべてのアプリケーションに適用されます。

そのため、代替サインオン・ポリシーを定義する場合は、新しいポリシーを作成します。代替サインオン・ポリシーには、様々な条件とアクションを含む異なるルールがあり、1つ以上の特定のアプリケーションで使用できます。

新しいポリシーを作成すると、アイデンティティ・ドメイン内にサインオン・ポリシーのリストが表示されます。

まとめ

サインオン・ポリシーは、ユーザーが認証にチャレンジされる方法と、統合アプリケーションへのアクセスを許可される状況を制御します。デフォルトのサインオン・ポリシーは、別のポリシーでカバーされないすべてのユーザーのアイデンティティ・ドメイン内の認証フローを管理します。他のサインオン・ポリシーを作成し、必要に応じて特定のアプリケーションに割り当てることができます。

この記事が役に立つと思います。詳細は、Oracle Cloud Infrastructure IAMアイデンティティ・ドメインのサインオン・ポリシーのドキュメントを確認してください。