IGA 機能: アクセス申請

この記事は https://docs.evolveum.com/iam/iga/capabilities/access-request/ の翻訳です。

別名

ロール申請と承認

ロール申請プロセス

承認

アクセス申請機能

アクセス申請ユーザーインターフェイス。一般的ユーザー向けのユーザーインターフェイス。通常ロールを含む申請を構成できるようにします。ユーザーインターフェイスは電子ショッピング、つまりショッピングカートのパラダイムに従うことが多く、利用可能なロールをカテゴリに整理し、ユーザーフレンドリーなロール検索、申請ポリシー検証などを提供します。申請提出後の申請状態 tracking をサポートします。ロールの unassignment を申請することも含みます。

承認スキームの管理。承認スキーム、承認レベル/段階、各レベル/段階の承認者グループ、optional 承認レベル/段階などの定義。ロール種類またはグループごとの scheme、機密性の高いロール向けの scheme variation、リスクベース承認スキームなどの定義。

承認プロセスの実行。承認スキームの execution。アクセス申請を承認レベル/段階に通します。承認者との人間によるやり取り。承認者に申請を人間にわかりやすいな形式で提示します。承認者判断、承認/拒否の handling、free-text communication、承認者 comment の handling。申請を別の人物がプロセスするために optional forwarding すること。

承認に関する説明責任記録の維持管理。説明責任、つまり監査目的のためのアクセス申請と承認プロセスの記録。メタデータ、誰が申請し、誰が承認し、いつ行われたかなどの recording。

承認済み申請の即時フルフィルメント。承認済み申請の結果に従い、アカウントを im仲介に作成し、エンタイトルメントと associate すること。

概要

アクセス申請 は、ユーザー主導のロールとエンタイトルメントの割り当てを制御された形で行うプロセスです。通常は、ロールをユーザーに割り当てる申請と承認プロセスとして実装されます。ロールは通常、セルフサービスユーザーインターフェイスを使ってユーザーによって申請されます。その申請は一連の承認手順を通過します。承認されると、ロールは自動的にユーザーに割り当てられます。

プロセスの最初の手順は申請です。この手順の複雑なな部分は、申請するものを select することです。申請は通常、申請を作成しているユーザーに割り当てられる ロール を specify します。 Role を申請することは大いに理にかなっています。ロール、特に business role は業務と密接に関連しているため、申請ユーザーはロールが表す概念を理解できる可能性があり、申請が意味のあるになる可能性が高くなります。またロールは通常申請に適した "size" を持ちます。細かすぎる非常に細粒度エンタイトルメントではなく、大きすぎる多すぎる権限でもありません。しかし mid-size の IGA 導入でさえ通常ロールは数千あるため、ロールの提示、navigation、selection は challenge です。

多くの IGA プラットフォームはロール選択に ショッピングカート 方法を採用しているようです。ロールは electronic shop が商品を提示するのと似た方法で presented されます。 Category、recommended 項目、広く使われている項目、その他ユーザーが appropriate ロールを select するのを助ける visual aid があります。ロールカテゴリはほぼ常に role カタログ の構造に基づきます。ユーザーは "ショップ" を閲覧し、適したロールを ショッピングカート に入れます。 IGA プラットフォームはロールと cart を presenting する際、通常ロールポリシーを考慮します。たとえば職務分掌 (SoD) ポリシーのケースでは、競合するロールが選択内でマークされたり、申請が配置される前に警告が出されたりします。

申請は通常 "myself" に対して行われます。つまりロールを申請する人物が、最終的にそのロールを得る人物でもあります。あるいは、チーム leader がチーム member のためにロールを申請するなど、別の人物のために申請するケースもあります。実務では両方の方法が使われます。

他の誰か、通常は申請中の人物の colleague が持つロールを申請するという、非常に魅力的な選択肢もあります。この選択肢は ordinary ユーザーの life を楽にできる一方で、非常に controversial です。第一に、通常の実務では、すべてのロールが必要かどうかを real 考慮せず、他の人物が持つ all ロールを申請します。これは least privilege 原則に関して大きな問題です。ロール割り当ての uncontrolled 増殖につながる可能性があるからです。第二に、これはロール割り当ての repetition、つまり redundancy につながります。そのような申請が承認されると、同じロール集合を持つ2人のユーザーが生まれます。一方の人物の職務責任が変わったとき、もう一方の人物のロール割り当ても更新する必要がある可能性が非常に高くなります。このような situation はシステムの維持管理を難しくし、"as somebody else has" というロール割り当てが増えるたびに状況は悪化します。このケースで行うべき正しいことは、「他の人物」の権限集合から新しいロールを作成し、そのロール集合が業務とセキュリティの両方の観点から意味を持つか見直しことです。その後、新しいロールを両方の人物に割り当てすべきです。残念ながら、既存の IGA プラットフォームではこの方法へのサポートは非常に少ないです。

