アイデンティティガバナンスとは何か

この記事は https://docs.evolveum.com/iam/iga/what-is-identity-governance/ の翻訳です。

はじめに

アイデンティティの管理は、かなり難しい取り組みです。 同期、コネクター、属性マッピングなど、多くの技術的な側面があります。 この技術的な部分は、通常 アイデンティティ管理 (IDM) と呼ばれます。 しかしアイデンティティの管理は、技術だけの話ではありません。 そこには業務プロセス、ルール、ポリシーもあります。 新しい従業員には一部の権限を自動的に付与したい一方で、別の権限は アドホック に割り当てたいことがあります。 ただし、どのユーザーにも無条件に権限を与えたいわけではありません。 そのため、管理を効かせるために承認プロセスを設定したくなります。 また、割り当てと承認を追跡し、判断した人に説明責任と責任を持たせる必要があります。 マネージャーが、従業員が今も保持している権限を必要としているかどうかを判断する再認定キャンペーンを設定したい場合もあります。 まもなく施行される新しいポリシーや規制に対して、自分たちのシステムがどの程度準拠なのかを評価する必要もあります。 判断を下す人と、その判断を監査・確認する人が同一人物になることを禁止したい場合もあります。 これらは技術よりも業務にずっと近い領域です。 そして、このソリューションの部分を アイデンティティガバナンス と呼びます。

アイデンティティ管理の完全なソリューションには、大きく2つの部分があります。

	Abstraction レベル	Major 懸念	価値 proposition	Primary ユーザー
アイデンティティ管理	Low 技術 (IT) に近い	データ同期、システム統合、データ形式、データ変換、ネットワークプロトコル	IT プロセスの高速化、自動化、IT 費用の削減、call center 効率化	IT 管理者
アイデンティティガバナンス	高 業務に近い	業務プロセス、業務ルール、ポリシー、組織構造	規制コンプライアンス、情報セキュリティ、効率的な組織管理	マネージャー、セキュリティ担当者、監査人

アイデンティティ管理とアイデンティティガバナンスは、一見すると大きく異なるように見えます。 実際、多くの違いがあります。 しかしソリューションの両方の部分は、非常に密接に連携しなければなりません。 一見明らかではないかもしれませんが、この2つには大きな重なりがあります。 どちらも、アイデンティティとは何か、権限とは何か、ロールとは何か、といった同じ概念に基づいています。 実のところ、この2つの間に明確な境界はありません。 たとえばロールベースのアクセス制御 (RBAC) は、アイデンティティ管理とアイデンティティガバナンスの両方に不可欠な部分と見なされます。

私たちはアイデンティティガバナンスを、低レベルのアイデンティティ管理の自然な拡張だと考えています。 片方だけではうまく機能しません。 そのため midPoint は、強力なアイデンティティ管理システムであると同時にアイデンティティガバナンスシステムでもあるように設計・実装されています。 この方法において、midPoint はかなり独自です。 競合ソリューションの多くは、IDM 用の製品とガバナンス用の製品という2つの異なる製品を持っています。 それらの製品は、しばしばまったく異なる環境から生まれ、異なる技術を使い、買収の連続によって後から組み合わされました。 こうしたソリューションの統合は、IDM とガバナンスの概念に大きな重なりがあることを考えると、しばしば非常に問題になります。 しかし midPoint はそうではありません。 midPoint は、共通のデータモデルを使って IDM とガバナンスの機能を組み合わせる、単一の包括的なアーキテクチャ design を持つ滑らかな製品です。 この方法は導入を大きく単純化します。 しかし、それ以上に重要なのは、ソリューションの長期的な維持管理に大きな違いをもたらすことです。

アイデンティティガバナンスと関連概念を指す用語は多数あります。 用語はまだ完全には定まっておらず、そのためかなり混乱しやすい状況です。 多くの人はこの分野を単に governance と呼びます。 Governance, リスク管理 と Compliance (GRC) は、この記事で説明する概念と技術の集合を指す古い用語です。 Industry analyst は、アイデンティティ管理とアイデンティティガバナンスの両方の機能を含めるために Identity ガバナンス と Administration (IGA) という用語を使う傾向があります。 私たちは、単に Identity Governance という用語を使うことにしました。 この文書でその用語を使う場合、アイデンティティガバナンスそのもの、アイデンティティベースリスク管理、コンプライアンス、そしてアイデンティティ管理をそれを取り巻く組織構造・業務構造と結び付ける関連概念と技術を意味します。

ロールベースのアクセス制御

ロールベースのアクセス制御 (RBAC) のロール構造は、アイデンティティガバナンスが構築される基本機構の1つです。 厳密には、RBAC がアイデンティティ管理の一部なのかアイデンティティガバナンスの一部なのかを言うのは困難です。両方で広く使われるためです。 ガバナンスの観点では、ロールは通常権限を表す主要なオブジェクトです。 そのためガバナンス機構の大半はロールを扱います。 ロールは、最小権限の原則や職務分掌など、いくつかの基本的な情報セキュリティ原則を実装するために使われます。

ガバナンスの観点から見ると、midPoint の RBAC 機構は多くの有用な機能を提供します。 もちろん midPoint のロールは階層を形成できます。 階層のレベル数に制限はありません。 アプリケーションロール、複数レベルのビジネスロールなどを作ることができます。 MidPoint は、より賢く expression-based なロール構造を形成するために使われる parametric ロールと メタロール もサポートしています。 これらのロールは式を使い、パラメーターに基づいて権限を動的に計算します。 したがって、1つの parametric ロールで多くの従来型ロールと同じ機能を提供できます。 このようなより賢い RBAC 構造は、管理と維持管理がずっと容易です。

組織構造

組織構造も、アイデンティティ管理とアイデンティティガバナンスの機構の間で広く共有される概念です。 組織構造は delegated 管理に不可欠です。 この場合、組織構造はアイデンティティ管理業務の一部を、組織内に分散した管理者に委任するために使われます。 しかし組織構造はそれ以上に強力です。 MidPoint には、組織上の単位のマネージャーを指定する標準の機能があります。 これは、functional 組織上の単位 (部門、節など) のマネージャー、プロジェクトマネージャーなどを定義するために使えます。 マネージャーは業務プロセスに参加できます。たとえば、自分の組織上の単位の member からのロール申請を承認できます。

