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

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

はじめに

アイデンティティガバナンスおよび管理 (IGA) は、アイデンティティおよびアクセス管理 (IAM) の分野であり、アイデンティティ関連情報の管理とガバナンスを扱います。 簡単に言えば、IGA はアイデンティティ情報の維持管理に関するすべての詳細を扱います。低レベル技術的な詳細から 高レベルの業務ポリシーまでが範囲です。

IGA システムは、ユーザープロファイルなどのアイデンティティ情報をストア、同期、管理します。 複雑なデータ、エンタイトルメント、ガバナンスポリシーを定義し、アイデンティティデータに適用できます。 IGA システムはポリシーを評価し、データが準拠であることを確認し、ポリシー違反に対処する責任を持ちます。 IGA は、アイデンティティ管理、アイデンティティガバナンス、コンプライアンス管理、アイデンティティベースリスク管理、その他アイデンティティ管理に関連する 側面 を覆う umbrella 用語と見なされることがよくあります。

IGA は IAM の非常に広い領域をカバーしますが、すべてを cover するわけではありません。 IGA は認証、セキュリティトークン、ユーザーがアプリケーションにアクセスする方法には関与しません。 それはアクセス管理 (AM) の懸念です。 IGA は認可にも直接関与しませんが、認可に影響するエンタイトルメントの管理は IGA の一部です。

用語

アイデンティティ専門家は、しばしば マーケティング上の必要性に動機づけられ、新しい名前を考案し、それを使って同じものを説明することを好みます。 そのため、多くの 重複した類似用語が使われています。 アイデンティティ管理 (IDM) は低レベル部分、つまり技術を説明するために使われ、アイデンティティガバナンス は 高レベル部分、つまり業務を説明するために使われます。 しかし 境界は非常に曖昧 であり、多くの IDM システムはガバナンス機能を提供し、多くのガバナンスシステムは低レベル機能を提供します。 ガバナンス、リスク管理、コンプライアンス (GRC) は、過去に高レベル アイデンティティガバナンス機能を表すために主に使われていた用語で、後に単に アイデンティティガバナンス として知られるようになりました。 アイデンティティセキュリティ は、IGA 機能をおおまかに cover する マーケティング用語です。

全体として、用語は非常に流動的 です。 ベンダーは独自の用語を使い、多義的または紛らわしい な用語を選ぶことがよくあります。 Marketing 用語は文書が適応するより速く invent され、状況をかなり 混乱させます。 私たちは、用語を理解可能 に保ちながら、できるだけ正確に用語を まとめようとしました。 多くの用語が 多義的で曖昧 であるにもかかわらず、可能な場合は 定着した業界用語に従うことを選びました。 しかし用語を re-invent して confusion を増やしたくはありませんでした。 必要に応じて本文中で 曖昧さ を指摘します。 迷った場合は 用語集 を参照してください。

アーキテクチャ

アイデンティティガバナンスおよび管理 (IGA) システムは IT インフラストラクチャ層 の一部です。 アプリケーションとアイデンティティデータストア内のアイデンティティ関連情報を管理・監視する不可欠サービスを提供します。 IGA システムはアイデンティティデータを統制し、それが最新で一貫していることを確認し、ポリシーを適用し、アイデンティティ関連セキュリティ課題を検出し、アイデンティティ関連リスクを評価し、不可欠可視性と分析機能を提供します。

IGA プラットフォームには2つの主な機能があり、それが2つの主なデータフロー につながります。

1. アイデンティティ管理、つまりアイデンティティ管理は、人事（HR）システムからのデータなどの信頼できるデータに基づき、ユーザーアカウントとエンタイトルメントの管理に重点を置きます。 この機能を実現するために、IGA プラットフォームはソースシステム、たとえば HR からデータを読み取り、それをプロセスし、対象システム、たとえば LDAP、Active Directory、アプリケーションにデータを書き込みなければなりません。

2. アイデンティティガバナンス は、アイデンティティデータへのポリシーアプリケーション、アイデンティティ関連プロセスの推進、アイデンティティとエンタイトルメント情報の収集と分析、リスク評価、ポリシー改善提案に重点を置きます。 この機能を実現するために、IGA プラットフォームは接続されたすべてのシステムへの直接読み取りアクセスを必要とし、アカウント、グループ、ロール、その他エンタイトルメント、組織構造など、すべてのアイデンティティ関連データを取得・分析します。 IGA プラットフォームは、ポリシー違反を 是正するため、たとえば 孤立したアカウントのアクセスを 無効化するために、必要に応じて情報を書き込みます。

