内部統制を意識して情報を管理する

2006.11.15

KPMGビジネスアシュアランス

セキュリティの強化や内部統制の必要性が高まるなか、ユーザー企業のPM（プロジェクト・マネジャ）はプロジェクトを運営する際に「情報管理」を十分に意識しなければならない。加えて、情報を適切に管理する仕組みをシステムに機能として実現することも必要になる。

　情報管理というと、「情報セキュリティ」に関する取り組みを思い浮かべるかもしれない。確かに現状では、情報管理と情報セキュリティ管理をほぼ同義とみなす向きが強いようだ。

　情報管理とは一般に、（1）事業機密の保護、（2）データの保護、（3）システム・セキュリティに関連する情報の保護、（4）システム設計などの知的財産の保護、の4点を目的とする一連の取り組みを指す。この内容は、「機密性、完全性、可用性」という三つの概念で説明される情報セキュリティに関する活動と共通する部分が多い。

内部統制の観点での情報管理が必要

　しかし、ユーザー企業のPMは今後、情報管理をより広い意味でとらえる必要があるのは間違いない。すなわち「内部統制」の観点から、情報管理を進めなければならなくなる。

現在、日本版企業改革法（日本版SOX法）の法制化に向けた作業が進行中であることをご存じの読者は多いと思う。日本版SOX法は、財務報告書に不正や誤りがないよう経営者に内部統制の有効性評価を求めるもの。これに対応するには、社内の業務プロセスなどの文書化や、それが正しく遂行されているかに関する評価が求められる。　

　当然、システム部門も対象になる。情報システムの構築・刷新プロジェクトでは、企画・設計から開発・テスト、本番移行、運用・保守までの各工程で、実施記録や承認記録などを残し、検証可能な状態で管理していく「IT内部統制」が必要になる。つまり、PMはプロジェクト全体で“可監査性”を意識しなければならない。

　そこでPMは、二つの面で情報管理を進める必要がある（図1）。一つは、プロジェクトの成果物に関する情報管理。構築するシステムに対して、情報管理に必要な機能を盛り込むことが重要になる。もう一つは、プロジェクト運営に関する情報管理。各工程での情報管理に加えて、有効な統制下でプロジェクトを運営していたことを証明するための情報管理、さらに情報管理を徹底するための枠組みに沿って運営することなどが要求される（表1）。

図1●情報管理に関する二つの論点
[画像のクリックで拡大表示]

表1●情報管理のポイント
[画像のクリックで拡大表示]

　以下、事例を通じてプロジェクトを実施する際に情報管理をどう進めていけばよいかを説明する。

情報管理機能をシステムに組み込む

　メインフレームを中心とするシステムを利用してきたユーザー企業A社は、顧客管理と情報分析を狙って、オープン系サーバーで稼働する顧客管理システムを新たに構築した。システム構築プロジェクトは遅延なく進み、本稼働に至った。誰もがプロジェクトは成功したと考えていた。

　そんな矢先、A社の顧客情報が流出した疑いが生じた。データの特性からみて、顧客管理システムに登録されている情報の可能性が高い。同社はさっそく調査を開始した。

　顧客管理システムでは、アプリケーションおよびサーバーOSへのログイン・ログ（履歴）は取得していたが、データベースの参照に関するログは取っていなかった。アプリケーションからデータ・ファイルをいつ、誰がダウンロードしたか、いつ帳票を印刷したかも分からなかった。

　ログイン・ログを調べたところ、システム運用上の問題点も明らかになった。本番環境のアプリケーションに対するログインに必要なユーザーIDとパスワードを、現場の担当者だけでなく情報システム部門の担当SE数人にも発行していたのである。障害対応や、プログラム・リリース時の動作確認で必要となるからだ。

　本番環境のサーバーOSおよびデータベースの特権IDのパスワードを、まったく変えていなかったことも判明した。いくつかのプログラムにパスワードを直接埋め込んでおり、パスワードを変えてプログラムを改変する必要が生じるのを避けたかったという。

　A社は「開発の外部委託先から情報が流出した可能性が高い」との結論を出した。プロジェクトを担当したPMは、「システムの機能面および運用面の考慮が不十分」と叱責を受けた。

　セキュリティの脆弱性を未然に防ぐには、プロジェクトの早期段階からリスク評価を実施することが重要である。具体的なセキュリティ基準が存在するのであれば、プロジェクトの企画あるいは設計の手順がその基準に準拠しているかを評価すればよい。具体的な基準が存在しない場合は、PMを中心とする関係者で議論し、リスク評価を進めるのが現実的だろう。

　企画段階のリスク評価は、マネジャなどが大まかなリスクを把握し、必要な対応方針を検討することを目的として実施する。評価の観点としては、（1）システムで取り扱う情報の重要性（個人情報か否か、など）、（2）機能上・運用上の留意点（大量のデータをダウンロードする、インターネット経由で利用する、外部とデータ・ファイルを送受信する、運用を外部委託する、など）といったものが挙げられる。

　設計段階では、より具体的かつ詳細にリスクを評価し、必要な機能が要件に盛り込まれているかを確認する。ここでシステムの運用面にも配慮しなければならない。A社のように、本来のユーザー以外の要員が本番環境にアクセス可能だったり、OSやデータベースの特権IDのパスワードが長期間変更されないケースは意外と多い。設計段階でこれらのリスクも評価し、必要な対策を講じなければならない。

　設計段階でのリスク評価は、（1）ユーザー認証、（2）アクセス権の設定、（3）蓄積データや伝送データの保護、（4）アクセス記録の取得と分析といった分野が対象となる。ISMS（情報セキュリティマネジメントシステム）認証基準を基に社内基準を策定する企業もあるが、そのレベルでは具体性に欠ける。例えばユーザーIDの不正使用防止に関しては、「パスワードの入力を一定回数失敗した場合、IDがロックされるか」、「ログイン後、一定時間操作しないと、強制的にログアウトするか」などと具体的な評価項目を作る必要がある。

　その際には、個人情報の安全管理措置について各種業界で策定されたガイドラインや、金融情報システムセンター（FISC）の「金融機関等コンピュータシステムの安全対策基準」などを参考にすればよい。A社の例では、例えば表2に示す対応策が必要になる。