善意のハッカーを育てるだけでは会社は守れない

山崎行政書士事務所のクラウド法務から見た、サイバー防衛の現場

私は、サイバー防衛を「優秀なホワイトハッカーを何人抱えているか」だけでは見ていません。

もちろん、高度な技術者は必要です。攻撃者の手口を読み、脆弱性を見つけ、ログを追い、侵入経路を再現できる人材は、企業にとって極めて重要です。

しかし、現場で会社を守れるかどうかは、それだけでは決まりません。

本当に問われるのは、次です。

誰が調査してよいのか。どこまで調査してよいのか。本番環境に触れてよいのか。顧客データを見てしまった場合、どう止まるのか。発見した脆弱性を誰に報告するのか。夜中にアラートが出たら、誰が判断するのか。ログをどう保全するのか。クラウド管理者権限を誰が持つのか。委託先はどこまで操作できるのか。官民で情報共有する場合、何をマスキングするのか。事故後、経営層・取引先・行政・顧客に何を説明できるのか。

ここまで決まっていなければ、どれだけ優秀な人材がいても、組織としては守れません。

1. 現場では、攻撃はきれいな形で来ない

サイバー攻撃は、教科書のようには来ません。

大量通信でサービスを落とす。メールから認証情報を盗む。委託先のアカウントを使う。クラウド管理画面に正規ログインする。VPNの古い設定を突く。社員証を偽造してオフィスに入る。USBデバイスを挿す。退職者アカウントを使う。バックアップを消す。ログを止める。脆弱な子会社から入る。地方拠点の古い端末を踏み台にする。

攻撃者は、正面玄関だけを狙いません。むしろ、会社が見落としている場所を狙います。

本社のクラウド環境は固い。しかし、地方拠点のVPNは古い。本社はMFAを入れている。しかし、委託先の管理者IDは棚卸しされていない。本番環境は監視されている。しかし、検証環境に顧客データが残っている。バックアップはある。しかし、復旧訓練をしたことがない。SOC契約はある。しかし、深夜に遮断判断できる責任者がいない。

これが現場です。

私は、サイバー防衛を考えるとき、まず「製品が入っているか」ではなく、「会社として判断できる状態か」を見ます。

2. 24時間365日体制は、契約書に書くだけでは成立しない

「24時間365日監視しています」

この言葉をよく見ます。しかし、現場で本当に必要なのは、監視ではなく、判断です。

深夜2時にアラートが出る。SOCから通知が来る。一次対応者が確認する。不審なログインがある。端末が外部と通信している。管理者権限が使われている。バックアップにもアクセスがある。

このとき、誰が何を決めるのか。

端末を隔離するのか。アカウントを止めるのか。ネットワークを遮断するのか。本番システムを止めるのか。委託先に連絡するのか。経営層を起こすのか。顧客影響を調べるのか。ログ保全を優先するのか。証跡を取る前に遮断するのか。

ここが決まっていない会社は、24時間365日体制とは言えません。

監視サービスを契約していても、委託先が勝手に本番を止められるわけではありません。逆に、委託先に強すぎる権限を渡していれば、委託先側の侵害や誤操作が自社の重大事故になります。

私は、24時間365日体制を作るなら、必ず次を文書に落とします。

一次対応者。二次対応者。経営報告基準。夜間・休日の連絡網。委託先の対応範囲。遮断・停止・復旧の承認者。ログ保全手順。顧客・取引先への説明手順。個人情報漏えい疑い時の初動。取締役会への報告様式。

ここまで整えて初めて、監視が経営統制になります。

3. 報告しない文化が、初動を殺す

サイバー事故で怖いのは、技術的な侵害だけではありません。もっと怖いのは、現場が気づいているのに報告しないことです。

担当者が違和感に気づく。ログがおかしい。端末の動きが変だ。管理者権限が使われている。でも、報告しない。

なぜか。

怒られるからです。責められるからです。「なぜ防げなかった」と言われるからです。「本当に攻撃なのか」と詰められるからです。「業務を止めたら責任を取れるのか」と言われるからです。

この空気がある会社では、初動が遅れます。初動が遅れれば、攻撃者は横展開します。権限を上げます。ログを消します。バックアップを消します。データを持ち出します。

だから私は、インシデント対応規程に「早期報告者を責めない」考え方を入れるべきだと考えています。

疑い段階で報告してよい。誤報でも責めない。報告の遅れはレビュー対象にする。一次報告では原因まで断定しなくてよい。事実と推測を分ける。経営層は初動段階で犯人探しをしない。まず封じ込めと証跡保全を優先する。

これは精神論ではありません。サイバー防衛の実務統制です。

4. ホワイトハッカーに必要なのは、攻撃技術だけではない

優秀なホワイトハッカーは、会社にとって重要です。しかし、攻撃技術だけが高い人材を、そのまま顧客環境に入れるのは危険です。

現場で必要なのは、技術だけではありません。

許諾範囲を読む力。契約を読む力。本番環境を壊さない判断力。個人情報を見たときに止まる力。ログを壊さず証跡化する力。脆弱性を再現する力。再現手順を安全に書く力。経営層に分かる言葉でリスクを説明する力。顧客に不安を与えすぎず、過小評価もしない報告力。