MidPoint は、HR システムやその他のソースから組織構造を同期できます。 しかし、一貫した組織構造データのソースが存在しないことも非常によくあります。 そのため midPoint 自体を組織構造の信頼できるソースにすることもできます。 組織構造は midPoint で直接維持管理し、その後対象システムに同期できます。 MidPoint には、組織構造を手動で維持管理するためのユーザーインターフェイスがあります。 ただし現在のユーザーインターフェイスは IT 担当者向けです。 非技術スタッフ (たとえば HR スタッフ) が簡単に使えるユーザーインターフェイスの改善は、将来計画されています。

MidPoint 3.5 には、業務レベルでの組織構造管理をサポートする機能があります。 たとえば、組織上の単位が何人のマネージャーを持つべきかを指定するルールがあります。 そのため、特定の組織上の単位にマネージャーが少なすぎる、または多すぎる場合、midPoint は対応を取れます。 この機能は現時点 (midPoint 3.5、3.6) ではかなり限定的です。 しかし、この機能の改善は近い将来 (midPoint 3.7) に計画されています。 将来は、マネージャーがいない組織上の単位に新しいマネージャーを指定するために新しい業務プロセスを開始したり、複数のマネージャーが指定された場合に conflict を解決したりできるようになります。

ロールカタログ

ロールは、アイデンティティ管理とアイデンティティガバナンスの両方における基本概念の1つです。 ロールは、組織内の権限の分配をモデル化する複雑な階層を作るために使われます。 つまり、どの組織にも通常かなり多くのロールがあります。 従来型 RBAC 方法を使う場合、ロールの数がアイデンティティの数より多くなっても驚くことではありません。 MidPoint の parametric RBAC 機構を使えば、ロール数を大きく減らすことができます。 それでも中規模組織では、選択対象となるロールが数百個残ることがあります。 ロールをグループ、アプリケーション、カテゴリ に分類しなければ、ロールを見つけるのは困難です。

MidPoint にはロールカタログを作成する機構があります。 ロールは、ユーザーに提示する目的で、任意の階層構造に分類できます。 このロールカタログ階層は RBAC ロール階層から独立しているため、ユーザーにとって意味のある任意の方法でロールを提示できます。

MidPoint のロールカタログは、実際には組織構造として実装されています。 したがって、他の組織構造が持つ利点や賢い機能をすべて備えています。 たとえばロールカタログはアプリケーションに従って構成できます。 この場合、ロールカタログの各部分の管理をアプリケーション所有者 に自動的に委任できます。 各アプリケーション所有者 は、自分が所有するアプリケーションに限って、新しいロールの追加、ロールの変更、ロールの削除ができます。 MidPoint の細粒度の認可機構を使えば、この仕組みは容易に実装できます。

ロール申請と承認プロセス

ほぼすべてのアイデンティティソリューションにとって理想的な状態は、おそらく完全な自動化です。 組織構造や職務ロールに基づいて、すべてのロールを自動的に割り当てることは、ごく一般的な夢です。 MidPoint には、その夢を実現する能力があります。 しかし問題は 入力データとポリシー、より正確にはそれらの不在にあります。 実務上は、一部のロールを自動的に割り当てることは十分可能です。 たとえば中規模銀行では、窓口担当者、監督者、支店長のロールを自動的に割り当てることは通常実現可能です。 しかし、back office、broker などの「central」back 従業員になると話はまったく異なります。 多くの職務責任が1人に集約されることが多く、非常に動的な責任を持つ職位もあり、ロールを自動的に割り当てるアルゴリズムによるポリシーを見つけ出すことは、全体としてほぼ不可能です。

そのため、ほとんどすべての組織は、ロール割り当てに request-approval プロセスを使います。 ロールを必要とする従業員は、midPoint ユーザーインターフェイスを使ってロールを申請できます。 それによって承認プロセスが開始されます。 申請が承認されると、ロールが割り当てられ、権限が自動的に provision されます。

このプロセスの最初の手順はロール申請です。 ユーザーは申請したいロールを選択することになります。 しかし、数百のロールの中からロールを選ぶのは簡単ではありません。 MidPoint は、この作業を容易にするために実績ある ショッピングカート パラダイム を使います。 ユーザーには、電子商店のように見えるインターフェイスが提示されます。 ロールは e-shop の製品とよく似た形で表示されます。 ロールはロールカタログに基づいて カテゴリ に分類されます。 ユーザーは「shop」を閲覧し、ロールをショッピングカートに入れることができます。 選択が終わると申請を送信できます。

申請が送信されると、承認プロセスが開始されます。 通常は従業員の直接マネージャーが最初に申請を承認します。 その後、申請はアプリケーション所有者やセキュリティ担当者 に送られ、追加の承認を受けます。

MidPoint は非常に柔軟で、さまざまな 複数レベルの承認スキーム を設定できます。 承認スキーム 定義は完全にポリシーベース にできます (midPoint 3.6)。 つまり、承認スキーム は グローバルルールの集合、メタロール 内のルールによって設定でき、承認者は静的に (例: ユーザー Adam Andersen)、組織構造に基づいて (例: セキュリティオフィス部門の任意のメンバー)、または動的に (例: 申請ユーザーのマネージャー、ロールが属するアプリケーションの所有者 など) 定義できます。

MidPoint 3.6 では、エスカレーションスキーム を指定するための簡単な declarative 方法が導入されました。 承認者が指定時間内に判断しない場合、自動エスカレーションが発生します。 MidPoint では、承認スキーマの各手順における個別の承認ケースをどのようにエスカレーションするかを指定できます。 たとえば、最初の承認手順は functional 組織構造の1つ上のレベルにエスカレーションできます。 2つ目の承認手順は上級セキュリティスタッフにエスカレーションする、といった設定が可能です。

