A2B攻撃の対策｜最初の72時間でやること、恒久対策、3〜5日以内の報告期限

A2B攻撃への対策を調べると、どの記事も同じ3点に行き着きます。侵害の確認、脆弱性の点検、暫定的な緩和策です。情報通信研究機構（NICT）が2026年10月13日の注意喚起で挙げた順序が、そのまま引用されているためです。

この3点は、そのままでは手順書になりません。実務で詰まるのは、誰が何を持つか、何をもって終わったことにするか、そして技術対応と別の期限が同時に進むことの3つです。個人データの漏えいが疑われた場合、報告の期限は知った日から概ね3〜5日以内です。点検が終わってから数え始めるものではありません。

この記事では、A2B攻撃の対策を時間軸で分けて並べます。手口そのものの解説はA2B攻撃とはで扱っているので、ここでは対応する側の段取りだけを書きます。

この記事で扱う範囲は次のとおりです。

• 対策を3系統に分けて、同時に進める考え方
• 最初の72時間でやること。止血より先に範囲を確定する理由
• 暫定的な緩和策と、それが業務に与える副作用の対応表
• 脆弱性の点検6観点と、何をもって完了とするかの証跡
• 個人情報保護法の報告期限が、技術対応と別に走ること
• 委託先に渡す質問の型と、回答の受け取り方
• 同じ状態に戻さないための恒久対策

対策は3系統に分かれ、締め切りがそれぞれ違います

対策を一本の手順として書こうとすると、どこかで必ず止まります。技術対応、法令上の報告、設計のやり直しは、求められる速さも担当も違うためです。

この3つは同時に進めます。順番に片づけようとすると、報告の期限に間に合いません。

最初の72時間でやるのは、止血ではなく範囲の確定です

最初にアクセスを遮断したくなりますが、先に手を付けるのは範囲の確定です。何が公開されているか分からないまま遮断しても、遮断できていない経路が残ります。

やることは3つです。

• 1. 公開しているAPIとホストを列挙する。サブドメイン、停止したつもりの旧API、検証環境、クラウド上の公開ストレージを含めます
• 2. ログの保全を依頼する。確認より先に、消える前に取ることを優先します
• 3. NICTが公開したIoC（侵害の痕跡）と照合する。ただし一致しただけでは断定しません

2を1より先に回したくなる場面もあり、実際ここが分岐点になります。アクセスログやAPIログの保存期間は30日や90日で設定されていることが多く、調査の体制を整えている間に対象期間が過ぎます。ログが残っていなければ、侵害がなかったことの証明にはならず、「判定できない」という結論になります。この結論が、後述する報告の判断に直結します。

一覧化の進め方は、経済産業省が2023年5月29日に公表したASM導入ガイダンスが整理しています。外部から到達できる資産を、組織の外側から探して見つける手順です。情報システム部門が把握していない資産ほど、点検から漏れます。

暫定的な緩和策は、業務を止める副作用とセットで決めます

総務省も2026年10月の注意喚起で暫定的な緩和策を求めています。ただし緩和策はどれも業務に影響します。打つ前に、何が止まるかを決裁者が把握している必要があります。

5つに共通するのは、どれも認可不備そのものを直さないことです。WAFもレート制限も、仕様どおりの正常なリクエストは通します。緩和策は点検の時間を稼ぐためのもので、点検の代わりにはなりません。

認証情報の無効化は、引く条件を先に決めておきます

全利用者の再ログインを伴う対応は、判断が遅れがちです。漏えいの確証が出てから動けば手遅れになり、疑いの段階で引けば社内への説明が難しくなります。そこで、引く条件を先に文章にしておきます。たとえば「管理者権限のトークンが関与した形跡がある場合は、確証を待たずに全件を再発行する」といった形です。条件さえ決まっていれば、当日の判断は当てはめるだけで済みます。

脆弱性の点検は、6つの観点を分担して、証跡を残して閉じます

点検の観点は、NICTとOWASP API Security Top 10の2023年版を突き合わせると6つに整理できます。観点の数より、それぞれ何をもって完了とするかが効きます。「確認しました」という口頭の報告で閉じると、後から同じ点検をやり直すことになります。

点検で確かめるのは、権限のない操作が拒否されることです。正常系のテストをいくら増やしても、認可不備は見つかりません。実装側の確認観点は、情報処理推進機構（IPA）の安全なウェブサイトの作り方がそのまま使えます。

個人データの漏えいが疑われた時点で、別の期限が始まります

技術の対策だけを追っていると抜け落ちる部分です。個人データの漏えい、滅失、毀損が発生し、または発生したおそれがある場合、個人情報取扱事業者には個人情報保護委員会への報告と本人への通知が義務づけられています。手続きは漏えい等の対応にまとまっています。

期限は二段構えです。

• 速報：事態を知った日から概ね3〜5日以内
• 確報：知った日から30日以内。不正の目的をもって行われたおそれがある漏えい等は60日以内

A2B攻撃で注意が要るのは、報告対象の類型です。1,000人を超える漏えいは対象ですが、それとは別に、不正の目的をもって行われたおそれがある漏えい等も対象になります。こちらに人数の要件はありません。攻撃によるものだと判断した時点で、件数が少なくても報告の検討に入ります。

「おそれがある場合」が対象に含まれるため、判定できない状態は対象外を意味しません。ログが残っていれば「取得されていない」と示せますが、残っていなければ、おそれを否定できないまま報告の要否を決めることになります。最初の72時間でログの保全を最優先にする理由は、技術的な調査のためだけではありません。

