Skip to content

アイデンティティリソースへの間接アクセス

この記事は https://docs.evolveum.com/iam/myths/indirect-access/ の翻訳です。

アイデンティティ管理は新しい発明ではありません。 アイデンティティ管理の必要性は、最初のシステム管理者が最初のユーザーアカウントを作成したときに生まれました。 それ以来、アイデンティティ管理は何らかの形で常に存在していました。 多くの組織はすべてを手作業で行い、ticket、作業、エスカレーション、終わりのない misunderstanding の海に沈んでいました。 一部の組織は do-it-yourself 方法を試し、homebrew アイデンティティ管理ソリューションを開発しましたが、何年ものうちにそのコードが un保守可能 な mess に変異したことに気づいただけでした。 他の組織は、2000年代に技術 giant が販売していた 過度に複雑な なアイデンティティプロビジョニング製品を導入しようとし、何年も consultant の army を雇った末に、完全に mediocre な結果を得ました。 多くのソリューションは解決した問題より多くの問題を生みましたが、誰もが何かをしなければなりません。 そうしなければ業務は 運用できないからです。

ツールや方法にかかわらず、アイデンティティ管理問題に対する何らかのソリューションは常に存在していました。 したがって、新しいアイデンティティ管理導入が本当にゼロベースから始まることはありません。 常に既存の プロセス、ツール、スクリプト、データベース表、view、spreadsheet、そして mindset があります。 既存ソリューションからできるだけ多くの部分を 再利用 したくなるのは自然です。 そのような 再利用 は確かに実装労力を 削減し、組織内の文化的変化の範囲を抑え、すべてをより扱いやすくします。 最も抵抗の少ない道 に従うことは常に良い考え方です。

本当にそうでしょうか。

書き込み専用

どのシステムでも最悪の問題は、非常に初期の段階に origin があります。 いいえ、最悪の問題を引き起こすのはシステムの design ではありません。 最も痛ましいな誤りは、最初の設計図が描かれる前に起こります。 問題はシステムが poorly 設計・構築されることではありません。 問題は、完全に間違ったシステムが構築されることです。 問題は通常 必要とments、つまりどのシステムが必要かの仕様化にあります。

2000年代初期以降に設計・構築されたアイデンティティ管理システムは、アイデンティティ管理分野の一部、プロビジョニングに重点を置いていました。 新しい従業員のアカウントを作成する必要があります。 新しい職務責任を持つユーザーに新しい権限を迅速に付与する必要があります。 新しいアプリケーションを導入し、すべてのユーザーのアカウントを作成する必要があります。 すべてはアカウント作成、アクセス enabling、権限 granting の話でした。 デプロビジョニングについての考えも多少はありました。 しかしデプロビジョニングは 必要悪、過度に疑り深いセキュリティ担当者から来る厄介な要件と見なされていました。 デプロビジョニングがあったとしても、それは従業員が退職したときにアカウントを削除することだけでした。 権限取り消し、監査、可視性、情報セキュリティのベストプラクティスについての 考慮 はほぼゼロでした。 それは「誰か別の人の問題」でした。 個人データ保護 については、企業 IT に関する限り、個人データは 収益化するものであり、保護するものではありませんでした。 それが2000年代の life であり、ある程度は2010年代も同じでした。 これがアイデンティティ管理ソリューションへの要件でした。 アイデンティティ管理ソリューションが期待されたことを行ったのは、さほど驚きではないかもしれません。 それらは write-only システムとして設計されました。

初期のアイデンティティ管理ソリューションは、すべてのアプリケーションに 伝播されるべき 絶対的に信頼できる真実 が存在するという 前提 に基づいて構築されていました。 多くのソリューションは次のような単純スクリプトに基づいていました。

  1. 人事（HR）システムからデータを取得する。 データを CSV ファイルまたは単純データベース表にストアする。

  2. 単純 string 操作または単純 SQL query を使ってデータを変換する。

  3. アプリケーションデータベースとディレクトリにデータを up負荷し、古いデータをすべて over書き込む。

