役割および役割の割り当てについて

役割は、1つ以上のターゲットシステムまたはアプリケーションに関連する一連の許可を定義します。ユーザは、［役割とリソース］タブを使用することで、役割とユーザ、グループ、またはコンテナの間の関係である役割の割り当てを要求できます。さらに［役割とリソース］タブでは、役割階層内での役割間の関係を設定する役割関係を定義することもできます。

役割は直接ユーザに割り当てることができます。この場合、これらの直接割り当ては、役割に関連付けられている許可に対して明示的なアクセスを付与することになります。また、間接割り当てを定義することもできます。この場合、ユーザは、役割階層内のグループ、コンテナ、または関連するメンバーシップを通じて役割を取得できます。

役割の割り当てを要求する際には、役割割り当ての有効開始日を定義して、割り当てが有効になる日時を指定できます。このオプションを空欄にすると、割り当てはただちに行われることになります。

また、役割割り当て有効期限を定義して、割り当てを自動的に削除する日時を指定することもできます。

ユーザが役割とリソースの割り当てを要求すると、役割サブシステムが役割要求のライフサイクルを管理します。ユーザまたはサブシステムによって要求に対して実行されたアクションを確認するには、［役割カタログ］の［要求ステータス］タブで要求のステータスを確認できます。

役割カタログおよび役割階層

役割の割り当てを始めるには、該当する役割が［役割カタログ］で定義されている必要があります。［役割カタログ］とは、役割とリソースサブシステムで使用されるすべての役割定義と関連データのストレージレポジトリです。［役割カタログ］を設定するには、役割モジュール管理者(または役割マネージャ)が役割および役割階層を定義します。

カタログ内の役割間の関係は役割階層で設定されます。役割関係を定義することで、役割関係を使用して権限を付与するタスクを簡素化できます。たとえば、医者が組織に加わるたびに医療関係の個別の役割を50個割り当てる代わりに、医師という役割を定義しておいて、その医師の役割と各医療関係の役割の間に役割関係を指定することができます。ユーザを医師の役割に割り当てることで、関連する医療関係の各役割に対して定義された許可をユーザに付与できます。

役割階層は3つのレベルをサポートしています。最上位レベルに定義されている役割(ビジネス役割)は、組織内においてビジネス的な意味を持つ業務を定義します。中間レベルの役割(IT役割)は、技術的な機能をサポートします。階層の最下位レベルで定義されている役割(許可役割)は、下位レベルの特権を定義します。次の例は、3レベルで構成されるある医療機関の役割階層のサンプルを示しています。左側に階層の最上位レベルがあり、右側が最下位レベルになります。

図 14-1 役割階層の例

上位レベルの役割には、自動的に、下位レベルの役割に含まれる役割が持つ特権が含まれます。たとえば、ビジネス役割にはIT役割が持つ特権が自動的に含まれます。同様に、IT役割には許可役割が持つ特権が自動的に含まれます。

階層内の同等の役割間の役割関係は許可されていません。さらに、下位レベルの役割に上位レベルの役割を含めることはできません。

役割を定義する際には、オプションでその役割に1人以上の所有者を指定することができます。役割所有者とは、役割定義の所有者に指定されたユーザです。役割カタログでレポートを生成する際には、役割所有者に基づいてレポートをフィルタできます。役割所有者には、役割定義の変更を管理する権限は自動的には与えられません。場合によっては、役割に対して管理アクションを実行するよう所有者が役割管理者に依頼しなければならないこともあります。

役割を定義する際には、オプションでその役割を1つ以上の役割カテゴリに関連付けることができます。役割カテゴリを使用すると、役割を分類して、役割システムを整理することができます。役割をカテゴリに関連付けたら、役割カタログを参照する際にこのカテゴリをフィルタとして使用できます。

役割割り当て要求に承認が必要な場合は、承認を調整するのに使用されるワークフロープロセスのほかに、承認者リストの詳細が役割定義によって指定されます。承認者とは、役割割り当て要求を承認または拒否できる個人のことです。

義務の分離

役割とリソースサブシステムの重要な機能は、義務の分離(SoD)制約を定義できる点です。義務の分離(SoD)制約とは、競合していると考えられる2つの役割を定義する規則です。組織の義務の分離制約はセキュリティ責任者が作成します。SoD制約を定義することで、セキュリティ責任者はユーザが競合する役割に割り当てられるのを防いだり、監査証跡を管理して、違反が許可されている状況をトラッキングしたりすることができます。義務の分離制約では、競合する役割は役割階層内の同じレベルに存在する必要があります。

義務の分離制約の中には、承認なしで上書きできるものも、承認が必要なものもあります。承認なしで許可されている競合を義務の分離違反と呼びます。承認されている競合は、義務の分離の承認済み例外と呼びます。役割とリソースサブシステムでは、間接割り当て(グループやコンテナ内のメンバーシップ、または役割関係など)の結果発生したSoD違反の承認は必要ありません。