承認者が単に許可/拒否の判断をするだけでは不十分な場合があります。 場合によっては、承認者が追加データを提供しなければなりません。 もちろん、requestor と承認者の両方が free-form comment を提供できる場所があり、申請の rationale や追加詳細を記入できます。 しかし、欠落している構造化されたデータを埋める必要がある場合もあります。 これは多くの場合、ソースシステム (HR) では入手できず、手動で入力しなければならないユーザー プロパティ です。 ソースデータが最初に midPoint へ同期される時点で、すべてのユーザーについてそのデータを入力することは通常現実的ではありません。 作業量が多すぎ、初期導入に許容できない遅延をもたらすためです。 データは on the fly、つまり「必要になった時点」で提供される必要があります。 そのため midPoint 3.6 では、承認プロセスの中で承認者が欠落データを指定できる新機能が導入されました。 各承認手順には小さな形式を定義できます。 形式には、承認者が確認すべき重要なユーザーデータを含めることができ、欠落している場合はデータを入力できます。 この形式は、そのデータを本当に必要とするロールだけに指定できます。 したがって承認プロセスは、midPoint 導入におけるアイデンティティデータを段階的に改善・維持管理するために、非常に自然な方法で使えます。

監査データと割り当てメタデータ

良い管理には1つの原則があります。判断する人は、自分の判断に責任を持たなければなりません。 しかしそれが機能するためには、まずその判断が accountable でなければなりません。 つまり、誰が判断したのか、何について判断したのか、その判断が何だったのかが明確でなければなりません。 MidPoint にはこのための機構がいくつかあります。

監査証跡は、midPoint における説明責任のための最も強力な機構です。 MidPoint 環境でのすべての外部変更は監査ログに記録されます。 例外はありません。 ユーザー対応によって生じたすべての変更が記録されます。ロール割り当て、unassignment、ロール定義の変更、ポリシー変更、設定変更まで、すべてです。 自動同期ルールによって生じた変更も記録されます。 監査証跡は、変更の時刻、どこから来たのか (ユーザー操作、自動同期、API 操作)、誰が変更を行ったのか、何が変更されたのか、などを記録します。 承認対応も監査ログに記録されます。 重要な情報は逃れられません。 MidPoint には、監査ログを調査し、監査ログに保存された変更に基づいてオブジェクト履歴を再構築する組み込み機能があります。 これは一種の時間 machine であり、過去にオブジェクトがどのような状態だったか、たとえば特定ユーザーが2か月前にどのロールを持っていたかを調べるために使えます。 ただし、この機能は midPoint データベースに保存されている監査データの量に制限されます。 MidPoint はアイデンティティ管理とガバナンスシステムであり、データウェアハウス ではありません。 膨大な historical データを長期間保存するために作られているわけではありません。 むしろ、他の 専門的なデータ処理システムと統合するように設計されています。 監査証跡は、よく構造化され文書化されたデータベース表に記録されます。 この表は midPoint public インターフェイスの一部です。 SIEM、データウェアハウス、レポートエンジン、分析エンジンなど、他システムのデータソースとして使えます。

監査証跡は非常に強力な機構です。 しかし監査データは厳密に chronological です。 特定のロール割り当てを誰が申請し、誰が承認したのかという情報を得るのは、特にそれが数年前に起こり、その間に監査証跡がデータウェアハウス に移されていた場合、必ずしも容易ではありません。 そのため midPoint は、監査証跡に加えて assignment metadata も維持管理します。 メタデータには、各特定の割り当てについて requestor と承認者の識別子、timestamp、実際に変更を実行したプロセスの owner、その他の追加データが含まれます。 メタデータは割り当てと一緒に維持管理されるため、inspection のために簡単に利用できます。 監査ログデータが信頼できる情報源である一方、メタデータは情報をすばやく、非常に便利な形で得るための実用的な方法です。

代理

あるユーザーの権限の一部を、別のユーザーに一時的に 委任する必要がよくあります。 これは、ユーザーが休暇や長期出張に出て、自分の責任を十分に果たせない場合によく起こります。 この種の delegation は通常アドホックに発生するため、algorithmically に扱うのが非常に困難です。 そのため midPoint 3.5 には、この種の temporary アドホック delegation を可能にする特別な機能があります。ユーザーは自分の権限の subset を、自分の deputy に一時的に delegate できます。 MidPoint ユーザーインターフェイスには deputy を 委任するための特別な制御があります。

Deputy は、一時的な期間、権限の一部を「inherit」します。 これらの権限がユーザーのために新しいアカウントやエンタイトルメントを定義している場合、deputy のためにアカウントが作成されたり、エンタイトルメントが割り当てられたりします。 Deputy は、delegated 権限に対応する midPoint 管理インターフェイスの部分へアクセスできるようになります。 Deputy は delegating ユーザーの作業項目 (承認) にアクセスできるため、その責任を代行できます。 Delegation に設定された期間が切れると、それらの権限はすべて自動的に revoke されます。 Delegation のためだけに作成されたアカウントは無効化または削除され、追加エンタイトルメントは revoke されます。 状況は自動的に通常状態へ戻ります。

Deputy への delegation 能力は、midPoint の細粒度の認可機構によって制御されます。 したがって、すべてのユーザーが任意の権限を任意の deputy に 委任できるわけではありません。 この能力は、ユーザーの subset、deputy の subset、そして一部の選択済みロールに厳格に限定できます。

ペルソナとアイデンティティのリンク

Persona は、物理的な人物の異なる側面を表すためによく使われる用語です。 1人の物理的な人物が、異なる環境や責任のために複数の persona を持つことがあります。 たとえばユーザーは、従業員 HR 記録や Active Directory の通常アカウントなどで表される、通常の「従業員」ペルソナを持つことがあります。 これらは会社メールを読む、事務処理を行う、などのために使われるアカウントです。 さらに、そのユーザーは「管理者」ペルソナと、elevated 権限を持つ特別な Active Directory アカウントを持つことがあります。 このような特殊なアカウントは、特に Windows のように頻繁に使われ、相対的にセキュリティが低い環境では非常に望ましいものです。 Privileged 作業を実行するための特殊なアカウントを持つことで、人為的誤り、malware attack、その他の threat のリスクを減らせます。 さらにユーザーは、テスト アカウントや テスト 環境へのアクセスで表される別の「テスト」ペルソナを持つこともあります。 以下同様です。

