IGA におけるロールベースアクセス制御

この記事は https://docs.evolveum.com/iam/iga/rbac/ の翻訳です。

はじめに

名前が示すとおり、ロールベースのアクセス制御 (RBAC) は ロール の概念に基づくアクセス制御機構です。多くの組織では、同じ権限群がユーザーに何度も繰り返し割り当てられます。同じ職務をしているユーザーは、同じ権限を持つ可能性が高いです。 RBAC の考え方は単純です。これらの権限を ロール にグループ化し、そのロールをユーザーに割り当てます。つまり割り当てるものが 少なく なります。いくつもの権限を割り当てる代わりに、1つのロールを割り当てます。管理するものが少なければ、管理労力も少なくなります。少なくとも理論上はそうです。

Basic RBAC Structure

いつものように、実務は少し異なります。 RBAC は、かなり 規則的 で静的な組織では非常にうまく機能します。多くの人が同じ職務を行い、その職務がめったに変わらない組織です。その場合、必要なロールはほんの少数で、それらを多くのユーザーに割り当て、ロール定義を頻繁に更新する必要もありません。残念ながら、私たちは21世紀の現実にいます。組織はもはやそれほど 規則的 でも静的でもなく、生き残るためには柔軟で効率的である必要があります。従業員は通常、複数の責任を持ち、それらはかなり頻繁に変わります。これは RBAC にとって理想的な環境ではありません。組織は、非常に動的な環境で、大量のロールとロール割り当てを管理する必要があります。それでも RBAC は、正しく使えば多くの価値をもたらせます。

まず基本から始めましょう。

用語

NOTE: RBAC という用語は、人によって多くの意味を持ちます。私たちは RBAC という用語をかなり広い意味で使います。 NIST RBAC モデルだけを厳密に意味しているわけではありません。私たちが RBAC で意味するのは、ロールの概念に基づく一般的な機構です。 midPoint RBAC の基本原則は NIST RBAC モデルと非常によく似ていますが、必要な場合は NIST モデルから逸脱する自由を取ります。

IGA 固有

NOTE: この本文は、アイデンティティガバナンスおよび管理 (IGA) システム、以前はアイデンティティ管理 (IDM) システムまたはプロビジョニングシステムと呼ばれていたシステムにおける RBAC の利用を説明しています。アプリケーション内の細粒度のアクセス制御に RBAC を使うことには焦点を当てていません。

基本ロール階層

権限をロールにグループ化する能力はかなり有用です。しかし、アクセス制御ポリシーが極端に単純でない限り、それだけではまだ十分ではありません。実務的なポリシーの多くはロールをロールの中に置き、ロール階層を作ることを必要とします。

2つの職務上の位置付け、担当者と監督者を考えてみましょう。担当者は基本的な権限集合を持っています。監督者は担当者ができることをすべて行えますが、さらに追加権限を持っています。素朴な方法は、担当者の権限をすべて監督者ロールに単純にコピーすることです。しかし権限はめったに静的ではありません。アクセス制御ポリシーは、環境の変化と同じくらい変化し進化します。担当者の権限が変わる可能性は高いです。その場合、監督者ロールも更新する必要があります。これは維持管理負担になります。では、継続的な維持管理が必要な関連ロールが数百、数千ある場合を想像してください。そのような構造を維持管理する人には、超人的な正確さと忍耐が必要になります。

より自然な考え方は、担当者ロールを監督者ロールに含めることです。担当者の権限が変わると、監督者の権限も自動的に更新されます。維持管理はずっと容易です。これがロール階層の基本考え方です。基本権限は低レベルのロールに置かれます。低レベルのロールを組み合わせて上位レベルのロールを作ります。そのロールもさらに組み合わせることができます。

Role hierarchy

ロール種類

すべてのロールが同じように作られているわけではありません。理想的には、上記の例のロールはすべて同等に扱われるべきです。すべてが業務上の職位または責任を表し、すべてがユーザーに割り当てられ、すべてが同じプロセスで作成・維持管理される、という形です。すべてのロールは、その業務上の職位または責任に必要な権限を含むべきです。しかし現実世界では通常そうではありません。

「純粋な」 RBAC 理論では、ロールは業務概念を表すことになっています。これは確かに良い方法です。ロールは、業務部門の担当者が理解できるもの、職務上の位置付け、責任、組織上の単位などを表すときに最もよく機能します。ここまでは問題ありません。しかしロールの中を見ると複雑になります。ロールは権限、つまり実際の IT 環境に対応付けられる権限を含むことになっています。しかし、業務上の意味と複雑で整理されていない IT 詳細の両方を持つロールを構築することは困難です。そのようなロールを作るには、業務部門の担当者が IT 担当者と非常に密接に協力する必要があります。しかし業務と IT の協力は、通常まだまだ改善の余地があります。異なる概念と言語を使っており、協力は完全に円滑ではありません。そのため一般的な実践は、少なくとも2種類のロールを持つことです。

ビジネスロール は、職務や責任などの業務概念を表します。

アプリケーションロール は IT 上の概念を表し、通常は特定のアプリケーションへの技術的なアクセス権を表します (そのためこの名前です)。

ビジネスロールは他のビジネスロールから構成できます。しかし階層の最下層にはアプリケーションロールがあります。

Role hierarchy - application と business roles

アプリケーションロール は IT 担当者によって作成されます。これは Active Directory account、Active Directory group "files-int"、DMS access to internal files (read-write)、CRM account with access to customer database などの 技術的 概念を表します。アプリケーションロールはロール階層の構成要素です。

推奨される方法は、アプリケーションロールをそれが表すものに「結び付け」することです。たとえば、すべての Active Directory グループを取り込み、各グループからアプリケーションロールを作成できます。さらに良いのは、Active Directory グループをアプリケーションロールの「射影」として作成することです。 IT 担当者が IGA システムでアプリケーションロールを作成し、その後 IGA システムが Active Directory に対応するグループを作成します。これはグループに対するガバナンスを維持管理する良い方法です。たとえば、すべてのグループに責任者が指名されていることを保証できます。残念ながら、アプリケーションロールはあまりに頻繁に手動で維持管理されており、労力集約的で、誤りの余地を大きく残します。

ビジネスロール は業務部門の担当者によって作成されるべきです。これは特定の職務、職務上の位置付け、業務プロセス、ワークグループ活動に必要な責任などの業務概念を表します。例として Marketing Manager、Branch Supervisor、Claim Reviewer、Innovation Task Force Member があります。ビジネスロールは通常 複合的 であり、アプリケーションロールまたは他のビジネスロールから作られます。

ビジネスロールを構築する方法はいくつかあります。古典的な方法は、ゼロベースでビジネスロールを作成することです。これには、個々の職務、職務上の位置付け、チームの責任の業務分析、活動を遂行するために必要な権限/権限の形式的仕様化、権限のビジネスロールへのグループ化が含まれます。これはかなり正確な方法ですが、通常は非常に遅く、退屈で労力集約的です。他の方法は、既存データからビジネスロール定義を発見または マイニング することに焦点を当てます。この方法は完全に正確ではありませんが、はるかに速く結果を提供できます。現実世界の実務では両方の方法を組み合わせることがよくあります。

