IGA 機能: アイデンティティワークフロー自動化

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

別名

ワークフロー

アイデンティティワークフロー管理

是正

アイデンティティワークフロー自動化機能

ポリシー違反の是正。ポリシー違反を remedy し、システムを完全なポリシーコンプライアンスの状態に戻すために取られる対応。この対応はポリシー違反の検知を受けて続行されます。是正対応は、人間のユーザーが行う手作業対応であることがよくあります。

ケース管理。通常は unstructured な形で、解決が必要な問題を指定する case の記録を保持すること。ケースは通常、ポリシー違反、ロール定義問題、高リスク状況などを記録するために使われます。ケースは多くの場合、その問題を解決するために使える pre-defined アルゴリズムやワークフローパターンがないことを前提にしています。ソリューションは、case 上で協力し communication するユーザーによって提供されます。

プロセス管理。特定の問題を構造化されたな方法で解決することを目的として、process を追跡すること。プロセスは通常、人間のやり取り、つまりワークフローに基づきます。この方法は、問題 resolution につながる特定ユーザーのやり取りの構造化されたで pre-defined なパターンが存在することを前提にします。

エスカレーション。 Original assignee が指定時間内に対応を取らなかった場合に、ケースまたはプロセス手順を新しい assignee に re-assign する能力。エスカレーションは、通常の time-frame 内に解決されない課題にマネージャーや leader の注意を向けるためによく使われます。

通知。特定の対応が発生したことをユーザーに知らせる能力。新しいアカウントやエンタイトルメントについてユーザーに知らせるメールメッセージが、おそらく最も一般的な形式です。ただし通知はさまざまな方法で実装できます。

概要

アイデンティティ管理は自動化を目指しますが、アイデンティティ管理とガバナンスには依然として人間が行わなければならない作業があります。それらは通常、自動的に判断できないもの、アルゴリズムによる説明を持たない作業、または作業の進行状況をユーザーに知らせる単純な通知です。

アイデンティティ管理の多くのプロセスは自動化できます。そして実際、自動化はアイデンティティ管理とガバナンスの主要なツールの1つです。しかし、その性質上、簡単には自動化できないケースがいくつかあります。そのような作業のほとんどは、何かがうまくいかず、自動対応では修正できない状況を扱うためのものです。

ポリシー違反の是正は、手作業ワークフローの最も一般的なケースかもしれません。組織のすべてのプロジェクトには少なくとも1人のマネージャーがいなければならない、というポリシーがあるとします。これは非常に自然なポリシーであり、プロジェクトとそれに関連するすべてのリソースに責任を持つ人物が常に存在することを要求します。しかしプロジェクトマネージャーが会社を退職したとき、IGA プラットフォームは何をすべきでしょうか。プロジェクトマネージャーのアイデンティティを削除または archive する操作は、マネージャーのいないプロジェクトを生むためポリシー違反を引き起こします。しかし IGA プラットフォームはその操作を止めることができず、アイデンティティの削除を拒否することもできません。 IGA プラットフォームは操作を postpone することさえできません。その人物のすべてのアクセスを直ちに無効化する正当な理由があるかもしれないからです。それでも操作を実行すると、システムはポリシー違反の状態に残されます。

この例は、アイデンティティガバナンスにおける比較的一般的な問題、つまりポリシーの strict 強制では解決できない問題を示しています。通常のソリューションは、ポリシーに違反する操作を進め、ポリシー違反が存在する事実を受け入れ、システムをポリシーコンプライアンスの状態に戻すために remediation 対応を開始することです。多くの是正対応は、人間が行う必要のある手作業対応です。上記のプロジェクトマネージャー不在のケースでは、人間が新しいマネージャーをプロジェクトに nominate するか、プロジェクトを close するかを判断しなければなりません。アイデンティティガバナンスには、人間のやり取りを必要とする作業が多数あります。たとえば次のようなものです。

