Home > Tags > システム監査技術者

システム監査技術者

システム監査技術者(14年度)~合否発表(その7)

今回は成績照会に必要な情報をEvernoteに登録したので、職場のお昼休みに結果を確認できます。ドキドキしながら合格番号一覧を探すと、無事自分の番号を発見できました。昨年のサビマネに続いての合格で、久しぶりに良い風が吹いてきたようです。

午前1 免除
午前2 84.00点
午後1 77点
午後2 A

午後1の得点は、予想通り自己採点より落ちていますね。それでも80点弱は、ここ最近の午後1としては、なかなかの出来です。午後2は自己採点通りA評価となって、良かったです。特に不安な点がない状態で不合格になると、原因分析に困るので、今回の合格には安心しました。

以前のエントリにも書きましたが、論文でサビマネの知識を活かせたのは大きいと思います。他の試験区分では常識であることを、さも立派に語ることができるので、非常に話が書きやすかったです。やはりシステム監査技術者は、他の高度区分をいくつか合格してから受けたほうが、やりやすいですね。

ちなみに、今回の勉強時間は約20時間です。論文系の試験は覚えることが少ないので、勉強時間のコストパフォーマンスが良いですね。駄目だった場合は、問題運がなかったと諦めるので、必要以上に勉強漬けとしません。

しかし、午後1の問題は、色々とやりづらいですね。Twitterでも多少呟いていましたが、各問題の出題者によって解答の粒度や傾向が違うので、どこに合わせればいいのか悩みます。

そんな不満もありましたが、何にせよ、システム監査技術者試験に合格したことにより、春の情報処理技術者試験は、全区分合格したことになります。来年からは、少しのんびりした春を過ごせそうです。数年後には、更新制が噂されるセキュスペを受けているかもしれませんが。

システム監査技術者(14年度)~自己採点(その6)

先日受けたシステム監査技術者試験について、自己採点を行いました。

午前2

