「ルールを守っているか」では、セキュリティは守れない ── 準拠性監査から有効性監査へ【CySec復習ログ#4】

Last updated at 2026-07-26Posted at 2026-06-28

はじめに

監査と聞いて、少し前の私が思い浮かべていたのは「チェックリストを片手に、書類に不備がないかをハンコで確認していく作業」でした。だから、脆弱性診断やペネトレーションテストが「監査」の一種だと言われたとき、まったくピンときませんでした。攻撃を仕掛けてみることのどこが「監査」なのか、と。

学び直してみると、この違和感の正体がはっきりしました。私が思い浮かべていたのは 準拠性監査(ルール通りにやっているかを確かめる監査)で、脆弱性診断やペネトレーションテストは 有効性監査(本当にリスクが下がっているかを確かめる監査)だったのです。同じ「監査」でも、確かめているものがまるで違いました。

この記事は、CySec(東京電機大学が提供する社会人向けのサイバーセキュリティ教育プログラム「国際化サイバーセキュリティ学特別コース」)で学んだ内容を、自分の言葉で整理した復習ログです。本シリーズの通し番号では #4 にあたります。想定読者は、少し前の私と同じく「監査をチェックリスト作業だと思っていて、なぜ脆弱性診断やペネトレーションテストが"監査"なのかピンとこない学習者」です。

この記事の軸になる主張を、先に引用ブロックで掲げておきます。

「ルールを守っているか(準拠性)」を確かめる監査では、セキュリティは守れない。「本当にリスクが下がったか(有効性)」を確かめる監査へ。そのために監査人は評価範囲を絞り込み、最後は「事実」を積んで「意見」を述べる。

読み終えたとき、「自分の現場でやっている検証作業は、質問・観察・検証・再実施のどれにあたるんだろう」と棚卸ししたくなれば成功です。なお私自身まだ学習中なので、間違いがあれば指摘していただけると助かります。

