4

コンテクスト

ZendACLについて読んでいます http://framework.zend.com/manual/en/zend.acl.html

質問

1台のサーバーで3つのZendアプリケーションを実行しています。

  • 私のフロントエンドアプリ
  • 私のフロントエンド-メンバーアプリ
  • 私のバックエンドアプリ（サイト所有者の管理者）

アプリケーション内で、2種類のACLを使用することを検討しています。

  • アプリケーション全体のACL-「アプリACL」の権限は単に「アクセス」（または「読み取り」（または「SendHTTPRequests」）と呼ぶこともあります））
  • アカウント全体-他のすべての権限を個々の「アカウントACL」に任せます

これにより、スパマーやその他の攻撃者をブロックしやすくなると思います

if (UserActivityScoresHighProbabilityOfHacking_Specification->IsSatisfiedBy(User))
 {
 User->addrole(Attacker)
 }

おそらく、次のようなルールがあります。

フロントエンドアプリのアクセス制御

  • 名前=攻撃者
  • 一意の権限=なし
  • 権限の継承元=N/ A
  • 名前=ゲスト
  • 一意のアクセス許可=SendHTTPRequests
  • 権限の継承元=N/ A
  • 名前=メンバー
  • 一意のアクセス許可=SendHTTPRequests
  • 権限の継承元=ゲスト
  • 名前=管理者
  • 一意のアクセス許可=（すべてのアクセス許可）
  • 権限の継承元=N/ A

他のアプリには、ゲストへのアクセスを拒否するためのより厳しいルールがあります。

したがって、答える質問は次のとおりです。

「攻撃者」の役割（否定的な役割）をユーザーに割り当てることは、賢明なことだと思いますか。

または、これは一般的なベストプラクティスに反しますか？

4

4 に答える 4

4

ACL の使用には、基本的に 2 つの哲学があります。

  1. 起動時にすべてを拒否し、ブラックリスト/ホワイトリスト/許可と必要なすべてのチェックを確認した後にのみリソースへのアクセスを許可します。

  2. 起動時にすべて許可してから、チェック後にのみアクセスを許可する機密領域へのアクセスを拒否します。

私は通常、最初のものを使用することを好みます。2 番目の方法は、保護するエリアが小さく、大部分がパブリック ゾーンである場合に適しています。呼び出しごとにチェックを行うと、アプリケーションに多少の重みが加わります。

于 2009-12-17T16:26:50.260 に答える
2

数日間熟考した後...上記の私の質問に対する私の答えは次のとおりです。

「攻撃者」の役割（否定的な役割）をユーザーに割り当てることは、賢明なことだと思いますか。

私の答え：

いいえ、それは非常にばかげたことです。

なぜ

koenとRobertHarveyによって概説された問題は別として。

ACLを使用すると、役割を継承できるため、2つの役割が状況に適用可能になった場合、正と負の役割を持つと、複雑さと競合が発生する可能性が高くなります。

私は次の意味で「ポジティブ」を意味します：

  • 「彼らがこの役割である場合にのみ、誰かに何かをさせてください」

次の意味での「ネガティブ」とは対照的です。

  • 「この役割でない場合にのみ、誰かに何かをさせてください」

したがって、「ハッカー」を定義する役割を追加する場合は、（ネガティブを否定することによって）ポジティブに保つ方がよいでしょう。つまり、「ハッカーではない」ということです。または、そのロール名を言い換えると、「FriendlyUser」です。

すべてポジティブ：

  • +Role1：FriendlyUser
  • +役割2：ゲスト
  • +役割3：メンバー
  • +役割4：管理者

混合とは対照的に：

  • -役割1：ハッカー
  • +役割2：ゲスト
  • +役割3：メンバー
  • +役割4：管理者

2番目の役割リストははるかに混乱しています。

于 2009-11-12T01:28:23.833 に答える
1

ユーザーが共通のIPアドレスを共有することは珍しいことではないので、IPによってユーザーを禁止することがどれほど実用的かはわかりません。

フォームタイプのものの場合、スパマーはキャプチャで停止するのが最適です。

于 2009-11-09T22:16:12.910 に答える
1

ユーザーが何を行っているか、何を持っているかに基づいてロールを割り当てる際の問題は、コードにルールをハードコーディングすることです。あなたの例の暗黙のルールは次のとおりです。

deny user access when user has property/behavior X

これがハードコーディングされていることを確認する方法は、調整したい場合に何が起こるかを自問することです。疑わしい動作が少し厳しすぎることに気付き、もう少し許容したい場合は、file.php に移動して変更する必要があります。

あなたの最善の策は、ルールのアサーション部分を調べることだと思います：

http://framework.zend.com/manual/en/zend.acl.advanced.html

特定のニーズに応じて、これらは優れたソリューションになる可能性があります。

編集：コメントへの回答 - >あなたの指摘に感謝します。これは、RBAC が属性ベースのアクセス制御のようなより強力なアクセス制御に置き換えられる理由を示していると思います。これにより、制御下にあるユーザーおよびオブジェクト/リソースの属性に基づくルールが可能になります。理想的には、アクセス制御に可能な限り多くのアクセス許可決定ロジックを含める必要があります。ユーザーにロールを暗黙的に割り当てると、意思決定の一部がアクセス制御の範囲外になります (たとえば、どのユーザーが管理者になるかは、ほとんどの場合、Web サイトの所有者などによって決まります)。ただし、ACL によって制御されないアクセスのレイヤーが追加されるため、ACL の外部での意思決定を最小限に抑える必要があります。したがって、誰が特定の役割を持つかを決定することは、多くの場合、暗示的であり、ACL の範囲外です。しかし、それは何らかのロジックによって決定されるアクセス制御の領域であり、そして、このドメインを処理する責任を持つロジックをできるだけ多くプログラム内に保持するのが最善です。このとりとめのないことが理にかなっていることを願っています:-)

于 2009-11-10T20:32:01.547 に答える