3

私たちの製品はクライアント サーバー アーキテクチャ上に構築されており、サーバーは Java で実装されています (Spring フレームワークで POJO を使用しています)。サーバーには 2 つの API レベルがあります。

  • REST Web サービスを使用する外部 API - 外部クライアントおよび他のサーバーとの統合に役立ちます。
  • 純粋な Java クラスを使用する内部 APIは、内部の実際のコード (ビジネス ロジックが API 呼び出しを何度も呼び出すため) や、社内外で開発され、製品の一部として展開されたプラスインとの統合に役立ちます。外部 REST API も内部 API を使用します。

最下位の API レベルでアクセスを制御したかったため、内部 API にアクセス許可チェック (Spring セキュリティを使用) を実装しました。

しかし、ここで問題が発生します。API レベルで定義されているいくつかの操作は、現在ログインしているユーザーに対して禁止されていると見なされますが、サーバー自体によってスムーズに実行される必要があります。たとえば、一部のエンティティの削除はユーザーに対して禁止されている可能性がありますが、サーバーは、ユーザーが実行した他の操作の副作用としてこのエンティティを削除したい場合があり、これを許可したいと考えています。

では、実際にログインしているユーザーには禁止されている可能性のある操作を (ある種のスーパーユーザー モードで) サーバーが実行できるようにする最善の方法は何でしょうか?

私が見ているように、いくつかのオプションがあり、それぞれに長所と短所があります。

  1. 外部レベル API (REST) でパーミッション チェックを実装します。プラグインがパーミッション チェックをバイパスするため、問題があります。
  2. リクエストが許可された後、現在のスレッドのパーミッション チェックを無効にします。危険すぎるため、禁止すべきサーバー アクションが多すぎる可能性があります。
  3. 特権モードで操作を実行するように内部 API レベルに明示的に要求します (Java セキュリティ フレームワークの PrivilegedAction と同様) - 冗長すぎます。

上記のアプローチはどれも理想的ではないため、この問題に対するベストプラクティスのアプローチは何ですか?

ありがとう。

4

3 に答える 3

2

セキュリティはモジュールの境界で適用されます。あなたのシステムは、(ほぼ) 同じ API の 2 つのレベルの抽象化にセキュリティを適用します。2 つの API 全体で二重のセキュリティ チェックを行う必要があるため、複雑に思えます。

REST に必要なメソッドを内部 API から外部 API に移行し、内部 API のセキュリティ要素を削除することを検討してください。

  • 外部 API は、(アプリの境界で) 外部クライアントのセキュリティを管理します。
  • 内部 API は、内部アプリとプラグインの使用のために厳密に予約されます (外部クライアントがバインドされていないため、喜んでハックしてください)。

アプリケーション ロジックに対するプラグインのアクセス許可を本当に制御する必要がありますか? それには正当な理由がありますか？結局のところ、プラグインはあなたの会社によって開発されます。おそらく、プラグインの開発者に何をすべきでないかを説明する正式なドキュメント、またはプラグインの安全性テスト スイートの検証 (たとえば、プラグインが "this" メソッドを呼び出さないことをアサートする) のいずれかが機能します。

これらのプラグインを「信頼できない」と見なす必要がある場合は、必要なメソッドを外部 API (アプリの境界上) に追加し、使用ごとに特定のセキュリティ プロファイルを作成します: 「restProfile」、「clientProfile」、「pluginProfile」。それぞれに、外部 API メソッドに対する特定の権限があります。

于 2009-02-25T03:56:02.273 に答える
0

Springを使用している場合は、Springを十分に活用することをお勧めします。Springは、インターセプターを使用してこれらのシステム間チェックを実行し、不正なアクションが発生した場合にそのアクションを防止できるAOPを提供します。

これについて詳しくは、Springのオンラインドキュメントをご覧ください。

お役に立てれば...

ユヴァル=8-）

于 2009-02-24T14:41:45.147 に答える