場合によっては、アプリケーション と業務ロールだけでなく、さらに多くのロール種類があります。他のロールはずっと少ないものの、時々使われます。下の表はロール種類をまとめたものです。

ロール種類	説明	内容	ユーザーに割り当てるべきか?	例
アプリケーションロール	単一アプリケーションへのアクセス権を説明するロールです。通常、アプリケーショングループ、権限、ロールなど、アプリケーション内の特定の entitlement を1つ表します。特定のアプリケーションに結び付けられています (そのためこの名前です)。アプリケーションロールは、エンタイトルメントの取り込み/同期によって自動作成されることがよくあります。たとえば Active Directory グループの取り込みです。	単一アプリケーションへのアクセス。	いいえ。ただし、かなり頻繁にユーザーに割り当てられています。	Active Directory Domain Administrators 会社 Web サイト Editors データベース `foo` 読み取り専用アクセス
技術ロール IT ロール	複数のアプリケーションロールまたは低レベルの権限を、管理しやすい1つの単位に組み合わせます。たとえばデータベース管理を行うためにオペレーティングシステムアクセスが必要な場合など、互いに依存するアプリケーションロールによく使われます。アプリケーションロールとビジネスロールの中間にあるものと考えられます。複数のアプリケーションへのアクセス権を与え得るためアプリケーションロールではありません。また完全な業務責任を説明せず、非常に技術的で業務部門に分かりやすいとは言えない用語を使うことが多いため、ビジネスロールでもありません。独自の種類です。あまり頻繁には使われません。	互いに依存する、または一緒に意味を持ついくつかのアプリケーションへのアクセス。	例外的な場合。たとえば非常に特殊で複雑な IT 責任。	データベース `bar` 管理（OS アクセス付き）バックアップ/リストア管理
認可ロール	それが定義されたシステム内部の認可または権限を提供します。IGA プラットフォームでは、プラットフォーム自身の一部へのアクセスを提供するロールです。認可ロールは他システムへのアクセスを付与しません。	認可文 (付与)。	いいえ。ただし導入の初期段階でビジネスロールがまだ十分形成されていない場合、一部のロールがユーザーに割り当てられることがあります。特にスーパーユーザーロールです。	`Superuser` ロール IGA プラットフォーム内部の `Approver` ロール
ビジネスロール	業務責任、業務プロセス内の機能、業務関連の職務上の位置付け、または類似の業務概念を表します。ビジネスロールは、より小さな「要素的な」ロールの組み合わせであることが想定されています。	他のビジネスロールを含む、任意のロール種類。	はい	`Clerk` `Branch Supervisor` `Marketing Assistant` `Call Center Operator`

ロール階層

RBAC は階層的です。ロールの中にロールが存在できます。 IGA に関しては、ほぼすべてのロール構造は技術的には階層的です。階層の最下層には アプリケーション ロールがあります。 ビジネス ロールはアプリケーションロールから構築されます。これは技術的にはロール階層ですが、RBAC モデルが意図するロール階層の効果を持つとは限りません。

階層の完全な効果は、ビジネスロールが他のビジネスロールの中に置かれるときに得られます。たとえば Sales Manager ロールは Sales Agent ロールを含み、エージェントのすべての権限をマネージャーの権限に含められます。この方法は、理論上ロール維持管理を減らせます。 Sales Agent 権限が変更した場合、その変更は Sales Manager の権限にも自動的に適用されます。しかしこの効果は、ロール階層がよく構築され、ロール重複や誤用を避けている場合にのみ得られます。

アクセス申請プロセス

理想的には、ロールはユーザーに自動的に割り当てられるべきです。ビジネスロールは業務概念に対応することが想定されています。したがって、勤務地、職務コード、プロジェクトメンバーシップなどのユーザー属性に基づいてビジネスロールを自動割り当てるのは簡単であるべきです。しかし実践的な障害があります。職務コードや勤務地は利用できないかもしれず、正確ではないかもしれません。同様の問題は他の業務データにも適用される可能性があります。全体的なデータ品質が低すぎて、そのような自動化ができない場合もあります。また、関連する業務概念がすべてビジネスロールでカバーされているとは限りません。さらに、業務 データ (勤務地や職務コードなど) と業務 ロール の対応付けが明らかではない場合もあります。言い換えると、ユーザーがどのアクセス権を持つべきかを本当に知っている人がいません。この課題は実際かなり一般的です。

実践的な IGA 導入では、しばしば アクセス申請 プロセスに頼ります。プロセスは次のようになります。

ユーザーがロールを申請します。 IGA システムはロール申請のための専用のユーザーインターフェイスを提供します。ユーザーは role カタログ からロールを選択します。
申請が承認に送信されます。
ロールがユーザーに 割り当て されます。アクセスがプロビジョニングされ、権限が付与されます。

これは多くの variation を持てる汎用プロセスです。ユーザーが自分自身のためにロールを申請する場合もあれば、マネージャーがユーザーの behalf でロールを申請する場合もあります。承認手順は複数段階になり得ます。たとえばラインマネージャーとアプリケーション所有者の承認が必要です。 High-privilege ロールはセキュリティ office による additional 承認を必要とする場合があります。

理想的なケースでは、role カタログ は選択済み集合の業務ロールだけを含むべきです。しかしカタログは通常、すべてのビジネスロールと、アプリケーション ロールも含んでいます。あまりに多くの組織はユーザーがどのアクセスを持つべきかを知りません。これが通常 アクセス申請 プロセスを導入する主な motivation です。ユーザーがどのアクセス権を持つべきかを誰も知らないということは、ビジネスロールがどのような姿であるべきかも誰も知らないことを意味します。そのためユーザーは代わりにアプリケーションロールを申請します。この方法はあまりにも一般的です。そのようなプロセスは正しくありません。ベストプラクティスに反し、常識にも反します。しかし、何らかの半体系的なアクセス制御ポリシーを適用する唯一現実的なプロセスであることも多いです。

要点は、アクセス申請 プロセスがしばしば over-provisioning、つまりユーザーが必要とする以上のアクセスを付与することにつながる点です。この問題の理由はかなり明らかです。アクセスを得るのは非常に簡単で、アクセスを削除する motivation はありません。 Over-provisioning は通常認定機構で対処されます。簡単に言えば、認定は責任者が、ユーザーが申請したアクセスを今も必要としていることを確認しなければならないプロセスです。一般的な方法は、定期的にアクセスを確認する certification campaign を設定することです (例: 年1回)。

ロールガバナンス

ロールを定義し、実用的な RBAC モデルを作成することは簡単な作業ではありません。しかし、そのモデルを良好に動く状態で maintain することはさらに困難です。

