top of page

能動的サイバー防御の現場評価



山崎行政書士事務所のクラウド法務から見た、攻撃予兆・AI監視・政府報告の実務

1. 結論

私は、能動的サイバー防御を「国が攻撃元を無害化してくれる制度」とだけ見ていません。現場で本当に変わるのは、企業側が“被害が出てから報告する”運用では済まなくなることです。

これから重要インフラ、クラウド運用、SOC、MSSP、サプライチェーン企業では、次が問われます。

攻撃の兆しをいつ把握したのか。その兆しを誰が分析したのか。レベル1〜2の予兆を捨てた根拠は何か。レベル3〜4に上げた判断者は誰か。政府・所管省庁へ報告すべき事象だったのか。通信情報やログをどこまで共有できるのか。個人情報・顧客名・取引先名をどうマスキングしたのか。AIが作った報告書の根拠を人間が確認したのか。委託先SOCが見た情報を、自社が説明できるのか。

つまり、能動的サイバー防御の本質は、国の無害化措置そのものよりも、民間企業側の予兆検知、ログ保全、報告判断、マスキング、責任分界、監査証跡にあります。

政府公式資料では、サイバー対処能力強化法と同整備法は2025年5月16日に成立、同年5月23日に公布されています。官民連携とアクセス・無害化措置部分の制度施行は2026年10月1日想定、通信情報の利用部分は2027年11月までの施行想定とされています。

2. 私が一番危ないと見る誤解

現場で一番危ない誤解は、これです。

「能動的サイバー防御が始まれば、国が攻撃者を止めてくれる」

これは危険な理解です。

民間企業がやるべきことは減りません。むしろ増えます。国がアクセス・無害化措置を行うとしても、企業側が攻撃の兆し、侵害の疑い、影響範囲、ログ、通信情報、システム構成、委託先関与を整理できなければ、国に渡す情報の質が足りません。

そして、民間企業が勝手に攻撃元サーバーへ入り込んでよいわけでもありません。企業側が担うのは、自社環境・委託先環境・クラウド環境における検知、封じ込め、証跡保全、報告、復旧です。

私なら、経営層にこう説明します。

国の無害化は最後の一手。企業の仕事は、その前に“攻撃が来ている”と証明できるログと判断プロセスを作ることです。

3. 現場では「予兆」の扱いが一番難しい

サイバー攻撃は、いきなりランサムウェアで止まるわけではありません。

最初は、小さな兆しです。

外部からのスキャン。VPNへの不審なログイン試行。古いサーバーへの探索通信。委託先アカウントの異常なサインイン。海外IPからの管理画面アクセス。MFA疲労攻撃の兆候。ダークウェブ上の認証情報流通。社名を含むフィッシングキット。業務委託先のメールアカウント侵害。普段使わない国からのEntra IDログイン。クラウド上のサービスプリンシパル利用異常。

ここをレベル1、レベル2としてAIが整理する運用は合理的です。人間がすべてを確認していたら、SOCも情シスも潰れます。

ただし、現場で一番怖いのは、AIが低レベル扱いした予兆を誰も見返さないことです。

最初は単なるスキャン。次に認証試行。次にフィッシング。次に委託先IDの侵害。次にVPNログイン。次に横展開。最後に暗号化。

攻撃者は、点ではなく線で動きます。AIが個別アラートをレベル1〜2に分類しても、横断的に見ると攻撃の準備行為かもしれません。

だから私は、AIでアラートを減らすことには賛成ですが、次の設計を必須にします。

低レベル予兆の保存期間。同一攻撃者・同一IP・同一ドメインの相関分析。委託先や海外子会社との突合。レベル1〜2からレベル3へ昇格する条件。AI分類の人間レビュー周期。捨てたアラートの根拠記録。重大事案後の過去アラート再点検手順。

AIで初歩的対応を自動化するなら、AIが捨てた情報を後から説明できる設計が必要です。

4. 政府報告は「結果報告」ではなく「判断過程の報告」になる

これから重要なのは、被害が出た後の報告だけではありません。予兆段階での判断も問題になります。

政府公式資料では、基幹インフラ事業者について、特定重要電子計算機のサイバーセキュリティが害されたこと、またはその原因となり得る一定の事象を認知したときに、事業所管大臣と内閣総理大臣へ報告する枠組みが示されています。