プロセスの second 手順は申請の承認です。一部の申請は承認なしで execute できますが、大多数の申請は人間による承認を必要とします。この手順は自動化が非常に困難です。結局のところ、ユーザーにロールを与えるアルゴリズムによるルールがあるなら、そのルールは通常、ユーザーがロールを申請する必要なく先回りして適用できます。 アクセス申請 プロセスの要点は、ロール割り当てのルールが不明である、または algorithmically に実装できないことです。多くの承認は "looks good" basis で行われ、ルールに従うのではなく、承認者が申請が業務観点から意味を持つか判断します。 "業務観点から意味を持つ" というルールは、通常暗黙的、非アルゴリズム的、変化し続けるです。したがって判断は human brain、より多くの場合 human brains によって下されなければなりません。承認には複数のレベル、または段階があることがよくあります。 First 承認レベルは通常、申請ユーザーのラインマネージャー、つまり直接監督者です。この承認レベルは通常2つの理由で実装されます。第一に、過剰なまたは意味のないな申請を迅速に stop する filter として機能し、filtering 作業を大きなユーザーグループに分散します。第二に、そのような申請が行われていることをマネージャーに知らせる形式です。第2承認レベルは通常、そのロールまたはロールがアクセス権を与えるアプリケーションに責任を持つ人物、つまり role/アプリケーション approver による承認です。 Third 承認レベルは通常 optional で、特殊なまたは機密性の高いロールにのみ reserved されます。このレベルは通常情報セキュリティスタッフによって処理されます。レベルは通常 sequence で実行されます。たとえば第2承認レベルは第1レベルが処理されたときにのみ開始されます。この方法はプロセスを長くしますが、上位レベル承認者の負荷を reduce します。

承認スキーム、つまり承認レベルと承認者は、通常ロールまたはロールグループごとに異なります。一部のロールは承認をまったく必要としない場合があります。他のロールは single-level 承認だけを必要とするかもしれません。大半のロールは、おそらくマネージャーと involved アプリケーションの業務 owner による承認を必要とします。一部のロールはセキュリティスタッフによる additional 承認を必要とするかもしれません。承認レベルと承認者グループの特定の集合はロールごとに異なる場合があります。実際のスキームは理想的にはコンテキスト認識型かつリスクベースであるべきです。たとえば低リスクロールであっても、申請ユーザーが既存ロールから蓄積している総リスクが高すぎる場合にはセキュリティ office による承認を必要とします。

承認プロセスは人間によるやり取りを伴う手作業プロセスです。 Requester がアクセスを申請する理由を書き、承認者が判断に comment するなど、何らかの free-text communication が含まれることがよくあります。一部のプロセスでは申請を別の人物に "forwarded" して処理できます。したがって、人々、comment、判断の比較的複雑な痕跡が存在し、通常記録されます。そのような記録は追加メタデータとともに、重要な 説明責任 機構です。後で割り当てが re-certified されるとき、またはインシデント調査のケースで証拠になる可能性があります。通常の運用ケースであっても、メタデータは重要な可視性と診断機構であり、誰がアクセスを申請されたし、誰が承認し、それがいつ起きたかをすばやく示します。

明らかに、承認プロセスは単純とはほど遠いものです。承認プロセスには surprising 量の identity-specific ロジックがあります。承認スキームの動的 computation に加えて、元の申請は smaller 部分に split され、potentially 各個々のロールが異なる承認レベルと承認者集合に送られる必要があります。申請はプロセスの end で merged され、承認された申請部分と rejected された部分を correctly reflect する必要があります。多くの IGA プラットフォームは汎用エンタープライズワークフローエンジンを使って承認プロセスを実装しようとしています。しかしそのような attempt は、必要な柔軟性レベルを deliver できないか、非常に複雑で保守困難なソリューションになります。これは、ほぼすべてのアイデンティティ管理システムに影響する可視化の難しさによってさらに増幅されます。アイデンティティ管理概念はかなり複雑で confusing になり得るため、何が申請され、申請のどの部分が承認され、どの文脈で申請が行われたのかを visualize するのは簡単ではありません。汎用ワークフローエンジンはそのような複雑性を扱うようには設計されていません。したがって specialized, identity-aware ユーザーインターフェイスの方がはるかに優れたユーザー経験を提供します。