漏えいの規模感も押さえておくと、社内の説明が通りやすくなります。個人情報保護委員会の令和7年度年次報告によると、個人データの漏えい等事案について処理した報告は17,139件にのぼりました。

委託先に投げるときは、回答の型を先に渡します

開発を委託している場合、点検の実務は委託先が担います。ここで起きがちなのが、依頼した時点で完了にしてしまうことです。依頼と完了の間には、何が確認できて何が確認できなかったか、という情報が要ります。

渡す質問は5項目に固定します。

• 対象範囲：どのAPIとホストを見たか。見ていないものがあれば、その理由
• 確認できた事項：拒否されることを確かめた操作と、その結果
• 未確認の範囲：見ていない部分と、見るために必要なもの（権限、環境、期間）
• 実施済みの対応：設定変更、修正、再発行のうち、すでに適用したもの
• 次に必要な判断：こちら側が決めるべきこと

この型を先に渡しておくと、回答が「問題ありませんでした」の一行で返ってくる事態を避けられます。未確認の範囲が残っている間は、対応は完了していません。

社内の分担も先に決めます。ログの保全と公開資産の一覧は運用担当、認可と入力値の検証は開発委託先、緩和策の業務影響と報告の要否は責任者、という割り当てです。緊急時に宛先を探し始めると、それだけで半日が消えます。

同じ状態に戻さないために、APIの一覧を人が維持することをやめます

一度点検を通しても、次のリリースで同じ状態に戻ります。APIは機能追加のたびに増え、認可のチェックは実装した担当者の記憶に委ねられるからこそ、抜けが再発します。恒久対策は、この依存を外す作業です。

手を付ける順に4つあります。

• 1. APIの一覧を自動で作る。仕様定義から生成するか、外部から到達できる資産を定期的に発見する仕組みに寄せます。手で更新する台帳は必ず古くなります
• 2. 認可のテストを自動化する。「他人のIDを指定したら拒否される」を、リリースのたびに機械が確認する状態にします
• 3. 権限の判定と計算をサーバ側に集約する。価格、残高、付与数、権限の可否をクライアントに置かない設計にします
• 4. 旧APIの廃止手順を決める。停止予定日、告知、アクセス元の制限、停止、という流れを運用に組み込みます

1と2が入れば、点検は年に一度の行事から日常の確認に変わります。3は設計の話なので時間がかかります。ただ、ここに手を付けない限り、同じ対応を繰り返すことになります。

情報処理推進機構（IPA）が2026年1月29日に公表した情報セキュリティ10大脅威 2026では、組織向けの3位に「AIの利用をめぐるサイバーリスク」が入りました。解析と探索にかかる時間が短くなる前提に立つと、点検の周期は従来より詰める必要があります。

ライブサービスでは、対策の効き目を運営指標で確かめます

ゲームやライブ配信、ECのように、サーバ側で数値が動くサービスには、もう1つの確認経路があります。スコアの書き換え、条件を満たさないアイテムの付与、クーポンやポイントの不正取得、課金判定の回避は、セキュリティのログより先に運営の指標に現れます。

対策を打ったあとに異常が止まったかどうかは、行動データ側を見れば分かります。到達し得ない値、不自然な操作間隔、特定のアカウントに偏った分布を、サーバ側の記録から継続的に拾う運用です。1回の検知で処分を決めず、複数の根拠と人の確認を挟む手順も併せて決めておきます。異常の原因を分解していく進め方は、データ分析AI Agentの記事とAIエージェントのユースケース12選で扱っています。

監視をAI Agentに任せるなら、そのAgentの権限も対策の対象になります

異常の監視を自動化する場合、Agentが業務データとサーバのログに触れます。その接続先と権限が、新しい点検対象になります。外部のサービスへログを送る構成を選べば、公開APIを1つ増やしたときと同じ検討が必要です。

ThinkingAIの企業向けAI Agentプラットフォーム「Agentic Engine」は、オンプレミス型のセルフホストレイヤーとして顧客自身の技術環境内でご利用いただけます。顧客データはすべて自社環境内に保持されます。権限まわりでは、ロールベースアクセス制御（RBAC）、データアクセスレベル設定、機密操作の承認フロー、マルチアカウント分離管理、ユーザー操作履歴監査をGovernance Studioで一元的に扱えます。Agentごとに、参照できるデータと実行できるアクションを分けて設定する考え方です。外部システムとの接続はMCPに準拠し、OAuth 2.0による認証と権限管理、監査を前提にしています。

操作履歴が自社側に残るため、恒久対策の4項目でいう「誰が何をしたか」の記録を、別の仕組みで作り直す必要がありません。AI Agent自身のID管理という論点はSSOとAIの関係で、AIを閉じた環境で動かす構成は生成AIをクローズド環境で使う3つの構築方式とオフラインAIの選び方で整理しています。

対策の出来は、平時に決めておいた項目でほぼ決まります

ここまで書いた手順のうち、当日になってから決められるものはほとんどありません。ログの保存期間、報告を判断する人、緩和策で止まる業務の範囲、委託先との連絡窓口。いずれも平時に決めておく項目です。

NICTは個別システムの診断や技術相談を受け付けていません。点検の実務は、社内の担当者、開発・運用の委託先、セキュリティ専門事業者のいずれかに割り当てることになります。割り当て先が決まっていない状態から始めると、最初の72時間が窓口探しで終わります。手口そのものの仕組みはA2B攻撃とはにまとめているので、社内で共有する資料が必要なときはそちらをお使いください。