この「原因となり得る一定の事象」が、現場では重いです。

被害が出ていない。でも、侵害の疑いがある。ログインは成功していない。でも、認証情報が流通している。マルウェアは見つかっていない。でも、外部からC2通信らしきものがある。データ流出は確認できない。でも、委託先アカウントが異常に使われている。

この段階で報告するかどうか。ここが一番揉めます。

情シスは「まだ確証がありません」と言う。法務は「報告義務の対象か確認したい」と言う。事業部は「騒ぎにしたくない」と言う。SOCは「早めに上げた方がいい」と言う。経営層は「報告したら当局対応が始まるのか」と不安になる。

だから、私は報告基準を事前に作ります。

確定侵害。侵害疑い。認証情報流出。重要システムへの不審アクセス。委託先経由の侵害疑い。復旧不能リスク。個人情報漏えい可能性。重要インフラ機能停止のおそれ。政府共有対象となる予兆。

この区分がない会社は、能動的サイバー防御の時代に、毎回会議で迷います。

5. 「AIで報告書を作る」は便利だが、危ない

SOCや監視拠点で生成AIを使って報告書を作る流れは自然です。アラート、ログ、端末情報、通信先、マルウェア痕跡、ダークウェブ情報、過去事例を要約するには、AIはかなり使えます。

しかし、私はAI報告書をそのまま当局提出や取締役会報告に使うのは危険だと考えます。

理由は明確です。

AIが事実と推測を混ぜる。ログにないことを補完して書く。攻撃者名を断定しすぎる。影響範囲を広く書きすぎる。逆に重大性を低く見積もる。個人情報や顧客名を含んだまま出す。委託先の責任を誤って記載する。過去事例を誤って引用する。根拠ログへのリンクがない。誰が確認したか分からない。

AIで報告書を作るなら、私は次を必ず入れます。

AI生成日時。利用したログ範囲。AIが参照した情報源。人間レビュー者。修正履歴。事実・推測・評価の区別。未確認事項の明示。マスキング済み項目の一覧。当局提出版と社内版の区別。顧客説明版との区別。

政府報告で重要なのは、きれいな文章ではありません。なぜその判断に至ったかを検証できることです。

6. 通信情報の扱いは、現場で最も神経を使う

能動的サイバー防御で避けて通れないのが、通信情報の扱いです。

政府公式説明では、法の適用は必要最小限度で厳格に権限を行使し、日本国憲法が保障する通信の秘密その他の権利と自由を不当に制限してはならない旨が示されています。

また、同説明では、通信情報の取得・分析について、サイバー通信情報監理委員会の承認、外外通信・外内通信・内外通信、自動選別、IPアドレスや指令情報など意思疎通の本質的内容ではない機械的情報の扱いが整理されています。

これは、現場ではかなり生々しい論点になります。

SOCのログには、顧客情報が混ざります。通信ログには、社員IDが入ります。DNSログには、業務内容が推測できる情報が残ります。プロキシログには、閲覧先が残ります。メールログには、送受信者が残ります。クラウドログには、システム名、利用者、操作対象が残ります。

「攻撃検知に必要だから全部出す」は危険です。「通信の秘密があるから何も出せない」も現実的ではありません。

私は、ここをマスキング基準で処理します。

IPアドレスを出すか。メールアドレスをハッシュ化するか。顧客名を伏せるか。システム名を一般化するか。取引先名を匿名化するか。ログ全文ではなく該当行だけ出すか。パケット内容を出さずメタデータだけ出すか。委託先名を出す前に契約確認するか。

通信情報は、提出すればよいのではありません。提出できる形に整えておくことが必要です。

7. 官民協定は「任意」でも、現場では準備が必要になる

政府公式説明では、内閣総理大臣と基幹インフラ事業者等は、協定締結のための協議を求めることができ、相手方は正当な理由がない限り協議に応じなければならないとされています。ただし、協定は任意と整理されています。

私は、ここを現場目線でかなり重く見ています。

任意だから何もしなくてよい、ではありません。協議を求められた瞬間に、企業はこう聞かれます。