私たちを取り巻く世界は常に変化しています。組織も変化し、ユーザーの職務と責任も変化します。アプリケーションは upgrade され、新しいアプリケーションが導入され、古いアプリケーションは廃止ed されます。 Re-organization、merger、spin-off、多数の unforeseen 変更があります。 RBAC モデルはロール定義を更新し、適応しなければなりません。

ロール管理は集中化されたにして、RBAC モデル維持管理の責任を単一チームに置くこともできます。この方法はかなり明らかですが、かなり間違っています。 RBAC モデルは、ロール定義がそれが表すものに align しているときに最もよく機能します。アプリケーションロールはアプリケーション権限に align し、ビジネスロールは業務必要性に align すべきです。非常に rare なケースを除き、組織全体にわたる IT の intricacy と業務複雑性の両方を cover できる単一チームは存在しません。

実践的な方法は、ロール管理労力を distribute することです。

アプリケーションロール は IT 部門によって管理されるべきです。それらは IT 上の概念に align すべきです。理想的には、アプリケーションロールは自動または半自動で管理されるべきです。ロールはアプリケーションエンタイトルメントから自動的に同期できます。たとえば Active Directory アプリケーションロールは Active Directory グループから自動作成できます。逆方向も現実的です。IGA プラットフォームで新しいアプリケーションロールが定義されると、Active Directory グループが自動的に作成されます。どちらにせよ、アプリケーションロールは IT domain であり、自動化された維持管理の良い候補です。

ビジネスロール は業務単位によって管理されるべきです。ビジネスロールは業務概念を説明するため、業務部門の担当者によって管理されるべきです。ロールを定義し、更新し続けるために、業務の概念と必要性を十分に知っているのは業務部門の担当者以外にいません。業務と IT の協力作業としてビジネスロールを維持管理することは可能ですが、業務部門の担当者の engagement は crucial です。

アプリケーションロールと異なり、ビジネスロールの維持管理を自動化することは非常に困難です。特にロール定義を更新に保つには多くの労力が必要です。通常の実務は、特にビジネスロールに対して role owner を割り当てることです。ロール owner はロール定義に責任を持つ人物です。ビジネスロールの場合、ロール所有者は通常、そのロールが関連する職務またはプロセスに責任を持つ業務人物です。業務必要性が変わるたびに、ロール所有者がロール定義を更新することが期待されます。多くの IGA プラットフォームは、IGA プラットフォーム自体の中でロール owner を指定できます。

ロール所有者は業務ロールの維持管理に不可欠です。しかし、特にアプリケーションロールがユーザーに直接割り当てられることが多い場合、アプリケーション ロールにも owner が必要な場合があります。

Owner と同様、IGA システムは通常ロール approver の仕様化を許可します。承認者は アクセス申請 プロセスにおけるロール申請の承認に責任を持つ人物です。

RBAC ポリシー

ロールベースのアクセス制御 (RBAC) モデルは1990年代から2000年代に形作られました。これが RBAC の「従来の」な形です。この RBAC の形式は完全に静的です。ロール割り当ては静的、ロール内の権限集合は静的、モデルによって付与されるアクセスは管理者が手動で変更しない限り変わりません。この方法は2000年代には有用だったかもしれません。しかし20年後の現在、私たちは非常に動的な世界にいます。静的アクセス制御モデルはもはやあまりうまく機能しません。静的 RBAC モデルには、ロール爆発やロール abuse など多数の問題があります。

Static RBAC

すべての欠点にもかかわらず、従来のな静的 RBAC モデルは昔も今もかなり広く使われている。しかし静的 RBAC は、その inception 直後からほぼ批判されていました。その critique の結果、2000年代の早い時期から、RBAC をより動的にする機構が導入されました。当時の一部のアイデンティティ管理システムは、単純ルールに基づいてユーザーにロールを動的に割り当てることをサポートしていました。しかしこの機能はまだかなり rare でした。アイデンティティ管理システムは2010年代に成熟し、アイデンティティガバナンスおよび管理 (IGA) システムとして知られるようになりました。現在、多くの IGA プラットフォームには動的 RBAC の少なくとも partial サポートが含まれています。しかし個々の製品の機能には依然として大きな差があり、動的機能は IGA 分野の外ではあまり広く使われているわけではありません。それでも動的 RBAC 方法は、静的 RBAC だけでなく、ABAC や PBAC など他のアクセス制御モデルに対しても多くの advantage を提供します。 2020年代の現在、動的 RBAC 機能は、複雑なアクセス制御要件を効率的に扱うため、どの IGA プラットフォームにとっても絶対に不可欠です。

Policy-driven RBAC

動的 RBAC への最も実践的で柔軟な方法の1つは、midPoint IGA プラットフォームに実装されている Policy-Driven RBAC です。 Policy-driven RBAC は3つのレベルで柔軟性を提供します。

動的ユーザー・ロール割り当て。ユーザーへのロール割り当て (および unassignment) はルールで制御できます。 Rule は通常、職務コードや勤務地などのユーザー属性を扱います。ユーザー属性に保存された業務データに基づいて、ロールをユーザーに動的かつ自動的に割り当てできます。

さらに midPoint では、ロールを組織構造に直接 link できます。その場合、組織上の単位、チーム、プロジェクトのメンバーシップは、特定のロールまたは権限を自動的に imply します。

動的ユーザー・ロール割り当ては、ロール割り当てのかなりの部分を管理者の明示的な対応なしに自動管理できるため、RBAC 管理負担を大きく減らします。

ユーザー・ロール割り当てパラメーターs。ユーザー・ロール割り当ては従来の RBAC のような単純な二項関係ではありません。これは parametrized できる rich データ構造です。たとえば割り当ては、limited 時間 period の間だけアクセスを提供する、またはアクセスを特定組織に limit するよう parametrized できます。 midPoint の関係パラメーターのような特殊なパラメーターは、ユーザーとロールの関係を決定するために使えます。これにより、通常のロールメンバーとロール所有者、リソースへの読み取り専用アクセスと読み書きアクセスなどを区別できます。

さらに midPoint では、ロールと同様の機能を持つ他のオブジェクト種類にも割り当てできます。たとえば組織上の単位は、部門、チーム、プロジェクトに提供されるアクセスを直接モデル化でき、関係パラメーターを使ってチーム member とマネージャーのアクセスも区別できます。さらにサービスの概念はアプリケーション、モバイルデバイス、API、類似 entity をモデル化でき、それらはすべてロールのように behave します。

Parametric ロール割り当てはロール爆発問題と戦う非常に効率的なツールです。割り当てパラメーターで区別することにより、単一ロールをさまざまな circumstance で使えます。従来の RBAC が多くのロールを必要とする場所で、policy-based RBAC は1つだけで済みます。

