情報システムで役割モデルを構築するには、2つの方法があります。
最初のアプローチ
役割は、機能モデルに基づいて開発されます。このアプローチは、組織に技術者の特別な部門がある場合に可能です。これを「組織技術部門（OTO）」と呼びましょう。私たちの銀行では、そのような部門はIT部門の一部でした。部門は、機能モデルで説明されているビジネスニーズをIT言語、つまり特定の機能を実行するためにシステムで提供する必要のある権利/オプション/権限の言語に変換します。
このアプローチは、新しいシステムが稼働し、ロールモデルが最初から形成される場合にも適しています。まず、システムのITマネージャーと一緒に、システム内に内部の役割またはグループがあるかどうか、権利がどのように付与されるかを理解する必要があります。次に、ビジネスユニットの責任者や一般的な相対性の技術者と一緒に、必要な権利を含む役割を開発する必要があります。次に、作成した役割は調整されなければならない業務からシステム所有者であるため、彼は、システム間の競合を回避するための内部制御部門およびセキュリティ部門とともに、ビジネスプロセスの実行を担当しています。会社の承認されたセキュリティポリシーに違反しないようにします。その後、承認された役割モデルに従って、システムを運用し、権限を割り当てることができます。
2番目のアプローチ
役割は、従業員にすでに付与されている既存の権利から形成されます。ほとんどの場合、これはまさにあなたがしなければならないことです。システムは長い間運用されており、長年の運用で蓄積されたユーザー権限の混乱を整理する必要があります。ここにはいくつかの特徴があります。
システムがそれほど大きくなく、異なる権利がほとんどない場合、同じ役職の従業員間で共通の重複する権利を特定することは難しくありません。それらから、役割を構成し、最初の場合と同様に、承認と承認のためにリソースの所有者であるヘッドに送信し、さらにチェーンに沿って送信することができます。システムに多くの権利（権限）があり、さまざまな部門の多数の従業員によって使用されている場合、タスクはより複雑になります。この場合、専門のユーティリティが助けになります。タスクを簡単にする役割マイニング。彼らは、特定の仕事に一致する資格を、利害関係者によってレビューおよび承認される標準的な役割に収集します。
2番目のアプローチを使用した役割モデルの構築
大規模な金融会社では、2番目のアプローチを使用して役割モデルを構築し、すでに機能しているシステムに秩序をもたらしました。ユーザーの権限が少ない方のために、クリアされたサンプル（アクティブユーザーのみ）を取得しました。各システムの役割マトリックスに記入するためのテンプレートを開発しました：役割マトリックスは、会社の部門とその中の位置に関連する役割（一連の権利）であることを思い出してください。テンプレートは、完成のためにこれらのシステムの所有者に送信されました。次に、システムが使用された部門から情報を収集し、情報セキュリティおよび内部制御サービスとのさらなる調整のために、すでに完成したテンプレートを返しました。完成したテンプレート、つまり役割マトリックスは、役割ベースのアクセスの許可と、将来の自動化プロジェクトへの組み込みに使用されます。
残念ながら、そのようなマトリックスはなく、すべての権利を明確に役割に分割でき、役割はポジションに関連付けられているようなシステムはありません。この場合、あなたはかなり普遍的な役割を得ることになり、権利のいくつかは冗長になるからです。または、逆に、役割が多すぎて、これは役割ベースではなく、最初の部分で説明した任意の方法に基づく個人アクセスになります。多くの場合、大規模な組織では、役職には役割は必要ありませんが、特定の機能には必要です。たとえば、複数の従業員が同じ役職に就いていて、異なる機能を実行する場合があります。したがって、デフォルトで割り当てられる基本的な役割に同じ機能の一部を追加することは理にかなっています。そして、個々の要求に対する権利の登録のための従業員のユニークな機能のいくつかを残し、会社が定めた手順に従って承認のために送信されます。
役割マトリックスに記入するためのテンプレートの例
テンプレートは次のようになりました。左側の最初のシート（垂直方向）に位置と部門がリストされ、上部（水平方向）に役割がリストされています。交差点では、どの部門がどの役割を必要としているかを示すマーカーを設定する必要がありました。色付きの塗りつぶしでマークしました。緑-ポジションへの任命時にデフォルトで提供される役割。黄色-個別の追加リクエストで特定の役職または部門にリクエストできる役割。
2枚目には、個人の権利（権力）による役割の遂行を示すガイドを配置しました。
3番目のシートには、SODの競合（役割の可能な組み合わせの禁止）のマトリックスが含まれています。
最初の概算でSODの競合のトピックにアプローチしたことを、すぐに言わなければなりません。これは、独自のプロセスを持つ別個の大規模なアクティビティです。特定の権限の組み合わせの禁止は、個別の役割内、役割間、およびシステム間の相互作用の両方で確立できます。さらに、SODの競合を処理するプロセスを設定し、それらに対応するためのシナリオを開発することが重要です。これは個別に検討するトピックです。
多くのユーザーとかなり多様な権利構造を持つシステムの場合、手動でマトリックスを作成することは非常に困難です。これらの目的のために、ロールモデルを構築するための専用ツールを使用しましたロールマイニング..。これらのツールは、作業のロジック、コスト、使いやすさ、およびその他の特性が大きく異なる可能性があります。しかし、共通の運用原則と目標は、情報システムにおける従業員の現在の権利に関する情報を収集し、同じ属性を持つ従業員に対するこれらの権利の繰り返しを分析し、これらの権利を役割に結合し、最終的には、現在を反映する特定の基本的な役割モデルを構築することです。状態。
現在、時間の経過とアクセス制御用のソフトウェアを開発する会社で働いていることで、大規模なシステムで役割モデルを構築するより効果的な方法があることに気付きました。組織が自動整理ツールを採用するのが早ければ早いほど、役割モデルの構築プロセスはよりスムーズで簡単になります。この場合、自動化されたシステムは、役割の構築を支援または支援します。自動アクセス制御システム（IdM / IGA）の実装は、データをアップロードし、それらのマッピングと分析を行うために、人事ソースとターゲットシステムを接続することから始める必要があります。アクセス制御ソリューションに組み込まれている専用ツールを使用することで、最初から自動化に基づいて必要なプロセスを効果的に構築できます。これにより、人件費が大幅に削減され、将来的にショック療法が排除されます。たとえば、アカウントを操作するプロセスは、最初の段階で、はるかに高速かつ効率的になります。
- 見つかった不正なアカウントをブロックし、
- 孤立したアカウントの識別、
- 外部の従業員アカウントの識別と登録など。
- 従業員を雇用するときにアカウントの作成を自動化し、解雇時にアカウントをブロックします。
そして、すでに第2段階では、自動アクセス制御システムを使用することで、ユーザー権限の操作効率を高め、特に次のような役割モデルを構築することができます。
- さまざまなユーザーの権利を比較するさまざまな方法を適用し、
- 自動化されたロールマイニングと特定のカテゴリのユーザーの一致する権利の識別を実行し、その後の分析と承認を行います。これにより、必要なアクセス権マトリックスの作成がはるかに高速かつ簡単になります。
アクセス権の新しい規制を実施しています
新しいアクセス制御規則（アクセスの許可、変更、取り消し）に従って、新しい構造を考慮して会社に住み始めることができるようになりました。この規制には何を含めるべきか：
- アクセス権は、特定の情報システムの役割モデルの有無によって決まります。上記のように、すべてのISの役割マトリックスを一度に作成することは不可能です。承認された計画に従って、徐々に行動する必要があります。
- 承認された役割モデルがまだシステムに含まれていない場合は、少なくとも、部門の責任者およびリソースの所有者と権利について合意する必要があります。
- 役割モデルが開発および承認された場合、それに基づいて権利が割り当て/変更されます。
- , .
. , , , .
. -, .
-, , , . IdM/IGA-, , . , , . , . , , . - . , .. , , . , , . . , .
役割モデルを静的にすることはできません。彼女は、生き物のように、組織で起こっている変化に適応しなければなりません。それを修正する理由は何ですか？
1つ目は、組織とスタッフの構造の変更です。大規模な組織では、私自身の経験からこれを確信していました。そのような変化はほぼ毎日発生する可能性があります。多くの場合、変更は部門や役職の名前変更に関連しています。同時に、機能は同じままですが、それでも、これらの変更はロールモデルに反映され、すべての調整はタイムリーに行われる必要があります。部門の合併、または逆に、別々のグループ/部門への分割がある場合、変更はよりグローバルになります。これらは、機能モデルを更新し、それに基づいて既存の役割を変更するために、改訂が必要な従業員の機能に影響を与えます。または、役割モデルで新しい役割を設計および実装します。
2つ目は、会社のビジネスプロセスの変更です。ビジネスを静的にすることはできません。各部門の作業を改善できる新しいプロセスとメカニズムが導入されています。これにより、顧客サービスが向上し、売上が増加し、戦略的目標の達成に役立ちます。それぞれの新しいビジネスプロセスの導入は、役割モデルに織り込む必要があります。新しい役割が表示されるか、既存の役割を改善する必要があり、新しいオプションと権限を含める必要があります。
3つ目は、システムアーキテクチャの変更です。企業は定期的に古いシステムを廃止し、新しいシステムを運用しています。古いシステムが廃止され、そこで従業員が実行した機能を新しいシステムに移す必要があるとします。これを行うには、古いシステムのすべての役割とそれらの関連性を修正し、新しいシステムの作成された役割を分析し、古い役割と新しい役割の比較マトリックスを作成する必要があります。いくつかの移行期間中、必要なすべての機能が新しいシステムに転送され、役割モデルが改良されるまで、これらの役割が並行して存在する可能性は十分にあります。次に、古いシステムの役割の使用を停止し、ユーザーアクセスを取り消して、古いシステムのデータをアーカイブに送信できます。
私たちが見たすべての変更は、役割モデルを最新の状態に保つために別のプロセスが必要であることを示唆しています。情報リソースへのアクセスに関連する組織のすべての活動を考慮に入れる必要があります。必要なすべての変更が時間内に行われるように事前に計画されている役割モデルを更新するプロセスを含める必要があります。これは、自動モードまたは手動モードで役割を変更するためのアプリケーションの開始、および変更の調整と承認、および関連するプロセスの更新によるそれらの試運転です。これはすべて、役割モデルを維持および更新するための規則に記録する必要があります。この場合、プロセスの各ステップの責任者を示す必要もあります。
上記の理由による役割モデルの変更に加えて、体系的かつ計画的な権利の改訂が必要です。特に金融会社の場合、このような定期的なレビューは監督者によって要求されます。改訂は、既存の権利モデルのギャップを特定し、ユーザー権利の管理を改善するのに役立ちます。この問題の解決策は、IGA / IdMシステムによって大幅に簡素化されます。これにより、特定の頻度で改訂（再認証）のプロセスを自動化できます。
まとめましょう
役割ベースのアクセス制御により、企業の情報セキュリティのレベルが向上します。アクセスがより透過的になり、管理および制御されます。また、管理面でのIT部門の負担も軽減されます。ロールベースのアクセス制御で何が簡単にできるでしょうか？
- 同じ役職または同じ部門で働く多くの従業員に同じ権利を付与することができます。彼らに同じ役割を与えるだけで十分です。
- 数回クリックするだけで、1つのポジションの従業員の権限をすばやく変更できます。共通の役割の一部として権利を追加または削除するだけで十分です。
- 役割の階層を構築し、権限を継承するためのルールを設定できるようになります。これにより、アクセス構造が簡素化されます。
- 権限の分割（SOD）に入ることができます-ある役割と別の役割の組み合わせの禁止。
ただし、ロールモデルを構築するだけでは、大企業における高品質で効果的なアクセス制御の問題は解決されません。これは、ステップの1つにすぎません。役割モデルを構築してこれを落ち着かせると、しばらくすると時代遅れになり、行われたすばらしい作業はまったく役に立たなくなります。どうして？
- - , , - .
- - , -.
- .
- C .
- , , , .
- .
これらすべての理由は、重要なのはアクセス制御のための一連の対策であることを示しています。自動化ツール、作業プロセスとメカニズム、それらのサポート、開発、更新、および会社のライフサイクルに応じたスケーリングが必要です。
著者：Lyudmila Sevastyanova、プロモーションマネージャー、Solar inRights