IdMの実装。 お客様側での導入準備

これまでの記事では、IdM とは何か、組織にそのようなシステムが必要かどうかを理解する方法、IdM が解決する問題、および経営陣に対する導入予算の正当性を説明する方法についてすでに説明しました。 今日は、IdM システムを導入する前に、組織自体が適切な成熟レベルに達するために通過する必要がある重要な段階について説明します。 結局のところ、IdM はプロセスを自動化するように設計されていますが、カオスを自動化することは不可能です。

企業が大企業の規模に成長し、さまざまな業務システムが蓄積されるまでは、通常、アクセス制御について考えることはありません。 したがって、権利を取得し、その中で権力を制御するプロセスは構造化されておらず、分析が困難です。 従業員は希望に応じてアクセス申請書に記入しますが、承認プロセスも正式なものではなく、単に存在しない場合もあります。 従業員がどのようなアクセス権を持っているか、誰がどのような根拠でそれを承認したかをすぐに把握することは不可能です。

アクセスを自動化するプロセスは、人事データと統合が実行される情報システムからのデータという XNUMX つの主要な側面に影響を与えることを考慮して、IdM の実装がスムーズに進み、拒否を引き起こさないようにするために必要な手順を検討します。

1. 人事プロセスの分析と人事システムにおける従業員データベースのサポートの最適化。
2. ユーザーおよび権利データの分析、および IdM への接続が計画されているターゲットシステムのアクセス制御方法の更新。
3. IdM の実装の準備プロセスにおける組織活動と人員の関与。

人事データ

組織内の人事データのソースは XNUMX つである場合もあれば、複数ある場合もあります。 たとえば、組織にはかなり広い支店ネットワークがあり、各支店が独自の人員ベースを使用している場合があります。

まず第一に、従業員に関するどのような基本データが人事記録システムに保存されているか、どのようなイベントが記録されているかを理解し、その完全性と構造を評価する必要があります。

すべての人事イベントが人事情報源に記載されているわけではないことはよくあります (さらに、時期尚早で完全に正確ではないことが記載されている場合の方がさらに多くなります)。 典型的な例をいくつか示します。

• 休暇、そのカテゴリーおよび期間（定期的または長期）は記録されません。
• パートタイム雇用は記録されません。たとえば、従業員は育児のための長期休暇中、同時にパートタイムで働くことができます。
• 候補者または従業員の実際のステータスがすでに変更されており（受け入れ/異動/解雇）、この出来事に関する命令が遅れて発行される。
• 従業員は解雇によって新しい正規職に異動しますが、人事システムにはこれが技術的解雇であるという情報は記録されません。

また、人事システムなどの信頼できるソースから取得したエラーや不正確さは、将来的にコストがかかり、IdM の実装時に多くの問題を引き起こす可能性があるため、データの品質の評価に特別な注意を払う価値があります。 たとえば、人事担当者は、大文字と小文字、略語、異なる数のスペースなど、さまざまな形式で人事システムに従業員の役職を入力することがよくあります。 その結果、同じポジションが以下のバリエーションで人事システムに記録される可能性があります。

• シニアマネージャー
• シニアマネージャー
• シニアマネージャー
• 美術。 マネージャー…

多くの場合、名前のスペルの違いに対処する必要があります。

• シュメレワ・ナタリヤ・ゲンナディエヴナ
• シュメレワ ナタリア ゲンナディエヴナ...

さらに自動化を進める場合、特にこれらの属性が識別の重要な兆候である場合、つまり従業員に関するデータとシステム内での権限がフルネームで正確に比較される場合、このようなごちゃ混ぜは受け入れられません。

さらに、社内に同名者や完全同名者が存在する可能性があることを忘れてはなりません。 組織に従業員が 50 人いる場合、そのような一致はほとんどないかもしれませんが、従業員が XNUMX 人の場合、これは IdM システムの適切な運用にとって重大な障害となる可能性があります。

上記をすべて要約すると、組織の人事データベースにデータを入力する形式は標準化する必要があると結論付けられます。 名前、役職、部門を入力するためのパラメータは明確に定義する必要があります。 最良のオプションは、人事担当者がデータを手動で入力するのではなく、人事データベースで利用可能な「選択」機能を使用して、事前に作成された部門および役職の構造のディレクトリからデータを選択する場合です。

同期エラーのさらなる発生を回避し、レポートの不一致を手動で修正する必要をなくすために、 従業員を識別する最も好ましい方法は ID を入力することです 組織のすべての従業員に。 このような識別子は各新入社員に割り当てられ、人事システムと組織の情報システムの両方に必須のアカウント属性として表示されます。 数字で構成されているか文字で構成されているかは関係ありません。重要なのは、各従業員に一意であるということです (たとえば、多くの人が従業員の従業員番号を使用します)。 将来的には、この属性の導入により、人事ソース内の従業員データと、情報システム内のアカウントおよび権限とのリンクが大幅に容易になるでしょう。

