Skip to content

アクセス管理とプロビジョニング

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

アイデンティティプロビジョニング は、もともとエンタープライズアカウント同期とアイデンティティ関連業務プロセスの管理のために設計された技術です。 この技術はエンタープライズ環境で生まれましたが、すぐにはるかに広い適用可能性を持つことが明らかになりました。 今日では、何らかのアイデンティティプロビジョニング構成要素なしに完全になり得るアイデンティティ関連ソリューションを見つけることはほぼ 困難 です。 しかし、この事実を 認識せず、部分的なアイデンティティ管理ソリューションを導入しようとして失敗し続ける エンジニアはまだかなりの数存在します。 この方法は、プロビジョニング技術が 信頼できない と 高額だった2000年代には正当化できたかもしれません。 しかし今日では、アイデンティティ管理ソリューションからプロビジョニング技術を omit する excuse はありません。 次の paragraph でその理由を説明します。

何が問題なのか

非常に多くのアイデンティティ管理ソリューションはアクセス管理技術に基づいています。 これにはシングルサインオン (SSO) ソリューション、アイデンティティフェデレーション、インターネットの "ユーザー中心" アイデンティティソリューションなどが含まれます。 しかし、ほぼすべてのアクセス管理技術には重要な weakness があります。ユーザープロファイルの transfer です。 これら技術の原則と current 実装は、ユーザープロファイルの transfer が本質的にユーザーがシステムにアクセスすることに結び付けされていることを意味します。結局これは "アクセス管理" だからです。 通常の flow は次のようになります。

  • 手順 1: ユーザーがアプリケーションまたはサービスにアクセスします。
  • 手順 2: アプリケーションはユーザーのセッションを持っていないため、ユーザーは認証サービス、たとえば SSO サーバーまたはアイデンティティプロバイダーに リダイレクトされます。
  • 手順 3: 認証サービスはユーザーを認証し、まだ行われていなければ、トークン を作成します。 このトークンは通常ユーザー識別子を含み、ユーザープロファイルの一部を含む場合もあります。
  • 手順 4: ユーザーは元のアプリケーションに redirected back されます。 トークン参照はリダイレクトされたリクエストの一部です。
  • 手順 5: アプリケーションはトークンを使い、ユーザー識別子とユーザープロファイルの一部を抽出します。 アプリケーションはそのデータを使い、通常どおり動作します。

これは理論です。 しかし実務でもよく使われ、満足できる完全なソリューションとして推奨されることさえあります。 しかし実際には、この方法で満足に対応できるのは非常に単純なアプリケーションだけです。 アイデンティティ関連データに対して本格的な処理を行う必要のないアプリケーションにしか機能しません。 一方で本格的なアプリケーションの大多数は、ユーザープロファイルの少なくとも一部をローカルに保存する必要があります。 アプリケーションがそうする必要がある 理由は多数あります。 おそらく最も 差し迫った要件は次のとおりです。

  • 通知. 特定イベントについてユーザーに通知する メールメッセージや SMS などです。 そのようなイベントは非同期に発生し、イベントが起きた時点でユーザーがアプリケーションにアクセスしていない場合があります。 したがってユーザープロファイルはアクセス管理システムから アクセスできないかもしれません。 そのためアプリケーションはユーザープロファイルの一部をローカルに保存するか、ユーザープロファイルを維持するデータベースへの非同期アクセスを持つ必要があります。 エンタープライズ環境ではこれは通常ディレクトリサービス、たとえば LDAP であり、すぐに利用可能である可能性があります。 しかし一部の、典型的には 古いアプリケーションでは統合が複雑になることがあります。 ただしフェデレーションや他のインターネットベースソリューションでは、この問題ははるかに顕著です。 通常そのようなディレクトリサービスはなく、唯一の選択肢はアプリケーション側 にユーザープロファイルの一部をストアすることです。
  • レポート。 ユーザーのフルネームを含む最も単純なレポートでさえ、プロファイルデータのローカル保存場所を必要とします。 フルネームはレポートに入る他のデータと同じデータベースに保存される必要があります。そうでなければレポートは本当に効率的にはなりません。 このケースではディレクトリサービス (LDAP) の利用でさえ通常問題外です。 何らかのデータ同期手法に頼らずに、通常のリレーショナルデータとディレクトリサービスのデータの間で効率的なデータ "join" を行うことはほぼ 困難 です。
  • 統合複雑性。 アイデンティティおよびアクセス管理 (IAM) はそれ自体のために存在するわけではありません。 IAM の目的は other アプリケーションを効率的に機能させることです。 しかし変更が難しいアプリケーションは非常に多数あります。 典型的な業務アプリケーションはリレーショナルデータベースの上に構築され、すべてのデータが同じデータ保存場所に保存されることを 期待します。 ユーザープロファイルデータを分離し、それでも同じ性能、拡張性、セキュリティ、その他システム品質を維持することはしばしば 困難 です。 そしてこれが通常のケースです。 理論上、データの一部をリレーショナルデータベースに、別の部分をディレクトリサービス (LDAP) にストアしてもシステム品質を損なわないケースがあるかもしれません。 しかし、あまりに多くのアプリケーションがデータベース層 の上に直接構築されているため、アプリケーションアーキテクチャへの 根本的な変更が必要になり、実装は非常に困難です。 そのような変更はほぼ常に 経済的に実行困難 です。

