web-dev-qa-db-ja.com

RBACを使用した職務の分離

セクション6(職務分掌)で、ロールベースのアクセス制御について 記事 を読んでいますが、この部分がわかりませんでした。

職務の分離は、staticまたはdynamicのいずれかです。静的分離要件への準拠は、役割への個人の割り当てと役割へのトランザクションの割り当てによって簡単に決定できます。より困難なケースは、動的な義務の分離であり、要件への準拠はシステムの動作中にのみ決定できます。

誰かがそれを明確にできますか?

2
Bilal

引用 このSANS記事

職務の静的分離は、役割メンバーシップを定義します相互に排他的です。たとえば、RBACは、ユーザーが購入ロールと承認ロールの両方のメンバーになることができないようにすることができます。 SSDは、このようにして、同じ人物が購入および購入を承認できないようにします。

動的な職務分離は、同じ人物が購買ロールと承認ロールになることを許可しますが、自分の購入を承認することは禁止されています。彼らは他人の購入を承認することしかできません。

もう1つの例は、ファイアウォール構成の変更を行った人が監査および同じ変更を承認することを制限することです。 SSDモデルでは、ユーザーは両方のロールのメンバーではない場合があります。 DSDモデルでは、ユーザーは両方のロールのメンバーになることができますが、同じリンクされたトランザクションの両方の機能で機能することはできません。

2
A. Darwin

彼らが参照しているのは、静的な場合は非常に厳格であるか、動的な場合のように少し順応性があるルールセットです。

この記事の例を使用して、もう少し詳しく説明します。

静的ポリシーには、支払い開始者として機能できるno individua lが必要とする可能性がありますalso支払い認証者として機能することもできます。これは、開始者の役割を実行できるユーザーが承認者の役割も実行できないようにすることで実装できます。

したがって、この場合、職務分離に関する静的ポリシーは、1人が支払い開始者の役割を引き受けることを許可しない[〜#〜]および[〜#〜]支払いオーソライザ。彼らは支払いを開始するか、それらを承認することができます。このルールは厳格です。つまり、どちらかの役割を引き受けることができず、[〜#〜] only [〜#〜]オーソライザーまたは[〜#〜]です。 only [〜#〜]イニシエーター。

例:ボブがイニシエーターであり、ベッキーがオーソライザーです。ベッキーが仕事に現れない場合、ボブは承認者であるベッキーの役割を果たすことはできません。

動的ポリシー:

同じ個人を許可する動的ポリシーによって、より柔軟に両方を引き受ける開始者と承認者の役割を許可することができますが、例外は彼または彼女が開始した支払いを承認することはできません

したがって、この場合、義務の分離に関する動的ポリシーは、1人が支払いを開始することを許可しない [〜#〜]および[〜#〜]それらを承認します。彼らは支払いを開始するか、それらを承認することができます。これは動的なポリシーであるため、必要に応じていずれかの役割を引き受けることができますが、できなかった両方の役割を引き受けます同時に

例:ボブがイニシエーター、ベッキーがオーソライザーです。ボブは仕事に現れません。 Beckyは、Bobが開始するように介入できますが、同じ支払いを承認することはできません。第三者、ビル、支払いを承認する必要があります。 (または、ボブが戻ってくるまで待ちます)

それの長いものと短いものは次のとおりです:義務を分離する静的ポリシーは厳格、あなたの役割はあなたの役割であり、タスクを完了するために「他人の帽子をかぶる」ことはできません。 義務を分離する動的ポリシーはそれほど厳格ではありません、そして柔軟性を可能にしますが、プロセスの完全な制御を1人の個人に与えることは決してありません。

1
INV3NT3D