Loading article…
アイデンティティ相関とは、情報システムにおいて、組織全体のシステムやアプリケーションに存在するさまざまなユーザーアカウントログインID（ユーザー名）の適切な所有権を調整および検証するプロセスであり、検証されたすべてのアカウントログインIDに一意の識別子（主キーまたは共通キーとも呼ばれる）を割り当てることで、それらのユーザーアカウントログインIDの所有権を特定の個人に永続的にリンクできます。[1]
ID 相関のプロセスでは、組織のビジネス ポリシー、アクセス制御ポリシー、およびさまざまなアプリケーション要件に従って、ユーザーがアクセスする必要がある適切なシステムとアプリケーションのアカウント ログイン ID のみが個人に付与されていることを検証します。
ID 相関のコンテキストでは、一意の識別子とは、グループおよび特定の目的で使用される識別子の中で一意であることが保証されている識別子です。 3 つの主要なタイプがあり、それぞれ異なる生成戦略に対応しています。
- シリアル番号は段階的に割り当てられます
- 識別されるオブジェクトの最大数（または予想される数）よりもはるかに大きい数空間から選択された乱数。一意ではないものの、このタイプの識別子は多くの実用的なアプリケーションでオブジェクトを識別するのに適しているため、この文脈では「一意」と呼ばれます。
- 名前またはコードは選択によって割り当てられますが、 EPCglobalネットワークのEPC情報サービスなどの中央レジストリを保持することで一意になるように強制されます。
ID 相関の場合、一意の識別子は通常、シリアル番号またはランダム番号です。このコンテキストでは、一意の識別子は通常、特定の各データ ソースに関連付けられたディレクトリ内の追加属性として表されます。ただし、各システム固有のディレクトリに属性を追加すると、組織の要件に応じて、アプリケーションまたは特定のビジネス要件に影響する場合があります。このような状況では、一意の識別子は受け入れられない追加である可能性があります。
アイデンティティ相関の基本要件
アイデンティティ相関にはいくつかの要素が関係します。
複数のシステムやアプリケーション間で異なるアカウント ID をリンクする
多くの組織は、さまざまなアプリケーション ユーザー ID を、それらのユーザー ID に関連付けられている実際の人物にリンクすることを要求する監査に準拠する方法を見つける必要があります。
個人によっては、かなり一般的な名や姓を持っている場合があり、特にそれらのアカウント ログイン ID が一意性を保つために十分な特定の ID データにリンクされていない場合、適切な個人を適切なアカウント ログイン ID にリンクすることが困難になります。
たとえば、ログイン ID の一般的な構成は、givenname の最初の文字 + シリアル番号の次の 7 文字で、一意性が増分されます。これにより、ユーザー John Smith、James Smith、Jack Smith に対してそれぞれ jsmith12、jsmith 13、jsmith14 などのログイン ID が生成されます。
逆に、ある個人が正式または非公式に名前を変更すると、その個人が使用する新しいアカウント ログイン ID の名称が、変更前に取得したアカウント ログイン ID とは大幅に異なるものになる可能性があります。
たとえば、ある女性が結婚して、仕事で新しい姓を使うことにしたとします。彼女の名前が元々 Mary Jones だったが、現在は Mary Smith である場合、彼女は人事部に電話し、連絡先情報と電子メール アドレスを新しい姓で更新するように依頼できます。この依頼により、彼女の Microsoft Exchange ログイン ID は mary. smith に更新され、姓の変更が反映されますが、彼女がアクセスできる他のシステムの情報やログイン資格情報は実際には更新されない可能性があります。この例では、彼女はActive Directoryでは mjones のまま、RACFでは mj5678 のままである可能性があります。
ID の相関関係は、適切なシステム アカウント ログイン ID を、区別がつかない可能性のある個人や、システムごとに見ると大幅に異なるように見える個人にリンクする必要があります。ただし、ID は同一個人に関連付けられている必要があります。
アイデンティティデータにおける意図的および意図的でない矛盾の発見
通常、ID データの不整合は、アプリケーションが追加、削除、または変更されるにつれて組織内で時間の経過とともに発生し、個人が組織に出入りする際に常に変化するアクセス権を取得または保持するにつれて発生します。
アプリケーション ユーザーのログイン ID は、異なるアプリケーションやシステム間で必ずしも一貫した構文を持っているわけではありません。多くのユーザー ログイン ID は、組織内の特定の個人に直接関連付けられるほど具体的ではありません。
ユーザー データの不整合は、手動入力エラー、非標準の命名法、またはすべてのシステムで同じように更新されない可能性のある名前の変更によっても発生する可能性があります。
ID 相関プロセスでは、これらの不一致を考慮して、最初の調査では無関係に思える ID データを関連付ける必要があります。
孤立したアカウントまたは廃止されたアカウントのログイン ID の特定
組織は合併や買収を通じて拡大、統合することができ、ビジネス プロセス、ポリシー、手順の複雑さが増します。
これらのイベントの結果として、ユーザーは組織内の別の部署に異動したり、組織内で新しい役職に就いたり、組織から完全に退出したりします。同時に、追加される新しいアプリケーションごとに、完全に一意の新しいユーザー ID が生成される可能性もあります。
一部の ID は不要になる可能性があり、他の ID はアプリケーション固有のポリシーまたはより広範な部門ポリシーに違反する可能性があります。また、他の ID は人間以外のアカウント ID またはシステム アカウント ID に関連している可能性があり、さらに他の ID は特定のユーザー環境には適用されなくなる可能性があります。
組織のさまざまな部分にまたがるプロジェクトや、複数のアプリケーションに焦点を当てたプロジェクトは、ユーザー ID が適切に整理されなかったり、ビジネス プロセスの変更により無効と認識されたりすることが多く、実装が困難になります。
ID 相関プロセスでは、組織のインフラストラクチャのこのような大幅な変化に属さなくなった孤立したアカウント ID や無効なアカウント ID をすべて識別する必要があります。
適切なアカウントIDによる個人の検証
サーベンス・オクスリー法やグラム・リーチ・ブライリー法などの規制の下では、組織はすべてのシステムにわたって各ユーザーの整合性を確保し、組織内のさまざまなバックエンド システムやアプリケーションに対するユーザーのすべてのアクセスを記録することが求められています。
正しく実装されていれば、ID の相関関係によってコンプライアンスの問題が明らかになります。監査人は、組織に対して、誰がどのリソースにアクセスできるかを説明するよう頻繁に求めます。エンタープライズID 管理ソリューションをまだ完全に実装していない企業では、組織のユーザー ベースの実際の状態を適切に証明するために、ID の相関関係と検証が必要です。
この検証プロセスでは通常、企業全体の観点から組織のユーザー ベースに精通している組織内の個人と、個々のシステムやアプリケーション固有のユーザー ベースに責任を持ち知識のある個人とのやり取りが必要になります。
さらに、検証プロセスの多くは、最終的には、特定の個人に関連付けられた特定の ID データを確認するために、問題の個人と直接通信することが必要になる場合があります。
各システムまたはアプリケーションに固有のプライマリキーまたは共通キーを割り当てる。各個人に付与されるアカウントID
さまざまなコンプライアンスのプレッシャーに応じて、組織はユーザー ベース全体に一意の識別子を導入し、各ユーザーがログイン機能を持つ特定のシステムまたはアプリケーションに属していることを検証できます。
このようなポリシーを実現するには、組織のユーザー ベース全体と各システム固有のユーザー ベースに精通したさまざまな個人が、特定の ID を相互にリンクし、他の ID を相互に切り離す必要があることを検証する責任を負う必要があります。
検証プロセスが完了すると、その個人とそれに関連付けられたシステム固有のアカウント ログイン ID に一意の識別子を割り当てることができます。
異なるアカウントIDをリンクする方法
前述のように、多くの組織では、ユーザーは異なるログイン ID を使用してさまざまなシステムやアプリケーションにサインインすることがあります。これらを「企業全体」のユーザー プロファイルにリンクする理由は多数あります。
この相関関係、つまり「ID マッピング」を実行するための基本的な戦略はいくつかあります。
- アカウント ID が同じであると仮定します。
- この場合、マッピングは簡単です。
- これは、長期間にわたって厳格で標準化されたプロセスを使用して新しいユーザーに ID を割り当ててきた多くの組織で実際に機能します。
- 既存のシステムからマッピング データをインポートします。
- 組織が長期にわたって ID をユーザーにマッピングするための堅牢なプロセスを実装している場合、このデータはすでに利用可能であり、新しいID 管理システムにインポートできます。
- 属性値の完全一致:
- あるシステム上の 1 つ以上の属性と相関する 1 つの ID 属性または属性の組み合わせを検索します。
- 属性が同じユーザーを見つけて、2 つのシステム上の ID を接続します。
- 属性値の近似一致:
- 上記と同じですが、属性または式が完全に一致することを要求するのではなく、ある程度の違いを許容します。
- これにより、スペルミス、大文字小文字の不一致、その他多少異なる名前や類似の ID 値が許可されます。
- ここでのリスクは、接続すべきでないアカウントがこのプロセスによって誤って一致してしまうことです。
- セルフサービスログインID調整:
- ユーザーにフォームに記入してもらい、どのシステムでどの ID を所有しているかを示してもらいます。
- ユーザーは嘘をついたり間違いを犯したりする可能性があるため、たとえばユーザーにパスワードの入力を求めたり、そのパスワードを確認したりすることで、ユーザー入力を検証することが重要です。
- ユーザーはシステム名を認識しない可能性があるため、どのシステムの ID かを指定するようにユーザーに求めるのではなく、代替案を提示するか、ID とパスワードをまとめて要求することが重要です。
- コンサルタントを雇うか、手動で行う:
- それでも、データがどこから来るのかという疑問は残ります。おそらく、問題となっているすべてのユーザーにインタビューすることによってでしょうか?
アイデンティティ相関を実行する際の一般的な障壁
プライバシーに関する懸念
多くの場合、ID データの詳細な調査を必要とするプロセスでは、プライバシーと開示の問題が懸念されます。ID 相関プロセスの一部では、関連する企業ポリシーとアクセス制御に対する一貫性と有効性を確保するために、各特定のデータ ソースを信頼できるデータ ソースと比較する必要があることが推測されます。
企業全体の権威ある HR 関連の ID データの公開を伴うこのような比較では、組織が ID 相関の実施をどのように決定するかに応じて、内部または外部でさまざまな秘密保持契約が必要になります。
権威あるデータは機密性が高く制限されていることが多いため、このような懸念により、ID 相関アクティビティを徹底的かつ十分に実行できなくなる可能性があります。
膨大な時間と労力が必要
ほとんどの組織は、すべてのデータ ソースにわたる ID データ内の不一致と複雑さを理解するのに苦労しています。通常、手動で 2 つの ID データ リストを比較したり、2 つの異なるデータ セット間の一致を見つけるための簡単なスクリプトを実行したりしても、プロセスを正確に、または十分に完了することはできません。組織がそのような作業にフルタイムの担当者を割くことができたとしても、通常、その方法では、ID 関連の監査の一般的な要件を満たすために、十分な割合の無効な ID を公開したり、十分な割合の一致した ID を検証したり、システム (非個人) アカウント ID を特定したりすることはできません。
ID の相関関係を手動で実現するには、多大な時間と人的労力が必要であり、その作業が正常に完了するか、準拠した方法で完了することが保証されません。
このため、最近、ID 相関処理をより簡単に処理できる自動 ID 相関ソリューションが市場に登場しました。
一般的な自動 ID 相関ソリューションの機能には、次の特性が含まれます。
- 複数のデータソース内のアイデンティティの分析と比較
- 任意の 2 つのデータ ソース間のデータ要素の任意の組み合わせに対する柔軟な一致基準の定義と割り当て
- 許可されているすべてのデータソースに直接的または間接的に簡単に接続できます
- すぐに使えるレポートやデータ一致結果の概要
- 一致したデータの組み合わせまたは一致しないデータの組み合わせを手動で上書きする機能
- 詳細なレベルでデータ結果を表示する機能
- 事前に承認された、または手動で検証された一致データに一意の識別子を割り当てます。
- 検証済みのユーザーリストをソースシステムやプロビジョニングソリューションに送り返すエクスポート機能
- データマッピング技術をカスタマイズしてデータの一致を精緻化する機能
- ソリューションに組み込まれたロールベースのアクセス制御により、組織内外のさまざまな個人がデータを読み込み、分析し、検証する際に、ID データの露出を規制します。
- 手動の方法よりも迅速かつ効率的にエンドユーザーに対してIDデータを検証する機能
- 部分的なアイデンティティ抽出による個人のモバイルデバイスからのアイデンティティ属性の収集[2]
- 追跡メカニズムによるウェブサーフィンとソーシャルメディアの行動のプロファイリング[3]
- 問題のユーザーの生体認証測定は、システム間でアイデンティティを相関させることができる[4]
- アイデンティティサイロを横断してアイデンティティ属性を管理およびアクセスする集中型アイデンティティ仲介システム[5]
アイデンティティ相関プロジェクトデリバリーの3つの方法
ID 相関ソリューションは、3 つの異なる配信モデルで実装できます。これらの配信方法は、さまざまな予算と人員要件に対応し、短期および長期のプロジェクト目標とイニシアチブの両方を満たすのに十分な柔軟性を備えたソリューションを提供するように設計されています。
ソフトウェア購入- これは、組織がソフトウェア ライセンスを購入し、独自のハードウェア インフラストラクチャ内でソフトウェアを実行する、従来のソフトウェア購入モデルです。
- トレーニングは利用可能であり、推奨されています
- 設置サービスはオプションです
Identity Correlation as a Service (ICAS) – ICAS はサブスクリプション ベースのサービスであり、クライアントは安全なインフラストラクチャに接続して相関アクティビティをロードおよび実行します。このサービスでは、ハードウェアや関連サポート スタッフを所有および維持することなく、ID 相関ソリューションが提供するすべての機能が提供されます。
ターンキー ID 相関–ターンキー方式では、クライアントはソリューション ベンダーと契約し、必要な ID 相関アクティビティを実行するためにデータを提供する必要があります。完了すると、ソリューション ベンダーは相関データを返し、不一致を特定し、データ整合性レポートを提供します。
検証活動では、企業全体の観点から組織のユーザー ベースの状態を理解している組織内の個人や、各システム固有のユーザー ベースに精通している組織内の個人からの直接的なフィードバックが依然として必要になります。さらに、一部の検証活動では、ユーザー ベース自体の個人からの直接的なフィードバックが必要になる場合があります。
ターンキー ソリューションは、1 回限りのアクティビティとして、または毎月、四半期ごとに、あるいは組織の年間検証アクティビティの一部として実行できます。次のような追加サービスもご利用いただけます。
- データの不一致を解決するためのメールキャンペーン
- 統合またはマージされたリストの生成
参照: 関連トピック
アイデンティティ相関のカテゴリに該当する関連トピックには、次のようなものがあります。
コンプライアンス規制/監査
アイデンティティの管理
アクセス制御
ディレクトリサービス
その他のカテゴリー
- ロールベースのアクセス制御(RBAC)
- 信頼できないネットワーク上の Web アプリケーションに対するユーザー アクセス権の連携
参考文献
- ^ Harris, Shon . 「CISSP 認定オールインワン試験ガイド、第 4 版」(2007 年 11 月 9 日)、McGraw-Hill Osborne Media。
- ^ ローター、フリッチュ;もめん、ヌルル（2017）。 「アプリの権限から生成された派生部分 ID」。 Gesellschaft für Informatik: 117–130。
{{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要です - ^ US 8566866、Fleischman、Michael Ben、「Web ID とソーシャル メディア ID の相関関係」、2013 年 10 月 22 日公開、Bluefin Labs Inc. に譲渡。
- ^ Ng-Kruelle, Grace; Swatman, Paul A.; Hampe, J. Felix; Rebne, Douglas S. (2006). 「欧州連合におけるバイオメトリクスと電子アイデンティティ (電子パスポート): 議論を呼ぶイノベーションの採用に関するエンドユーザーの視点」Journal of Theoretical and Applied Electronic Commerce Research . 1 (2): 12–35. doi : 10.3390/jtaer1020010 . ISSN 0718-1876.
- ^ ブリュッガー、バド P.;ロスナゲル、ハイコ (2016)。ヨーロッパおよびその他の地域向けの分散型アイデンティティ管理エコシステムを目指して。 Gesellschaft für Informatik eV ISBN 978-3-88579-658-9。