動的ロール権限。ロールはもはや静的な権限集合だけではありません。静的権限集合も引き続き使えますが、動的 expression を使って権限を決定する additional 機構があります。そのような式は、ユーザー、ロール、ロールとユーザーの割り当て、評価 context からパラメーターを取得します。 Parameter は、ロールによって付与される権限を決定するために使われます。これは通常割り当てパラメーターに基づいて、さまざまな situation を決定する効率的機構です。たとえば式を使って、通常のロールメンバーにはある権限を、ロール所有者には別の権限を付与できます。さらに一般的なケースは、location パラメーターを使って権限を特定の物理勤務地または国にだけ制限する式です。

さらに midPoint では、式を使って midPoint が provision するアカウントのエンタイトルメントと属性を設定できます。たとえば、グループの naming convention に従い、foo-reader、foo-writer、foo-admin の中から適切なグループを自動選択するようプログラムできます。これらはすべて単一ロールで扱われます。 MidPoint は組織上の単位をロールとして扱うため、この機構を使って、複雑ポリシー定義を必要とせずにプロジェクト member とマネージャーのアクセスを区別できます。可能性はほぼ無限です。

動的ロール式は、ABAC や PBAC のような動的アクセス制御モデルと非常に似た機能を提供します。しかし policy-based RBAC は、RBAC の効果の大半を維持します。ポリシーはロールにきれいに分割され、その中に encapsulated されます。多くのロールは他から independent に維持管理・更新できるため、ABAC/PBAC モデルに一般的なポリシー維持管理悪夢を減らします。

Policy-driven RBAC は RBAC 概念の自然な evolution です。 Traditional 静的 RBAC モデルの問題に対処しながら、RBAC の advantage を引き続き提供します。動的アクセス制御モデルの柔軟性を RBAC world に持ち込みます。

ロールエンジニアリング

組織ロールエンジニアリング

NOTE: この節で提供される概念の大半は、organizational ロールエンジニアリングに適用されます。つまりエンタープライズ、academia、政府における 従業員、student、スタッフ、contractor などの組織上のアイデンティティのためのロールエンジニアリングです。 Customer、business partner、citizen アイデンティティには完全には適用できない場合があります。そのようなアイデンティティには、大量のアイデンティティ、より単純で既知かつ一貫して適用されるポリシーなど、特定の characteristic があります。そのような環境には、他の方法の方が適している可能性があります。 IGA に silver bullet はありません。

ロールエンジニアリングは、RBAC モデルを作成・維持管理するプロセスです。ロールの作成と更新、そして関連するすべてのルールとポリシーの作成・更新が中心です。厳密に言えば、ユーザーへのロール割り当てはロールエンジニアリングの一部ではありません。しかしロールエンジニアリングと密接に関連しており、ロールエンジニアリングから分離することは非常に困難です。

基本的に、ロールエンジニアリングには2つの方法があります。

トップダウン方法 は業務概念から始め、それをより細かなロール定義、最終的には権限に表現しようとします。たとえばロールエンジニアリングは組織構造、職務、職務上の位置付け、プロセスの分析から始まります。個々の職務のために top-level ビジネスロールが作成され、ロールは個々の責任に分割され、それらが lower-level ビジネスロールを形成します。 Lower-level ビジネスロールは権限で満たされます (通常はアプリケーションロールを通じて間接的に)。

ボトムアップ方法 は権限から始め、それらをロールにグループ化し、ロールを業務概念に match させます。プロセスは権限、通常はアプリケーションロールの形から始まります。アプリケーションロールはグループ化され、IT/技術ロールまたは lower-level ビジネスロールを形成します。上位レベルビジネスロールは lower-level ロールから形成されます。ビジネスロールは職務、職務上の位置付け、組織上の単位などの業務概念に対応付けされます。

どちらの方法も実務で使われており、どちらにも plus と minus があります。

トップダウン方法は、業務分析の観点から「正しい」方法と認識されるものです。確かに、分析が最新で完全な業務データに基づいている限り、トップダウン方法は正確で信頼できる結果を与える傾向があります。トップダウン方法は理論上、over-provisioning など、アクセス制御実務に隠れた多くの課題を uncover し remedy できます。しかしトップダウン方法は非常に労力集約的です。 Top-tier 業務部門の担当者の非常に intensive な協力が必要であり、それを確保するのは困難です。トップダウン方法の遅く高価な progress は通常重大な障害であり、大規模利用では実行困難になることがよくあります。

さらに、正確業務データへの依存はトップダウン方法の重要な問題になり得ます。あまりに多くの組織で、従業員がどのアクセスを持つべきかを本当に知っている人はいない、というのは公然の秘密です。業務プロセス、職務、責任は十分に文書されていません。形式的組織構造は real 業務実務と align していません。 Combined で temporary な責任を持つ職務上の位置付け、ルールの exception、文書化されていない管理判断に由来する実務、informal communication back-channel などが多数あります。このような環境では、トップダウン方法は容易に futile exercise になります。トップダウン方法は、現実世界のアプリケーションへのアクセスに必要な文書化されていない intricacy を見落としやすいため、under-provisioned アクセスで終わることがよくあります。

アイデンティティ管理はゼロベースから始まるわけではありません。常に既存のデータがあります。組織は成長する間、かなりの期間アイデンティティ管理や IGA プラットフォームなしで運営しなければなりませんでした。ユーザーとグループでいっぱいの Active Directory があるでしょう。多くの connected アプリケーションを持つ中央LDAP ディレクトリサーバーがあるかもしれません。大規模ユーザー base、ロール、業務必要性に合わせてカスタマイズされたポリシーを持つ業務アプリケーションがあるかもしれません。何らかの形で、権限、エンタイトルメント、アプリケーションアクセスがすでにプロビジョニングされた既存ユーザー base が存在します。これは IGA 導入の障害、つまり取り込み、プロセス、align しなければならない既存状態と見なされるかもしれません。しかしそれは advantage でもあり、precious データ集合でもあります。既存アプリケーションへのアクセスは (ほとんどの場合) 既存アクセス制御ポリシーに基づいていました。ポリシーに関する情報はまだデータの中に隠れており、発見されるのを待っています。既存データからポリシー情報を発見することが、ロールエンジニアリングにおけるボトムアップ方法の基本考え方です。

通常の実務は、Active Directory や LDAP などの中央ディレクトリサービスから始めることです。そのようなシステムは多くのアプリケーションの basis や認証ソースとして使われるため、通常かなり完全なユーザーデータベースを持っています。また、application-specific 権限を表すグループが存在する可能性も非常に高いです。グループは IGA プラットフォームに取り込みでき、アプリケーションロールを自動作成できます。この方法にはいくつかの効果があります。第一に、アクセス申請 プロセスの base を提供します。グループメンバーシップを手動で管理する必要がなくなります。ユーザーは アクセス申請 プロセスを使ってアプリケーションロールのメンバーシップを申請でき、完了時に Active Directory または LDAP グループのメンバーシップが付与されます。第二に、アプリケーションロールへのユーザー割り当ては bottom-up ロールエンジニアリングの starting データを提供します。明らかな出発点は広く使われているグループ、つまり多数の member を持つグループです。これはポリシー自動化の prime candidate です。メンバーシップ overlap は隠れたポリシー fragment の良い indicator です。似た member 集合を持つアプリケーションロールを探してください。それらはビジネスロールに combine できる可能性が高いです。

