解説：　富士通メインフレームGS/PFの内部統制

　監査人の方へ　「IT統制のための富士通メインフレームの基礎」の連載をはじめました。　（※ユーザ限定です）

　富士通のメインフレーム(GS21,GS,PRIMEFORCE、以下GS/PFと略す)での内部統制、特にIT全般統制の構築手法について、弊社はメーカより先行して
具体的な検討を行ってきました。
　この作業を通し、GS/PFはセキュリティが確保されていると勘違いしている人、そう信じたがっている人（様々な利害関係による）がたくさんいることがわかりました。
　内部統制に関わる皆さんには、多くのGS/PFは、セキュリティレス・統制レスで運用されている事実（これが標準だった）を認識して頂く必要があります。
　そして、実際にお客様のシステムの現状を把握して、どこに大きなリスクがあるのか分析して頂くことが重要です。

第１部　IT全般統制（ITGC）とは
第２部　富士通メインフレームGS/PFのIT全般統制（ITGC）支援機能
第３部　GS/PFで目指すIT全般統制（ITGC）とは
第４部　GS/PFでのIT全般統制（ITGC）構築における問題

第３部　GS/PFで目指すIT全般統制(ITGC)とは

● (11)　　不祥事例から学ぶ
　NECで裏金問題が発覚したようです。
　NECのホームページからニュースリリース「東京国税局からの更正通知の受領について」（2007年5月29日）を抜粋します。

　　今回の税務調査の過程において、社員による個人的な不正取引が発覚いたしました。更正通知によって指摘された不正取引の内容は以下の通りです。
　　1.税務調査の対象期間: 平成11年度～17年度(7年間)
　　2.不正取引の件数・部門数: 5件、5部門
　　3.不正取引額: 約22億円
　　4.不正取引の内容: 当社の取引先に対して、その下請先へのソフトウェア・保守・現地調整工事などの水増し発注または架空発注を指示し、
　　　　取引先を経由して当社から不正に金銭を流出させた上、約5億円を下請先からリベートとして受取り、個人的な飲食費などに使用していた。
　　5.関与人員: 10名
　　6.関与取引先数: 17社(下請先含む)

　　（省略）

　　企業におけるコンプライアンスの強化、内部統制の整備などが強く求められているなかで、このような不正取引が発生したことは誠に遺憾であり、
　　関係の皆様にご迷惑をおかけしたことを深くお詫び申し上げます。
　　当社では、今回の税務調査を受け、また昨年のNECエンジニアリングの架空取引問題の教訓から、営業部門と計上部門の職務分離の徹底等、
　　受注・売上プロセスの改革や資材調達プロセスの改革等を行ってまいりました。今般の不正取引は、役務・工事等の無形資産の取引につき、
　　営業部門等の発注者自らの確認により検収ができる仕組みとなっていたため、長期間にわたり不正が発見できなかったものです。
　　これに対し、昨年末から第三者の管理部門が確認する体制を整備いたしました。
　　また、様々な研修機会を設け、不祥事例を取り上げるなどして、コンプライアンス最優先という意識を全従業員に徹底させております。更に、全従業員
　　に対して、従業員の相談・申告窓口制度であるNECヘルプラインの重要性を訴え、その利用を促しております。
　　今般の件を機に、更にこうした施策を強化し、再発防止を徹底してまいる所存であります。

　続いて、「子会社の架空取引について」（2006年3月22日）を抜粋します。架空取引金額は332億円。（NECE：NECエンジニアリング）

　　昨年12月末、NECE社従業員がその所属する部門において架空の仕入れと架空の売上を計上していたことが判明し、NECE社からその連絡をうけました。
　　当社は、ただちに社内で調査対応チームを編成するとともに、外部の弁護士、会計士へ調査を依頼し、今般その内容が明らかになりました。
　　この架空取引は、実際に取引の対象となる物の移動があるかのように見せかけて、仕入先、NECE社、販売先の3者間で取引を循環させていたもので、
　　2002年3月の取引を発端に2005年12月までこれを繰り返し行っておりました。
　　NECE社は、仕入先、販売先から確証を入手していたこと、社内での手続きに必要な書類をこの従業員が偽造して取り揃えていたこと、売上の入金が
　　販売先から予定通り行われていたこと等から、昨年12月まで架空であることが認識できませんでした。

