8

私はRESTを介して公開しているAPIを持っており、当局の制限をどこに置くかについて検討しています。
サービスレイヤーは作業を行うものであり、どこに呼び出されるかわからないため、サービスレイヤーのセキュリティ保護に関するベストプラクティスがあることを読みましたが、WSに関するベストプラクティスはわかりません。層。
私が持っている考えの1つは、一方ではDRYの原則に違反することを最小限に抑えるために、サービス層に非常に細かい承認モデルを、WS層に非常に粗い承認モデルを用意する必要があるということです。多層防御。

例：

Usersリソースには、とUserWSがありUserServiceます。管理者はユーザーを作成/更新/削除でき、ユーザーは他のユーザーについて読むことができます。がバインドされている
と仮定すると、そこに到達するにはユーザーである必要があるとだけ言っている権限を 持つそのURLのを定義しますが、サービスレイヤー自体が関連するメソッドの特定の権限を指定します。UserWS%root%/usersintercept-urlROLE_USER

その他のオプションは次のとおりです。

  • サービスとWS-Proの両方に同じ認証要件を設定し
    ます-できるだけ早く侵入者を除外します（たとえば、spring mvcを使用している場合はパラメーターの変換を保存します）
    構成の重複はメンテナンスです問題が発生し、エラーが発生しやすい=>セキュリティの問題


  • WS Con-から来る場合は、できるだけ早くWS-Pro-Filterにのみ許可要件を設定します
    。サービスレイヤーは異なるコンテキストから使用される可能性があります。

  • 承認要件をサービスにのみプレートします
    -Pro-重複なし
    の問題-「率直に」不適切な要求がサービスレイヤーに到着することを許可するオーバーヘッド

オプションについてのフィードバックを本当にいただければ幸いです

4

2 に答える 2

6

Ittai、WS層とサービス層の両方でまったく同じセキュリティメカニズムを使用することは、自分自身を繰り返すと見なされます-そして、これらの2つのレベルでのメンテナンスが必要です。WSレイヤーにセキュリティがないことは悪いことです-実際には誰でもシステムに侵入できるようにするためです（後でブロックする場合でも-多くの人はそれを悪いことだと考えています）。要するに、これら2つを混同する必要があると思います-WS層で非常に大まかなメカニズムを使用し、サービス層で非常に強力なメカニズムを使用します。これにより、繰り返したり、両方の場所でコードを維持したりする必要がなくなります（同じセキュリティレベルではありません）; また、小さめのユーザーをできるだけ早く除外することができますが、それでも、配置する必要のある場所に非常に高いセキュリティレベルがあります。

于 2012-05-20T07:05:28.743 に答える
0

時間がある場合は両方、時間がない場合はサービスレイヤーのみと言います。

プレゼンテーションとサービスを保護することは常に良いことです。なぜなら、サービスをプレゼンテーション以外のものに公開する場合 (たとえば、Web サービスを公開する場合) は、セキュリティを適切に配置し、既に完了しているからです。

また、誰かがプレゼンテーション レイヤーをバイパスする方法を見つけた場合 (層があり、リモート マシンでサービスが実行されているとします) も、セキュリティを確保できます。

于 2012-05-16T08:45:16.727 に答える