Skip to content

IGA 機能: ポリシーとロールの管理

この記事は https://docs.evolveum.com/iam/iga/capabilities/policy-and-role-management/ の翻訳です。

別名

  • ロール管理
  • ロールガバナンス
  • オブジェクトガバナンス
  • ロールモデリング
  • ロールライフサイクル管理
  • ポリシー管理

ポリシーとロールの管理機能

  • ロールベースのポリシー。 ロールベースのアクセス制御 (RBAC) 機構など、ロールに基づくポリシー定義。
  • ロール構造。 アクセスと定義を容易にするためのロールの組織。 ロール階層、ロールカタログ、metarole などの機構を使用します。
  • ロールモデリングとガバナンス。 ロール定義の作成と効率的維持管理。 ロールライフサイクル、ロール所有権、ロールモデル バージョン管理とキュレーション、見直しと 承認プロセスの管理。
  • 職務分掌。 危険な権限組み合わせを prohibit するポリシー。
  • 自動ロール割り当て。 通常はルール集合を使ったロールの自動割り当ておよび解除。
  • 代理管理。 通常は短期間、ユーザーからユーザーへ正しいをアドホック delegation すること。

概要

ポリシーはアイデンティティガバナンスの heart です。 ポリシーは、物事がどう あるべきか、すべてのシステムとデータの理想的な状態を指定します。 組織と規制はかなり複雑になりがちであるため、ポリシーも複雑になりがちです。 さらにポリシーは、changed 規制や組織上の必要性に反応して変わる傾向があります。 これらすべてが、ポリシー管理を非常に困難なものにします。

組織上のポリシーを表現する方法は多数あります。 ポリシーは完全に non-structured な free-form 本文として表現されることがあり、その場合は人間だけが、しかもかなり ambiguous な形で interpret できます。 ポリシーは compilable コードとして表現され、computer が unambiguous に interpret できることもあります。 しかし、これら極端な方法はどれも実務では機能しません。 したがって現実には、ポリシーの表現方法はその両極端のどこかにあります。

アイデンティティガバナンスポリシーを表現するために使われる方法の多くは、ロール 概念に依存しています。 Role は、権限を named で manageable な集合にグループ化したものです。 理想的には、ロールは職務上の位置付けや組織上の責任など、現実世界の概念に関連するべきです。 しかしロールと現実世界の概念の対応が常に可能なわけではなく、多くのロールはその性質上かなり abstract です。 Role の重要な characteristic は、ロールにグループ化された個々の権限よりも管理しやすいことです。

理論上、ロール は entitlement のグループ化です。 IGA 文脈では通常、LDAP グループ、アプリケーション権限、特定のアクセス制御リストに 一致するアカウント属性価値など、application-specific エンタイトルメントのグループ化を意味します。 従来の RBAC 文脈ではこのようなロール定義は通常ユーザーがシステムにログインするときにプロセスされます。いわゆる "just in time" 方法です。 しかし IGA 文脈ではロールは別の方法でプロセスされます。 ロール定義は、ユーザーがシステムに初めて login する前にプロセスされなければなりません。 IGA ロールのメンバーシップは、ロールがユーザーに割り当てられた時点で、そのアカウントが特定の LDAP グループまたはアプリケーション権限に 関連付けられる、つまりメンバーにされることを意味します。これはユーザーがログインするずっと前に行われる、いわゆる "just in case" 方法です。

ロールは通常、他のロールを含むことができ、これにより ロール階層 が作られます。 ロール階層は 再利用 の形式として利用でき、よく使われる権限グループをロールにまとめ、それを他のロールに含めます。 しかしロール階層は通常、ロールをいくつかの種類または layer に分けるために使われます。 通常のロール種類は次のとおりです。

  • アプリケーションロール は単一のアプリケーションまたはシステムへのアクセスを付与します。 アプリケーションロールはグループなどの application-level エンタイトルメントに対応することがよくあります。 通常、単一アプリケーションのアカウントとエンタイトルメントを付与します。 多くの IGA プラットフォームはアプリケーションロールをまったく必要とせず、application-level エンタイトルメントを直接管理できます。 しかし、そのようなプラットフォームでもガバナンス目的でアプリケーションロールを使うことがよくあります。 アプリケーションロールはエンタイトルメント、たとえば Active Directory グループと自動的に同期されることがあります。
  • 技術ロール または IT ロール は、主に他のビジネスロールで 再利用 する目的の権限のアドホックグループ化です。 これらは reports 読み取り専用アクセス や basic OS permissions など、組織上のまたは管理概念を表すことがありますが、完全業務概念は表しません。 技術的な/IT ロールは複数のアプリケーションにまたがる場合があります。 通常、アプリケーションロールの組み合わせとして定義されます。
  • ビジネスロール は、職務上の位置付けや職務責任などの business-level 概念を表すことがよくあります。 ビジネスロールは、IT slang ではなく組織上の と 業務用語を使い、一般的ユーザーに理解できるよう設計されます。 一般ユーザーはアクセス申請プロセスで適切なビジネスロールを探すことが想定され、マネージャーは申請を見直して承認/reject することが想定されます。 したがってビジネスロールがユーザーに理解できる言語を使うことは極めて重要です。 ビジネスロールは通常、アプリケーションロールや技術ロールの組み合わせとして定義されます。