ホワイトハッカーの仕事は、見つけて終わりではありません。発見した脆弱性を、会社が直せる形に変換しなければなりません。

「危険です」だけでは足りない。どの資産が影響を受けるのか。攻撃者は何ができるのか。どのログで確認できるのか。一時対応は何か。恒久対応は何か。委託先の責任はどこまでか。経営判断が必要な投資は何か。

そこまで書けて、初めて現場で使える報告書になります。

5. 善意のハッカーを活かすには、契約が必要になる

私は、ホワイトハッカーに診断や調査を依頼する場合、最初に契約とSOWを見ます。

技術者が優秀かどうかだけでは不十分です。何をしてよいのかが決まっていなければ、善意の調査でも事故になります。

必ず決めるべき項目があります。

診断対象。診断期間。本番環境へのアクセス可否。負荷をかけるテストの可否。認証情報の貸与方法。取得してよいログの範囲。個人情報を発見した場合の停止基準。顧客データを閲覧した場合の報告方法。脆弱性報告の期限。第三者製品に関する脆弱性の扱い。再委託の可否。秘密保持。成果物の利用範囲。事故時の責任分界。

ここを曖昧にすると、双方にとって危険です。

企業側は「そこまで触ってよいとは言っていない」と言う。技術者側は「診断のために必要だった」と言う。顧客データに触れる。本番環境が止まる。ログが残らない。責任分界が分からない。

善意のハッカーを守るためにも、企業を守るためにも、許諾範囲を明確にする必要があります。

6. 官民連携で一番揉めるのは、情報共有の範囲

官民連携は必要です。しかし、現場で一番難しいのは「何を共有するか」です。

攻撃元IPを出すのか。ログをそのまま出すのか。顧客名を伏せるのか。従業員IDを伏せるのか。取引先名が入っている場合どうするのか。クラウド構成図を出してよいのか。脆弱性情報をどこまで出すのか。攻撃を受けたシステム名を出すのか。委託先名を出すのか。海外拠点の情報を含めるのか。

ここを決めずに、官民連携と言っても現場は動けません。

特に、企業のログには多くの情報が混ざります。

個人情報。顧客名。取引先名。社員ID。メールアドレス。IPアドレス。端末名。クラウド構成。認証履歴。業務システム名。委託先の操作記録。

このまま外部共有すれば、別のリスクが生まれます。しかし、共有しなければ攻撃の全体像が見えません。

だから私は、官民連携にはマスキング基準が必要だと考えます。

どの情報は共有できるのか。どの情報は匿名化するのか。どの情報は経営承認が必要なのか。どの情報は顧客・取引先との契約確認が必要なのか。どの情報は弁護士確認が必要なのか。共有した記録をどう残すのか。

情報共有は、善意だけではできません。運用基準が必要です。

7. クラウド時代の攻撃は、IDと権限を狙う

クラウド環境では、攻撃者は必ずしもサーバーそのものを壊しに来ません。もっと効率のよい場所を狙います。

IDです。権限です。管理画面です。委託先アカウントです。サービスプリンシパルです。APIキーです。バックアップ権限です。ログ閲覧権限です。条件付きアクセスの例外です。

Azureを使っている会社であれば、私は最初にEntra IDを見ます。誰が管理者か。常時管理者は何人いるか。PIMを使っているか。条件付きアクセスはあるか。MFA例外はあるか。委託先アカウントは残っていないか。退職者アカウントは消えているか。緊急用アカウントは管理されているか。サービスプリンシパルに過剰権限がないか。ログは保存されているか。

ここが甘い会社は、クラウド基盤がどれだけ強くても危険です。

「クラウドだから安全」ではありません。クラウドでは、管理者権限を奪われた瞬間に、正規機能で攻撃されます。

ストレージを消す。バックアップを消す。ログ設定を変える。仮想マシンを止める。Key Vaultにアクセスする。条件付きアクセスを緩める。新しい管理者を作る。外部アカウントを招待する。監査ログの保存先を変える。

これらは、攻撃ツールではなく、正規機能です。だからこそ、クラウド法務では、権限表、操作ログ、承認フロー、責任分界が重要になります。

8. 物理セキュリティとクラウドはつながっている

サイバー防衛というと、ネットワークやクラウドだけを見がちです。しかし、現場では物理から入られることがあります。

偽造社員証で入館する。会議室に置かれた端末に触る。USBデバイスを挿す。無線LANに接続する。端末のセッションを奪う。画面に表示された情報を見る。廃棄端末から情報を取る。

ここからクラウドへつながります。

端末の認証情報を盗む。Entra IDへログインする。クラウド管理画面に入る。権限を確認する。ログを探す。データを持ち出す。バックアップを消す。

だから私は、クラウド法務でも物理セキュリティを見ます。

入退室管理。来訪者管理。端末管理。USB制御。MDM。端末暗号化。条件付きアクセス。準拠デバイス要求。紛失時リモートワイプ。委託先作業員の入館権限。

クラウドと物理は分かれていません。攻撃者にとっては、どちらも入口です。

