会社が1人で構成されている場合、内部の秘密はありません。 すべてのアクションと情報は、唯一の従業員が利用できます。
会社が成功し、仕事の量が増えている場合、一人が対処しなくなる時が来ます。 そして、新しい従業員が会社に採用されます。
しかし、会社の従業員の数が増えると、次のような他の問題が発生します。
- 各従業員は自分のビジネスタスクのみを実行し、見知らぬ人にはアクセスできません。
- 各従業員には、ビジネスタスクに関連する情報のみが表示されます。
- 各タスクには、その実装を担当する従業員が必要です。
これらの問題を解決しないと、会社は次の理由で経済的損失を被る可能性があります。
- 無能による他の人のタスクの非効率なパフォーマンス;
- 他の人のタスクにおける意図的または意図しないミス;
- 権限のない人への情報の開示。
これらの問題を解決し、アクセスを正しく区別するには、どの従業員がアクション（認証）を実行したいか、そしてそれを実行できるかどうか（許可）を理解する必要があります。
最も難しいのは認可の問題です。 ソリューションにはいくつかのアプローチがありますが、現在、ロールベースのアクセス制御（RBAC）が最も広く使用されています。
役割ベースのアクセス制御（RBAC）
このアプローチの本質は、社内でビジネスロールを繰り返すロールを作成し、それらをユーザーに割り当てることです。 これらのロールに基づいて、アクションを実行するユーザーの能力がチェックされます。
ビジネスルールが1次元であり、すべてのアクションをロール（会計士、マネージャー、管理者など）に分割できる場合、そのようなアプローチで十分です。 次に、1つのロールが1つのビジネスルールに対応します。
しかし、ビジネスルールは必然的に、より複雑で多次元になります。 これにより、ビジネスルールを表現するための1つの属性（ロール）が不十分になり、他の属性（都市、国、支店、曜日、所有者、制限など）が追加され始めます。
この複雑さに対処するには、追加のロールを作成する必要があります。このロールの数は、すべての属性のさまざまな組み合わせの数に等しくなります。
新しい属性値を追加するたびに、新しいロールを追加する必要があります。 つまり、ブランチ「G」が表示される場合、「ブランチの管理者」G「」、「ブランチの管理者「G」、「ブランチの会計士」G」などの新しいロールを追加し、必要なすべての従業員を割り当てる必要があります役割。 これはすべて、多くの日常的な手作業を引き起こします。
さらに、他の問題が表示されます。
- 1つのビジネスルールが多くの役割の間で「広がり」、明白ではなくなるため、このルールとそのサポートの理解が複雑になります。
- 役割の数の爆発的な増加が始まり、管理が非常に複雑になります。
また、値が事前にわからず、作業の過程で計算される属性を使用するビジネスルールは、ロールモデルを使用してまったく表現できません。
また、アクションではなくデータへのアクセスを制限するビジネスルールもあります。 このようなビジネスルールは、ロールモデルを使用して表現することもできません。
このようなビジネスルールのサポートを実装するには、他のツールを使用する必要があります。これにより、アクセス制御システムの実装と保守がより高価で複雑になります。 ビジネスルールが多次元になるか、データ制御が必要になるとすぐに、ロールモデルは現在のアクセス制御の問題を解決するだけでなく、新しい問題を作成します。
属性ベースのアクセス制御（ABAC）
RBACフレームワーク内で解決できない問題に対処するために、属性に基づく別のアプローチが作成されました。
このアプローチの主な違いは、各状況がユーザーの役割と実行したいアクションの観点からではなく、それらに関連する属性の観点から評価されることです。
実際、ビジネスルールは、さまざまな属性がそれらの要件を満たす必要がある一連の条件です。
属性のいくつかのカテゴリを明確に識別できます。
許可を実行するために、すべての属性の値が権利のチェック時に取得され、予想される値と比較されます。 すべての条件を満たせば、リソースにアクセスできます。
単純なルールは、単純な条件によって記述されます。
このモデルの多次元ルールはこれ以上複雑になりません。
新しい属性値を追加しても、ビジネスルールの条件は変わりません。 つまり、ブランチ「G」が表示された場合、ビジネスルールの条件では、何も変更する必要はありません。 必要なのは、属性「支店」-「支店」Gを必要な従業員に追加することだけです。
このようにして、ABACはRBACに現れる問題を回避します。
- ビジネスルールはシステムによって「広がらない」ため、理解とサポートが十分に簡単になります。
- 条件の数が爆発的に増加することはなく、メンテナンスが簡単になります。
しかし、最も重要なことは、ABACを使用すると、RBACでは解決できない問題を解決できることです。このアプローチには、ビジネスルールの複雑さに対する制限がないためです。 以前は未知の属性を使用していたものを含む、あらゆる複雑なビジネスルールは、新しい問題を作成せず、保守が容易です。
データをフィルタリングするための一連の条件の形式でビジネスルール表現を使用すると便利です。 一部の条件はリソースにアクセスする前でも計算でき、残りの条件はデータを選択するためのフィルターになります。
データにアクセスする前に、最初の3つの条件を確認できます。 最後の条件は、許可されたデータのみを取得するための述語として使用できます。
ABACとRBACの比較
比較からわかるように、RBACは単純なビジネスルールの実装にのみ適しています。 ルールの複雑さが増すと、アクセス制御システムをサポートするコストが増大するため、RBACを使用する可能性が低下し、ルールの特定のレベルの複雑さから始めて、このアプローチでは結果が得られません。
一方、ABACはビジネスルールの複雑さを制限しません。 より理解しやすいビジネスとコンパクトな表現のおかげで、このアプローチにより、より複雑なルールを実装するときにサポートのコストを増やすことなく、アクションだけでなくデータにもアクセス制御を提供できます。
PS：今日、ABACには標準のXACMLがあり、積極的に開発され使用されています。 次の記事でそれについてさらに学ぶことができます。
ABAC、XACML、およびそれらの使用に関する興味深い有用なリンク：