Skip to content

初心者向けアイデンティティガバナンスおよび管理

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

この「IGA」とは何か

アイデンティティガバナンスおよび管理 (IGA)、別名 アイデンティティ管理 (IDM) は、アイデンティティおよびアクセス管理 (IAM) の分野です。 簡単に言えば、IGA ソフトウェアは、新しい従業員が会社に join したとき、責任が変わったとき、会社を退職したとき、新しい請負業者が enrolled されたときなどに発生する技術的な、つまり IT 作業を処理します。 これは "アイデンティティライフサイクル" と呼ばれます。すべての "アイデンティティ" が必要なものを持つようにするイベントと作業の集合です。 アイデンティティ管理は、アカウントの作成、適切なグループと権限の割り当て、パスワードの設定と reset など、アイデンティティライフサイクルの "技術的な詳細" を処理します。 アイデンティティ管理の目的は、可能な限り 自動化 し、運用費用を削減し、セキュリティを改善することです。

アイデンティティ管理は通常、中規模から大規模のエンタープライズで非常に useful です。 IDM システムは通常、従業員に関する情報を人事（HR）システムから取得します。 たとえば新しい従業員が HR システムに入力されると、IDM システムはそれを検出して情報を pull します。 この情報は、各ユーザーが持つべきロール集合を 判断 するために 処理されます。 ロールはユーザーがどのアカウントを持つべきかを 決定し、そのアカウントが作成されます。 これらすべては通常、数秒で行われます。 したがってユーザーが first day から作業できるよう、すべてが prepared されます。 同様のプロセスは、ユーザーが別 部門 に transferred されたとき、責任が変わったとき、会社を退職したときにも適用されます。 特に後者は重要です。 IDM システムは従業員のために作成されたすべてのアカウントを remember します。 従業員が退職すると、IDM システムはすべてのアカウントが削除済みまたは無効化されることを保証します。

アイデンティティ管理はエンタープライズ環境で生まれましたが、さまざまな他の環境にも適用できます。 Customer Relationship 管理 (CRM) システムからデータを取得し、顧客のアカウントを作成できます。 IDM システムはパスワードも維持できるため、通常顧客サポート centre の負荷を reduce します。 IDM システムはポータルやサービスプロバイダー環境でユーザーアカウントを同期できます。 IDM はクラウド環境で、多数のアプリケーションにある非常に大量のアカウントを管理する場合に特に useful です。これは手作業では現実的ではありません。 アイデンティティ管理は疑いなくアイデンティティおよびアクセス管理の基盤です。

なるほど、では実際にはどう機能するのか

IDM システムは robot のようなものです。 HR システムなどの情報ソースを continually watch します。 情報ソースで何かが変更すると、IDM システムは新しい情報を pull し、recompute し、ポリシーを適用し、その情報を他のシステムに push します。 例で説明します。

New employee is hired

HR スタッフは通常どおり従業員データを HR に入力します。 HR システムはすべての従業員のリスト を毎日本文ファイルにエクスポートするプロセスを持っています。 これは最も cumbersome な HR システムでも通常は非常に簡単にできます。 IDM システムはコネクターを使って、そのファイルの変更を継続的に監視します。 したがって新しい従業員を説明する新しい line を見つけ、ファイルからデータを読み取ります。 Typical IDM システムには、そのデータをプロセスするためのルールとスクリプトの集合があります。 たとえばルールは HR 記録の "組織単位" 分野を取得し、このユーザーがどのビジネスロールを持つべきかを 判断 するために使うかもしれません。 また通常、メールサービスへのアクセスを各従業員に与えるロールなど、すべての ordinary ユーザーに何らかのロールを適用します。 このロジックは組織ごとに異なり、IDM システムは効率的に カスタマイズ可能 であるよう構築されています。

IDM システムが新しいユーザーが何者で、どのロールを持つべきかを 判断 すると、本当に興味深い部分が始まります。 IDM システムは、そのユーザーが持つべきアカウントを compute します。 これは通常、ユーザーが持つロールから計算されます。 アカウント属性とエンタイトルメントも計算されます。たとえばユーザーが 所属すべきグループのリスト です。 IDM システムはアカウントがどのように見えるべきかを知ると、connector を使って自動的に作成できます。 コネクターは対象システムと communicate する単純コード片 です。 コネクターはアカウントを read、作成、修正、削除する方法を知っています。 したがって IDM システムはユーザーが必要とするすべてのアカウントを自動的に作成できます。 自動的に。 数秒で。