機能を実現するために、IGA プラットフォームは組織全体のアイデンティティデータにアクセスする必要があります。 IGA プラットフォームはアイデンティティ情報を含むすべてのデータベースとデータストアにアクセスしなければなりません。 アクセスは通常コネクターを使って実装され、アプリケーションやデータストアに標準の 通信機構でアクセスします。 IGA プラットフォームは、フィルタリングや変形 のない信頼できるアイデンティティ情報へのアクセスに依存します。 アプリケーションとデータストアへの 直接 接続 は、IGA プラットフォームが適切に機能するためにほぼ常に不可欠です。詳細は 間接アクセス アンチパターン を参照してください。 アイデンティティデータを自分自身のデータベースにストアするアプリケーションは、常に IGA プラットフォームに直接接続されるべきです。 LDAP サーバーや Active Directory などのアイデンティティデータストアにあるアイデンティティデータを使い、その情報の永続的なローカルコピーを作らないアプリケーションは、IGA プラットフォームに接続する必要はありません。 しかし IGA プラットフォームは、そのアプリケーションの存在と、LDAP グループなどデータストアエンタイトルメントとアプリケーションとの 関係 を認識しているべきです。

IGA プラットフォームはポリシーエンジンでロールベースのポリシー、ガバナンスポリシー、組織上のポリシーなど、さまざまなポリシーをプロセスします。 ポリシーエンジンは通常プラットフォームの最も複雑な部分の1つです。 ポリシーの大半は 全自動モード でプロセスされますが、一部はユーザーや管理者とのやり取りを必要とします。 その目的、および他の目的のために、ほぼすべての IGA プラットフォームは 包括的なユーザーインターフェイスを提供します。 ユーザーインターフェイスは通常、いくつかの機能を提供します。

• 一般ユーザー向けのセルフサービスユーザーインターフェイス。 このユーザーインターフェイス部分は、アカウントとエンタイトルメントについてユーザーに知らせ、ユーザープロファイルの選択済み部分を管理できるようにし、パスワードなどの認証情報を管理する手段を提供し、アクセス申請の 提出 を可能にします。

• アイデンティティとポリシー管理機能は、アイデンティティ情報の修正と、ロール定義などのポリシー設定を可能にします。 このユーザーインターフェイス部分は、レポートと分析機能を管理し、レポート、分析、運用情報、たとえばダッシュボードの結果にアクセスするためにも使われます。

• 業務プロセスやり取りは、ユーザー、通常マネージャーがアクセス申請承認、認定キャンペーン、是正作業などのアイデンティティ関連業務プロセスに参加するために必要です。 このインターフェイスの一部は サードパーティ ITSM またはワークフローシステムに 委任される場合があります。

• システム設定インターフェイスは低レベルシステム機能を構成するために使われ、通常初期導入やカスタマイズ目的で使われます。 通常はシステム管理者だけがアクセスできます。

IGA プラットフォームは通常 API を提供し、通常は RESTful サービスの形式です。 API はアイデンティティデータ、ポリシー、設定など、IGA プラットフォームが処理するデータを公開 します。 API は通常 IGA 機能へのアクセスを提供しますが、API の機能は製品ごとに大きく異なります。

IGA プラットフォームは通常アイデンティティ関連業務プロセスに参加するため、organization-wide プロセス と 作業管理に使われるシステムと協力してプロセスを管理する要件があります。 通常は IT サービス管理 (ITSM) システムやエンタープライズワークフローエンジンです。 多くの IGA プラットフォームはそのようなシステムと統合し、承認プロセス、是正、類似作業を 委任する機能を持っています。 ITSM システムは手作業フルフィルメント操作を 仲介 するためによく使われます。

機能

アイデンティティガバナンスおよび管理 (IGA) は、業務と技術の両方の必要性によって駆動されます。 組織はそれぞれ異なりますが、多くの組織で非常によく似た形で使われる要件と機能が多数あります。 多くの IGA 製品に共通する基本機能は次のとおりです。

• アイデンティティライフサイクル管理

• エンタイトルメント管理

• フルフィルメント

• 同期

• ポリシーとロールの管理

• アクセス申請

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

• アクセス認定

• 監査

• アイデンティティ分析とレポート

続きを読む...

一般的な機構とインフラ

上記の IGA 機能は "tangible" な機能、つまりシステムユーザーにとって明らかな機能を提供します。 しかし、そのような機能を実装するために使われる機構と基盤となる infrastructure は多数あります。 次の機構は、ほぼ常に多くの機能で再利用されるため、特定機能に分類するのが困難です。

