IGA 機能: エンタイトルメント管理
この記事は https://docs.evolveum.com/iam/iga/capabilities/entitlement-management/ の翻訳です。
別名
- グループ管理
- 権限管理
エンタイトルメント管理機能
- エンタイトルメントライフサイクル管理。 エンタイトルメント（グループなど）の作成、変更、削除。
- エンタイトルメント関連付けの維持管理。 ユーザーアカウントとエンタイトルメントの関係の保守。たとえばグループメンバーシップの保守。 関連付け属性（例: グループメンバーシップ属性）の解釈。
概要
エンタイトルメント管理は、アイデンティティとエンタイトルメントの間の関連付けを扱います。 エンタイトルメントはアイデンティティに割り当てられ、特定の資産や操作へのアクセスをアイデンティティに与えます。 これらは通常、グループ、権限、アクセス制御リストへの関連付け、低レベルのシステムロールなどです。 簡単に言えば、エンタイトルメント管理は「誰が何にアクセスできるのか」という問いを扱います。
エンタイトルメント管理には2つの主要な機能があります。 第一に、エンタイトルメントライフサイクルを管理します。 エンタイトルメント管理は、必要に応じてグループや類似のエンタイトルメントを作成・削除できます。 第二に、エンタイトルメント管理はグループメンバーシップやシステム権限の割り当てなど、エンタイトルメント associations を管理します。
包括的な IGA 導入では、エンタイトルメント自身がアイデンティティになり得ますし、その逆もあります。 たとえば、ユーザーの組織メンバーシップでは、組織（アイデンティティ）がユーザーに割り当てられたときエンタイトルメントと見なされます。 一方で、ロール（エンタイトルメント）はアイデンティティと見なされることがあります。たとえば LDAP グループやアプリケーションロールと自動的に同期される場合です。
エンタイトルメント、ポリシー、フルフィルメントの曖昧さ
エンタイトルメント管理は通常、より低いレベルで機能し、グループ、filesystem 権限、アプリケーション権限など、アプリケーション、サービス、ディレクトリに関連する概念を扱います。 Business role のような高レベル概念がエンタイトルメント管理の対象なのか、それともエンタイトルメント管理を駆動するポリシーの一部なのかには曖昧さがあります。 厳密に言えば、IGA の文脈ではビジネスロールは 誰が何にアクセスできるか を指定するのではなく、誰が何にアクセスすべきか を指定します。 したがって、ビジネスロールは運用上の現実（is）よりも policy（should be）に近いものです。 それでも、ロール と entitlement の概念の解釈と実装はシステムごとに異なります。
次の表は、高レベルのポリシー概念から低レベルの権限まで、エンタイトルメント spectrum の概要を示しています。
| レベル | 説明 | 用語 | 例 | 管理場所 |
|---|---|---|---|---|
| Highest | 業務（非IT）言語で指定される純粋な業務概念 | Roles | 純粋なビジネスロール（他のロールから構成され、エンタイトルメントからは構成されない） | IGA プラットフォーム |
| High | 単純な IT 上の概念を含むことがある業務概念 | Roles | Hybrid ビジネスロール（他のロールとエンタイトルメントから構成される） | IGA プラットフォーム |
| Mid | IT 上の概念と業務概念の混在 | Roles | IT ロール、技術ロール | IGA プラットフォーム |
| Low | IT 上の概念。場合により一部業務概念を含む | Entitlements, Application roles | アプリケーションロール、nested LDAP グループ、アプリケーション内の階層的またはパラメトリックな「ロール」や権限 | 対象システム。任意で IGA プラットフォームへ同期 |
| Lowest | 純粋な IT 上の概念。多くの場合 OS、filesystem、ネットワークを参照 | Entitlements | OS グループ（UNIX グループ）、単純な LDAP グループ、Active Directory セキュリティグループ、filesystem 権限、データベース権限、アクセス制御リスト（ACL）を参照する属性価値 | 対象システム |
同様に、エンタイトルメント管理が扱う詳細の深さにも曖昧さがあります。 たとえば、LDAP グループと LDAP アカウントを関連付ける属性の名前や形式がエンタイトルメント管理の関心事なのか、それともフルフィルメント機能の責任なのかは明確ではありません。 厳密に言えば、フルフィルメントは対象システムへの変更の伝播を扱い、グループメンバーシップはしばしば情報ソースです。 したがって、関連付け属性の管理はエンタイトルメント管理の責任だと考えます。
ここでは、曖昧さを次のように解決します。
- エンタイトルメント管理 は reality（誰が何にアクセス しているか）を扱います。 エンタイトルメントは、低レベルの権限、OS グループ、アクセス制御リスト、それらが使う属性価値など、ポリシー強制に直接使われるデータ構造です。 エンタイトルメントは通常、すべての操作に対してシステムによって評価されます。 または login 時間に評価され、ユーザーセッションの間キャッシュされることもあります。 エンタイトルメントはポリシー強制に直接使われるため、エンタイトルメントが現実と不整合になる可能性はほぼありません。 エンタイトルメントは通常 application-specific です。 グループ construction、維持管理（例: nested グループを作成する能力）、アクセス制御リスト言語、強制ルールの方法は、アプリケーションごとに異なる場合があります。
- ポリシー管理 は policy（誰が何にアクセス すべきか）を扱います。 ポリシー概念はポリシー強制に直接使われるわけではなく、現実に間接的に影響します。 たとえば、IGA の文脈における business role は、直接のポリシー強制には使われません。 ビジネスロールは通常、ポリシー強制の目的で account と entitlement（グループ、権限）へ変換されます。 ポリシー概念（ロールなど）は直接使われないため、ポリシーが現実と不整合になる可能性があります。 たとえば、ユーザーアカウントがポリシーに基づかないエンタイトルメントを持っている場合があります。 したがって、ポリシーと現実が一致していることを保証するために、reconciliation のような synchronization プロセスが必要です。 ポリシー概念は通常汎用で application-agnostic です。 ポリシーは、接続されたすべてのアプリケーションに対して同じ原則と言語で表現されます。
- アカウント属性とエンタイトルメント属性の操作はフルフィルメントの責任ですが、エンタイトルメントを管理するためにどの属性をどの値へ変更する必要があるかを知ることはエンタイトルメント管理の責任です。 たとえば、グループに member 属性があることを知るのはフルフィルメントの責任です。 フルフィルメントはまた、適切な操作とプロトコルなどを使って属性を変更する責任も持ちます。 しかし、この属性がグループメンバーシップを表す association 属性であることを知るのはエンタイトルメント管理の責任です。 エンタイトルメント管理はまた、この属性にはグループの メンバーであるアカウントのユーザー名が含まれるべきこと、アカウントは最大1回だけ メンバーになれること、グループは ネストできないこと、などを知る責任があります。