したがって、人事記録のすべての手順とメカニズムを分析し、整理する必要があります。 一部のプロセスを変更または修正する必要がある可能性があります。 これは退屈で骨の折れる作業ですが、必要なことです。そうしないと、人事イベントに関する明確で構造化されたデータが欠如し、自動処理でエラーが発生します。 最悪の場合、構造化されていないプロセスを自動化することはまったく不可能になります。

対象システム

次の段階では、IdM 構造に統合する情報システムの数、ユーザーとその権利に関するどのようなデータがこれらのシステムに保存されるか、およびそれらの管理方法を把握する必要があります。

多くの組織では、IdM をインストールし、ターゲット システムへのコネクタを設定すれば、魔法の杖をひと振りするだけで、追加の労力を必要とせずにすべてが機能するという意見があります。 残念ながら、そんなことは起こりません。 企業では、情報システム環境が発展し、徐々に増加しています。 システムごとに、アクセス権を付与するための異なるアプローチを使用できます。つまり、異なるアクセス制御インターフェイスを構成できます。 制御が API (アプリケーション プログラミング インターフェイス) を通じて行われる場合もあれば、ストアド プロシージャを使用するデータベースを通じて行われる場合もあれば、対話インターフェイスがまったく存在しない場合もあります。 組織のシステムでアカウントと権利を管理するための多くの既存のプロセスを再考する必要があるという事実を覚悟しておく必要があります。つまり、データ形式を変更し、対話インターフェイスを事前に改善し、この作業にリソースを割り当てる必要があります。

ロールモデル

おそらく、IdM ソリューションプロバイダーを選択する段階でロールモデルの概念に遭遇するでしょう。これは、アクセス権管理の分野における重要な概念の XNUMX つであるためです。 このモデルでは、データへのアクセスはロールを通じて提供されます。 ロールとは、特定のポジションにある従業員が機能上の責任を遂行するために最低限必要なアクセス権のセットです。

ロールベースのアクセス制御には、否定できない利点が数多くあります。

• 多数の従業員に同じ権限を割り当てるのは簡単かつ効果的です。
• 同じ権限を持つ従業員のアクセスを速やかに変更する。
• 権利の重複を排除し、ユーザーの相容れない権限を制限します。

役割マトリックスは、最初に組織の各システムで個別に構築され、次に IT ランドスケープ全体に拡張され、各システムの役割からグローバルなビジネスの役割が形成されます。 たとえば、ビジネス ロール「会計士」には、企業の会計部門で使用される情報システムごとにいくつかの個別のロールが含まれます。

最近では、アプリケーション、データベース、オペレーティング システムの開発段階でもロール モデルを作成することが「ベスト プラクティス」と考えられています。 同時に、ロールがシステム内で構成されていない、またはロールが単に存在しないという状況もよくあります。 この場合、このシステムの管理者は、必要な権限を提供するいくつかの異なるファイル、ライブラリ、およびディレクトリにアカウント情報を入力する必要があります。 事前定義されたロールを使用すると、複雑な複合データを含むシステム内でさまざまな操作を実行する権限を付与できます。

情報システムにおける役割は、原則として、人員配置構造に従って役職および部門に割り当てられますが、特定のビジネス プロセスに対して作成することもできます。 たとえば、金融組織では、決済部門の複数の従業員が同じポジション (オペレーター) を占めています。 しかし、部門内では、さまざまな種類の業務 (外部または内部、さまざまな通貨、組織のさまざまなセグメント) に応じて、個別のプロセスへの分散も行われます。 必要な詳細に従って、XNUMX つの部門の各業務領域に情報システムへのアクセスを提供するには、個々の機能上の役割に権限を含める必要があります。 これにより、活動領域ごとに、重複する権利を含まない、最小限の十分な権限を提供することが可能になります。

さらに、数百のロール、数千のユーザー、数百万の権限を持つ大規模システムの場合は、ロールの階層と権限の継承を使用することをお勧めします。 たとえば、親ロールの管理者は、子ロールであるユーザーと読者の権限を継承します。これは、管理者はユーザーと読者が実行できることすべてを実行できることに加えて、追加の管理権限も持つためです。 階層を使用すると、同じモジュールまたはシステムの複数の役割で同じ権限を再指定する必要がなくなります。

最初の段階では、権限の組み合わせの数がそれほど多くないシステムでロールを作成でき、その結果、少数のロールの管理が容易になります。 これらは、Active Directory (AD)、メール システム、Service Manager などの公的にアクセス可能なシステムに対して、会社の全従業員に必要とされる一般的な権利です。 次に、作成した情報システムの役割マトリックスを一般的な役割モデルに組み込み、ビジネス役割に結合します。

このアプローチを使用すると、将来 IdM システムを実装するときに、作成された第 XNUMX 段階のロールに基づいてアクセス権を付与するプロセス全体を簡単に自動化できます。

N.B. できるだけ多くのシステムをすぐに統合に含めようとしないでください。 より複雑なアーキテクチャとアクセス権管理構造を持つシステムは、最初の段階では半自動モードで IdM に接続することをお勧めします。 つまり、人事イベントに基づいて、アクセス要求の自動生成のみを実装し、実行のために管理者に送信され、権限を手動で構成します。