しかしアプリケーションロールの分析を手作業で行うことはかなり困難です。一部のパターンやメンバーシップ overlap は明らかですが、大半はそうではありません。ビジネスロールはデータから mined されなければなりません。いくつかの IGA ツールは、この目的のために role mining 機構を提供します。 Role mining は通常、クラスターing、パターン検知、さらには高度な機械学習や人工知能 (AI) 方法など、アプリケーションロールの類似性を検出する mathematical アルゴリズムに基づきます。機構はアプリケーションロールを分析し、類似権限のグループを検出し、新しいビジネスロールを提案します。

ロールマイニング機構は非常に useful です。しかし blind に使ってはいけません。ロールマイニングはほぼ常に approximate です。 Similar な権限を持つロールをプロセスし、元の権限を少し増やしたり減らしたりするビジネスロールを提案することがよくあります。さらにアルゴリズムには業務文脈の情報がありません。ロールマイニングは、多くの権限と高い類似性を持つユーザーを含むビジネスロールを提案するかもしれません。しかし、そのロールは偶然似た権限を持つ2つの independent ユーザーグループを混ぜているかもしれませんし、より深いロール階層の方が適切かもしれません。ロールマイニングには常に human 監督が必要です。ビジネスロール提案は、業務文脈を認識し、その提案が業務と組織上の観点から意味を持つか判断できる人物によって見直されなければなりません。簡単に言えば、人工知能アルゴリズムを補う natural インテリジェンスと文脈 awareness が必要です。

ボトムアップ方法は、ポリシーが完全には known でない現実世界の situation で通常非常に実践的です。ボトムアップ方法にはいくつかの大きな advantage があります。特にロールマイニング機構を使ってプロセスを speed up できる場合、非常に現実的な方法です。既存アクセス制御プロセス (例: アクセス申請 プロセス) と並行して、円滑で継続的に適用できます。トップダウン方法と異なり、ボトムアップ方法は形式的な rubber-stamped 仕様化ではなく、real な practical ポリシーを分析します。しかし disadvantage もあります。ボトムアップ方法は approximate でなければなりません。 Policy-based 判断、ポリシー exception、古くなったポリシーに基づく判断などが混在したデータを扱います。 Input データは clean ではなく、output が perfect であることは期待できません。ボトムアップ方法は status quo を legalize する傾向があり、それは通常過剰プロビジョニングアクセスを意味します。 Over-provisioning が systemic だった場合、ボトムアップ方法は過剰プロビジョニングアクセスをビジネスロールに反映します。これはビジネスロール提案が見直される時点で対処できます。しかしその時点では通常 priority ではなく、broader 業務文脈も known ではないかもしれません。したがって bottom-up ロールエンジニアリングの後には、ロール consolidation とクリーンアップ手順が続くべきです。

全体として、トップダウン方法はセキュリティとコンプライアンスを優先し、業務 disruption と high 費用の大きなリスクを伴います。一方ボトムアップ方法は業務 continuity を優先し、セキュリティに大きな改善をもたらさないまま status quo を埋め込む大きなリスクを伴います。実務では、top-down と bottom-up の両方の方法が useful であり、必要です。私たちの推奨は、それらを組み合わせることです。

トップダウン 方法を使って「whales」を処理します。メンバーが多いロール、影響が大きいロール、機密性の高いロールです。トップダウン方法は遅く、高価で、disruptive になり得るため、そのようなロールの数は比較的少なく保ってください。

Bottom-up 方法を使って「fish」を処理します。ordinary な mid-size ロールです。ロールマイニングを主な分析ツールとして使うことで、かなり多くのロールをすばやく処理できます。 Reasonably high 類似性を持ち、業務上の意味もあるロールを選んでください。ただしやりすぎないでください。類似性が低いロールや業務上の意味がないロールを無理に処理しようとしないでください。すべての権限をビジネスロールに処理する必要はありません。

「plankton」を処理しようとしないでください。ポリシー exception、非常に小さなロール、historical leftover です。そのようなアプリケーションロールはユーザーに直接割り当てたままにしてください。完全に忘れてはいけませんが、ビジネスロールに処理しようとしないでください。労力に見合いません。見直しと認定キャンペーンを設定し、段階的に削除するか、制御下に置いてください。

ロールエンジニアリングプロセスのすべての段階で心に留めておくべきことが1つあります。常に業務部門の担当者の assistance を求めてください。ロールはまず業務 sense を持たなければなりません。それがロールベースのアクセス制御の主な考え方です。業務部門の担当者の協力はトップダウン方法に絶対不可欠です。しかしボトムアップ方法でさえ業務知識なしには機能しません。業務部門の担当者は不可欠です。

ロール エンジニアing はロール管理の手順の1つにすぎません。ロールは useful であるためにユーザーに割り当てられなければなりません。前に見たように、ユーザーへの静的ロール割り当ては望ましくありません。ユーザーへの自動化されたロール割り当てのための policy 定義は、role 管理 労力の不可欠な部分であるべきです。

長期的な持続可能性

RBAC を機能させるだけでも十分に困難です。それをうまく動き続けさせることはさらに困難です。アクセス制御モデル一般の 持続可能性 は簡単な問題ではなく、まだ完全には解決されていません。 RBAC も例外ではありません。

アクセス制御モデルは、理論上は厳格にポリシーに基づくべきです。しかし見てきたように、そのような strict 方法は通常現実的ではありません。常に discrepancy があります。ポリシー exception、データ誤り、古くなったデータ、historical baggage、leftover、その他多数の小さな課題です。 RBAC モデルはその性質上かなり堅牢で、多くの discrepancy を tolerate しながらも運用できます。それがおそらく RBAC の popularity の理由の1つです。しかしそのような discrepancy は望ましくなく、全員の生活を複雑にします。それらを積み上げるのではなく、時間とともに discrepancy の数を減らすにはどうすればよいでしょうか。

少なくとも今のところ、その問題への definitive answer はありません。提供できるのは考え方と提案の集合です。

何よりもまず、可能な限り広く ポリシーと自動化を適用 してください。ロールは自動的に割り当てられるべきです。さらに重要なのは、不要になったときに自動的に unassigned されるべきことです。 RBAC を組織構造と統合してください。すべてのロール割り当てを再認定するのではなく、ロール定義とポリシーを見直してください。

