Skip to content

IGA 機能: アクセス認定

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

別名

  • 再認定
  • 証明

アクセス認定機能

  • 完全な認定キャンペーン。 大規模に実施する認定。 大きなユーザーグループのアクセスを認定し、通常は多くの認定者に分散して実施されます。 キャンペーンは多くの場合、定期的に実行され、期間が限定されています。
  • マイクロ認定。 非常に小規模に実施する認定。 通常は1人のユーザーのアクセスを、1人または数人の認定者が認定します。 マイクロ認定は通常、組織変更などのアイデンティティライフサイクルイベントや、リスク状況の変化によって開始されます。
  • ロール定義の認定。 含まれるロール、エンタイトルメントなど、ロールを構成する要素の認定。

概要

アクセス権限は増え、蓄積していく傾向があります。 権限を効率よく付与する方法は多数あります。正式な アクセス申請 プロセス、システム管理者による手動付与、さまざまな非公式の抜け道などです。 しかし、権限の蓄積はリスクです。人はしばしば、一度得た権限を永久に保持し続けるからです。 アクセス認定は、もはや必要でない権限を取り除くためのプロセスです。 アクセス認定プロセスでは、責任者が、ユーザーに付与された権限が今も必要であることを 確認 しなければなりません。

認定は、アドホックなロール割り当てに対抗するために設計されたプロセスです。 ロールが正式な アクセス申請 プロセスで割り当てられた場合でも、統制されていないプロセスで手動割り当てられた場合でも、最終的には認定が必要です。 そうしなければロール割り当ての数は制御不能に増え、ロール割り当ての増加に伴って全体のリスクも増大します。 認定は、アドホックなロール割り当てがもたらすリスクを抑制できる、ほぼ唯一の実用的な機構です。

ただし、典型的な組織、特に状況が頻繁に変わる動的なエンタープライズ環境では、アドホックなロール割り当てが大量に存在します。 そのため、認定プロセスは大量の判断を非常に効率よく処理できるように設計されていなければなりません。 承認プロセスを単に再実行しても機能しません。 承認件数が多すぎ、dialog も多すぎ、click も多すぎます。 そのため認定のユーザーインターフェイスは、大量の判断を非常に素早く行う目的に合わせて、通常は1つのユーザーインターフェイス dialog で処理できるよう設計されます。

認定判断は、ほぼ常に業務マネージャーが行います。通常は、アクセスが認定されるユーザーの直接マネージャーです。 直接マネージャーは通常、そのユーザーの職務について最もよく把握しており、ユーザーがもはや必要としていないロールを見つけられる可能性も高くなります。 この方法には、認定労力を多くの認定者に分散し、認定完了に必要な総時間を短縮する効果もあります。

認定には通常、2つの種類があります。

  • 認定キャンペーン は、大きなユーザーグループが持つすべてのロール、またはその他の "アクセス" の認定を目的とします。 これは、多くの認定者が比較的短い期間に多数の判断を下す必要がある「mass」対応です。 ユーザーは通常、組織構造に従ってグループに分けられます。 認定作業は多くの認定者、通常は組織上の単位のマネージャーに分散されます。 キャンペーンには固定の期間があり、通常は数週間単位です。 キャンペーンは通常、年次などの規則的 schedule に基づいて繰り返されます。
  • マイクロ認定 は、triggered certification または アドホック certification とも呼ばれます。 これは通常、1人のユーザーに付与されたアクセスのロール割り当てを、1人の認定者が認定するものです。 マイクロ認定は、ユーザーの組織上の割り当ての変更など、アイデンティティライフサイクルにおける重要なイベントによって開始されることがよくあります。 その場合、新しいマネージャーはユーザーの行動に対して何らかの責任を引き受けるため、そのユーザーのロール割り当てを認定しなければなりません。 マイクロ認定は、ユーザーのエンタイトルメントの全体リスクが指定された threshold を超えた場合、ユーザーが 外れ値 として検出された場合、またはロール割り当ての状態を把握するための完全な random selection など、他のイベントによって開始されることもあります。

認定キャンペーンは、権限蓄積 問題に対処できる可能性が高い、体系的で広範なソリューションです。 しかし、認定キャンペーンを適切に使うのはかなり難しいことです。 認定キャンペーンでは、多数の人が多数の判断を下す必要があり、全体として非常に大きな労力になります。 過去の一般的な推奨では、完全な認定キャンペーンを年1回、あるいは年2回実施することが推奨されていました。 しかし、キャンペーンの頻度が高いほど、過剰なロール割り当てを検出できる可能性は低くなります。 認定キャンペーンが「退屈だが必要な paperwork」と見なされると、認定者は終わらせることだけを目的に、深く考えずにすべてを確認しがちです。 そのため、頻繁な大規模認定キャンペーンは、完全に役に立たない結果を生むことがあります。