このプロセスは毎日、または毎時間 repeated されました。 ある程度は機能しました。 しかし、最初の run でさえいくつかの問題を明らかにしました。 デプロビジョニングに関しては、単純な上書き では不十分です。 既存アカウントはすべてまず削除されなければなりません。 ただし、すべてのアカウントを単純に削除することはできません。 管理アカウントとアプリケーションアカウントは残さなければなりません。 したがって、それらは whitelist に追加され、今日までそこに残っています。 さらに、アカウントを削除してすぐ 再作成 するのはあまり効率的ではなく、アカウントが存在しない 期間 を残し、アカウント削除が複雑な プロセスであるシステムでは使えません。 単純な上書き はより複雑な ロジックを使って 再実装 されなければなりませんが、それでもどうにか機能しました。 その後、実際には信頼できる単一ソース が存在しないことが判明しました。 ほぼ信頼できるが完全ではない情報ソースがいくつかあり、それらを比較、マージ、選択、後処理 する必要があります。 そのためスクリプトはより複雑で複雑で整理されていないになり、それでも 根本問題は解決されませんでした。

フィードバック

Vernacular アイデンティティ管理スクリプトは特定の目的のために設計され、その目的ではうまく機能しました。 それらは通常データベース表または CSV ファイルの形で、アイデンティティの単純な "統合された" view を含んでいました。 Target 環境に関する知識もスクリプトに大量に hardcoded されています。 それらを新しいアイデンティティガバナンスソリューションで 再利用 するのは非常に魅力的な選択肢かもしれません。 ディレクトリサービス構造の複雑で整理されていない詳細 すべてに対処する代わりに SQL insert を行えば、古き良きスクリプトがすべての作業を行います。

まあ、それは機能もしますし、機能しないとも言えます。

書き込み専用システムの問題の根本 は、もちろんフィードバック の欠如です。 Vernacular アイデンティティ管理スクリプトはデータを書き込むことは得意でした。 しかし、情報を 取得・分析するようには設計されていませんでした。 それらは LDAP サーバーにアカウントが存在すると確信していました。たった今それを作成したからです。 すべてのアカウントを 一覧表示する必要はありませんでした。 すべての属性を取得する必要はありませんでした。 LDAP サーバーの状態を確認する必要もありませんでした。

しかしアイデンティティガバナンスシステムは、すべてのアカウントを一覧化し、属性を取得し、アカウントの状態を確認する必要があります。 それはアイデンティティガバナンスの主な責任の1つです。 それ以上に、ガバナンスシステムはすべてのエンタイトルメントを取得し、分析する必要があります。興味深いメタデータや文脈があるかもしれず、対象システムによって割り当てられた識別子があるかもしれず、ガバナンスシステムが必要とするデータは非常に多いのです。 間接プロビジョニングのための write-only システムは、そのどれも提供しません。

アイデンティティガバナンスおよび管理 (IGA) は フィードバック がすべてです。 IGA プラットフォームはアカウントを作成、更新、削除しますが、データを read する必要もあります。 典型的なプロセスはアカウントを作成し、それを read back することです。 対象システムは entryUUID や GUID などの永続的な識別子を割り当てる場合があり、自動的に割り当てられるエンタイトルメントがある場合もあります。 さらに重要なのは、IGA プラットフォームがすべてのアカウントを list と scan し、自分が知らないアカウント、誰にも属していないアカウント、つまり孤立したアカウント、不適切なエンタイトルメントを持つアカウントなどを特定する必要があることです。 情報取得は、情報を書き込む能力よりもさらに重要です。

再利用するべきか、しないべきか

既存ソリューションの reuse は非常に魅力的な選択肢かもしれません。 プロジェクトマネージャーは時間 と 費用の saving と見るかもしれず、エンジニアは既存ソリューションで既に対処済みの複雑で整理されていない詳細を避けたいと思うかもしれず、あるいは単に「いつもそうしてきた」という sentiment があるかもしれません。 どれほど魅力的でも、すべての選択肢を careful に consider するのは常に良い考え方です。

  • 既存ソリューションは単純スクリプトかもしれません。その場合、体系的な IGA ソリューションで置き換えるのは非常に easy であるべきです。 古いソリューションを破棄し、直ちに新しいソリューションで置き換えることが、おそらくここでは最善の選択肢です。
  • より可能性が高いのは、既存ソリューションが entangled スクリプト、SQL query、手順 の labyrinth であり、それを作った人々は別作業に再割り当てed されていたり retired していたりすることです。 そこには明らかに大量の ドメイン知識が ハードコード されていますが、同時に 巨大な技術的負債 もあります。 古いソリューションを置き換えることが明らかに最善の選択肢です。 大きな問題は、それを どのように 置き換えるか、そして いつ 行うかです。