　（省略）

　　内部統制機能を構築し運用してまいりましたが、今回はNECE社一従業員の違法行為によりこのような事態となりました。このような行為は決してあってはならない
　　ことであり、NECグループとして今回の問題を真摯に受けとめ、再発防止に努めてまいります。
　　NECE社において4年間にわたりこの架空取引を発見できなかったのは、社内関係部門が本来行うべき取引へのチェックが十分行われなかったためと認識して
　　おり、これについては外部弁護士からも同様の指摘をうけております。
　　この認識、指摘を踏まえ、NECE社におきましては、
　　(1)相互牽制機能強化をめざした会社組織、体制の変更
　　(2)経営監査室、経理部による牽制機能強化
　　(3)現品確認の徹底
　　(4)社員の再教育および啓発の強化
　　等を実施いたします。
　　当社といたしましても、当社およびグループ会社において内部統制の運用面における不備の有無を早急に再確認するとともに、より厳正な運用を徹底してまいります。
　　また、各社の監査役および内部監査部門との連携を強化して、より実効的な監査が実施できるよう徹底してまいります。さらに、当社およびグループ会社の役員および
　　従業員に対して、教育、研修、日々の行動、経営トップのメッセージ等を通じて遵法行動の再徹底を行い、二度とこのような問題を生じさせない所存であります。

　2006年3月に332億円（5年間）の架空取引が発覚、今回は税務調査で約22億円（7年間）の不正取引が発覚。
　連結売上4.6兆円ですから、金額の多い少ないはあると思います。
　内部統制に係わる皆さんは、それぞれの立場でこの不詳事例から学ぶことがあるのではないでしょうか。

　完全な内部統制はありませんし、更にIT全般統制が直接関与することもありません。
　事実として、メインフレーム上では様々な統制がきいています。手段から入るのではなく、本質的なIT統制を考え、適用することが重要だと考えます。
　内部統制の大切な目的は、業務の有効性と効率性です。

　P.S　昨日、NEC主催の大きなカンファレンスに出席したら、カンファレンス事務局（委託会社）から間違った名前で礼状メールが届いた。信じられん...

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ　第１部　第２部　第３部　第４部

● (12)　　潜在的な統制
　基本的に、メインフレーム（GS/PF)の仕組みを理解していない人は、本質的なメインフレームのIT統制は構築できません。
　メインフレームでシステムを構築したことがない人が、IT統制を構築できないといっても過言ではありません。
　　・・・PFDを使ってCOBOLのプログラミグ～実行すらできないなんて問題外
　IT統制を知らないと、IT統制を構築できません。　（重要です）
　お客様のシステムを網羅的に理解していないと、そのシステムに適したIT統制を構築することはできません。

　メインフレーム（GS/PF）を知らない人は、自分の知っているコンピュータに置き換えて考えようとします。
　　・・・IT屋、コンサル屋はこうやって知らないことを誤魔化します　（自分が理解するプロセスはよいが、そのままユーザに返してはいけない）
　コンピュータを知らない人は、手持ちのチェックリストをそのまま使おうとします。
　結果、本質とはほど遠い内容だったり、抽象的な内容になります。

　私たちは、お客様のメインフレームシステムが持っている「潜在的な統制を生かしたIT統制」の構築により、本質的なIT統制を目指しています。
　メインフレームを使っている人なら持っている、なんとなく統制がとれている感じと、長年の改善すべき慣習の見える化です。
　潜在的な統制を発見する最初のステップは、今動いているシステムのログ（RACFではありません）からシステムを可視化し、把握することです。

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ　第１部　第２部　第３部　第４部