自己採点結果:84点(午前2自己採点簿

IPAから発表された公式解答を用いて採点しました。無事突破できたようです。

午後1

自己採点結果:88点(午後1自己採点簿

TACおよびiTECから出ている解答速報を用いて、自己採点しました。基本的にOR条件で正解判定しています。iTECの重点対策をテキストに使ったためか、自分はiTECの解答にしっくり来ることが多かったですね。

調整によって採点が厳しくなり、実際の点数はもう少し下がるかなあ、と思っています。以前他区分で、自己採点結果がかなり良くても、結果が意外と厳しいことがあったので。

午後2

例によって、骨子のみ載せておきます。今回も鉄板ネタである、旅行商品販売システムを題材に用いました。再現時に改めて気づきましたが、設問イは骨子段階では十分に作成しておらず、サビマネの知識により即興で肉付けした部分が多いので、少し精度に不安が残りますね。大きく題意を外した箇所はないと思うので、自己採点結果は、一応Aとします。

設問ア

情報システムの概要

  • 旅行商品販売システム
  • 自分は、運用課のリーダーとして被監査側担当の立場である
  • システムの利用者は、営業部員と一般消費者
  • システムは、WEBサーバ2台、アプリサーバ2台、DBサーバ1台で構成している
  • 経営会議で、99.9%以上の稼働率を要求されている

障害発生時の影響

  • サービス停止による、売上機会の消失
  • 顧客離れ。旅行商品の特性上、航空券や休みなど、購入タイミングがシビアであるため
  • 近年、カウンター業務よりWEB経由の売上高が大きく伸長しているので、経営に与える影響も大きい

設問イ

可用性確保のためのコントロール

  • WEBサーバとアプリサーバをデュアル構成で冗長化している
  • メモリなどサーバの構成部品の二重化ではなく、様々な部品や論理不具合にも対応できるよう、サーバごと二重化した
  • 故障時に1台運用となっても、負荷には耐えられる
  • DBサーバはデータの同期が難しいため、待機系はコールドスタンバイさせている

障害対応のためのコントロール

  • モニタリングソフトで、CPUやメモリの使用状況を監視し、異常を早期に検知する
  • 即座に現状復帰を目指すインシデント対応プロセスと、根本解決を目指す問題管理プロセスを、分離する
  • インシデント対応では、まずデータの参照だけでも出来れば、業務に与える影響を軽減できる
  • 影響を受ける営業部員や一般消費者に、適切なタイミングで状況の連絡や報告をする

設問ウ

可用性確保の監査

  • 経営とのSLAである99.9%を上回っているか、各サーバの障害発生状況を、インシデント受付記録から確認する
  • 可用性確保のために、過剰なコストをかけていないか、比較検討会議の議事録や報告書をレビューする
  • 可用性確保のための冗長化が、計画通りに実施されているか、実施報告書を確認する

障害対応の監査

  • 障害対応規程が存在するか。検知の方法、対応プロセス、連絡体制が明記されているか、チェックリストに従い確認する
  • 障害対応規程は、複数の部署で遵守すべき規程なので、経営レベルの承認がされているか、確認する
  • 改訂日付が新しくなっているか、確認する
  • 障害対応規程が正しく運用されているか、インシデント受付記録や障害対応報告書から確認する

システム監査技術者(14年度)~試験当日(その5)

2014年4月20日、システム監査技術者試験を受験してきました。朝、コンビニでカツ重を弁当に買い、ゲン担ぎ。会場は前回と同じ川崎科学技術高校です。この会場の区分は、基本情報と応用情報と監査でした。

【午前1】

免除です。

【午前2】

全体的に解きやすい印象でした。突破出来てると思います。

【午後1】

問1と問3を選択しました。ぱっと見た感じ、問3は解答欄の文字数が多くて避けようと思いましたが、BYODがテーマということで、セキュリティ系かな、と考え、選ぶことにしました。サビマネのときもそうでしたが、セキュリティ系の問題は、わりと解きやすい気がしています。

毎回午後1は慎重に解きすぎて、2問目に当てる時間が不足しがちですが、今回はわりと時間に余裕を持てました。確信が持てない設問を、早めに決断して埋めてしまえたのが良かったのだと思います。ちなみに、1問目が終わったのが、40分くらいでした。解答を問題用紙に書く時間って、純粋に書く時間や字数調整など、意外と馬鹿に出来ないです。

問題文から引けないタイプの設問があって、モヤモヤした部分もありますが、一通り埋めることが出来ました。問1より問3のほうが、解きやすかったです。

【午後2】

問1がパブリッククラウドで、問2が障害管理がテーマでした。クラウドサービスは職場でも使用したり、多少馴染みはありますが、論じられるレベルではないので、素直に問2を選びました。昨年秋に受けたサビマネの知識を活用出来たので、結構書きやすかったです。システム監査の論文の型に従い、サビマネの知識で肉付けしながら、書き上げました。おかげで、だいぶ時間に余裕がありましたね。字数は、設問アが750字、設問イが850字、設問ウが900字くらいでした。行数換算なので、実際の字数はこれより幾らか少ないです。

以上で試験終了です。長丁場で、やはり疲れますね。それだけに、午前1免除はありがたいです。試験後は街をブラブラして、気晴らししました。

結果が分かるのは、2か月後です。とりあえず答案用紙の内容には、満足しています。あとは、果報は寝て待て、ですね。

システム監査技術者(14年度)~その4

今回の勉強量のまとめです。結局目標としていた勉強量には、少し足りませんでした。

  • テキスト読み(午前2演習含む):473分
  • 午後1演習:426分
  • 午後2演習:305分
  • 午後2向け情報整理:120分

合計は、1324分(約22時間)でした。

テキスト読みは、通勤電車が本を読める程度に空いているので、その時間を使って読みました。昨年は内容を掴むのに精一杯でしたが、2年目となると多少見え方が違ってきます。何か1年目で培った知識のフレームがあって、それに沿って知識を補充していく感じで、だいぶ読みやすいです。

午後2演習ですが、昨年ほとんど手を着けられなかった反省から、午後1演習に先立って着手しました。論文骨子作成演習は、H25問1、2と、H24問1、2で、論文作成フル演習は、H24問3と、H23問2です。予定より少なかったですが、思いのほか進みが遅くて、午後1演習の時間が取れなくなることを危惧した結果、早めに切り上げました。それでも、論文フル演習を2本こなせたのは、良かったです。

午後1演習は、わりと直前から駆け足でこなしました。結局、目標としていた3年分には、2問届かずでした。前日の夜を、午後1の残り2問に当てるか、午後2の論文フル演習に当てるか、迷いましたが、計画段階の方針に従い、午後2の演習を優先しました。

午後2向けの情報整理は、ブログの前回エントリで書いた内容です。これまでに理解した内容について、頭のなかを整理するための作業でした。

システム監査技術者(14年度)~その3

試験日まで残りい少なくなってきました。最近は、午後1問題の演習を進めています。何とか3年分は終えたいですね。

さて、ここまで勉強してきて、何となく理解した監査のイメージをまとめます。午後1や午後2の問題を考える上で、フレームワークとして使いたいです。内容の信頼性は微妙なので、当てにしないで下さい(笑

監査対象(概要)

監査対象には、元々経営上の目的があるはずです。まずは、それを明らかにしておきます。

続いて、具体的な監査対象の中身です。開発や運用などの業務、特定システムなど、ありとあらゆる業務やシステムが、監査対象となります。このへんは、他区分の内容を知っていると、やりやすいですね。

監査対象(リスク)

もし○○だったら、というように、監査対象へ損害を与える可能性を、リスクとして挙げていきます。多少慣れが必要かもしれませんが、少し考えるだけで、わりと多くのリスクを抽出できると思います。

  • もし不正な入力があったら
  • もしサーバ障害でサービスが停止したら
  • もしインフルエンザで要員が大量欠勤したら

通常、これらのリスクに対して、回避や軽減をするためのコントロールを組み込むことになります。

  • 職掌分離による承認制度
  • 障害発生時の復旧手順規定
  • 要員のバックアップ体制

リスクとコントロールは、情報関連に関わらず、日常のあらゆるところに存在します。交通量の多い交差点に信号があるのも、交通事故というリスクに、信号機というコントロールを設けているといった具合です。

監査目的と監査要点

監査するにあたり、監査目的を明確にしておきます。基本的には、監査対象の目的を正しく達成するために、チェックしておきたい内容になります。着目点は、下記でしょうか。

  • 経営目標を実現できるか
  • 資源を効率的に活用しているか
  • 情報の信頼性が保証されるか
  • 法令順守しているか(法定監査に関わる場合)

監査目的が明確になったら、その目的のためにチェックしておくべき点を、監査要点として何点か決めます。監査要点となる候補は幾つもありますが、コントロールがきちんと機能しているか、を見ることになります。

監査手続

監査要点について、監査対象が満たしているかを確認する手順が、監査手続となります。色々とありますが、大きく分けて、準拠性テストと実証性テストがあります。

準拠性テストは、コントロールがルールとして整備されていることを、確認します。具体的な手続きは、運用規程の存在や改訂日などのチェックになります。

実証性テストは、ルールがきちんと運用されているか、確認します。具体的な手続きは、運用記録のチェックになります。

こうした手続きを通して出てきた一連の情報が、監査証拠となります。

具体的な手続きは、様々な方法がありますが、代表的な監査技法として、下記があります。下へ行くほど、高コストですかね。なるべく省コストで確認できるほうが、良いです。外部の立場である監査人が、確認できる量や深さには限界があるので、効果的に実現可能なコストとなるよう、気をつけます。

  • チェックリスト
  • 規程や運用記録、会議録などのレビュー
  • 関連する複数資料の突合せ
  • インタビュー
  • 現地調査

具体的にどれをどのようにチェックするかは、チェック対象の入手方法まで含めて、予備調査の段階で決定しておき、本調査では手続きに則り、粛々と監査証拠を収集します。

    監査の評価/結論、報告、フォローアップ

    事実である監査証拠を元に、監査人が監査要点に対して、評価をします。それらの評価から、指摘事項や改善勧告、総合評価の記述を行い、監査人の意見としてまとめます。改善勧告に対するフォローアップも実施します。

    Home > Tags > システム監査技術者

    メタ情報
    素材拝借元
    参加ランキング
    にほんブログ村 旅行ブログへ
    にほんブログ村 資格ブログへ

    Return to page top