多くの midPoint 導入は、midPoint がデフォルトで提供する単純なユーザー-account モデルで十分満足できます。 このモデルでは、組織内の各 物理ユーザーは、その 表現としてちょうど1つの midPoint ユーザーを持ちます。 ペルソナの概念が部分的に実装される場合でも、導入の大多数ではこれで十分です。 MidPoint にはアカウント intent を定義できる機構があります。 したがって、1人のユーザーが従業員アカウント、管理アカウント、テスト アカウントを持つことは十分可能です。

しかし、intent 機構では足りない場合があります。 MidPoint のデフォルトモデルでは、すべてのアカウントが1人のユーザーに linked されます。 そのためユーザーパスワードが変更されると、その変更はすべてのアカウントに 伝播 されます。 Partial propagation を使っても、すべての管理アカウントや テスト アカウントに異なるパスワードとパスワードポリシーを設定するのは簡単ではありません。 Default モデルには、すべての管理アカウントをまとめるものがありません。 したがって、より複雑な multi-layered 方法が必要になる場合があります。 その方法を可能にするのがアイデンティティリンク です。

アイデンティティリンク は midPoint 3.6 で導入された機構です。 アイデンティティリンク により、2つの midPoint ユーザーを link できます。 アイデンティティリンク は一般的な機構ですが、persona-based モデルを実装するためによく使われます。 その場合、アイデンティティリンク の一方は 物理 人物を表すユーザーです。 Link のもう一方は、特定ペルソナ (従業員、管理、テスト など) を表すユーザーです。 これらの「ペルソナ」ユーザーは、すべての実務操作で使われるユーザーです。 MidPoint への ログイン、パスワードリセット、ロール申請などに使われます。 この場合、アカウントは 物理 人物を表すユーザーではなく、ペルソナユーザーに linked されます。 これにより、アカウントはきれいに分離されます。従業員アカウントは従業員ペルソナに、管理アカウントは管理ペルソナに、といった具合です。 したがって、異なるパスワードを設定したり、異なるパスワードポリシーを設定したりすることが容易です。 Physical 人物を表すユーザーオブジェクトは、直接使われることはありません。 その目的は2つあります。 第一に、すべてのペルソナユーザーのためのデータ bridge として使われます。 HR アカウントが更新されると、更新されるのは 物理ユーザーオブジェクトです。 その後、更新がペルソナユーザーに 伝播 されます。 第二に、物理ユーザーとアイデンティティリンク は、オブジェクト ownership と責任の痕跡です。 MidPoint におけるすべての対応は、それに責任を持つ 物理 人物まで痕跡できる必要があります。 それこそがアイデンティティリンク の主目的です。

アクセス認定

Request-approval プロセスは、ユーザーにロールを追加するための非常に効率的な機構です。 特定システムへのアクセスが必要なユーザーがロールを申請し、プロセスを進めます。 しかし、この方法はロールの危険な累積につながることがあります。不要になったロールを手放す motivation がほとんどないためです。 そのため、余剰ロールを revoke するにはまったく異なる方法が必要です。 この目的でほぼ常に使われるプロセスは、アクセス認定、再認定、または証明と呼ばれます。

アクセス認定プロセスはキャンペーンとして機能します。 キャンペーンは、設定された criteria に従って作業を配布します。 最も一般的なシナリオは、作業をマネージャーに配布することです。 各マネージャーは、自分が 責任を持つ従業員のリスト を受け取ります。 List には従業員が申請したロールが含まれます。 マネージャーは、従業員がまだそのロールを必要としていることを 確認 しなければなりません。 ロールが確認されない場合、それは自動的に unassigned されることがあります。

この ブログ記事 も参照してください。

認定機構は、限られた時間内に多くの判断を行う必要があるケースに特に合わせて調整されています。 すべてがこの目的に適応されています。認定はキャンペーンとして実行され、認定者には多数のケースが一度に提示され、ユーザーインターフェイスは単一 click で判断できるように設計されています。 認定キャンペーンは通常定期的 で実行され、多くのデータを処理する必要があるため、このプロセスをできるだけ効率的にする目的で全体が設計されています。

認定機構の設計にもかかわらず、誰かが期限内に判断しない可能性は残ります。 キャンペーンは time-limited に設計されており、複数 段階 を持つことができ、すべての判断が揃っていなくてもキャンペーンを close できます。 しかしポリシーが判断を必須とする場合があります。 そのため midPoint 3.6 では、認定ケースに対してもエスカレーション機構が導入されました。 期限内に判断されなかったケースは、エスカレーションスキームを使ってエスカレーションできます。

認定は通常キャンペーンとして実行されます。 しかし、限定的な認定判断が必要となる例外もいくつかあります。 よくあるケースの1つは、ユーザーが新しい組織上の単位に再割り当てed され、新しいマネージャーを得る場合です。 新しいマネージャーは、そのユーザーが持つロール割り当てに責任を持つことになります。 古い組織上の単位でユーザーが持っていたロール割り当ての一部は引き続き必要かもしれませんが、他のロール割り当ては不要になり、削除されるべきかもしれません。 そのため midPoint 3.6 では、設定されている場合に、このような限定的認定を実行する能力が導入されました。 たとえばユーザーが新しい組織上の単位に移動すると、midPoint は移動を行い、申請され承認されたロールは変更せずに残します。 しかしその直後、その特定のユーザーの認定が新しいマネージャーに対して開始されます。 マネージャーは、どのロールを残し、どのロールを削除するかを決定します。 認定が close されると、ユーザーロールは自動的に調整されます。

ポリシールール

ポリシールールは、midPoint で多くのガバナンスとコンプライアンスの機能を実装する基本機構です。 ポリシールールはさまざまな目的で使われます。 たとえば、組織上の単位におけるマネージャー数が正しいかを確認するためにポリシールールが使われます。 ポリシールールはロール承認に影響を与えるためにも使えます。 ポリシールールはロール排他性 (職務分掌) を強制します。 ポリシールールはコンプライアンス機能が使う ベースライン を定義します。 全体として、ポリシールールは midPoint でアイデンティティガバナンスポリシーを表現するために使われる「言語」です。