ポリシーとロール定義の 重複を避けて ください。 "Don't Repeat Yourself" (DRY) は情報技術の基本 mantra の1つです。ほぼ同じだが完全には同じでないコピーを10個作るのではなく、式を持つ1つの parametric ロールを使ってください。ロール assignment の重複も避けてください。ビジネスロールまたは技術的な/IT ロールを使い、ユーザー・ロール割り当ての数を減らしてください。

ポリシーをロール内に encapsulate してください。ロール定義は、そのロールが表すポリシーを表現するために重要なものをすべて含むべきです。権限集合 (または式) をロール内に置き、自動割り当てのためのルールやデータもロール内に置き、説明 (ユーザー向け) と文書 (ロールエンジニア向け) もロール内に置いてください。ロールはできるだけ互いに independent に保ってください。 1つのロールの更新がシステムの他部分に予測不能な cascading side effect を与えないようにしてください。

リスクに従って ください。アクセス申請承認と見直しでは high-risk 領域に焦点を当ててください。高リスクロール割り当ての認定を優先してください。 Cumulative リスク動向を監視してください。もちろん、リスクベース方法を適用するにはリスクがどこにあるかを知る必要があります。そのためには、IGA プラットフォームの組み込み機能として自動化されたリスクモデリングが必要です。

問題を carpet の下に 隠さないで ください。ポリシー exception、temporary hack、historical baggage を明確に mark してください。レポートし、ダッシュボードに表示し、その数が不合理に増えていないことを確認してください。それらを継続的に処理し、ゆっくり整理するプロセスを設定してください。

可能な限り IT と業務を align してください。 IGA システムは IT システムです。しかし大量の業務情報を扱います。 IGA は業務知識、文脈、業務部門の担当者の協力なしには意味を持ちません。 IGA プラットフォームに、管理提示から来た価値のない slide ではなく、実用的で最新な組織構造データがあることを確認してください。ビジネスロールが業務責任、職務、プロセスと一致していることを確認してください。アプリケーションカタログが real IT システムを表していることを確認してください。 IGA は reality の継続的管理です。作られ、送られ、忘れられる monthly spreadsheet ではありません。

データ品質を管理 してください。 "Garbage in, garbage out" という言葉はコンピューター技術の黎明期にまでさかのぼります。今でもまったく真実です。ポリシーベースの方法は品質データに依存しています。アイデンティティ属性はロールを自動割り当てるために使われます。そのような属性の価値が間違っていれば、ロール割り当ても間違います。職務コード、組織上の単位割り当て、類似データが正しいことを確認してください。そのようなデータは多くの場合人事（HR）システムに由来します。 HR システムではそのデータが重要な目的に使われていないため、データ品質が低い場合があります。しかし IGA プラットフォームはそれに依存します。 IGA プラットフォームは通常、データ不整合を検出する最初のシステムであり、それが大きな damage を引き起こす可能性があります。 Im仲介問題を回避するために、IGA プラットフォーム内のデータをすばやく correct する機構を持ってください。また、その元システム (通常は HR) のデータを修正する フィードバックプロセス があることも確認してください。このプロセスは遅く痛ましいですが、絶対に必要です。

システムを良い状態に保つための assistive ツール を導入してください。そのようなツールは現在 IGA プラットフォームに現れ始めています。たとえばプラットフォームは アクセス申請 プロセスでユーザーのロール選択を支援するかもしれません。ユーザーが選択した少数のアプリケーションロールの代わりに、ビジネスロールをユーザーに提案するかもしれません。あなたが design しているロールが既存の別ロールとかなり同じであると warn するかもしれません。ロールマイニングプロセスが継続的に実行され、新しく発見されたロール candidate を notify するかもしれません。 Future がもたらし得る改善は多数あります。

ポリシーマイニング は future に向けた大きな考え方です。ビジネスロールはアプリケーションロールデータからマイニングできます。しかしロールデータをユーザー属性と組織構造と組み合わせれば、policy をマイニングできるかもしれません。特定ロールがいつ割り当て済み・unassigned されるかを決定するルールをマイニングできます。ポリシーマイニングは、policy-driven RBAC へのボトムアップ方法の ultimate ツールになる可能性があります。

その他の注記

RBAC モデルは職務分掌 (SoD) 機能を実装する elegant な方法を提供します。単純ロール排他ルールで、複数のビジネスロールを相互排他的にするには十分です。

理想的には、RBAC モデルのロールは independent であるべきです。そのような方法は、システム内の任意のロールを independent に修正でき、システム内の interference や望ましくない不整合のリスクを避けられます。しかしロール間の dependency は、特に複雑ロール階層では完全には避けられません。一部のシステムはロールモデル versioning と staging 機能を提供します。複数ロールの修正を単一 atomic 単位として適用できます。

完全な RBAC モデル (NIST RBAC 標準など) はセッションと active ロールの概念を含みます。各セッションの開始時に、ユーザーはそのセッションの間 active にするロールを選択するよう求められます。しかし、この機能は RBAC モデルへの完全なコンプライアンスを主張するアプリケーションでさえ、実装されていないことがよくあります。 IGA システムについては、この機能はプロビジョニング/フルフィルメントでは完全にはサポートできません。IGA システムはユーザーセッションを直接制御していないためです。必要な場合、この機能はアプリケーションによって実装されなければなりません。

RBAC のロール構造は、リスク exposure calculation をサポートする重要なツールです。ユーザーはロールに割り当てられ、ロールは権限を imply するため、ユーザーと権限の関係が known になります。個々の権限のリスク exposure はユーザーにプロジェクトでき、リスクホットスポットを特定できます。 RBAC はこのプロセスを比較的簡単にしますが、他のモデル (特に PBAC/ABAC) はこの機能を容易にはサポートしません。

通常の RBAC 階層に加えて、RBAC モデルはさらに別の dimension を持てます。 RBAC モデルは自身に適用でき、ロールがロールを持つことでメタロールを作れます。たとえば Business role と Application role は、それぞれビジネスロールとアプリケーションロールに適用されるメタロールになり得ます。特定ロール種類に共通する機能はメタロールに指定でき、ポリシー定義の重複を減らします。たとえば midPoint の archetype はメタロールとして機能します。

RBAC は主にロールを扱いますが、他の種類のオブジェクトもロールと類似した機能を持ち得ます。たとえば組織上の単位はロールとして動作し、その単位のすべての member に直接権限を付与できます。この方法により、RBAC の効果を他のオブジェクト種類に直接適用でき、ポリシー文の数と複雑性を減らせます。たとえば midPoint の組織構造とサービスはロールとして動作します。

ユーザー・ロール割り当ては、ロールガバナンスのような高度な use-case をサポートするよう拡張できます。たとえば parametrized ユーザー・ロール割り当ては、ユーザーが plain member ではなくロールの owner であることを示せます。この統合された方法により、多くの RBAC-related 機構を再利用し、それらをロールガバナンスにも再適用できます。たとえばユーザーは ordinary ロールメンバーシップと同じ アクセス申請 プロセスを使ってロール owner になることを申請できます。ロール所有権は、ロールメンバーシップに適用されるのと同じアクセス認定機構を使って確認できます。