前回(第2回=#3)は、内部統制を「リスク(脆弱性)に打つ実装戦略」として、統制を 実装する側 から捉え直しました。その末尾で、統制の有効性評価は「整備状況評価(設計)」と「運用状況評価(実運用)」の2段階で、これが SOC 2 の Type1 / Type2 に対応すると書きました。今回(#4)は、その統制が本当に効いているかを 検証する側=監査 に視点を移します。前回の続きとして、有効性をどう確かめるのかを掘り下げる回です。

監査とは ── 第三者が「意見」を述べ、その意見に責任を負う

まず、監査そのものの定義からほどきます。講義での定義は、おおむね次のとおりでした。

監査とは、特定の基準に対して証拠を入手・評価し、その結果に基づいて意見を述べる活動である。監査人は第三者的な立場で独立性を保つ。

ここには3つの要素が詰まっています。第三者であること、証拠に基づくこと、そして最後に意見を述べることです。とりわけ重い意味を持つのが、最後の「意見を述べる」です。

監査の核心は、監査人が自分の責任で意見を表明する点にあります。「適正だ」「有効だ」と述べた以上、その意見には責任が伴います。チェックリストにチェックを入れる作業との決定的な違いがここにあります。チェックは事実の記録ですが、監査は意見の表明です。

この「意見に責任を負う」重さは、歴史的にも変わってきました。講義では、かつて監査人の責任が 無限責任(損害をどこまでも負う)だったのが、現在は 有限責任 に整理されてきたという話が出ました。責任が重すぎると、引き受け手がいなくなるからです。今でもセキュリティ分野には、責任を負う重い監査と、助言にとどまる軽い検証の両方があります(後述します)。

コラム: 監査の歴史は意外と新しい

監査が資本主義と株式会社の歴史に寄り添ってきたことを、短い年表で眺めておきます。

年	出来事	意味
1602年	オランダ東インド会社(VOC)設立	世界初の株式会社。出資者(株主)と経営者が分かれ、第三者が経営をチェックする発想が生まれた
1844年	英・会社登記法(Joint Stock Companies Act)	会社設立時に監査を制度として導入。以後、会計監査などへ広がる
1929年	米・株式市場の大暴落(世界恐慌の引き金)	ずさんな情報開示への不信が頂点に。投資家保護の必要性が高まる
1933年	米・証券法(Securities Act of 1933)	証券の発行時に正確な情報開示を義務づける連邦法
1934年	米・証券取引所法(Securities Exchange Act of 1934)	SEC(証券取引委員会)を設立。上場企業に継続的な開示・監査を求める枠組みが整う

日本では、これらの流れを引き継ぐ形で 会社法 が監査を義務づけています。出資者と経営者が分かれ、外から「本当に大丈夫か」を確かめる必要が生じたときに、監査は信頼を外から補強する仕組みとして生まれた、と理解しておけば十分です。

法律が求める監査 ── 会社法と地方自治体

監査を法律が求める例を、2つだけ押さえます。記事の本筋ではないので軽くです。

会社法では、大会社(会社法2条6号。資本金5億円以上、または負債総額200億円以上の株式会社)に対して、会計監査人による監査を義務づけています。そして会計監査人になれるのは、公認会計士または監査法人だけです(会社法337条1項)。一方、監査役は取締役の職務執行を監査する役割で、会計監査人とは別の存在です。

地方公共団体にも外部監査の制度があります。包括外部監査人になれるのは、地方自治法252条の28に定められた 弁護士・公認会計士、および「国の行政機関で会計検査に、もしくは地方公共団体で監査・財務に関する行政事務に従事し、監査の実務に精通している者(政令で定めるもの)」です。税理士は、地方公共団体が必要と認めるときに、これらに加えて契約できる枠として規定されています(同条2項)。私が受けた講義のメモには「公務精通者」とありましたが、条文を確認すると、そうした語はなく、正確には上記の「監査の実務に精通している者」でした。学習メモの言葉は、一次情報で裏を取ると表現が変わることがある、という一例です。

準拠性では、セキュリティは守れない ── ISMS から有効性監査へ

ここが、この記事の背骨です。監査は、確かめるものによって大きく2つに分かれます。

監査の種類	確かめること	問い
準拠性監査(コンプライアンス監査)	ルール通りに実行され、記録が残っているか	「決められた手順を守っていますか?」
有効性監査	リスクが実際に下がっているか	「その対策で、本当にリスクは下がりましたか?」

従来の監査は、準拠性監査が中心でした。基準やルールに照らして、その通りにやっているか、証拠(記録)が残っているかを確かめます。ISMS(情報セキュリティマネジメントシステム)の認証監査も、基本はこの準拠性の確認です。「ポリシーを定め、その通りに運用し、記録を残しているか」を見ます。

ところが、セキュリティでは準拠性だけでは守れません。理由は単純です。攻撃者はルール遵守では止まらないからです。社内ルールを完璧に守っていても、設定の穴を1つ突かれれば侵入されます。「ルールは守っていました」は、攻撃者の前では何の盾にもなりません。

だから、リスクが実際に下がっているかを直接確かめる 有効性監査 が必要になります。その代表が 脆弱性診断(設定やシステムに弱点がないか調べる)と ペネトレーションテスト(実際に侵入を試みる)です。攻撃側の視点で「本当に突破できないか」を確かめるからこそ、これらは有効性の検証なのです。私が最初に抱いた「なぜ攻撃を試すことが監査なのか」という違和感は、有効性監査という枠を知って初めて解けました。

近年は、この有効性検証をさらに進めた TLPT(Threat-Led Penetration Testing、脅威ベースのペネトレーションテスト) が注目されています。これは、実際の攻撃者が使う脅威インテリジェンスをもとに攻撃シナリオを組み立て、組織のセキュリティ対策が総合的に効いているかを評価する手法です。出発点は2018年10月、G7 のサイバー・エキスパート・グループ(CEG)が公表した「脅威ベースのペネトレーションテストに関するG7の基礎的要素」だとされています。欧州では欧州中央銀行(ECB)の TIBER-EU というフレームワークがあり、EU の DORA(デジタル・オペレーショナル・レジリエンス法)では金融機関への TLPT 実施が義務化されました。日本でも金融庁が金融機関向けに TLPT の活用を促しています。

講義のメモには「TRPT」という綴りがありましたが、一次情報を確認すると TLPT(Threat-Led Penetration Testing) が正しい表記でした。

保証型監査と助言型監査 ── 脆弱性診断は「保証しない」

有効性の検証にも、責任の重さで2タイプあります。ここを区別しておかないと、脆弱性診断を「お墨付き」と勘違いしてしまいます。

タイプ	目的	監査人の責任	性格	例
保証型監査	外部に見せてよい「保証」を与える	重い(意見に責任を負う)	外部目的。引き受け手は限られる	第三者による保証業務
助言型監査	弱点や問題点を指摘して改善を助ける	軽い(助言にとどまる)	内部目的。実務で広く行われる	脆弱性診断

ここで大事なのは、脆弱性診断は助言型であり、「安全であること」を保証するものではないという点です。診断は「見つかった範囲の弱点を教える」ものであって、「もう安全です」という保証書ではありません。診断で指摘ゼロだったとしても、それは「保証された」ことを意味しません。アドバイスを受け取って、自分たちで直していく。この前提を取り違えると、診断結果を過信する事故につながります。

情報セキュリティ監査とシステム監査

セキュリティに関わる監査には、隣接する制度がいくつかあります。表で整理します。

監査	主に見るもの
情報セキュリティ監査	情報資産のセキュリティマネジメント全体(ISMS の検証など)
システム監査	情報システムの信頼性・安全性・効率性

システム監査の「効率性」は、見落としやすい観点です。無駄なリソースや電力を使っていないか、といった効率の良し悪しも監査の対象になります。セキュリティは「安全性」だけを見ればよいと思いがちですが、システム監査はもっと広い視野を持っています。

日本では2003年、経済産業省が 情報セキュリティ監査制度 を設けました。この制度は「情報セキュリティ監査基準」(監査人の行為規範)と「情報セキュリティ管理基準」(判断の尺度)から成ります。なお、システム監査については別に「システム監査基準」があります。

監査の実施主体でも、いくつかの言葉が出てきます。軽く整理しておきます。

主体	立場	補足
外部監査	組織の外の独立した監査人	客観性が高い
内部監査	組織内部の監査部門	経営者が監査したい場所を監査する
監査役	取締役の職務執行を監査する役員	会社法上の機関

外部監査・監査役・内部監査が連携することを 三様監査 と呼びます。ただし、これは主に財務・ガバナンスの文脈で使われる言葉で、サイバーセキュリティの現場でそのまま登場することは多くありません。頭の片隅に置く程度で十分です。

有効性監査は重い ── リスクアプローチで「見るべき場所」を絞る

有効性監査が大切なのはわかりました。では、なぜ準拠性監査がいまだに根強いのでしょうか。答えは単純で、有効性監査は重いからです。「すべてのリスクが本当に下がっているか」を網羅的に確かめるのは、現実には不可能なほどの作業量になります。

そこで出てきたのが リスクアプローチ監査 です。これは「リスクの高いところに資源を集中し、評価する範囲を段階的に絞り込んでいく」考え方です。すべてを等しく見るのをやめ、危ない場所を見極めて、そこを重点的に見ます。範囲を絞ることで、重い有効性監査を現実的な作業量に落とし込みます。

絞り込みの流れを Mermaid で描きます。図の上から下へ、評価のたびに「見るべき範囲」が狭まっていきます。

各ステップを言葉にすると、こうなります。まず 固有リスクの評価 で、対策が何もなかったときの「生のリスク」を洗い出します。次に 内部統制の評価 で、ファイアウォール・IDS・EDR といった既存の対策がどれだけ効いているかを把握します。その差し引きで残るのが 統制リスク(残存リスク) です。そして残った高リスクの領域に対してだけ、実証手続(実際に確かめる手続き)を打ちます。実証手続は、ポリシーや設計の整合を見る 分析的手続 と、脆弱性診断・ペネトレーションテストのような 詳細テスト に分かれます。

ここで濃淡が生まれます。信頼して 依拠できる対策 には、軽い確認で済ませます。たとえば、事業者が日々リスク評価を回している基盤システムは、比較的依拠しやすい部類です。一方、依拠しにくい対策(個別の部門システムなど)には、脆弱性診断のような重いテストをしっかり当てます。すべてに同じ深さで向き合うのではなく、リスクと信頼度に応じてメリハリをつけます。これがリスクアプローチの実装です。

なお、講義では監査手続を 帰納的アプローチ(実証手続。個別の事実を多く集めて結論へ)と 演繹的アプローチ(内部統制の予備評価。全体のリスク分析から重点を定める)に分ける整理も出ました。従来の準拠性監査は情報を網羅的に集める帰納寄り、リスクアプローチは先に全体像を分析する演繹寄り、というニュアンスです。ここは「絞り込みの2つの考え方」として軽く押さえておけば十分です。

監査人の頭の中 ──「事実」と「意見」を絶対に混ぜない

リスクの高い場所を絞り込んだら、いよいよ検証です。ここで監査人が徹底するのが、「事実」と「意見」を絶対に混ぜないという規律です。これは、私が今回いちばん「プロの思考だ」と感じた部分でした。

具体例で考えます。特権IDの利用申請書に、管理者の 承認印 が押されているとします。

「印が押されている」── これは事実です。 監査人が目で見て確認できる、客観的な事象です。
「だから管理者が承認した」── これは事実でしょうか? 印があることと、管理者本人が承認の意思を持って押したことは、別の話です。部下が勝手に押したかもしれません。

ここを混同すると、「印がある → 承認されている → 不正な特権利用は起きていない → 有効」と短絡してしまいます。承認印という事実から、いきなり「有効」という意見へ飛んでしまうのです。

監査人は、この2つを言葉のレベルで使い分けます。

事実 = 監査手続の結果、判明した事象(「印が押されていた」「ログに記録があった」)。
意見 = 監査人の結論(「この統制は有効である」「有効でない」)。

不備の評価(=「有効でない」という意見)も、事実から論理で導きます。結果(事実) と 原因(事実) の因果関係を押さえたうえで、初めて「だからこの統制は不備だ」という意見を述べます。事実を飛ばして意見に飛ぶと、それは監査ではなく当てずっぽうになります。

監査リスク ── 監査人が「間違った意見」を述べてしまう可能性

事実と意見を慎重に扱っても、監査人が誤った意見を形成してしまう可能性は残ります。これを 監査リスク と呼びます。監査リスクは3つに分解されます。

監査リスク	意味	見落とすもの
固有リスク	統制がない場合に、もともと存在するリスク	「生のリスク」の大きさを見誤る
統制リスク	統制があっても検出・防止できないリスク	統制の効き具合を過大評価する
発見リスク(検出リスク)	監査手続そのものが不適切で、問題を見つけられないリスク	監査のやり方が甘い

そして、監査リスクはこの3つの掛け算で表されます。

監査リスク = 固有リスク × 統制リスク × 発見リスク

掛け算なので、どれか1つでも大きいと、全体の監査リスクが跳ね上がります。逆に、固有リスクと統制リスクが高い領域では、監査人は発見リスクを下げる(=より入念な手続きを行う)ことで、全体のバランスを取ります。リスクの高い場所ほど深く検証する、というリスクアプローチの考え方が、ここにも一貫して流れています。

なお、日本の監査基準では3つ目を「発見リスク」と呼び、英語では detection risk(検出リスク)と表記します。講義スライドでは「検出リスク」とあり、どちらも同じものを指します。本記事では「発見リスク(検出リスク)」と併記しておきます。

実証性テストの4手法 ── 質問・観察・検証・再実施

ここが、この記事の山場です。リスクの高い場所を絞り込んだあと、監査人は実際にどう確かめるのでしょうか。実証性テストには4つの手法があり、第2回(#3)で描いたリスクシナリオ(標的型攻撃や特権IDの悪用など)に、そのまま当てはまります。

4手法を、サイバーセキュリティの文脈で表にまとめます。

手法	やること	サイバーでの例	証拠能力	作業負荷
質問(Inquiry)	担当者に知識・運用状況を問う	標的型メール訓練と EDR の導入・運用状況を、担当者や SOC 要員に質問する	弱	軽
観察(Observation)	統制の実施状況を現場で見る	データセンターの入退管理や機器の現物管理を実地で観察する	中	中
検証(Verification)	サンプルの文書・記録を突き合わせる	特権ID利用申請書をサンプル抽出し、承認証跡(署名・捺印・日付)を操作ログと突合する	強	重
再実施(Re-performance)	統制を監査人が実際にやってみる	入退管理を実際に試し、共連れ入室して退出できないかを確かめる	最強	最重

この表で押さえてほしいのは、証拠能力と作業負荷が同じ方向に並んでいることです。質問 → 観察 → 検証 → 再実施と進むほど、得られる証拠は強くなります。同時に、作業負荷も重くなります。証拠の強さと手間はトレードオフの関係にあり、どこまでやるかは、その領域のリスクの高さで決まります。リスクの高い統制ほど、重くても再実施まで踏み込みます。リスクが低ければ質問で済ませます。ここでもリスクアプローチが効いています。

それぞれを、具体例でかみ砕きます。

質問(Inquiry)── まず聞く、ただし証拠力は弱い

標的型メール攻撃で添付ファイルを開かせ、C2(指令)サーバから遠隔操作して機密情報を盗む、というリスクを考えます。これに対する統制が、不審メール訓練・振る舞い検知型のエンドポイント対策(EDR)・外部通信のモニタリングだとします。

質問では、訓練の内容・参加者の成績・フォロー方法を担当者や参加者に問い、EDR の機能を確認し、SOC 要員に運用状況を聞きます。手早く全体像をつかめますが、返ってくるのは「運用しています」という回答であって、本当に機能しているかの証拠ではありません。だから証拠力は弱い、という位置づけです。

観察(Observation)── 現場で目で見る

重要な機器が置かれた場所への入退管理がゆるいと、機器や機密情報の破壊・盗取につながります。これに対する統制が「重要機器をロッカーに保管し、手順通り管理する」だとします。

観察では、監査人が現場へ行き、現物管理が適切か、保管マニュアルと実際の業務が一致しているかを目で見て確かめます。書類上は完璧でも、現場を見たら鍵が開けっ放しだった、ということは起こりえます。

検証(Verification)── サンプルを突き合わせる

特権IDが不適切に使われると、機密情報の盗取につながります。これに対する統制が「特権IDは普段は停止し、使うときだけ申請書で使用者を申請・管理者が承認し、使用後は速やかに停止する」だとします。

検証では、申請書の全リストを入手してサンプルを抽出し、記載内容と承認証(署名・捺印・日付)を確認します。さらに、形式だけの承認になっていないかの心証を得たうえで、承認のない操作が行われていないかを特権IDの操作ログと突き合わせます。記録(申請書)と実態(ログ)を突合する点が、検証の肝です。先ほどの「印がある≠承認された」という論点が、ここで実務に直結します。

再実施(Re-performance)── 監査人が自分でやってみる

データセンターの入退管理が、いちばんわかりやすい例です。統制が「ICカードで開閉し、アンチパスバック(入室記録のない者の退室を防ぐ設定)を有効にする」だとします。

再実施では、監査人がデータセンターへ実際に行き、規程通りかを確認し、共連れ入室(他人について入る)をしたうえで、退出できないことを自分で試します。証跡が残りにくく、ほかの手法では確かめにくい統制に対して、最後の決め手になる手法です。そのぶん作業負荷は最重で、得られる証拠は最強です。

これら4手法は、単独ではなく組み合わせて使われます。サイバーセキュリティ監査には決まりきった型がなく、各社が自分たちの環境に合わせて手続きを組み立てる必要がある、というのが講義での結びでした。

コラム: 監査の英単語ミニ辞典

監査の文献を読むと、似た意味の英単語が次々と出てきて、最初は区別がつきませんでした。背骨に直結する4語だけ、現場での語感の違いを表に整理します。ただし、これは厳密な定義というより「ニュアンスの目安」です。語の使い分けの拠り所として、NIST SP 800-53A が評価手法を examine(文書などを調べる)・interview(担当者に聞く)・test(実際に動かす) の3つに整理している点が参考になります。先ほどの4手法とも、ゆるやかに対応しています。

英単語	語感(目安)
Audit	監査。最も重く、結果に責任を負う。法律で定められることもある
Attest	証明。第三者が任意で「証明」を与える(SOC 報告書など)
Assess	評価・査定。リスクがどれだけ残っているかを見積もる
Examine	観察・検査。目で見て確認する(NIST の examine に対応)

混同しやすいのが Attest(証明)です。これは、外部の監査人に任意で依頼する 証明業務(attestation) を指し、その代表が SOC 報告書 です。SOC も3種類あるので、あわせて整理します。

種類	対象	公開範囲
SOC 1	財務報告に係る内部統制	限定(顧客・監査人など)
SOC 2	セキュリティ・可用性などの内部統制(財務以外)	限定(NDA のもとで顧客などに開示)
SOC 3	SOC 2 の要約	一般公開向け(Web で公開可)

SOC は米国公認会計士協会(AICPA)の枠組みで、証明業務の基準 SSAE 18 と、SOC 2 / 3 が用いる Trust Services Criteria(セキュリティ・可用性・処理のインテグリティ・機密性・プライバシー)に基づきます。前回(#3)で「AWS や Azure は SOC 2 Type2 を取得している」と書きましたが、その SOC が、この証明業務の体系の一部だったわけです。なお、この語感の整理は厳密な辞書的定義ではなく、現場で文献を読むときの目安として受け取ってください。

被監査人の心理を察する ── 監査を「うまくやる」作法

最後に、教科書には載りにくいけれど実務で効く話を1つ取り上げます。監査を受ける側(被監査人)の心理です。

被監査人は、本音では監査を受けたくありません。指摘されれば仕事が増えるからです。だから、聞かれたこと以外は進んで話そうとしません。これは責めるべきことではなく、人間として自然な反応です。監査人は、この心理を前提に動く必要があります。講義で示された「うまくやる作法」を、私なりにまとめます。

Yes / No で答えられない聞き方をする。 「承認していますか?」と聞くと「はい」で終わります。「どういう手順で承認していますか?」と聞けば、相手は手順を語らざるをえません。相手に話させることが、事実を引き出す近道です。
素人のふりをして、何でも聞く。 知ったかぶりをすると、相手は説明を省きます。「すみません、ここがよくわからないので教えてください」という姿勢のほうが、情報を引き出せます。
矛盾や不明瞭な回答は、論理的に整合するまで質問する。 つじつまの合わない答えは、何かを隠しているサインのことがあります。理詰めで、しかし冷静に、整合が取れるまで聞きます。
ダメなものはダメと言い、良い所は褒める。 指摘ばかりだと敵視されて、情報が出てこなくなります。良い統制はきちんと評価します。そうすることで、被監査人を敵に回さずに済みます。
不備は「どこで・何を(事実)・なぜ不備か」をその場で説明し、合意を得る。 後から一方的に「不備でした」と通告すると、反発を招きます。その場で事実を示し、なぜ不備なのかを説明し、相手の納得を得ておきます。事実と意見を分けて伝える規律が、ここでも生きてきます。

監査は、敵対的な詰問ではありません。事実を引き出し、論理で意見を組み立て、相手と合意していく協働作業です。この感覚を持てると、監査がぐっと立体的に見えてきます。

まとめ

この記事では、監査を「チェックリストにハンコを押す作業」という先入観から引きはがし、準拠性監査から有効性監査へと視点を移しました。タイトルに掲げた「準拠性 → 有効性」と、はじめに掲げた次の主張は、同じことを言っています。