「基本の徹底」が求められる理由：政府の不正アクセス注意喚起から、事業者が今すぐ・日頃から・これからやるべきこと

2026年11月6日、総務省は「個人情報の漏えい等につながる不正アクセスへの対策について（事業者向け注意喚起）」を公表しました。もとになっているのは、前日11月5日に内閣官房国家サイバー統括室（NCO）が出した文書「個人情報の漏えい等につながる不正アクセスへの対策について～ウェブサイトやモバイルアプリに関する基本的な対策の徹底～」で、総務省はこれを所管事業者や関係団体に改めて周知した形です。

この秋は、10月9日のNCO・総務省・個人情報保護委員会などによる一斉の注意喚起、10月13日のNICTによる「アプリ解析からのサーバ攻撃（A2B攻撃）」の注意喚起と、政府からの呼びかけが続いています。それでも被害が止まらないなか、今回の文書の副題はずばり「基本的な対策の徹底」です。今回は注意喚起の中身を整理したうえで、事業者があらためてやるべきことを「今すぐ」「日頃から」「これから」の3つの時間軸に分けてまとめます。

注意喚起のポイント：原因は「基本ができていなかった」

政府は、最近の不正アクセスによる情報漏えい事案について、次のような基本的な対策の不足が原因とみられる事例を複数確認したとしています。しかも、自社だけでなく委託先の不備が原因になったケースも含まれます。

モバイルアプリ開発時のセキュリティ対策不足（APIの認可不備など）
ウェブサイト等の設定不備（管理画面や検証環境の公開、クラウドストレージの共有設定ミスなど）
サポートが終了したソフトウェア（EOL製品）の使い続け
既知の脆弱性を放置したままのソフトウェアの使い続け

攻撃の手口としては、国内の公開ウェブサイト等を広く調べ上げ、侵入口が見つかったところから入り込んで個人情報を盗み出す、という流れが想定されています。注目したいのは、標的の調査や侵入にAIが使われている可能性が高いとされている点です。これまでの脆弱性診断なら「リスクは比較的低い」と評価されていた弱点でも、AIがそれらを組み合わせることで侵入口になってしまったとみられています。

さらに、AIによって攻撃を大規模に展開しやすくなったことで、事業規模の大小を問わず幅広い事業者が狙われているとも指摘されています。「うちは小さい会社だから狙われない」という考え方は、もう通用しないということです。

NCO文書の対策は「3領域・8項目」

NCOの文書は、対策を3つの領域・計8項目に整理しています。総務省のページでは、これを「脆弱性や設定不備への対処と継続的な診断・監視」「設計・開発段階からの対策」「委託先を含むサプライチェーン全体の対策」として紹介し、経営層のリーダーシップのもとで取り組むよう求めています。

領域	対策項目	主な中身
運用・管理	1. デジタル資産の把握と脆弱性の解消	ソフトウェアの構成・バージョン・設置場所を把握し、既知の脆弱性に対処（サーバー・ネットワーク機器を優先）
	2. 攻撃対象領域の棚卸しと最小化	外部公開システムを定期的に洗い出し、不要な機能を停止。設定やアカウント管理も見直す
	3. AIも活用した継続的な診断と監視	定期的な診断、ログの集約・相関分析による不審な動きの検知。AIの評価は人が根拠を確認して最終判断
設計・開発	4. セキュリティ・バイ・デザイン	企画・設計段階からセキュリティを組み込む。SAST／SCA／DAST／IASTの活用
	5. APIのセキュリティ強化	認可不備の解消、認証情報の適切な管理、レート制限の設定（A2B攻撃対策）
	6. 公開前の脆弱性診断	リリース前の脆弱性診断・ペネトレーションテスト、修正と再確認
サプライチェーン	7. 委託先の統制と接続経路の厳格化	VPN・リモートデスクトップ等の経路把握、MFA、接続元制限、契約へのセキュリティ要件明記
サプライチェーン	8. OSS・外部ライブラリの管理	重大な脆弱性発覚時の初動手順、SBOMの提出要求と継続監視