● (13)　　RACFは内部統制のツールでない
　RACFを検討されるお客様も多いと思います。
　その際、一番大切なことは、RACFは内部統制のために作られたツールではないと認識することです。
　IT全般統制を構築していくプロセスで、この統制はRACFの機能を使った方がより効果的であると判断することはありますが、RACFを使ってIT全般統制を
構築することはできません。

　RACF V12は1993年に提供されています。（もちろん、内部統制はそれ以前からありますが。）
　RACFとは、情報システムの中で、利用者と資源およびそのアクセス関係を定義し、利用者が許可された権限の範囲内で作業することを監視するプログラム
です。（RACF解説書より）
　利用者、資源、権限の範囲内、監視の中身は時間とともに変化しています。
　富士通のRACFは、セキュリティ管理（第４回）の一部を支援するツールです。
　また、RACFのログをわざわざ監査ログと表現している資料がありますが、その内容から見ても監査ログと呼ぶべきではありません。
　マニュアル通り、RACFのSMF、アウトプットを監査レポートと表現すべきです。

　IT統制の成熟度で見ると、3→4にするフェーズでRACFは効果的なツールの一つですが、2→3は効果が薄いと考えます。
　
　ご参考　COBIT 4.0　の成熟度モデル

　０　不在
　　識別可能なプロセスが完全に欠落している。企業は、対応すべき問題が存在することすら認識していない。
　１　初期/その場対応
　　企業は、対応が必要な問題の存在について認識している。ただし、標準化されたプロセスは存在せず、対応や個人的に、または場合に応じて場当たり的に
　　行われている。総合的な管理方法は体系化されていない。
　２　再現性はあるが直感的
　　同じ仕事に携わる複数の要員において同等の手続が行われる段階にまで、プロセスが進歩している。標準的な手続に関する正式な研修や周知は行われて
　　おらず、実行責任は個人に委ねられている。個人の知識への依存度が高く、そのため、誤りが発生しやすい。
　３．定められたプロセスがある
　　手続は標準化および文書化されており、研修により周知徹底されている。ただし、このプロセスに従うかどうかの判断は個人に委ねられ、プロセスからの逸脱は
　　ほとんど発見されない。手続自体は、既存の実践基準を正式化しただけのものであり最適化されてはいない。
　４．管理され、測定が可能である
　　手続の遵守状況をモニタリング、測定でき、プロセスが効果的に機能していないと判断された場合に対処が可能である。プロセスの改善が常時図られており、
　　優れた実践基準を提供している。自動化やツールの活用は、限定的または断片的に行われている。
　５．最適化
　　継続的改善、および他社との比較による成熟度モデル化の結果、プロセスがベストプラクティスのレベルにまで最適化されている。ITは統合され、ワークフローが
　　自動化されている。これにより品質と有効性を改善するツールが提供され、企業の迅速な環境適応に貢献している。

　IT全般統制の範囲は、第１回に記述したとおりです。

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ　第１部　第２部　第３部　第４部

● (号外)　　不祥事例から学ぶ（その２）
　富士通（富士通関西システムズ）でも架空取引が発覚したようですね。
　富士通のホームページ、富士通からのお知らせ「当社関係会社の取引に関する一部報道について」（2007年6月7日）をリンクします。
　公表すべき事実が明らかになった段階で、すみやかに公表させていただきます・・・に期待しましょう。

　・6月8日の経営方針説明会で、黒川さんが陳謝したそうです。（Enterprise Watch）　　なぜシステム的にチェックできなかったか、ってねぇ...　　期待しましょう。
　・6月15日のお知らせで公表したことは、架空取引の2006年度売上は、最大でも44億円であり、連結決算における影響は軽微であることだけ。
　富士通関西システムズの2006年度売上350億円（毎日新聞）の12.5%である。
　・結局、知らん振りするのですかね。(2007/9/18)

