0

LDAP は初めてで、マルチレベル セキュリティ モデルを実装するための最適なセットアップを見つけようとしています。同じユーザーが複数のアプリケーションを使用しており、ユーザー管理を一元化したいため、LDAP が必要です。

マルチレベル セキュリティ モデルとは、次のことを意味します。会社、プロジェクト、ユーザー、役割があります。

会社、プロジェクト、ユーザーの組み合わせごとに役割を割り当てたい。したがって、companyA、projectA、および userA の組み合わせには RoleA がありますが、companyA、projectB、および userA の組み合わせにはありません。

該当する会社、プロジェクト、役割の組み合わせごとに「レコード」を返すユーザーの LDAP 検索を実行できる必要があります。

たとえば、次のようにセットアップされたLDAPサーバーに「オブジェクトツリー」を作成することを知っています

companyA
   |
   +---- project A
   |       |
   |       +----- roleA
   |               |
   |               +---- (attribute) member=userA
   |               +---- (attribute) member=userB
   |
   +---- project B
           |
           +----- roleB
                   |
                   +---- (attribute) member=userA
                   +---- (attribute) member=userB

しかし、これには多くのオブジェクトの重複が含まれており、私には非効率的です。

データ、会社、プロジェクト、役割、およびユーザーの 4 つの「リスト」と、これらのエントリの組み合わせを含む別のリストが必要です。リレーショナル データベースの経験が豊富なため、これはより論理的に感じられます。しかし、このセットアップは LDAP 環境ではまったく論理的ではないことを認識しています。

アクセス制御を提供できるldapについて読みました。ACI (アクセス制御命令) を使用すると、特定のユーザーに特定のオブジェクトへのアクセス権を与えることができます。たぶん、これを何らかの方法で利用して、必要なものを提供できますか？

4

1 に答える 1

0

このセットアップの「理由」について明確な実際的な理解はありませんが、いくつかの指針を提供することはできます。これらのアイデアを吟味して他の人と話し合う必要があることを覚えておいてください。また、その意味を理解していることを確認してください。

ユーザーが重複している場合（例：ユーザーAがプロジェクトAとプロジェクトBの両方に関与している場合）、あなたが述べたようにデータが重複することは事実です。さらに、これは望ましくないユーザー エクスペリエンスにつながる可能性があります。ユーザー A が 2 つのアカウントを持っている場合、パスワードも 2 つ持っているため、何らかの方法で管理する必要があります。そのような極限が組織の要件でない限り、ユーザーは間違いなくそれを楽しむことはありません. さらに、ユーザー管理をさらに細分化するのではなく、一元化したいとおっしゃいました。;-)

あなたの状況では、少し変わったアイデアを提案できます。

複雑な DIT (「リレーショナル」用語でデータベースまたはテーブルと呼ぶもの) を活用する代わりに、カスタム スキーマを活用することを検討してください。

AUXILIARY OBJECTCLASS として知られるものを作成することも考えられます。OBJECTCLASSES は静的であるため (入力可能な属性ではなく、ある意味で単なる「タグ」) を使用することを好みます。

たとえば、あなたの場合、いくつかの AUX OC を作成できます。

  • objectClass: companyA
  • objectClass: companyB
  • オブジェクトクラス: projectA
  • オブジェクトクラス: projectB
  • objectClass: roleA
  • オブジェクトクラス: roleB

人は、これらの OC を任意の数 (ゼロ、1 つ、またはすべて) 持っている可能性があります。

その結果、ユーザーの SINGLE アカウント (したがって、SINGLE パスワード) が作成されます。これらの各ユーザーは、適切と思われる OC の任意の組み合わせを持つことができ、必要に応じてカスタム フィルター (クエリ) を利用するようにすべてのクライアント (例: LDAP サーバーを使用するシステムとソフトウェア) を構成できます。 .

これの欠点は、(通常) スキーマ データが実際の DATA のように複製されないことです。そのため、LDAP サーバーが 3 つある場合は、このスキーマ データを 3 つの LDAP サーバーにロードする必要があります。OpenLDAP の新しいバージョンは動的構成をサポートしており、非常に特殊なセットアップでは、CONFIGURATION エンジンの設定を複製することは可能ですが、これは、理論的なドキュメントを除いて、実際に誰かが行っているのを見たことがないまれなセットアップです。その精神で、私はこれがあなたのためのオプションではないと仮定するつもりです. 私が間違っている場合は修正してください。

あなたの ACI のアイデアに関しては、それらを使用するメリットはあまりありません。ACI は十分に文書化されておらず、実験的なものです (また、使用している LDAP サーバーのビルドにコンパイルされない場合もあります)。

必要なのは ACL (アクセス制御リスト) です。特定の人やグループによる特定のオブジェクトへのアクセスを制御できます。ACL はより適切に文書化されており、実験的ではありません。

これが役立つことを願っています。質問等ありましたらおっしゃってください。

マックス

于 2013-07-20T22:30:27.877 に答える