目次

２．１　把握しきれないシステム上のリスク

２．２　RACFに対する過大な期待

２．３　メインフレームを知らない

２．４　システムの稼動状況の見える化

２．１　把握しきれないシステム上のリスク

　多くのメインフレームでは、一つのシステムに本番環境と開発環境が同居し（前回表１の②）、誰でも好きなジョブ名でジョブを実行でき　（同④）、稼動ログの分析を行っていない（同⑥）のが実態です。 　内部統制では、業務プロセスを文書化し、リスクを洗い出し、RCM(Risk Control Matrix)を作成します。１日数千以上のジョブが実行されているメインフレームでリスクを網羅して抽出できるのでしょうか。 　具体的なリスクを４つ紹介します。 　RACFを導入していないシステムでは、全てのTSS/AIF用のIDは「管理されていない特権ユーザ」と同じで、データベースを直接更新することも可能です。実際にこの機能を使ってデータベースのメンテナンスをしているシステムでは、証跡を残さず容易に操作できるかもしれません。 　オンライン業務は、数百以上のプログラムがマルチタスク構造のジョブ（システムACPという）として動作します。稼動状況を把握するには専門的な知識と、システムごとに工夫が必要です。 　性能品質の悪いプログラムを調べると、仕様上使っていないデータベースをアクセスしていることがあります。これは製造工程で作りこんだバグであり、本来は初期のテスト工程で検出しなければならず、ユーザの受け入れテストで発見することは困難です。 　業務プログラムが格納されているロードモジュールライブラリのメンバはいつ更新されたのか容易にはわかりません。 メンバを改名→追加→実行→削除→改名（元に戻る）といった操作を行われたら検出はやっかいです。

システム管理者でさえシステムの稼動状況を網羅的に把握することは簡単ではありません。まずやるべきことは、システムが取得している稼動ログを使ってシステムの運用状況を見える化し、リスクの洗い出しをすることだと考えます。

２．２　RACFに対する過大な期待

　富士通メインフレームのRACFは内部統制のための製品ではありません。理由は以下に示します。

２．３　メインフレームを知らない

　　内部統制に関わっている人（お客様の監査部門、監査法人、コンサルタント、メーカ）のほとんどはメインフレームを知りません。お客様でメインフレームを担当されている方は、内部統制やIT全般統制を理解するのも大変ですし、技術的にも曖昧な点が多くあります。両者の会話がなかなか成り立たず、目標の共有も難しくなります。 　例えば、メインフレームを知らない人（監査人やコンサルタント等）は、自分の知っているコンピュータに置き換えて考えようとします。自分自身の理解のためなら問題ありませんが、この程度の知識レベルで指摘などされると無茶苦茶になります。 　メインフレームにとって知られていないことは大きな特徴です。具体的には、操作できる人は限られている、情報や技術が一般に公開されていない、標準で多数のログが取得されている等、いくつも例が上げられると思います。これらを生かしたIT全般統制を構築することが重要だと考えます。

２．４　システムの稼動状況の見える化

　システム標準の稼動ログ（SMF等）を使い、システムの稼動状況を見える化し、リスクを検出した事例を紹介します。見える化により、システムの管理規約と実態とのギャップを正確かつ網羅的に確認することができます。 　ジョブの稼動状況に、データベースをアクセスしているものを一目でわかるように色分けしたグラフを図３に示します。IT全般統制の視点で見ると、DB未使用と参照のみのジョブのリスクは小さくなります。認識していないジョブがデータベースを更新していれば問題です。

図３　ジョブの稼動状況　　（縦軸：ジョブ名）

【検出されたリスク】

　　　・データベースを更新しないはずのジョブが更新系になっている
　　　　　　⇒　プログラムとDBを特定し、仕様書とプログラムのどちらが正しいか確認する
　　　・更新系で、管理者や内容がわからないジョブが動いている
　　　　　　⇒　ジョブの調査、ジョブ実行のルールを確認する
　　　・AIM/VSAM（図３のその他）を利用している
　　　　　　⇒　内部統制に影響するデータか確認する

　データベースにはどのジョブ（プログラム）がアクセスしているか把握することができます。表３はNDBのアクセス状況を示します。

表３　NDBのアクセス状況

RACFは基本的にジョブ名、ユーザID、ファイル名で管理をします。そのため、不正なアクセスがあったとしても、どのプログラムを使ったのか、データベースのどのスキーマやテーブルをアクセスしたのか知ることができないのが欠点です。

　システムの稼動状況を把握し、リスクとコントロールを整理した後でRACFの導入を検討すると大きな間違いがないと考えます。次回は、メインフレームの強みを生かしたIT全般統制について解説します。