すべてのロールベースの機構の中で最も困難な部分は、間違いなくロール定義の design と維持管理です。 私たちはこのプロセスを role 管理、またはより正確には role ライフサイクル管理 と呼びます。 典型的な中規模から大規模の組織は大量のロールを必要とします。 1人、または小さなチームだけで数千のロール定義を作成し維持管理することは考えにくいです。 ロールには、特定チームや職務上の位置付けの責任など、大きな量の組織上の知識が含まれます。この知識は、多くの場合どこにも文書化 も recorded もされていません。 ロール定義には、業務単位、アイデンティティチーム、セキュリティ office、管理など、多くの人の協力が必要です。 そのためロール定義 と 維持管理作業は、複数の人々またはチームに分散されることがあります。

一般的な方法は、ロールに owner を割り当てることです。 Owner はロール定義の維持管理とロール usage の policing に責任を持ちます。 ロール所有権 は、ロール維持管理作業を分散する方法の1つで、通常ビジネスロールに適用されます。

ロールは ロールカタログ に整理 されることがあります。これは電子ショップのカテゴリ に似た階層的構造です。 Catalog は通常提示目的に使われ、一般的ユーザーがロールを選択しやすくします。特に アクセス申請 プロセスのためです。 しかしロールカタログは複数存在することがあり、一部のカタログはロール維持管理の目的で使われることがあります。 たとえばロール提示カタログは業務機能や 関心領域 に従ってロールを整理 し、 ロール定義カタログはロール定義維持管理に責任を持つ業務単位や 領域 に従ってロールを整理 し、さらに別のカタログはレポートやコンプライアンス目的のためにロールを整理 することがあります。

個々のロールの定義と維持管理は independent チームに分散できますが、role model 全体の維持管理には強い coordination が必要です。 Role model は組織で使うよう design されたロール集合です。 ロールモデル内の個々のロールは、業務 観点 と実装、つまり IT 観点 の両方から意味を持つよう、互いに連携することが想定されています。 Independent owner が design したロールは、一貫したロールモデルとしては理想に満たないことがよくあります。 Duplicate ロール、ロール階層を使わず定義をコピーするロール、overlapping ロール、non-systemic ロール naming convention などが発生します。 ロールモデルは curated されなければなりません。 個々のロールの定義は経験d アイデンティティ specialist によって coordinated される必要があります。そうでなければロールモデルは un保守可能 な状態に進化します。 またビジネスロールは通常 lower-level ロール、他のビジネスロール、技術的な/IT ロール、アプリケーションロールに依存します。 したがってロールを1つずつ変更しても意味がありません。 ロールモデル全体への変更はまとめて検討され、見直され、検証され、一貫したポリシーとして適用されなければなりません。 ロールモデルのバージョン管理 は、ロールモデルへの一貫した更新を整理 するために使われます。 ロールモデルの古いバージョンが使用されている間に、新しいバージョンを準備、見直し、修正、承認でき、本番環境には影響しません。 モデルの新しい version が ready になると、本番環境は1つの操作で新しい version に switch できます。

システムへの新しいロールのはじめには比較的 easy です。 既存ロールの修正はより困難です。 しかし既存ロールの廃止 は、おそらく最も困難なプロセスです。 ロールは通常既存ユーザーに割り当てられており、ユーザーはロールが提供する権限を使っていることが多いため、ロールをすぐに削除することはできません。 通常のプロセスは、まずロールを deprecated として mark することです。 これによりロールは further 割り当てには un可用になりますが、既存割り当ては functional のままです。 次に deprecated ロール割り当てが evaluated され、新しいロールの equivalent 割り当てに置き換えられます。 Deprecated ロールがもはや割り当てられていなければ、削除または archive できます。

ロールモデルの design と維持管理は art であり science でもあります。 適切なバランス、組織構造、プロセス、culture についての適切な理解 が必要です。 ロールモデルは非常に簡単に大きく間違えられます。 ロールモデリングにおける well-known 課題の1つが role explosion 問題です。 Role explosion は、ロール定義の multiplication が制御不能になることです。 ロール爆発 は、ロール定義内のアルゴリズムによる機能、RBAC/ABAC hybrid、metarole、ロールに適用されるロール、または類似機構など、高度な ロールベースの機構を使うことで mitigated できます。

全体として、ロールは増殖する傾向があります。 新しいロールを作るのは簡単ですが、ロール定義を最新に保ち、古いロールを廃止するのはかなり困難です。 ロール認定プロセスは、ロールの数が制御不能に増える自然な tendency に対抗できます。 ロール認定はアクセス認定とほぼ同じ方法で機能します。 ただしユーザー・ロール 割り当てではなく、ロール定義が 認定されます。

用語

