概要
企業の情報システムにおいて、適切なシステム運用設計を行うことは、業務の安全稼働のみならず、ビジネスの効果を最大限に引き上げるために、非常に重要な役割をもつ。 長年製造業のシステム管理に携わってきた著者が、実体験をもとに、「システム運用設計」に織り込むべきことや、運用管理とシステム開発の関係などについて語る。
皆様こんにちは、伊藤です。
当コラムを担当して、６回目を迎えました。「システム運用設計」で必要なこと というテーマを頂き、私が日頃考え、実施していることを中心にお話してまいりましたが、今回でいよいよ最終回となりました。
今回はＳＯＸ法やいわゆる日本版ＳＯＸ法に対応するために必要なＩＴ全般統制を考慮した運用設計についてお話いたします。
- 目次
- ＳＯＸ法とＩＴ全般統制のおさらい
- ＩＴ全般統制で必要な、システム運用の項目
- ＩＴ全般統制に関するシステム運用を効率化するための運用設計
- プログラムとデータへのアクセス管理を効率化するための運用設計
ＳＯＸ法とＩＴ全般統制のおさらい
ＳＯＸ法等は極めて乱暴に言えば、財務諸表作成に至るまでの様々な業務や組織の “統制状況”が適切であるかどうかを評価した結果を、財務諸表とともに証券取引所に提出する制度です。この評価対象の中に、財務諸表につながる経理データ（売上げ、在庫、資産等々）を日々処理している業務のプロセスの統制があります。
これは、個々の業務プロセスの中で、リスクコントロールが正しく機能していることを評価するわけです。例えば、材料の仕入れが、もれなく、正確に処理されているための作業手順などを、手順が明確化されていること（整備状況監査）、その手順が正しく遂行されているかを、サンプリングや、データのマッチングなどで監査されます（運用状況監査）。
このそれぞれの業務プロセスの中には情報システム処理が入り込んでいるわけですが、これは、手作業ではなく、自動処理とみなされます。手作業の場合は、その作業が適切に実施されていることを統計的に評価するためのサンプリングが行われますが、自動処理の場合は、サンプリングは行なわれません。
ただし自動処理であるためには「ＩＴ全般統制」が機能していることが必要となるのです。このため、情報システム部門で「ＩＴ全般統制」が機能していることを外部監査人から監査されるわけです。図１（この図は第４回のオーナーの責任の項でも使用しました）にこの関係を図示しました。
図１：財務報告に係わる内部統制の構造
一方、業務プロセス自体と、そこに組み込まれる情報システム(アプリケーション)の機能は密接に連携しており、業務プロセスの責任者は、システムの仕様や、運用状況に起因するリスクの認識と対応に責任を持っています。（例えは悪いですが、ユーザーの権限分離ができていないシステムを使用している場合は、システムの外側でその替わりの統制作業を行わなければなりません）
したがって、個々のアプリケーションの使用の際に使用されるＩＤと権限の設定、パスワードの管理、そして、これらの統制状況は、「IT全般統制」とは区別され、個別業務プロセスの一環として、「アプリケーション統制」と呼ばれ業務統制の一環として監査されます。
ＩＴ全般統制で必要な、システム運用の項目
図１で表していますが、システム運用とシステム開発を分けた場合、ＩＴ全般統制に関して、特にシステム運用に要求される項目は以下の２つです。
１．システム運用そのもの
２．プログラムとデータへのアクセス
前者は、システム運用が正しく行われていること、後者はプログラムやデータへのアクセスは管理された状況にあるか ということです。
これらは、業務システムや、システム稼動環境によって必要な実際の統制作業が大きく異なってきます。つまりＩＴ全般統制を考慮した業務システムの設計が行なわれることによって、運用部門の効率が大幅に違ってくるということです。それでは、それぞれについて、どのような運用設計が行われるとよいのでしょうか。
ＩＴ全般統制に関するシステム運用を効率化するための運用設計
システム運用の分野でのＩＴ全般統制の評価項目の例を次に示します。
まず、ＩＴ全般統制で要求されている項目を、その統制目的から整理すると次の３点になります。
１）統制目的１
コンピュータ処理の可用性（サービス維持）を保持するため以下のリスクに対応すること
1. 異常な状態（能力不足や機器の故障）が発生し、
処理（サービス）が停止する
処理（サービス）が停止する
2. システム障害により、事業活動の停止やデータの消失等が
発生する。
発生する。
3. データの利用可能期間が法令などに準拠しない。
２）統制目的２
コンピュータ処理（記録・処理・報告）の信頼性を保持するため、以下のリスクに対応すること
1. コンピュータのバッチ処理（日次、週次、月次、年次）が
不完全・不正確に実施されること
不完全・不正確に実施されること
2. 処理に異常が発生しても適切に処理されず、情報の信頼性
が損なわれる。
3. システムソフトウェア（OS,DBMSなど）の不適切な管理により、
処理の信頼性が損なわれる。
３）統制目的３
外部委託業務が適切に管理されないため、外部委託業者がサービスを適切に提供できない
運用の対場からこれらを考えると、システム障害や、異常処理の際、エラー表示をしてシステム停止をさせる場合でも、どのようなエラーが起こったのかについて、エラーの事象、たとえば「中間ファイルのサイズオーバーのエラーが発生した」という表示ではなく、「同時利用者が仕様上の設定より増えた」 とか、「注文数が設定より増えすぎた」など、より発生理由に踏み込んだエラー表示を行うように設計する。
さらには、データ発生時に仕様と比較してそのまま処理をすすめればエラーが発生する可能性が高い場合は、データ発生時（入力画面など）に入力規制の表示をさせる等の機能を織り込んで、運用が調査する項目や時間を短縮できるシステムが、運用にとって、よりよいシステムとなります。つまり、こうすることによって、その異常や障害がＯＳやＤＢの固有の問題で発生したのか、業務系の理由で発生したのかの区別がつきやすくなり、結果として、可用性も向上し利用者にも有効なシステムが提供されます。
一方、システムソフトウェア（ＯＳやＤＢ）の不適切な管理 というリスクは、例えば脆弱性パッチを適用する際、適切なテストの実施をせずに、ＯＳをアップデートしてしまう際に障害が発生する可能性を示しています。この問題については、あらかじめこれらのテストのためのテストプログラムを準備してあると対応が容易になります。開発サイドとしては面倒な機能追加かもしれませんが、オープン系のシステム構築と、ＯＳの脆弱性をついたウイルスの発生が日常的になった昨今では、脆弱性対策パッチを当てることは常識化していますので、ぜひ対策しておいていただきたい項目です。
この点でもう一点留意点を挙げると、ＯＳやＤＢの正式な機能だけを使い、ＯＳ、ＤＢのベンダーが動作保障していない機能を使わずにシステム開発することも重要です。ベンダーが動作保障していない機能は、脆弱性対策パッチを当てたりすることで使用できなくなるケースが多く、後々問題となるからです。
プログラムとデータへのアクセス管理を効率化するための運用設計
前項と同様に、プログラムとデータへのアクセス管理の分野でのＩＴ全般統制の評価項目の例を次に示します。
同じく、統制目的で分類すると以下の２点になります。
１）統制目的１
情報セキュリティに関する全社のレベルを統一するため、以下のリスクに対応すること
情報セキュリティの認識のレベルが異なることにより、セキュリティホールが発生する
２）統制目的２
情報セキュリティ基盤のセキュリティ対策に関して、以下のリスク対応がなされていること
1. OSレベル（データベース含む）への不適切なアクセスにより、
プログラム及びデータに権限外のアクセスが行われる。
2. コンピュータ機器の不適切な物理的アクセスにより、
コンピュータや外部メディアの破壊や盗難・情報漏洩が
発生する。
3. 現場によるデータ利用（ＥＵＣ）で権限外のアクセスや
情報漏洩が発生する
4. ネットワークから外部の不正なアクセスが行われ、
不正なプログラムやデータの改ざんが行われる。
この点で運用担当のアクセス管理について特に多い問題は、データベースの直接操作を、通常の業務処理の中に組み込んでいる場合です。具体的には、我々のような製造業の場合、パーツサプライヤーが多数いらっしゃいますが、サプライヤーを新規追加したり、削除するような業務を、業務プログラムを通さず、サプライヤーのマスターデータをデータベースのツールにより、直接操作する形にしたり、あるいは（これは盲点になるのですが）、業務ユーザのＰＣからオフィスソフトを通じてデータベースにＯＤＢＣ等で直結させることなどです。
これらの何が問題なのでしょうか。
業務システムの通常運営のなかにＯＳレベルのアクセスを組み込んでしまうと、ＯＳレベルのアクセスが異常か正常かの区別がつけにくくなってしまいます。ＯＳレベルの操作は、通常の運用の手順の中では極力避けることが望ましいのです。このような作業は自動化されている訳ではなく、業務側からの依頼に基づく人手での作業ですから、個々の依頼書の有無、それに基づいて正しく処理することと、そのことを承認したことの記録が必要になって参ります。この承認や記録のコストも積みあがれば大きな数字になります。（ＩＴ全般統制の監査の際は、ＯＳレベルの人手処理について、個々に承認された操作であることを確認するためサンプリングによる抜き取り監査が行われます）
業務ユーザーのＰＣから、オフィスソフトを通じてデータベースを間接的に操作する場合は、一見、業務システムに組み込まれた機能のように見えますが、実際は関係のないデータまで操作できてしまうケースが多く、またこの操作と、ＰＣにインストールされた業務アプリによる操作をデータベース側から区別できるようになっていない事が多く、そのような操作を抽出することもできない場合があるので、統制が煩雑になってきます。
したがって、運用設計に際しては、通常の業務プロセスで起こりうるデータベース操作などは、業務アプリケーションの機能として実装し、業務アプリケーション側のＩＤの権限や、操作記録が残る様にすべきだと考えます。
システム開発コストに制約がある場合にこのようなケースが多く見られますが、実際の運用でのランニングコスト（実際のデータベース操作以外の管理コスト）は継続的に発生し、人手による作業のためミスも起こりがちです。
これらの内容を、運用設計の際にぜひ織り込んでおけば、低いコストで安定した運用ができるシステムが出来上がります。
システムオーナーからの注文と限られた予算、期日の中で開発するため、無理を言うなよ。と言われることは承知の上ですが、システム運用は長く、継続的に続くため、運用コストの差は経営への影響は大きくなります。システム開発に関係する皆様にはぜひ理解していただきたいと存じます。
さて、以上で私のコラムを終了させていただきます。
拙い文章を読んでいただいた皆様に感謝するとともに、
このような場を設けていただいた、システム管理者の会にお礼を申し上げます。
ありがとうございました。
連載一覧
筆者紹介
伊藤 裕 (いとう ゆたか)
トヨタ車体株式会社 情報システム部 ITマネジメント室 参事補
自動車製造業でのシステム管理、運用部門の管理者をはじめ、IT予算管理、J-SOX、セキュリティ対策対応など、企業の情報システムにおける様々な経験をもつ。
コメント
投稿にはログインしてください