義務の分離制約に承認が必要な場合は、承認を手配するのに使用されるワークフロープロセスのほかに、承認者リストに関する詳細が制約定義によって指定されます。承認者とは、SoD例外を承認または拒否できる個人のことです。役割とリソースサブシステムの設定の一部として、デフォルトリストが定義されます。ただし、このリストはSoDの制約の定義で上書きできます。

役割のレポートおよび監査

役割とリソースサブシステムは、監査担当者が役割カタログに加え、役割割り当ておよびSoDの制約、違反、例外の現在のステータスを分析するのに役立つ豊富なレポート機能を備えています。役割監査担当者および役割モジュール管理者は、役割レポート機能を使用して次の種類のレポートをPDF形式で表示できます。

レポーティング機能を通した情報提供に加えて、役割とリソースサブシステムはNovellまたはOpenXDAS監査クライアントにイベントをログするように設定できます。

役割のセキュリティ

役割とリソースサブシステムは、一連のシステム役割を使用して、［役割とリソース］タブにある機能へのアクセスを保護しています。［役割とリソース］タブにある各メニューアクションは、1つ以上のシステム役割にマップされています。ユーザが、アクションに関連付けられているいずれかの役割のメンバーでない場合、そのアクションに対応するメニュー項目は［役割とリソース］タブに表示されません。

システム役割とは、インストール時に自動的に定義される、委任管理のための管理役割です。これらの役割には次のものが含まれます。

システム役割については、次で詳細を説明します。

役割とリソースのサービスドライバ

役割とリソースサブシステムは、役割とリソースサービスドライバを使用して役割のバックエンド処理を管理します。たとえば、すべての役割割り当ての管理、承認が必要な役割割り当て要求やSoD競合用のワークフローの開始、グループとコンテナのメンバーシップに従った間接役割割り当ての管理のほか、関連する役割のメンバーシップの管理を行います。このドライバは、役割のメンバーシップに基づいてユーザのエンタイトルメントを付与および取消し、完了した要求のクリーンアップ手順を実行します。

役割とリソースサービスドライバの詳細については、『Identity Managerユーザアプリケーション: 管理ガイド』を参照してください。

リソースベースのプロビジョニングについて

ユーザアプリケーション内のリソース機能の目的は、リソースベースのプロビジョニングアクションを実行する簡単な仕組みを提供することです。これらのアクションを使用することで、組織内でのリソースの定義およびリソースの割り当てを管理できます。リソース割り当ては会社内部のユーザまたは役割にマップできます。たとえば、リソースを使用して次の作業を実行できます。

リソース割り当て要求に対して組織内の1人以上の個人による許可が必要な場合、ワークフローが開始されます。ワークフローは、要求の完了に必要な承認を手配します。1人の個人の承認が必要な割り当て要求もあれば、複数の個人の承認が必要なリソース割り当て要求もあります。場合によっては、承認なしに実行できる要求もあります。

次のビジネスルールはユーザアプリケーション内のリソースの動作を制御します。

組織内のユーザのためにユーザアプリケーションを設定するのは、ワークフロー設計者およびシステム管理者の責任です。ワークフローの制御の流れ、およびフォームの外観は、Designer for Identity Managerでリソースベースのワークフローの承認定義がどのように定義されているかによって変わります。加えて、通常各ユーザが表示できる情報および実行できる操作は、ユーザのジョブ要件と権限レベルによって決まります。

リソース

リソースは、任意のデジタルエンティティ(ユーザアカウントなど)、コンピュータ、またはビジネスユーザがアクセスできる必要のあるデータベースです。ユーザアプリケーションはエンドユーザが必要なリソースを要求する簡単な方法を提供します。また、管理者がリソースを定義するために使用できるツールも提供します。

各リソースはエンタイトルメントにマップされます。リソース定義はそれに結合する1つのエンタイトルメントだけを持つことができます。リソース定義は、リソースごとに別のエンタイトルメントパラメータを使って、同一のエンタイトルメントに1度以上結合されます。

リソース要求

リソースはユーザにのみ割り当てられます。グループまたはコンテナに割り当てることはできません。ただし、役割がグループまたはコンテナに割り当てられている場合、グループまたはコンテナ内のユーザはその役割に関連付けられたリソースへのアクセスを自動的に許可されます。

リソース要求は承認を必要とします。リソースの承認プロセスは、プロビジョニング要求定義によって、またはリソース要求にステータスコードを設定することより外部システムによって処理されます。

リソース許可要求が役割割り当てによって開始される場合、役割がプロビジョニングされている場合でも、リソースは許可されない可能性があります。これについて最も考えられる理由は、必要な承認が与えられなかったことです。

リソース要求では、ユーザにリソースを許可する、またはユーザからリソースを取り消すことができます。

役割とリソースのサービスドライバ

ユーザアプリケーションは、役割とリソースのサービスドライバを使用して、リソースのバックエンド処理を行います。たとえば、すべてのリソース要求の管理、リソース要求のワークフローの開始、およびリソース要求のプロビジョニングプロセスの開始などです。