私たちは役割ベースのアクセス制御モデルを構築しています。 パート XNUMX、準備

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

私が苦労して得た顧客経験とベンダーの知識や能力を組み合わせて、大企業で役割ベースのアクセス制御モデルを作成する方法と、その結果として得られるものについて、基本的に段階的な手順を共有したいと思います。 。 私の指示は XNUMX つの部分で構成されています。XNUMX つ目はモデルを構築する準備をすることであり、XNUMX つ目は実際に構築することです。 ここからは最初の部分、準備部分です。

N.B. 残念ながら、ロールモデルの構築は結果ではなくプロセスです。 むしろ、社内にアクセス制御エコシステムを構築するプロセスの一部でもあります。 だから、長い間試合に向けて準備をしてください。

まず、定義しましょう - ロールベースのアクセス制御とは何ですか? 数万人、場合によっては数十万人の従業員 (エンティティ) を擁する大銀行があり、各従業員が数百の内部銀行情報システム (オブジェクト) に対する数十のアクセス権を持っているとします。 次に、オブジェクトの数にサブジェクトの数を掛けます。これが、最初に構築してから制御する必要がある接続の最小数です。 これを手動で行うことは本当に可能ですか? もちろんそうではありません。ロールはこの問題を解決するために作成されました。

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

通常、ロールは各情報システムの個々の従業員の権限から作成されます。 そして、各システムの役割からグローバルなビジネス役割が形成されます。 たとえば、ビジネス ロール「与信管理者」には、銀行の顧客オフィスで使用される情報システムにおけるいくつかの個別のロールが含まれます。 たとえば、主要な自動銀行システム、現金モジュール、電子文書管理システム、サービス マネージャーなどです。 ビジネス上の役割は、原則として、組織構造、つまり会社の一連の部門とその中の役職に関連付けられています。 これは、グローバル役割マトリックスがどのように形成されるかです（下の表に例を示します）。

注目に値するのは、商業構造の各ポジションの従業員に必要なすべての権利を提供する、100%のロールモデルを構築することはまったく不可能であるということです。 はい、これは必要ありません。 結局のところ、ロールモデルは常に変化する環境に依存するため、静的であることはできません。 また、企業の事業活動の変化により、組織構造や機能にも変化が影響します。 そして、リソースの十分な提供の欠如、職務内容の不遵守、安全を犠牲にして利益を求めること、その他多くの要因によるものです。 したがって、ポジションに割り当てられたときに必要な基本的な権限について、ユーザーのニーズの 80% までをカバーできるロールモデルを構築する必要があります。 そして、必要に応じて、後で別の申請で残りの 20% を要求することができます。

もちろん、「100% のロールモデルなど存在しないのですか?」と疑問に思うかもしれません。 では、なぜ、これは、たとえば、頻繁に変更されることのない非営利組織、つまりある研究機関で起こるのです。 あるいは、安全が最優先される高度なセキュリティを備えた軍産複合組織でも。 それは商業構造の中で行われますが、別の部門の枠組みの中で行われ、その仕事はかなり静的で予測可能なプロセスです。

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

小売会社の場合を考えてみましょう。この会社は何千人もの営業担当者を雇用していますが、彼らはシステム N で同じ一連の権限を持っており、彼らに対して作成されるロールは XNUMX つだけです。 新しい営業担当者が会社に入社すると、システム内で必要な役割が自動的に割り当てられ、システムには必要な権限がすべて備わっています。 また、ワンクリックで何千もの販売者の権利を一度に変更できます。たとえば、レポートを生成するための新しいオプションを追加できます。 各アカウントに新しい権限をリンクするなど、何千もの操作を行う必要はありません。このオプションを役割に追加するだけで、すべての販売者に同時に表示されます。

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

ロールベースのアクセス制御がどのようにして実現されたかに興味がある人は誰でも、
歴史に飛び込む
歴史を見てみると、IT コミュニティが最初にアクセス制御方法について考えたのは、70 世紀の XNUMX 年代に遡ります。 当時のアプリケーションは非常にシンプルでしたが、現在と同じように、誰もがアプリケーションへのアクセスを便利に管理したいと本当に望んでいたのです。 ユーザー権限を付与、変更、制御します。これは、各ユーザーがどのようなアクセス権を持っているかを理解しやすくするためです。 しかし、当時は共通の標準がなく、最初のアクセス制御システムが開発されており、各企業は独自のアイデアとルールに基づいていました。

