IGA 機能: 同期

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

別名

• 照合

• 相関付け

同期機能

• データフィード管理。 ソースシステムから IGA プラットフォームへの inbound データフィードの管理。 変更のリアルタイムまたはほぼリアルタイム検知と処理。 複数データソースを扱い、情報が適切に merged されることを保証すること。

• 照合。 ソース/対象システムにおける物事の real 状態と、IGA プラットフォーム内のデータおよびポリシーを比較すること。 フルフィルメントが機能していること、特に手作業フルフィルメントを 確認し、アカウント存在、属性価値、エンタイトルメントを 確認します。 多様なアイデンティティ種類、ユーザー、アプリケーション、org、ロールの照合をサポートします。

• データ整合性管理。 データの eventual 整合性の維持管理。 データフィード、照合、opportunistic disco非常に など、さまざまな方法で 検出されたデータ不整合の検知。 Discovered 不整合に反応し、それを correct することを目指します。

• アイデンティティ相関付け。 同じアイデンティティを表すデータ構造、アカウントやエンタイトルメントの検知。 相関付けルールまたは query、probabilistic 相関付けなどの execution。

• 孤立アカウント検知。 Owner または同等の responsible entity を持たないアカウント、その他データの検知。 そのような状況への reaction。通常は owner の establish、またはアカウントの削除/無効化 につながります。

概要

同期機能は、接続されたすべてのシステム全体でアイデンティティデータの整合性を保つ機能を提供します。 フルフィルメントはアカウントがポリシーに従って作成されることを保証できますが、そのアカウントが常にポリシーに準拠であり続けることを保証するのは同期です。 このため同期は、あらゆる IGA プラットフォームにおいておそらく最も重要な基盤的な機能です。

同期は、IGA プラットフォームにデータをフィードする手段も提供します。 エンタープライズシナリオでは通常人事（HR）システムによって提供される、少なくとも1つの信頼できるデータソースが存在することがよくあります。 そのデータソースはユーザーの legal データと employment status に関する信頼できる情報を提供します。 しかし包括的な IGA 導入では、HR システムが提供する基本情報だけではなく、はるかに多くのデータが必要です。 したがって、比較的単純な導入であっても、authoritativeness のレベルが異なる多数のデータソースが存在することがよくあります。 そのようなデータソースは、contact 情報、組織構造割り当てなどの additional 詳細を提供することがよくあります。 組織構造、パートナー組織、セキュリティトークン、デバイス、"モノ" などの非人物アイデンティティに関するデータで IGA プラットフォームを 投入するために、複数のデータフィードが使われることがよくあります。 このような "自動" データソースは、手作業で維持管理されるデータで補完されることが多く、通常は spreadsheet の形で維持管理され、手作業で IGA システムへ取り込みされます。 一部のアイデンティティ種類が、IGA プラットフォーム内で信頼できるソースとして手作業で維持管理されることも珍しくありません。

通常、IGA システムへデータをフィードするソースは複数あります。 各ソースは、それぞれ独自のスキーマ、データ形式、コード、その他特定の characteristic を持つ可能性が高いです。 このような diverse データは、IGA システムのアイデンティティモデルと一貫した形式に 対応付け・変換 されなければなりません。 さらに、同じアイデンティティを説明する記録は 相関付けd され、merged されなければなりません。 相関付けは、従業員番号などの相関付け識別子が容易に利用できるエンタープライズシナリオであっても、完全に信頼できるプロセスではありません。 ソースデータはおそらく手作業で維持管理されており、データ誤りや不整合の可能性は比較的高いです。 IGA システムはデータが初めて出会うシステムであるため、手作業で handling しなければならない相関付け failure や mismatch が発生する可能性が高いです。 信頼できる相関付け識別子がない場合、または 半信頼できる相関付け属性が複数ある場合、相関付けはさらに困難です。 その場合は probabilistic 相関付け、別名 identity matching を使用できます。 しかし、そのような相関付けはほぼ常に human intervention を必要とし、semi-automatic プロセスになります。 相関付け労力の大半は、IGA プラットフォームが導入される時点、または新しいシステムが IGA プラットフォームに接続される時点で想定されます。 しかしソースデータは常に変化し、ユーザーグループは増減します。 したがってアイデンティティ相関付けは 継続的 プロセスであり、日常的なアイデンティティ管理処理の一部です。

データソースから IGA システムへの 継続的 データフィードには、2つの fundamental モデルがあります。

