14.1 役割とリソースタブについて

[役割とリソース]タブの目的は、役割ベースのプロビジョニングアクションをユーザが簡単に実行できるようにすることです。これらのアクションにより、組織内の、役割定義と役割割り当て、およびリソース定義とリソース割り当ての管理ができます。役割の割り当ては、会社内部のリソース(ユーザアカウント、コンピュータ、データベースなど)にマップできます。また、リソースはユーザに直接割り当てることもできます。たとえば、[役割とリソース]タブを使用して次の作業を実行できます。

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

役割割り当て要求の結果、義務の分離の競合が発生する可能性がある場合、イニシエータは義務の分離制約を上書きすることができ、制約に対して例外を許可するための正当な理由を提供します。場合によっては、義務の分離の競合のためにワークフローが開始されます。このワークフローは、義務の分離の例外を有効にするために必要な承認を手配します。

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

14.1.1 役割について

この項では、[役割とリソース]タブで使用されている用語および概念の概要について説明します。

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

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

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

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

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

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

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

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

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

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

図 14-1 役割階層の例

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

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

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

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

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

義務の分離

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

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

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

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

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

  • 役割リストレポート

  • 役割詳細レポート

  • 役割割り当てレポート

  • SoD制約レポート

  • SoD違反および例外レポート

  • ユーザ役割レポート

  • ユーザエンタイトルメントレポート

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

役割のセキュリティ

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

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

  • 役割管理者

  • 役割マネージャ

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

表 14-1 システム役割

役割

説明

役割管理者

このシステム役割に含まれるメンバーは、すべての役割を作成、削除、変更したり、ユーザ、グループ、またはコンテナに役割を付与したり、取り消したりすることができます。さらにこの役割のメンバーは、任意のユーザに対して任意のレポートを実行できます。この役割に含まれるユーザは、ユーザアプリケーション内で次の機能を制限なしで実行できます。

  • 役割を作成、削除、および変更する

  • 役割の役割関係を変更する

  • 役割へのユーザ、グループ、またはコンテナの割り当てを要求する

  • SoD制約を作成、削除、および変更する

  • 役割カタログを参照する

  • 役割とリソースサブシステムを設定する

  • すべての要求のステータスを表示する

  • 割り当て要求を撤回する

  • すべてのレポートを実行する

役割マネージャ

このシステム役割に含まれるメンバーは、役割および役割関係を変更したり、ユーザに対して役割割り当てを付与したり、取り消したりすることができます。この役割に含まれるユーザは、ユーザアプリケーション内で次の機能を実行できます。その範囲は、役割オブジェクトに対するディレクトリ参照権限によって制限されます。

  • 新しい役割を作成し、ユーザが参照権限を持っている既存の役割を変更する

  • ユーザが参照権限を持っている役割の役割関係を変更する

  • ユーザが参照権限を持っている役割へのユーザ、グループ、またはコンテナの割り当てを要求する

  • 役割カタログを参照する(参照権限によって範囲が制限される)

  • ユーザ、グループ、およびコンテナに対する役割割り当て要求を参照する(役割、ユーザ、グループ、およびコンテナに対するディレクトリ参照権限により範囲が制限される)

  • ユーザ、グループ、およびコンテナに対する役割割り当て要求を撤回する(役割、ユーザ、グループ、およびコンテナに対するディレクトリ参照権限により範囲が制限される)

認証ユーザ

システム役割のサポートに加え、役割とリソースサブシステムは、認証ユーザによるアクセスを許可します。認証ユーザとは、ユーザアプリケーションにログインしていて、システム役割のメンバーシップによる特別な特権を持たないユーザのことです。標準的な認証ユーザは次の機能を実行できます。

  • ユーザに割り当てられているすべての役割を表示する

  • 参照権限を持つ役割への割り当てを要求する(ユーザ自身に対してのみ)

  • ユーザが要求者または受信者のいずれかである要求の要求ステータスを表示する

  • ユーザが要求者および受信者の両方である要求の役割割り当て要求を撤回する

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

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

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

14.1.2 リソースについて

この項では、リソース管理使用条件とユーザアプリケーションで使用する概念の概要を説明します。

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

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

  • 自分自身または組織内の他のユーザのためのリソース要求を行う

  • リソースを作成するそれらをエンタイトルメントにマップする

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

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

  • リソースはユーザに割り当てられるだけです。これは暗黙の役割割り当てに基づくコンテナまたはグループのユーザに許可されているリソースを除外しません。ただし、リソース割り当てはユーザにのみ関連付けられます。

  • リソースは次の方法のいずれかで割り当てられます。

    • UIメカニズムを通して直接ユーザによって

    • プロビジョニング要求を通して

    • 役割要求を通して

    • RestまたはSOAPインタフェースを通して

  • 同一のリソースは複数回ユーザに許可されます(この機能がリソース定義で有効にされている場合)。

  • リソース定義はそれに結合する1つのエンタイトルメントだけを持つことができます。

  • リソース定義はそれに結合する1つまたは複数の同一エンタイトルメント参照を持つことができます。この機能は、エンタイトルメントパラメータがプロビジョニング可能なアカウントまたは接続するシステムへのアクセス許可を表す場合のエンタイトルメントをサポートしています。

  • エンタイトルメントおよびデシジョンがサポートするパラメータは、設定時(静的)または要求時(動的)に指定できます。

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

リソース

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

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

リソース要求

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

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

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

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

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

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