プロセスの third 手順はロール割り当てです。承認された申請の部分は fulfilled されなければなりません。多くの IGA プラットフォームは統合済みフルフィルメント機構を使って申請を im仲介に fulfill します。一部のプラットフォームは、申請のすべての部分についてすべての承認者が判断を made した場合にのみ申請を fulfill できます。しかしこれは、単一承認者が大きな申請を hold back できることを意味します。他のプラットフォームには、pending 承認のロールを待たずに、承認された申請部分を im仲介に実現する選択肢があります。

アクセス申請 プロセスの目的は、ロール、そして可能性として他のエンタイトルメントをユーザーに assignment することです。しかしユーザーに新しい権限を追加する効率的プロセスがあると、権限は増え続け、危険な権限蓄積に達します。 アクセス申請 プロセスの cumulative effect は、もはや必要でないエンタイトルメントの removal に重点を置いた inverse プロセスによって counter-acted されることが極めて重要です。素朴な IGA ソリューションはシステム管理者の手作業作業や手作業, paper-based プロセスに依存することがよくあります。しかしそのような機構はアクセス申請プロセスの効率にはまったく及ばず、ロールが追加される速さでロールを削除することは決してできません。アクセス申請プロセスに counter-act できるおそらく唯一の実践的なソリューションは アクセス認定 です。アクセス申請プロセスが使われる場合、効率的アクセス認定はほぼ常に absolute necessity です。

全体として、アクセス申請プロセスは非常に有用なツールです。特にアクセス制御ポリシーが暗黙的、不明確、または完全に直感的な場合です。しかしそのようなケースでは、アクセス申請プロセスの利用は通常問題のソリューションではなく、問題の根本、つまり効率的ポリシーの欠如を覆い隠すだけです。そのようなケースでアクセス申請プロセスを集中的に使うと、問題のあるロール割り当ての量を増やし、維持管理労力を増やし、根本問題に対する体系的なソリューションのはじめにを難しくし、状況を worse にする可能性が高いです。アクセス申請プロセスの適度な利用は完全に許容できます。実際、アクセス申請プロセスをまったく使わずに実践的な IGA ソリューションを導入することはほぼ不可能です。しかしそれは節度の範囲で消費されなければならず、そうでなければ確実に制御を失います。

注記

ほぼすべての IGA プラットフォームは大まかには同じ request-approval-fulfilment プロセスを実装していますが、詳細はしばしば大きく異なります。申請ユーザーインターフェイス、別名 "shopping cart" には大きな違いがあり、ユーザー経験の品質もさまざまです。一部の IGA プラットフォームには、承認プロセスの期間中ユーザー記録全体をロックするなどの serious 実装制約があります。他のシステムは、特定時点で各ユーザーに active な申請を1つだけサポートします。承認プロセスは長時間かかることがあるため、そのような制約はアイデンティティ管理とガバナンスプロセスに深刻な影響を与えます。一部のシステムは内部実装を使ってプロセスを実装し、他は汎用ワークフローエンジンを使います。ワークフローエンジンとの統合品質は製品ごとに大きく異なります。ユーザーインターフェイスの品質は通常かなり明らかですが、アクセス申請プロセスの他の詳細は隠れたです。アクセス申請は実務でよく使われ、プロセス全体の品質は IGA プラットフォームの効率的な日常運用に不可欠であるため、ソリューションのこの部分の概念実証に十分なリソースを投資することを強く推奨します。

アクセス申請プロセスの大多数は ロール 割り当て申請を扱います。理論上は、LDAP グループやオペレーティングシステム権限などの低レベル entitlement に対してアクセス申請プロセスを実装することも可能です。しかしそのようなプロセスは非常に problematic になりがちです。アクセス申請プロセスは policy や ownership などのガバナンス概念に基づきます。 IGA プラットフォームの外部に存在する entity に対して、そのような概念を定義するのは非常に困難です。エンタイトルメントはしばしば対象システムに "live" します。 IGA プラットフォームはそれらについて何らかのデータを維持しますが、通常 IGA プラットフォームの第一級の対象ではありません。そのような申請の承認者を IGA プラットフォームが判断することは困難です。したがって IGA プラットフォームが entitlement に対するアクセス申請を直接サポートする機能は、ほぼ常に非常に limited です。多くの IGA プラットフォームは、entitlement に対応する ロール を自動的に維持することでこの状況を overcome します。たとえば LDAP グループを IGA プラットフォームに自動的に同期し、LDAP グループごとに application role を作成できます。そのようなアプリケーションロールは、ポリシーの指定や ownership tracking を含む ordinary アクセス申請プロセスの subject になれます。

