こんにちは、k.katoです。
今回は、「ネットワーク・ペリメータ」と「ネットワーク・ソース」の違いについて整理してみます。
そもそも何が違うの？
2つは名前が似ていますが、機能するレイヤーが異なります。整理するとこうなります。
| ネットワーク・ペリメータ | ネットワーク・ソース | |
|---|---|---|
| 機能するレイヤー | 認証（Authentication） | 認可（Authorization） |
| いつ評価されるか | OCIコンソールへのサインイン時 | OCIリソースへのAPIリクエスト時（コンソール操作・CLI・SDKすべて含む） |
| 何の設定と組み合わせるか | Identity Domainのサインオン・ポリシー | IAMポリシーの条件句 |
| 設定場所 | アイデンティティ・ドメイン > セキュリティ | アイデンティティおよびセキュリティ > ネットワーク・ソース |
以降で、それぞれをもう少し詳しく説明します。
ネットワーク・ペリメータとは
ネットワーク・ペリメータは、Identity Domain（アイデンティティ・ドメイン）の機能です。
「OCIコンソールにログインする」という操作は、「Identity Domainへの認証（サインイン）を行う」ことを意味します。コンソールのURLにアクセスしてユーザー名・パスワードを入力する一連のプロセスは、Identity Domainが管理しています。
ネットワーク・ペリメータは、このサインイン（認証）のタイミングで評価されます。具体的には、Identity Domainの「サインオン・ポリシー」のルール条件として使用します。
ユーザーがIdentity Domainへサインインする際に、どのような条件のとき・どのような認証（MFAなど）を要求するかを定義するポリシーです。ルールは優先度順に評価され、最初に条件が一致したルールのアクションが適用されます。
設定場所
例えば、「社外のIPアドレスからのサインインは拒否する」という制御を実現したい場合、以下の流れで設定します。
1. ネットワーク・ペリメータで「許可するIPアドレス」または「拒否するIPアドレス」の範囲を定義する
2. サインオン・ポリシーのルールに、作成したネットワーク・ペリメータを条件として割り当てる
3. 条件に一致した場合のアクション（許可 / 拒否 / MFA要求）を設定する
⚠️ 注意
デフォルト・ドメインのAdministratorsにネットワーク・ペリメータをつける際は、ブレーク・ガラスのOCI仕様も把握しておきましょう。
ネットワーク・ソースとは
ネットワーク・ソースは、IAMポリシーの機能です。Identity Domainがログイン（サインイン）の管理を担うのに対し、IAMポリシーはログイン後に「どのリソースで何ができるか」の権限を管理する仕組みです。ネットワーク・ソースはこのIAMポリシーの中で機能します。
こちらが制御するのは、「認証済みのプリンシパルがOCIリソースを操作する際の認可」です。CLI・SDK・REST APIはもちろん、コンソール上でのぽちぽち操作も内部的にはREST APIが走っているため、すべてが評価の対象になります。
ネットワーク・ソースは、IAMポリシーの条件句として参照します。
例えば、「社内ネットワークからのリクエストのみ、インスタンスの操作を許可する」といった制御が可能です。
設定場所
OCIコンソールのナビゲーション・メニューから、以下の順に進みます。
アイデンティティおよびセキュリティ → ネットワーク・ソース
ネットワーク・ソースには、パブリックIPアドレス（CIDR表記含む）とVCN内のIPアドレスの2種類を指定できます。VCNを指定する場合は、VCNのOCIDとサブネットのIPアドレス範囲を組み合わせて設定します。
アイデンティティおよびセキュリティ → ポリシーで、作成したネットワーク・ソースを用いたポリシーステートメントを記述する
セキュリティ設計での注意点
① ネットワーク・ペリメータはCLI・SDK・REST API操作に効かない
ネットワーク・ペリメータは、CLI・SDK・REST APIによる操作には効きません。
評価されるのは「Identity Domainへのサインイン（コンソールへのログイン）」のタイミングだけです。
APIキーを使ったCLI操作やSDKによるリソース操作は、Identity Domainのサインインを経由しないため、ネットワーク・ペリメータの設定は関係しません。
「社外からのコンソールアクセスをネットワーク・ペリメータで制限した」としても、APIキーさえ持っていれば社外からCLI/SDKでリソース操作が可能な状態が続きます。セキュリティ要件が厳しい場合は、ネットワーク・ソースをIAMポリシーに組み込む制御もあわせて検討してください。
（もしくはAPIキー等を作らせない、根本的な対処として、各ユーザーの「ユーザ機能の編集」からローカルパスワード以外の不要な機能をOFFにする、などを検討する必要があります。）
② ネットワーク・ソースの管理ポリシーはルート・コンパートメントに置く必要がある
ネットワーク・ソースはテナンシレベルのリソースのため、管理権限のポリシーは in tenancy と記述する必要があります。
この記述はルート・コンパートメント上にあるポリシーにしか書けません。（子コンパートメントでin tenancyは指定不可）
コンパートメント単位でポリシーを分けて管理する設計をしている場合、ネットワーク・ソースの管理ポリシーはルート・コンパートメントに置く必要がある点に注意してください。
❌ allow group SecurityAdmins to manage network-sources in compartment SomeCompartment
終わりに
ネットワーク・ペリメータとネットワーク・ソースは、どちらもIPアドレスによるアクセス制限を実現する機能ですが、機能するレイヤーが異なります。
- ネットワーク・ペリメータ → コンソールへのサインイン（認証）を制御。Identity Domainのサインオン・ポリシーと組み合わせて使用します。
- ネットワーク・ソース → OCIリソースへのAPIリクエスト（認可）を制御。IAMポリシーの条件句として使用します。
コンソールアクセスだけを制限したい場合はネットワーク・ペリメータで十分ですが、CLI/SDKも含めてリソース操作を制御したい場合は、ネットワーク・ソースが必要です。セキュリティ要件の高い環境では、両方を組み合わせることで多層的な制御が実現できます。
最後までお読みいただき、ありがとうございました！この記事が皆様の設計・運用の参考になれば幸いです。