コネクターは通常対象システムに標準のなプロトコルを使って communicate します。 したがって Active Directory とは LDAP インターフェイスを使って話し、データベースは SQL で 修正 し、SOAP web サービスを invoke し、クラウドサービスには REST を使って provision します。 これは IDM システムが non-intrusive であることを意味します。Target アプリケーションを 変更する必要は ありません。 それらはそのまま残ります。 これは IDM システムを効率的で実践的なツールにしている crucial 機能です。 多数の情報システムを 変更するより、いくつかの単純コネクターを適応する方がはるかに簡単です。特に、その多くがまだ20世紀を覚えている場合にはそうです。

それだけでしょうか。他には何もありませんか?

もちろん違います。 IDM システムはアイデンティティライフサイクル全体を処理します。

  • IDM システムはすべての変更の 監査証跡 を保持します。 したがって、誰が何を、いつ、なぜ変更したかを痕跡できます。
  • IDM システムはユーザー権限とシステムへのアクセスに関する情報を提供する レポート を 生成できます。 これはセキュリティ監査にとって priceless な情報です。 IDM システムは、特定のユーザーがアクセスできるシステムのリスト を提供できる唯一のシステムです。 他のシステムはその情報を持っていません。
  • IDM システムは 承認 プロセスを drive できます。 この能力は通常、システムへのアクセスを申請し、それを承認するために使われます。
  • ユーザーは権限やアカウントの変更について notified されることがあります。 たとえば従業員はアクセス申請が承認され、アカウントが作成されたときにメールや SMS を受け取れます。
  • 多くの IDM システムは セルフサービス インターフェイスを提供します。ユーザーはこれを使ってパスワードをリセット し、アクセスを申請し、ユーザー名を確認するためにアカウントを確認する、などができます。 これによりヘルプデスク負荷は大幅に reduce されます。
  • Sophisticated IDM システムは グループ を作成し、組織構造 を replicate し、virtual サイトなどの サービス まで provision と デプロビジョニングできます。

この愚かなロボットがシステム管理者を置き換えられるとは思えない

そのとおりです。置き換えることはできません。 Human brain は常に必要です。 この 側面 は効率的には置き換えできません。 IDM システムが行うのは、誰もが嫌がる処理 mundane 作業の自動化です。 そのような作業は scripting、ルール、ポリシーを使って自動化されます。 しかし良い IDM システムは標準のシステム管理ツールを 無効化 しません。 それらはシステム管理者が emergency システム 回復 などで使えるよう、引き続き可用です。 システム管理者は、作成されるアカウントを承認するなど、完全に制御を維持することもできます。 しかし IDM システムは mundane 作業を大幅に reduce できます。操作を承認または refuse するだけです。 すべてのシステムに接続 し、スクリプトを run し、結果を確認するなどの30分の作業ではなく、ワンクリック です。 また承認は、elevated 権限を持つアカウントなど unusual アカウントに対してのみ作業するよう設定できます。 いずれにせよシステム管理者は常にシステムを制御し続けます。 しかし、はるかに効率的にそれを行えます。 処理作業を取り除き、重要な課題にもっと時間を使えるようにします。

それで私にはどんな効果があるのか

アイデンティティ管理には2つの大きな効果があります。

  • 費用削減: 手作業アイデンティティ管理の費用はかなり小さく見えるかもしれません。 しかし実際にはそうではありません。 まったく違います。 問題は、費用の大半が 隠れた であることです。 マネージャーが "アイデンティティ管理の費用" として 認識するものは、通常アカウントを作成するシステム管理者の時間だけです。 しかしそれ以上があります。パスワードリセット、アクセス申請、誤ってアクセスが revoked されたためシステムにアクセスできない人の call などを handle する ヘルプデスク エージェントがいます。 一般的従業員は、アクセスを申請する方法、申請を誰に送るべきか、何を含める必要があるかを理解するために多くの時間を無駄し、実際には必要なアクセスを得るために正確に何を申請すべきかさえ理解しなければなりません。 そして申請が sent されると、待つ必要があります。 さらに待ちます。 通常申請の自動エスカレーションはないため、申請は簡単に forgotten されます。 プロセスへの可視性はほとんどなく、requestor は誰に ask すべきかさえ分かりません。 などなどです。 これはすべての従業員にとって in効率 と 膨大な時間の無駄の信頼できる処方箋です。 良いアイデンティティ管理システムはこれを dramatic に改善できます。 Real 導入の結果は、パスワードリセット が1時間から数秒に下がり、help-desk 負荷が大幅に reduce されることを示しています。 またアクセス申請の 平均 処理時間が1週間超から2時間に下がることも示しています。 組織全体で見れば、節約できる時間は膨大です。
  • 改善されたセキュリティ: すべてのセキュリティ専門家は、セキュリティがファイアウォールや cryptography 以上に、情報、プロセス、人々に関するものであることを知っています。 セキュリティ担当者 が人々について信頼できる情報を持っていないなら、セキュリティを持つことはできません。 それほど単純です。 誰が何にアクセスしていたかを知らずに、セキュリティ担当者はどうやってセキュリティインシデント を 調査すればよいのでしょうか。 セキュリティインシデント は単一システムに 孤立しません。 しかし複数システムから情報を combine することは、セキュリティ担当者 にとって Herculean 作業です。 疑わしい従業員のグループについて、すべてのシステムにおけるすべての権限のリストをまとめ することがどれほど「簡単」か想像してください。 単一特定のシステムにアクセスできるアカウントのリスト を得ることは、実際にはかなり簡単です。 しかし、すべてのシステムにおける任意の単一人物のすべてのアクセス権限のリスト を得ることはほぼ不可能です。 この crucial 情報なしに、どうやって何かを investigate できるでしょうか。 プロビジョニングシステムの help なしにこれを行うセキュリティ担当者は、hero と呼ばれて当然です。 しかし抜け道があります。IDM システムは多くのシステムにあるユーザーアカウントを相関付けします。 IDM システムはすべての情報を 容易に提供できます。 良い IDM システムは、誰がどこにアカウントを持っているかだけでなく、グループメンバーシップや特殊な権限など権限に関する情報も提供します。 IDM システムからのレポートはセキュリティ インシデント調査を改善するために使えます。 またセキュリティ監査も dramatic に改善できます。 IDM システムからの単一レポートは、システムからデータを collect し spreadsheet で手作業で相関付けするために無駄される多くの日数を save します。 しかしさらに大きなな効果があります。IDM システムはすべての情報システムでポリシーを enforce できます。 そして組織全体としてポリシーが一緒に意味を持つことを保証できます。 これにより、セキュリティインシデント がそもそも起きる 可能性を減ら できます。