現在、さまざまなアクセス制御モデルが知られていますが、それらはすぐには登場しませんでした。 この地域の発展に多大な貢献をした人々について触れてみましょう。

最初の、おそらく最も単純なモデルは次のとおりです。 任意（選択的）アクセス制御 (DAC – 随意アクセス制御)。 このモデルは、アクセス プロセスのすべての参加者による権利の共有を意味します。 各ユーザーは特定のオブジェクトまたは操作にアクセスできます。 本質的に、ここでは権利主体の集合はオブジェクトの集合に対応します。 このモデルは柔軟性が高すぎて維持が困難であることが判明しました。アクセス リストは最終的に巨大になり、制御が困難になります。

XNUMXつ目のモデルは、 強制アクセス制御 (MAC - 強制アクセス制御)。 このモデルによれば、各ユーザーは、特定レベルのデータ機密性に対する発行されたアクセスに従って、オブジェクトへのアクセスを受け取ります。 したがって、オブジェクトは機密性のレベルに応じて分類する必要があります。 最初の柔軟なモデルとは異なり、このモデルは逆に、厳格かつ制限的すぎることが判明しました。 企業に多数の異なる情報リソースがある場合、その使用は正当化されません。異なるリソースへのアクセスを区別するには、重複しない多くのカテゴリを導入する必要があります。

これら XNUMX つの方法には明らかな不完全さがあるため、IT コミュニティは、組織のさまざまな種類のアクセス制御ポリシーをサポートするために、より柔軟でありながら、多かれ少なかれ普遍的なモデルの開発を続けてきました。 そして現れたのは XNUMX 番目の役割ベースのアクセス制御モデルです。 このアプローチは、ユーザーの ID の承認だけでなく、システム内のユーザーの操作機能も必要とするため、最も有望であることが証明されています。

最初に明確に記述されたロールモデル構造は、1992 年に米国国立標準技術研究所のアメリカ人科学者デビッド フェライロとリチャード クーンによって提案されました。 そこでこの用語が初めて登場しました RBAC (ロールベースのアクセス制御)。 これらの研究と主要コンポーネントの説明、およびそれらの関係は、国際情報技術標準委員会 (INCITS) によって承認され、現在も有効な INCITS 359-2012 標準の基礎を形成しました。

この標準では、ロールを「組織のコンテキストにおける職務機能であり、そのロールに割り当てられたユーザーに割り当てられた権限と責任に関するセマンティクスが関連付けられている」と定義されています。 この文書では、RBAC の基本要素であるユーザー、セッション、ロール、権限、操作、オブジェクトと、それらの間の関係と相互接続を確立します。

この標準は、ロール モデルを構築するために必要な最小限の構造を提供します。つまり、権利をロールに結合し、これらのロールを通じてユーザーにアクセスを許可します。 オブジェクトと操作からロールを構成するメカニズムの概要が説明され、ロールの階層と権限の継承が説明されます。 結局のところ、どの会社にも、会社のすべての従業員に必要な基本的な権限を兼ね備えた役割があります。 これには、電子メール、EDMS、企業ポータルなどへのアクセスが含まれます。 これらの権限は、「従業員」と呼ばれる XNUMX つの一般的な役割に含めることができ、上位レベルの役割のそれぞれですべての基本権限を何度もリストする必要はありません。 「従業員」ロールの継承特性を単に示すだけで十分です。

その後、この標準には、絶えず変化する環境に関連する新しいアクセス属性が追加されました。 静的および動的制限を導入する機能が追加されました。 静的なものは、役割の組み合わせが不可能であることを意味します (上記の同じ入力と操作の制御)。 動的制限は、時間 (勤務時間/非勤務時間または日数)、場所 (オフィス/自宅) などのパラメータを変更することによって決定できます。

別に、それはについて言われるべきです 属性ベースのアクセス制御 (ABAC - 属性ベースのアクセス制御)。 このアプローチは、属性共有ルールを使用してアクセスを許可することに基づいています。 このモデルは個別に使用できますが、多くの場合、古典的なロール モデルを積極的に補完します。ユーザー、リソース、デバイスの属性、および時間や場所を特定のロールに追加できます。 これにより、使用するロールを減らし、追加の制限を導入し、アクセスを最小限に抑えることができるため、セキュリティが向上します。