ここからは、この8項目に、10月の一連の注意喚起で示された内容も加えて、「いつ・何をやるか」の順に並べ直してみます。

【今すぐ】今週中に手をつけたい緊急点検

まずは「すでに入られていないか」「明らかな穴が開いていないか」を確かめるところからです。完璧を目指すより、短期間で一周することを優先しましょう。

1. ログを見て、侵害の痕跡がないか確認する

総務省は10月13日の注意喚起で、アクセスログ等を調べて侵害の有無を確認するよう求めています。特に見ておきたいのは次のような動きです。

普段と違う国・IPアドレス・時間帯からの管理画面ログイン
APIへの短時間での大量アクセス、連番IDを順に叩くようなリクエスト
データベースからの大量のデータ取得、普段使われないエクスポート機能の利用
権限の変更や、見覚えのない管理者アカウントの追加

そもそも「ログが取れていない」「保存期間が短すぎて遡れない」ことが分かった場合は、それ自体が最優先の改善点です。

2. 外から見える自社の資産を洗い出す

攻撃者はインターネット側から自社を「調査」してきます。同じ目線で、外部に公開されているものを洗い出しましょう。NCO文書が例に挙げているのは、次のようなものです。

インターネットから到達できる管理画面（CMS、各種SaaSの管理コンソールなど）
公開されたままの開発環境・検証環境・ステージング環境
「リンクを知っている全員」などで共有されたクラウドストレージ
キャンペーン終了後も残っている特設サイトや古いサブドメイン

不要なものは停止し、どうしても必要なものは接続元IPアドレスの制限や多要素認証（MFA）で守ります。総務省も、不要なアクセスの制限といった暫定的な緩和策を早めに講じるよう呼びかけています。

3. EOL製品と既知の脆弱性をつぶす

OS、CMS、ミドルウェア、VPN機器などのバージョンを確認し、パッチを適用します。サポートが終了した製品は、そもそもパッチが出ないため利用停止・移行を検討します。優先順位は、NCO文書にあるとおりサーバーとネットワーク機器から。米CISAが公開している「実際に悪用が確認された脆弱性カタログ（KEV）」に載っているものは、最優先で対応しましょう。

4. モバイルアプリとAPIの「認可」を確かめる

アプリを提供している事業者は特に注意が必要です。NICTが注意喚起したA2B（App-to-Backend）攻撃は、公開されているアプリを解析して接続先サーバーやAPIの仕組みを割り出し、アプリではなくサーバー側の弱点を突くものです。アプリ自体に問題がなくても情報漏えいにつながる恐れがあり、iOSアプリやWebサービスでも同じことが起こり得るとされています。

ログインしていないユーザーや、他人のIDを指定したリクエストで、他人のデータが返ってこないか
画面に表示する以上の情報（住所・電話番号など）をAPIが返していないか
アプリ内にAPIキーや認証情報が埋め込まれていないか、埋め込まれたキーに過剰な権限がないか
短時間に大量のリクエストを受け付けてしまわないか（レート制限）

大前提として、「アプリから来た通信だから信頼できる」とは考えないこと。総務省も、アプリ側の制御だけに頼らず、サーバー側で認証・認可や入力値の検証を行うことが重要だとしています。

5. 委託先の「つながり方」を確認する

保守ベンダーや制作会社が、VPNやリモートデスクトップで自社環境に入れる状態になっていないでしょうか。どの委託先が、どの経路で、どの権限で接続できるのかを一覧にし、MFAが有効か、使っていない接続経路やアカウントが残っていないかを確認します。自社に落ち度がなくても、委託先の不備から被害を受けることがある、というのがNCO文書の指摘です。

【日頃から】運用に組み込んで続けること

緊急点検で一度きれいにしても、システムは日々変わり、新しい脆弱性も見つかります。今回の注意喚起で繰り返し出てくるキーワードは「継続的に」です。