アイデンティティ管理は LDAP や SSO とどう関係するのか

IDM はアイデンティティおよびアクセス管理 (IAM) puzzle の1つの piece にすぎません。 他の2つの crucial 部分はアイデンティティストアとアクセス管理です。 各部分は全体的な IAM ソリューションで非常に異なるロールを果たします。

  • アイデンティティストア はユーザー記録を含む、大きくスケーラブルで効率的なデータベースです。 通常は複数のアプリケーションの間で共有されます。 これは通常 LDAP ディレクトリサービスまたは Active Directory によって実装されます。 これは fascinating 技術ですが、それでも単なるデータベースです。 したがって limit があります。 基本的にはデータをストア と 取得することしかできません。 データを別形式に convert する、データのコピーを作成と維持する、または他データベースと同期する必要があるなら、それはアイデンティティストアが通常 できない ことです。 アイデンティティストアは IAM ソリューションの静的部分 です。データをストアするだけです。
  • アイデンティティ管理 システムはデータをあちこちへ replicate します。 データを変換し、ポリシーを適用し、すべてのデータが最新であることを保証し、承認を駆動し、監査ログを保持します。 アイデンティティストアができないアイデンティティ管理作業を行えます。 IDM システムは IAM ソリューションの統合部分 を実装します。データを移動するのです。
  • アクセス管理 システムは認証、認可、アクセス監査、しばしば "AAA" と呼ばれるもの、セッション管理などを処理します。 ここでシングルサインオン (SSO) が発生します。 この技術の主な目的はユーザーと やり取りすること、またはシステムへのユーザーアクセスをリアルタイムに管理することです。 これは proverbially cherry on the cake です。 しかし通常、他の2つの構成要素なしには実装できません。 そしてそれでも実装は非常に高額になることがあります。 理由は、アクセス管理がシステムへのユーザーアクセスを管理しなければならないためです。 したがってユーザーがシステムと やり取りする方法に入り込む必要があります。 ユーザーインターフェイスや認証機構を 修正 し、プロキシや他のintermediary を introduce し、エージェントを install する必要があります。 アイデンティティストアと IDM が inherently バックエンドシステムであるのに対し、アクセス管理はアプリケーション front-end に entwined されます。 アクセス管理は IAM ソリューションの動的部分 です。リアルタイムにデータを扱います。

So, what should I do now?

