>
>
公開日
A2B攻撃の定義と、アプリやAPIを公開する事業者が優先する対応を解説します。NICT・総務省の注意喚起を軸に、侵害確認、脆弱性点検、暫定的な緩和策の順序、サーバ側の防御、開発・委託先・情シスの担当分界を整理。アプリ側の対策だけで終わらせない判断材料を示します。情報は2026年10月22日時点です。
A2B攻撃とは
A2B攻撃とは、公開アプリを解析してAPIの接続先や仕様を割り出し、バックエンドサーバを狙う攻撃です。APIはアプリとサーバが情報をやり取りするための窓口で、バックエンドサーバはデータの保存や処理を担う裏側のサーバを指します。
本記事のポイント
公開アプリの解析を起点にバックエンドが狙われます。
対象はアプリやAPIを公開する事業者です。
侵害の確認と脆弱性の点検を優先します。
開発・委託先・情シスの担当分界を明確にします。
対象読者は、アプリやAPIを公開する事業者の情報システム部門の担当者・管理者です。APIへの攻撃やバックエンドへの攻撃を、アプリ開発だけの問題として扱わず、自社サービスの接続関係と運用体制から捉えます。対応の入口となるのは、公開アプリがどのAPIにつながり、誰がサーバを管理しているかという整理です。攻撃の再現方法ではなく、対象範囲、侵害確認と点検の優先順位、開発・委託先・情シスの責任分担を整理します。
国立研究開発法人情報通信研究機構（NICT）の脅威情報分析チームLETTICEは、2026年10月13日付のプレスリリースでA2B攻撃（App-to-Backend Attack）への注意喚起を公表しました。詳細資料（PDF）によると、攻撃者はGoogle Playの日本地域で公開されているAndroidアプリを入手・解析し、接続先、APIの構成、通信のパラメータを調べたうえで、サーバごとに攻撃内容を変えています。NICTは、国内で相次ぐ情報漏えい事案の原因の一つとしてこの手法を挙げ、AIによって解析や脆弱性探索が効率化され、より多くのシステムに攻撃が及ぶおそれがあるとしています。
認証なしで呼べるAPIだけでなく、ログイン後に使うAPIも攻撃対象になります。同じ問題はiOSアプリやWebサービスのバックエンドでも起こり得るとNICTは指摘しており、総務省の続報も、アプリ自体に脆弱性がなくてもサーバ側の脆弱性が悪用されるおそれがあると伝えています。
情報は2026年10月22日時点です。
▲ 公開アプリの解析からバックエンドサーバへ至るA2B攻撃の構造。
対象となるアプリ・API公開事業者
アプリやAPIを公開する事業者は、アプリ本体だけでなく接続先のサーバも対応範囲として捉えます。対象を整理する際は、利用者の端末の種類だけで区切らず、自社が公開するアプリ・Webサービスと、接続先APIの管理主体を組み合わせて整理します。
Android・iOS・Webサービスの対象範囲
Androidアプリを提供していない事業者も、iOSアプリやWebサービスの接続先を確認対象に含めます。総務省は、総務省によるA2B攻撃の続報で、同様の問題がAndroid以外でも発生する可能性を注意喚起しています。また、アプリ自体に脆弱性がない場合でも、サーバ側の脆弱性が悪用され、情報漏えい等につながるおそれがあると説明しています。
アプリとバックエンドの管理範囲
自社で対応範囲を整理する際は、公開アプリとバックエンドの管理主体を分けて記録します。バックエンドとは、アプリからの要求を受けて処理するサーバ側の仕組みです。アプリ名だけの一覧ではなく、接続先API、サーバ側の管理主体、調査結果を受け取る担当を対応づけます。自社管理ならサーバ側の確認担当を、委託先管理なら結果を受け取る窓口を定める形にすると、アプリ担当だけで対応を完結させる取り違えを避けられます。
体制を決める際は、次の表を公開アプリ・Webサービスごとの整理に使います。技術的な対策の選定に進む前に、誰がサーバ側の確認を担い、誰が結果を把握するかを明確にするための区分です。
条件 | 対応範囲 | 読者側で定める担当・窓口 |
|---|---|---|
自社で接続先APIを管理している場合 | 公開アプリに加え、自社管理のAPIと接続先サーバを確認対象に含めます。 | サーバ側の確認担当を定め、アプリ担当と結果を共有する体制にします。 |
委託先が接続先APIを管理している場合 | 委託先が管理するAPIとサーバも、調査状況を把握する対象に含めます。 | 委託先から調査結果と対応状況を受け取る自社の窓口を定めます。 |
管理主体が分かれば表の区分に沿って担当を置き、分からなければアプリの管理担当を起点に接続先と管理主体を整理します。委託しているという理由だけで、自社の確認範囲から除外しない運用にします。
複数のアプリやAPIがある場合の着手順は、次の4点で判断します。
公開資産の重要度：停止や改ざんが売上・主要業務に直結するAPIから先に点検します。
データの機密性：個人情報や決済関連情報を扱うAPIは、侵害確認の対象に先に入れます。
外部公開と認証の有無：インターネットから認証なしで呼べるAPIは、緩和策の検討も並行して始めます。
ログの保全期間：保存期間が短いシステムは、記録が上書きされる前に取得を依頼します。
対象となり得ることと、侵害が確認されたことは別です。アプリやAPIを公開しているだけで「侵害済み」と扱わず、対象範囲の一覧と調査結果を分けて管理します。これにより、未調査の接続先を安全とみなすことも、調査前に被害を断定することも避けられます。
▲ 接続先APIの管理主体に応じた対応範囲と担当窓口の比較。
NICTの対応順序と優先事項
NICTの詳細資料は、Androidアプリを公開する事業者に推奨する対策を「（1）侵害の確認」「（2）脆弱性の点検」「（3）暫定的な緩和策」の順に示し、早急に実施するよう求めています。（1）と（2）には「優先的に」とあります。（3）は「業務への影響を考慮しながら、必要に応じて」実施するものとされているため、制限できるものは（1）（2）と並行して進めます。
対応段階 | 着手時点 | 実施内容 | 確認材料 | 次の判断 |
|---|---|---|---|---|
（1）侵害の確認 | 着手直後 | 公開APIとホストを列挙し、2026年8月以降のログを調べる | 公開ホスト一覧、アクセスログ・APIログ・認証ログ、IoC | 不審なアクセスがあれば影響範囲を調べる。ログがない期間は未確認として残す |
（2）脆弱性の点検 | （1）と並行 | NICTが挙げる6つの観点で、APIと公開ホストを点検する | 点検結果、修正対象 | 問題があれば修正と再点検へ。未点検の箇所は解消済みに含めない |
（3）暫定的な緩和策 | 制限の対象と業務への影響を判断できた時点 | 不要なアクセス元の制限、不要なAPI・検証環境の停止、レート制限・WAF | 変更内容、適用範囲、業務への影響 | 緩和策を入れても（1）（2）は続ける。リスクを下げきれなければ一時停止を検討する |
表の「着手時点」と「次の判断」は、資料の推奨を社内の進め方に落とし込むための編集部の提案です。
侵害の確認
NICTは、次の範囲と観点で侵害の有無を確認するよう求めています。
対象：アプリが使うAPIに加え、サブドメイン、旧バージョンのAPI、検証環境、クラウド上の公開サービス
期間：2026年8月以降のアクセスログ、APIログ、認証ログ。可能であればそれ以前も
照合：資料に掲載されたIoC（IPアドレス、User-Agentなど）との一致
兆候：認証なしでの大量の情報取得、連番IDを使ったアクセス、他の会員情報の閲覧・変更、認証トークンの不審な発行、管理機能の利用
不審なアクセスが見つかった場合は、認証の成否、アクセスされたデータ、情報の取得・変更、認証情報の悪用の有無と範囲を速やかに調べます。IoCと一致しただけでは侵害を断定できないとNICTは注意しており、ログや通信内容と合わせて判断します。
ログの保存期間が短いシステムでは、8月分がすでに残っていないことがあります。取得できなかった期間はシステムごとに記録し、「侵害なし」ではなく「未確認」として扱います。
脆弱性の点検
NICTによると、今回の攻撃で主に探索・悪用の対象になったのは次の4種類です。
SSRF：外部からのリクエストで、サーバに本来意図しない通信をさせる脆弱性。内部システムやクラウドのメタデータにアクセスされるおそれがあります。
RCE（リモートコード実行）：外部からサーバ上で不正なコマンドやプログラムを実行できる脆弱性。
SQLインジェクション：APIなどへの入力を通じて、データベースに不正なSQL処理を実行させる脆弱性。
IDOR（BOLA）：識別子を指定するときの権限確認が欠けている脆弱性。リクエスト中のIDを変えるだけで、他の利用者の情報を取得できてしまいます。
点検の観点として、資料はこの4種類を含む次の6つを挙げています。
観点 | 確認すること |
|---|---|
認可不備（IDOR/BOLA） | 会員IDなどの識別子を変えて、他者や他テナントの情報を閲覧・変更できないか |
認証・セッション管理の不備 | 認証トークンの不正発行・偽造、認証回避ができないか。固定された認証情報や暗号鍵が露出していないか |
SQL・NoSQLインジェクション | 外部入力を介して、データベースの情報を取得・変更できないか |
SSRF | URL取得、画像処理、文書変換などの機能から、内部ネットワークやクラウドのメタデータサービス、ローカルファイルに到達できないか |
クラウドサービス・ストレージの設定不備 | S3、GCS、Firestoreなどに、認証なしや本来の権限外でアクセスできないか |
コード実行・ファイル操作 | 危険なデシリアライズ、任意ファイルの書き込み・上書き、不適切な管理機能の公開がないか |
暫定的な緩和策
NICTが挙げる緩和策は次のとおりです。
国外からのアクセスや、不要なアクセス元からの通信を一時的に制限する
不要な公開API、管理機能、検証環境へのアクセスを停止・制限する
アクセス頻度や連続した識別子の指定を監視し、必要に応じてレート制限やWAFでアクセスを制御する
認証情報やトークンの漏えい・悪用が疑われる場合は、無効化・再発行する
脆弱性が見つかったら速やかに修正します。すぐに直せない場合や、重大な脆弱性の有無を確認できず、暫定的な制限でもリスクを許容できる水準まで下げられない場合は、該当するAPIや機能、必要に応じてサービス全体の一時停止を検討するようNICTは求めています。
緩和策を入れたことと、侵害の有無や脆弱性の解消を確認したことは別の事実です。対応票では「緩和策の適用状況」「侵害確認の結果と未確認範囲」「脆弱性の修正・再点検結果」を別の欄にします。
▲ NICTの注意喚起に基づく対応手順と優先事項。
防御設計の論点
恒久的な対策についてNICTは、攻撃者がアプリを介さずにAPIを直接操作できることを踏まえ、アプリ側の制御だけに頼らず、バックエンドサーバ側で認証・認可や入力値の検証を行うことが重要だとしています（NICTの詳細資料）。公開アプリが解析されること自体を完全に防ぐのは難しいためです。APIの接続先を隠すことや、アプリの難読化だけでは対策になりません。
以下の4つの論点は、資料が挙げる点検の観点と緩和策をもとに、設計の見直しで決めることを編集部が整理したものです。
秘密鍵・長く有効な認証情報の管理
NICTは点検の観点に「固定された認証情報や暗号鍵が露出していないか」を含めています。配布するアプリに秘密鍵や長く有効な認証情報を埋め込んでいる場合は、サーバ側で保持する構成に見直します。署名の検証に使う公開鍵のように、配布しても問題のない鍵とは分けて扱います。認証情報には利用範囲と有効期間を設け、漏えいが疑われたときにすぐ無効化・再発行できるようにしておきます。
サーバ側の認証・認可
認証は利用者を識別する仕組み、認可はその利用者にデータや操作の権限があるかを判断する仕組みです。今回悪用されたIDOR/BOLAは認可の不備にあたります。レビューでは次の3点を確認します。
オブジェクト単位：他の利用者のIDを指定した参照・更新を拒否できるか
機能単位：管理機能や更新系のAPIを一般利用者が呼べないか
テナント境界：他の組織のデータに到達できないか
ログイン済みであることを、すべてのデータ操作を許可する理由にはしません。
レート制限と監視
NICTは緩和策として、アクセス頻度や連続した識別子の指定を監視し、必要に応じてレート制限やWAFでアクセスを制御することを挙げています。連番IDで情報を集める攻撃は、要求数と識別子の並びに表れます。恒久的に入れる場合は、通常の利用を妨げない上限値と、アラートを受けて対応する担当を決めておきます。レート制限は攻撃の速度を落とすもので、認可の不備を直すものではありません。
SSRFへの対策
SSRFは、URL取得、画像処理、文書変換のように、外部から受け取った情報をもとにサーバが通信する機能で起こります。対策は、許可する宛先を検証すること、名前解決後のアドレスが内部ネットワークやメタデータサービスでないか確かめること、サーバから外へ出る通信をネットワーク設定で制限することの3つです。入口のアクセス制御だけでは、サーバから先の通信は守れません。
設計レビュー用のチェック項目
配布アプリに秘密鍵や長く有効な認証情報を含めていないか。含めている場合、無効化・再発行の手順があるか
データ・操作ごとの権限判断をサーバ側で行っているか
要求数の上限と、監視アラートの対応担当を決めているか
サーバが通信する宛先と範囲を制限しているか
クラウドストレージやデータベースに、認証なしでアクセスできる設定が残っていないか
開発・委託先・情シスの担当分界
責任があいまいになりやすいのは、侵害の確認、修正、対応状況の集約の3つです。作業をする担当と、結果を受けて次の対応を決める担当を分けて決めます。
次の表は割り当ての例で、法令などで決められた体制ではありません。実際の管理権限と契約の範囲に合わせて変えてください。
対応事項 | 実施担当 | 判断担当 | 受け渡す情報 |
|---|---|---|---|
侵害の確認 | 調査対象を管理する開発部門・委託先 | 社内のインシデント対応の責任者 | 対象範囲、確認結果、根拠、未確認範囲 |
脆弱性の点検 | 仕様・実装を調べられる開発部門・委託先 | 修正を判断する社内の責任者 | 点検結果、修正対象、追加で調べること |
暫定的な緩和策 | 設定を変更する権限を持つ担当 | 業務への影響を判断できる社内の責任者 | 実施内容、適用範囲、業務への影響、残る課題 |
開発部門の担当範囲
開発部門は、自分たちで管理している範囲の調査と修正、修正後の確認を受け持ちます。実装を変更できるのが委託先だけの場合は、対象と修正の条件を整理して委託先に渡します。
修正結果を報告するときは、変更箇所だけでなく、確認した範囲と残る課題も添えます。変更は反映したが確認が終わっていないものは「修正済み・確認待ち」とし、完了とは分けて記録します。
委託先の担当範囲
委託先には、契約範囲に含まれる調査・修正と、その結果の報告を依頼します。依頼するときに対象を明示し、回答は次のテンプレートで受け取ります。
対象範囲：調査したシステム、機能、期間
確認できた事項：判明した事実と判断の根拠
未確認の範囲：調べていない対象と、調べられなかった理由
実施済みの対応：調査・修正・緩和策の内容と結果
次の判断：社内で決めてほしいことと、追加調査の担当・回答予定
契約の範囲外や権限不足で調べられない部分は、未確認として残し、社内で別の調査担当を決めます。
情シスの担当範囲
情シスは、各担当からの回答を一つの共有表にまとめ、未対応のものと判断待ちのものを責任者に渡します。設定を変更する権限がない場合も、進捗管理と情報の集約は受け持てます。
侵害の兆候が見つかったら、確認結果と根拠を添えて社内のインシデント対応体制に引き継ぐ
判断材料が足りないものは、未確認範囲、追加調査の担当、回答予定を共有表に書いて「判断待ち」にする
回答を受け取った時点で閉じず、責任者が次の対応を決めるまで記録を残す
委託先に依頼したことは、対応が終わった根拠になりません。調査・修正の結果を共有表で突き合わせ、対象の抜けや未確認の範囲がないかを確かめてから完了にします。
対策の取り違えと対応時の失敗パターン
注意喚起の内容から考えられる、対応でつまずきやすいパターンを3つ挙げます。実際の被害事例ではありません。
アプリ側の点検だけで終える
アプリに問題が見つからなくても、サーバ側は点検対象に残します。A2B攻撃は、アプリ自体に脆弱性がなくても、バックエンドのAPIに認証・認可や入力値の検証の不備があれば成立します（総務省の続報）。アプリの調査結果を受け取ったら、接続先のサーバまで調べたかを確認します。
緩和策を入れて終える
アクセス制限を入れても、過去に侵害されていないかと、脆弱性が残っていないかは分かりません。制限の記録とは別に、侵害の確認と点検の結果を残します。制限が正規の利用を妨げていると分かった場合は、条件を見直します。
委託先への依頼で終える
「問題なし」という回答でも、調査対象と根拠が示されていなければ全体の安全は確認できていません。たとえば「アプリを調査して問題なし」という回答で、接続先のAPIサーバが対象に入っていなかった場合は、サーバ側を未点検として残します。ログの保存期間が短いなら、点検より先にログの保全を依頼します。
パターン | 残っている未確認事項 | 正しい扱い |
|---|---|---|
アプリ側の点検だけで完了 | サーバ側の脆弱性 | サーバ側を点検対象に残す |
アクセス制限だけで完了 | 過去の侵害の有無、脆弱性 | 緩和策とは別に、それぞれの結果を記録する |
委託先への依頼だけで完了 | 回答の対象外・未調査の範囲 | 未確認の範囲が残る間は完了にしない |
まとめ
A2B攻撃への対応は、公開しているアプリとAPI、検証環境まで含めて一覧にするところから始まります。次に、2026年8月以降のログで侵害の有無を確かめ、NICTが挙げる6つの観点でサーバ側を点検します。並行して、業務への影響を見ながら不要なアクセスを制限します。対策の詳細とIoCはNICTの詳細資料（PDF）で確認してください。
まとめ
最初の一歩は、公開しているAPI・ホスト・検証環境を一覧にし、2026年8月以降のログを確認する担当者を決めることです。
総務省が公表したNICTの注意喚起は、侵害の確認、脆弱性の点検、暫定的な緩和策の3つを推奨し、前の2つを優先するよう求めています。
公開アプリと接続先APIの管理担当が明らかなら、その担当へ侵害の確認と脆弱性の点検を割り当てます。
管理担当が不明なら、情シスが開発・委託先との連絡窓口を決めます。
担当を決めた後は、確認・点検の着手状況と緩和策の実施担当を共有し、対応の抜けを残さないようにします。
社内展開には、本記事の担当分界の表と委託先からの回答テンプレートを、そのまま共有表として使えます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
