概要
金融商品取引法の内部統制報告制度がスタートします。多くのメインフレームシステムでは性善説にたったシステム開発や運用管理を行っていますが、これが内部統制という名のもとに否定される可能性があります。 「富士通メインフレームの本質を見る」の第３弾として「IT全般統制の考え方」について解説します。第１回はIT全般統制から見た富士通メインフレームの現状について考えます。
３．１ メインフレームの潜在的な統制
◆解説
【問】を読んであなたはどのように感じましたか。
メインフレームを使っていない多くの方は「そんなことできるか」と思われたかもしれません。Windowsのような操作性の良さ、情報のオープン性はメインフレームには皆無です。このことは、結果的に統制がかかっていると見ることができます。
データベースをアクセスするには以下のような方法が考えられます。
・TSS/AIFからデータベースを直接更新する機能、保守ツール等を利用する
・ユーザプログラムを使って更新する
・データベースのアンロード、リロードなどのユーティリティを利用する
データベース構造、AIM環境、ライブラリ構成等の情報がなければ何もできません。
データベースの更新は、更に難易度が高くなります。データの一部を変えることに成功しても、後の業務処理プログラムで不整合を起こす可能性も大です（IT業務処理統制）。
AIM配下のデータベース（NDB、SymfoWARE）であればログ環境との整合性をとる必要もあります。
システムを管理する立場で怪しいとはどんなことでしょうか。
・システムの運用規約と違うこと
・コンソールにエラーが出力されること
・不当なプログラムがデータベースを更新すること 等々
日ごろから意識していないと、何も気づかないかもしれません。２．４節で紹介しましたが、メインフレームでは多くの稼動ログを取得しています。これを分析してもおかしな動きは見えてきます。
３．２ IT全般統制構築上の留意点
（２）システムの運用・管理
メインフレームでは、基本的にだれでも自分の端末からジョブを実行できます。そのため、スケジューリングされていないジョブや、TSS/AIFのフォアグラウンド処理（特に、データベースの保守ツール）の運用には注意が必要です。例えば、以下のような対応は今からでも必要と考えます。
・SUBMITジョブの命名規約（例：ジョブ名＝ユーザID＋αとする）
・TSS/AIFのフォアグラウンド処理の制限
・ライブラリ関連のユーティリティ、データベースユーティリティ、AIMの環境定義などの実行結果リストは
保管する
証跡ログとしてはAIM、DBMS、TSS/AIF、ジョブ管理等の稼動ログが効果的ですが、すべて縦割りでシステムとしての連携がとれていないのが欠点です。また、RACFのログがこれらを包含する訳ではありません。ログは採取しただけでは何の意味もなく、価値のあるログ活用には以下のアプローチが必要です。
①目的を明確にし、取得するログデータを決定
②抜けなく継続してログデータを取得する仕組み
③ログデータを改ざんされない仕組み
④ログデータを蓄積する仕組み
⑤蓄積したログデータから必要な情報を早く正確に取り出す仕組み
（３）内外からのアクセス管理等のシステムの安全性の確保
TSS/AIFのIDを登録・削除するプロセスを整備・運用します。業務処理のID管理はIT業務処理統制の範囲とするためここでは除外します。
OSの標準機能ではすべてが特権ユーザで、簡易的なID/パスワード管理しか提供されていない事実を理解することが重要です。セキュリティ管理の一貫としてID管理を行うなら、RACFの機能を使います。IT全般統制としてID管理をどこまで厳密に行うか、システムの状況に応じて以下のステップで考える必要があります。
・現状を把握しIDを整理する。不要なログオンは止める。
・共有IDを廃止し、個人IDを発行する。
・IDの申請、発行、削除に関する手続を作り、運用する。
・TSS/AIFの稼動ログによるモニタリングを行う（図４）。
・正式なID管理を行うには、RACFの機能を使用する。
図４ TSS/AIFの稼動状況
アクセス管理を行うにはRACFが必須です。IT全般統制としての対象は、財務報告に関係するプログラムとデータ（データベース）であり、RACFの導入については、２．２節で解説したように過大な期待をしないでください。
参考までに、メインフレームでの最大ログオン数をまとめた結果を図５に示します。
図５ 本番系システムでの最大ログオンユーザ数
３．３ まとめ
教科書の通りにIT全般統制を整備・運用せよ、と言うことは簡単です。しかし、職務分掌する人がいない、RACFの導入に多額の金額を提示されたといった相談を受けたこともあります。本質的な議論が先送りされ、やろうとしている姿勢を見せることが目的化するのは悲しい話しです。
ID管理が無くても、社会的責任のある企業の基幹システムとして10年以上も信頼されていることも事実です。これは偶然ではなく、前節で紹介した「潜在的な統制」が機能しているのも理由の一つだと考えます。将来的にリスクが高くなる（発生可能性×影響度）とも一概には言えません。
メインフレーム上でIT全般統制を構築するには、お客様固有のリスクベースで考えることがポイントです。そのとき、潜在的な統制と稼動ログの活用が必ず役に立ちます。
連載一覧
筆者紹介
株式会社アイビスインターナショナル 代表取締役
1963年生まれ。1985年富士通株式会社入社。1992年～2003年まで社内共通技術部門で国内外のメインフレームの性能コンサルティングを実施、担当したシステム数は1,000を超える。2000年からは大規模SIプロジェクトへの品質コンサルティング部門も立ち上げた。
2004年に株式会社アイビスインターナショナルを設立。富士通メインフレームの性能コンサルティングとIT統制コンサルティングを行っている。
技術情報はhttp://www.ibisinc.co.jp/で公開中。富士通やSI’erからのアクセスが多い。
当サイトには、同名シリーズ「富士通メインフレームの本質を見る～IT全般統制の考え方」を3回、「富士通メインフレームの本質を見る～バッチ処理の性能評価と改善事例から」を6回、「富士通メインフレームの本質を見る～CPUリプレースの考え方」を3回、「富士通メインフレームの本質を見る～性能改善の現場」を7回、「富士通メインフレームの本質を見る～2009年度の最新トッピックス」を3回、「富士通メインフレームの本質を見る～2008年度の最新トピックス」を2回にわたり掲載。
コメント
投稿にはログインしてください