ロールはユーザーに birthright permission を提供するために使われることがあります。この方法は完全には正しくなく、可能であれば避けるべきです。 Birthright permission はユーザー種類、またはユーザーの類似した inherent 品質によって与えられます。たとえばユーザーは存在する (registered されている) だけで、またはアイデンティティが 従業員 種類であるだけで、特定アクセスを得るかもしれません。 Birthright はユーザー種類を決定したのと同じ機構またはポリシーによって付与されるべきです。たとえば midPoint では、birthright は archetype によって提供されます。

他のアクセスモデル (特に PBAC) の提唱者は、policy-based アクセス制御モデルと ロールベースの アクセス制御を対比し、RBAC が policy-based ではないかのように示します。しかし、ロール、ロール構造、ユーザーへのロール割り当ては ポリシー です。これらのデータ構造はアクセス制御ルールを指定し、したがって誰が何にアクセスできるかのポリシーを指定します。このポリシーは algorithmic ではなく、むしろ declarative ですが、それでもポリシーです。さらに動的 RBAC モデルは algorithmic ポリシーを実装する手段も提供します。

RBAC の一般的な問題

RBAC は単純に見えるアクセス制御機構です。しかし正しく使わないと、予期しない複雑性と complication を生み出すことがあります。この節は、RBAC 機構の利用に関する一般的誤り、misconception、問題をまとめます。

アプリケーションロールの過剰利用 は、おそらく最も一般的な誤りです。アプリケーション権限とエンタイトルメントをアプリケーションロールの形で IGA プラットフォームに取り込みすることは、非常に一般的で正しい実務です。アプリケーションロールは、アプリケーションアカウントへのアプリケーション権限/エンタイトルメントの既存割り当てに従ってユーザーに割り当てられます。この実務は RBAC 導入の非常に良い 出発点 を提供するため、良いものです。問題は、多くの人がこれを完成した RBAC 導入と見なすことです。そうではありません。アプリケーションロールは権限の IGA equivalent です。アプリケーションロールをユーザーに直接割り当てることは、permission をユーザーに直接割り当てることを意味します。これは RBAC 構造ではありません。ロール はほとんど関与していないからです。この時点で持っているものは RBAC ではありません。

労力は business role の導入へ続くべきです。これが RBAC モデルを作る最初の手順です。ビジネスロール割り当てを自動化し、アプリケーションロールの直接利用を minimize するためにポリシーを適用すべきです。ユーザーへのアプリケーションロールの直接割り当ては標準と見なすべきではなく、ポリシー exception、最終的にクリーンアップされるべき負債と見なすべきです。実践的な導入では、特殊なケースをビジネスロールに整理する労力に見合わないため、直接アプリケーションロール割り当てがある程度残ります。しかしそれは最小限に保ち、アプリケーションロールの過剰利用を避けるために注意深く監視すべきです。

アクセス申請 frenzy も非常に一般的な課題です。 アクセス申請 プロセスが導入されると、それをあらゆる問題を解決する汎用ツールとして使う傾向があります。ユーザーはロールが何を意味し、なぜ必要なのかを本当に理解しないまま、多数のロールを申請することがよくあります。同僚が持っているロール集合と同じものを blindly に申請することは非常に一般的な実務です。また承認者も、アプリケーションロールの申請が substantiated かどうかを知らないことがよくあります。彼らはそのようなロールの目的を理解していないためです。申請が「looks good」である限り、深く考えずに承認します。これは必然的にアプリケーションロール割り当ての無限 spaghetti につながります。

IGA 導入の start 時点で RBAC 構造がまだほとんどない場合、アクセス申請 プロセスの wild 利用は許容されるかもしれません。プロジェクトの後半では、アクセス申請 プロセスはビジネスロール申請を prefer するよう tune されるべきです。 Recommender やその他高度な手法の使用は、将来プロセスをさらに改善できます。しかし最も重要な成功要因は、ビジネスロールのエンジニアing と、その管理のための自動ポリシーを進めることです。ロールマイニングは導入初期の アクセス申請 プロセスの uncontrolled 利用によって生じた mess をクリーンアップするための非常に有用なツールになり得ます。

Rubber-stamp 認定 は巨大で無意味な exercise であり、通常は アクセス申請 プロセス abuse の consequence です。 アクセス申請 プロセスはアプリケーションへのアクセスを得るための quick で非常に convenient な方法です。しかしアクセスが不要になったときにそれを削除する motivation はほとんどありません。 Excessive アクセスを削除するために認定キャンペーンが使われます。 アクセス申請 プロセスによって付与されたすべてのロールは、定期的で確認されなければなりません。責任者は、そのアクセスがまだ必要であることを確認しなければなりません。しかし膨大な数のロールがユーザーに付与されている場合、認定キャンペーンも巨大になります。認定者がすべてのユーザーに付与されたすべてのロールを責任を持って判断し、それを定期的で繰り返すことは、その機能を超えています。認定キャンペーンは 形式的な承認 exercise になり、多くの認定者は深く考えずにすべてのロールを accept します。つまり、削除されるアクセスは非常に少なくなります。新しいアクセスが継続的に付与され、アクセスが削除されないため、認定キャンペーンは大きくなり、それが形式的な承認の motivation をさらに高めます。結果として vicious spiral になります。

Symptom が発生した後にそれを treat する方法はあります。リスクベースの認定は、認定者の注意を機密性の高いロールに集中させ、少なくとも高リスクロールの形式的な承認を減らそうとするために使えます。これは良い最初の手順かもしれません。一部の IGA プラットフォームは認定判断を支援する人工知能機構を提供します。しかし形式的な承認実務がすでに標準になっている場合、人工知能でさえその実務に従います。この方法は形式的な承認をより効率的にすることはできますが、問題の core には対処しないかもしれません。

最良のソリューションは症状への対処に焦点を当てるのではなく、問題の根本原因に対処します。ソリューションは、ビジネスロールと policy-driven 自動化を導入してアプリケーションロール割り当ての数を減らすことです。 Root 原因は本質的に同じであるため、このソリューションは他の問題のソリューションと基本的に同じです。

ロール爆発 は静的 RBAC モデルのよく知られた問題です。いくつかの原因があり得ます。おそらく最悪の原因は、動的で多次元的な概念を静的モデルで説明しようとする欲求です。たとえば責任と勤務地の両方をロールに含めようとすると、New York Supervisor、New York Director、Boston Supervisor、Boston Director など、ロール組み合わせの explosion が起こります。また、ビジネスロールレベルで最小権限の原則をやりすぎる attempt や、すべてのポリシー exception と anomaly を systemic ビジネスロールで cover しようとする attempt もロール爆発につながり得ます。