たとえば、会計士が特定の地域で働いている場合、アカウントへのアクセスを許可できます。 次に、専門家の位置が特定の基準値と比較されます。 または、ユーザーが許可されたデバイスのリストに含まれているデバイスからログインした場合にのみ、アカウントへのアクセスを許可することもできます。 ロールモデルへの優れた追加ですが、多くのルールや権限または制限のテーブルを作成する必要があるため、単独で使用されることはほとんどありません。

私の「過去世」からABACを使用した例をあげましょう。 私たちの銀行にはいくつかの支店がありました。 これらの支店のクライアント オフィスの従業員はまったく同じ操作を実行しましたが、メイン システムでは自分の地域のアカウントのみを使用して作業する必要がありました。 まず、地域ごとに個別のロールの作成を開始しました。そして、繰り返し機能を備えた、しかし異なるアカウントにアクセスできるそのようなロールが非常にたくさんありました。 次に、ユーザーの場所属性を使用し、それをレビュー対象の特定範囲のアカウントに関連付けることにより、システム内のロールの数を大幅に削減しました。 その結果、役割は XNUMX つの支店のみに残り、銀行の他のすべての地域部門の対応する役職にもその役割が複製されました。

次に、必要な準備ステップについて説明します。これがなければ、実用的なロールモデルを構築することはまったく不可能です。

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

まず機能モデルを作成する必要があります。これは、各部門および各役職の機能を詳細に説明する最上位の文書です。 原則として、情報はさまざまな文書から入力されます：部門、部門、部門などの個々の単位の職務記述書や規制。 機能モデルは、関係するすべての部門 (ビジネス、内部統制、セキュリティ) と合意され、会社の経営陣によって承認される必要があります。 この文書は何のためにあるのでしょうか? ロールモデルが参考にできるように。 たとえば、システムからアンロードされ、「共通の分母に還元された」従業員の既存の権利に基づいてロールモデルを構築するとします。 次に、受け取った役割についてシステムのビジネス所有者と合意するときに、機能モデル内の特定の点を参​​照し、これに基づいて特定の権利が役割に含まれるようにすることができます。

ステップ 2. IT システムを監査し、優先順位付け計画を作成します

第 XNUMX 段階では、IT システムの監査を実施して、IT システムへのアクセスがどのように構成されているかを理解する必要があります。 たとえば、私の金融会社では数百の情報システムを運用していました。 すべてのシステムには役割ベースの管理の基礎があり、ほとんどのシステムにはいくつかの役割がありましたが、ほとんどが紙の上またはシステム ディレクトリにありました。それらはとうの昔に時代遅れであり、それらへのアクセスは実際のユーザーの要求に基づいて許可されていました。 当然のことながら、一度に数百のシステムでロールモデルを構築することはまったく不可能であり、どこかから始めなければなりません。 私たちは、アクセス制御プロセスの詳細な分析を実施して、その成熟度レベルを判断しました。 分析プロセス中に、重要性、準備状況、廃止措置計画など、情報システムに優先順位を付けるための基準が策定されました。 彼らの協力を得て、私たちはこれらのシステムのロールモデルの開発/更新を準備しました。 そして、アクセス制御を自動化するための ID 管理ソリューションとの統合計画にロールモデルを組み込みました。

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

• システムは、企業の中核活動が依存する運用プロセスにリンクされていますか?
• システムの中断は会社の資産の完全性に影響しますか?
• システムの最大許容ダウンタイムはどれくらいですか?これに達すると中断後にアクティビティを復元できなくなりますか?
• システム内の情報の整合性が侵害されると、経済的および評判の両方に取り返しのつかない結果が生じる可能性がありますか?
• 詐欺に対する重大さ。 機能の存在は、適切に管理されていない場合、内部/外部の不正行為につながる可能性があります。
• これらのシステムに対する法的要件と社内規則と手順は何ですか? 違反した場合、規制当局から罰金が科せられるのでしょうか?