実践的な経験は、本格的なアプリケーションの大多数がユーザープロファイルの一部をローカルに保存する必要があることを明確に示しています。 アプリケーションはそれなしには効率的に作業できません。 したがって、上記のアクセス管理フロー には通常もう1つの手順があります。

  • 手順 6: アプリケーションはユーザープロファイルの関連する部分をローカルデータベースにストアします。 ユーザーのプロファイルがすでに存在する場合、そのプロファイルは更新されます。

この方法は 一見すると問題を解決します。 非常に広い範囲 のアプリケーションに 適用可能な満足できるソリューションに見えます。 ベストプラクティスとして推奨されることさえあります。 しかし現実にはいくつかの 驚き があります。

この "on demand" ユーザープロファイル管理を行うシステムは、初期導入後には実際に非常にうまく機能することがあります。 これが、この方法がこれほど頻繁に利用・推奨される理由です。 しかし導入からしばらくすると、状況は悪化し始めます。 Critical 課題が appear し始めます。 問題の主な原因はユーザープロファイルのオンデマンド同期であり、これは完全とは程遠いものです。 実際には real ソリューションより "hack" に近いものです。 そのような同期はユーザーがシステムにアクセスしたときだけ発生します。 したがってシステムに初めてアクセスするユーザーに対しては非常によく機能します。 これは導入時にそのようなシステムが非常によく機能する理由を説明します。すべてのユーザーが初めてアクセスしているからです。 またユーザーがシステムに頻繁にアクセスしている場合も許容できるに機能します。 Frequent アクセスは、システムが tested されるときや pilot 導入中に典型的に起きることです。 したがって課題はかなり長い間 undetected であり、そのようなシステムはすべての テスト を flying colors で pass することがあります。 しかしシステムライフサイクルの後半、ユーザー visit の間隔が長くなると課題が appear し始めます。 同期は頻度が低くになり、データはすぐ古くになります。 ユーザーフルネームのような無害なデータ項目でさえ、驚くほど頻繁に変わります。 毎日 何千件もの結婚があり、そのそれぞれがユーザーフルネームの変更につながる可能性があります。 そして wedding は個々のの life では still quite rare イベントです。 電話番号、メールアドレス、住所、所在地、組織上の所属の変更ははるかに頻繁です。 ユーザープロファイルは 平均 エンジニア が想像するよりはるかに動的です。 Locally stored ユーザープロファイルデータは驚くほど迅速に古くなったになります。 通常運用状況では、これは通常数か月や数年ではなく数日や数週間の問題です。