最初の段階が正常に完了すると、システムの機能を新たに拡張されたビジネス プロセスに拡張し、追加の情報システムを接続して完全な自動化と拡張を実装できます。

つまり、IdM の実装を準備するには、情報システムが新しいプロセスに対応できるかどうかを評価し、ユーザー アカウントとユーザー権限を管理するための外部対話インターフェイスがまだ完成していない場合は、そのインターフェイスを事前に最終決定する必要があります。システムで利用可能です。 包括的なアクセス制御のために情報システム内で段階的に役割を作成するという問題も検討する必要があります。

組織的なイベント

組織の問題も軽視しないでください。 プロジェクト全体の成果は部門間の効果的な相互作用に依存することが多いため、場合によっては決定的な役割を果たすこともあります。 これを行うには、通常、組織内にプロセス参加者のチームを作成し、関係するすべての部門を含めることをお勧めします。 これは人々にとってさらなる負担となるため、今後のプロセスにおけるすべての参加者に、対話構造における役割と重要性を事前に説明するようにしてください。 この段階で IdM のアイデアを同僚に「売り込む」と、将来の多くの困難を回避できます。

多くの場合、企業内の IdM 導入プロジェクトの「所有者」は情報セキュリティ部門または IT 部門であり、ビジネス部門の意見は考慮されません。 これは大きな間違いです。なぜなら、各リソースがどのビジネス プロセスでどのように使用されるか、誰にアクセス権を与えるべきか、誰にアクセス権を与えるべきではないかを知っているのは彼らだけだからです。 したがって、準備段階では、情報システムにおけるユーザー権限 (役割) のセットに基づいて開発される機能モデルに対して責任を負うのは事業主であることを示すこと、また、以下のことを保証することが重要です。これらの役割は最新の状態に保たれます。 ロールモデルは、一度構築すれば落ち着いて使用できる静的なマトリックスではありません。 これは、組織の構造や従業員の機能の変化に応じて、常に変化、更新、発展しなければならない「生き物」です。 そうしないと、アクセスの提供の遅延に関連して問題が発生するか、過剰なアクセス権に関連して情報セキュリティのリスクが発生し、これはさらに悪いことになります。

ご存知のとおり、「XNUMX 人の乳母が目のない子供を育てている」ため、企業はロールモデルのアーキテクチャ、ロールモデルを最新の状態に保つためのプロセスにおける特定の参加者の相互作用と責任を説明する方法論を開発する必要があります。 企業に多くの事業活動分野があり、それに応じて多くの部門や部門がある場合、役割ベースのアクセス管理プロセスの一環として、各分野 (融資、運用業務、リモート サービス、コンプライアンスなど) に対して、別途キュレーターを任命する必要があります。 これらを通じて、部門の構造の変更や各役割に必要なアクセス権に関する情報を迅速に受け取ることができます。

プロセスに参加している部門間の対立状況を解決するには、組織の経営陣の支援を得ることが不可欠です。 そして、新しいプロセスを導入するときの衝突は避けられません、私たちの経験を信じてください。 したがって、他人の誤解や妨害行為によって時間を無駄にしないように、利益相反の可能性を解決してくれる仲裁人が必要です。

N.B. 意識を高めるには、スタッフをトレーニングすることから始めるのが良いでしょう。 将来のプロセスの機能とそのプロセスにおける各参加者の役割を詳細に調査することで、新しいソリューションへの移行の困難を最小限に抑えることができます。

チェックリスト

IdM の導入を計画している組織が実行する必要がある主な手順を要約します。

• 人事データに秩序をもたらす。
• 各従業員の一意の識別パラメータを入力します。
• IdM の実装に対する情報システムの準備状況を評価する。
• アクセス制御のための情報システムと対話するためのインターフェースを開発し（不足している場合）、この作業にリソースを割り当てます。
• ロールモデルを開発し構築する。
• ロールモデルの管理プロセスを構築し、そこに各ビジネス分野のキュレーターを含めます。
• IdM への初期接続用にいくつかのシステムを選択します。
• 効果的なプロジェクトチームを編成する。
• 会社経営陣からのサポートを得る。
• 列車のスタッフ。

準備プロセスは難しい場合があるため、可能であればコンサルタントに協力してもらいます。

IdM ソリューションの導入は難しく責任あるステップであり、導入を成功させるには、ビジネス部門の従業員、IT および情報セキュリティ サービスなどの各当事者の個別の取り組みと、チーム全体の相互作用の両方が重要です。 しかし、その努力には価値があります。企業に IdM を導入した後は、情報システムにおける過剰な権限や無許可の権利に関連するインシデントの数が減少します。 必要な権限の欠如または長時間の待ち時間による従業員のダウンタイムが解消されます。 自動化により人件費が削減され、IT および情報セキュリティ サービスの労働生産性が向上します。

出所： habr.com