どの重要システムが対象か。どの通信情報を提供できるか。誰が提供判断をするか。提供前に法務確認が必要か。委託先ログは取得できるか。海外子会社ログは含まれるか。個人情報や取引先情報のマスキングはどうするか。提供記録をどう残すか。提供後の問い合わせ窓口は誰か。情報漏えい時の責任分界はどうするか。

これをその場で決めるのは無理です。

私は、基幹インフラや関連ベンダーには、事前に「官民連携対応台帳」を作るべきだと考えます。

対象システム。対象ログ。データ所有者。委託先。再委託先。海外拠点。提供可能範囲。マスキング方法。承認者。保存期間。提出記録。当局対応責任者。

8. 重要なのは、国内本社ではなく海外子会社・委託先・サプライチェーン

私は、サイバー攻撃の現場で、本社だけ見ても意味がないと考えています。

攻撃者は一番弱いところを探します。

海外子会社。地方拠点。物流拠点。工場。販売子会社。保守会社。クラウド運用委託先。SaaS管理者。VPN管理者。海外の小規模拠点。グループ共通IDに接続している子会社。

本社は強い。でも、海外子会社のMFAが弱い。本社はSOC監視されている。でも、物流子会社は監視対象外。本社はPIMを使っている。でも、委託先は常時管理者。本社はログを90日保存。でも、海外拠点は7日で消える。

こういう状態で、国への報告や予兆共有が必要になったらどうなるか。影響範囲が分かりません。委託先に問い合わせます。海外と時差があります。言語の壁があります。契約にログ提出義務がありません。結局、報告が遅れます。

だから、能動的サイバー防御に備えるなら、グループ全体のログと権限を見ます。

本社だけ強くしても、現場は守れません。

9. AI監視拠点に任せるほど、自社の責任分界が重要になる

国内大手SIer系の監視拠点や、海外系CTI事業者の脅威インテリジェンスサービスを使うこと自体は有効です。

ダークウェブを見る。攻撃者グループの動向を見る。RaaSの兆候を見る。漏えい認証情報を見る。攻撃キャンペーンを把握する。世界拠点のログと突き合わせる。AIでアラートを分類する。

これは、人手だけでは難しい領域です。

ただし、任せるほど、自社側の責任分界が必要になります。

監視会社は何を見ているのか。どのログを渡しているのか。どこまで分析してくれるのか。政府報告文案まで作るのか。当局提出は誰の名義か。AIが生成した報告の責任は誰か。誤検知で業務停止した場合、誰が責任を負うのか。レベル1〜2を通知しない運用で、後から重大攻撃につながった場合どうするのか。顧客情報を含むログを海外拠点で見ていないか。サブプロセッサーは誰か。

ここを契約に落とさないと、事故時に揉めます。

私は、SOC・MSSP・CTI契約では、次を必ず見ます。

ログ取扱い。再委託。国外移転。AI利用。アラート分類基準。重大アラート通知期限。政府報告支援の範囲。証跡提出義務。誤検知・見逃し時の責任。契約終了時のログ削除。監査協力。秘密情報のマスキング。

監視サービスは、入れれば終わりではありません。自社が説明できる形で使うことが必要です。

10. Azure環境で私が最初に見る場所

Azureを使っている企業なら、能動的サイバー防御対応で私はまずここを見ます。

Entra ID。条件付きアクセス。PIM。管理者アカウント。Break Glassアカウント。委託先アカウント。サービスプリンシパル。Key Vault。Defender。Sentinel。Log Analytics。Azure Activityログ。Storageログ。WAFログ。Azure Policy。バックアップ。DR。Microsoft 365監査ログ。Purview DLP。Teams・SharePointの外部共有。

なぜか。

政府や所管省庁へ報告する段階では、こう聞かれるからです。

いつ侵入された可能性があるか。どのIDが使われたか。どの端末から入ったか。どの管理者権限が使われたか。どのデータに触ったか。データは外部に出たか。ログは改ざんされていないか。委託先が操作したのか。バックアップは生きているか。復旧可能か。再発防止策は何か。

Azureの設定が正しいかだけでは足りません。Azureの設定を、報告書と責任分界表に変換できるかが重要です。

11. 企業が今すぐ作るべき文書

私は、能動的サイバー防御に備える企業には、次の文書を作るべきだと考えます。

11.1 予兆検知・重大度分類基準

