プログラム変更はIT全般統制のもう1つの鍵：セキュリティツールで作る内部統制（9）（2/3 ページ）

[中島 浩光，＠IT]

「正しい」プログラム変更における統制活動

　では、「正しい」プログラム変更とはどういったものでしょうか？ プログラム変更における「正しさ」には、以下のような要素があります。

・業務上、変更が必要である

・変更内容が明確である

・変更内容によって目的が達成される

・変更作業が確実に行われる

・変更作業に不正がない

　上記のような要素を統制活動を通して実現していきます。そのための具体的なポイントを以下で説明します。

（1）変更が事前に計画され、承認されている

　本番環境のシステムの変更は、どのような場合に行うものなのでしょうか？ システムの変更には、アプリケーションの修正・機能の追加や、OSの設定変更・パッチ適用などがありますが、これらの変更は必要性があるために行われます。

　決して、システム管理者の思い付きや好き嫌いで行うわけではありません。従って、変更を行うに当たっては、「どういった理由で行うのか」「その変更はいつ行われるのか？」といったことをあらかじめ明確にするのに加え、変更対象のシステムのオーナーの承認を得ること、また、変更の計画やその承認を監査証跡として残すことが必要になります。

　具体的には、変更の承認プロセスを明確化し、変更についての計画を記述した文書や、それに対する承認行為を、監査証跡として残す必要があります（印鑑・サイン・議事録など）。

（2）変更の内容がテスト環境にてテストされており、その結果が承認されている

　本番環境のシステムの変更については、事前にその変更内容がテスト環境においてテストされている必要があります。

　つまり、事前のテストなしにいきなり本番環境でゴソゴソいじる、ということはあってはならないことなのです。従って、本番環境でのシステムの変更を行う前に、テスト環境において必要なテストを行い、変更の目的を達成できることを確認しておく必要があります。また、そのテスト結果に対する承認をしかるべき人間（システム所有者やユーザー、システム管理者）から得る必要があります。

　そして、実際の変更に当たっては、テスト環境においてテスト済みのモジュールを利用して変更を行うことが必要となります。

（3）変更管理手順が明確に定められている

　前述の2項目とも関連してくるのですが、システム全体の運用管理プロセスにおいて、本番環境に対する変更管理プロセスを明確にすることが必要です。

　変更の理由となる事象の発生の認識から、実際のソースコードの変更、テスト、本番環境へのリリースといったさまざまなタスクが発生します。

　こういった変更に関する一連のプロセスについてその流れをきちんと定義し、管理することが必要なのです。この変更管理プロセスにおいては、本番環境に対する実際の変更リクエストへの承認を、開発責任者、運用責任者、システムオーナーといったメンバーから得ること、かつ、承認されたリクエストのみを実際の変更作業に移すことが重要になります。

（4）変更における権限分離ができている

　通常、プログラムの変更が発生する場合には、開発（保守）担当者がプログラムの変更・テストを行い、その後テストされたモジュールを本番環境に移行するのが一般的でしょう。その際、権限分離（Segregation of Duties：職務分掌）が必要です。

　つまり、プログラム自体の変更を行う開発（保守）担当者、変更を承認する承認者、実際のモジュール移行担当者はそれぞれ別とし、特定の承認を受けたメンバーのみがモジュール移行担当者として移行を担当する必要があります。この権限分離の考え方は、プログラム変更において担当者の不正やミスを防ぐためにも必要なものとされています。

　しかしながら、実際にはそこまで人員の余裕がなく、開発担当者がモジュール移行も行ってしまう、つまり権限分離がされていないことも多いのが現状です。そうしたケースでは、次項に挙げるような方法で変更作業時のアクセス管理やモニタリングを工夫することによって、不正やミスを防ぐ必要があります。

（5）変更作業時のアクセス管理とモニタリング

　前項でも述べましたが、実際に本番環境への変更を行うに当たっては、変更作業者の不正やミスをどのように防ぐかがポイントになります。

　具体的には、「実際の変更作業内容・作業手順が明確になっているか」「変更作業に使用されるIDが個人を特定できるようになっているか」「IDに付与されているアクセス権が必要最低限の権限になっているか」「作業内容について監査証跡（アクセスログ）を取得しモニタリングしているか」といった点が挙げられます。

　米国SOX法の対応では、変更作業にrootを使用していたところ、監査法人から指摘を受けてしまい、アクセス権に制限のないrootではなく、適切なアクセス権を設定された個人IDを使用するようにし、作業履歴を取得したという例もあります。

　また、別の方法としては、OSレベルでアプリケーションプログラムファイルの変更・削除の履歴を取得し、それを監査証跡とし、変更管理のログと突合し定期的にシステムオーナーへ報告することで、承認された変更のみが起こっていることを担保するというものもあります。

　このように、変更作業において、OSレベルでの管理者権限の制限をしたり、その変更作業に必要なアクセス権の設定や、作業の履歴を取得・モニタリングすることが不正やミスを防ぐうえで非常に役立ちますが、通常のOSではそのために必要な機能が不足している場合があるのも事実です。そのため、米国SOX法対応においては、セキュアOSといわれるセキュリティ強化OSや、OSセキュリティ強化ソフト（例：CAの「CA Access Control」）を利用している例も多くあります。

（6）緊急変更のプロセスの定義とその実行

　通常の変更管理プロセスにおいては、これまで説明したような手続きを守ることが求められますが、緊急時においては、そういったプロセスを守っていると事態が手遅れになってしまう可能性もあります。

　こういったときのために、「システムにおいては緊急変更をしなくてはいけないことがあり得る」という前提で、緊急変更の際の手続きを定めておくことが必要です。ただし、その場合でも緊急変更が必要かどうかの判断基準、緊急変更内容の承認といったポイントを押さえ、それらを記録することが必要になります。