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