あなたがおそらくこれを読んでいるのは、 somehow 完全な IAM ソリューションを build したいからでしょう。 方法は多数あります。 しかし、おそらく最も easy で汎用な方法は次のとおりです。

  1. まだ持っていないなら ディレクトリサービス を導入します。 または既存のものを reuse します。 Microsoft-oriented 環境では Active Directory が prime choice です。 他の環境では標準の LDAP ディレクトリサービスが有用です。 Market には、over-priced commercial monster から lean と elegant なオープンソースサーバーまで、非常に良い製品 choice があります。

  2. アプリケーションをディレクトリサービスに接続 します。 簡単に接続 できるすべてのアプリケーションです。 ただし、この手順をやりすぎないよう注意してください。 ディレクトリサービスは単なるデータベースであることを忘れないでください。 アプリケーションが lightweight と 単純なら、おそらく LDAP で満足するでしょう。 そのようなアプリケーションは迷わず LDAP に接続 してください。 しかし heavyweight と 複雑なアプリケーションでは状況がかなり異なります。 それらには LDAP 認証選択肢があるかもしれませんが、内部利用のためにユーザープロファイルを頻繁にコピーします。 一時的な回避策 として LDAP に接続 できます。 しかし本当に satisfactory なソリューションを得るには next 手順に進む必要があります。

  3. IDM システム を導入します。 HR や CRM をソースとして使うなどして、IDM システムでディレクトリサービス内のデータを維持します。 また IDM システムを使って heavyweight アプリケーションを fully 統合します。 IDM システムのロールベースのアクセス制御 (RBAC) 機構を使い始め、アカウント管理を clean up と 自動化 したいかもしれません。 この 段階 では基本セルフサービスも良い考え方かもしれません。 しかしプロジェクトをまだ遠くまで push しないでください。 Im仲介 効果を明確にもたらす、最も明らかな手順だけを行います。

  4. Think。そして re-think します。 この 段階 では状況はおおむね under 制御です。 最も 差し迫った懸念はすでに対処されています。 おそらく im仲介 pressure はないため、次に何をするか判断する時間があります。 おそらく最善の戦略は、IDM システムからのデータを使って real situation を分析することです。 IDM システムのレポートは、実際に何個のアカウントがあるか、そのうちどの proportion が active か、どの特定の権限を持つか、それらを自動的に link できるか、孤立したアカウントがいくつあるか、などを示せます。 これが real データです。 次の手順について responsible informed 判断を行うために必要なものです。 ユーザーの声も聞いてください。 彼らにとって最も severe な問題は何でしょうか。パスワード管理でしょうか。アクセス申請でしょうか。ユーザー名/パスワード prompt が多すぎることでしょうか。 このデータに基づき、次の手順のいくつかを行うことになるかもしれません。

. IDM システムで、より形式的な RBAC 構造と、より多くの自動化、ポリシーやワークフローの構築を続ける。

. SSO などのためにアクセス管理ソリューションを導入する。

. セルフサービスインターフェイスを extend する。

. より多くのアプリケーションを統合する。

. 何もしない。

驚くことに、この 段階 ではこれが非常に効率的な選択肢になることがあります。 ディレクトリと基本プロビジョニングの組み合わせは、費用対効果比 に関して、おそらく IAM ソリューションの最も効率的な部分です。 この 点 を超えて何をしても、previous 手順より費用は高く、deliver される効果は少なくなります。 80-20 Pareto ルールを考えてください。 いつ stop するかを知ることは重要です。

アイデンティティ管理製品をどう選ぶのか

これはかなり困難な部分です。 Market には多くの IDM 製品があります。 機能、費用、適合性は大きく異なります。 しかし基本的には3つの選択肢があります。

  • Big guns: "Big 名前" 会社の製品を選ぶと、非常に rich 機能、world-wide サポート、巨大な marketing brochure の山が得られます。 しかし、これらすべてには price tag がつきます。 License 費用だけでなく、entire ソリューションの price を consider することが重要です。 サポート、特にプロフェッショナルサービスは ライセンス 費用よりさらに重要です。 私たちの経験では、"big 名前" 製品はかなり elaborate で、長い development history を持っています。 しかしそれは、それらを使うのをかなり困難にもします。 これらの製品を効率的に扱える エンジニア が low daily rate を求める可能性は低いです。 これら製品の複雑性と age は、典型的 IDM プロジェクトが長期間、9〜18か月かかり、多くの skilled エンジニア を必要とすることも意味します。 これは IAM プロジェクト全体の費用対効果比 に大きく影響します。
  • Challengers: 代替策製品を提供する smaller 会社がいくつかあります。 この領域では price と品質が大きく異なります。 サポートとプロフェッショナルサービスの可用性も課題になる場合があります。 この カテゴリ の製品について十分な知識を持つ エンジニア を得ることは困難かもしれません。 もう1つの課題は製品自体の future です。 Acquisition はかなり一般的です。 そして acquisition により technologically excellent な製品が サポート終了 に達した precedent ケースが少なくとも1つあります。 これら製品はクローズドソースであるため、そのようなケースで顧客が投資の無駄を避けるために取れる実践的な手順はありません。
  • オープンソース: これはまだ比較的新しい選択肢です。 2000年代には実践的な open-source IDM システムはありませんでした。 しかし2010年代に大きく変わりました。 現在では、少なくとも2つの reasonably mature なオープンソースアイデンティティ管理製品から選べます。 これら製品は commercial 代替策と comparable です。 また newer 技術に基づいており、ある程度理解 と 利用しやすくなっています。 オープンソース製品は commercial サポートサービスを提供する会社によって backed されています。