5.OCFを使ったセキュリティの実際
- (3)パスワードのみ
-
OCFの機能の中で一番簡単なものです。
システム生成で、OCF機能をオペレータのみ((NNN))にすると、操作開始時などにオペレータコードとパスワードを求められるようになります。
最初にPC/WSエミュレータを起動したり、操作開始コマンドを実行したりすると以下のようにオペレータコードの入力画面になります。
オペレータコードを入力すると、オペレータ名が表示され、次にパスワード入力になります。
パスワードが正しいと操作開始となります。もし初期プログラムが設定されていれば、そのオペレータ用のジョブ(メニューなど)が自動実行されます。
1つの端末(PC/WSエミュレータ含む)を1人(1オペレータ)で使用しているのならば、1度操作開始を行ってしまえばオペレータコードを再度入力することはありません。 しかし、1台の端末を複数のオペレータが共用している場合、画面接続コマンド、プログラム放棄コマンド、拡張システムコマンド入力時などにオペレータコードの入力を求められることがあります。
例えば、画面接続コマンドを実行する場合を考えてみます。画面接続コマンドは、裏側にあるジョブを表側に(ステーションに接続)するコマンドです。1台の端末で3人のオペレータが実行中であるとします。画面上には、オペレータAのジョブが表示されています。そうすると裏側にオペレータBとオペレータCのジョブが実行中なわけです。オペレータBが自分のジョブの画面を見るために、自分のジョブを表側にしたいとします。このときにオペレータBは画面接続コマンドを実行し、オペレータコードの入力画面で、自分のオペレータコードを入力することになります。そうするとオペレータBのジョブが表側になります。
既に操作開始済みのオペレータが、再度操作開始コマンドを実行することはできません。
よく間違えるのが、裏側に自分のジョブがあるのに気付かず、また操作開始コマンドを実行してしまうことです。
操作開始コマンドを実行して、「操作開始コマンドは実行できません」というエラーメッセージが表示された場合は、自分のオペレータコードで画面接続を試してみてください。たいていの場合、自分が以前実行したジョブが表示されます。
システム生成を「オペレータのみ」にした場合、1つ重要な問題があります。オペレータコントロールファイル保守のユーティリティのセキュリティがなされていないため、どのオペレータからも実行可能であるということです。具体的には、どのオペレータも全員のパスワードを知ることができるし、変更することも可能になっています。したがって、このシステム生成ではなく、もう一工夫したレベル3の方を使用すべきです。
ちなみに、以下はオペレータコントロールファイルでオペレータの情報を参照したところです。
このレベル1は、誰でもオペレータコントロールファイル保守が実行できるので、各個人がパスワードを変更するという運用にする時には、便利かもしれません。
ただし、上で説明したようにオペレータコントロールファイル保守を直接実行すると、誰でもパスワードが見れてしまうので、オペレータコントロールファイル保守ユーティリティは自分のパスワードのみ変更できるようにJSで制御を行い、かつそのJSを初期プログラムのメニューから実行できるようにし、オペレータコントロールファイル保守ユーティリティは直接実行できないような構造にする必要があります。
パソコン上のエミュレータを使っている限りは、Windowsのログオン時のパスワード、A−VXの操作開始時のパスワードと2重になっています。
私個人の考えですが、定期的に変更するパスワードはWindowsのパスワードだけでいいのではないかと思います。そしてA−VX側はレベル3にしてパスワードはある程度固定にして変更しない。外部からの進入には、Windowsのパスワードで守り、内部のユーザの誤操作や不正操作を防止する役割としてA−VXのパスワードを使用する。普通のWindowsサーバは、Windowsのパスワードだけで十分運用しているのですから、A−VXのパスワードはおまけのような扱いでも十分だと思います。