資産台帳と脆弱性情報を「生きた状態」に保つ

サーバー、ネットワーク機器、ソフトウェア、ライブラリ・フレームワークまで含めて、構成とバージョンを台帳で管理する
脆弱性情報を継続的に収集し、影響を評価して、対応の優先度と期限を決める
外部公開資産の変化を継続的に監視する（ASM：アタックサーフェスマネジメントのツールやサービスも選択肢）

定期的な診断と、ログによる監視

脆弱性診断は「リリース時に一度だけ」ではなく、定期的に実施します。あわせて、各システムのログを集約・相関分析して、不審なログイン、権限の悪用、大量のデータ取得などを検知できるようにし、怪しい動きがあったときにすぐ調査して影響範囲を特定できる体制を整えます。自社だけで回すのが難しければ、EDR、MDR、SOC、SIEMといったツール・サービスの活用も検討対象です。

守る側もAIを使う。ただし最終判断は人が

今回の文書で目新しいのが、防御側もAIを活用するよう明確に勧めている点です。攻撃経路の探索・検証、脆弱性の影響範囲や対応優先度の評価、ログ分析や異常検知、対応手順の提案などにAIを使うことが挙げられています。攻撃者がAIで低リスクの弱点を組み合わせてくるなら、守る側も同じ視点で自社を点検しよう、という考え方です。一方で、AIの評価結果は人間が根拠と妥当性を確認したうえで最終判断する、とクギを刺している点も押さえておきましょう。

アカウントと権限、そして持っているデータを絞る

管理者権限を持つアカウントを定期的に棚卸しし、退職者・異動者・終了した委託先のアカウントを削除する
管理画面やリモート接続には多要素認証（MFA）を必須にする
利用目的を終えた個人情報は速やかに削除し、保有するデータそのものを最小化する（10月9日のNCO注意喚起でも、情報資産の棚卸しと保有情報の最小化が求められています）
保存データや通信経路を暗号化し、パスワードを平文で保存しない

「持っていないデータは漏れない」は、地味ですが最も確実な対策です。

委託先の対策状況を、契約時だけでなく継続的に確認する

委託先のセキュリティ対策は、契約時のチェックシートを受け取って終わりにしがちです。接続経路や権限の棚卸しを定期的に一緒に行い、作業時だけ接続を許可する運用にするなど、継続的に状況を確認する仕組みにしておきましょう。

【これから】仕組みとして作り込むこと

最後は、すぐには終わらないものの、今から計画に載せておきたい中長期の取り組みです。新規開発やリニューアル、契約更新のタイミングに合わせて進めるのが現実的です。

開発プロセスにセキュリティを組み込む

NCO文書は、要件定義から運用まで全工程でセキュリティを考える「セキュリティ・バイ・デザイン」を求めています。脅威モデリング、認証・認可・暗号化・ログ取得・アクセス制御の設計、クラウドアカウントの管理境界の分離などを設計段階で検討し、開発・テストでは次のようなツールを使い分けます。

ツール	何をするか	主に使う工程
SAST（静的解析）	ソースコードを解析して脆弱な書き方を見つける	実装
SCA（ソフトウェア構成分析）	使っているOSS・ライブラリと、その既知の脆弱性を洗い出す	実装〜運用
DAST（動的解析）	動いているアプリに外部から攻撃的なリクエストを送って検査する	テスト
IAST（対話型解析）	アプリ内部に仕込んだセンサーで、動作中の挙動から脆弱性を検出する	テスト

そのうえで、リリース前には脆弱性診断やペネトレーションテストを実施し、目的と範囲を決めて検査、見つかった問題を修正し、修正を確認してから公開する流れを標準にします。SQLインジェクション、OSコマンドインジェクション、リモートコード実行、SSRF、ディレクトリトラバーサルといった、典型的かつ深刻な脆弱性が主な確認対象です。

APIを前提にした設計にする

