開発環境と運用環境の分離ができない場合は変更コントロール
こんにちは、丸山満彦です。本日(正確には昨日ですが・・・)、多数の上場企業の財務諸表監査でIT全般統制の評価を行っている人と簡単な会話をしました。多くの企業で一番問題となっているのは、「開発環境と運用環境の分離」とその人はおっしゃっていました。
結局、人がいないので開発者が本番環境にも入れてしまう。確かにそれは問題なんですが、むしろ緊急時などは、開発者が直接本番環境のソフトを修正をするほうが間違いがなくてよい・・・という話もあります。
結局、開発者等が承認を得ずに勝手に本番環境のプログラムを変更してしまうのが問題なわけです。
防止的コントロールとして、開発環境と運用環境を分離し、アクセス管理などをして、事前に不正なプログラム変更等を防止することができないのであれば、
発見的コントロールとして、すべての変更されたプログラムの一覧をサンプルベースとし、サンプリングにより選ばれた変更が承認を得ていることを確認するという方法で統制目標を達成できることになります。
問題は、「すべての変更されたプログラムの一覧」を以下に作るかですが、現実的には自動化されたコントロールにより行うしかないでしょうね。
しかし、それができるようになっているので、案外、開発環境と運用環境を無理にわけるよりも、すべての変更された本番環境のプログラムが未承認で行われていないことを確認するようなコントロールを導入するほうが業務の有効性・効率性などの目的も考慮するとよいのかもしれませんね・・・
Comments
なかじまです。
本番環境のプログラムを変更の行為が承認されていることも重要ですが、変更が正しく行われていることを保証するため、テストが行われていることも重要だと思います。
本番環境のプログラムを直接変更するというのは、変更・テストが終了するまではプログラムが誤作動を起こす可能性があるため、「テストが出来る環境(開発環境でも可)」で変更しテスト済みのプログラムを本番環境に反映することが重要なのではないでしょうか?
「HTMLドキュメントの誤字の修正」というような変更であれば、本番環境での直接変更およびテストも、許されるかもしれませんが、そうでない場合においては環境の分離はテストを行う環境の確保と考えています。
本番環境におけるプログラムの変更履歴については、ライブラリ管理・アクセス管理等のツールで自動化は出来ると思いますが、変更対象のモジュールがテスト済みかどうかについては、自動化は難しいでしょうねぇ。
Posted by: なかじま | 2006.08.30 13:24
なかじまさん、コメントありがとうございます。
本番環境のプログラムの変更はすべて承認を受けた正当なものである必要がありますが、と同時に、本番環境に導入するプログラムは予定されている機能が実装されていて、予定されていない機能が実装されていないことが保証されていることが重要で、導入前のテストが重要となりますね。
もっとも、それを100%担保できるのかというとそういうわけではないですが・・・
Posted by: 丸山満彦 | 2006.08.31 12:30