アドバイザリー

IT全般統制におけるモニタリングツールの導入・運用の落とし穴

2013.03.26
松浦隼
松浦 隼
新日本有限責任監査法人
ITリスクアドバイザリー部 マネージャー
公認情報システム監査人
SIerおよび事業会社にて情報システムの企画・開発・運用などの業務に従事。監査法人入所後は、上場企業を中心として、情報システムに関わる内部統制の構築・評価・監査業務のほか、最近ではシステム導入に関するアドバイザリー業務や業務効率化支援などを手掛けている。


はじめに

内部統制報告制度(J-SOX)の施行を契機に、上場企業を中心にIT全般統制の整備が進み、それを補助するためのモニタリングツールやID管理ツールなどが多くの企業で導入されてきました。しかし、それらのツールの導入・運用が適切でないため、IT全般統制の評価において不備が識別されるケースが見受けられました。
本コラムでは、モニタリングツールの導入・運用過程における落とし穴を事例で紹介します。

【事例1】導入目的(リスクへの対応)の検討不足

X社は、基幹システムの本番環境に多数のシステム部門担当者がアクセスすることから、基幹システムのアクセス管理を有効にするために、様々な種類のログが出力できる市販のモニタリングツールを導入しました。
X社の手続きは、ツールから出力可能なあらゆる種類のログについて、週次でモニタリング担当者が分析結果のレポートを作成し、責任者がレポートの内容を確認するというものでした。しかし、対応するリスクや分析するログの種類、分析に要する手間や時間については検討されませんでした。実際に運用してみると、分析対象となるログの種類が多いため、作業に多大な時間を要し、週次レポート作成の遅延が頻繁に発生しました。その結果、X社の内部統制評価において、モニタリング手続きが適時に実施されていないことが、基幹システムのアクセス管理の不備として識別されました。

【事例2】導入時の検証不足

Y社では、プログラムの変更が正規の手続きを経て行われたものかをモニタリングするため、日次のプログラム変更ログを蓄積し、月末にモニタリング担当者あてにメール通知を行う自製のモニタリングツールを構築しました。
ツールの要件定義については、複数の関係者(開発担当者やモニタリング担当者など)が関与し、問題がないことを確認していましたが、その後の検証は開発担当者だけで実施され、モニタリング担当者などのユーザーによる検証は行われませんでした。ツール運用開始後しばらくたってみると、毎月、特定の日に関するプログラム変更ログが通知に含まれていないことが判明しました。その結果、Y社の内部統制評価において、プログラム変更ログの通知の網羅性がなく、モニタリング範囲が不十分であったことが、プログラム変更管理の不備として識別されました。

【事例3】運用開始後の環境変化への対策不足

Z社では、システム部門担当者が、データベースを直接修正することが常態化していたため、データベースに対する不正操作対策としてモニタリングツールを導入しました。このツールでは、モニタリング対象を個人単位または所属部門単位で設定できるため、Z社はシステム部門を対象に設定しました。
ツール運用開始後に組織再編があり、一部のシステム部門担当者がユーザー部門のシステム担当者として異動し、データベースの直接修正業務を引き継ぐことになりました。この変更に伴い、データベース修正の依頼手続きが見直されましたが、モニタリング対象の設定変更が必要であることは見落とされてしまったのです。その後しばらくは、ユーザー部門に異動した担当者がモニタリング対象に含まれないまま、モニタリング手続きが運用されていました。その結果、Z社の内部統制評価において、モニタリングの対象範囲が網羅的でなかったことがデータベース直接修正管理の不備として識別されました。

おわりに

今回ご紹介したような落とし穴に陥らないためには、①導入前に導入目的(リスクへの対応)とそれに合った運用手続きを具体的に検討する、②導入時の検証手続きを明確にし、UAT(ユーザ受入れテスト)を実施する、③運用開始後も組織改編や異動などの環境変化に応じて設定を見直すなど、ツールに対しても統制意識を持つ必要があります。IT全般統制を補助するツールとしてモニタリングツールなどを導入しているから大丈夫というわけではなく、適切な要件に基づいて導入・運用してこそ、ツールとしての機能を十分に発揮できるといえます。うちの会社に限ってと思われる方も、ツールの導入・運用手続きを点検されてはいかがでしょうか。





情報量は適当ですか?

文章はわかりやすいですか?

参考になりましたか?