私たちの金融会社ではこのような監査を行いました。 経営陣は、最も優先度の高いリストにある情報システム内の既存のユーザーと権限を最初に調査するために、アクセス権レビュー監査手順を開発しました。 セキュリティ部門がこのプロセスの所有者として割り当てられました。 しかし、社内のアクセス権の全体像を把握するには、IT 部門とビジネス部門をプロセスに関与させる必要がありました。 そして、ここで論争、誤解、そして時には妨害行為さえも始まりました。誰も現在の責任から逃れて、一見すると理解できない活動に巻き込まれたくありません。

N.B. 開発された IT プロセスを持つ大企業は、IT 監査手順 - IT 一般統制 (ITGC) に精通していると思われます。これにより、IT プロセスの欠点を特定し、ベスト プラクティス (ITIL、COBIT、IT) に従ってプロセスを改善するための制御を確立できます。ガバナンスなど) このような監査により、IT とビジネスがお互いをより深く理解し、共同開発戦略を策定し、リスクを分析し、コストを最適化し、より効果的な作業アプローチを開発することができます。



監査の分野の XNUMX つは、情報システムへの論理的および物理的アクセスのパラメータを決定することです。 私たちは、得られたデータをロールモデルの構築にさらに使用するための基礎として利用しました。 この監査の結果、IT システムの技術的パラメータが決定され、説明が記載された IT システムの登録簿が作成されました。 さらに、各システムの所有者は、そのシステムが運用されるビジネスの方向性から特定され、その所有者がこのシステムが提供するビジネス プロセスの責任者でした。 特定の IS のビジネス ニーズの技術的な実装を担当する IT サービス マネージャーも任命されました。 企業にとって最も重要なシステムとその技術パラメータ、試運転と廃止の条件などが記録されており、これらのパラメータはロールモデルの作成準備のプロセスで非常に役立ちました。

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

あらゆるビジネスの成功の鍵は、正しい方法です。 したがって、ロールモデルを構築するためにも、監査を実施するためにも、部門間の相互作用を説明し、会社の規定に責任を確立するなどの方法論を作成する必要があります。
まず、アクセスと権利を付与する手順を確立する利用可能な文書をすべて調べる必要があります。 良い意味で、プロセスはいくつかのレベルで文書化されるべきです。

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

私たちの金融会社では、古い書類が大量に見つかりました。導入されている新しいプロセスに合わせてそれらの書類を持参する必要がありました。

経営陣の命令により、セキュリティ、IT、ビジネス、内部統制の代表者を含む作業グループが設立されました。 この命令には、グループ創設の目標、活動の方向性、存続期間、各側の責任者が概説されていた。 さらに、監査方法論とロールモデルを構築するための手順を開発しました。これらは、各分野の責任ある代表者全員によって合意され、会社の経営陣によって承認されました。

仕事の進め方、期限、責任などを記載した文書。 - 最初は誰にとっても明らかではない大切な目標に向かう途中で、「なぜこれを行うのか、なぜそれが必要なのかなど」という疑問を抱く人がいないという保証。 そして、「飛び降りる」ことも、プロセスを遅らせることもできません。

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

アクセスコントロールの観点から、いわゆる「システムパスポート」を策定中です。 本質的に、これは特定の情報システムに関するアンケートであり、その情報システムへのアクセスを制御するためのすべてのアルゴリズムが記録されます。 すでに IdM クラスのソリューションを導入している企業は、このようなアンケートに精通していると思われます。これは、ここからシステムの検討が始まるためです。

システムと所有者に関する一部のパラメータは IT レジストリからアンケートに入力されました (ステップ 2、監査を参照) が、新しいパラメータも追加されました。

• アカウントの管理方法 (データベース内で直接、またはソフトウェア インターフェイスを通じて)。
• ユーザーがシステムにログインする方法 (別のアカウントを使用するか、AD アカウント、LDAP などを使用する)。
• システムへのアクセスのどのレベルが使用されているか (アプリケーション レベル、システム レベル、ネットワーク ファイル リソースのシステム使用)。
• システムが実行されているサーバーの説明とパラメータ。
• どのようなアカウント管理操作がサポートされているか (ブロック、名前変更など)。
• システムユーザー識別子の生成にどのようなアルゴリズムまたはルールが使用されるか。
• 人事システム内の従業員のレコードとの接続を確立するために使用できる属性 (氏名、従業員番号など)。
• 考えられるすべてのアカウント属性とそれらを入力するためのルール。
• システムにどのようなアクセス権が存在するか (役割、グループ、アトミック権限など、ネストされた権限または階層的な権限があるか)。
• アクセス権を分割するメカニズム (役職、部門、機能などによって)。
• このシステムには権利分離のルール (SOD – 職務分離) があり、それらはどのように機能するのか。
• 欠勤、異動、解雇、従業員データの更新などのイベントがシステム内でどのように処理されるか。

