したがって、ITで個人データを管理するために、大企業は、企業システムのユーザーに関する情報を管理するために、特殊なIDMクラスシステムを導入することを余儀なくされます。 この地域で有能な人材がある程度不足する前に、雷が襲い、農民が洗礼を受け始めると、この不足は壊滅的な規模になります。
この専門分野の人員不足は、IDMの専門家が一度に複数のITスキルを持たなければならないという事実によるものです。ビジネスプロセスの説明と設定。 また同時に、彼は個人データの調整に関する膨大な量の日常業務について絶賛すべきではありません。 私はそのような人々が自然に存在しないとほぼ確実に言うことができます。 この事実に関連するのは、一般的に漠然と私たちの詳細を想像する人事部従業員の永遠の頭痛です。
この状況から抜け出す唯一の方法は、作業を少なくとも2つに分割することです。 セキュリティシステムコネクタのプログラミング、内部ワークフローの構成、スクリプトの記述、展開を行うことができます。 2つ目は、ユーザーデータの操作、ビジネスプロセスの説明、IT大衆のIDMアイデアの文書化と宣伝です。
私は仲間のプログラマを失望させようとしました。 この一連の記事では、IDMの実装のビジネスと生産の部分、およびユーザーデータを実装して操作するための実用的な手法に重点が置かれます。 インテリジェントプログラマーがほとんどいないため、見つけることができます。 しかし、なぜこれがすべて行われているのかを理解している人々は、モスクワの指で数えることができます。
この資料を読んだ後、同僚がこの問題の明確性を高め、多くのプログラマーまたはシステム管理者がIDMビジネスインテリジェンスキャンプに行って、この分野で働いている少数の「スター」と競争できることを心から願っています。
アイデンティティ管理とは何ですか？
アイデンティティは人です。 実在の人物に関する情報を構成するものはすべてアイデンティティです。名前、性別、地位、生年、システム内のアカウントの属性です。 特定の組み合わせでは、個人に関する情報は連邦法の対象となり、管理する必要があります。 プロセスと個人データ管理システムは、Identity Management（IDM）と呼ばれます。
会社の従業員に関する個人情報はどこに保存されますか？ もちろん、人事制度では。 また、Active Directory、数十のアプリケーションシステムのユーザーカード、メールプログラムのデータ、クライアント管理システム、課金システム、サービスデスクシステムなどでは、この情報に一貫性がないことがよくあります。 同一の人物を同時に多数のシステムに登録することができ、誰もが同じように正しく登録されていることを保証する人はいません。
IDMの主なタスクの1つは、管理プロセスをさらに発展させるための基礎として、個人情報の単一の関連カタログを作成することです。
IDM、IAM、RM-WTF？
ユーザーアカウントとその属性（アクセスグループなど）は、メールアドレス、名前、役職と同じ個人情報の一部です。 Active Directoryの専門家は、これがすべて同様の方法でシステムデータベースに保存されていることを確認します。 したがって、IDMプロセスのフレームワークに情報システムへのアクセス管理（アクセス管理）を含めることは論理的です。 多くの場合、IDMはIdentity and Access Management（IAM）として理解されており、IDMの略語はもっと好きです。
IDMの実装の成功の結果は、「静的」と「動的」に分けることができます。 最初は「何になったのか」の結果です。 2番目の「そして、それはどのように機能しますか？」
IDMの正常な実装の静的な結果は、ユーザーアカウントの順序であり、次の要素で構成されています。
- すべてのシステムのすべてのアカウントは、技術（プロセスとシステムの「記録」）およびシステム（「管理者アカウント」）を含む特定の人々によって配布されます
- すべてのアカウント属性は互いに一貫しています（たとえば、姓と会社の電話番号はどこでも同じです）
- 各従業員が持つシステムの権利を正確に把握しています
実装を成功させるための動的なコンポーネントは、実際には、時計のように機能するアカウント管理プロセスです。 そのようなプロセスの基準の例を次に示します。
- 新入社員の採用、従業員の別の役職への異動、従業員の解雇では、情報システムのアカウントの属性が並行して一貫して変化します
- 新しい従業員のアカウントは、事前定義されたルール（さまざまな魔法のスクリプトやタンバリンを使用したその他のダンスの開始など）に従って自動的に生成されます。 もちろん、新しい従業員は、コンピューターを与えられた場合、フレームで登録した後すぐに仕事を始めることができます。
- 解雇された、または信頼できない従業員のアカウントは、彼らが働いたすべてのシステムで同時にブロックされます。 したがって、「気分を害する」ことによる被害は最小限に抑えられます。
- 各従業員は、その時点では、公務を行うために必要な特権のセットのみを持っています。 追加の特権がありません。
説明されている全体像では、小さいながらも非常に重要なコンポーネントが1つ欠落しています。 注意深い読者は、アカウントの開始とブロック、ディレクトリの同期を学んだことに気付くかもしれませんが、質問に対する答えはまだありません。多くの場合、この問題はIDM実装プロジェクトのほとんどの作業の原因となっています。
さまざまなシステムでのユーザーの権利（特権）は、公式の職務のみに依存します。 そして、彼の責任が多様になるほど、これらの特権を割り当てるための原則を決定することが難しくなります。
最も単純なケースでは、ユーザーの権利は、自分の位置と職場の物理的な場所によって決まります。 これは、さまざまなオペレーター、コールセンターの従業員、コンベアラインの従業員など、大量の交換可能な職種で一般的です。
従業員の職務に同僚の特徴ではない追加のアクティビティが含まれる場合、タスクは複雑になります。 たとえば、従業員は部門全体の事務用品を注文する責任があります。 これを行うために、彼は特定のシステムへのアクセスを許可され、そこで四半期に1回アクセスし、そこで3つのボタンを押して、次の3か月間それを忘れます。 そして、そのようなユーザーはすべての部門にいます。 大企業の会計士も同様の頭痛の種を抱えています。大企業の会計士は、ご存知のように、多くの場合、さまざまな分野に特化しており、さまざまなシステムを使用していますが、同じ立場にいます。
さらに複雑なケースは、会社が内部プロジェクトまたはその他の不規則な活動を行っており、従業員を一時的にグループ分けする必要がある場合です。 たとえば、ERPシステムが導入され、ワーキンググループのすべてのメンバーがテストサイトへの一時的なアクセスを受け取ります。 または、会社は新しいプレゼンテーションテンプレートに取り組んでおり、主要な従業員はポータルマーケティングサービスに入場し、設計レイアウトを評価しました。 しかし、あなたは他に何ができるのか決してわかりません！ このような状況で必要な権限を与えることは、まだ戦いの半分です。 それらを正しく、時間通りに思い出してみてください！ 90％の企業では、ユーザー資格情報が取り消されることはありません。 長く働く従業員は、砲弾の船のように徐々にアクセスを獲得しています。 2、3年後、誰がどこからそんなに多くの特権を得たのかを実際に知ることはできません。 アカウントの数と所有者の数の点で、アプリケーション管理者によってアカウント自体がまだ何らかの形で制御されている場合、1つのアカウントの枠組み内で悪魔は彼の足を突破します。
災害の規模を評価するために、いくつかの数字を示します。 会社に1000人のユーザー、10のシステムがあり、各システムに10の異なる特権があるとします。 たとえば、Active Directoryに関連付けられているシステムもあれば、独自の認証システムを備えているシステムもあります。 したがって、平均して、たとえば、ユーザーごとに3つのアカウントがあります。 合計3000のアカウントがあります。 各ユーザーは、システムで平均5〜7の特権を持っています。 合計で1万から2万のユーザーへの特権の割り当てがあります。 特権の各割り当ては、そのようにではなく、意味を持って一度に行われました。 そしてその意味には、時間とともに消える性質があります。
これをすべて理解するには、理解しているように、いくつかの深刻な作業を行う必要があります。 手動モードでは、少数のシステムと鉄則で管理できます。 しかし、普通の人にとってエンティティが多すぎる場合は、プロセスの自動化とロール管理要素の使用について考える必要があります。 RMは現在、ミドルウェアの分野で非常にファッショナブルで人気のあるトレンドです。 外部のオブザーバーにとっては、考えられないほどのお金がかかり、何をしているのか明確ではありません。 このクラスのシステムは、Oracle（別名Sun）、IBM、Microsoftなどの大手ソフトウェア大手と競合しています。 特定のプラットフォームの利点についての無意味な論争で、多くのコピーが壊れています。 経験から言えば、ビジネスプロセスで物事を整理することに十分な注意を払わなければ、すべてのシステムが同様に愚かになると言えます。
一般的に、これらのシステムの仕組みは、実装の成功は独自のエンジンや使用されるプログラミング言語ではなく、ロールモデルの正しい形成とビジネスルールの微調整であるため、私にはほとんど関心がありません。 特定のシステムの品質は、ロールモデルの作成の利便性とビジネスルールの設定の柔軟性によって決まります。 すべての主要メーカーは、既製のコネクタの数の拡大とエンジンの信頼性の全般的な向上とともに、開発のこれらのパラメータを正確に最適化しようとしています。
IDMの導入の場合、私たちの慣習であるように、カートがそれに沿って馬を引き寄せることを期待して、すぐにソフトウェアのインストールを急ぐ必要はありません。 いつものように奇跡は起こりませんが、今後何年もfireを壊します。 結局のところ、IDMシステムは、非常に「全員」のシステム管理者（ユーザー認証）に実装されています。 倒れたIDMは、会社全体の仕事を麻痺させる可能性があります。 曲がったエンジンは、新しいユーザーを手動で処方する以前の「hem」が、管理者にとって良い話に見えるという事実につながります。 言うまでもなく、あなたの周りの全員があなたとあなたのシステムを受け取ります。
例として、同名のアカウントを生成するときに、競合解決アルゴリズムの面白い不具合を挙げることができます。これにより、一度に数百のアカウントが自動的に生成されます。 購入したシステムの各アカウントにライセンスを支払う顧客の喜びを想像してください。 奇跡的にスキャンダルを静めることができました。 しかし、スプーンは見つかりましたが、沈殿物は残りました。
ロシアの現実は、最も先進的で進歩的な企業でさえ、ユーザー特権の混乱は信じられないほどです。 アカウントの定期的なクリーニングとインベントリにもかかわらず、特に上位の従業員の間で、小さな櫛でユーザーの特権を排除する人はいません。 また、公式アカウント、ゲストアカウント、および管理アカウントは特定の人に関連付けられておらず、一般にそれらをどう処理するかが明確ではないため、多くの場合、注文はありません。
情報セキュリティ部門の従業員は、監査人の基本的な質問「誰がどのベースで1つまたは別のシステムにアクセスできるのか」に対する答えを知らないため、時限爆弾に座っていることがわかります。しかし、彼らはこの質問すべてに対処する必要がありますより多くの場合、科学によって確立された事実があります。 いつでも（1か月の特権の手動調整の後だけでなく）答えは、IDMクラスシステムが役割ベースのアクセス制御の追加機能を使用するのに役立ちます。
次の出版物では、IDM実装プロジェクトの組織と、ロールモデルを作成するためのさまざまな実用的なアプローチについて説明します。
PSその本質をよりよく反映するようにトピックの名前を変更しました。
以前：Identity Management- 個人データ管理の基本
今：アイデンティティ管理- アカウント管理の基本