現在の認定推奨は、頻繁な認定キャンペーンではなく、マイクロ認定の賢い活用を重視しています。 1人のユーザーに対するマイクロ認定は、組織上の割り当ての変更など、重要なライフサイクルイベントによって開始されるべきです。 さらに重要なのは、認定をリスクベースにすることです。より高いリスクを持つユーザー、または通常とは異なるアクセス権限の組み合わせを持つユーザー、すなわち 外れ値 を対象に、マイクロ認定または小規模な認定キャンペーンを開始します。 小規模認定を賢く使っても、完全な認定キャンペーンの必要性がなくなるわけではありません。 しかし、コストが高く痛みの大きいキャンペーンの頻度を大幅に減らすことができます。

ロール構造は認定労力に大きく影響します。 優れたロールエンジニアリング により、再利用性の高い、よく定義されたビジネスロールが得られます。 これは、典型的なユーザーが少数のビジネスロールだけを持ち、それらを比較的容易に認定できることを意味します。 一方、poor ロールエンジニアリング では、大量のアプリケーションロールがユーザーへ直接割り当てられます。 これは、典型的なユーザーが数十、あるいは数百のロールを持つことを意味します。 結果として認定労力は膨大になり、認定結果の品質は非常に低くなります。 このような状況では、アクセス申請 プロセスが過剰に使われ、ビジネスロールの エンジニアing と維持管理が軽視され、ユーザーが同僚と同じロール集合を繰り返し申請するようになることがよくあります。 この方法は必然的に、保守不能で、したがって安全でないシステムにつながります。

優れたロールエンジニアリング とマイクロ認定の賢い活用があっても、認定は常に時間がかかり、ある程度苦痛を伴う活動です。結果には疑問が残ることもあり、品質制御も非常に困難です。 アクセス申請 プロセスと同様に、certification は、ほぼすべての包括的な IGA 導入に必要な構成要素です。 しかし、この両方は必要最小限に抑えることが非常に望ましいです。 ロール、エンタイトルメント、権限の割り当て、そして unassignment が自動化されるほど、アクセス申請certification に必要な労力は少なくなります。 誤りの余地も少なくなり、可視性は高まり、残余リスクも低下します。 したがって、IGA 導入の主要な目的は、実用上可能な限りロール割り当てを自動化することに置くべきです。

多くのアクセス認定活動は、ユーザー・ロール 割り当ての認定に関するものです。 しかし認定機構は、ロール定義などポリシーの他の部分を認定するためにも使用できます。

アクセス認定 の究極の目的は、資産へのユーザーアクセスを可能な限り細く保つことです。 アクセス認定は、システムを least privilege の原則が示す理想状態へ近づけるための機構です。 IGA システムには、ユーザーアクセスを広げる方向に働く機構が多数あります。 アクセス認定は、その反対方向に働き、ユーザーアクセスを薄くする数少ないツールの1つです。 そのためアクセス認定は、IGA ツールボックスにおける貴重なツールです。 アクセス申請や類似プロセスが使われる場合、アクセス認定は必須のツールです。 アクセス認定は不可欠なツールである一方、使いこなすのは比較的困難です。 適切に使わなければ、大量の無駄な労力を生み、具体的な成果を何も得られないことがあります。 他の多くの IGA ツールと同様に、賢く使わなければなりません。

注記

アクセス認定は、ロールベースのアクセス制御 (RBAC) 原則に基づくシステムなど、ロールベースのシステムでほぼ常に使用されます。 ロールは、アクセス申請アクセス認定 機構の両方で使う自然な概念です。 理論上は、アクセス認定は attribute-based アクセス制御 (ABAC) システムなど、ロールに基づかないシステムでも使用できます。 しかし、そのようなシステムには通常「アクセス」が何を意味するかについての形式的概念がないため、アクセス認定キャンペーンの定義と管理ははるかに難しくなります。 ABAC システムにおけるアクセス認定は、通常ユーザー属性価値の認定を意味します。 この方法は可能ですが、通常は非常に労力集約的で、実現可能なことはまれです。

近年の動向は、機械学習、しばしば「人工知能」(AI) として提示されるものを使って認定労力を削減することです。 機械学習 は認定労力を削減できますが、結果の品質を維持するには細心の注意が必要です。 認定が手動プロセスとして設計されているのには、正当な理由があります。 認定判断は、システムをリスクにさらしたかもしれない他の人間の判断に対抗するため、人間が下さなければなりません。 機械学習 の問題は、結果の品質がシステムの training に使われたデータの品質に依存することです。 組織ごとに異なるため、ロール、ポリシー、実務も異なる傾向があります。 そのため、他のシステムから得た既製の 訓練データで 機械を訓練 することはできず、その目的には自組織が生成したデータだけを使えます。 認定者の判断が良くない、たとえばほぼ常にすべてを確認している場合、AI も同じように悪い判断を下します。 これは、何年にもわたり見えないところに隠れる、発見困難な問題につながる可能性があります。 アクセス認定は 危険な権限蓄積 から守る唯一の機構であることが多いため、これは極めて危険です。

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