同じアルゴリズムを新しい IGA プラットフォームで 再実装 することは、確かに選択肢です。 しかし 文書化されていない スクリプトの maze を分析するには years かかる可能性があります。 さらに、historic reason によって作られた部分、temporary ソリューション、または現在ではまったく意味を持たない部分が存在する可能性があります。 これは現実的な選択肢であることはまれで、まして良い選択肢ではありません。

より良い選択肢は、古いソリューションにしばらくプロビジョニングを続けさせることです。 その間に、IGA プラットフォームを対象システムに直接接続します。ただし read のためだけです。 IGA プラットフォームにデータを read させ、アイデンティティを相関付けし、データを分析させます。 これは エンジニア が結果がどう見えるべきかを学ぶために使えます。 これに既存ソリューション、業務要件、プロセスの分析を補います。 これは最終的に古いスクリプトの寄せ集めを置き換えられる機能するソリューションにつながる可能性が高いです。

  • 場合によっては、状況はさらに複雑です。 インフラの一部を管理するために、専用のアイデンティティ管理システムが使われていることがあります。 このようなソリューションは Microsoft や SAP システムの pocket に見られ、複雑 entangled 導入の管理に専用されています。 そのようなプラットフォームは ドメイン知識で saturated しており、しばしば 独自 と 文書化されていない 技術に依存しています。 ソリューションには specialized、そして高額な構成要素が存在することが多く、その一部は obsolete で upgrade 困難 である可能性があります。 このようなソリューションには巨大な burning letters で "ベンダーロックイン" と書かれているため、置き換えは簡単ではありません。

正直なところ、そのようなベンダーロックイン状況 には良い選択肢はありません。 おそらく唯一現実的な選択肢は、当面ソリューションを keep することです。 しかし IGA プラットフォームは 囲い の中で何が起こっているかを 監視するために使えます。 IGA プラットフォームは Active Directory インスタンス や SAP サーバーに直接接続され、アカウント、グループ、ロールを 監視できます。 少なくとも 孤立したアカウントは 検出できるはずです。 IGA プラットフォームは、グループ ownership の管理、ロールマイニング機能、アイデンティティデータの 汎用 分析など、独自 アイデンティティ管理ツールに通常欠けている機能を提供できる場合があります。

Proprietary ソリューションのベンダーは、システムに直接に接続するのではなく、彼らのアイデンティティ管理ソリューションの "aggregated" view からデータを取るよう説得しようとするかもしれません。 これは通常、IGA 目的には労力に値しません。 Intermediary である 独自 aggregator が提供する情報の fidelity には疑問があります。 それはおそらくフィルタリングされ、古くであり、そのデータの信頼性は問題able です。 個々のシステムに直接接続し、一次の信頼できる情報を得る方がはるかに良い考え方です。 特に Active Directory のような ビジネスクリティカルなシステムではそうです。

手作業プロビジョニング

間接アクセスによって引き起こされる問題には、基盤となる技術はまったく異なるものの、もう1つの whole dimension があります。 Traditionally、アイデンティティ管理労力の大きな部分は手作業です。 アカウントはシステム管理者によって手作業で作成され、エンタイトルメントは 汎用チケットシステムを使って 申請され、運用者によって手作業で割り当てられ、パスワードはヘルプデスクエージェントによって リセットされます。 アイデンティティ管理 (IDM) プラットフォームが導入されると、その作業の一部は自動化されます。 しかし常に制約があります。 IDM プロジェクトはほぼ常に資金不足であり、フォローアップ活動はほぼ常に人員不足です。 したがって組織内の一部システムは IDM プラットフォームに直接接続されません。 そのようなシステムを管理するために手作業管理がまだ使われます。ただし今では ticket はユーザーではなく IDM システムによって作成されます。

この方法は、正しく使われるなら根本的に間違っているわけではありません。 確かに IDM システムに自動的に接続する労力に値しないシステムは存在します。 それは、少数のユーザーしかアクセスできず、fluctuation がほぼない非常に specialized なアプリケーションかもしれません。 来年廃止 される予定の obsolete システムかもしれません。 手作業アイデンティティ管理には valid ケースがあります。 しかし多くの場合、手作業アイデンティティ管理は大幅に over-used されています。