ポリシー違反を re仲介する、

missing ロール定義を追加する、

既存ロール定義を改善する、

危険な権限蓄積を解決する、

高リスク状況に対処する、

redundancy、たとえばほぼ duplicate なロールを排除する。

実際の対応は人間が行わなければならないとしても、IGA システムには作業の progress を監視し、participant に作業が必要であることを remind し、作業をレポートし、同様のサポートと管理機能を提供する責任があります。これは identity ワークフロー automation として知られています。

IGA プラットフォームは通常、ワークフロー自動化に2つの方法を使います。

プロセスベースの方法は、事前定義された手順の並びを使います。プロセスは、何をすべきか、誰が行うべきか、どの sequence で、どの condition の下で行うべきかを定義します。本質的には、人間のやり取りで構成されるアルゴリズムです。プロセスの管理には通常汎用ワークフローエンジンが使われ、BPMN などの業務プロセス定義言語がそのプロセスの仕様化に使われます。

ケースベースの方法は、作業を完了するために unstructured または semi-structured な協力に依存します。 Case は ITSM システムで使われるトラブルチケットに似ています。解決すべき問題を記述しますが、それを解決するための predefined 手順は指定しません。ケースに割り当てられた人物または人物が、ケースを解決するための具体的な手順や操作を見つけなければなりません。ケースは最初、単純ルールに基づいて特定の人物またはグループに割り当てられます。しかし、その初期 assignee がケースを完了できるとは想定されていません。ケースはしばしば別の人物に re-assign され、複数の人物がケースの解決に協力し、comment ややり取りを重ねて、ケースに記述された問題が解決されます。ケースに関する作業と情報の大半は unstructured ですが、ケースにはほぼ常に progress を示す構造化されたな status、たとえば open、on hold、resolved、closed などがあります。

従来、IGA プラットフォームは、あらゆる状況を formalize でき、解決のためのアルゴリズムを指定できるという期待のもと、プロセスベースの方法に依存していました。これは形式的には正しいかもしれませんが、具体的なアルゴリズムは IGA プラットフォーム導入時点ではめったに知られていません。実際には、特定のケースごとに少しずつ異なる可能性があるため、そもそも知られていないことがほとんどです。したがって多くの実践的な IGA 導入は、組織の鍵人物が持つ暗黙知に依存してケースを解決するケースベースの方法を利用する傾向があります。プロセスベースの方法は、オンボーディングやオフボーディングプロセスなど、いくつかの特殊な目的に使われます。

進捗監視やエスカレーション機能など、一部の機能は両方の方法に共通です。エスカレーションは通常、問題が解決されない、またはプロセスの手順が指定された時間間隔までに完了しない場合に自動的にトリガーされます。作業はマネージャーにエスカレーションされることが多いため、エスカレーションは組織構造管理に依存することがよくあります。

通知機能もワークフロー自動化機能の一部と見なされます。通知の目的は、対応が発生したことをユーザーに知らせることです。通知の最も一般的な形式は、新しいアカウントが作成された、または新しいエンタイトルメントが割り当てられたことをユーザーに知らせる informational メールメッセージでしょう。しかし通知には多くの形式があります。メールメッセージ、モバイルテキストメッセージ、アプリ内通知、chat メッセージなどです。通知はしばしば専用メッセージを含み、複数言語 version を必要とすることもよくあります。

アイデンティティワークフロー自動化機能は、IGA プラットフォームの他の部分では解決できないすべての問題を解決するための "catch all" ツールであることがよくあります。しかし IGA の主な目的は、人間中心のワークフローの自動化だけではなく、管理とポリシー処理の自動化であるべきです。ロール定義、機械処理可能なポリシー、ルールなどのポリシー概念の形式化は、成功する IGA 導入に必要です。ワークフロー自動化は、computer が自動的に実行できない手順にのみ使うべきです。

