More than 3 years have passed since last update.

midPoint by OpenStandiaAdvent Calendar 2019Day 6

midPointにおける「エンタイトルメント管理」「ポリシーとロール管理」を解説する

Last updated at 2020-01-06Posted at 2019-12-05

はじめに

midPointアドベントカレンダー6日目はIGAの主要な要素である、エンタイトルメント管理とポリシーとロール管理について、一般的な意味とIGAの概念の説明、またmidPointでどのように実現していくのかをご紹介したいと思います。

エンタイトルメント管理とは

一般的にエンタイトルメントは「資格」や「権利」といった意味で使われます。様々なビジネスシーンで使われるエンタイトルメント管理ですが、サポート業務のプロセスを例として説明します。

1.　顧客がサポート契約を行い、サポートエージェントが顧客のエンタイトルメント情報を作成します。
2.　この顧客がサポートを受けるため、サポートエージェントに質問を行います。
3.　エージェントは、この顧客が有効なエンタイトルメントがあるかを確認します。
4.　エージェントはエンタイトルメント情報に合わせて適切なサービスレベルで対応を行います。

上記のように、顧客がサポート契約済みか、サポート有効期限内か、質問内容はサポート範囲内かなど、サービスを受けるための「資格」を管理することをエンタイトルメント管理と呼びます。

ポリシーとロール管理とは

ポリシーは主に「方針」や「規定」などの意味を持ち、IT分野では「プライバシーポリシー」など「○○○ポリシー」のような形で使用されることが多く、あるの分野の運用方針や運用ルールの集合を指して、ポリシーと呼ばれます。
また、ロールは「役割」や「役目」などと訳され、「一般利用者」や「システム管理者」など、あるシステムにおけるアクセス権や利用機能の制限などを定義する際に使用されます。

IGAで定義されているエンタイトルメント管理

Gartner社ではIGAにおけるエンタイトルメント管理を以下のように定義しています。

(日本語訳)
"アイデンティティとアクセス権の間のリンクを維持します。誰が何にアクセスでき、誰がアカウントまたはアクセス権を維持する責任があるかを判断します。
これには、リコンシリエーション（どのエンタイトルメントが存在し、どのように割り当てられているかを発見する）、エンタイトルメントカタログを維持および管理して、アカウント、ロール、グループメンバーシップなどのタイプを記述することが含まれます。"

