システム監査技術者 2009年 午後1 問01
ERPパッケージの監査に関する次の記述を読んで、設問1～4に答えよ。
Z社は、日用品の卸売業者であり、財務管理、購買管理、会計などの業務システムをERPパッケージで再構築した。
〔ERPパッケージの概要〕
Z社が導入したERPパッケージ及び周辺システムの構成は、図のとおりである。
(1) OS及びDBには、汎用の製品が採用されている。DBへのアクセスは、初期インストールのときを除いて、DB用IDを使用しなくてもよいようになっている。
(2) 財務管理、購買管理、会計などの業務システムは、ミドルウェアを経由して、マスタファイル及びトランザクションファイルを共有している。利用者は、ユーザIDを使用して業務システムにアクセスする。
(3) ミドルウェアの主な役割は、業務システムが基盤のアーキテクチャに依存しないで処理できるようにすることである。また、業務システムの安定運用を支援するための機能やセキュリティのレベルを設定する機能として、例えば、次のような機能が搭載されている。
・パスワードの最少けた数の設定機能
・多重ログイン（同一ユーザIDによる同時・複数のログイン）禁止の設定機能
・業務システムへのアクセス、ログインの失敗、マスタデータの変更などにおけるログ採取の設定機能
(4) ERPパッケージの管理者用の機能を使用するためには、専用の管理者用ID（以下、管理者用IDという）が必要である。管理者用IDは、情報システム部のシステム管理担当者（以下、担当者という）3名だけが使用を許可されている。管理者用IDは、1ライセンス（1ユーザ）の契約で使用している。同時に1ユーザしか使用できないので、3名の担当者は、パスワードを共有している。パスワードは、暗号化してファイルサーバのフォルダに保存されている。そのフォルダには担当者以外はアクセスできないように制限されている。
(5) ERPパッケージのDBには、各種設定ファイルのほかに、商品マスタや取引先マスタなどのマスタファイルと、仕入実績などのトランザクションファイルがある。
〔周辺システムとの連携〕
販売管理システムは、ERPパッケージとは別に構築・運用されている。ERPパッケージは、販売管理システムから日次で売上実績データを受け取る。受け取った売上実績データは、会計システムに自動連携され、店舗別、商品分類別に集計される。
人事システムは、ERPパッケージとは別のシステムであり、人事システムからERPパッケージに、異動データが送られる。異動データには、所属部署及び役職の情報が含まれており、所属部署と役職に応じた利用権限が、ユーザIDに自動的に設定される。
ただし、この権限については、異動データで自動削除されないようになっている。その理由は、人事異動などに伴う業務引継期間中に元の部署の権限が使用できなくなると、業務に支障を来すからである。業務の引継ぎが完了したら、異動者は元の部署の権限を削除してもらうための申請を速やかに提出し、担当者が申請に従って管理者用画面で削除する。
管理者用画面で権限が付与された場合には、ミドルウェアの機能によってログが採取される。
〔システム監査の実施〕
監査部では、Z社のビジネスの中核を担うERPパッケージを対象としたシステム監査を、毎年実施している。既に、業務面や機能面の監査は実施しているので、今年度は、アクセス管理及びバックアップリカバリの適切性を確認するシステム監査を実施することになった。担当するのは、監査部のT氏である。
(1) アクセス管理の状況
T氏は、アクセス管理に関するリスク及びコントロールを表1のようにまとめた。
(2) バックアップリカバリの状況
ERPパッケージには標準で、データのバックアップのスケジュール管理機能が備わっている。担当者は、管理者用画面を使用して、バックアップの実行スケジュール、バックアップデータの記録装置、バックアップの種類（全件か差分か）などを設定する。T氏は、アクセス管理と同様に、バックアップリカバリについても、リスク及びコントロールを抽出して表2のようにまとめた。
項番①のコントロールについて、管理者用画面を確認し、バックアップデータが日次で取得されていることを確かめた。また、取得されたバックアップデータはすべて外部の保管業者に週次で送付し、保管していることを確認した。さらに、バックアップ媒体が読取り可能かどうかを定期的に確認していることを確かめた。
項番②のコントロールについて、障害発生時のリカバリ手順書及びリカバリ訓練の実施記録を閲覧し、問題がないことを確認した。しかし、災害発生時のリカバリについては手順書が作成されていないので、ERPパッケージのDBのバックアップが取得されていてもリカバリできないリスクがあると考えた。そこで、コントロール項目を追加して、更に詳しい調査を行うことにした。
設問1：
問題文を見る〔ERPパッケージの概要〕の(4)について、管理者用IDのライセンス契約に違反していないことを確認するための監査手続を、45字以内で述べよ。
模範解答
ミドルウェア上で多重ログインが禁止されていることを、設定画面を目視して確認する。
解説
解答の導き方
まず、確認したいのは、管理者用IDが1ライセンスの契約条件に反して使われていないかです。本文には「同時に1ユーザしか使用できない」とあり、さらに3名の担当者が同じパスワードを共有しています。このため、複数の担当者が同時に管理者用IDを使える状態なら、契約条件に反するおそれがあります。
次に、その同時使用を防ぐ仕組みを確認します。本文では、ミドルウェアに「多重ログイン（同一ユーザIDによる同時・複数のログイン）禁止の設定機能」があると説明されています。したがって、監査では、その機能が実際に有効になっているかを確かめる必要があります。
機能が備わっていることだけでは、禁止する設定になっているとは限りません。そのため、設定画面を目視し、多重ログインが禁止されている状態かを確認します。
誤りやすいポイント
- パスワードが暗号化され、アクセス制限されたフォルダに保存されていることだけを確認しても、複数人の同時使用を防げるとは限りません。
- 多重ログイン禁止の機能が存在することと、その設定が有効であることは別です。設定画面で実際の状態を確かめます。
- ログを確認するだけでは、同時使用を防ぐ設定になっているかを直接確認できません。ここでは、設定による予防策を確認します。
FAQ
Q: 3名の担当者がパスワードを共有していること自体が、設問の確認対象ですか？
A: ここで確認するのは、1ユーザの契約に反する同時使用が可能な状態になっていないかです。そのため、多重ログイン禁止の設定が有効かを確認します。
A: ここで確認するのは、1ユーザの契約に反する同時使用が可能な状態になっていないかです。そのため、多重ログイン禁止の設定が有効かを確認します。
Q: 多重ログイン禁止の機能があると本文に書かれていれば、確認は不要ですか？
A: 不要ではありません。機能の有無ではなく、実際に禁止する設定になっていることを確認する必要があります。
A: 不要ではありません。機能の有無ではなく、実際に禁止する設定になっていることを確認する必要があります。
関連キーワード: アクセス管理、多重ログイン、ライセンス管理、設定監査、認証
設問2：
問題文を見る表1中の項番①のコントロールが有効でも、リスクが十分に軽減されているとは言えない。T氏が本調査で更に確認すべきコントロールを、40字以内で述べよ。
模範解答
DB用IDのパスワードは、必要最小限の担当者しか知らないように管理すること
解説
解答の導き方
-
表1の項番①では、「ERPパッケージのDBに直接ログインされ、重要データが改ざんされたり、破壊されたりする」リスクが挙げられています。つまり、業務システムを通さずにDBへ接続できるIDが不正に使われると、重要データに直接影響するおそれがあります。
-
既に挙げられているコントロールは、初期インストール後にDB用IDのパスワードが変更されていることの確認です。これは、初期設定のパスワードがそのまま使われるリスクを抑えるものです。
-
ただし、パスワードを変更したことだけでは、その後のパスワードが誰に知られているかまでは分かりません。変更後のパスワードを多くの人が知っていたり、不適切に共有されていたりすれば、DBへ直接ログインされるリスクは残ります。
-
したがって、T氏はパスワードが変更済みかだけでなく、知る人を必要最小限に絞る管理も確認する必要があります。これにより、パスワードを知る人を通じた不正利用の可能性を低減できます。
誤りやすいポイント
- パスワードの変更だけで、DBへの不正ログインを防げると考えることです。変更後のパスワードが適切に管理されているかも確認が必要です。
- パスワードを定期的に変更することだけを追加のコントロールとして挙げることです。この設問では、誰がパスワードを知っているかを制限する点が重要です。
- ERPパッケージの管理者用IDと、DB用IDを混同することです。表1の項番①で確認する対象は、DBへ直接ログインするためのIDです。
FAQ
Q: パスワードが変更済みなら、初期設定のパスワードを使われる心配はないのではありませんか？
A: 初期設定のパスワードが残るリスクは抑えられますが、変更後のパスワードが広く知られていれば、不正利用の可能性は残ります。
A: 初期設定のパスワードが残るリスクは抑えられますが、変更後のパスワードが広く知られていれば、不正利用の可能性は残ります。
Q: なぜパスワードを知る人を絞る必要があるのですか？
A: DBに直接ログインできるIDのパスワードを知る人が多いほど、漏えいや不正利用の機会が増えるためです。
A: DBに直接ログインできるIDのパスワードを知る人が多いほど、漏えいや不正利用の機会が増えるためです。
Q: 「必要最小限」とは、どのような管理を指しますか？
A: 業務上そのパスワードを知る必要がある人だけに限定し、保管や共有の方法も含めて管理することです。
A: 業務上そのパスワードを知る必要がある人だけに限定し、保管や共有の方法も含めて管理することです。
関連キーワード: アクセス制御、特権アカウント、パスワード管理、最小権限、データベースセキュリティ
設問3：
問題文を見る表1中のaに入れるリスクを、40字以内で述べよ。また、異動者の申請による削除よりも確実にリスクを低減できるコントロールを、45字以内で述べよ。
模範解答
リスク：異動者の権限が削除申請漏れによって、引継期間を過ぎても使用できてしまう。
コントロール：異動者の元の所属部署での権限に期限を設定し、延長には申請が必要な手続にする。
解説
解答の導き方
この設問では、異動後も元の部署の権限が残ることで生じるリスクと、異動者本人の削除申請に頼らずにそのリスクを抑える方法を考えます。
-
まず、権限がどのように設定・削除されるかを整理します。人事システムから送られる異動データによって、所属部署と役職に応じた権限が設定されます。一方、本文には「この権限については、異動データで自動削除されない」とあります。つまり、異動後も元の部署の権限は自動では消えません。
-
自動削除しないのは、引継期間中に元の部署の権限が必要になることがあるためです。ただし、引継ぎが完了した後は不要になります。現行の手続では、異動者が削除申請を提出し、担当者が申請に従って権限を削除します。
-
この方法では、異動者が申請を忘れたり、遅れたりすると、元の部署の権限が必要なくなった後も残ってしまいます。その結果、異動者が不要な権限を使えてしまうことが、表1のaに入るリスクです。
-
より確実にするには、異動者本人が申請するかどうかに削除を委ねないことが重要です。元の部署の権限に期限を設定して期限到来時に失効させ、引継ぎの延長などで必要な場合だけ申請によって期限を延ばす仕組みにすれば、申請漏れによる権限の残存を防ぎやすくなります。
誤りやすいポイント
- 異動データにより権限が自動設定されることから、削除も自動で行われると思い込まないようにします。本文では、自動削除されないと明記されています。
- 引継ぎ中に元の部署の権限が必要になる事情は、権限を残し続ける理由にはなりません。引継ぎが終わった後も権限が残ることが問題です。
- 「異動者に削除申請を速やかに提出させる」だけでは、現行手続の徹底にとどまります。申請忘れや遅れそのものを防ぐ仕組みが、より確実なコントロールになります。
- 期限を設けるだけでなく、必要な場合の延長には申請を必要とすることで、引継ぎに必要な権限を確保しつつ、不要な権限の長期残存を防げます。
FAQ
Q: 異動と同時に元の部署の権限を削除する方法ではいけませんか？
A: 引継期間中に元の部署の業務を行う必要があり、権限をすぐに削除すると業務に支障が出る場合があります。そのため、期限を設けて必要な場合に延長する方法が適しています。
A: 引継期間中に元の部署の業務を行う必要があり、権限をすぐに削除すると業務に支障が出る場合があります。そのため、期限を設けて必要な場合に延長する方法が適しています。
Q: 削除申請を速やかに出すよう周知すれば、リスクはなくなりますか？
A: 周知だけでは、申請の忘れや遅れを完全には防げません。期限による失効を設けることで、本人の申請漏れに依存しない統制にできます。
A: 周知だけでは、申請の忘れや遅れを完全には防げません。期限による失効を設けることで、本人の申請漏れに依存しない統制にできます。
Q: 延長にも申請を必要とするのはなぜですか？
A: 期限を過ぎても権限が自動で延長されないようにし、引継ぎなどで必要性が続く場合に限って権限を残すためです。
A: 期限を過ぎても権限が自動で延長されないようにし、引継ぎなどで必要性が続く場合に限って権限を残すためです。
関連キーワード: アクセス制御、最小権限、権限管理、権限の有効期限、職務異動
設問4：
問題文を見る表2中の項番②について、災害が発生したときのリスクに対して追加すべきコントロールを、45字以内で述べよ。
模範解答
販売管理システムから受け渡される売上実績データのバックアップを日次で外部保管すること
解説
解答の導き方
-
表2の項番②には、障害時のリカバリに関するリスクと、災害時に外部保管のバックアップからリカバリできないリスクの二つがあります。今回問われているのは、後者に対する追加のコントロールです。
-
すでに、ERPパッケージのバックアップは日次で取得され、取得したバックアップデータは外部に保管されています。ただし、本文では「外部の保管業者に週次で送付」とあり、また、対象となるバックアップはERPパッケージのデータです。この対策だけでは、ERPパッケージの外にあるデータまで災害時に復旧できるとは限りません。
-
本文によると、販売管理システムはERPパッケージとは別に運用され、ERPパッケージはそこから日次で売上実績データを受け取ります。つまり、売上実績データはERPの業務に使われる重要な入力データですが、ERPパッケージのバックアップだけでは、受け渡し元のシステムにあるデータや、受け渡されたデータが確実に保全されているとは判断できません。
-
災害後に売上実績データを使って会計処理を復旧できるよう、受け渡されたデータ自体を日次でバックアップし、外部に保管する対策を加えます。これが、災害時に外部保管のバックアップからリカバリできないリスクへの追加コントロールです。
誤りやすいポイント
- ERPパッケージのバックアップが取得されていることだけで、販売管理システムから受け取る売上実績データも保護されていると考えないようにします。
- 既存の対策に「外部保管」が含まれていても、対象データと保管頻度を確認する必要があります。ERPパッケージのバックアップを週次で送付することと、売上実績データを日次で外部保管することは別の対策です。
- リカバリ手順書の作成や訓練は重要ですが、ここで求められているのは、災害後に復旧に使えるデータを確保するためのコントロールです。
FAQ
Q: なぜ売上実績データを日次でバックアップするのですか？
A: ERPパッケージは売上実績データを日次で受け取るため、そのデータを日次で保全すれば、災害後に復旧できないデータが生じる可能性を抑えられます。
A: ERPパッケージは売上実績データを日次で受け取るため、そのデータを日次で保全すれば、災害後に復旧できないデータが生じる可能性を抑えられます。
Q: ERPパッケージのデータを外部保管していれば十分ではありませんか？
A: ERPパッケージのバックアップだけでは、別システムから受け取る売上実績データまで保全されるとは限りません。データ連携の対象も確認し、必要なデータを別途保管する必要があります。
A: ERPパッケージのバックアップだけでは、別システムから受け取る売上実績データまで保全されるとは限りません。データ連携の対象も確認し、必要なデータを別途保管する必要があります。
Q: この設問では、リカバリ訓練を追加するのではないのですか？
A: リカバリ訓練は表2にすでに挙げられています。追加するのは、災害時の復旧に必要なデータを日次で外部保管する対策です。
A: リカバリ訓練は表2にすでに挙げられています。追加するのは、災害時の復旧に必要なデータを日次で外部保管する対策です。
関連キーワード: バックアップ、外部保管、災害復旧、データ連携、リカバリ