ポリシールールは非常に柔軟で、いくつかの異なる方法で指定できます。 すべてのオブジェクトまたは filter で選択されたオブジェクトの subset に適用される グローバルポリシールールがあり得ます。 ポリシールールはロールに直接指定することも、メタロール に間接的に指定することもできます。 これらの機構を使って、非常に複雑なポリシーを作成できます。 MidPoint は、それらがどのように定義されているかにかかわらず、各オブジェクトに適用されるすべてのルールを評価します。 したがって midPoint は、すべてのルールが一貫して適用されることを保証します。

ポリシールールは midPoint 3.5 で導入され、その最初の用途は policy-based 承認の実装でした。 ポリシールールは、特定ロールをどのように承認すべきかという方法を指定するために使われます。 MidPoint 3.5 以前は、承認の対象となる各ロールに承認者と承認スキーム を定義しなければなりませんでした。 MidPoint 3.5 以降は、承認スキーム を指定する グローバルポリシー、または メタロールベースポリシーを持てるようになりました。 ポリシールールの機能は midPoint 3.6 で大きく強化され、midPoint 3.7 でさらなる強化が期待されています。

職務分掌

職務分掌 (SoD) は、危険な権限組み合わせを避けるために権限を分離する方法です。 たとえば、material を purchase する権限を持つ従業員は、その purchase を確認する責任も持っていてはなりません。 そうでなければ fraud や誤りが起こる可能性があります。 通常、executive 責任と controlling 責任は厳格に分離する必要があります。

MidPoint で SoD を実装する主な機構はロール排他性 です。 簡単に言えば、各ロールはロール排他のリスト を指定できます。 Exclusion に含まれるロールは、同じユーザーに同時に割り当てできません。 MidPoint には、この機構がほぼ初期からありました。 しかし、この機構は midPoint 3.5 と 3.6 で大きく改善されました。 MidPoint 3.5 では、この機構はポリシールールと整合されました。 現在は、すべてのガバナンスとコンプライアンスポリシーを指定する統合された機構があります。

ロール排他 機能は midPoint 3.6 で大きく拡張されました。 MidPoint 3.6 以前は、ロール排他 を 強制 することしかできませんでした。排他的なロールは単純に同時割り当てできず、そうしようとする試みは誤りになりました。 これは理論上は正しいものの、実務上は大きな障害になります。 実務では、ロール排他性 には通常いくつかの degree があります。 非常に機密性の高いなロールの exclusivity は厳格に enforce しなければなりません。 一方で、理想的には segregate すべきだが、そこまで機密性の高いではないロールもあります。 しかし、そのルールを緩和する必要がある状況もあります。 利用可能な従業員が不足し、exclusion を一時的に suspend する必要があるかもしれません。 また、非常に特定のな状況では exclusion が実務上意味を持たないこともあります。 そのため midPoint 3.6 では、ロール排他 違反を追加承認によって処理できます。 これらの sensitivity が低めの exclusive ロールを1人のユーザーに割り当てようとした場合、追加承認者がその操作を許可するか拒否するかを判断できます。 承認者が操作を許可した場合、そのルールからの exception がロール割り当てに記録されます。 したがって midPoint は、その特定のケースを後続の照合作業や recertification キャンペーンで注意喚起すべきでないことを把握します。 MidPoint は各割り当てのメタデータを保存するため、この exception がいつ作成され、誰が申請し、誰が承認したかも明確です。

MidPoint の基本的なロール排他 では、互いに排除するロールを列挙することでロールを排除できます。 しかし実務では、より複雑な exclusion scheme が存在します。互いに exclude し合い、一度に1つだけ割り当てできるロールの種類、ユーザーが一方の種類 (executive または controlling) のロールだけを持てる2つのロール種類、などです。 このような scheme は、ロール排他 機構と非常に強力な メタロール 機構を組み合わせることで midPoint に実装できます。

ロールが割り当てられる時点で SoD を 強制することは非常に有用です。 しかし、SoD ポリシーの効率的な長期維持管理をサポートするにはそれだけでは不十分です。 すべてのポリシーはいずれ変化し、SoD ポリシーも例外ではありません。 SoD ポリシーは通常、より厳格で制限的にする目的で変更されます。 しかしその場合、古いポリシーの下では合法だったロール組み合わせが、新しいポリシーの下ではもはや合法でなくなります。 ポリシーが変更されたときに、競合するロールを単純に 割り当て解除することはできません。 第一に、midPoint は conflict のどちらの「side」を unassign すべきかを知りません。そして、すべてを unassign したいわけではありません。 第二に、そのような対応は業務に 影響 を与える可能性があります。 MidPoint の philosophy は、常に business first 方法を可能にすることです。midPoint は status quo を破壊しない設定を許容しなければなりません。 したがって、SoD ポリシーがより厳格になった場合でも、業務への damage を避けるために SoD 違反は変更されずに残されます。 しかし、その状態を維持したいわけではありません。 最終的に conflict を解決する方法が必要です。 MidPoint 3.6 にはそのための機構があります。SoD 認定です。 特殊な認定キャンペーンが開始され、designated 認定者が違反を1つずつどう扱うかを決定します。 これは、既存違反を resolve しつつ、業務への 影響 を最小化する効率的な方法です。

ロール排他 はもう1つの工夫にも使えます。 ロールの種類があり、そのうち任意の時点で意味を持つのは1つだけ、という状況がよくあります。 たとえば filesystem のユーザー quota を定義するロール、financial トランザクション limit を定義するロール、他の variation の基礎となる基本顧客プログラムを指定するロールなどです。 これらは「1 of N」スキームと呼ばれることがあります。 ロール排他性 は、このような scheme の実装に使えます。 これらのロールは互いに exclusive にされます。 しかし強制や承認の代わりに、特別な prune 対応が使われます。 既存ロールと conflict する新しいロールが割り当てられた場合、prune 対応により古いロールの自動 unassignment がトリガーされます (midPoint 3.6 以降で利用可能)。

ロールライフサイクル