（原文）
Maintaining the link between identities and access rights to determine who has access to what, and who's responsible for maintaining an account or access right.
This includes reconciliation (discovering which entitlements exist and how they're assigned), maintaining and curating the entitlements catalog to describe the types of accounts, roles, group memberships, etc.

※ 出典 Gartner社「Gartner, Definition: Identity Governance and Administration」, Felix Gaehtgens, Refreshed 11 September 2019, Published 7 August 2018 (2018年9月の記事-閲覧は有料)

これは、IDとアクセス権の間の繋がりを維持し、誰が何にアクセスできるのか、誰がアカウントまたはアクセス権を維持する責任があるのかを管理する機能を指しています。イメージとしては以下のようにアカウントの状態を管理します。

IGAで定義されているポリシーとロール管理

Gartner社ではIGAにおけるポリシーとロール管理を以下のように定義しています。

(日本語訳)
"アクセス権の自動割り当て（および削除）を管理するルールの維持。
アクセス要求、承認プロセス、依存関係、およびアクセス権間の非互換性における選択のためのアクセス権の可視性を提供します。等々。
ロールは、ポリシー管理の一般的な手段です。"

（原文）
Maintaining rules that govern automatic assignment (and removal) of access rights;
providing visibility of access rights for selection in access requests, approval processes, dependencies and incompatibilities between access rights; and so on.
Roles are a common vehicle for policy management.

※ 出典 Gartner社「Gartner, Definition: Identity Governance and Administration」, Felix Gaehtgens, Refreshed 11 September 2019, Published 7 August 2018 (2018年9月の記事-閲覧は有料)

上記のように、ポリシーはアクセス権の自動割り当て（および削除）を管理するルールと定義されています。また、ロールはそのポリシーに基づいて割り当てられるアクセス権や操作権限をグルーピングしたものを指します。

ロールの管理

Gartner社はロールを以下のように管理すると定義しています。

（日本語訳）
"エンタープライズロール管理の基本的なアーキテクチャ特性は次のとおりです。

企業内のロール管理には2つの独立したレイヤーがあります。1つはpeple用で、もう1つはResource（つまり、通常はアカウントとエンタイトルメントによってアクセスが制御されるシステムとアプリケーション）用です。
エンタープライズロール管理は、Resourceレイヤーのアクセスを制御するために使用されるすべてのエンタイトルメントに関係しません。代わりに、システムおよびアプリケーションでの日々のユーザー管理に使用されるもののみが含まれます。
エンタープライズロールは、高レベルの管理資格のみを編成します。

ロールは通常、アカウントとエンタイトルメントのリストです。ただし、エンタープライズロールの階層化により、複雑なエンタープライズロールの管理を容易にするセマンティック構造が導入されます。
"

（原文）
The essential architectural characteristics of enterprise role management are:

There are two separate layers for role management in the enterprise.
one for people and the other for resources (i.e., systems and applications, for which access is usually controlled through accounts and entitlements).
Enterprise role management is not concerned with all the entitlements used to control access for the resource layer; instead, it involves only those used for day-to-day user administration in systems and applications.
Enterprise roles organize high-level, administrative entitlements only.

Roles are generally lists of accounts and entitlements. The layering of enterprise roles, however, introduces a semantic structure that supports easier management of the complexities of enterprise roles.

※ 出典 Gartner社「Gartner, IGA Best Practices: Take Control of Enterprise Role Management」, Brian Iverson, Refreshed 29 July 2019, Published 13 December 2016 (2018年9月の記事-閲覧は有料)

Gartner社のIGAの定義では、ロールはPeopleとResourceの2つのレイヤに分けて管理することを提唱しています。Peopleレイヤのロールは雇用形態・職階・所属・職務内容・勤務地などの組織構造や役割を反映した共通属性によりグルーピングし、ResourceレイヤのロールはPeopleレイヤのロールに割り当てるのに扱いやすいように纏められた、リソースへのアクセス権や操作権限の集合で、ビジネスルールを反映してグルーピングします。
このようにロールを2層に分けて管理することで、アカウントの変更やリソースの変更の影響を極小化することが出来ます。

ロールの設計

Gartner社はロールの設計について以下のように定義にしています。

（日本語訳）
"IGA展開では、アプリケーションをオンボーディングしてその資格を発見するとき、エンタープライズロールエンジニアリングのイニシアチブはリソースレイヤーから開始する必要があります。
エンタイトルメントには多くの場合、不可解な名前があり、それらに関する有用な情報を含むメタデータがありません。
メタデータでエンタイトルメントを強化すると、ビジネスユーザーがエンタイトルメントの意味を理解するのに役立ちます。

このレイヤーのロールは、まとまったエンタイトルメントセットをユーザーに割り当てるためにまとめてバンドルすることを目的としています。
ロールは、アプリケーションのユーザーの実際のアクセスパターンをサポートする必要があります。
これは、バンドルされたエンタイトルメントに関連付けられた特権は、特定のタイプのユーザーがアプリケーションで自分のロールを果たすために必要であることを意味します。"

（原文）
In IGA deployments, when onboarding applications and discovering their entitlements, enterprise role engineering initiatives should start with the resource layer.
Entitlements often have cryptic names and lack metadata with useful information about them.
Enriching entitlements with metadata will help business users understand what the entitlements mean.

Roles in this layer are intended to bundle cohesive sets of entitlements together for assignment to users.
Roles should support actual patterns of access for users of an application.
This means that the privileges associated with the bundled entitlements would be necessary for a certain type of user to fulfill his or her role in the application.

ロールはResourceレイヤからPeopleレイヤの順にボトムアップ方式で設計します。Resourceレイヤでは1つのリソースに対して、複数の権限（一般アクセス権限や管理者権限など）を抽出し、複数のリソースに跨るようなロール設計は行わないようにします。
Peopleレイヤは前述の通り、雇用形態や職階、勤務内容などで抽出し、それらをResourceレイヤのロールに適切に割り当てられるように設計します。

ポリシーの設計

Gartner社はポリシーは以下のように設計すると定義しています。

（日本語訳）
"アクセス要求にロールを使用可能にすると、ビジネスユーザーにとって環境が読みやすくなり、アクセスを要求するときに必要なアクセスを見つけやすくなります。
ポリシーを使用すると、アクセス要求を送信することなく、ロールとユーザーを自動的に結び付けることができます。
2層のロールフレームワークは、2つの形式の割り当てポリシーを使用します。"

（原文）
Making roles available for access requests can make the environment more legible for business users, making it easier for them to find the access they need when requesting access.
Policies can be used to bring roles and users together automatically, without requiring the submission of access requests.
The two-layer role framework makes use of two forms of assignment policies.

ロールの割り当てを決めるポリシーでは、ユーザの属性値に基づいてPeopleレイヤのロールのみを割り当てるようなポリシーを設計します。
割り当てられたPeopleレイヤのロールに基づいてResourceレイヤのロールを割り当てるようにポリシーを設計することで、ユーザの追加・変更・削除の影響範囲をPeopleレイヤのみに限定することができます。これにより、リソースの追加・変更・削除の影響範囲もResourceレイヤのみに限定することができます。

midPointにおけるエンタイトルメント管理

midPointのエンタイトルメント管理では、エンタイトルメント情報（役割や組織に伴う資格）をロールや組織として表現します。
例えば、ある連携先システムの利用権限を表すロールをmidPoint上で定義します。このロールとユーザをmidPoint上で紐づけることで、ユーザ情報を連携先システムにプロビジョニングすることが可能となっています。これをロールベースプロビジョニングと呼んでいます。

また、連携先システム内固有の権限（管理者など）を表すロールをmidPoint上で定義し、ユーザに紐づけることでその情報を連携先システムにプロビジョニングすることもできます。

ロールベースプロビジョニング

midPointには、ユーザを特定の連携先システムにプロビジョニングさせる方法がいくつかあります。

ユーザに直接リソースをアサイン
ユーザにロールをアサイン。ロールがリソースにinducementという特殊なアサイン方式で関連付けられる。これにより、間接的にユーザにリソースがアサインされる
メタロールを定義して多段にする（ユーザ→ロール→メタロール→リソース）

1番目はとてもシンプルですが、ロール起点としていないため、midPointでは基本的には使用されません。2・3番目がロールを起点としたプロビジョニングであり、midPointではこの2つの使用が推奨されています。
特に3番目は、IGAのロール管理・設計にある、PeopleレイヤとResourceレイヤに分割して設計を行うという方式を、メタロールを活用することで表現することができるため、こちらの方式がより推奨されます。

メタロール

メタロールとはロールに適用されるロールを指します。通常、ロールはユーザに割り当てられ、それにより間接的にリソースに割り当てられますが、メタロールはロールに割り当てられ、リソースへのマッピングや構成をメタロールに持たせることで、ユーザに割り当てられるロールは単純な権限のみを持つロールとすることが可能です。

引用：Metarole

連携先システム内の権限管理

midPointでは、連携先システム内の権限を表すグループをロールや組織を用いてmidPoint内に定義し、そのグループを連携先システムへプロビジョニングすることができます。下図のように、組織にリソースをアサインして関連づけることで、連携先システムにグループが作成されます。

ユーザはこれらのロールや組織にmidPoint上でアサインされると、連携先のグループのメンバー情報としてプロビジョニングされることになります。これにより、midPoint上で連携先システムの利用権限だけでなく、システム内の権限管理も行うことが可能となっています。

midPointにおけるポリシーとロール管理

midPointにおいては、アクセス権はロールや組織で表現でされ、ユーザが自動アサインされるようにポリシー管理を行うことができます。また、ロール管理においては拡張されたRBACの機構を備えており、ロールのメンテナンス負荷を下げるための工夫がなされています。

ポリシーによるロールの自動割り当て

ロールをユーザの属性値などを条件にして自動的にアサインする仕組みが複数用意されています。スクリプト言語を使用して柔軟にアサインのための条件を定義することが可能となっています。条件から外れた場合には、付与されていたアサイン情報が自動的に解除される仕組みも備えています。

拡張されたロールベースアクセスコントロール（RBAC）

従来のRBACはロールに割り当てられたユーザがロール毎の権利（アクセス権）を有します。このようなロール設計を行うと、いわゆるロール爆発（Role Explosion）になりがちです。例えば、役割に応じたロールを定義していた場合に、勤務地や所属組織に応じた権限制御が必要となると、勤務地や所属組織×役割の数だけのロールを作成することになります。ロール数が膨大になることを容易に想像できます。midPointでは、ロールをユーザにアサインする際に関連する組織などのパラメータを付与する仕組みを備えており、これにより作成するロールを少なくし、ロール爆発をおさえることが可能となっています。