アプリは解析されるもの、APIは直接叩かれるもの、という前提で設計します。認可チェックはすべてサーバー側で行い、APIが返すデータは必要最小限に絞り、認証情報をアプリに埋め込まない仕組みにし、レート制限を標準で設けます。既存アプリの改修時にも、この観点でAPIを見直しましょう。

契約と調達のルールを変える

サプライチェーン対策は、最終的には契約書と仕様書で担保することになります。次の項目を、委託契約や調達仕様のひな形に盛り込んでおきましょう。

委託先が満たすべきセキュリティ要件（MFA、接続元制限、ログ取得など）
インシデント発生時・漏えい時の報告義務と報告期限
業務終了時のデータ削除と、その証跡の提出
納品物のSBOM（ソフトウェア部品表）の提出と、納品後の脆弱性監視の分担
セキュリティ対策の費用負担と実施方法（事前に協議しておくことがNCO文書でも触れられています）

「起きたとき」の手順を決めておく

NCO文書は、利用しているOSSや外部ライブラリでゼロデイ脆弱性など重大な問題が見つかったときの初動対応手順を整備するよう求めています。これに加えて、情報漏えいが疑われるときの連絡体制、調査を依頼する外部専門家、顧客への告知の段取りも決めておきたいところです。

なお、個人データの漏えいが不正アクセスによるものであるおそれがある場合などは、個人情報保護法にもとづき個人情報保護委員会への報告と本人への通知が必要になります。報告には「速報」と「確報」の期限があるため、誰がいつ判断して報告するのかを、事前に決めておくことが重要です。

経営層が旗を振る

総務省は、経営層のリーダーシップのもとで対策を強化するよう求めています。ここまで挙げた対策の多くは、予算、委託先との交渉、開発スケジュールの見直しを伴い、情報システム部門だけでは決めきれません。10月の注意喚起の段階から「もはや情報システム部門だけの問題ではない」というメッセージが出ていたことも思い出しておきましょう。またNCO文書は、今回の対策は現在の攻撃手法を想定したものであり、AIの悪用がさらに高度化・巧妙化することも見据えて対策を講じる必要があるとしています。一度やって終わり、ではありません。

まとめ：時間軸別チェックリスト

時間軸	やること
今すぐ	ログで侵害の痕跡を確認／外部公開資産の洗い出しと不要な公開の停止／EOL製品・既知の脆弱性への対応（KEV掲載分を最優先）／APIの認可とアプリ内の認証情報の確認／委託先の接続経路とMFAの確認
日頃から	資産台帳と脆弱性情報の継続管理／定期的な脆弱性診断／ログの集約・相関分析と監視／AIを活用した点検（最終判断は人）／アカウント・管理者権限の棚卸し／保有データの最小化と暗号化／委託先の対策状況の継続確認
これから	セキュリティ・バイ・デザインとSAST・SCA・DAST・IASTの導入／リリース前診断の標準化／API前提の設計／契約・調達仕様へのセキュリティ要件・報告義務・データ削除・SBOMの明記／重大脆弱性や漏えい時の初動手順の整備／経営層主導の体制づくり

今回の注意喚起に、まったく新しい対策が並んでいるわけではありません。むしろ「パッチを当てる」「不要なものを公開しない」「委託先を管理する」といった、これまでも言われ続けてきた基本ばかりです。ただ、AIによって攻撃者が小さな穴を見つけて組み合わせるコストが劇的に下がったいま、「ひとつひとつは軽微だから」と後回しにしてきた弱点が、そのまま侵入口になる時代になりました。基本を、継続的に、委託先まで含めて。まずは今週、「今すぐ」の5項目から手をつけてみてください。

本記事は、総務省および内閣官房国家サイバー統括室の公表資料、関連する報道（2026年11月7日時点の情報）をもとに整理したものです。「今すぐ／日頃から／これから」の分類や一部の具体例は、注意喚起の内容をもとに筆者が独自に整理・補足したものであり、公的資料の区分ではありません。実際の対策にあたっては、必ず原文の資料をご確認ください。