web-dev-qa-db-ja.com

ACL / RBACハイブリッドシステム内にACLを格納するためにどのようなデータ構造を使用しましたか？

私たちのシステムでは、すべてのリソースにアクセス制御リスト（ACL）があり、そのリソースへの特定の種類のアクセス権を持つエントリ（ACE）がリストされています。 ACEは、エンドエンティティ（例：「Mr Q」のようなユーザー）またはグループエンティティ（例：「北大西洋」）に使用できます。グループエンティティを含めることで、これはハイブリッドACL/RBACシステムになります。

ACLデータ

Resource #1 => ACL
ACL => ACE#1 Entity(Type:User, ID:006), Rights(~Read, ~Write)) /* Deny */
       ACE#2 Entity(Type:User, ID:007), Rights(Read, Write))
       ACE#3 Entity(Type:User, ID:101), Rights(Write))
       ACE#4 Entity(Type:Group, ID:A01), Rights(Read, Write))
       ACE#5 Entity(Type:Group, ID:B04), Rights(Read, Write))

ACLに表示されないものはすべて拒否され、DENYは他のものを無効にします。

システム情報

上記のリソースへのアクセスを仲介する中央オンラインサーバーがあります。 ACLへの書き込みはまれですが、ほとんどの場合は読み取りです（おそらく1:50の比率以上）。

質問

上記のACLを格納するのに適したデータ構造は何ですか？ ACL全体を単一のJSON文字列としてNoSQLストアに保存するのは簡単に思えますが、ACLデータを正規化してSQLテーブルに保存することもできます。誰かがどちらかのアプローチの賛否両論の運用経験を持っている場合は、彼らから連絡が欲しい。これをLDAPに保存することは検討する価値があるが、X.500/DERやその他のテレコムソーステクノロジーに近づかないようにしたいと思っているのかもしれません...おそらく、NoSQL/SQLを超えて探索するための最新のLDAPオプション（CSの世界に根ざした）があるでしょう。 ？

access-controlauthorizationrbacnosql
9
Cat Nap

ACLを構成する最善の方法は、リソースの複雑なアクセス権をすばやく簡単に決定できるビットマスクとして使用することです。

これを格納する最適な方法は、Redisなどのキーバリューストアや、環境と適切に統合されるオブジェクトキャッシュテクノロジーなどです。 NoSQLとSQLのどちらを採用するかは、単純なルックアップがどちらの方法でも同じくらい高速である可能性があるため、技術的というよりはビジネスまたはITの決定に近いものになります。

もちろん、LDAPも優れた方法ですが、他のシステムと権限を統合しない限り、あまり意味がありません。

2
Mark Burnett