IGA 機能: フルフィルメント
この記事は https://docs.evolveum.com/iam/iga/capabilities/fulfillment/ の翻訳です。
別名
- プロビジョニング/デプロビジョニング
- 変更の伝播
フルフィルメント機能
- アイデンティティリソース管理。 ソース/対象システムとやり取りするための接続パラメータとコネクターコードの保守。 アイデンティティリソースとコネクターのインベントリ、状態とスキーマの保守。 アイデンティティスキーマ discovery。
- リモートシステムとの通信。 Remote システム（アイデンティティリソース）での作成/read/更新/削除（CRUD）操作の実行。 通信プロトコルの実装、プロトコル差異への適応、データ型変換。 追加操作（例: プロビジョニングスクリプト）の実行。 Remote システムがサポートしていない機能のシミュレーション。
- フルフィルメント失敗の処理。 通信エラー、設定エラー、通信セキュリティ違反、その他類似の失敗の検出、解釈、処理。 操作の再試行、遅延操作、その他の corner ケースの管理。
- アイデンティティ状態の追跡。 アイデンティティ属性の追跡。たとえば IGA システムのデータベースに属性をキャッシュすること。 アイデンティティリソースに存在しないアイデンティティ（例: まだ作成されていないアカウントや、最近削除されたアカウント）を含むアイデンティティ status の追跡。
- 手動フルフィルメント操作の管理。 手作業フルフィルメントのプロセス管理、手作業操作の開始、操作状態の追跡、ITSM システムとの通信。 操作フィードバック の処理（例: 半手作業のフルフィルメントの場合）。
概要
簡単に言えば、フルフィルメントは変更を対象システムへ伝播する機能です。 フルフィルメントはユーザーアカウントを作成、変更、削除します。 厳密に言えば、この機能は、たとえばポリシーによってアカウントが要求されたときにそのアカウントを作成することで、ポリシーを fulfilled します。 しかし、フルフィルメントでは作成・変更・削除操作に加えて、データを読み取り、比較する必要があることもよくあります。 これにより、他の機能、特にエンタイトルメント管理と同期との大きな重なりが生じます。 さらに、属性スキーマ管理、属性価値の解釈と変換、その他の機能は、ほぼすべての IGA 機能に必要であり、フルフィルメントにも必要です。 したがって、ここでは fulfilment という用語を、対象システムとソースシステムを扱うために必要な低レベル機能すべてを意味するものとして使い、単なる変更の伝播だけに限定しません。
フルフィルメントの望ましい実装は、ほとんど常に automatic fulfilment です。 この場合、変更は IGA システムのコマンドを実行するコネクターまたはエージェントによって、対象システムに自動的に行われます。 これは明らかに、最も便利で信頼性の高い方法です。 しかし、コネクターやエージェントの開発と保守はかなり負担が大きい場合があります。 対象システムの中には、再利用可能なプログラムming インターフェイス（API）の形で必要な機能を提供していないものもあります。 そのため、デプロイメントによっては manual fulfilment を選ぶことがあります。 この場合、変更は IGA システムからの要求に従って、人間のオペレーターが実行します。 IT サービス管理（ITSM）システムは、オペレーターへ指示を届け、作業の進捗を追跡するためによく使われます。 手作業フルフィルメントは通常、実用的で非常に費用対効果の高い解決策ですが、大きな欠点があります。 IGA システムが対象システムに到達できないため、アカウントが正しく作成されたか、さらに重要なこととして、権限が正しく削除されたか、またはアカウントが削除されたかを確認できません。 これは深刻なセキュリティ問題を生みます。 そのため、一部の IGA システムは 半手作業のフルフィルメント の選択肢を提供しています。 この場合、操作は人間のオペレーターによって実行されます。 しかし、対象システムから定期的にデータをエクスポートし、検査のために IGA プラットフォームへ渡すプロセスがあります。 IGA プラットフォームは不整合を特定し、状況を修正するための作業をオペレーターに作成します。
自動フルフィルメントは通常、identity connectors を使って実装されます。 コネクターは比較的小さなコードのまとまりであり、対象システムとのネットワーク通信の詳細を実装します。 コネクターは、そうしたプロトコルやインターフェイスが利用できる場合、標準化されたネットワークプロトコルまたはインターフェイス（API）を使って対象システムと通信します。 一部の IGA プラットフォームはコネクターの代わりに agent を使います。 エージェントは対象システムの環境にインストールされ、対象システムとローカルに通信します。 エージェントは通常コネクターより強力ですが、たいてい大きな保守負担を生みます。
Connectors は、特定のプロトコルまたはインターフェイスを使うように設計された、比較的単純なコードです。 しかし、connector は接続先の host を知らず、認証情報やその他の接続詳細も知りません。 そうした詳細は アイデンティティリソース に指定されます。これはアイデンティティデータベースへの通信チャネルを記述するデータ構造です。 Identity リソース は通常、内部ユーザーデータベースを持つアプリケーションを表します。 しかし、アイデンティティリソース は、多くのアプリケーションで使われるディレクトリサービスやアイデンティティプロバイダーへの接続を表すこともあります。
Identity リソース は通常、identity schema を扱います。 Schema は、特定の アイデンティティリソース で使われるデータ構造の記述です。 たとえば、スキーマは通常、ユーザーアカウントが持つことのできる attributes の名前と型を指定します。 一部のアプリケーションには静的なスキーマがあり、すべてのアプリケーション instance で同じです。 しかし、リレーショナルデータベースや LDAP ディレクトリサーバーのように、柔軟または拡張可能なスキーマを持つシステムもあります。 そのような場合、アイデンティティリソース は多くの場合、実行時に動的にスキーマを決定する schema discovery をサポートします。
コネクター管理に加えて、フルフィルメント機能にはかなりの量のエラー処理 機能が含まれます。 対象システムが提供するプロトコルやインターフェイスは、その機能に大きな差があります。 たとえば、あるシステムはアカウントを無効化 できますが、別のシステムではできません。 あるシステムはアカウントを削除できますが、別のシステムでは永続的に 無効化することしかできません。 こうした詳細の一部はコネクターコードで扱えます。 しかし、多くの詳細と edge ケースはフルフィルメント構成要素で扱う必要があります。 たとえば、フルフィルメントは通常、対象システムが持たない機能をシミュレートする必要があります。認証情報を 無効化 または変更することでアカウント 無効化をシミュレートする場合などです。 エラー処理 は機能の重要な部分です。たとえばネットワーク障害 の場合に操作を再試行することを保証します。 エラー処理 コードはしばしば非常に複雑です。特に同期、エンタイトルメント管理、ポリシーなど、他の機能との相互作用が数多くあるためです。
フルフィルメント構成要素は通常、対象システム上でスクリプトを実行する機能など、追加機能も提供します。 このような機能は、アカウントプロビジョニングを完了するために使われることが多く、アカウントアーカイブの場合に filesystem データをアーカイブするために使われることもあります。