ロール爆発の systemic 原因と戦う最良の方法はアルゴリズムによるポリシーを使うことです。たとえば動的ロール式とパラメーターは、動的で多次元的な概念によって起こる爆発を避ける非常に効率的な方法です。 Overzealous なロールモデリングによるロール爆発は、モデルは決して perfect にはならず、常に exception と leftover があることを認めることで、比較的容易に対処できます。

ビジネスロール重複 は、やや少ない問題です。ロールエンジニアリングが複数人に分散している場合、またはモデルが非常に複雑で古くなったになった場合に発生します。同じビジネスロールが2人によって作成されたり、元のが作成され忘れられてから長い時間の後に再作成されたりします。また、通常はロールエンジニアの neglect や limited 知識により、あるロールの一部が別のロールにコピーされる形で意図的に発生することもあります。

Unintentional ロール重複は、新しいビジネスロールを作成する前にエンジニアが類似ロールの存在を確認しなければならない、というロールエンジニアリングプロセスによって部分的に対処できます。しかし RBAC モデルが成長するにつれて、これはますます難しくなります。理想的なソリューションは IGA tooling のサポートであり、新しいロールが既存の別ロールと非常に類似であるとエンジニアに warn することです。 Intentional ビジネスロール重複は別です。ロール定義の一部をコピーすべきではありません。代わりに小さなロール階層を作り、両方のロールが一般的 sub-role を share するべきです。

ロール decay は古い導入の問題です。そもそもロールを定義するだけでも十分に困難です。しかしロール定義は見直され維持管理される必要があります。そうしなければ、最終的に業務現実から乖離します。ロール見直しと維持管理は困難で、ある意味退屈な作業であるため、しばしば軽視されます。

1人が entire RBAC モデルを適切に維持管理することは通常不可能です。ソリューションは作業を distribute することです。ロールに owner、つまりロール定義の維持管理に責任を持つ人物を割り当ててください。ビジネスロールでは、owner は通常業務部門の担当者です。特にロールから過剰な権限を削除し、古くなったロールを廃止することに重点を置いた、ロール定義の見直しと更新の規則的プロセスを設定してください。

しかし ultimate ソリューションは、自分たちの機能を理解することです。モデルを維持管理できないほど過度に複雑化しないでください。あなたとチームが完全な RBAC モデルを維持管理できない場合、妥協案を検討してください。制御された over-provisioning を許容し、より単純で「大きな」ロールを作る方が lesser evil かもしれません。 Outdated ロール定義も over-provisioning をもたらす可能性がありますが、それは隠れたである可能性が高いです。システム内の大量の不明リスクを疑うよりも、known リスクをある程度受け入れる方が wise かもしれません。

Phantom ポリシー は一般的組織上の問題であり、RBAC に限られません。理論上、どの組織でもアクセス制御ポリシーは well-known で、clearly-formulated で、文書化され、properly 維持管理されるべきです。通常はそうではありません。ポリシーは文書化されていない、ambiguous で、subjective 考慮とアドホック判断に基づいています。そのような「ポリシー」をアクセス制御機構で表現できるでしょうか。

明らかにトップダウン方法はここでは機能しません。しかし組織は何らかの方法で動いているため、明らかではなくても、何らかの半体系的なポリシーが存在しているはずです。私たちはポリシー、または少なくともその一部を発見しなければなりません。切迫した状況には思い切った対策が必要です。アプリケーションロールとアクセス申請プロセスの組み合わせはしばしば失敗につながりますが、このケースでは適用する価値があるかもしれません。アクセス申請プロセスからデータを得て、mining ツールでロールを分析し、ポリシーの一部を抽出してみることができます。簡単ではありませんが、start にはなります。

重要なのは、これは start であるということです。プロセスはそこで止まってはいけません。組織が phantom ポリシーに固執していては遠くへ行けません。ポリシーの一部が検出されたら、それは文書化、reviewed、改善されなければなりません。 IGA 方法と業務の両方が互いに適応しなければなりません。業務側が変われない場合、この IGA 労力全体はいずれ death march になります。

IT 部門による集中化されたロール管理 は、IGA ソリューション導入時の一般的な実践です。しかしそれも誤り実務です。確かに アプリケーション ロールは IT 部門が管理できますし、管理すべきです。しかし IT 部門には業務ロールを管理するために必要な知識がありません。 IT 部門がビジネスロールを定義しようとする attempt は点less です。結果として生じるロールは業務単位にとって役に立たなくで、必要性に合わず、アプリケーションへのアクセスを得るためのさらなる confusing 障害になるだけで、すべてを悪化させます。

ビジネスロールは業務概念に align されなければなりません。業務概念を知っているのは業務部門の担当者だけです。したがって業務部門の担当者はビジネスロールエンジニアリングに関与しなければなりません。以上です。

もちろん、業務部門の担当者は通常ロールを定義する技術的な skill を持っていません。特にロールエンジニアリング労力の初期では、IT 担当者でさえ少し迷うことがあります。したがって、ロールエンジニアリングプロセスが IT と業務の密接な協力として始まることが重要なです。チームが経験を得るにつれて、より多くの労力を業務部門の担当者に委任できる可能性があります。それでもロールエンジニアリングプロセスは常に業務と IT の両方を含む協力作業です。

あらゆるものをロールにする。 Engineer がロールの概念をつかむと、すべてがロールに見え始めます。もちろん Branch supervisor や Marketing assistant のロールはあります。しかし突然、Employee、Marketing 部門、New York Branch、Project X member のロールが現れます。そしてルールも現れます。location 属性の価値が NY であるユーザーは New York Branch ロールを得る、という具合です。最終的にはロール、ルール、naming convention、カテゴリの avalanche になります。 RBAC labyrinth へようこそ。

この方法は一見 sound に見えますが、そうではありません。重複が多すぎます。 Employee はロールではなく、おそらくユーザー種類です。従業員に属する birthright permission はロールによって付与されるべきではなく、ユーザーが従業員であると決定したのと同じ機構によって割り当てられるべきです。それは通常、何らかの HR 同期、または IGA プラットフォームの組み込み typing 機構です。それをロールにしたくない good reason があります。そのロールが unassigned されたら何が起こるのでしょうか。また Marketing 部門 はロールではなく組織上の単位です。システム内に Marketing 部門 組織上の単位と Marketing 部門 ロールの両方を持ちたくはありません。それは confusion の処方箋です。 Marketing 部門で働くために必要な権限はロールではなく、Marketing 部門 organizational unit によって付与されるべきです。同様に、New York Branch と Project X は組織上の単位の別形態にすぎません。同じ論理がここにも適用されます。

組織構造をロールでモデル化しようとしないでください。代わりに real 組織構造を使ってください。勤務地をロールでモデル化しようとしないでください。代わりに勤務地ディレクトリを使ってください。アプリケーションをロールでモデル化しようとしないでください。代わりにアプリケーションカタログを使ってください。職務に適したツールを選んでください。 Role は golden hammer ではありません。