このリストはさらに続けて、アクセス制御プロセスに関係するさまざまなパラメータやその他のオブジェクトを詳しく説明します。

ステップ 5. ビジネス指向の権限の説明を作成する

ロールモデルを構築する際に必要となるもう XNUMX つの文書は、情報システム内でユーザーに付与できるすべての権限 (権利) と、その背後にあるビジネス機能の詳細な説明を記載した参考書です。 多くの場合、システム内の権限は文字と数字で構成される特定の名前で暗号化されており、企業従業員はこれらの記号の背後に何があるのか​​を理解できません。 その後、IT サービスに行きますが、そこでも、たとえば、めったに使用されない権利についての質問には答えることができません。 その後、追加のテストを行う必要があります。

すでにビジネスの説明がある場合、またはこれらの権限をグループや役割に組み合わせた場合でも問題はありません。 一部のアプリケーションでは、開発段階でそのような参照を作成することがベスト プラクティスです。 しかし、これは頻繁に起こることではないため、私たちは再び IT 部門に行き、考えられるすべての権利に関する情報を収集し、それらを説明します。 私たちのガイドには最終的に次の内容が含まれます。

• アクセス権が適用されるオブジェクトを含む、権限の名前。
• オブジェクトに対して実行が許可されているアクション (表示、変更など、地域ベースまたはクライアントのグループなどによる制限の可能性)。
• 認可コード (認可を使用して実行できるシステム関数/リクエストのコードと名前)。
• 権限の説明 (権限を適用する際の IS でのアクションとそのプロセスに対する結果の詳細な説明。
• 権限ステータス: 「アクティブ」(権限が少なくとも XNUMX 人のユーザーに割り当てられている場合) または「非アクティブ」(権限が使用されていない場合)。

ステップ 6 ユーザーと権利に関するデータをシステムからダウンロードし、人材ソースと比較します。

準備の最終段階では、すべてのユーザーとユーザーが現在持っている権利に関するデータを情報システムからダウンロードする必要があります。 ここで考えられるシナリオは XNUMX つあります。 第一に、セキュリティ部門はシステムに直接アクセスでき、関連レポートをダウンロードする手段を持っています。これは頻繁に行われるものではありませんが、非常に便利です。 XNUMX 番目: IT 部門にリクエストを送信し、必要な形式でレポートを受け取ります。 経験上、最初から IT 部門と合意に達して必要なデータを取得することは不可能であることがわかっています。 情報を希望の形式で受け取るまでには、いくつかのアプローチを行う必要があります。

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

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

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

次に、会社に解雇された従業員へのアクセスをブロックする自動化された手段がない場合 (これはよく起こります)、またはつぎはぎの自動化が常に正しく機能するとは限らない場合は、すべての「死んだ魂」を特定する必要があります。 私たちは、すでに解雇された従業員のアカウントについて話していますが、その権利は何らかの理由でブロックされておらず、ブロックする必要があります。 これを行うために、アップロードされたデータを人材ソースと比較します。 荷降ろしの人員についても、人員データベースを管理する部門から事前に入手する必要があります。

これとは別に、所有者が人事データベース内で見つからず、誰にも割り当てられていない、つまり所有者のないアカウントを確保しておく必要があります。 このリストを使用すると、最終使用日が必要になります。かなり最近の場合でも、所有者を探す必要があります。 これには、誰にも割り当てられていないが、何らかのプロセスに関連付けられている外部請負業者のアカウントやサービス アカウントが含まれる場合があります。 アカウントが誰に属しているかを調べるには、すべての部門に返信を求める手紙を送信します。 所有者が見つかると、そのデータをシステムに入力します。これにより、アクティブなアカウントがすべて特定され、残りはブロックされます。

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

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

出所： habr.com