• 属性対応付け 機構は、属性価値の moving と変換ing に責任を持ちます。 たとえば HR から取得した属性 LAST_NAME の価値が、IGA プラットフォームのユーザー プロパティ familyName に copied され、それが LDAP 属性 sn に write されることを処理します。 属性対応付け機構は、属性名対応付け、データ形式変換、価値 translation など、データ統合の低レベル詳細をすべて処理します。 この機構は、初期移行、リアルタイム同期、照合、フルフィルメント、分析、エンタイトルメント管理など、常に使われます。

• Expressions は、価値を変換する必要がある場合、またはアルゴリズムの execution に影響を与える必要がある場合に使われます。 式は通常、JavaScript、Groovy、Python などの well-known スクリプト言語を使った非常に短い scripting コードです。 式の最も一般的な利用は、attribute mapping の behavior をカスタマイズし、属性価値がアイデンティティリソースとの間で mapped されるときに変換することです。 しかし式は versatile 機構であり、IGA プラットフォームのさまざまな場所で使われます。 式はロールが付与するエンタイトルメントを 決定し、ABAC 的な動作 を実装できます。 式は承認者や認定者の de解雇、設定の動的 setting、smart ポリシー定義への参加、データ提示とレポートのカスタマイズ、その他さまざまなことに使えます。

• スキーマ管理 機構は、接続された各システム、つまりアイデンティティリソースのデータモデル定義を維持します。 LDAP サーバーが 複数値文字列属性 cn と sn を使うこと、HR システムが 単一値文字列属性 LAST_NAME を持つことなどを知っておくのはスキーマ管理の責任です。 このようなアイデンティティリソースのスキーマは通常、アイデンティティコネクターによって自動的に 検出されます。 スキーマ管理は extension 属性、つまりデータモデルカスタマイズの一部として IGA プラットフォームで定義された属性も維持します。 一部の IGA プラットフォームは完全に "schemaless" でスキーマ管理をまったく持ちませんが、一貫していて保守可能なシステムを 構築するにはスキーマ管理が通常不可欠です。

• アイデンティティコネクター は、アイデンティティリソース、ソース と 対象システムへの connection を facilitate する小さな統合コードです。 アイデンティティコネクターは通常 IGA プラットフォーム上で run し、ネットワーク経由でアイデンティティリソースにリモートからアクセスします。ただし一部の IGA プラットフォームは、アイデンティティリソースシステムに install しなければならないエージェントをまだ使っています。 コネクターはアカウントやグループなどのオブジェクトを read、作成、更新、削除 (CRUD) する操作を initiate する責任を持ちます。 コネクターはスキーマ 検出プロセスも 仲介 し、同期機構に 連携し、プロビジョニングスクリプトを 実行し、類似の補助操作に参加します。 純粋な形式では、アイデンティティコネクターは本質的にプロトコル適応er であり、IGA プラットフォームの操作を interpret し、それをアイデンティティリソース上で標準のプロトコル、LDAP、SQL、HTTP などを使って 実行します。 コネクターは通常システムに directly アクセスし、標準の形式の unフィルタリング情報を取得して解釈します。 この直接アクセスはデータ fidelity を維持し、データが authentic かつ完全であることを確認するために重要です。 この authenticity は孤立したアカウント検知、エンタイトルメント管理、ロールマイニングなどにとって不可欠 側面 です。

• カスタマイズ機構は、ほぼすべての IGA 導入に必要な部分です。 現在の動向は業務プロセスを技術に合わせる方向に傾いていますが、それでも各組織ごとに IGA 導入をカスタマイズする必要性は残ります。 組織はそれぞれ異なり、アイデンティティ管理は組織上の fabric の奥深くまで入り込みます。 プロセスを standardize することは一般に良い考え方ですが、IGA プラットフォームのある程度のカスタマイズは避けられません。 したがって、すべての IGA プラットフォームは多かれ少なかれ カスタマイズ可能 です。 Behavior を適応でき、ポリシーを設定でき、データフロー を adjust でき、データモデルを extend でき、多くの IGA プラットフォームではユーザーインターフェイスもある程度カスタマイズできます。

• サービス (API) と 統合 は、IGA プラットフォームが他の IT infrastructure システムと 連携するための不可欠機構です。 ほぼすべての IGA プラットフォームは、機能を network-accessible インターフェイス、通常は HTTP-based RESTful サービスの形式で expose します。 Exposed API の機能は IGA 製品ごとに異なります。 一部の製品は API-first 方法に基づき、すべての機能を API で expose します。 一方で、ほとんど何の機能も expose しない製品もあります。 大半の IGA 製品はその中間です。 API はプラットフォームの不可欠部分です。 IGA は infrastructure の一部であり、アプリケーションではありません。 したがって IGA は IT プラットフォームに統合される必要があります。 統合の一方の "side" は、アイデンティティコネクターの形式で IGA プラットフォーム自身によって facilitate されます。 しかしもう一方の "side"、つまり API を使って IGA プラットフォームの機能にアクセスする他のアプリケーションやサービスもあります。 したがって API は可用で、reasonable feature-complete で、stable で、well 文書化 でなければなりません。