ロールは情報セキュリティポリシーの基本的な構成要素の1つです。 すべてのポリシーと同様に、セキュリティポリシーも時間とともに変化します。 したがってロールも一定ではありません。 新しいロールは常に定義され、古いロールは deprecated され、新しいロールに置き換えられます。 ロールにはライフサイクルがあります。draft され、proposed され、サービスに active 化され、deprecated され、最終的にはサービスから外され archived されます。

MidPoint 3.5 では、すべての midPoint オブジェクト、つまりユーザー、ロール、組織、サービス、その他オブジェクトに適用できるオブジェクトライフサイクルの概念が導入されました。 しかし最も重要なアプリケーションはロールライフサイクルです。 いくつかの pre-defined ライフサイクル状態があり、追加の専用状態も使えます。 MidPoint 3.5 では、ロール変更を承認プロセス経由で進める能力も導入されました。 これら2つの機能を組み合わせることで、新しいロールの定義と proposal、既存ロールの置き換えと廃止 など、制御されたロールライフサイクルプロセスを実装できます。

MidPoint 3.5 のオブジェクトライフサイクルサポートは実用可能ですが、まだ完全ではありません。 ライフサイクル機構の改善は、midPoint subscriber の関心に基づき、将来の midPoint version で計画されています。

是正

MidPoint 用語における remediation は、ポリシー違反を re仲介 する semi-formal 対応を意味します。 これはポリシー違反を修正し、状況をポリシーに完全に準拠にする対応です。 この対応または判断は、物理的な人物によって行われる必要があります。 たとえば、古いマネージャーが会社を離れた結果、マネージャーのいない組織上の単位ができた場合、新しいマネージャーを選ぶことが是正になり得ます。 新しいロール定義が業務に許容できない 影響 を持つ場合、是正はロール定義の変更につながるかもしれません。 是正対応は「別のことをする」対応です。つまり、自動でもアルゴリズムによるでもない、知的な人間が下さなければならない判断です。 MidPoint がポリシー違反を自動的に修正できる場合、それを是正とは呼びません。 そのケースは簡単すぎます。 それは通常の midPoint behavior です。 業務 as usual です。 Remediation という用語は、midPoint が自動的にはできないものに reserved されています。

MidPoint 3.6 以前には、ポリシー違反を自動的に handle できる多くの機構があります。 承認や認定など、人間の input に依存してポリシー違反を修正する機構もあります。 しかし、これらの機構はすべてユーザーが選べる pre-defined 選択肢を持っています。 まだ「別のことをする」選択肢はありません。 このような柔軟是正機構は、midPoint 3.7 に暫定的に計画されています。

コンプライアンス

どの組織も真空の中に存在しているわけではありません。 常に law、規制、外部または内部ポリシーが存在し、それらの多くはアイデンティティの管理方法に影響します。 さらに重要なのは、ポリシーが常に変化していることです。 ゼロベースにアイデンティティ管理の新しいシステムを構築することは、それほど難しくありません。 しかし、既存システムに新しいポリシーを適用することは非常に困難な場合があります。 特に、数千のユーザーが数千のロールを割り当てられている場合はそうです。 ユーザーは日々の職務を行っており、彼らが行うほぼすべての作業はアイデンティティ管理ソリューションによって制御される権限に依存しています。 これは生きて呼吸している organism です。 新しいポリシーを検討するとき、何が起こるかを見るために、この生き物に単純に適用することはできません。 新しいポリシーは既存の業務プロセスを危険にさらすかもしれません。 Impact が深刻すぎるため、ポリシーを1 手順で実務的に適用できないかもしれません。 Transition period が必要で、ポリシーをいくつかの連続した手順で実装する必要があるかもしれません。 ポリシーが full effect になる前にポリシー違反を見つけ、手動で 是正する必要があるかもしれません。 しかし、これらすべてをポリシーを見ただけで見積もるするのは非常に困難です。 ポリシーの影響の多くは非常に subtle で、見積もるするのが極めて困難です。 また、IDM システムからのサポートなしにすべてのポリシー違反を見つけることはほぼ不可能です。 これらが compliance 機能の理由です。

コンプライアンス機能の主な目的は、システムが特定のポリシーにどれほどよく準拠しているかを追跡することです。 ポリシーは midPoint が理解できるオブジェクト、つまりポリシールール、ロールなどに変換されます。 しかし、このポリシーはまだ完全には enforce されません。 最初の手順は、これらのルールを使って、新しいポリシーがシステムに与える 影響 を analyse することです。 MidPoint はポリシー違反を見つけ、レポートできます。 ポリシー違反がどれだけあるかを評価できます。 ポリシーを複数の手順に分解し、各個々の手順の 影響 を評価できます。 ポリシーをより実践的なにするために adjust できます。 ポリシーが完全に enforce される前に、ポリシー違反を見つけて remedy できます。 コンプライアンス機能は、新しいポリシー adoption の全体プロセスを track し続けることを支援します。 ポリシー違反の数と、それらの時間経過における progress を示すコンプライアンスダッシュボードがあり得ます。

MidPoint におけるコンプライアンス機能の実装は、ポリシールールの概念に大きく基づいています。 ポリシールールは、law、規制、その他ポリシーによって与えられる constraint を指定するために使われる言語の最も重要な部分です。 ポリシールールは midPoint 3.5 で利用可能になり、midPoint 3.6 で大きく拡張されました。 しかし midPoint 3.6 でさえ、ポリシールールが enforce されるべきポリシーを定義することを前提にしています。 MidPoint 3.6 には非常に基本的なコンプライアンス機能しかありません。 コンプライアンス機能の大幅な拡張は、midPoint 3.7 以降の version に暫定的に計画されています。

ロールマイニング

ゼロベースに導入されるアイデンティティ管理ソリューションはほとんどありません。 たとえ midPoint が組織に導入される最初の自動化された IDM ソリューションであっても、それ以前にアイデンティティを管理する何らかの方法は常に存在していました。 それは紙ベースのプロセスだったり、完全にアドホックな活動の集合だったりすることが多いですが、常に何かはありました。 したがって、それらの活動によって作られたデータが多く存在します。 一部のデータは midPoint に取り込みやすいものです (HR データなど)。 MidPoint には、アカウントを相関付けし、アカウント属性を一貫したにする優れたツールがあります。 これらの機能はアイデンティティ管理プロセスを劇的に改善します。 これは、拡大しつつ情報セキュリティも維持管理する必要がある組織にとって絶対的な要件です。

