はじめに
タイトル通りですが、本記事では OCI コンソールへのログインを送信元IPで制限する手順についてまとめていきます。
番外編としてデフォルト Sign-on policy の挙動を記載してますので良かったらのぞいてみてください
概要
実現方法は非常に簡単で、Sign-on policy と Network perimeter を組合せて実現 します。
共に Identity Domain 毎に適用するコンポーネントです。
Network perimeter は、Sign-on policy にて定義するルール内の条件値として利用します。
Sign-on policy は、名前の通りで OCI コンソールへのログインを許可/拒否するルールをまとめたものです。
適用対象は、定義したルールにもよりますが、以下となります。
- ポリシーを定義した Identity Domain で管理している特定IAMグループ
- ポリシーを定義した Identity Domain で管理している全IAMユーザー (特定IAMユーザー除外も可)
- ポリシーを定義した Identity Domain で管理している特定アプリケーション
使用方法(デモ)
検証構成
検証構成図は以下の通りです。
- 環境構築コードは以下 GitHub にあげてますので、よかったら覗いてみてください
実践
Network perimeter 作成
まず Network perimeter を作成します。
OCI コンソール左上のハンバーガーマークをクリックし、「Identity & Security」→「Domains」をクリックします。
制限したいユーザーが所属する Identity Domain をクリックします。
「Security」タブを選択し、「Create network perimeter」をクリックします。
任意の名前と、今回は許可するアドレス帯を入力し「Create」をクリックします。
今回はこちらを参考に自宅のGIPを指定しています。
アドレス帯の記載ルールは下記参照ください。
Security Policy for OCI Console のルール変更
続いて、Security Policy for OCI Console のルール変更をします。
先程と同じ Identity Domain の「Domain policies」タブを選択し、「Security Policy for OCI Console」をクリックします。
上記ポリシーを選択する理由はこちらを参照ください
「Sign-on rules」を選択し、「MFA for all users」の「…」→「Edit sing-on rule」をクリックします。
「ポリシーミスったらコンソールログインできなくなるから注意してね」ってニュアンスの確認ポップアップがでるので「Continue」をクリックします。
画面中部に位置する「Filter by client IP address」を「Anywhere」から「Restrict to the following network perimeters」に変更し、先程作成した Network perimeter を選択します。
他設定は編集せず、画面最下部まで移動します。
すると、「この変更で何か損害があってもOracleは保証しませんよ」ってニュアンスの文章に同意するチェックボックスが表示されます。
チェックを入れ、任意の理由を選択し、「Edit sing-on rule」をクリックします。
- 上記の設定により、「Administratorsグループ以外の全ユーザー」かつ「指定のIPアドレス」がルールにマッチし、「MFA認証成功」でOCIコンソールにログイン可能となります
- ただし、こちら にも記載の通り、ポリシー内のルールは若番から評価され、マッチしたルール以降のルールは評価されません
- そのため、商用などでは、Administratorグループがマッチする「MFA for administratorsルール」にも同様の設定を入れることを推奨します
動作確認（成功パターン）
それでは成功パターンを確認します。
検証用ユーザーで以下のようにログインを試行します。
問題なくログインできますね。
動作確認（失敗パターン）
続いて失敗パターンを確認します。
Network perimeter の値を、適当な値に修正します。
この状態で検証用ユーザーで以下のようにログインを試行します。
MFA認証する前に拒否されました。
動きとしては、こちらにも記載の通り、どのルールにもマッチせず、暗黙の拒否となります。
おわりに
本記事では OCI コンソールへのログインを送信元IPで制限する手順についてまとめました。
AzureやGCPは存じ上げませんが、AWSで同様のことをするならばコンソール自体の制限はできず、ログイン後の権限剥奪という形での制限となります。
対してOCIにはコンソールへのログインを制御するポリシーが用意されており、比較的導入も容易のため、商用環境での利用時は積極的に導入することをおすすめします。
🌟この記事が誰かの役に立てば幸いです！
また、ご質問やフィードバックもお待ちしています。
番外編
デフォルトで存在する Sign-on policy には役割が決まっている
Identity Domain には、作成時から存在する Sign-on policy があります。
各ポリシーには役割があり、OCI側で固定されています。
- Default Sign-On Policy
- Security Policy for OCI Console
- User Category Based SignOn Policy
Default Sing-On Policy
こちらは、OCIコンソールへの初回ログイン時に適用されるポリシーです。
つまり、本ポリシー内のルール定義にて、OCIコンソールへの初回ログインを制御することが可能です。
- 本ポリシーの削除は不可。ただし、非アクティブ化は可能
- ポリシー内デフォルトルール編集は可能。ただし、削除は不可
- ポリシー内への新規ルール追加可能
- ルール優先度変更可能
例えば、本ポリシー内にて アクションを拒否とするルールが最優先される場合、もしくは、本ポリシーが非アクティブ化されている場合、以下の通り、初回ログインにてPW設定完了後、アクセスが拒否されます。
Security Policy for OCI Console
リリースノート より、本ポリシーは比較的新しいものとなります。
2025年10月1日以降に OCI テナンシを開設した方は、明示的にアクティブ化する必要があります
こちらは、OCIコンソールへの初回ログイン完了以降、OCIコンソールへログインする際に適用されるポリシーです。
つまり、本ポリシー内のルール定義にて、OCIコンソールへのログインを制御することが可能です。
本ポリシーの挙動についは、前述していますので割愛します。
- 本ポリシーの削除は不可。ただし、非アクティブ化は可能
- ポリシー内デフォルトルール編集/削除は可能
- ポリシー内への新規ルール追加可能
- ルール優先度変更可能
User Category Based SignOn Policy
こちらは OCI 内部アプリケーションの挙動に適用されるポリシーです。
私自身、使い道がよくわからず動作確認の掲載は割愛しますが、最近導入された Sign-on policy です。
- 本ポリシーの削除 及び ポリシー内デフォルトルール編集/削除は可能
- ポリシー内への新規ルール追加可能
- ルール優先度変更可能
ユーザー独自の Sign-on policy は特定アプリケーションに紐づけるためにしか利用できない
上述したデフォルトポリシーとは別で、ユーザー独自の Sign-on policy を作成することが可能です。
ただし、このカスタムポリシーが適用されるのは、指定したアプリケーションのみとなります。
Sing-on policy 内のルール評価順序
ポリシー内のルールにはPriorityが定義されており、若番から順に評価されます。
若番から評価され、マッチしたルール以降のルールは評価されません。
仮にマッチするルールがない場合は、ルールアクションとしては拒否される動きとなります。
例えば、Security Policy for OCI Console の２つ目のルールは、元々全ユーザーがマッチする設定となっていますが、検証として指定ユーザーを除外しています。
この場合、指定ユーザーはどのルールにもマッチしないことになります。
この状態で、サインインを実行すると、ログインができません。