全自動アイデンティティコネクターの開発は簡単 でも安価でもありません。 実際にはコネクターは通常かなり小さなコード片 であり、何をすべきか知っている開発者なら非常に迅速に開発できます。 問題は、何をすべきかを知ることです。 開発者は対象システムがどう機能するかを知り、インターフェイス、手順、制約、対象システムの 特性 を学ぶ必要があります。 それには時間がかかります。 そしてコネクターが うまく機能するまで、大量の テスト、バグ修正、手戻り があります。 コネクターは維持管理を必要とし、対象システムが upgraded されると更新が必要になる場合があります。 コネクターは比較的小さく単純なコード片 ですが、それでもコードです。 開発労力と長期維持管理が必要です。 安価ではありません。

しかしコネクターを develop しない費用も consider しなければなりません。 特定システムへのコネクターがない場合、手作業プロビジョニング、より正確には手作業フルフィルメントが次善策です。 それにはシステム管理者がアカウントを作成する時間などの費用が associated します。 しかしこれは real 費用のほんの一部です。 手作業プロビジョニングの問題は、それが実質的に write-only システムであることです。 IDM システムは ticket を作成しますが、対象システムで実際に何が起きたかを知りませんし、確認する方法もありません。 したがって IDM システムは監査をサポートするために使えず、監査は20世紀式に手作業で行う必要があります。 孤立アカウントなどのセキュリティリスクが存在する可能性は非常に高いです。 孤立アカウントは驚くほど簡単に作られます。 削除されなかった テスト アカウントかもしれず、管理者が間違ったアカウントを削除済みしたのかもしれず、あるいはシステムが backup から 復元され、削除操作が実質的に ロールバック されたのかもしれません。 対象システムへの可視性が非常に limited であることは、misunderstanding、多くの call と会議で無駄に される時間のソースになりがちです。 しかし、おそらく最悪の 影響は意味のある分析がまったくないことです。 IDM システムは対象システムの中を見られないため、データを分析できません。 警告を出せず、ロールマイニングの実践的な方法はなく、システム設定は決して改善しません。 データ保護 ポリシーを自動化することも困難です。 そのシステムは負債となり、他のすべてのアイデンティティ管理とガバナンス活動を引き下げます。 費用は積み上がります。

特に IAM プログラムの 初期 では、すべてのシステムにコネクターを作成することはできないかもしれません。 しかし midPoint など一部の IDM システムは、半手作業 コネクターを使う能力を提供します。 Semi-manual コネクターは、システム管理者用の ticket を作成することでプロビジョニング活動を手作業で行います。 しかし対象システムからデータを自動的に read できます。 Semi-manual コネクターは対象システム内のデータベース表に直接に接続することがあります。 より多くの場合、コネクターは対象システムからエクスポートed された CSV ファイルからデータを読み取ります。 どちらにせよデータは自動、ただし scripted な方法で IDM システムに delivered されます。 IDM システムはデータをポリシーと比較し、孤立したアカウントやその他ポリシー違反を検出できます。 また 運用者 がアカウントの作成・更新・削除時に行った誤りを検出し、その誤りを修正する ticket を直ちに作成できます。 簡単に言えば、欠落したフィードバックループ を提供します。

Semi-manual 方法は temporary ソリューションになる場合も、小規模システムでは permanent ソリューションになる場合もあります。 これは通常 低コストソリューションであるため、使わない 正当な理由 はほとんどありません。

しかし重要なシステム、変更 rate が高いシステム、または複雑な セキュリティモデルを持つシステムには、real コネクターの substitute はありません。 Real fully-automatic コネクターを今実装できない場合は、future の計画を立ててください。

  • 後でコネクターを develop する計画を立てる。
  • アプリケーションを改善し、SSO システム、LDAP や Active Directory などのアイデンティティデータストアに接続する、またはアプリケーションを間接的に管理できる認証/認可フレームワークを使う計画を立てる。
  • アプリケーションを置き換える計画を立てる。 適切に管理できず、改善することもできないアプリケーションは効果ではなく負債です。 それは常に trouble-maker になります。 早くなくなるほど良いです。

関連項目