政府のセキュリティガイドライン改定から学ぶ、5つの対策

はじめに

2026年6月12日、内閣官房 国家サイバー統括室が「政府機関等の対策基準策定のためのガイドライン」を一部改定しました。
対象は政府機関や独立行政法人ですが、改定の内容を読むと、民間のシステム運用でも普通に参考になる話が多かったです。特に「なぜこの改定が必要になったのか」という背景を読み解くと、現在のサイバー脅威の傾向が見えてきます。
今回は5つの改定事項を、背景・内容・実務での考え方の順で整理してみました。

① 脆弱性対策の強化：パッチ管理を「運用設計」として捉え直す
② IT-BCPの確実な整備：事業継続とセキュリティをつなげる
③ インシデント発生時の対処強化：IoCをどう扱うか
④ 多要素認証の強化：なぜパスワードだけでは足りないのか
⑤ DMARC対応：メールのなりすましを技術的に防ぐ

改定の背景

今回の改定の背景として、ガイドラインには「高性能AIの悪用などのサイバー攻撃の高度化・自動化」が明記されています。
攻撃者がAIを活用することで、脆弱なシステムのスキャン、認証情報のブルートフォース、フィッシングメールの生成などが自動化・高速化されています。これまで「時間がかかるから現実的ではない」とされていた攻撃が、現実的なコストで実行できるようになりつつあります。
こうした状況を踏まえて、政府機関のベースラインを引き上げるのが今回の改定の趣旨です。

① 脆弱性対策の強化：パッチ管理を「運用設計」として捉え直す

改定の内容

今回の改定で最も実務的な影響が大きいのが、脆弱性対策の強化です。
改定のポイントは2点です。

• 全情報システムについて、セキュリティパッチの適時の適用を前提とした運用設計（パッチマネジメント） を行う
• 迅速な適用が必要な場合、情報システムの運用を一時停止することも検討する

特に後者は踏み込んだ表現で、「パッチ適用のためにシステムを止める判断ができる体制を作れ」というメッセージとして読み取れます。

パッチマネジメントとは

パッチマネジメントとは、単に「パッチが出たら当てる」ではなく、以下を含む一連のプロセスです。

Step 1｜脆弱性情報の収集
↓
Step 2｜自組織への影響確認（該当製品を使っているか）
↓
Step 3｜リスク評価（緊急度・影響範囲の判断）
↓
Step 4｜適用計画の策定（いつ、どのシステムに、どの順序で）
↓
Step 5｜テスト環境での検証
↓
Step 6｜本番環境への適用
↓
Step 7｜適用後の確認・記録

このサイクルを全システムに対して回せる状態を「運用設計として組み込む」というのが今回の改定の要求です。

実務で詰まりやすいポイント

パッチ管理で最初に詰まるのは「自組織で何の製品が動いているかを把握できていない」という問題です。
社内資産台帳が最新化されていない、クラウド環境での一時的なリソースが管理対象から漏れている、外部委託先の機器が把握できていない、といったケースが典型的です。

新しいCVEが公開されたとき、影響確認の最初のステップは「該当製品が自組織のどこにあるか」を洗い出すことです。これが素早くできるかどうかが、パッチ管理の実効性を大きく左右します。

外部公開資産の把握には、Criminal IPのようなIT資産検索エンジンで製品名やHTMLタイトルを検索して外部露出の有無を確認する方法も補助的に使えます。ただし、あくまで「外から見える候補」であり、社内資産台帳の代替にはなりません。

例えば、6月8日に公開されたApache脆弱性ではパッチバージョンとして2.4.68がリリースされました。この場合、productフィルターとバージョンフィルターを組み合わせることで、未パッチのバージョンが稼働している外部露出資産を絞り込んで確認できます。

product_version:2.4.67 product: "apache"
直前のバージョンである2.4.67の検索結果では、7月1日時点で外部に露出している資産が120,468件確認できました。

詳細情報では、どのポートでどの製品のどのバージョンが運用されているのか、バナー情報や関連する脆弱性情報もあわせて確認できます。
このように、パッチバージョンが明確な脆弱性については、製品名とバージョンを組み合わせた検索で、未対応の資産がどの程度残っているかを概観できます。ただし、これも「外部から見えている候補」であり、実際の自組織資産かどうかは別途照合が必要です。