• Pull モデル (polling): IGA プラットフォームが新しいデータを periodic に polling します。 たとえば IGA システムは、last poll 以降に changed されたデータベース row を探す場合があります。 ポーリング間隔は比較的短く、通常は数分程度です。 したがってこの方法は、多くの一般的ケースに十分な "ほぼリアルタイム" 同期を提供できます。 Pull-based 同期は、変更識別子、変更シリアル番号、timestamp、シーケンス番号などが適切に存在する限り、通常導入と維持管理が単純です。 しかし同期には固有の遅延、つまりポーリング間隔があります。 またソースシステムは additional 状態、変更 timestamp、変更 log などを保持する必要があります。 Pull-based 機構のおそらく最も痛い欠点は、削除済みオブジェクトの検知です。 これは特に timestamp-based polling 機構に影響します。オブジェクトが痕跡なく削除される場合です。 Timestamp-based polling 機構は、そのようなケースで削除済みオブジェクトを detect できません。

• Push モデル (messaging): ソースシステムがデータ更新について IGA プラットフォームに actively notify します。 メッセージベースのシステムは プッシュベースの同期フィードの実装によく使われます。 そのようなフィードは、circumstance が理想的な、変更 volume が低く、変更処理が速い場合、リアルタイムに非常に近い同期を提供できます。 さらに プッシュベースの同期は、state-keeping 機能を専用 intermediary、つまりメッセージ broker に移し、ソースシステムと IGA プラットフォームを de-couple できます。 しかしこの方法は通常、データ path方法に additional 構成要素と indirection を追加し、ソリューションの複雑性を増やします。 メッセージ broker に基づく同期が advantage かどうかは明確ではありません。Full メッセージ queue、bug、設定ミス などによるメッセージ loss の border ケースを依然としてすべて cover しないからです。 Sender、つまりソースシステム、または receiver、つまり IGA プラットフォームは、message-based communication の full 信頼性のために追加機構を必要とします。

明らかに、単一汎用 と 信頼できる同期機構は存在しません。 状況は ケースバイケース で考慮する必要があり、それが IGA 導入を複雑にします。

同期は、接続されたすべてのシステムにおけるデータの 継続的 整合性を 強制することを目的とします。 しかしこの作業は見かけよりはるかに難しいです。 IGA プラットフォームは、それぞれがさまざまなデータモデル、アクセスプロトコル、操作al characteristic、整合性 constraint を持つデータベースを維持している、複数の independent システムを相互接続します。 単純な操作の間でさえデータが一貫したままであることを保証する汎用機構はありません。 Transactional 機構は一部のシステム、通常はリレーショナルデータベースでしか使えず、そこでも詳細は大きく異なるため、汎用 cross-system データ整合性にはほとんど役に立ちません。 多くのシステムは REST インターフェイス、API に基づいており、データ整合性保証 をまったく提供しません。 データは操作完了直後、または操作実行中にさえ変わる可能性があります。 このような環境では、short-term データ整合性は間違いなく大きな challenge です。 Long-term データ整合性は巨大な作業です。

ほとんどの IGA プラットフォームは現実を認め、eventual consistency 方法を採用しているようです。 この paradigm では、ある時点でデータが一貫しないである可能性がありますが、最終的にはデータは一貫したになります。 結果整合性は複数機構の組み合わせによって達成されますが、reconciliation はおそらく最も広く使われる汎用な機構です。

Reconciliation は、IGA プラットフォームに保存されたデータと対象システムのデータを比較するプロセスです。 照合にはさまざまな形式があります。 最も lightweight な照合プロセスはアカウント存在だけを見て、すべての属性とエンタイトルメントを無視します。 最も heavyweight なプロセスは各ユーザーに対して完全なポリシー評価を実行し、アカウント status、すべての属性価値、エンタイトルメントを 確認します。 すべての照合形式は通常、orphaned account を検出できます。 孤立アカウントとは、IGA データベースに 対応するアイデンティティを持たないアカウントです。 それらは通常、削除されるべきだったがシステムに残ったアカウントです。 アカウントが削除されなかった理由は、人為的誤り、コネクターコードの bug、システム管理者による手作業作成、たとえば テスト アカウント、失敗 回復 の 副産物、古い back-up からのデータ restore、またはアカウントが overlooked された他の多くの理由かもしれません。 孤立アカウントはしばしば重大なセキュリティリスクであるため、孤立したアカウントの検知と クリーンアップ は IGA 導入の重要な機能です。 しかし 孤立したアカウントの検知だけでは、継続的 セキュリティレベルを維持するには不十分です。 データ整合性、したがってセキュリティを維持するには、照合が誤りアカウント status、誤り属性価値、誤りエンタイトルメントを検出しなければなりません。 これは、データソースから IGA プラットフォームを経由して対象システムまで、情報の整合性を end-to-end で確認する完全な照合プロセスによって達成できます。 完全照合は負荷が高くで遅いかつ長時間実行されるなプロセスです。 それでも必要なプロセスです。 完全照合は通常、データが一貫しており、長期に一貫したままであることを保証する唯一の実践的な機構です。 Periodic に実行されるべきです。