<< ホームへ　第１部　第２部　第３部　第４部

● (14)　　システム管理者を守るIT全般統制
　こんな不祥事が起きると、システム管理者には、上から無理難題な要求が落ちてきます。
　ログはすぐに出てきて当たり前、無ければ関係のないあなたたちが悪者扱いされる可能性さえあります。
　実際の調査で必要なログの多くはどユーザアプリで取得すべき情報でしょう。
　RACFのSMFだけでは何もわかりません。（RACFが悪いのではなく、これ一つあれば何でもわかるスーパツールなどシステムにはあり得ない）

IT全般統制	システム標準のログ	OS、AIM、TSS/AIF
	オプションのログ	OS、AIM、SymfoWARE
	RACFのSMF	RACF
IT業務処理統制	ユーザアプリのログ	ユーザアプリ
	ユーザログ	ユーザアプリ、AIM

　並行して早急にやるべきことは、特権ユーザであるシステム管理者・システム管理部員の身の潔白を証明することです。
　そのためにはIT全般統制の運用ルールと、証跡（紙でもデータでも）が必要になります。
　IT全般統制はシステム管理者ご自身を守るものであるとも言えます。

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ　第１部　第２部　第３部　第４部

● (15)　　システム管理者を守る実査
　実査（physical inspection）とは一般的には、資産（現金、有価証券等）を監査人自らが現物を調査して、実在性を確かめる手続きをいいます。
　対象をコンピュータシステムに限定すると、ユーザ資産（ジョブ、プログラム、ID、データベース、環境定義体など）の存在、数量、稼動状況・使用状況等を
確認する手続きと定義します。そして、これらのユーザ資産を結びつけることがポイントです。
　システム管理上の問題点
　　・プログラムは実在する仕様書・設計書は通りには動いていない
　　・データベースにどのジョブがアクセスしているかわかる手段がない
　　・使われていない資産がわからない
　これらの問題を迅速に解決する手段が実査です。
　実査はITGCの信頼性を高めるばかりでなく、システムを透明化することで誠実なシステム管理者を守る結果となります。
　社保システムと180度逆のことを行えばよいのですね。

　実査はシステムに関する知識と時間があれば誰でもできますが、システム管理部門外の方がやった方がもちろん信憑性は高くなります。
　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ　第１部　第２部　第３部　第４部

● (16)　　RACFを入れちゃうのも一つの手
　最前線で活躍しているSEと意見交換をすると勉強になります。
　10年以上前からRACFを触っているSEは、RACFができないこと、できること、得意なことを熟知しています。
　だから彼は、RACFを”導入できる”システムには、まずRACFを入れちゃうて言ってまます。これは、直感的に正しいと感じました。
　　　”導入できないシステム”には入れないのだらか、トラブルは起きにくい。（極めて慎重である）
　　　”できる人”が導入するのだから迅速かつ正確に導入できる。
　　　”できなないこと”を知っているから、お客様にも正確に伝えられ、のちに問題も起きにくい。
　　　”XSPを知っている”。
　　　おまけ：　メインフレームが好きである、プライドを持っている。
　（将来、RACF導入のトラブル原因を調べたら上の４つのどれかが欠如していたと予言します。）
　
　私たちは、彼らと組んで、GS/PFで内部統制構築のご支援をしていきます。
　RACFと実査は補完しあう関係です

（2007/9/18追記）
　RACFはOSの基本機能の一部として適用すべきだったのです。事実上、OSにセキュリティの概念がないのですから。
　そういう意味でも、RACFを入れられるなら入れちゃうのは悪くない。どう使うかが問題です。

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ　第１部　第２部　第３部　第４部

● (17)　　RACFを入れちゃうのも一つの手、だけど...
　やはり、GS/PFの内部統制＝RACF、とinputしているSEが多いでしょうね。
　先日もSEに、RACFでIT全般統制なんてできないよ、と言ったらキョトンって顔をしていました。
　内部統制もRACFも知らないのですから、これが実態でしょう。・・・今まで、読んで頂いた皆さんにはわかって頂けることを期待しています。