ローカルに保存されたデータが古くなると、多くの 深刻な問題が appear します。

  • Un信頼できる通知。 通知サービスは locally stored ユーザープロファイルから contact 情報を取得します。 ユーザーがシステムにあまり頻繁にアクセスしない場合、ユーザープロファイルのローカルコピーは deteriorate します。 通知は古い address や 電話番号に sent され、通知システムはほとんど 役に立たなく になります。 この問題は、マーケティング志向のアプリケーション、公益事業分野の多くのアプリケーション、eGovernment アプリケーションなど、頻繁に訪問されないアプリケーションで特に問題です。
  • データ deformation。 レポートや類似の一括データ処理は、ローカル保存されたデータを使う以外に実践的な選択肢がありません。 ユーザープロファイルが locally 保存されている場合、レポートは日々 ますます変形 になります。 レポートは最終的に古くなったデータに基づくため completely 役に立たなく になります。 そのようなレポート facility は 時間と費用の明らかな無駄です。

  • デプロビジョニング問題。 これは疑いなくアクセス管理技術の最も severe な問題です。 アクセス管理技術はユーザープロファイルを on demand に作成し、何らかの形で imperfect に最新に保つことはできます。 しかし情報を削除する "純粋な" な方法はまったくありません。 更新は常にユーザーがシステムにアクセスすることに結び付けられています。だからこそ "アクセス 管理" です。 しかしユーザーが元のシステム、たとえば中央ディレクトリサービスやアイデンティティプロバイダーで削除された場合、もはやアクセスはありません。 存在しないユーザーはシステムにアクセスできず、したがって自分が削除されたという情報を伝達できません。 In有効なユーザープロファイルのローカルコピーは、systematic に クリーンアップする方法がないまま残ります。 これが多くの 深刻な問題の原因です。

    • Impact on 性能。 アプリケーションに 有効なユーザープロファイルより in有効なユーザープロファイルの方が多いことは珍しくありません。 現代のアプリケーションとデータベースはスケーラブルであるよう構築されています。 しかし拡張性とはシステムリソース consumption がシステム utilization に proportional に高めることを意味し、まったく高めるしないことではありません。 そのような "不要なデータ" は、システムがスケーラブルであってもシステム性能に深刻な影響を与えることがあります。
    • セキュリティ。 アクセス管理技術はアプリケーションの主認証方法を置き換えることがよくあります。 したがってユーザー記録が元のデータストアから 削除d されると、そのユーザーはもはや認証できません。 これは許容できるソリューションと見なされることがよくあります。 しかし多くのアプリケーションにはユーザーが有効化できる二次認証機構があります。 これはさまざまな "remember me" 機能、セキュリティ質問、SSH キーから永続アクセストークン、OAuth やモバイルデバイス向けトークンなどに及びます。 一部のアプリケーションにはレガシー認証方法を完全に無効化する選択肢さえありません。 したがってユーザーの主認証が無効化されても、ユーザーは二次認証機構を使ってシステムにアクセスできる場合があります。 ユーザープロファイルがすべてのアプリケーションから 完全に削除d されない限り、セキュリティリスクはまだ残ります。
    • 個人データ保護とプライバシー。 ユーザープライバシーを尊重するすべての業務は、ユーザーがすべてのデータストアから自分のデータを completely wipe できるようにします。 この要件の一部は legislation によっても与えられています。 しかしこれはアクセス管理技術だけではできません。 ユーザープロファイルの 断片 は多くのアプリケーションに 分散しており、データがどこに 存在しているかの 一覧がない場合があります。 したがって中央ユーザープロファイルが削除されたとしても、ユーザー情報の痕跡が残ります。 これはプライバシーのベストプラクティスへの明確な違反であり、適用法令や規制への違反にさえなり得ます。
    • Licensing 費用. 多くのアプリケーションのライセンスとサポートの費用はアプリケーションユーザー数に基づいています。 しかし多数の 非アクティブなアイデンティティがアプリケーションに残ると、ライセンス 費用は 不必要に高く になる可能性があります。 Inactive アイデンティティがアプリケーションに比較的短期間しか残らなくても、これは大きな費用の無駄になり得ます。

これらの問題は、アイデンティティフェデレーションとインターネットベース、ユーザー中心なアイデンティティソリューションにも適用されます。それらも 類似した方法に基づいているからです。 したがって OpenID、SAML、WS-Federation、OAuth、類似技術に基づくソリューションにも同様の論理が適用されます。 "API economy" を形成する非常に広く使われている API にも 類似した問題が適用されます。これらもオンデマンド方式 でユーザープロファイルのコピーを頻繁に作成するからです。

アクセス管理ソリューションの deployer の一部は、これら問題を明らかに awareness しています。 彼らは通常、数か月 inactive なアカウントデータの クリーンアップ などの "hack" で解決しようとします。 しかしそのような手法は通常 非常に信頼できないであり、利用頻度の低いユーザーに 深刻なユーザー不便 を引き起こし、セキュリティリスクとプライバシー懸念への対応もほとんどできません。 ごく少数のケースを除き、そのような "ソリューション" は絶対的に inadequate です。