• ログ記録 と diagnostics は IGA プラットフォームの操作に不可欠です。 IGA プラットフォームは多くの要件に適応し、多様なポリシーと設定をサポートし、多数のサードパーティシステムに接続 しなければなりません。 したがってプラットフォーム自体、特にプラットフォーム設定はほぼ確実に複雑です。 設定を最初の試行で機能させることはほぼ不可能であり、設定は常に新しい要件に合わせて変更・適応する必要があります。 したがって、IGA プラットフォームの良い diagnostic と troubleshooting 機能はソリューションの長期維持管理に絶対的に不可欠です。 構成要素レベルと severity レベルの両方で構造化された comprehensive ログ記録機能は絶対的に不可欠です。 データ内の特定の変更の影響、またはポリシー変更の影響をシミュレートまたは "preview" できる機能も非常に歓迎されます。さまざまな性能 probe や counter も同様です。 残念ながら、多くの IGA プラットフォームは非常に limited な diagnostic 機能しか提供しておらず、IGA 導入と維持管理を極めて負荷が高くにしています。

関連機能

• アクセス制御評価 と 強制、たとえば RBAC/ABAC 評価 と 強制。 IGA はロールベースのアクセス制御 (RBAC) や attribute-based アクセス制御 (ABAC) など、アクセス制御ポリシーの定義と維持管理に関係します。 ロール定義、ロール構造、さらには attribute-based ポリシーの定義も通常 IGA の重要な部分と見なされます。 IGA プラットフォームは通常ポリシー管理 点 (PAP) 機能を実装します。 しかし厳密に言えば、ポリシーの評価と強制は IGA の一部ではありません。 ポリシー、ABAC や RBAC の強制は通常、アプリケーションや infrastructure 構成要素内のポリシー判断 点 (PDP) とポリシー強制 点 (PEP) によって行われます。

• 組織構造管理 は、small でも big でも、ほぼすべての組織にとって crucial 機能です。 組織構造情報は多くの IGA 機能とプロセスに不可欠です。 厳密に言えば、組織上の管理は IGA の一部では なく、IGA ソリューションは組織上の情報を use するだけであるべきです。 組織構造情報は人事（HR）システムなどの専用システムで作成済み と 維持管理されるべきです。 しかし、あまりに多くの組織が組織構造について完全で一貫した機械処理可能な情報を持っていません。 組織構造情報が専用システムで維持管理されているケースでさえ、適切なフィードバックサイクル が欠けています。 組織構造情報は通常、それが作成されたシステム内でしか使われず、業務プロセスや機能における現実世界の検証 の対象になりません。 組織構造データを必要とする他の情報システムは、official 組織構造ソースが提供する形式と異なる、partial 情報だけを必要とすることがよくあります。 したがって組織構造情報はアプリケーション内で手作業で維持管理されることがよくあります。 IGA プラットフォームはおそらく、その情報を同期、比較、検証しようとする最初のシステムであり、フィードバックサイクル を完成させ、実質的に組織構造管理に参加します。

• 個人データ保護 はアイデンティティガバナンスと密接に関連しています。 まだアイデンティティガバナンスおよび管理の一部として形式的に認識されてはいませんが、IGA の多くの 側面 に浸透しています。 GDPR などのデータ保護 とプライバシーフレームワークは、法的根拠 がある場合にのみ個人データをプロセスできると定めています。 したがって処理 basis は、アイデンティティごと、さらにはデータ項目ごとに individually tracking されなければなりません。 これは柔軟情報環境では簡単な作業ではありません。さまざまなアイデンティティ種類が混在し、1つのアイデンティティが多くの目的やロールに使われることが多いからです。 同意は可能な処理根拠 の1つです。 しばしば誤用されますが、ユーザーがいつでも consent を revoke できる可能性を考慮し、consent 情報は厳密に tracked される必要があります。 処理根拠 に加えて、個人データの 来歴 も追跡されなければならず、個人データの 移転、特に他の組織や国への移転 は制御される必要があります。 データは不要になった時点で消去 されなければなりません。

関連項目

• アイデンティティおよびアクセス管理

• https://docs.evolveum.com/glossary/