直近の例では、2026年6月、KDDIがISP事業者向けに提供するメールシステムで不正アクセスが発生し、最大1,422万件のメールアドレス・パスワードが漏洩した可能性があると発表されました。原因として、システムで利用していた第三者製ソフトウェアの脆弱性が悪用されたことが挙げられています。
この事案が示すのは、自社が直接開発していないコンポーネント（ライブラリ、ミドルウェア、外部委託先のシステムなど）についても、脆弱性対策の対象として把握しておく必要があるという点です。パッチマネジメントは自社開発のシステムだけでなく、組み込んだ第三者製ソフトウェア全体に対して機能させる必要があります。

② IT-BCPの確実な整備：事業継続とセキュリティをつなげる

改定の内容

IT-BCP（情報システム運用継続計画）について、以下が求められています。

• 政府業務継続計画における非常時優先業務を支えるシステムかを確認する
• IT-BCPが整備されているかを確認する
• IT-BCPの要件をふまえてセキュリティ要件を策定する

IT-BCPとセキュリティの関係

IT-BCPは「障害やインシデントが発生したとき、どのシステムをどの順序で復旧するか」を定めた計画です。
セキュリティとの関係で重要なのは、「どのシステムが止まると困るか」を明確にすることで、セキュリティ対策の優先順位を決められるという点です。

システムの重要度	セキュリティ対策の方針
業務継続に直結する基幹システム	外部公開を最小化、アクセス制限強化、ログの長期保全
停止しても代替手段がある補助システム	標準的な対策、定期的なパッチ適用
非常時には停止可能なシステム	復旧優先度は低め

IT-BCPが整備されていると、インシデント発生時に「このシステムは今すぐ復旧が必要か、それとも先に証拠保全を優先すべきか」という判断ができるようになります。

③ インシデント発生時の対処強化：IoCをどう扱うか

改定の内容

インシデント発生時にNCO（国家サイバー統括室）へ報告する事項に、サイバー脅威の分析に資する情報（IoC、ログ、デジタルフォレンジック結果等） が追加されました。

IoCとは何か

IoC（Indicator of Compromise）は、侵害の痕跡を示す情報です。代表的なものは以下です。

IoCの種類	例
IPアドレス	C2サーバーのIP、攻撃元IP
ドメイン	マルウェアが通信するドメイン
URL	フィッシングや配布に使われたURL
ファイルハッシュ	マルウェアのMD5/SHA256
レジストリキー	マルウェアが作成・変更するレジストリ
ユーザーエージェント	攻撃ツール固有のUser-Agent文字列

インシデント対応においてIoCは、「自組織の他のシステムにも同じ攻撃が及んでいないか」を横断的に確認するために使います。また、外部と共有することで、他組織が同じ攻撃を早期に検知することにもつながります。

IoCを扱えるようにするために

IoCを収集・活用するには、前提としてログが残っていることが必要です。攻撃に気づいたときにはログが消えていた、保存期間が短すぎてさかのぼれなかった、というのはよくある失敗です。
不審なIPやドメインを調査する場面では、Criminal IPのような脅威インテリジェンスで対象の性質（所有組織、過去の悪用履歴、公開ポートなど）を確認することも、IoCの文脈整理に使えます。

例えば、Criminal IPでは30秒ごとに悪意のあるIPと判断された目録を更新しています。

ここで一部資産を確認してみると、悪用履歴の有無やオープンポート、関連する脆弱性の有無に限らず、ハッキンググループとの関連性まで含めた豊富なコンテキストで分析が可能です。
また、こうした機能はAPI連携にも対応しているため、SIEMやSOAR、自社のインシデント対応フローに組み込んで、運用体制に合わせて活用することもできます。

④ 多要素認証の強化：なぜパスワードだけでは足りないのか

改定の内容

基幹システム等において、情報セキュリティインシデントに繋がるおそれのある強い権限を持つ主体には、原則として多要素主体認証方式を導入するとされています。

多要素認証（MFA）の基本

認証の要素は以下の3種類に分類されます。

• 知識情報（Something you know）：パスワード、PINなど
• 所持情報（Something you have）：スマートフォン、ICカード、ハードウェアトークンなど
• 生体情報（Something you are）：指紋、顔認証など

