経営者は、一般的なシステム管理における有効なIT統制として、「準拠性」「信頼性」「可用性」「機密性」という目標を求められています。
そして、その目標を達成するための主なIT統制活動として、IT全般統制とIT業務処理統制があります。
実施基準によると、IT全般統制とは、IT業務処理統制が有効に機能する環境を保証するための統制活動のことをいい、具体的な統制項目としては、以下のものがあります。
- システムの開発、保守に係る管理
- システムの運用・管理
- 内外からのアクセス管理などシステムの安全性の確保
- 外部委託に関する契約の管理
この記事では、この項目のうち「システムの運用・管理」に関連する統制活動について、簡単にまとめました。
※内部統制基準＝「財務報告に係る内部統制の評価及び監査の基準」
※実施基準＝「財務報告に係る内部統制の評価及び監査に関する実施基準」
システムの運用・管理の概要
実施基準では、システムの運用・管理の監査について、以下のポイントが挙げられています。
●システムを構成する重要なデータやソフトウェアについて、障害や故障等によるデータ消失等に備え、その内容を保存し、迅速な復旧を図るための対策が取られていること
●システム、ソフトウェアに障害や故障等が発生した場合、障害や故障等の状況の把握、分析、解決等の対応が適切に行われていること
また、「システム管理基準 追補版」では、システムの運用・管理の評価における留意点として以下のように記しています。
経営者は、企業が適切なデータを適切なプログラムで処理し、信頼できる処理結果を得るための統制が整備・運用されているかを評価する。
このように日々のシステム運用の中で、プログラムやデータ、蓄積されたトランザクションを守るため、以下のような点に着目して統制を整備します。
- システム運用体制の構築：業務分掌や組織図等による運用体制の明確化、システム運用会議体の運営 など
- 規程・マニュアルの整備：システム運用規程やシステム運用マニュアルの策定 など
- 運用管理：障害管理、バックアップ管理、ジョブ管理、規程・マニュアルの運用状況のモニタリング など
ジョブ管理
ジョブとは、蓄積されたトランザクションの集計のような、システムに実行させる処理の単位のことです。
そしてジョブ管理とは、ジョブの実行にあたり、処理漏れや処理の重複等の誤りが起こらないようにすることをいいます。
例）複数の店舗を有する企業において、各店舗の売上データがリアルタイムで本社のメインフレームに送られ、本社ではそのデータを毎日午後23時に集計し、会計システムに取り込んでいるケース
売上データ集計と会計システムへの取り込みというジョブにおいて、データの欠落や、処理漏れ等を防ぐための統制が必要になります。
統制の例
標準的の統制としては、以下のようなものが考えられます。
- ジョブスケジュール表の作成やジョブスケジューラの活用
- ジョブスケジューラの登録・変更に誤りがないよう、権限者の承認等の適切な手続きを定める
- ジョブスケジュールを実行する者の明確化
- ジョブ実行結果の確認
- ジョブ実行結果がエラーとなった場合の手続きを定める
- 臨時でジョブを実行する場合の手続きを定める
- ジョブ実行履歴（ログ）の記録
評価ポイント
上記の統制の整備・運用がされているかを評価するため、以下のようなポイントが検証されます。
- 定例のジョブにおいて、ジョブスケジューラへの登録・変更に際し、依頼書等に権限者の承認証跡があるか
- 臨時のジョブ実行において、依頼書等に権限者の承認証跡があるか
- ジョブスケジューラへのアクセス権限が設定されているか
- ジョブの実行結果を確認・記録しているか
- ジョブの実行結果がエラーとなった場合の対応について記録し、その適切性を検証しているか
障害管理
ITを利用した業務では、プログラムで一度処理手順等が定められれば、それが修正されるまで、同じ処理が繰り返し実行され続けます。
もしプログラムの不具合が放置されると同じ誤りが繰り返されることになるため、障害発生時に適切な対応が行われるような統制の整備が必要です。
障害とは
障害対応の記録を残す等の障害管理の際に、何を「障害」とするかは各事業のリスク評価の結果によって異なります。
そのため、システムの不具合や中断が起こった場合、どのようなリスクが発生し、それは業務にどの程度の影響を与えるのかを分析しておく必要があります。
障害対応と統制の例
たとえば、システム障害が発生すると担当者に連絡が入り、そのシステムが提供してきたITサービスの稼働状態を取り戻すため、重要度の優先順位に応じてまずは暫定的な対策をとることになります。
障害の原因が判明すると、再発防止のためシステム改修等の恒久的な対策を講じます。
また、システム障害では、ユーザー部門の要望とは関係なく、システムのプログラムやデータ、ハードウェア等を変更するきっかけとなり、さらに、緊急の対策が必要であれば、復旧作業によるシステム変更が規定の手続きを経ずに行われる場合があります。
そのため、システム変更等が適切に行われたかを事後に検証するためにも、障害対応の経緯を記録に残し、レビューできるようにしておきます。
評価ポイント
上記の統制の整備・運用がされているかを評価するため、以下のようなポイントが検証されます。
- 障害発生時の通知方法や連絡・対応体制が明確になっているか
- 障害発生の状況や原因、対処方法等について記録されており、必要に応じて適切な権限者の承認証跡があるか
- システム障害の記録についてシステム運用会議等でレビューが行われ、障害発生防止策等について議論されているか
バックアップ管理
さまざまなトラブルによってデータやプログラムの消失等を防ぐため、定期的にバックアップを取得し、万が一の時にはリストア（復元）できるようにしておく必要があります。
特に最近はランサムウェアの感染によりハードディスク等が暗号化され、データが利用できなくなる事案が増えており、その対策としてバックアップ管理が重要になってきています。
バックアップ管理では、以下の点が主なポイントとなります。
- バックアップが必要なデータの選定
- 適切なタイミングでのバックアップの取得
- バックアップデータの管理
- リストア（復元）の確実性
バックアップの方法
バックアップの方法には、主に以下のものがあります。
●フルバックアップ
フルバックアップでは、すべてのデータを保存します。
障害発生時には直前のフルバックアップだけでリストア（復元）できますが、バックアップのデータ量が大きくなり、バックアップにかかる時間が長くなります。
●差分バックアップ
差分バックアップでは、直前のフルバックアップ以降に作成・変更されたデータのみを保存します。
障害発生時には直前のフルバックアップと差分アックアップを用いてリストア（復元）するため、フルバックアップのみのリストアよりも手間がかかります。
しかし、フルバックアップのみのバックアップ管理よりバックアップのデータ量を抑えられ、バックアップにかかる時間が短くなります。
●増分バックアップ
増分バックアップでは、直前のバックアップ以降に作成・変更されたデータのみを保存します。
障害発生時には、まずフルバックアップをリストアし、次に取得した増分バックアっプを古い順にリストアします。
フルバックアップのみや差分バックアップよりもさらにリストアに手間がかかり、バックアップデータの管理も複雑になります。
しかし、バックアップのデータ量がより抑えられ、バックアップの時間ももっと短くなります。
バックアップデータの管理
●オフサイト管理
本番稼働しているシステムのデータが格納されている場所とは離れた場所にバックアップデータを保管しておけば、火災や自然災害等が発生した場合でも本番データかバックアップデータの両方が失われることがありません。
●世代管理
バックアップデータを保存する媒体を複数用意しておくことで、世代管理を行うことができます。
もちろん最新のバックアップデータを取得しておくことが最も重要です。
しかし、障害の発生原因が直前のバックアップ時より以前に起こっていたようなケースでは、直前のバックアップデータではなく、それより前のバックアップデータによるリストアが必要になる場合があります。
●ミラーリング
ミラーリングとは、同じデータを２つのサーバに同時に記録しておくことをいいます。
主サーバに障害が発生した場合、もう一つのサーバが機能を引き継ぐため、リストアの手間が省けますが、保存データの容量が大きくなります。
また、ミラーリングでは世代管理ができないため、別にデータのバックアップ管理が必要になります。
リストア（復元）
システムによってバックアップデータのリストア（復元）が頻繁に発生するものではない場合、いざ行うとなると不慣れにより手順漏れ等が起こりやすくなります。
そのため、マニュアル等を整備し、可能であればリストアの訓練を行っておくことが重要です。
ただし、本番稼働のシステムを利用してのリストア手順のテストは、システムへの影響が大きく困難が伴う場合もあるため、マニュアル等のレビューで済ませることが考えられます。
評価ポイント
バックアップに係る統制の整備・運用がされているかを評価するため、以下のようなポイントが検証されます。
- バックアップ管理の対象データ等が明確になっているか
- バックアップ管理が専用のツールやジョブスケジューラ等により自動的に取得されている場合、そのツールにおいて適切な設定がされているか
- バックアップの取得が確かに実行されているか
- リストアの手続きがマニュアル等で文書化され、レビューが行われているか
- リストアのテストが行われた場合、テスト結果が検証されているか