アクセス申請 プロセスの基本考え方は、アクセス とは何かを define できるという考え方に基づいています。これはロールベースのアクセス制御 (RBAC) のような構造化されたアクセス制御モデルでは比較的 easy です。 RBAC では、ロールはアクセスを付与する明確に定義された概念であり、アクセス申請プロセスの自然な対象です。しかし構造が弱いアクセス制御モデルは、アクセス申請プロセスにあまり適していません。たとえば attribute-based アクセス制御 (ABAC) には アクセス を define するために使える概念がありません。 ABAC ではアクセスは多くの variable に基づくため、そのうちどれが アクセス を決定し、どの variable 組み合わせが申請するに足る意味のあるなものなのかを specify することはほぼ不可能です。実務上、ABAC モデルのアクセスは通常ユーザーアカウントの属性によって判断d されます。したがって ABAC アクセス申請プロセスは、ユーザーアクセス属性の価値、通常形式的に規定されていない価値を扱う必要があります。この方法を declarative 形式で実装するのは非常に困難です。 ABAC に基づくシステムのアクセス申請プロセスを構成と維持することは不可能ではありませんが、RBAC システムの equivalent プロセスよりはるかに困難です。 ABAC-based システムを管理する多くの実践的なソリューションは、ロール 概念、または ロール と機能的に同等な機構を再導入しています。

アクセス申請 機能は identity ワークフロー automation 機能と大きな overlap があります。これは部分的には historical reason によるもので、従来のly アクセス申請 プロセスの承認部分は一般的な workflow ツールによって実装されていました。

近年、機械学習と人工知能 (AI) に基づく承認プロセス自動化の概念が登場しました。 AI は確かにアイデンティティガバナンスにおける居場所を持っていますが、承認プロセスの自動化に AI を使うことは極めて危険になり得ます。承認プロセスを自動化するために使われる "人工知能" は機械学習機構に依存し、それはさらに良い訓練データまたはフィードバックに依存します。ロール、ポリシー、組織上のプロセスの構成は組織ごとに異なるため、AI ベースの承認はベンダーや他組織が生成した訓練データに依存できません。 "承認 AI" は、自分の組織で作られたデータと判断によって trained される必要があります。 "承認 AI" が生成する提案は、あなたが作るデータと判断と同じくらい良くしかなりません。コンピューターサイエンスの古い言葉どおり、garbage in, garbage out です。しかし承認者の判断はどれほど良いでしょうか。通常、人間の誤りを排除するために承認者レベル/段階は複数あります。さらに誤りを排除し、その結果に対処するために見直し、認定キャンペーン、インシデント調査があります。実際には完全情報セキュリティプログラムがあり、アイデンティティガバナンスはその小さな一部にすぎません。承認プロセスの誤りは、発生から years 後に特定されることがよくあります。機械を訓練するためのデータ品質には疑問があり、フィードバック loop は長すぎます。

これは AI 判断への可視性がほぼないことによってさらに増幅されます。 AI がなぜそのように判断したのかを explain する方法は、事実上ありません。これは説明責任への重大な障害です。

AI-assisted 承認はそれでも useful ツールになり得ますが、非常に careful に使わなければなりません。たとえば AI を使って複数レベルの承認をなくすしつつ、chain には少なくとも1人の人間の承認者を残すのは、おそらく良い考え方です。 "AI" がどのように実装されるかはベンダーごとに確実に異なり、実装品質も大きく異なる可能性が非常に高いです。実装品質を確認する方法がないままベンダーの chèque en blanc を accept し、blindly 信じるのは極めて危険です。アクセス認定プロセスは、危険な権限蓄積と abuse の間にある唯一の実際の障壁であることがよくあります。この barrier を paper-thin にしていないことを確認してください。

AI は正しく使えばアイデンティティガバナンスにおける非常に有用なツールです。 AI はロールマイニング、big データ内のパターンの発見、新しいロール定義の提案に非常に useful です。 AI-assisted 相関付けは、haystack の中の needle を探し、最も likely な candidate を提案することで、多くの時間を節約できます。しかしそのすべてのケースで、AI は提案を提供するだけで、final 判断は人間が下さなければなりません。それが AI の正しい使い方です。自分の kingdom のすべての鍵を machine に渡してはいけません。

アクセス申請 と アクセス認定 の自動化を AI に頼るよりも、proper ロールとエンタイトルメントエンジニアing に労力を向けるべきです。より良いロールとエンタイトルメント、およびそれらの自動化された割り当て/割り当て解除ルールは、アクセス申請 と アクセス認定 プロセスの両方を劇的に減らし、同時に透明性を高めることができます。機械学習は、ロールマイニングを使って良いロール定義を提案するなど、ロールエンジニアリングを改善するために使う方が適しています。