3

現在、ソリューションに統合するスケジューリング アプリケーションを探しています。Quartz.net でのロックに非常に近づいていますが、Stackoverflow または Google で解決策を見つけることができない取引ブレーカーが 1 つあります。

問題は、API を介したリモート アクセスに関するものです。例:

NameValueCollection properties = new NameValueCollection();
properties["quartz.scheduler.instanceName"] = "instanceName";
properties["quartz.scheduler.proxy"] = "true";
properties["quartz.scheduler.proxy.address"] = "tcp://localhost:555/QuartzScheduler";

ISchedulerFactory sf = new StdSchedulerFactory(properties);
IScheduler sched = sf.GetScheduler();

現在、どのユーザーも上記と同様のコードを使用でき、スケジューラ インスタンスを使用してジョブを管理/変更/追加できることを理解しています。問題は、このアクセスを制限する必要があることです (これが実行されるユーザー コンテキストとして)。機密情報にアクセスできます)。

私たちの理想的なケースでは、特定のユーザーへのリモート アクセスをロックダウンしたいと考えています。これにより、許可されたユーザーがインターフェイスから Quartz を管理できるようになります。これが不可能な場合は、同じマシンから API にアクセスする機能を壊さずにリモート アクセスをロックダウンするソリューションを求めます (欠点は、ユーザーが Quartz を管理するためにサーバーにログオンする必要があることです)。

私たちの組織がこの要件を持つ最初の組織だったとしたら、私は非常に驚くでしょう.他の組織はこの問題をどのように解決しましたか?

4

1 に答える 1

2

要するに、組み込みの認証/承認スキームはありません。

まず第一に、悪意のあるユーザーがインターフェイスにアクセスできたとしても (人々が敵対的である場合、私には危険なネットワークのように思えます)、この個人はスケジューラしか管理できませんでした。したがって、公開される可能性のある情報は、ジョブ/トリガー名とグループです。ユーザーが悪意を持ってジョブを実行する可能性がありますが、そのジョブは、当初の予想よりも頻繁に実行できるほど堅牢にコーディングされていません。

外部の関係者は、ジョブが許可されているものにアクセスできませんでした。これには、接続文字列などや実際のジョブ ロジックが含まれます。また、外部の関係者は、サーバーの bin ディレクトリに存在しないジョブを追加することもできません。そのため、ジョブはロックされ、実際に予期せぬ事態が発生することはありません。

頭に浮かぶことの1つは、ユーザーがパラメーターを使用してネイティブジョブをスケジュールし、サービス権限で実行されているシステムで有害なことを実行できることです。

これを回避する1つの方法は、Webサービス/Webアプリケーションのような単純な制御インターフェースを使用して、許可などを処理し、それ以外の場合はファイアウォールで保護されているlocalhostのWindowsサービスに接続することです.

于 2013-03-06T15:30:56.317 に答える