アクセス制御のロールモデルを構築しています。パート1、準備

現在、私はソフトウェアベンダ、特にアクセス制御ソリューションを担当しています。そして、私の「過去の人生」の経験は、顧客の側、つまり大規模な金融組織と結びついています。当時、私たちの情報セキュリティ部門のアクセス制御グループは、IdMの優れた能力を誇ることができませんでした。その過程で多くのことを学び、社内の情報システムにおけるユーザーの権利を管理するための機能的なメカニズムを構築するために、多くのバンプを埋める必要がありました。



お客様で得た私の経験とベンダーの知識と能力を組み合わせたので、大規模な会社で役割ベースのアクセス制御モデルを作成する方法と、それが最終的に何をもたらすかについて、基本的にステップバイステップの説明を共有したいと思います。私の指示は2つの部分で構成されています。1つ目はモデルを構築する準備をしており、2つ目は実際に構築しています。これがパート1の準備です。



NB残念ながら、ロールモデルの構築は結果ではなくプロセスです。むしろ、会社のアクセス制御エコシステムを作成するプロセスの一部ですらあります。長期的に見てください。



まず、定義しましょう-ロールベースのアクセス制御とは何ですか？数万または数十万の従業員（サブジェクト）を抱える大規模な銀行があり、それぞれが数百の内部銀行情報システム（オブジェクト）への数十のアクセス権を持っているとします。次に、オブジェクトの数にサブジェクトの数を掛けます。これは、最初に構築してから制御する必要がある接続の最小数です。これを手動で行うことは現実的ですか？もちろん、そうではありません-この問題を解決する役割が現れました。



ロールは、ユーザーまたはユーザーグループが特定の作業タスクを実行するために必要な一連の権限です。各従業員は1つ以上のロールを持つことができ、各ロールには、このロール内のユーザーに許可される1つから多くの権限を含めることができます。役割は、従業員の特定の役職、部門、または機能的タスクに関連付けることができます。







ロールは通常、各情報システムの個々の従業員の権限から作成されます。次に、各システムの役割からグローバルなビジネス役割が形成されます。たとえば、クレジットマネージャーのビジネスロールには、銀行のクライアントオフィスで使用される情報システムのいくつかの異なるロールが含まれます。たとえば、メインの自動銀行システム、キャッシュモジュール、電子ドキュメント管理システム、サービスマネージャーなどです。原則として、ビジネスロールは、組織およびスタッフの構造、つまり、会社の部門とそのポジションのセットに関連付けられています。これは、グローバルな役割マトリックスがどのように形成されるかです（以下の表に例を示します）。







100％のロールモデルを構築することは単に不可能であり、商業構造の各ポジションの従業員に必要なすべての権利を提供することは注目に値します。はい、必要ありません。結局のところ、ロールモデルは絶えず変化する環境に依存しているため、静的ではありません。そして、それに応じて組織構造と機能の変更に影響を与える会社の事業活動の変化から。そして、リソースの完全な提供の欠如から、そして職務記述の非遵守から、そして安全性を犠牲にして利益を欲することから、そして他の多くの要因から。そのため、ユーザーが必要な基本的権利を求められたときに、ユーザーがその地位に任命されたときに最大80％のニーズをカバーできるロールモデルを構築する必要があります。そして、必要に応じて、残りの20％を後で個別にリクエストすることができます。



もちろん、次のように質問することもできます。「100％のロールモデルはありませんか？」ええと、なぜこれは、頻繁に変更されることのない非営利組織、たとえば一部の研究所で発生するのでしょうか。または、セキュリティが最優先される、高レベルのセキュリティを備えた軍事産業複合組織において。これは商業構造でも発生しますが、別のユニットのフレームワーク内で行われ、その作業はかなり静的で予測可能なプロセスです。



ロールの数は情報システムのユーザーの数よりも大幅に少ないため、ロール管理の主な利点は、権限の付与が単純化されることです。そして、これはどの業界にも当てはまります。