照合は、アカウントが正しくプロビジョニングされたことを確認し 孤立したアカウントを確認する "監査" 機構と見なされることがよくあります。 しかし照合はそれ以上のものです。 照合は不可欠データ整合性機構であり、IGA プラットフォーム全体の適切な運用に重要なです。 照合はデータフロー の target side と source side の両方で使われなければなりません。 "リアルタイム" 同期機構は 信頼できないであるため、データソースの照合は、IGA が fresh で valid なデータを扱っていることを保証する唯一の実践的な方法です。 総じて、照合は crucial failsafe 機構です。 IGA プラットフォームに接続されたすべてのシステムとデータフィードに対して使われるべきです。

同期は、新しいシステムを IGA プラットフォームに接続する必要があるときに特に不可欠なツールです。 新しいシステムは、実のところそれほど新しいではない可能性が高いです。 そのシステムは IGA プラットフォームに接続される前に何年も稼働しているかもしれません。 したがってシステムにはほぼ常に既存データがあり、それを IGA プラットフォーム内のデータと相関付けし reconcile する必要があります。 同期はこの職務に適したツールです。 この機能はあまり頻繁には必要ないように見えるかもしれません。 しかし現実はかなり違います。 特に柔軟クラウドサービスの時代には、新しいシステムが常に追加され、廃止されます。 同期機能は、IGA 導入の ライフタイム 全体を通じて、予想以上に頻繁に使われます。

同期は、データフィードを受け取り長時間実行される照合プロセスでデータを比較するだけのものではありません。IGA プラットフォーム全体に浸透する不可欠機能です。 同期イベントは、IGA プラットフォームが行った予期しない "discovery" によってトリガーされることがあります。 たとえば IGA プラットフォームがアカウントを 修正 しようとしたが、そのアカウントがもはや存在しない場合です。 または IGA プラットフォームがアカウントを作成しようとして、conflicting 識別子を持つ不明アカウントがすでに作成されていることを発見する場合です。 このような situation はアドホック同期イベントをトリガーし、しばしば situation の自動是正につながります。

アイデンティティ管理はもはやユーザーとアカウントだけのものではありません。 アイデンティティ種類は多数あり、その多くはアプリケーションロール、組織上の単位、サービスなどの非人物アイデンティティです。 同期は、このようなアイデンティティを人物アイデンティティとほぼ同じ方法で handling できなければなりません。 少し counter-intuitive ですが、非人物アイデンティティは伝統的に target システムと見なされるシステム から 同期されることがよくあります。 たとえば IGA プラットフォームは Active Directory グループごとにアプリケーションロールを自動作成し、権限の適切なガバナンス、アクセス申請、ownership、認定を可能にするかもしれません。 これは、source システムと target システムの従来のロールがもはや厳密には分離されず、mixed 方法が 標準 になりつつあることを意味します。

同期機能は、フルフィルメントに使われるのと同じ identity connector を使って実装されることがよくあります。 これは完全に理にかなっています。同期機構とプロトコルは、接続先システムに依存するからです。

同期は見落とされがちな機能です。 Analyst からは通常、深い関心なくフルフィルメントまたは "監査" に含められ、軽視されます。 業務 観点 からは、同期がしばしば 隠れた であるため、それは理にかなっているかもしれません。 同期が正しく動作しているとき、それはユーザーにはほぼ完全に invisible です。 しかし現実を invisible にすることはできず、必ず跳ね返ってきます。 同期は接続されたすべてのシステムの信頼できる操作に不可欠であり、情報セキュリティには絶対的に重要なです。 同期は after-thought、IGA プラットフォームへの mere 拡張であってはなりません。 それはすべてに浸透するため、プラットフォームの中核に組み込ま されなければなりません。

関連項目

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