NOTE: Role 管理 と ロールベースのアクセス制御 (RBAC) という用語は、人によって多くの意味を持ちます。 私たちはロール関連用語をかなり広い意味で使います。 NIST RBAC モデルや、その他の 形式化されたロールベースのアクセス制御モデルを指しているわけではありません。 私たちが意味するのは、ロール概念に基づく一般的な機構です。 多くのロールベースの機構の基本原則は似ていますが、微妙な詳細があります。 私たちはそのような詳細を抽象化しようとしています。 また、この節は主に role 管理、つまりロール定義を作成し維持管理するプロセスについて述べています。 厳密に言えば、これはロールベースの アクセス制御 (RBAC) とは異なります。RBAC はロールを使って資産へのアクセスを制御するプロセスです。

ロールを使わずにポリシーを表現する方法もあります。属性ベースアクセス制御 (ABAC) などです。 そのような方法は非常に powerful で、極めて柔軟になり得ます。 しかし大きな力には大きな責任が伴い、そのようなポリシーは長く複雑になるにつれて、管理がほぼ常に problematic になります。 たとえば ABAC ポリシーを小さな piece に分割し、それぞれを independent delegated 管理者が管理することは困難です。 ロールは管理責任のそのような separation を可能にします。 さらにロールはガバナンスを単純化します。ロール 設計者、owner、reviewer を指定でき、ロールは認定労力を分割する natural boundary を提供するからです。 したがって、実践的なアイデンティティガバナンス導入の大半はロールベースのです。ただしロールは通常、その定義内にある程度の ABAC-like 柔軟性 を提供し、実質的に RBAC/ABAC hybrid を作ります。

ロールはいくつかの方法でユーザーに割り当てられます。

  • ロールはアイデンティティ管理者によってユーザーに手作業で割り当てられます。 この方法は単純ですが、非常に小さな導入でしか現実的ではありません。
  • ロールはルールに基づいて自動的に割り当ておよび解除されます。 Rule は多くの場合ユーザーの組織上のメンバーシップに基づきます。
  • ユーザーが アクセス申請 プロセスでロール割り当てを申請します。 申請は通常マネージャー、ロール所有者、セキュリティスタッフなどによる承認の対象です。

実践的な導入では3つの方法の組み合わせが使われます。 手作業ロール割り当て/割り当て解除 はまれに使われ、通常特殊なケースまたは emergency situation です。 自動ルールベース ロール割り当ては、ユーザーの組織上の割り当てと明確に関連するロールに使われます。 たとえば Basic 従業員 ロールは特定組織のすべての従業員に割り当てられ、監査人 ロールは情報セキュリティチームのすべての member に付与されることがあります。 一般的ケースでは、particular ロールを誰が持つべきかというルールが不明であるため、自動的に割り当て済み/unassigned できるロールは比較的少数です。 ロールの大半は アクセス申請 プロセスを使って割り当てられます。

ロール構造と内容は、アクセス制御ポリシーの大きな部分を指定します。 したがってロール割り当てをユーザーに制限するポリシーがあるのは自然です。 Segregation of duties (SoD) ポリシーはロールレベルで実装されることが多く、特定のロール組み合わせをユーザーに割り当てることを拒否します。 たとえばユーザーは Funds requester ロールと Funds approver ロールのどちらかを持てますが、両方を同時に持つことはできません。 SoD ポリシーの目的は、同じ人物が fund を申請し承認する権限など、危険な権限組み合わせを避けることです。

ポリシーは通常、複数の enforcement mode で適用されます。 ポリシーは fully 強制できます。たとえば SoD ポリシーに違反するロール割り当てを strictly 拒否します。 これはポリシーの preventative アプリケーションとして知られます。ポリシーが違反の発生を prevents します。 あるいは、ポリシーは承認を求め、承認された場合に割り当てを許可することがあります。 ポリシーは強制なしで設定され、違反のレポートだけを行うこともあります。 これはポリシーの 検出的 適用として知られ、ポリシー違反を 検出 し、それをフォローアップ します。 この選択肢は新しいポリシーを導入するときによく使われます。多数の違反が存在すると予想されるためです。 ポリシーは違反を見つけ、それぞれを個別に remedy し、完全なコンプライアンスに向けて gradually progressing するために使われ、その時点でポリシーを fully 強制できます。

ポリシーは remediation、つまりポリシー違反に対処するプロセスと密接に関連しています。 しかし remediation は多くの場合手作業プロセスであり、workflow 機能によって governed されます。 ポリシーエンジンは是正プロセスを initiate する、つまりワークフローを start する、またはケースを open する責任を持ちます。

ロールは組織構造割り当てと組み合わせて、delegated administration ポリシーの定義に使えます。 たとえば、特定集合のユーザーの管理を専用管理チームに delegate し、必要に応じて管理正しいを limit できます。 Delegated 管理はロール定義、設定維持管理の分散や、類似目的に使われることがあります。

Delegated 管理は管理者によって規定され、めったに変更されない "静的" ポリシーです。 一方、ユーザーの特定責任を短期間だけ別のユーザーに 委任する必要があることもよくあります。 この機能は、vacation や業務 travel 中に権限を temporary に 委任するためによく使われます。 そのような delegation は通常、delegating ユーザーがセルフサービスユーザーインターフェイスを使って構成します。 そのような "deputy" は delegation が expire するまで、delegating ユーザーの権限を使えます。