システム監査技術者試験の勘所
この春にシステム監査技術者試験を受験します。
私の担当している業務からすると、
まったく関連がないということはありません。
それどころか、システム開発に携わるものでシステム監査が
関係ない、ということはそうそうないと思われます。あくまで受ける側として、ですが。
システム監査というと、監査人がやってきて箸の上げ下げまで文句を言う、
というイメージを抱かれる方もおられると思います。
しかしよくよく勉強してみると、すこし違うことがわかってくるんですよ。
システム監査というのは、ひと言で言うとルールの遵守状況の確認です。
何も、机の上が汚いとか、ネクタイが緩んでいるとか、
そういう注意をするものではありません。
ましてや、フロアレイアウトが悪いから動線が長いじゃないか、とか、
おまえたちは日本語をもっと勉強すべきだとか、
そういうレベルの指摘というのは原則ありません。
ではどのような指摘が「システム監査」なのでしょうか。
日本の警察は規則で動きます。人相が悪いからといって無罪の人を突然逮捕しないように、
システム監査にも守るべき規則というのがあります。
監査人の胸先三寸で「お前その目つきは何だ。監査結果悪くしてやる。」とはなりません。
企業にはルールがあります。最近ですと日本版SOX法（J-SOX法）関連の
話題が盛り上がっていますね。あの法律は、会計のルールを厳しく定めたものです。
経理処理と異なり、システム自体にはさほど厳しいルールがありません。
建築物でも大きなものは耐震強度などが公式なルールで定められています。
一方、システムはこのように構築すべし、という共通ルールはないのです。
（ISOやらRFCなどは一旦忘れてください）
ので、代わりとなるルールを各社が責任を持ってしっかり作成します。
情報セキュリティガイドラインであったり、ユーザ登録手続き規定集であったりします。
システム監査人が調査するのは
そのようなルールが徹底されているかどうか
のひと言に尽きます。
まずシステム監査では、企業がシステム監査で何を目的とするかを
決定します。その目的を監査目的といいます。
普通ならば企業が抱えるリスクの大きさを考慮した目標がいくつかできます。
では、その目的を達成するためにはどうしたらよいのか。
それを実現するために計画書を作成します。
費用対効果を考えて効率的に監査が進むように計画します。
その段階で、会社が定めたルールを把握します。
ここが大変重要です。そのルールの遵守状況を確認することが監査だからです。
社長「個人情報漏洩なんていうのがあるとまずいからさ、しっかり監査してね」
監査人「いや、セキュリティポリシーすら無いんじゃ『何が悪い行為か』が定義できません。」
なんていう運びは監査ではありません。そんな場合は、
その辺りに明るいエンジニアやコンサルタントを早期に導入すべきでしょう。
（システム監査人がセキュリティ標準などの策定に参画する意味も大きいと思います。
また、上の例でも現実世界では経験豊富で優秀なシステム監査人が過去の経験から
有効な監査手続を洗い出して実力を発揮してくれることもあると思われます）
少し横道にそれましたが、その会社で、システムに関するルールが徹底されているか、
という辺りを監査するのがシステム監査です。
公正な判断のために、システム監査人は色々な利害関係から独立していなくてはいけません。
自分の元上司のところの監査をしたら、無言の圧力で「問題なし」と報告してしまった、
ではまずいのです。自分の会社のサーバをたくさん買ってくれるユーザ企業の監査を
自社でやった場合、甘くならないでしょうか。「このサーバ良くないですね」と言えるでしょうか。
そのような場合は別の監査人を立てるべき、ということになっています。
続きです。社内規約が記載されたドキュメントから、監査したいポイントを探しても
机上の空論になってしまいがちです。そういう場合、現場に入って準備をします。
予備監査と言います。そこで急所を洗い出すなどして、監査手続を完成させます。
監査手続には、チェック項目がずらーっと記載されます。
それに基づいて状況を確認します。もし良くない部分を見つけたら、
その場で証拠を取ります。被監査部署が監査人の目の前でログを削除することはないにしろ、
後日証拠を取得するために監査人が出向いたら跡形も無く・・・となるとまずいです。
oracleデータベースなどには「監査証跡ログ」というものがありますが
（デフォルトOFFだったような気が・・・）
それらは簡単には削除できない仕組みになっています。
ので、監査人はそういうような機能を活用し、
「ちゃんと社員それぞれが自分のアカウント使ってるね」
「SYS権限の利用状況を調べたけど、不要な場合には一切使われていないね」
などを確認します。まずいところがあったら証拠を押さえます。
証拠を持たない監査結果は監査報告書と言えません。
「なんか色々とまずいみたいです。」
じゃまずいわけです。上の例に絡めると
「普通のテーブルを参照するだけなのにSYSでログインした割合が20%」
「社員の6割が1つの特権アカウントを使いまわしている」
という指摘とともに、LOGという証拠を突きつけてこその監査となります。
社長が正式に監査人に監査を依頼したのであれば、
監査人の言うことは社長の言うことですので
「業務秘密につきLOGは出せない」
とは言わせません。（お客様の個人情報保護まで絡むとケースバイケースですが
個人を特定する部分をスクランブルしても証拠性を確保できるLOGもあると思います。
そもそも監査報告書は極めて丁寧な扱いを受けるはずです。その会社の弱点が山盛りですから。）
このようにまとめた監査報告書は経営者向けと、現場向けに作成されます。
現場には「あんたらこのへんまずいんちゃうか」という感じになりますし、
経営者向けにはそれらを包括したレベルの報告書が行きます。
アウトソーシング依頼主が、システム監査人を雇ってアウトソーシング依頼先を
監査するように命じるケースもあります。その場合も双方に報告書が行くのが普通でしょう。
監査報告書には「このへん、ちゃんと改善してよね」という意見が出されます。
「来週までにやれ」的な勢いもあれば、「費用対効果を考えてじっくり結論を出してね」
というテンションのものまでがあります。監査証拠から導き出せることを書きます。
「社員が挨拶もまともにできないし、この調子じゃ近いうちつぶれますな」
などという個人的な恨み言は記載されません。
監査の目的がリスク管理であるならば、特にハイリスクであり、至急対策を要するような
大穴が発見されてしまった場合などは必ず「フォローアップ監査」が行われます。
別に大穴じゃなくてもやったほうがいいのですが、そう毎月毎週監査ばっかりやっていられませんので
重要度に応じてフォローアップを1ヵ月後にやったり、来年の監査で重点項目にすればいいやで済ませたり、
と言うような具合に監査は終わります。終わりが続きでもあるのです。
美しいPlan-Do-Seeになります。
実際には、システム構築前に試算したパフォーマンスが予想値どおり発揮されているか、
というような監査などのバリエーションもあり、とても1エントリで語りきれるものではありません。
私は「やる側の」システム監査なんてこれっぽっちも経験が無いです。
以上は教科書から理解できた事を綴ってみました。長くなってすみません。
今週末の試験はこれで戦います。
間違いは発見次第修正していくつもりですが、上記理由により
このエントリにも間違いがいくつもある事かと思います。その点はお含み置きください。