これら 深刻な問題に関する知識は、エンタープライズソリューションに取り組む エンジニア の間では比較的 広く共有 です。 これら懸念は早くも2006年に文書化 され、一般知識はその日付より前から存在していました。 しかしこれら事実はインターネット指向 環境ではほとんど知られていません。 インターネット指向 技術コミュニティは課題を無視しているようにさえ見えます。

アイデンティティ同期とプロビジョニング

ネットワーク内でデータ重複を避けることは 困難 です。 実際、ネットワーク越しのデータ transfer はすべてコピーを作成します。 そのコピーが ほんの一瞬 だけ存在することもありますが、数か月や数年存在することも珍しくありません。 データのコピーを避けるできない以上、コピーを管理する必要があります。 そしてそれを synchronization と呼びます。データコピーを管理可能な方法で作成、維持、dispose するプロセスです。 すべての identity provisioning システムは、何らかの形でこの概念を中心に構築されています。 Lightweight と elegant なものもあれば、heavyweight cumbersome monster もあります。 しかし、それらは本質的にアイデンティティ関連データを同期します。 基本的には次のように機能します。

  • プロビジョニングシステムは中央ディレクトリサービスやアイデンティティプロバイダーのデータベースなどのアイデンティティ情報ソース、またはソースを継続的に監視します。
  • プロビジョニングシステムは情報ソースの変更を検出します。 その変更をプロビジョニングシステムに pull します。 通常、何をすべきか判断 するためにルールやスクリプトの集合が 実行されます。
  • プロビジョニングシステムは変更を、それが複製されるべきすべてのシステムに replicate します。 アカウントは必要に応じて作成済み、更新、削除されます。
  • プロビジョニングシステムはデータのコピーがどこにあるかを remember します。 これは重要です。 この種のメタデータは、必要に応じてすべてのコピーを 正しく更新するために使えます。 また必要に応じてデータを削除するためにも使われます。

これはアクセス管理技術で使われる手法とは 根本的に異なる な原則です。 イベント駆動ではなくデータ駆動 です。 トリガーはユーザーアクセスではなくデータの変更です。 したがってはるかに信頼できます。 特に信頼性を高めるための照合などの追加手法と組み合わされた場合にはそうです。 一部の 高度なプロビジョニングシステムは自己修復 機能も持ち、問題が 発見されるとすぐデータを修正 できます。 データは同じである必要もありません。 システム間を流れ する際に変換・調整 できます。

アイデンティティ同期は substantial advantage をもたらします。

  • セキュリティ。 ユーザープロファイルが多くのシステムに コピーされても、プロビジョニングシステムはそれらすべてを 追跡します。 すべてのコピーが 記録されます。 データは自動的に維持管理できます。 そしてこれは一貫した ポリシーベースの形 で行えます。 職務分掌などの 高度な セキュリティ概念も容易に 強制できます。 すべてのデータについて知る場所 があるため、そのデータを自動化されたリスク分析に使うことは簡単です。
  • 監査。 プロビジョニングシステムはデータの変更を記録します。変更がどこで 発生し、誰が 引き起こし、どこに 伝播されたかです。 したがってコンプライアンスは より速く、大幅に低コスト になります。
  • 個人データ保護とプライバシー。 データコピーは 記録されます。 したがってプロビジョニングシステムは、必要に応じてすべてのシステムからデータを 完全に削除 できます。 またすべてのシステムのすべてのデータを直ちに更新でき、データ誤りを 修正しやすくすることで 誤解を招くデータや漏えいしたデータの影響を減らせます。
  • 市場投入までの時間。 アプリケーションはデータ同期中 受動的です。 アプリケーションはデータが 取得 または更新されるのを待つだけです。 プロビジョニングシステムが 能動的な部分です。 したがってアプリケーションは通常、ソリューションに統合するために 変更される必要がありません。 プロビジョニングを使ったアプリケーション統合は、アクセス管理技術に基づく技術と比べて より短時間かつ低コストです。

プロビジョニング技術はエンタープライズ、eGovernment、クラウドソリューション内など一部の環境で大きな成功を収めています。 しかしインターネットへ単独で進むことはできません。 そのようなソリューションには アクセス と プロビジョニング の両方の部分が不可欠であることは明らかです。 しかしインターネットベースアイデンティティソリューションが アクセス 部分を持つべきことはかなり広く受け入れられている一方で、プロビジョニング 部分はほぼ常に軽視されています。 しかしそれは不可欠です。 ソリューションはそれなしには完全になり得ません。

