IGA はアカウント同期だけではない
この記事は https://docs.evolveum.com/iam/myths/iga-means-accounts/ の翻訳です。
アイデンティティガバナンスおよび管理（IGA）システムは、すべてアカウントの同期のためのものです。 HR データベースからデータを取り込み、それを Active Directory といくつかのアプリケーションへ同期します。 だいたいそれだけです。 IGA システムは、実際には見栄えのよいデータ同期エンジンにすぎません。
これは2000年代初期には当てはまったかもしれません。 過去20年間進化していない製品については、今でもかなりよい説明かもしれません。 しかし、最先端の IGA プラットフォームについて言えば、これは真実から大きくかけ離れています。
同期
完全に明確にしておくと、アカウントライフサイクル管理と属性同期は、今でもすべての IGA プラットフォームの基本機能です。 それは当然です。作業するには「信頼でき、きれいで、一貫したデータ」が必要だからです。 同期は今も存在し、今も必要です。ただし、IGA プラットフォームの最も重要な責任ではなくなったというだけです。 IGA プラットフォームは単なる同期よりもはるかに多くのことを行うため、同期はもはや主役ではありません。
入社者・異動者・退職者
伝統的な考え方では、IGA プラットフォームは主に 入社者・異動者・退職者（JML）プロセスに焦点を当てているとされます。 実際、IGA 導入の最初のステップは通常、JML プロセス自動化です。 しかし、それは IGA 導入プロジェクトのごく始まりであり、長期的なアイデンティティガバナンス プログラム については言うまでもありません。 JML プロセスは伝統的な最初の一歩ではありますが、IGA 状況の中では比較的小さな部分です。 実際、最先端の IGA プラットフォームはプロセスそのものに焦点を当てているわけではなく、policy に焦点を当てています。 IGA プラットフォームは、複雑なライフサイクルの細部を扱い、考え得るすべてのライフサイクル状態と状態 transition を管理します。 もちろん、3つの基本的な transition（join, move, 退職）は今でも最も重要です。 しかし、それらだけではありません。 現実の状態モデルは、「JML」という考え方が示すよりもはるかに複雑です。 ユーザーは join する前に candidate として存在するかもしれません。move ではなく suspend されるかもしれません（産休、sabbatical）。退職後も retiree や alumnus として存在し続けるかもしれません。 さらに、アイデンティティ のライフサイクル状態だけではまったく十分ではありません。 アイデンティティには、ペルソナ、ownership、権限、組織単位やグループのメンバーシップなど、他のアイデンティティとの多数の 関係 があります。 これらも管理する必要があり、多くの場合、それら自体のライフサイクルを持っています。 アイデンティティ管理の現実は、見かけよりもはるかに複雑です。
ユーザーアカウント
IGA はもはや ユーザーアカウント だけのものではありません。 まず、管理すべき account には多くの種類があります。 アカウントの大半は、今でも従業員、請負業者、学生に属する通常の ユーザーアカウント です。 しかし、アプリケーション やその他の service が user の代わりに使う service accounts もあります。 これらは machine identities のような non-human identities に対応します。 最先端の IGA プラットフォームは、人間のアイデンティティと同じように non-human アイデンティティを管理するように作られています。 しかし、concept に対応する non-human アイデンティティも多数あります。 グループ、ロール、エンタイトルメント、アクセス権限は、そのようなアイデンティティの最も重要な例です。 さらに、組織単位、チーム、プロジェクト、業務パートナー、勤務地などの概念もあります。 IGA プラットフォームは、これらの概念を扱えなければなりません。なぜなら、それらはアクセス制御とポリシーに密接に関係しているからです。 優れた IGA プラットフォームは、単なるユーザーアカウントだけでなく、幅広いアイデンティティ種類を管理できなければなりません。
アクセス制御
IGA プラットフォームの主要な責任の1つは アクセス制御 です。 しかし、これは言うほど簡単ではありません。 アクセス制御には多くの形態があります。 アクセス制御ポリシー を表現するために使われる、競合するアクセス制御モデルが数多くあります。 実際、IGA システムが管理するために作られているのは policy です。 IGA プラットフォームは事実上、アクセス制御ポリシーを作成し管理するために使われるシステム、つまりポリシー管理 点（PAP）として機能します。 その後、IGA プラットフォームはポリシーと関連データを他の構成要素（PRP, PDP, PIP）へ provisions します。
したがって、グループやロールなどのエンタイトルメントの同期は、IGA プラットフォームの最も有用な機能の1つです。 エンタイトルメントはアクセス制御の生命線です。 しかし、各アプリケーションは独自のエンタイトルメント集合を扱います。権限、権限、グループ、ロール、その他アクセス制御 ZOO にいる多種多様な存在です。 IGA プラットフォームはそれらを整列させ、統合されたアクセス制御ポリシーへ組み合わせます。 アクセス制御の世界が多様であることを考えると、これは決して簡単な仕事ではありません。
普通の ポリシーは簡単ではない も難しいですが、組織全体で統一されたポリシーはさらに困難です。 静的なロールベースのアクセス制御（RBAC）モデルは非常に一般的であると同時に、非常に時代遅れです。 しかし、最先端の IGA システムは policy-based 機能を備えた 動的 RBAC モデルを提供しています。 たとえば midPoint は policy-driven RBAC 機構を提供しています。
アイデンティティガバナンス
アクセス制御ポリシーはアイデンティティ administration の中心にあります。 では、アイデンティティ governance はどうでしょうか。
アイデンティティ governance はすべてポリシーに関するものです。 しかし、ガバナンスポリシーはアクセス制御ポリシーとはかなり異なります。 アクセス制御ポリシーが「誰が何にアクセスできるか」を指定するのに対し、ガバナンスポリシーは「誰が何に責任を持つか」を指定します。 これらは高レベルでビジネス指向のポリシーです。 大規模なサイバーセキュリティガバナンスを維持するうえで重要です。
ガバナンスポリシーは多くの形を取り得ます。 Segregation of Duty（SoD）ポリシーのように、アクセス制御との境界上にあるガバナンスポリシーもあります。 ガバナンスポリシーは、各アプリケーションに 所有者がいること、各エンタイトルメントとアプリケーションロールに 所有者がいること、重要なロールが適切に担当されていること、ロール定義が定期的にレビューされること、リスクホットスポットが対処されること、アプリケーションが適切に分類されること、クリアランス がレビューされること、ユーザー意識 が定期的に更新されること、などを要求する場合があります。 多くのガバナンスポリシーは ownership に焦点を当てています。ownership は責任の基盤だからです。 ガバナンスポリシーは技術を考慮しますが、しっかりとビジネス側を向いています。 これらは アイデンティティベースサイバーセキュリティコンプライアンス に最適なツールです。
ガバナンスポリシーは IGA の「G」です。 アイデンティティガバナンスポリシーの実装なしに、完全な IGA プラットフォームはあり得ません。