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

共通の文章

DevOpsを適用したシステム開発・運用の監査に関する次の記述を読んで,設問に 答えよ。 A社は,衣料品などを販売する企業であり,ECサイトを構築し,運用している。A 社ECシステムでは,ECサイトの頻繁な更新や新たなサービスへの迅速な対応が求め られることから,アジャイル開発を採用してきた。また,ECシステム以外の情報シ ステムでもアジャイル開発が増加し,本番リリースの頻度が高くなってきたことか ら,システムの開発・運用プロセスを見直してDev0psを適用することになった。 ECシステムにおけるDev0psを適用した開発・運用プロセスについて,A社監査部 のシステム監査チーム(以下,監査チームという)が監査を実施することになった。 監査の主な観点は,リリースサイクルの短縮というDevOpsの適用目的が達成される ような運用方法になっているかどうか,及びDev0ps特有の環境や開発・運用プロセ スにおけるリスクに対応できているかどうかである。 (ECシステムの開発・運用プロセス]〕 A社のECシステムにおける開発・運用プロセスの概要は図1のとおりである。 (ase UR |thts)(a)Ge)[enn]! Sa a a |::::| [owns ai}lean ar]ofoenr-Jo[235%Jol|| ems <CI/O38 FA A> ーー 注記破線の矢印はデプロイを示す。 図1 A社のECシステムにおける開発・運用プロセスの概要 CIとは,プログラムの開発と単体テストを自動化することであり,CDとは,開発 ー2一 又は修正したモジュールを実行環境に移送して実行可能な状態にする作業(以下,デ プロイという)を含めて自動化することである。自動化すると,一連の作業として本 番リリースまで実行されるので,A社では,ウォーターフォール型開発でいう単体テ スト以降の工程を,“ステージ"と呼んでいる。 A社のDev0psの環境の概要は,次のとおりである。 (1)開発環境 エディター,コンパイラ,デバッガなどの開発ツール群が,開発担当者のローカ ルの環境に提供されている。 (2)リポジトリ 構成管理ツールによって,開発されたソースコードのバージョン管理機能及び保 管先としてのリポジトリが提供される。ソースコードには,許可された開発担当者 だけがアクセス可能である。また,インフラに関する設定情報を管理し,各ステー ジにおける環境設定の自動化を支援する。 (3)実行環境 各ステージでは,ソースコードから実行可能なモジュールの生成(以下,ビルド という),デプロイ,テストなどの自動化を支援する各種のツール(以下,CI/CD ツールという)が準備されている。各ステージの概要は,次のとおりである。 ①単体テスト:開発環境から構成管理ツールにソースコードを格納し,モジュー ルのビルドから単体テストまでを実行する。単体テストを完了したモジュールが リポジトリに格納される。 ②機能テスト:実行環境にモジュールをデプロイし,機能要件の検証及び性能要 件を除く非機能要件の検証を行う。 ③性能テスト:実行環境にモジュールをデプロイし,性能要件の検証を行う。 ④ユーザー受入テスト:実行環境にモジュールをデプロイし,機能要件を満たし ているか,情報システムが使いやすいかなどの利用者観点の検証を行う。 ⑤本番リリース:本番の実行環境(以下,本番環境という)へのモジュールのデ プロイを行う。 〔予備調査の実施〕 監査チームが,予備調査で把握した内容は,次のとおりである。 (1)開発・運用の体制 ECシステムにおけるDev0psを適用した開発・運用の体制について,営業部のS 課長にインタビューした。S課長は,ECシステムの開発・運用に関する最終決定権 と責任をもつプロダクトオーナーである。インタビューの結果分かったことは,次 のとおりである。 ①S課長の下に,利用部門としての要件整理と検証を行う業務チームがある。 ②機能ごとに五つのスクラム開発チーム(以下,開発チームという)があり,プ ログラムの開発からリリースまでを担当する。各開発チームの構成は,開発チー ムのリーダーであるスクラムマスター1名と3~6名の開発担当者である。 ③共通チームは,コーディングルールやCI/CDツールの効果的な使用方法につい ての標準化など,各開発チームに共通する課題を担当する。 ④運用チームは,主にサーバやネットワークの構築及び運用を担当する。 (2)開発・運用の状況 DevOpsを適用した開発・運用の状況について,複数の開発チームのスクラムマ スター及び開発担当者へのインタビューの結果分かったことは,次のとおりである。 ①Dev0psでは,開発担当者がCI/CDツールを利用して,本番環境を含む各実行 環境にデプロイすることが可能である。CI/CDツールでは,各環境へのデプロイ の権限及びアクセス可能な環境や期間を開発担当者ごとに設定できる。また,デ プロイや設定変更が行われると,指定した者に通知されるように設定できる。 ②Dev0psの適用によってリリースサイクルを短くしていくために,CI/CDツール を活用して本番リリースまでのステージの早期の自動化を目指している。 ③各開発チームには開発スキルの高いメンバーが集まっており,それぞれが自分 の担当する機能の開発に集中して作業しているので,プログラム開発の生産性は 高く,単体での品質は高い状況である。しかし,先日,他チームの進捗遅延の支 援のためにプログラムの修正を行った際に,担当したメンバーが修正前のプログ ラムを理解するのに時間が掛かり,生産性が期待よりも低いことがあった。 ④CI/CDツールの自動化の設定については,開発担当者の習熟度に応じて適用範| 囲を順次拡大していく計画である。リリースサイクルの短縮の第一段階となる単 体テストステージでは,各スクラムマスターが開発担当者の権限を設定している。 ー4ォー [監査手続の検討] 監査チームは,予備調査の結果を踏まえて,ECシステムにおけるDev0psを適用し た開発・運用についてリスクを分析し,監査手続を検討している。【[予備調査の実 施〕(2)開発・運用の状況①ー④について検討した内容は,次のとおりである。 (1)①のような状況下では,未承認のプログラムが本番環境にデプロイされてしま うリスクに対して,従来のウォーターフォール型開発で必要とされてきたコントロ ールを適用することは適切ではない。CI/CDツールの設定による予防的なコントロ ールや未承認のデプロイを適時に発見するコントロールによってリスクの低減を図 る必要があるので,これらのコントロールが設定されているかどうかを確認する。 (2)②について,CI/CDツールによってテストを自動化するステージの範囲を設定 CX,DevOpsの適用目的の達成を可能とすることは理解できる。しかし,全ての ステージを自動化するべきではないので,自動化の検討範囲について確認する。 (3)③について,共通チームが役割を十分に果たせていない可能性があるので,ZA クラムマスターにインタビューして確認する。 (4)について,Dev0psの適用目的を達成できるようになっているかどうか, CI/CDツールの運用方法を確認する。

共通の文章

システム監査報告書の作成に関する次の記述を読んで,設問に答えよ。 B社は,中堅の食品専門商社である。近年の厳しい経営環境の中,ITコスト低減の ために,従来オンプレミスで開発・運用していた基幹システムを1年前にクラウド環 境に移行した。B社内部監査室のシステム監査チームは,クラウド環境に移行した基 幹システムの信頼性及び安全性について,ITコスト低減による問題が生じていない か,統制の整備状況及び運用状況のシステム監査を実施した。 [システム監査報告書案の作成〕 システム監査チームは,監査結果をまとめ,表1のとおり,システム監査報告書案 を作成した。また,システム監査チームが実施した監査手続及びその結果は,表2一 表4に示す監査調書にまとめられている。 内部監査室長は,監査調書を参照しながらシステム監査報告書案をレビューした。 表1システム監査報告書案(抜粋) 1.監査目的クラウド環境に移行した基幹システムの信頼性及び安全性について,統制 の整備状況及び運用状況の観点から評価及び検証を行う。 2.監査対象基幹システム(会計システム,販売システム,購買システム)のうち,会 計システムと販売システムを対象とする。 3.監査対象部門情報システム部 (システム開発チーム,システム運用チーム) 4,監査対象期間(省略) 5.実施体制内部監査室システム監査チームリーダー以下2名 (a) 7.監査手続の概要・情報システム部長及び担当者へのインタビュー ・システム開発,システム運用及び情報セキュリティに係る規程,マニュ アル,記録などの閲覧 ・基幹システムの情報セキュリティに係る設定状況の目視による確認 8.総合評価基幹システムの信頼性及び安全性はおおむね良好である。ただし,システ ム開発及び情報セキュリティに関して各1件の発見事項があったので,次 項に報告する。 ーー6ーー 表1システム監査報告書案(抜粋)(続き) 9.発見事項 (1)監査対象期間におけるシステム変更|システム変更申請書について規程に 申請書を209件サンプリングしてナチ|従って情報システム部長が適時に承 ェックしたところ,情報システム部|BL,記録を残す。 長の承認記録がないものが3件あっ Tes (2)情報システム部のシステム開発チー|システム開発チームリーダーに更新 ムリーダーに本番環境の更新権限が|権限を付与せず,本番環境の作業は あり,常時本番環境のデータベース|全てシステム運用チームが行う。 にアクセスできてしまう。 表2監査調書(リスク1) る。 | 監査手続①情報システム部の体制図や職務分掌規程などの資料を閲覧し,情報システム 部の体制と役割が明確になかっていることを確かめる。 ーに質問し,体制図や職務分掌などと整合がとれていることを確かめる。 監査結果①情報システム部の体制図及び職務分掌規程を閲覧し,情報システム部の業務 と職務分堂が明確に規定されていることを確かめた。 ②情報システム部の関係者にインタビューを行い,上記①で把握した業務及び 職務分掌に基づいて業務が実施されていることを確かめた。 ・システム開発チームリーダーは開発,変更したプログラムのリリース後の 稼働状況確認のほか,本番環境におけるインシデント発生時の原因調査及 び緊急対応を行っている。システム開発チームは,クラウド環境への移行 に伴い,変更管理ツールを導入した。本ツールには変更したプログラムの 本番環境へのリリース時に本ツール上での申請,承認を必須とすることが できる機能があるが,その機能は使用していない。 ・システム運用チームリーダーは,本番環境の維持管理として,本番リソー スの使用状況や各種設定を管理している。システム運用チームは,基幹シ ステムの機能や仕様については熟知していない。 ・情報システム部長は,情報システム部の中で最も経験年数が長く,利用部 門の業務知識も豊富で,要件定義における利用部門のサポートも行ってい る。情報システム部長は,.システム開発チーム及びシステム運用チームの 作業内容が適切かどうかを適宜チェックしている。なお,情報システム部 長は来年退職予定である。 ーーaiーー 表3監査調書(リスク2) eee[Race 監査目標基幹システムの本番環境のプログラムに対する全ての変更が適切に承認され 監査手続①変更管理規程を閲覧し,基幹システムの本番環境のプログラムを変更する 際のルールを確かめる。 ②変更ログ及び関係書類の閲覧によって,基幹システムの本番環境のプログ ラムに対する全ての変更が規程及び手続に基づき承認されていることを確 かめる。 監査結果①変更管理規程を閲覧し,次のことが規定されていることを確かめた。 基幹システムの本番環境のプログラムを変更する前に,システム開発チー ムがシステム変更申請書を作成し,情報システム部長の承認を得る。 ②ず監査対象期間におけるシステム変更申請書から監査実施要領に従い20件を サンプリングしてチェックしたところ,情報システム部長の承認記録がな いものが3件あった。情報システム部長の説明では,変更内容は別途確認し ているが,忙しくて承認の押印が漏れてしまったとのことである。 指摘事項監査対象期間におけるシステム変更申請書の20件中3件について,情報シス テム部長の承認記録がなかった。情報システム部長の承認の押印が漏れてい ることから,運用上の不備とする。 表4監査調書(リスク3) eee 監査手続①情報セキュリティ管理規程を閲覧し,本番環境の更新権限を制限する規定及 ②本番環境の更新権限を有するアカウント一覧を出力し,正当なアカウントだ び更新権限付与ルールを確かめる。 監査結果①情報セキュリティ管理規程を閲覧し,本番環境のアカウント及びアカウント | ②本番環境のアカウント一覧を出力し,更新権限を有するのはシステム運用チ ーム2名,システム開発チームリーダーの3名であることを確かめた。 た。 指摘事項情報システム部のシステム開発チームリーダーに本番環境の更新権限があり, 常時本番環境のデータベースにアクセスできてしまう。システム開発チームが 本番環境の更新権限をもっていることは統制が不十分であることから,整備上 の不備とする。 [内部監査室長の指示] 内部監査室長は,監査調書及びシステム監査報告書案をレビューし,次のように ーー8ーー 内容を見直すよう,システム監査チームに指示した。 (1)表1の“8.総合評価”については,"1.監査目的"に照らすと,記載内容が不十 分であるので,必要な事項を追記すること。 (2)表1の“9.発見事項"(1)に関連して,次の2点を確認すること。 ①表2及び表3の"監査結果"を踏まえると,“改善提案"がこれで受当かどう か疑問である。情報システム部と協議の上,“改善提案"の内容を必要に応じて 修正すること。 ②表3の"監査手続"の下線部について,網羅性の観点から,“BRR”OO でシステム変更申請書からサンプリングするのに先立って実施した監査手続とそ の結果を監査調書に記載しておくこと。 (3)表1の“9.発見事項"(2)の“改善提案”の内容については,表2の“EAR” DS,情報システム部の業務に支障を来す可能性があると考えられる。"改善提案" の内容が実行可能かどうか,情報システム部と十分にコミュニケーションを取って 検討すること。 (4)表2の“監査結果"DS,情報システム部の来年度以降の体制について懸念す べき事項があるので,今後継続して確認していくこと。

共通の文章

ITサービス管理システムの監査に関する次の記述を読んで,設問に答えよ。 P社の情報システム子会社のQ社は,P社のグループ各社(以下,各社という)に ITサービスを提供している。提供するITサービスの種類と規模が拡大してきたので, より効率的かつ迅速に提供することを目的として,ITサービス管理システム(以下, 新システムという)を新規に導入する予定である。『P社の内部監査室はP社グループ 全体を監査する役割を担っているので,新システムの目的が実現できるように検討さ れていることを確かめるために,0社に対するシステム監査を実施することとした。 [現在のITサービスと申請方法の概要〕 現在,0社が提供しているITサービスと申請方法の概要は次のとおりである。 (1)ITサービスの内容と申請方法 ITサービスには,PC,サーバ,電子メールや事務処理のソフトウェアなどを利 用するための定型サービスと,業務で利用する情報システムの開発などのSIサー ビスの2種類がある。0社は,P社グループ内での情報共有のための掲示板システ ムに,ITサービスの仕様などを記載したサービスカタログと申請方法を掲載して WS.各社のIT部門は,次の(2)と(3)に述べる手順で利用部門からの申請を 取りまとめて申請一覧表を作成し,電子メールに添付して0社へ送付している。 (2)定型サービスの申請 Q社では定型サービスの種類ごとに定型サービスチームが設置され,仕様と利用 料単価がサービスカタログに記載されている。各サービスの仕様と利用料単価は原 則として半年ごとに改定されるが,例外的に半年の間に改定される場合もある。 サービス提供を希望する利用者は,上長の承認を得た上で各社のIT部門へ申請 する。人事異動などに伴い多くの申請が必要な場合には,職場ごとに担当者が取り まとめて申請一覧表を作成し,上長の承認を得た上でIT部門へ申請する。 (3)SIサービスの申請と見積り SIサービスは,0社のSIサービスチームが提供している。各社の利用者はSI+ ービスの依頼内容を検討し,上長の承認を得た上でIT部門へ申請する。 SIサービスチームの担当者は,各社のIT部門から届いた申請について,必要に 応じて個別にヒアリングした上で費用を利用料として見積もる。その結果は,リー ー19一 ダーが承認した上で,要員などの必要リソースが一定規模を超える場合はSIサー ビスチームの部長が承認した後,申請元のIT部門経由で利用部門へ通知する。見 積りに対する利用部門からの回答が届いた後,正式な申請として受け付ける。 (4)ITサービス利用料管理 ITサービス利用料は,毎月15日締切りで0Q社から各社の1IT部門へ請求する。決 算期の最終月には16日から月末までの金額を算出して会計処理を行う必要があり, Q社と各社の両方で手間が掛かっている。 〔新システムの概要]〕 内部監査室の監査チームは,予備調査として,0社内で検討中の新システムの導入 企画書案を入手して閲覧するとともに,導入検討プロジェクトのリーダーを務めてい る0社の技術管理部長にヒアリングした。その概要は次のとおりである。 (1)新システムの概要 各社の管理業務を削減するとともに,利用者のニーズに迅速に対応する狙いか ら,新システムでは利用者が自身でQ社へ申請する。新システムはクラウドサービ スを利用して構築する予定で,その概要は図1のとおりである。 (2)定型サービスの申請 利用者はサービスカタログの内容を確認した上でサービス申請の画面に入力し 利用者の上長が申請を承認した後,関係する定型サービスチームへ通知される。 0社ITサービス管理システムP社グループ各社 トニーでサト1トーニーですす| ||ITサービス申請管理|| |定型利用者マニュアル|| |サービス|| |=I|| |as ef een Ne| !あーテー閲覧|| I|syーュ区つる=“ed| ||マスター利用料管理| 1 WW 注記P社グループ各社のIT部門は,ITサービス申請管理の各データを閲覧できる。 図1 ITサービス管理システムの概要 定型サービスチームの担当者が受付した後に定型サービスチームのリーダーが承 認する。多くの申請を効率的に処理するために,定型サービスチームのリーダーが 申請を一覧画面で承認できる機能を提供する予定となっている。 主要な定型サービスにおける申請の受付から提供までのリードタイムは,現在よ りも短縮する予定であり,導入企画書案にリードタイムの目標が記載されている。 (3)SIサービスの申請と見積り 新システムでは,SIサービスの申請に対して,SIサービスチームの担当者が画 面から見積りを入力し,リーダーが承認する。 (4)ITサービス利用料管理 新システムには,サービスコードをキーとして定型サービスの仕様や利用料単価 などを管理する定型サービスマスターがあり,半年ごとに技術管理部が取りまとめ て更新する。例外的に半年の間に改定があった場合は,各サービスを担当している 定型サービスチームが更新する。 毎月末には,サービス申請のデータに基づき,サービスコードが一致する定型サ ービスマスターの利用料単価を使用して各社へのサービス請求明細が作成される。 サービスコードが一致しなかったサービス申請はエラーとなりリストが出力される。 決算期の最終月の会計処理を効率よく行うために,経理部とITサービス利用料 の締切日の変更を協議している。新システム導入の機会に,毎月末時点で当月分を 各社へ請求して,当月中のITサービス提供の開始や終了による差額は翌月に精算 する方法に変更することを検討している。新システム導入と同時に締切日を変更す るので,開発とテストの作業量が多く,かなり厳しい日程となっている。 〔本調査のための検討] 予備調査の結果を基に,監査チームのリーダーであるT氏は,内部監査室長と本調 査のための検討を行った。その内容の抜粋は次のとおりである。 室長:現在は定型サービスで多数の申請がある場合,利用者の上長は一覧表で承認で きますが,新システムは申請ごとの承認なので上長は手間が掛かりそうですね。 T氏:定型サービスチームのリーダーに提供予定の機能を活用すれば対応が可能ではな いかと思われるので,技術管理部にヒアリングして|sa|を確認します。 室長:SIサービスの見積りについて必要な承認が行われるためのコントロールが, ー12— 新システムで実装されることはどのように確認しますか。 T氏:新システムに,| b|機能だあるかどうかを確認します。 室長:定型サービスの仕様や利用料単価が半年の間に改定される場合は,定型サービ スマスターが適切に更新されない可能性がありますね。 T氏:各定型サービスチームの担当者のために,を定めるといったコン トロールが必要と思われます。 室長:サービスコードが一致しなかった場合のエラーが適切に処理されなければ, [|9|というリスクがありますね。 T氏:エラーに対処する部署や処理方法が明確になかっているかどうかを確認します。 室長:今回の新システムは,多くの利用者に直接影響ほ与えることから,移行時のリ スクは極力回避すずる必要がありますね。 TR:監査手続としては| e|]によって,新システム導入後に運用が定着して から締切日を変更することを検討したかどうかを確認します。 室長:主要な定型サービスのリードタイムは,現在よりも短縮する目標を掲げていま すが,定型サービスの利用者にも明確にしておく必要がありますね。 T氏:定型サービスを申請する際に閲覧できれば,利用者にも目標が明確になると考 えられるので,| f|を確認することにします。