レベル1〜4のような分類を、自社の業務影響と結びつけて定義します。AI分類を使う場合、人間レビュー条件も入れます。

11.2 政府・所管省庁報告判断フロー

確定侵害、侵害疑い、認証情報流出、重要システム影響、委託先経由、個人情報関与などで報告要否を判断します。

11.3 通信情報・ログ提供マスキング基準

IP、メールアドレス、顧客名、社員ID、取引先名、システム名、構成図をどこまで伏せるかを決めます。

11.4 SOC・MSSP責任分界表

監視、分析、通知、報告支援、証跡提出、復旧支援、政府対応支援の範囲を明確にします。

11.5 Azureログ設計書

Entra ID、Sentinel、Defender、Key Vault、Azure Activity、WAF、アプリログの保存期間と閲覧権限を定めます。

11.6 AI報告書レビュー手順

生成AIが作成したサイバー報告書を、人間がどの観点で確認するかを決めます。

11.7 取締役会向けサイバー予兆レポート

技術アラートではなく、経営判断に必要な重大予兆、未対応リスク、例外承認、委託先リスクを整理します。

12. 経営層への生々しい提言

経営層は、能動的サイバー防御を国の制度として眺めていてはいけません。

経営層が今すぐ確認すべきことは、次です。

自社は基幹インフラ・重要取引先・サプライチェーン上、報告対象になり得るか。攻撃予兆を誰が見ているか。AIが低レベル扱いした予兆を後から確認できるか。政府報告の判断者は誰か。報告前にマスキングできるか。通信ログに個人情報や顧客情報が混ざる場合、どう扱うか。SOC委託先は報告支援までしてくれるか。海外子会社のログは取れるか。Azureの管理者権限とログは説明できるか。取締役会に月次で予兆レポートを出しているか。

これに答えられないなら、制度対応はまだできていません。

13. 山崎行政書士事務所としての支援

山崎行政書士事務所のクラウド法務として、私はこの領域で次を支援すべきだと考えます。

Azure構成と法務文書をつなぐ。SOC契約と責任分界を整理する。政府報告のための事実整理様式を作る。通信情報・ログのマスキング基準を作る。AI報告書のレビュー手順を整える。委託先・再委託先のログ提出義務を契約化する。予兆検知から報告までのフローを規程化する。取締役会向けのサイバー予兆レポートを作る。

行政書士としては、契約、規程、責任分界表、事実証明資料、監査説明資料、報告準備資料の作成支援が中心です。個別事案の法的判断、紛争対応、相手方との交渉、訴訟対応は弁護士等との連携領域です。

14. 最終評価

私は、能動的サイバー防御を「国が攻撃元を無害化する制度」としてだけ語るのは不十分だと考えています。

現場にとっての本質は、次です。

企業は、攻撃予兆を見つけ、分類し、証跡化し、必要な範囲で政府・所管省庁・委託先・取引先に説明できる体制を持たなければならない。

国の制度は強くなります。しかし、企業側のログが弱ければ、報告できません。委託契約が弱ければ、証跡を取れません。AI分類がブラックボックスなら、判断過程を説明できません。マスキング基準がなければ、情報共有で別のリスクを生みます。取締役会が理解していなければ、投資判断が遅れます。

山崎行政書士事務所のクラウド法務として、私はこのテーマを次の一文で整理します。

能動的サイバー防御の時代に必要なのは、攻撃を受けた後の謝罪文ではない。攻撃の兆しを、Azureログ、SOC分析、AI分類、契約、規程、責任分界、政府報告資料で説明できる会社になることだ。

これができる会社は、制度を防衛力に変えられます。これができない会社は、制度が始まっても、現場で迷い、報告が遅れ、被害を拡大させます。

 
 
 

コメント


Instagram​​

Microsoft、Azure、Microsoft 365、Entra は米国 Microsoft Corporation の商標または登録商標です。
本ページは一般的な情報提供を目的とし、個別案件は状況に応じて整理手順が異なります。

※本ページに登場するイラストはイメージです。
Microsoft および Azure 公式キャラクターではありません。

Microsoft, Azure, and Microsoft 365 are trademarks of Microsoft Corporation.
We are an independent service provider.

​所在地:静岡市

©2024 山崎行政書士事務所。Wix.com で作成されました。

bottom of page