ネクストモードのゆきなわです。
本ブログシリーズでは、ID ガバナンスに特化したソリューションである Okta Identity Governance (OIG) が提供する主要機能を、実践的なユースケースとともに紹介していきます。
今回は2025年3月に正式リリース（Generally Available）となった Realms（レルム、領域）機能を取り上げ、その概要から具体的な設定方法までを解説します。
Oktaでのユーザー管理において、以下のような課題でお悩みではないでしょうか。
Okta Identity Governance (OIG) の一機能である Realms（レルム）は、これらの課題に対する有力なソリューションの一つです。
Realms は Okta の Universal Directory 内のユーザーを論理的に分割する領域 (Realm) を作成する機能です。これにより、以下のようなメリットが得られます。
Realms を活用することで、組織のセキュリティポリシーに準拠した柔軟なユーザー管理と、適切な権限委譲によるガバナンス強化を実現できます。
以下の表に Realms 活用による具体的な効果を改めてまとめます。
| 観点 | 効果 | 備考 |
|---|---|---|
| 管理境界の明確化 | 管理者ごとにユーザー操作の対象を Realm 単位で制限できる | カスタム管理者ロールとリソースセットにより、最小権限の原則を実現 |
| ユーザーの分離 | 部門・子会社・委託先などのユーザーを論理的に切り分けて管理できる | アプリやグループは共通で使えるため、Okta org の統合管理と両立可能 |
| テナントの集約運用 | Okta org を分けることなく、1つのテナント内で複数の管理単位を扱える | Okta ライセンスや統合ログの管理負荷を抑えられる |
| Okta Identity Governance (OIG) 機能連携 | Access Certifications や Entitlement Management とスコープ連携できる | ガバナンス強化が必要な組織で効果を発揮（一部機能は未対応、後述） |
| 自動化対応 | Realm 作成・削除、ユーザー移動を Okta Workflows で自動化できる | OIG との組み合わせで効率的な運用が可能 |
前述のように、Realms はこれまでの Okta Universal Directory を補完する機能ですが、以下に示す通りいくつかの制約があります。
| 項目 | 制限内容 |
|---|---|
| ユーザー | ・各ユーザーは1つの Realm のみに所属できる ・同様の制約として Realm の階層化はできない |
| グループ | ・ユーザーとは異なり、グループ自体を Realm に所属させることはできない（グループを Realm で区切ることはできないが、グループ内で操作対象となるユーザーを Realm ごとに分離することができる） |
| アプリ | ユーザーやグループと異なり、アプリを Realm にアサインすることはできない |
| 各種ポリシー | ・認証ポリシーのルールで条件として指定する場合、Okta Expression Language (EL) での記述が必要 ・グローバルセッションポリシーのルール条件として利用できない |
| OIG 連携 | Access Certification、Access Requests は現時点（2025年4月）では非対応 |
| 最大数 | Realm は 1 orgあたり最大500個まで |
| デフォルト Realm | 削除・名前変更不可（既存ユーザーはこちらに自動的に割り当てられます） |
このような制約は存在するものの、カスタム管理者ロールと追加のリソースセット（アプリケーションやグループ）を組み合わせることで、きめ細かな権限委譲が可能です。これにより、特定の管理者は担当の Realm に対してのみ許可された操作を実行でき、最小権限の原則に基づいたセキュアな運用を実現できます。
ここからは、Okta を導入している企業 X 社（単一の Okta org を利用）を例に、具体的な Realms の活用シナリオを紹介します。
■シナリオ
X 社では、営業本部と開発本部それぞれに情シス担当者が存在している。
各情シス担当者には自部門のユーザーのみを管理させたい。
■Realms による解決方法
SalesRealm（営業本部）と DevRealm（開発本部）を作成■シナリオ
X 社では業務委託先の協力会社 A 社からの参画メンバーにアカウントを払い出して運用している。
A 社専任の管理者には社内ユーザーの情報等にはアクセスさせず、パスワードリセットやロック解除などのヘルプデスク業務のみ実施させたい。
■Realms による解決方法
VendorARealm）前述のユースケース 1 の例に沿い、X 社の営業本部に該当する Realm SalesRealm を作成し、営業本部情シス担当者にカスタム管理者ロールとリソースセットを割り当てる手順を紹介します。また、情シス担当者が Okta Admin Console でどのような管理操作ができるかについて、Okta org の全権限を持つスーパー管理者との画面比較を交えながら説明します。
ここでは説明を単純化するため営業本部向けの SalesRealm に絞っていますが、開発本部 DevRealm など他の組織単位に対しても同じ考え方で設定が可能です。
SalesRealmAdministrators とし、このグループに SalesRealm の管理を委譲する。SalesRealm の管理者には、以下の権限を含む管理者ロール SalesRealm Administrator を割り当てる。
SalesRealm のユーザー管理（表示、作成、削除、サインアウトなど）SalesRealm ユーザーの割り当てSalesRealm ユーザーの追加・削除設定は、1. Realm の作成、2. リソースセットの作成、3. カスタム管理者ロールの作成、4. 管理者グループへの割り当ての4つのステップからなります。全て Super Administrator（スーパー管理者）または Organization Administrator（Org 管理者）の管理者ロールを持つユーザーによる Okta Admin Console での操作となります。
SalesRealm を設定Security > Administrators > Resources に移動
Create new resource set をクリック
Name: SalesRealm Resource Set を設定
Add resource をクリックし、下記リソースを追加
| リソースタイプ | リソース | 備考 |
|---|---|---|
| Realm | SalesRealm | Realm へのユーザー追加などに必要 |
| Users | SalesRealm | ・Select users で Users in Realm から追加 ・ユーザー管理に必要 |
| Applications | All applications | ・アプリケーションへの割り当てに必要 ・部門利用のアプリケーションに限定するなどの設定も可能 |
| Groups | All groups | ・グループメンバシップの管理に必要 ・部門利用のグループに限定するなどの設定も可能 |
Create を押下して保存
Security > Administrators > Roles に移動
Create new role をクリック
Role name: SalesRealm Administrator を設定
以下の権限 (Permissions) を追加（全5権限）
| No | 権限名 | カテゴリ | 備考 |
|---|---|---|---|
| 1 | Manage users | User | ユーザー操作に関する全権限を許可 |
| 2 | View groups and their details | Group | Org へのグループの作成とアプリケーションへのグループ割り当ては制限 |
| 3 | Manage group membership | ||
| 4 | Manage realms | Realms | Realm へのユーザー作成に必須 |
| 5 | Edit application's user assignments | Application | ユーザーへのアプリケーション割り当てに限定 |
Save role を押下して保存
SalesRealmAdministrators を設定SalesRealm Administrator と SalesRealm Resource Set を設定以上で設定は完了です。
営業本部情シス担当者グループ SalesRealmAdministrators に所属する管理者ユーザーとして Okta Admin Console にログインし、グループを通じて本ユーザーに設定済みの権限（管理者ロール SalesRealm Administrator ）の動作を確認してみます。
以下の図では、左側に設定した権限での表示を、右側には比較用として Okta org の全権限を持つ Super Administrator の管理者ロールでの表示を示しています。
ユーザー (Directory > People)
SalesRealm Administrator では SalesRealm 所属のユーザー（2ユーザー）とログインしている管理者ユーザーのみが表示されます（今回の設定では管理者自身は SalesRealm に所属していません）。Super Administrator では Org の全ユーザが表示されます。グループ (Directory > Groups)
SalesRealm Administrator では SalesRealm 所属のユーザーとログインしている管理者ユーザーのみが表示され、本 Realm 外のユーザーは不可視となります。また、グループメンバシップの操作は SalesRealm 所属のユーザーに限定されます。Super Administrator では、187 中 187 となっており、全ユーザーが表示・操作の対象となります。Super Administrator ではアプリケーションに関する全ての操作タブが表示されているのに対して、管理者ロール SalesRealm Administrator では割り当ての操作タブのみが表示されています。ユーザー・グループの動作と同様に、SalesRealm Administrator では SalesRealm 所属のユーザーとログインしている管理者ユーザーへのみアプリケーションの割り当てが可能であるのに対し、Super Administrator は全ユーザーへの割り当てが可能です。本記事では、Okta Identity Governance の Realms 機能について、その概要から設定例までを解説しました。
Realms は、単一の Okta テナント内でユーザーグループを論理的に分割し、部門別管理や委託先管理といったニーズに応えるための有効な機能です。カスタム管理者ロールやリソースセットと組み合わせることで、管理権限を特定の範囲に限定し、ゼロトラストの要素として不可欠な最小権限の原則に基づいたセキュアなガバナンス体制の構築を支援します。
いくつかの制限事項はありますが、適切な権限委譲と管理境界の明確化が求められる多くのユースケースにおいて、Realms は組織のセキュリティポリシー遵守と効率的なユーザー管理の両立のためにご活用いただけると考えています。
OIG シリーズでは、これからも Okta Identity Governance の多様で便利な機能を紹介していきます。ぜひ、今後の記事もチェックしてください。
Okta Identity Governance の導入、実践的な活用方法、ライセンス体系や価格についてさらに詳しく知りたい方は、ぜひ弊社窓口までお気軽にお問い合わせください。