9. AI防御は必要だが、AIに任せすぎてはいけない

攻撃は増えています。人間だけで全部を見るのは現実的ではありません。

だから、防御側でもAIは必要です。

アラートの優先順位付け。ログの相関分析。不審ログインの検知。KQLの補助。マルウェア挙動の分類。インシデント要約。一次対応案の提示。

これは有効です。

しかし、AIに本番遮断を完全自動で任せるのは危険です。AIが誤判定すれば、業務が止まります。顧客影響が出ます。取引先に迷惑がかかります。

私は、防御AIには承認設計が必要だと考えます。

AIが検知する。人間が確認する。重大度を判断する。遮断は承認制にする。自動遮断は条件を限定する。AIの判断ログを残す。誤判定をレビューする。モデルやルール変更時に再評価する。

AI防御も、クラウド法務の対象です。AIが何を検知したのか。誰が承認したのか。どの操作を実行したのか。誤判定時にどう説明するのか。

ここを決めないままAIを入れると、便利な防御機能が新しい事故原因になります。

10. 地方拠点・子会社・委託先が入口になる

本社だけ守っても、会社は守れません。

攻撃者は、最も弱いところを探します。

地方拠点。工場。倉庫。店舗。子会社。海外拠点。委託先。古いVPN。古い端末。共有アカウント。棚卸しされていない管理者ID。

本社は強い。でも、地方拠点のルーターが古い。本社はMFAあり。でも、子会社はパスワードだけ。本社はSOC監視。でも、倉庫端末は監視対象外。本社は教育済み。でも、委託先には教育していない。

こういう会社は珍しくありません。

私は、サイバー防衛を考えるとき、必ずグループ全体を見ます。

どの拠点にどのシステムがあるか。どの子会社がどのクラウドに入っているか。委託先にどの権限を与えているか。地方拠点の端末は管理対象か。工場系ネットワークと業務系ネットワークは分離されているか。バックアップは地理的に分散しているか。本社停止時に地方拠点が最低限動けるか。地方拠点で復旧訓練をしているか。

防衛力は、最も強い場所ではなく、最も弱い場所で決まります。

11. 経営層が確認すべきこと

経営層は、サイバー防衛を情シス任せにしてはいけません。

最低限、次を確認すべきです。

24時間365日の初動責任者は誰か。夜間に本番停止を判断できる人は誰か。SOC委託先は何をしてくれるのか。委託先は遮断権限を持つのか。その権限は契約に書いてあるか。バックアップは攻撃者から消されないか。復旧訓練は実施済みか。ホワイトハッカー診断の範囲は明確か。官民連携で共有する情報のマスキング基準はあるか。早期報告者を責めない規程はあるか。取締役会に出すサイバーリスク資料はあるか。重要取引先に自社のクラウド統制を説明できるか。

これに答えられないなら、まだ防衛体制はできていません。

12. 山崎行政書士事務所として支援すべきこと

私は、クラウド法務の支援として、単に「セキュリティを強化しましょう」とは言いません。

必要なのは、技術と文書をつなぐことです。

サイバー防衛責任分界表

経営層、CISO、情シス、SOC、MSSP、クラウド運用委託先、ホワイトハッカー、法務、広報、監査部門の責任を整理します。

ホワイトハッカー診断契約・SOW

診断範囲、許諾、禁止行為、取得データ、秘密保持、報告形式、再委託、事故時責任を明確にします。

官民情報共有マスキング基準

IP、ログ、顧客名、取引先名、社員ID、クラウド構成、脆弱性情報をどこまで共有するかを決めます。

Azureセキュリティ統制レビュー

Entra ID、条件付きアクセス、PIM、RBAC、Sentinel、Defender、Key Vault、Backup、Azure Policy、ログ保存、委託先権限を確認します。

インシデント初動規程

報告義務、責めない文化、夜間連絡、遮断承認、証跡保全、経営報告、顧客説明を整備します。

取締役会向けサイバー報告資料

技術画面をそのまま出すのではなく、経営判断できる資料に変換します。重大リスク、未対応事項、例外承認、委託先リスク、復旧可能性、投資判断を整理します。

13. 最終評価

私は、善意のハッカー育成を重要だと考えています。しかし、それだけでは会社は守れません。

善意のハッカーが動ける許諾範囲。調査できる契約。守秘義務。ログ保全。脆弱性報告ルール。官民情報共有のマスキング基準。Azure上の権限管理。委託先との責任分界。経営層への報告資料。

これらがそろって初めて、ホワイトハッカーの力は企業防衛になります。

サイバー防衛の現場で必要なのは、きれいな標語ではありません。

深夜に誰が電話に出るか。誰が止めるか。誰がログを取るか。誰が報告するか。誰が顧客に説明するか。誰が責任を持って復旧を判断するか。

私は、そこまで決めるのがクラウド法務だと考えています。

なお、個別案件の法的判断、紛争対応、相手方との交渉、訴訟対応は弁護士等との連携領域です。行政書士としては、契約、規程、責任分界表、事実証明資料、監査説明資料等の作成支援を中心に、技術と法務の間をつなぐ支援を行います。