過去、プロビジョニングシステムは非常に高額なおもちゃ でした。 そしてその時代の製品の多くはいまだ市場で生き残っています。 しかし新しい製品もあります。 それらは より新しい技術と長年の経験の上に構築されています。 それらはもはや おもちゃではなく、高額でもありません。 一部の新しい製品は 大量のアイデンティティの管理に現実的な業務モデルを持っています。 これらはクラウドソリューションに導入でき、顧客アイデンティティ、ソーシャルネットワークアイデンティティなどを管理するために使えます。 これら製品はインターネット時代のために構築されています。

例: Evolveum midPoint

数年前、インターネット規模に適したソリューションはありませんでした。 プロビジョニングは 厳密にエンタープライズ境界に閉じ込められ され、非常に高額でした。 しかしそれはすべて終わりました。

MidPoint はいくつかあるオープンソースアイデンティティプロビジョニングシステムの1つです。 プロジェクトは数年にわたる非常に 急速な開発 を経て、非常に独自、柔軟、効率的なシステムを作りました。 MidPoint は 次世代 プロビジョニングシステムです。 インターネットが生み出した 軽量技術の上に構築されています。 技術的には 前世代 とほとんど共通点がありません。 しかし midPoint は 前世代 の製品が行ったすべてのこと、そしてそれ以上を 実現するよう設計されています。 MidPoint はクラウド導入、顧客アイデンティティ管理、または同様の大規模導入に特に適した、非常に興味深い価格モデルを備えています。

MidPoint には インターネット 環境に適した機能があります。

  • エンジニアリングと業務の両面での 拡張性。 技術的には、midPoint はデータベース 抽象化レイヤー の上に構築されており、noSQL データベースなどの 非従来型データストア上で実行できます。 ビジネス面では、midPoint はクラウドソリューション、フェデレーション導入、インターネットポータル、サービスプロバイダーなどに非常に適した価格モデルを持っています。
  • 大量のアイデンティティを扱うには 自動化 が不可欠です。 MidPoint はアプリケーション全体への変更の伝播を自動化し、それを迅速かつ効率的に行うよう設計されています。 MidPoint はゼロ管理モード で導入でき、新しいアプリケーションの費用と市場投入までの時間を削減します。 MidPoint は 自己修復 です。データの誤りが 検出されるとすぐ、透過的に修正 できます。
  • REST と SOAP インターフェイスは標準です。 MidPoint インターフェイスはすべての midPoint 機能に対する完全制御を提供します。 したがって midPoint は より大きなソリューションの部分として、または 組み込みシステムとしてさえ使えます。

エンタープライズ に不可欠な機能もあります。

  • 少数のロールだけで 非常に複雑な構造をサポートする Advanced RBAC モデル。 プロビジョニングシステムとして可能な限り ABAC に近いものです。 これは ロール爆発 問題を効率的に避けられます。
  • 組織構造 は midPoint で ネイティブにサポートされています。 これは 委任管理 に使え、他のアプリケーションに容易に同期することもできます。 グループなど他のオブジェクトも同期できます。
  • 豊富なコネクター集合 は既存アプリケーションとの容易な統合を可能にします。 MidPoint は他のいくつかのプロジェクトのコネクターを使うことができ、独自コネクターも追加しています。
  • エンタイトルメント は midPoint によって 直接管理 できます。 MidPoint はグループメンバーシップ、アクセス制御リスト (ACL)、権限、または同様の細粒度エンタイトルメントを管理できます。

MidPoint は 完全な商用サポートを持つ オープンソース システムです。 これは不可欠です。理由は次のとおりです。

  • 経済的実現性 はライセンス費用ゼロと非常に 妥当なサブスクリプション費用によって与えられます。
  • 柔軟性 は midPoint に 本質的に備わっています。 MidPoint 設定は非常に柔軟であり、いくつかの スクリプト言語を midPoint 設定の部分として使えます。 またパートナーが midPoint ソースコードを 変更することも可能 です。 多くのソフトウェアベンダーと異なり、私たちは 変更されたソースコードを持つ midPoint 導入に対してもサポートを提供できます。 パートナーは 萎縮するのではなく力を得られます。
  • 革新的なビジネス が 可能です。 私たちのパートナーは midPoint を使ってクラウドと SaaS 導入を作成しています。 Identity-in-the-box や 事前構成済みソリューションの計画もあります。 MidPoint は他種類のソフトウェアでは単純に現実的ではない業務モデルを許可します。

関連項目