システム監査技術者 2017年 春期 午後I 問題

共通の文章

在庫管理システム統合計画の監査に関する次の記述を読んで,設問1~Sに答えよ。 P社は,コンベアチェーン,コンベアベルトを主力製品とする機械部品販売会社で HS,社の機械部品の製造・組立てを行っている子会社のA社とB社が,X年10 月1日付けで合併し,両社の情報システムを統合することになった。社の内部監査 部は,統合する情報システムごとに監査チームを編成し,統合計画の監査を行うこ とにした。そのうち,在庫管理システムの監査を担当することになったのは,K氏を リーダとする監査チームである。 合併の背景〕 P社では近年,複数の機械メーカから,チェーン,モータといった単品製品だけで はなく,複数の製品をあらかじめ組み立てた製品(以下,モジュール製品という) の注文が増加している。また,全国展開しているホームセンタから一括受注したDIY 用の機械部品を,各地の店舗に配送することも多くなってきた。 P社は,A社及びB社との業務連携を強化することによって,こうした変化に対応 してきた。しかし,A社及びB社の在庫管理システムの処理能力が限界に達してお り,更に取引件数・品目数の増加,物流効率の低下も予想される。そこで,A社とB 社の合併,及び工場と物流センタの再編によって,製造と物流の効率を抜本的に改 善することにした。 (A社及びB社の現状 (1)製品の製造と配送,売上・出庫処理 A社は主としてコンベアチェーン,コンベアベルトを3工場で,B社は主として コンベアの駆動用モータ,制御機器を2工場で製造している。 A社及びB社の各工場で製造された製品は,P社からの指示によって,全国5か 所に配置されたP社の物流センタに一旦搬入される。P社が顧客からの注文を受け て,製品を物流センタから顧客向けに出荷した段階で,P社から顧客への売上処理 が行われる。このデータに基づき,A社及びB社では,P社への売上処理及び出庫 処理が日々の夜間バッチ処理で行われる。 ータ2一 (2)モジュール製品の製造と在庫管理 モジュール製品の製造はA社が担当している。A社は,モジュール製品に組み 込むB社の製品をB社から直接仕入れ,モジュール製品に組み込む前まではA社 の製品在庫として管理している。完成したモジュール製品は,他の製品と同様に 物流センタに搬入される。 〔在庫管理システム統合計画の概要) A社とB社の合併,及び工場と物流センタの再編に当たっては,大規模な在庫の BE,両社の在庫データの統合,及び在庫管理システムの変更が必要になるので,P 社情報システム部は,A社及びB社の情報システム課と合同で,在庫管理システム 統合プロジェクトチーム(以下,統合PTという)を編成した。統合PTは,各社の 在庫管理部門,経理部門と連携して,在庫管理システム統合計画(以下,統合計画 という)を策定した。 統合計画によると,A社の在庫管理システムを存続させ,B社の在庫データを移管 することになっている。統合スケジュールは図1のとおりである。 X年8月31日X年9月30日X年10月31日X年11月30日 aa) 在庫数量差異調整在庫移管 システム変更,マスタ登録 図1統合スケジュール QO RMAs X48 A BL日に実施し,在庫数量の差異調整を行い,9月30日に在 庫場所ごと・品目ごとの在庫数量を確定する。 ②工場及び物流センタの再編計画に従って,在庫の移管を10月1日から開始し, 10月31日に完了させる。 ③A社の在庫管理システムにB社の在庫データを移管するためのシステム変更, マスタ登録を10月1日から11月30日の間で行い,11月30日の入出庫業務終了 後に在庫データの統合を完了させる。 2 8 x [予備調査でのインタビュー結果 K氏をリーダとする監査チームは,X年4月に統合PTのリーダにインタビューを 行った。次はその抜粋である。 Ql)在庫データの統合 ・A社及びB社では,異なる製品を製造しており,A社の製品コードは10桁,B 社の製品コードは9桁である。現状では,A社の製品コードの上から1桁目には “8”が使用されていないので,B社の製品コードの前に“8”を付加して10桁 LL,統合後の製品コードとする。 ・A社及びB社の在庫管理システムは同じソフトウェアパッケージで構築されて BY,上記のB社の製品コードの変換を除き,コード変換,項目の再設定など を行うことなく,両社の在庫データはそのまま統合できる。 (2)実地棚卸と差異調整 A社及びB社では毎年2月末日と8月末日に,工場及び物流センタの全製品の 実地棚卸を行っている。A社とB社の合併及び在庫の統合に当たっては,正確な 在庫数量の確定が重要なので,実地棚卸及び差異調整の手続を次のように見直し Tes ・実地棚卸で確認された在庫数量を在庫管理システムに入力し,在庫管理システ ム上の在庫数量と自動照合する。 ・照合の結果,一致しなかった(棚卸差異があった)品目について,棚卸差異デ ータが生成される。 ・各在庫場所の担当者が棚卸差異の原因を調査し,棚卸差異データに判明した原 A,及び調査後の適正数量の登録入力を行う。 ・棚卸実施責任者が,棚卸差異データに登録入力された原因の竣当性を判断し, 承認入力を行う。 ・承認された棚卸差異データに基づき,在庫データを適正数量で自動修正し,在 庫管理システム上の在庫数量を確定する。 (3)長期滞留品の取扱い A社及びB社では,12か月以上売上実績がない製品を長期滞留品としている。 在庫管理システムの在庫データには,品目ごとに直近に出庫された日(以下,最 ーーif va 終出庫日という)が記録されており,在庫管理システムから最終出庫日が実地棚 PHA O 12か月以上前の日付になっている品目を抽出し,長期滞留品リストを 作成している。長期滞留品リストに基づき,実地棚卸時に現品を確認した上で, 廃棄処理又は評価減処理を行うことになっている。 [リスク及びコントロールの状況〕 K氏の監査チームのメンバが,[予備調査でのインタビュー結果]に基づいて統合 計画におけるリスクを抽出し,各リスクに対するコントロールを表1のとおりまと めた。 表1リスク及びコントロール(抜粋) 1・在庫データの統合が,適正に行われない。・A社及びB社の統合後と統合前の在 庫データを在庫管理システムで全件 照合する。 2・実地棚卸の差異数量が,適正に修正されな|・棚卸差異の原因,及び調査後の適正 い。数量の登録入力ができる担当者を限 定し,十分な教育・訓練を行う。 3・在庫管理システム上の在庫数量が,実地棚[a EIOCE RUE UB—-MOKEERBE OA 始される。 [予備調査でのインタビュー結果〕」の(1)て(3)及び表1をレビューしたK氏は,B 査チームのメンバに次のとおり指摘した。 (1)表1中の項番1について,モジュールル製品製造用の一部製品の在庫データが統 合されず,複数の製品コードに分かれて記録されてしまうリスクを考慮する必要 がある。 (2)表1中の項番2のコントロールについて,[予備調査でのインタビュー結果〕」の ⑫)に記載されている職務分離に関するコントロールの記述が漏れている。 (3)[予備調査でのインタビュー結果〕の(3③)について,最終出庫日を滞留期間算出 の起算日にすると,次回(X十1年2月)の実地棚卸時に作成される長期滞留品リ スト上に抽出漏れが生じるおそれがある。 natal 5 a

共通の文章

システム開発における品質管理の適切性の監査に関する次の記述を読んで,設問1 ~4に答えよ。 C社は,全国に営業展開している金融機関X社のシステム開発及び運用を担う子 会社である。こご数年,開発中のシステムにおいて,本番稼働前のユーザ受入テス ト時に不具合が発生し,本番リリースに影響を及ぼす事態が発生している。そこで, X社の監査部が,C社におけるシステム開発の品質管理の適切性を監査することにな > 〔C社における品質管理の状況 C社には,五つの開発部,運用部,企画部,品質管理部及び間接部門がある。 品質管理部は,システムの設計(基本設計,詳細設計),製造(コーディング,単 体テスト)及びテスト(結合テスト,システムテスト,ユーザ受入テスト)の各工 程において,品質管理基準,及びシステム開発で使用する各種の標準・規約の維持 管理と,品質管理状況のモニタリングを行っている。 各開発部では,プロジェクトごとに,プロジェクトマネージャ(PM)が品質管理 基準に従って各工程の品質管理を行っている。 〔品質管理基準の概要〕 監査部は,予備調査としてC社の品質管理基準について確認した。品質管理基準 では,次のことが定められている。 (1)PMは,品質管理部が所管する標準・規約に従って開発を行い,各工程の品質評 価を行う。品質管理部が所管する標準・規約は,表1のとおりである。 (2)PMは,品質評価結果について,次のような点を品質管理部に報告する。 ・設計工程におけるレビュー密度,指摘密度などの実績値 ・テスト工程におけるテスト密度,欠陥密度などの実績値 ・各工程で,実績値が指標値の上下20%の範囲を超えた場合の理由及び品質向上 策 なお,ここでいう“Be”Lit,例えば,指摘密度については,指摘項目数を 設計書ページ数で除した数値を表している。 ーッー (3)プロジェクトが中規模(10人月以上50人月未満)又は大規模(50人月以上) の場合は,品質管理部の主導で工程完了判定会議を開催する。一方,小規模(10 人月未満)の場合は,品質管理部が書面で品質評価結果を審査し,工程完了判定 会議は省略される。実績値が指標値の上下20%の範囲を超えた場合は,品質管理 部が審査することによって,次工程への着手が認められる。 (44)プロジェクトでは,各設計工程の完了前に設計レビューを実施する。レビュー 実施時間は,設計書のページ数に応じて目標が設けられている。レビューの実施 結果は,レビュー記録表に記載される。 (5)製造工程では,プログラム作成者とは別の担当者がソースコードのインスペク ションを実施して,インスペクション記録表にその結果が記載される。 (6)テスト工程では,発見された不具合とその解決状況が不具合管理表に記録され る。 7)開発中及び本番稼働後に発生した障害などの不具合については,根本原因分析 を実施して再発防止を図る。根本原因分析では,障害の根本原因を分析し,対策 を立案・実施し,各開発部への横展開を行う。 (8)品質管理部は,年に1回,各プロジェクトから報告された品質評価の実績値を 集計する。実績値が指標値と掛け離れている場合は,実績値の妥当性を評価して 指標値を更新し,新たな指標値を各開発部に通知する。 表1品質管理部が所管する標準・規約 内容(Bil) ・各工程で実施すべき作業内容,作成するドキュメントの種類と承認のルール ・プログラム名,項目名などの命名の規則 ・正規化,データベース構造,インデックス作成などのルール 計標準 ・作成するドキュメントのフォーマット,記載・更新のルール ・各工程でのドキュメントレビューへの参加者,レビュー実施時間などの指標 レビュー標準値 ・基本設計,詳細設計工程におけるレビュー密度,指摘密度などの指標値 ・結合テスト,システムテスト,ユーザ受入テスト工程におけるテスト密度, テスト標準欠陥密度などの指標値 ・不具合の管理ルール 本8ェーー 監査部は,本調査として,品質管理基準の運用状況を確認した。詳細設計工程及 びシステムテストエエ程の完了判定に関する確認結果は,次のとおりである。 【詳細設計工程の完了判定に関する確認 (1)昨年度に完了した50件のプロジェクトの適用状況について 50件のプロジェクトのうち,中規模以上は21件,小規模は29件であった。中 規模以上の21件のうち,詳細設計工程の指摘密度が指標値の上下20%の範囲内の ものは19件であった。その中から3件をサンプリングして,レビュー記録表の内 容と工程完了判定会議への提出資料とを照合して確認した結果,3件ともレビュー 指摘件数に差異が見られた。PMに確認したところ,次のような回答があった。 "詳細設計を担当したのが新人であったことから,教育も兼ねて全ての指摘を レビュー記録表に記載させたので,レビュー指摘件数が多くなった。このうち, 単純ミスや標準に合致しない記述の修正指摘などは,重要性が低いと考え,品質 管理部への報告書では除外した。” この回答を受けて,監査部は,レビュー指摘件数のカウント方法について品質 管理部に問い合わせ,確認した。 (2)指摘密度が指標値の上下20%の範囲外であった2件について 工程完了判定会議の議事録を査半したところ,2件とも,指摘密度は指標値の半 分以下であった。その理由として,PMからの報告書には,“過去に開発したシス テムで参考にできる機能が多く,設計書も流用できるものが多い"という記載が あった。監査部は,品質管理部に確認し,工程完了の判定は妥当であると判断し io (3)昨年度の工程完了判定会議の記録,及びレビュー記録表について 本番稼働後の障害発生が増加していることから,昨年度の中規模以上のプロジ ェクトにおける工程完了判定会議の記録21件を,全て調査した。その結果,詳細 設計工程で作成することになっているドキュメントは全て作成され,品質評価結 果の報告書についてもPM及び品質管理部の承認印があった。 次に,(①で抽出した3件のレビュー記録表を一覧表にして比較・検討すること にした。そのために,表計算ソフトを使用して,レビューアごとの指摘区分別の 指摘項目数をカウントした。 ー9一 なお,指摘区分とは,指摘の内容について,単純ミス,機能要件の理解不足, 機能漏れなどに分類したものである。 レビュー記録表には,レビュー実施日時,レビュー対象ドキュメント,ページ 数,ドキュメント作成者,レビューア,レビュー観点,指摘区分,発生原因が記 載されている。 [システムテストエ程の完了判定に関する確認 監査部は,X社ユーザ部門のT課長にユーザ受入テストの問題点についてヒアリ ングを行った。その結果,T課長からは,“本来はC社のシステムテストで発見され るべき不具合が,ユーザ受入テストで発見されることがある。C社でのテストケース が不足しているのではないか"という回答があった。 そこで,監査部がシステムテスト工程の完了判定会議の記録を確認したところ, 不具合が解決すればシステムテスト工程が完了したとみなし,承認されていた。監 査部は,完了判定基準の項目が不十分な可能性があると考え,品質管理部にヒアリ ングを行った。

共通の文章

制御ネットワーク及び制御システムの監査に関する次の記述を読んで,設問1~4 に答えよ。 D社は,エネルギー企業グループ系列の中規模の石油精製会社である。東京に本社 があり,東日本で製油所を操業している。 [D社ネットワークの統合〕 D社では,老朽化した製油所の装置設備を,10年前に改装した。その際,製油所 の石油精製制御システム(以下,制御システムという)も刷新した。また同時に, 制御システムが接続されている製油所のネットワーク(以下,制御ネットワークと いう)と,生産管理システムなどの各種業務システム(以下,業務システムという) が接続されているネットワーク(以下,本社基幹ネットワークという)を統合した。 D社の現在のネットワーク構成(概要)を,図1に示す。 SPA |本社基幹ネットワーク 生産管理システム||需給管理システム|経営管理システム|| !サーバサーバザーパが! juトーーインターネットへ サービス網 ーーデーペーニーどこで ーー !Ma=a a>|FW.B|!インターネットを !制御機器中継機器 た 制御ネットワークセンサKT SW:スイッチングハブ 図1 D社のネットワーク構成(概要) 制御ネツットワークは,広域イーサネットサービス網で本社基幹ネツットワークと接 続されている。また,制御システムの遠隔監視・保守のために,インターネットを PUT,制御システムの導入を担当したベンダである社と接続されている。 (制御システムの刷新及び業務システムとの連携 刷新前の制御システムは,E社独自のシステム機器及び通信プロトコルを使用して 構築され,製油所内の閉域ネットワークで稼働していた。その後の情報技術の進歩 で,一部の装置を除き,汎用のシステム機器を用いることが可能になったので,fil 新時に,コスト面で優位であるそれらの機器を導入した。また,汎用の通信プロト コルを利用して,制御システムを業務システムの一つである生産管理システムと連 携させ,リアルタイムにデータを共有することによって生産性の向上を図った。そ の後,順次,電給管理システム及び経営管理システムとも連携させ,D社の経営効率 の向上を図ってきた。 [予備調査の実施〕 ぜい 最近,他社で制御ネットワーク及び制御システムの脆弱性を突いたセキュリティ インシデントが発生したことを受け,D社の社長は,内部監査部長に制御ネットワー ク及び制御システムのセキュリティ管理状況を監査するよう指示した。 制御ヘミットワークは本社基幹ネットワークと接続されていることから,システム 監査人は,予備調査の一環として,それぞれのネットワーク及びシステムのセキュ リティ管理の相違点について比較し,表1のとおりまとめた。 Rlセキュリティ管理の相違点(抜粋) 制御キネットワーク本社基幹ネットワーク 製油所安全管理規程情報セキュリティ管理規程 2|セキュリティ管理部署|製油所の操油部計装課本社の情報システム部セキュリ ティ管理課 セキュリティ管理者機械及び電気の専門技術者|情報セキュリティの専門技術者 4|セキュリティ管理の考|物理的セキュリティを重視|物理的セキュリティに偏らな え方い,バランスがとれたセキュリ ティを重視 5|優先されるセキュリテ|24時間365日連続稼働(装|情報漏えいからのデータ保護 イィ要件置設備の法定点検時などの 停止を除く) [本調査での発見事項 システム監査人による本調査の結果,次のことが判明した。 )表1の項番1-3について,製油所安全管理規程及び情報セキュリティ管理規程 の改訂は,ネットワーク統合時に各セキュリティ管理部署主管で行われている。 また,製油所安全管理規程の承認は製油所安全管理委員会で,情報セキュリティ 管理規程の承認は情報セキュリティ管理委員会で,それぞれ行われている。 これらの規程では,ネットワーク及びシステムのセキュリティ管理において遵 守すべきルール,セキュリティ管理部署及びセキュリティ管理者の役割と責任範 囲などが定められている。しかし,両規程は個別に策定されており,D社における 全社的ながセキュリティ管理の観点からは内容の確認が行われていない。 (2)#1の項番4について,制御ネットワークでは,物理的セキュリティが重視さ れており,本社基幹ネットワークに比べてセキュリティ管理対象が限定されてい る。 したがって,マルウェアの物理的な感染経路であるUSBポートは,セキュリテ イィ対策が講じられているが,制御ネットワークへの論理的アクセス制御やサーバ のハードニングなど,管理対象として重視されていないセキュリティ領域の対策 が不十分である。このため,システム設定上の不備に起因するセキュリティイン シデントが発生するおそれがある。 (3)OS開発元が提供するセキュリティパッチを制御システムに適用するに当たって lk,表1の項番5に示したセキュリティ要件を満たすことを,セキュリティ管理 者が事前に確認する必要がある。さらに,制御システムは,製油プロセスを制御 データの数値によって正確にタイミングよく制御するために,プログラムロジッ ク及びパラメタ値が最適化されている。このため,制御データ処理時の数値の変 動とタイミングの変化が定められた範囲に収まることも,セキュリティ管理者が 事前に確認する必要がある。 また,セキュリティパッチヂ適用の間隔が比較的長いこともあり,その間のOSの 脆弱性を突いたセキュリティインシデント発生に備えた補完的コントロールが必 要である。 (4)操油部計装課には情報セキュリティの専門技術者がいないので,図1に示した FW-Bの設定は,E社が推奨するポリシに基づいて,E社の技術員が行っている。 ー{9 また,操油部計装課は,FW-B経由の遠隔監視・保守に伴う不正アクセスを防ぐ ために,次の対策の,②を講じるようE社に求めている。さらに,各対策が適切 に行われていることを確認するために,四半期ごとに社から報告を受けている。 対策①遠隔監視・保守を行うために制御ネットワークに接続する端末及びその 利用者を限定する。 対策②制御ネットワークへのアクセス状況を記録し,遠隔監視・保守以外の操 作の有無を,製油所安全管理規程で定められた頻度で確認する。異常が発 見された場合には,直ちに操油部計装課に報告する。