多要素認証（MFA）は、このうち2種類以上の要素を組み合わせる認証方式です。

なぜ「強い権限」が対象なのか

パスワード単体の認証が抱える根本的な問題は、「認証情報が漏れたとき、それ以上の防御がない」という点です。
実際に、FortiGateの認証情報が大量に流出した「FortiBleed」では、漏洩した認証情報が自動的に試行され、ログイン可能なアカウントが記録されていました。これがMFAありの環境であれば、認証情報が漏れても、即座に不正ログインにはつながりません。
「強い権限を持つ主体」から優先する理由は明快で、管理者権限が奪われたときの影響が最も大きいからです。

認証方式の選択

MFAの導入にあたって選択肢になる方式は以下のとおりです。

方式	特徴	注意点
TOTP（時刻ベースのワンタイムパスワード）	スマートフォンアプリで生成	SIMスワップ攻撃の影響を受けない
SMS OTP	SMSでコードを受信	SIMスワップ攻撃のリスクがある
ハードウェアトークン（FIDO2/WebAuthn）	物理デバイスで認証	フィッシングに強い、コストがかかる
プッシュ通知	スマートフォンアプリで承認	MFA疲労攻撃（プッシュ爆撃）に注意

特にFIDO2/WebAuthnはフィッシング耐性が高く、政府機関や金融機関での採用が増えています。

⑤ DMARC対応：メールのなりすましを技術的に防ぐ

改定の内容

政府機関等になりすました電子メールを受信した場合、受信側で迷惑メール（quarantine）または受信拒否（reject）となるよう、DMARCポリシーの設定を強化するとされています。

メール認証の仕組みを整理する

DMARCを理解するには、まずSPFとDKIMを知る必要があります。

SPF（Sender Policy Framework）

ドメインのDNS（TXTレコード）に、そのドメインから送信が許可されているIPアドレスの一覧を登録しておく仕組みです。受信側は、メールの送信元IPがSPFレコードに登録されているかを確認します。
example.com. IN TXT "v=spf1 include:_spf.google.com ~all"

DKIM（DomainKeys Identified Mail）

送信側がメールに電子署名を付与し、受信側がDNSに公開された公開鍵でその署名を検証する仕組みです。メールの内容が改ざんされていないことと、正規の送信者から送られたことを確認できます。

DMARC（Domain-based Message Authentication, Reporting & Conformance）

SPFとDKIMの検証結果を使って、「認証に失敗したメールをどう扱うか」を送信ドメイン側が指定できる仕組みです。
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[e-mail]"
p=の値がポリシーを示します。

ポリシー	動作
p=none	何もしない（モニタリングのみ）
p=quarantine	迷惑メールフォルダに振り分ける
p=reject	受信を拒否する

今回の改定では、quarantineまたはrejectに設定することが求められています。これまでnoneのまま放置されているケースが多かったことへの対応と言えます。

DMARCレポートの活用

DMARCのrua（集計レポート）やruf（フォレンジックレポート）を設定すると、自ドメインを使ったなりすまし送信の試みを把握できます。
誰が、どのIPから、どれだけの頻度で自ドメインを使ったなりすましを試みているかが可視化されるため、フィッシングキャンペーンの早期把握にも役立ちます。

まとめ

今回の改定を通じて見えてくるのは、「把握していないものは守れない、止められないものは対応できない」というシンプルな原則です。

改定事項	核心にある問い
①脆弱性対策	自組織にどの製品がどこにあるか、把握できているか
②IT-BCP	どのシステムが止まると最も困るか、整理できているか
③インシデント対処	攻撃の痕跡を収集・分析できる体制があるか
④多要素認証	認証情報が漏れたとき、次の防御線があるか
⑤DMARC	自ドメインのなりすましを技術的に防げているか

政府機関向けのガイドラインですが、「なぜこの対策が求められているのか」という背景を理解することで、自組織のセキュリティを見直す際の参考になると思います。

---

参考
• 政府機関等の対策基準策定のためのガイドライン（令和８年度一部改定）のポイント（PDF）：https://www.cyber.go.jp/pdf/policy/general/rev_pointr8_6.pdf
• Criminal IP：https://www.criminalip.io/ja