MidPoint は既存データを使って、次世代アイデンティティ管理ソリューションを bootstrap します。 しかし、そのデータの中には埋もれた treasure もいくつかあります。アカウントにすでに割り当てられている権限です。 権限は arbitrary に割り当てられたわけではありません。 割り当てには理由があり、その理由はユーザーが職務を行うために権限を必要としていたことです。 これは正しく使えば非常に価値の高い情報です。 この情報を midPoint のユーザーデータと相関付けし、可能であれば他のリソースとも相関付けできます。 その相関付けの結果、新しいロールをどのように作成するかの 提案 が得られるかもしれません。 類似した既存エンタイトルメントの集合を持つユーザーは、新しいロールの member 候補として有力です。 この方法は role mining と呼ばれます。

MidPoint はすべてのユーザー、アカウント、ロール、エンタイトルメントに関する情報を持っており、それらは将来的に効率的なロールマイニングを可能にする形で提示されています。 MidPoint には現在ロールマイニング機能はありません。 しかし、そのための基本 infrastructure は準備されています。 ロールマイニングは近い将来、標準の midPoint 機能として、または拡張として実装される可能性があります。 ロールマイニングの実装計画は、midPoint subscriber とパートナーに依存します。

リスク管理

リスク管理は情報セキュリティの基本です。 情報セキュリティ専門家なら誰でも手順を知っています。assessment、計画、execution、reaction、などです。 その中でも assessment 手順が最も負荷が高くかもしれません。 セキュリティ担当者は、数十のアプリケーション、数百のビジネスロール、数千のユーザーを持つシステムのリスクをどのように評価 できるでしょうか。 これは、数万のアカウント、数千のグループとロール、その他エンタイトルメントを評価することを意味します。 孤立アカウントの check、機密性の高いデータへのアクセスの確認、権限蓄積の確認、危険な権限組み合わせの確認 などを行うことを意味します。 これを手作業で行うのは超人的な作業です。 中規模組織であっても明らかに 実行困難 です。 そのため一般的な実務は、リスクを分析するのではなく見積もるすることです。 しかしその見積もるはどれほど良いのでしょうか。 そして、その主な input であるリスク評価が信頼できるでない場合、リスク管理プロセス全体はどれほど良いのでしょうか。

それでも、はるかに良い方法があります。 アイデンティティ管理システムは、このリスク評価の部分に必要なデータの大半をすでに持っています。 IDM システムはすべてのアカウントを知っており、owner を知っており、アカウントとエンタイトルメントがロールによって正当化されているかを知っています。 そしてこれはさらに改善できます。 ロールにリスクレベルを割り当てることで、各個々のユーザーがもたらすリスクを容易に assess できます。 これは、危険な権限蓄積 を持つ 高リスクユーザーを見つけるために使えます。 この方法は、各アプリケーションの全体的なリスクレベルを assess するためにも使えます。 ポリシールールなどのガバナンス機構は、危険な権限組み合わせを検出するために使えます。 もしかすると、競合するロールが1人のユーザーに割り当てられているが、SoD ポリシーが 明示的な承認によって 上書きされているかもしれません。 これはポリシーに準拠かもしれませんが、それでもセキュリティリスクであり、リスク評価で考慮されるべきです。 MidPoint はそのようなデータをすでに維持管理しているため、容易に gather できます。 必要なのは、そのデータを良いリスク評価モデルにフィードすることだけです。

現在 midPoint は、リスク評価モデルで使えるすべてのデータを維持管理しています。 MidPoint はポリシールールの定義と、ロールのリスクレベル指定を可能にします。 MidPoint は semi-automatic リスク評価をサポートする効率的なツールとして機能するよう設計されています。 しかしリスク評価モデル自体はまだ実装されていません。 近い将来実装される可能性があります。 ただし、具体的な実装計画は midPoint sponsor、subscriber、パートナーに依存します。

情報セキュリティ

アイデンティティ管理は情報セキュリティの基盤 stone の1つです。 情報セキュリティ専門家が必要とする重要な情報があります。特定アカウントに誰が responsible なのか、どのアカウントに owner がいないのか、この特定のユーザーがどのシステムにアクセスできるのか、などです。 これらの問題に答える現実的でスケーラブルな唯一の方法はアイデンティティ管理です。 アイデンティティ管理なしにセキュリティは本当に存在せず、私たちは何年もそう伝えてきました。 アイデンティティ管理は情報セキュリティに不可欠なデータを提供します。 良いアイデンティティ管理は、良い情報セキュリティの必要条件です。 それに疑いはありません。 しかし、セキュリティ担当者 の仕事を効率的にするのはアイデンティティガバナンスです。 アイデンティティ管理なしに、非 trivial なシステムを 安全 にすることはほぼ不可能です。 しかし、本当に複雑なシステムを構築し維持管理できるようにするのはアイデンティティガバナンスです。 アイデンティティ管理が necessary condition である一方、アイデンティティガバナンスは成長と効率的な長期維持管理の enabler です。

ロールベースのアクセス制御 (RBAC) は、今でもエンタープライズ情報セキュリティの golden 標準です。 それには十分な理由があります。 Attribute-Based アクセス制御 (ABAC) のような、理論上はより柔軟な若いモデルもあります。 実際、場合によってはそれらの方が優れています。 しかし、これらのモデルが主張する革新性そのものが、同時に主な問題でもあります。ロールの概念がないことです。 ロールがなければ、特定のユーザーが持つ権限を把握するのはかなり困難です。 ロールがなければ、ユーザーが申請できるものがありません。 システムへの変更の 影響 を評価することが困難です。 ポリシーへのコンプライアンスを評価することも非常に困難です。 などなどです。 とはいえ、ABAC のような柔軟モデルには merit があります。 だからこそ midPoint は、多くの式によって従来型 RBAC モデルを拡張しています。 その結果が、ABAC の考え方を RBAC モデルに取り込んだ Advanced Hybrid RBAC モデルです。 しかし私たちのモデルは、アイデンティティ管理とガバナンスの主な「atom」としてのロールに依然として基づいています。

