web-dev-qa-db-ja.com

ロールベースのアクセス制御の短所

NISTによると、RBACモデルは500以上の企業で最も広く使用されているスキームです。企業の規模が関係する個人の数ではるかに大きい場合はどうなりますか。言い換えると、RBACモデルの主な欠点は何ですか？

access-controlrbac
6
user505

RBACの主な欠点は、「ロール爆発」と呼ばれることが最も多いことです。さまざまな（現実の）役割の数が増えるため（違いはごくわずかな場合もあります）、適切にカプセル化するには（RBAC）の役割の数が増える必要があります。権限（RBACの権限は、オブジェクト/エンティティに対するアクション/操作です）。これらすべての役割を管理することは、複雑な作業になる可能性があります。

RBACの基盤を形成する抽象化の選択のため、個人の権利を管理するのにもあまり適していませんが、これは通常、問題が少ないと見なされます。

一般的に提案されている代替手段は、ABAC（属性ベースのアクセス制御）です。 ABACには役割がないため、役割の急増はありません。しかし、ABACを使用すると、人々が現在「属性爆発」と呼んでいるものを手に入れることができます。 2つの問題は詳細は異なりますが、より抽象的なレベルではほとんど同じです。 （皮肉なことは、RBACソリューションの市場の飽和と、その結果としての「より新しい」「より良い」アクセス制御ソリューションの必要性を指摘するかもしれませんが、それは別の議論です。）

5
Jacco

RBACにはさまざまな問題がありますが、Jaccoが言うように、すべては役割の爆発に帰着します。

RBACは次のとおりです。

  • アイデンティティ中心、つまり、ユーザーアイデンティティ、ユーザーロール、およびオプションでユーザーグループに焦点を当てています
  • 通常、完全にIAMチームによって管理されます
  • admin-time：ロールと権限は管理時に割り当てられ、プロビジョニングされた期間有効です。

RBACでそれほど良くないことは何ですか？

  • 粒子が粗いです。医師と呼ばれる役割がある場合、医師の役割に「医療記録を表示」する権限を付与します。それは医者に彼ら自身のものを含むすべての医療記録を見る権利を与えるでしょう。これは役割の爆発につながるものです
  • 静的です。 RBACはコンテキスト情報を使用できません。時間、ユーザーの場所、デバイスの種類...
  • リソースのメタデータは無視されます。医療記録の所有者。
  • 管理と維持が困難です。多くの場合、管理者はユーザーに役割を追加し続けますが、それらを削除することはありません。何百もの役割ではないにしても、何十もの役割と権限を持つユーザーになってしまう
  • 動的な職務分離には対応できません。
  • より細かい制御を実装するために、アプリケーションレイヤー（API、アプリ、DB ...）内のカスタムコードに依存しています。
  • アクセスレビューは苦痛で、エラーが発生しやすく、時間がかかる

ABACが解決策ですか？

ABAC-属性ベースのアクセス制御-は、承認を処理する次世代の方法です。 [〜＃〜] nist [〜＃〜] と [〜＃〜] oasis [〜＃〜] のようなものとオープンソースによって駆動されますコミュニティ（Apache）およびIAMベンダー（Oracle、IBM、 Axiomatics ）。

ABACは次のような承認と見なすことができます。

  • Externalized：アクセス制御はビジネスロジックから外部化されます
  • Centralized：アクセス制御ポリシーは一元的に維持されます
  • 標準化：アクセス制御ポリシーは、OASISによって定義され、ほとんどのABACソリューションによって実装された標準であるXACML（eXtensible Access Control Markup Language）を使用します
  • Flexible：ABACはAPI、データベースなどに適用できます
  • Dynamic：アクセスの決定は実行時に動的に行われます
  • コンテキストベース/リスクベース：ABACは、決定に到達するときに、時間、場所、およびその他のコンテキスト属性を考慮に入れることができます。

ABACが提供するもの：

  • ポリシー決定ポイント（PDP）およびポリシー実施ポイント（PEP）の概念を持つアーキテクチャー
  • ポリシー言語（XACML）
  • 要求/応答スキーム（JSON/XACML）
1
David Brossard