小売会社を例に挙げます。数千人の営業担当者を雇用していますが、Nシステムでは同じ一連の権限があり、1つのロールのみが作成されます。新しい売り手が会社にやって来ました-彼は自動的にシステムで必要な役割を自動的に割り当てられました、そしてそれはすでにすべての必要な力を持っています。たとえば、レポートを生成するための新しいオプションを追加するなど、ワンクリックで数千のセラーの権利を変更することもできます。新しい権限を各アカウントにリンクする1,000の操作を実行する必要はありません。このオプションをロールに追加するだけで、すべてのセラーに同時に表示されます。



役割ベースの管理のもう1つの利点は、互換性のない権限の発行を排除できることです。つまり、システムで特定の役割を持つ従業員が同時に別の役割を持つことはできません。その役割は、最初の役割と組み合わせるべきではありません。顕著な例は、金融取引の入力と制御の機能を組み合わせることの禁止です。



役割ベースのアクセス制御がどのように行われたかに興味がある人なら誰でもできます

次に、必要な準備手順について説明します。準備手順なしでは、実際的な役割モデルを構築することは不可能です。

ステップ1.機能モデルを作成する

各部門と各ポジションの機能を詳細に説明するトップレベルのドキュメントである機能モデルの作成から始めることは価値があります。原則として、情報はさまざまなドキュメントから取得されます。個々の部門-部門、部門、部門のジョブの説明と規制。機能モデルは、関係するすべての部門（ビジネス、内部統制、セキュリティ）と合意し、会社の管理者によって承認される必要があります。このドキュメントの目的は何ですか？ロールモデルがそれを参照できるように。たとえば、既存の従業員の権利に基づいてロールモデルを作成します-システムからアンロードされ、「共通の特徴を持っています」。次に、受け取ったロールをシステムのビジネスオーナーと調整するときに、機能モデルの特定の項目を参照できます。これに基づいて、この権利またはその権利は役割に含まれます。

2. -

2番目のステップは、ITシステムの監査を実施して、アクセスがどのように構成されているかを理解することです。たとえば、私の金融会社は数百の情報システムを実行していました。すべてのシステムには役割ベースの管理の原始があり、それらのほとんどは何らかの種類の役割を持っていましたが、ほとんどが紙またはシステムのマニュアルにありました-それらは古くなっており、それらへのアクセスは実際のユーザーの要求に基づいて分散されていました。当然、一度に数百のシステムでロールモデルを構築することは単に不可能であり、どこかから始める必要があります。アクセス制御プロセスの詳細なレビューを実施して、その成熟度を判断しました。分析中に、情報システムに優先順位を付けるための基準が開発されました-重要度、準備状況、廃止計画など。彼らの協力を得て、これらのシステムのロールモデルの開発/更新のシーケンスを構築しました。そして、アクセス制御を自動化するために、アイデンティティ管理統合計画にロールモデルを含めました。



では、システムの重要性をどのように判断するのでしょうか。次の質問に答えてください。

• システムは、会社のコアビジネスが依存する運用プロセスにリンクされていますか？
• システムの混乱は、会社の資産の完全性に影響を与えますか？
• 最大許容システムダウンタイムはどのくらいですか。その後、中断後にアクティビティを復元することはできません。
• システム内の情報の整合性に違反すると、財務上および評判上の不可逆的な結果につながる可能性がありますか？
• 詐欺への批判。機能の可用性。制御が不十分な場合、内部/外部の不正行為を実行する可能性があります。
• これらのシステムの法的要件、および内部ルールと手順は何ですか？規制に違反すると罰金が科されますか？

