概要
金融商品取引法の内部統制報告制度がスタートします。多くのメインフレームシステムでは性善説にたったシステム開発や運用管理を行っていますが、これが内部統制という名のもとに否定される可能性があります。 「富士通メインフレームの本質を見る」の第３弾として「IT全般統制の考え方」について解説します。第１回はIT全般統制から見た富士通メインフレームの現状について考えます。
２．１ 把握しきれないシステム上のリスク
多くのメインフレームでは、一つのシステムに本番環境と開発環境が同居し（前回表１の②）、誰でも好きなジョブ名でジョブを実行でき （同④）、稼動ログの分析を行っていない（同⑥）のが実態です。 内部統制では、業務プロセスを文書化し、リスクを洗い出し、RCM(Risk Control Matrix)を作成します。１日数千以上のジョブが実行されているメインフレームでリスクを網羅して抽出できるのでしょうか。 具体的なリスクを４つ紹介します。 RACFを導入していないシステムでは、全てのTSS/AIF用のIDは「管理されていない特権ユーザ」と同じで、データベースを直接更新することも可能です。実際にこの機能を使ってデータベースのメンテナンスをしているシステムでは、証跡を残さず容易に操作できるかもしれません。 オンライン業務は、数百以上のプログラムがマルチタスク構造のジョブ（システムACPという）として動作します。稼動状況を把握するには専門的な知識と、システムごとに工夫が必要です。 性能品質の悪いプログラムを調べると、仕様上使っていないデータベースをアクセスしていることがあります。これは製造工程で作りこんだバグであり、本来は初期のテスト工程で検出しなければならず、ユーザの受け入れテストで発見することは困難です。 業務プログラムが格納されているロードモジュールライブラリのメンバはいつ更新されたのか容易にはわかりません。 メンバを改名→追加→実行→削除→改名（元に戻る）といった操作を行われたら検出はやっかいです。
システム管理者でさえシステムの稼動状況を網羅的に把握することは簡単ではありません。まずやるべきことは、システムが取得している稼動ログを使ってシステムの運用状況を見える化し、リスクの洗い出しをすることだと考えます。
２．２ RACFに対する過大な期待
富士通メインフレームのRACFは内部統制のための製品ではありません。理由は以下に示します。
RACFのサポート範囲は図２に示す通りシステムの一部である
・基本的には、バッチジョブ、TSS/AIFを対象にした機能
・オンライン処理ではログオン認証が可能
・業務プロセスの職務分掌をRACFの機能だけで実現することは困難
・RACFのログは数ある監査証跡の一つ
日本版SOX対応とセキュリティ管理は目的が異なる
・前者の目的は財務報告の信頼性のためであり、例えば個人情報が漏洩しても、
財務情報が見られても直接的には問題ない
・RACF導入済ユーザでも、内部統制視点でのアクセス管理が不十分である例がある
OSのぜい弱性をカバーするものではない
・導入には制限事項が多い
・導入したが結局運用できないケースも多い
RACFの機能を理解せずに導入を推奨したり、過大な期待をかけるケースがありますので十分に注意をしてください。
図２ RACFのサポート範囲
２．３ メインフレームを知らない
内部統制に関わっている人（お客様の監査部門、監査法人、コンサルタント、メーカ）のほとんどはメインフレームを知りません。お客様でメインフレームを担当されている方は、内部統制やIT全般統制を理解するのも大変ですし、技術的にも曖昧な点が多くあります。両者の会話がなかなか成り立たず、目標の共有も難しくなります。 例えば、メインフレームを知らない人（監査人やコンサルタント等）は、自分の知っているコンピュータに置き換えて考えようとします。自分自身の理解のためなら問題ありませんが、この程度の知識レベルで指摘などされると無茶苦茶になります。 メインフレームにとって知られていないことは大きな特徴です。具体的には、操作できる人は限られている、情報や技術が一般に公開されていない、標準で多数のログが取得されている等、いくつも例が上げられると思います。これらを生かしたIT全般統制を構築することが重要だと考えます。
２．４ システムの稼動状況の見える化
システム標準の稼動ログ（SMF等）を使い、システムの稼動状況を見える化し、リスクを検出した事例を紹介します。見える化により、システムの管理規約と実態とのギャップを正確かつ網羅的に確認することができます。 ジョブの稼動状況に、データベースをアクセスしているものを一目でわかるように色分けしたグラフを図３に示します。IT全般統制の視点で見ると、DB未使用と参照のみのジョブのリスクは小さくなります。認識していないジョブがデータベースを更新していれば問題です。
図３ ジョブの稼動状況 （縦軸：ジョブ名）
【検出されたリスク】
・データベースを更新しないはずのジョブが更新系になっている
⇒ プログラムとDBを特定し、仕様書とプログラムのどちらが正しいか確認する
・更新系で、管理者や内容がわからないジョブが動いている
⇒ ジョブの調査、ジョブ実行のルールを確認する
・AIM/VSAM（図３のその他）を利用している
⇒ 内部統制に影響するデータか確認する
データベースにはどのジョブ（プログラム）がアクセスしているか把握することができます。表３はNDBのアクセス状況を示します。
表３ NDBのアクセス状況
RACFは基本的にジョブ名、ユーザID、ファイル名で管理をします。そのため、不正なアクセスがあったとしても、どのプログラムを使ったのか、データベースのどのスキーマやテーブルをアクセスしたのか知ることができないのが欠点です。
システムの稼動状況を把握し、リスクとコントロールを整理した後でRACFの導入を検討すると大きな間違いがないと考えます。次回は、メインフレームの強みを生かした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回にわたり掲載。
コメント
投稿にはログインしてください