ワークフロー自動化は、IGA ソリューションの長期維持管理という別の challenge ももたらします。自動化されたワークフロープロセスは、特にプロセスベースの方法が使われる場合、驚くほど多くのカスタマイズを必要とします。プロセスはモデル化され、高レベルプログラミング言語を使ってアルゴリズムの形で表現される必要があります。組織が変わるとプロセスも変わる傾向があり、コードの継続的な維持管理が必要になります。理論上はプロセスを non-IT の業務部門の担当者が作成し維持管理できますが、現実は異なることがよくあります。 IGA プロセスは通常、アイデンティティ管理概念、データ構造、実装詳細の負担を受けます。プロセスの作成と維持管理には、ほぼ常にアイデンティティ管理とガバナンスの expert skill が必要であり、IGA ソリューション操作の非常に高価な部分になります。さらに、heavy カスタマイズは通常、システム upgrade の大きな障害です。これは汎用ワークフローエンジンに大きく依存する IGA プラットフォームでは特に危険です。そのようなシステムの upgrade では、通常すべてのカスタマイズを完全に再実装する必要があります。 Case-based システムは通常、維持管理と upgrade がはるかに容易です。

用語に関する注記

Industry で確立された用語と taxonomy に関しては、identity ワークフロー automation 機能の scope について大きな曖昧さがあります。一部の author は、アクセス申請承認プロセスや手作業フルフィルメントプロセスを含む、ほぼすべての人間によるやり取りをワークフロー自動化に含める傾向があります。厳密に言えば承認と手作業フルフィルメント手順はどちらも "ワークフロー" ですが、その目的と構造は他の手作業手順とは大きく異なります。承認と手作業フルフィルメントは非常に構造化されたなプロセスであり、ほぼ常にアルゴリズムによるであり、アイデンティティリソース、policy、ロール の構造に関するかなりの知識を必要とします。そのため多くの IGA プラットフォームは、そのようなプロセスのために専用の実装を持っています。さらに、そのようなプロセスには非常に特定のな業務目的があり、それぞれ アクセス申請 機能と fulfillment 機能の目的に対応します。したがって、アクセス申請承認と手作業フルフィルメントは identity ワークフロー automation 機能の一部とは考えません。それにもかかわらず、他の機能、特に アクセス申請、fulfillment、certification との実装 overlap はあり得ます。 IGA プラットフォームがケースの管理、comment や類似やり取り、エスカレーションなどに同じ機構を使う可能性は高いです。

ワークフローエンジンに関する注記

アイデンティティワークフロー自動化は、汎用エンタープライズワークフロー自動化のために開発された手法と技術に依存することがよくあります。多くの IGA プラットフォームは、BPMN のような汎用 high-level 業務プロセス言語でプログラム可能な組み込みワークフローエンジンさえ含んでいます。そのような embedded ワークフローエンジンは通常、アクセス申請、ロール、エンタイトルメント、アカウント、アイデンティティ属性など、アイデンティティ関連概念をサポートするために大きくカスタマイズされています。そのようなワークフローに参加するユーザーは、IGA プラットフォームとその専用のユーザーインターフェイスを使ってワークフローエンジンとやり取りすることが想定されています。

このような方法は、自前のエンタープライズワークフロー自動化プラットフォームをまだ導入しておらず、そのようなプラットフォームの導入も予定していない小規模組織では意味があります。すでにワークフロー自動化プラットフォームを使っている組織では、IGA ワークフローを既存プラットフォームに統合する方がはるかに理にかなっています。残念ながら、既存 IGA プラットフォームにおけるそのような統合可能性は現在かなり限られています。

IGA-embedded ワークフローエンジン方法は、初期費用効率への強い pressure がある導入でも意味があります。しかし、そのようなソリューションの維持管理は長期では非常に高価になる可能性があります。特に embedded ワークフローエンジンに大きく依存するソリューションや、heavy カスタマイズを持つソリューションではそうです。