金融会社では、以下の監査を実施しました。経営陣は、最優先の情報システムで最初に既存のユーザーと権利に対処するためのアクセス権レビュー監査プロセスを開発しました。セキュリティユニットは、このプロセスの所有者として指定されました。しかし、会社のアクセス権の全体像を把握するには、プロセスにIT部門とビジネス部門を関与させる必要がありました。そしてここで紛争、誤解、そして時には妨害行為さえも始まった：誰も彼らの現在の義務から脱却して、一見しただけでは理解できない活動に参加したくはない。



NB - - – IT general controls (ITG), - , best practice (ITIL, COBIT, IT Governance .) , , , .







監査の領域の1つは、情報システムへの論理的および物理的アクセスのパラメーターを決定することです。得られたデータは、ロールモデルを構築するための基礎として使用しました。このような監査の結果、ITシステムの登録があり、ITシステムの技術パラメーターが決定され、説明が行われました。さらに、各システムについて、事業ラインからの所有者が特定され、その利害が運用されました。このシステムが提供するビジネスプロセスを担当したのは彼でした。 ITサービスマネージャーも任命され、特定のISにおけるビジネスニーズの技術的な実装を担当しました。会社にとって最も重要なシステムとその技術的パラメータ、試運転と廃止措置の条件などが記録されました。これらのパラメーターは、ロールモデルを構築する準備に非常に役立ちました。

ステップ3方法論を作成する

ビジネスの成功の鍵は正しい方法です。したがって、ロールモデルの構築と監査の両方を行うために、部門間の相互作用を記述し、会社の規制における責任を確定するなどの方法論を作成する必要があります。

最初に、アクセス権と権利を付与するための手順を確立する利用可能なすべてのドキュメントを調べる必要があります。友好的な方法で、プロセスはいくつかのレベルで文書化されるべきです：

• 一般的な企業要件;
• 情報セキュリティの分野の要件（組織の活動分野に応じて）;
• 技術プロセスの要件（指示、アクセスマトリックス、ガイドライン、構成の要件）。

私たちの金融会社では、古くなったドキュメントを数多く見つけました。導入された新しいプロセスに従ってそれらを持ってくる必要がありました。



管理の順序で、セキュリティ、IT、ビジネス、内部統制の領域の代表を含む作業グループが作成されました。命令には、グループを作成する目的、活動の方向、存在期間、および両側の責任者の概要が示されていました。さらに、監査を実施するための方法論とロールモデルを構築するための手順を開発しました。これらは、地域のすべての責任ある代表者によって合意され、会社の経営陣によって承認されました。



作業の手順、条件、責任などを記載した書類 -誰もが一目瞭然ではない大切な目標に向かう途中で、「なぜこれを行うのか、なぜそれが必要なのかなど」という質問は誰にもないでしょう。そして、プロセスを「ジャンプオフ」したり、速度を落としたりする機会はありません。

ステップ4.既存のアクセス制御モデルのパラメーターを修正する

アクセス制御の観点から、いわゆる「システムパスポート」を作成します。実際、これは特定の情報システムに対する質問表であり、アクセスを制御するためのすべてのアルゴリズムが記録されています。IdMソリューションをすでに実装している企業は、システムの調査が始まるのはこのためです。



システムと所有者に関するパラメーターの一部はITレジスターから質問表に流れました（ステップ2、監査を参照）が、新しいパラメーターも追加されました。

• アカウントの管理方法（データベースで直接、またはソフトウェアインターフェイスを介して）;
• ユーザーがシステムにログインする方法（別のアカウントを使用するか、ADアカウント、LDAPなどを使用する）;
• システムへのアクセスのどのレベルが使用されているか（アプリケーションレベル、システムレベル、システムによるネットワークファイルリソースの使用）;
• , ;
• (, ..);
• ;
• (, .);
• ;
• (, , ., );
• ( , , .);
• (SOD – Segregation of Duties), ;
• , , , ..

リストには、アクセス制御プロセスに関連するさまざまなパラメーターやその他のオブジェクトの詳細が記載されています。

ステップ5.ビジネス指向の許可記述を作成する

