2

私は現在、drools デシジョン テーブル スプレッドシート形式を使用するビジネス ソリューションの設計を調査しています ( jboss drools ドキュメントへのリンク)。ビジネス ユーザーは、スプレッドシート内のルールを所有して維持します。

デシジョン テーブル形式を使用する主な利点の 1 つは、後でルールを簡単に変更して、さまざまなルール構造に対応できることです。

Drools は、スプレッドシート ベースのルール データをネイティブ ルール形式にコンパイルします。コンパイラの実装例は、ここで見ることができます。

セキュリティ チームからの懸念の 1 つは、ルール スプレッドシート データはユーザー入力であり、悪意のあるデータが含まれていないことを確認するために、すべてのユーザー入力が正しいことを検証する必要があるということです (入力検証の理論的根拠については、こちらを参照してください)。

質問:

  1. ビジネス ユーザーが悪意のあるデータをルール スプレッドシートに追加するセキュリティ リスクはありますか?
  2. リスクの大きさ/深刻度は? たとえば、コンパイラはユーザーが入力したデータを十分に検証しますか?
  3. リスクはどのように軽減できますか？たとえば、ルールを本番環境にデプロイする前に、別の関係者がスプレッドシートでルールを視覚的に検証します。
4

1 に答える 1

2

ルールにはJavaコードを含めることができるため、セキュリティリスクは実際には悪意のあるデータよりも大きくなります。ユーザーは、選択したJavaコードを簡単に挿入して、システムにアクセスできます。

drools verifierを使用して独自のルールを作成することはできますが、すべてのリスクを排除することはできません。

サードパーティを使用してルールを検証することは機能する可能性がありますが、検証を行う人は、リスクを正しく評価するためにプログラマーである必要があります。これにより、最初にスプレッドシートを使用する利点が打ち消されます。

私の意見では、スプレッドシートは過大評価されています。

  • あなたが言及した固有のセキュリティリスクがあります
  • 技術者以外の人がルールアクションパーツを変更してXLSファイルを壊すのは非常に簡単です
  • ルックアップテーブルの定義と使用は面倒です。

プロジェクトが安定したら、スプレッドシートを破棄してデシジョンテーブル用の独自のユーザーインターフェイスを実装するか、使用する場合はguvnorをWebアプリケーションに埋め込むことをお勧めします。

于 2013-01-15T11:59:59.853 に答える