　Googleで「富士通 RACF」を検索すると218件、うちRACFの情報は数件。「IBM RACF」を検索すると35.7万件。
　これもある意味、実態を示しています。

　GS/PFで目指すIT全般統制（ITGC）のポイントをまとめます。（随時、メンテナンスします）
　　① システムの状況を正確に把握する、いつでも把握する手段を持つ
　　② システムの弱み（リスク）だけでなく、強み（統制）を掌握する
　　③ GS/PFの強みを生かした、本質的かつ現実的な（身の丈に合った）ITGC構築を目指す
　　④ RACFは目的を達成するための単なるツールである
　　⑤ 最初から欲張らず、しかし将来の目標を掲げ、段階的に対応していく
　　⑥ 特にシステム管理部門はガラス張りに

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ　第１部　第２部　第３部　第４部

● (18)　　一番のリスクは。。。
　RACFを内部統制のツールと言わないようにしたなんて噂を聞きましたが本当でしょうか？
　メーカさんもチェックしてくれているようなので、頑張って書いていきましょう。

　GS/PFでITGCを構築するにあたっての特徴的なリスクはなんでしょう。
　　・GS/PFを知らない人が教科書どおり、非現実的な机上のITGCを構築させようとする。
　　・GS/PFを知っている人が、ITGCとは関係ないものを構築させようとする。
　　・結局よくわからないので無期限の先送り、みんな責任を持たず知らんぷりをする。
　　・できることから手をつけたが、あとどれだけやればよいのかわからない。

　多くのGS/PFでは、
　　・本番機も開発機も一緒、業務アプリケーションの変更管理をする習慣もない
　　・誰でも簡単にジョブを実行できる
　　・みんな特権ユーザで、パスワードがなくても普通
　　・当たり前とだと思うことで、できないことがたくさんある
　　・知らないだけで、できることもたくさんある
　この現実の表面だけを見てを否定されると困るのですね。内部統制とは何なのか、原点に戻って考えてください。

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ　第１部　第２部　第３部　第４部

● (19)　　ログを取得するときのリスク
　GS/PF上で新たにログを取得することになったときのリスクを、性能評価のプロの視点から紹介します。
　ログはRACFのSMFとAIM課金統計情報を想定しています。
（2007/9/18修正）
　1. システムへの影響
　　・CPU使用率の上昇（いわゆるCPUオーバヘッド）
　　・仮想記憶の圧迫（仮想記憶使用量の現状分析と見積りが必要）
　　・I/Oの増加（RACF管理簿、HLF）
　2. システム運用について
　　・SMF、HLFの容量不足
　　・SMF、HLFのバッファ不足
　　・SMF、HLFのバックアップ回数の増加
　　・ログが欠落なく取得されていることの証明
　3. サポートについて
　　・上記性能見積りを、SEが適切な作業品質と費用で行うこと
　　・問題があれば適切な改善作業を提案し、実施すること
　４．ログ管理について
　　・ログが改ざんされない仕組み
　　・ログの一元管理

　AIM課金統計情報を常時取得することは今まで推奨していません。次のトラブルは容易に想定でき、トラブルを起こしたら言い訳できません。
　　HLFバッファが枯渇して、システムがスローダウンする
　　HLFのデータ量が増加して、バックアップが間に合わず、システムダウンする
　　システムが全体的に遅くなる
　　オンラインの遅延により、DCバッファが枯渇する

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ　第１部　第２部　第３部　第４部

2007年4月作成、2008年2月更新
株式会社アイビスインターナショナル
代表取締役　有賀　光浩

株式会社アイビスインターナショナル　134-0003 東京都江戸川区春江町4-17-12

解説： 富士通メインフレームGS/PFの内部統制

解説：　富士通メインフレームGS/PFの内部統制