ロールモデルを構築する際に必要となるもう1つのドキュメントは、情報システムのユーザーに提供できるすべての可能な権限（権利）のガイドであり、その背後にあるビジネス機能の詳細な説明が含まれています。多くの場合、システムの権限は文字と数字で構成される特定の名前で暗号化されており、企業の従業員はこれらの記号の背後にあるものを理解できません。それから彼らはITサービスに行きます、そして、そこで...彼らは、例えば、めったに使われない権利についての質問に答えることができません。次に、追加のテストを実施する必要があります。



ビジネスの説明が既に存在する場合、またはこれらの権利がグループと役割に組み合わされている場合でも問題ありません。一部のアプリケーションでは、設計段階でそのような参照を作成することがベストプラクティスです。しかし、これはまれにしか発生しないため、IT部門にアクセスして、考えられるすべての権利に関する情報を収集し、それらについて説明します。ガイドには最終的に次のものが含まれます。

• アクセス権が適用されるオブジェクトを含む、権限の名前。
• オブジェクトを使用して実行できるアクション（表示、変更など、たとえば、地域やクライアントのグループによる制限の可能性）。
• 認証コード（認証を使用して実行できる機能/システム要求のコードと名前）;
• 権限の説明（権限を適用するときのISのアクションの詳細な説明とプロセスへの影響）
• : «» ( ) « » ( ).

6

準備の最終段階では、すべてのユーザーとそのユーザーが現在持っている権利に関する情報システムからデータをダウンロードする必要があります。ここでは2つのシナリオが考えられます。まず、セキュリティ部門はシステムに直接アクセスでき、関連するレポートをアップロードする手段があります。これはまれですが、非常に便利です。次に、必要な形式でレポートを受け取るようITに要求を送信します。実務では、ITと交渉して必要なデータを最初に取得することは不可能であることを示しています。情報が目的の形式と形式で受信されるまで、いくつかのアプローチをとる必要があります。



ダウンロードする必要があるデータ：

• アカウント名
• 割り当てられている従業員のフルネーム
• ステータス（アクティブまたはロック済み）
• アカウント作成日
• 最終使用日
• 利用可能な権限/グループ/役割のリスト

そのため、すべてのユーザーとそれらに付与されたすべての権限を使用して、システムからアンロードを受け取りました。また、ロールモデルの作成作業はアクティブユーザーに対してのみ実行されるため、すべてのブロックされたアカウントをすぐに脇に置きます。



次に、解雇された従業員へのアクセスを閉じる自動化された手段がない場合（これはよくあることです）、または常に正しく機能しないパッチワーク自動化がある場合は、すべての「死んだ魂」を特定する必要があります。私たちはすでに解雇された従業員のアカウントについて話しているが、その権利は何らかの理由でブロックされていない-彼らはブロックされる必要がある。これを行うには、ダウンロードしたデータを人事ソースと比較します。人員の降ろしもまた、最初に人員基地を率いる部隊から取得しなければなりません。



それとは別に、その所有者が人事ベースで見つからず、誰にも割り当てられていないアカウント、つまり所有者がいないアカウントを延期する必要があります。このリストによると、最後に使用した日付が必要です。それがかなり最近の場合は、所有者を探す必要があります。これには、外部の請負業者のアカウントや、誰にも割り当てられていないが、プロセスに関連付けられているサービスアカウントが含まれる場合があります。アカウントの所有権を確認するには、応答を要求する手紙をすべての部門に送信できます。所有者が見つかると、システムにその所有者に関するデータを入力します。これにより、既存のアカウントがすべて識別され、残りのアカウントはブロックされます。



アップロードで不要なレコードが削除され、アクティブなアカウントのみが残ったら、特定の情報システムのロールモデルの構築を開始できます。しかし、これについては次の記事で説明します。



著者：Lyudmila Sevastyanova、Solar inRights、プロモーションマネージャー