典型的な中規模エンタープライズの情報セキュリティ専門家は、数百、場合によっては数千のロールを扱わなければなりません。 これらすべてのロールを把握し続けるのは非常に困難です。 多くのセキュリティ担当者は スプレッドシートや専用アプリケーションでロールを追跡しています。 これは手作業作業に基づいているため、維持管理が非常に困難です。 この方法は本質的に情報システムから disconnected であるため、現実を反映していることを保証するのが非常に困難です。 規則的監査、手作業レビュー、同期が必要になります。 これにより、この方法はスケーラブルでないになります。 Fidelity を失わずに数百ロールを超えて scale することは非常に困難です。 多少の不正確さを許容し fidelity を犠牲にしたとしても、数千ロールが上限です。 これは組織の成長を制限する要因の1つです。

もちろんソリューションはあります。アイデンティティ管理とガバナンスです。 ソリューションの第一の部分は、ロールを現実としっかり結び付けておくことです。 これはまさにアイデンティティ管理システムが行うことです。 ロール design、権限プロビジョニング、監査 (照合) の「closed loop」を維持管理します。 自動的な 双方向 フィードバック があります。ロール変更は 実システムに反映され、実システムの変更は 検出されレポートされます。 しかし、それはソリューションの一部にすぎません。 第二の部分は、ロール管理をより効率的にすることです。 最低限必要なのは、ロールをロールカタログに分類できることです。 MidPoint は、多くの独立した criteria に基づいてロールを分類できます。 ロールはアプリケーション、業務 領域、影響範囲 などで分類できます。 ロールカタログは、ロール維持管理の一部制御をアプリケーション所有者や業務 部門 に 委任するためにも使えます。 MidPoint が提供するロールカタログとその他のロール管理ツールは、スケーラブルなロール維持管理を可能にするために絶対に不可欠であり、それが組織の効率的な成長を可能にします。

MidPoint は、アプリケーションが自動化されたコネクターで接続されている場合に最も効率的です。 その場合、midPoint はポリシーと現実の整合性を自動的に維持管理できます。 しかし、すべてのアプリケーションが midPoint に自動接続されていない場合でも、midPoint のロール管理サポートは不可欠です。 MidPoint には、当初からリソースの 非自動接続 の能力がありました。 しかし midPoint 3.6 では、この能力が大きく改善されました。 Manual connector は、自動コネクターを持たないシステムを接続する便利な方法です。 これは、自動コネクターを構築する費用に見合わない小さなシステムかもしれません。 または、プロジェクトの後続フェーズ で自動コネクターが計画されているシステムかもしれません。

自動コネクターを使うか手作業コネクターを使うかにかかわらず、midPoint でロールを design し維持管理することには常に効果があります。 新しい規制は常に導入され、新しいポリシーを 強制する必要があります。 たとえば、2018年半ばに施行される General データ Protection 規制です。 あなたの組織は GDPR に備えていますか。 あなたのロール構造は準拠ですか。 あなたのポリシーは準拠ですか。 準拠にするには何が必要ですか。 現在、新しいポリシーに違反しているユーザーは何人いますか。 それらの違反を解決するにはどれだけの作業が必要ですか。 Paper-based ポリシーからこの情報を得ることはほぼ不可能です。 しかし midPoint のガバナンスとコンプライアンス機能を使えば、これらの問題に容易に答えられます。

手作業コネクターと ITSM 統合

典型的なエンタープライズは、多くの異種混在のシステムを維持管理する必要があります。 中規模エンタープライズでさえ、広範なベンダーから提供され、さらに広範な技術で構築された数十から数百のシステムを通常維持管理しています。 これらすべてのシステムを自動化されたコネクターによって IDM ソリューションに接続することが強く望まれます。 これにより 運用費用が下がり、操作が高速化し、ガバナンス機構の信頼性が高まります。 しかし、それが常に選択肢になるわけではありません。 小規模または deprecated されたシステムでは、自動化されたコネクターを構築する費用に見合わない場合があります。 自動化されたコネクターが望ましいが、プロジェクトの後続フェーズ で計画されているシステムもあります。 すべてのシステムを IDM に直接接続できない理由は多数あります。 それが midPoint 3.6 の manual connector 機能の理由です。

Manual connector は、特別な種類のリソース接続 です。 この場合、midPoint は対象システムに接続するために自動化されたコネクターを使いません。 MidPoint は、アカウントがどのようにあるべきかを記憶し、pending 操作を記憶するだけです。 MidPoint は管理者に、アカウントを手動で作成、更新、削除するよう notify します。

ほとんどの組織には、システム管理者に作業を割り当てるために使われる IT サービス管理 (ITSM) システムがすでにあります。 システム管理者が1つのツールだけで作業できるよう、midPoint が ITSM システムにチケットを送信し管理できることは非常に望ましいことです。 この種の統合は midPoint 3.6 で利用可能です。 ただし、個々の ITSM システムとの統合には、midPoint 側にそれぞれの「プラグイン」(driver) が必要です。 MidPoint 3.6 と 3.7 に向けて、Evolveum パートナーからいくつかのプラグインが contribution される計画があります。

手作業コネクターには、特別な 単方向の操作モードもあります。 この mode は、midPoint が write できないが、read アクセスまたは規則的データエクスポートがあるシステムに使われます。 この mode でも、midPoint はアカウントの作成、修正、削除の ticket を課題します。 しかし同時に、対象システムから直接取得したアカウント状態、またはエクスポートファイルから読み取ったアカウント状態を 確認します。 この方法は、対象システムの real データを扱うため、より良い可視性とセキュリティを提供します。 それでも統合は容易です。通常必要なのは、データの規則的本文ファイルエクスポートだけだからです。

関連項目

• アイデンティティガバナンスおよび管理

• エンタープライズアイデンティティおよびアクセス管理

• Advanced Hybrid RBAC

• ポリシールール

• 職務分掌