読んであなたはどのように感じましたか。メインフレームを使っていない多くの方は「そんなことできるか」と思われたかもしれません。Windowsのような操作性の良さ、情報のオープン性はメインフレームには皆無です。このことは、結果的に統制がかかっていると見ることができます。データベースをアクセスするには以下のような方法が考えられます。・TSS/AIFからデータベースを直接更新する機能、保守ツール等を利用する・ユーザプログラムを使って更新する・データベースのアンロード、リロードなどのユーティリティを利用するデータベース構造、AIM環境、ライブラリ構成等の情報がなければ何もできません。データベースの更新は、更に難易度が高くなります。データの一部を変えることに成功しても、後の業務処理プログラムで不整合を起こす可能性も大です(IT業務処理統制)。AIM配下のデータベース(NDB、SymfoWARE)であればログ環境との整合性をとる必要もあります。システムを管理する立場で怪しいとはどんなことでしょうか。日ごろから意識していないと、何も気づかないかもしれません。2.4節で紹介しましたが、メインフレームでは多くの稼動ログを取得しています。これを分析してもおかしな動きは見えてきます。経済産業省が公開しているシステム管理基準追補版(財務報告に係るIT統制ガイダンズ)を使い、メインフレームでIT全般統制構築する際の留意点を解説します。(1)システムの開発・調達メインフレーム上で動作する情報システムの多くは自社開発されたソフトウェアです。そのため、開発者が不正なプログラムを埋め込まないような統制が必要となります。変更管理の支援ツールはメインフレームには対応していないため、人間系重視(手動)で行わなければなりません。監査では「本番プログラム登録時にシステムが自動生成した証跡」を要求されることが予想されますが、OSでは対応していないため、お客様個別の対応が必要となります。(BSPさんのLMISに期待しています。)変更管理プロセスを整備した後に、本番環境と開発環境を分離する統制を考えます。現在1つのシステムで運用しているお客様は、手動統制の手間やコストを考え、表4のA~Dの形態を選ぶことになります。担当者が少人数のことが多く、現実的な統制方法は監査人と十分に詰めていく必要があります。AVMもRACFもシステムにオーバヘッドがかかりますが、現状分析や見積りをせずに1ランク大きなCPUを導入しないよう注意してください。本番環境と開発環境の分離パターン(2)システムの運用・管理メインフレームでは、基本的にだれでも自分の端末からジョブを実行できます。そのため、スケジューリングされていないジョブや、TSS/AIFのフォアグラウンド処理(特に、データベースの保守ツール)の運用には注意が必要です。以下のような対応は今からでも必要と考えます。・ライブラリ関連のユーティリティ、データベースユーティリティ、AIMの環境定義などの実行結果リストは保管する証跡ログとしてはAIM、DBMS、TSS/AIF、ジョブ管理等の稼動ログが効果的ですが、すべて縦割りでシステムとしての連携がとれていないのが欠点です。RACFのログがこれらを包含する訳ではありません。ログは採取しただけでは何の意味もなく、価値のあるログ活用には以下のアプローチが必要です。1目的を明確にし、取得するログデータを決定2抜けなく継続してログデータを取得する仕組み3ログデータを改ざんされない仕組み4ログデータを蓄積する仕組み5蓄積したログデータから必要な情報を早く正確に取り出す仕組み(3)内外からのアクセス管理等のシステムの安全性の確保TSS/AIFのIDを登録・削除するプロセスを整備・運用します。業務処理のID管理はIT業務処理統制の範囲とするためここでは除外します。OSの標準機能ではすべてが特権ユーザで、簡易的なID/パスワード管理しか提供されていない事実を理解することが重要です。セキュリティ管理の一貫としてID管理を行うなら、RACFの機能を使います。IT全般統制としてID管理をどこまで厳密に行うか、システムの状況に応じて以下のステップで考える必要があります。・現状を把握しIDを整理する。不要なログオンは止める。・共有IDを廃止し、個人IDを発行する。・IDの申請、発行、削除に関する手続を作り、運用する。・TSS/AIFの稼動ログによるモニタリングを行う(図4)。・正式なID管理を行うには、RACFの機能を使用する。TSS/AIFの稼動状況アクセス管理を行うにはRACFが必須です。IT全般統制としての対象は、財務報告に関係するプログラムとデータ(データベース)であり、RACFの導入については、2.2節で解説したように過大な期待をしないでください。参考までに、メインフレームでの最大ログオン数をまとめた結果を図5に示します。まとめ教科書の通りにIT全般統制を整備・運用せよ、と言うことは簡単です。職務分掌する人がいない、RACFの導入に多額の金額を提示されたといった相談を受けたこともあります。本質的な議論が先送りされ、やろうとしている姿勢を見せることが目的化するのは悲しい話しです。ID管理が無くても、社会的責任のある企業の基幹システムとして10年以上も信頼されていることも事実です。これは偶然ではなく、前節で紹介した「潜在的な統制」が機能しているのも理由の一つだと考えます。)とも一概には言えません。メインフレーム上でIT全般統制を構築するには、お客様固有のリスクベースで考えることがポイントです。そのとき、潜在的な統制と稼動ログの活用が必ず役に立ちます。金融商品取引法の内部統制報告制度がスタートします。多くのメインフレームシステムでは性善説にたったシステム開発や運用管理を行っていますが、これが内部統制という名のもとに否定される可能性があります。「富士通メインフレームの本質を見る」の第3弾として「IT全般統制の考え方」について解説します。第1回はIT全般統制から見た富士通メインフレームの現状について考えます。代表取締役1963年生まれ。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回にわたり掲載。毎年恒例となった「システム管理者の会」の年に一度の大イベントとなる「システム管理者感謝の日イベント」の模様をお届けします。今年のテーマは、「集まれ若いチカラ!システム管理者のための夏期講習!!」です。