A2B攻撃をAWSで守るきめ細かい闘い方 ― アプリの裏のAPIを、時間軸で守る

Webサイトの画面は、デザインもセキュリティも人目につくぶん、しっかり作り込まれていることが多いですよね。ところが、スマホアプリの裏で動いているアプリ向けAPIはどうでしょうか。

「どうせアプリからしか呼ばれないから」「ユーザーには見えないから」と、入力値のバリデーションが甘かったり、認証がAPIキー1本だけの簡素なものだったり、返すデータの絞り込みが雑だったり。僕自身、いろいろな現場を見てきて、表に出ないAPIほどセキュリティがおろそかになりがちだと感じています。

でも攻撃者から見れば、アプリは中身を開けられる「設計図付きの入口」です。そして本当に守るべき顧客データや決済、業務ロジックは、そのAPIの向こう側にあります。だからこそ、APIこそしっかり作り込みましょう。これが今回いちばん伝えたいことです。

そんな「表に出ないAPI」を狙う攻撃に、昨日（2026年10月13日）名前が付きました。情報通信研究機構（NICT）のサイバーセキュリティネクサス（CYNEX）が、「相次ぐ情報漏えい、その原因の一つは『アプリ解析からのサーバ攻撃』」という注意喚起を出し、この攻撃を「A2B攻撃」と名付けました。A2BはApp-to-Backendの略で、公開されているアプリを解析して接続先のサーバーやAPIの仕様を割り出し、その裏にあるバックエンドの弱点を突く攻撃のことです。NICTの注意喚起は、アプリ自体に脆弱性がなくても、サーバー側の認証や認可に不備があれば情報漏えいにつながると書いています。対象はAndroidアプリを例にしていますが、iOSアプリやWebのバックエンドAPIでも同じことが起こりえます。

僕はふだんAWSでのインフラ構築やAIシステムの設計をしていますが、この攻撃は「アプリ側の問題」に見えて、実はAPIとインフラの設計でしか本当には守れないタイプの攻撃だと感じています。今回は、A2B攻撃の手口と、AWSで運用しているサービスが実際に攻撃されたとき、どのサービスが・どうやって・どのタイミングで働くのかを整理します。新人エンジニアの方にも読めるよう、用語には（→ 注釈）を付けました。

※2026年10月14日時点の公開情報に基づきます。AWSの各サービスの機能や料金は頻繁に更新されるので、導入時は公式ドキュメントで最新情報を確認してください。本文の構成と時間軸は設計の考え方を示す例で、特定の環境で計測した数字ではありません。

なぜ今、A2B攻撃が増えているのか

一番大きいのは、AIによって解析のコストが激減したことです。

Digital.aiが2026年5月に出した「2026 Application Security Threat Report」では、同社が監視しているクライアント向けアプリのうち攻撃を受けたものの割合が、2022年の55%から2026年には87%に上がっています。ある顧客のアプリは、ストアに公開されてから1時間56分で最初の攻撃を受けたそうです。平均ではなく1件の事例ですが、「公開したらすぐ狙われる」と考えておくには十分な数字です。以前は専門チームが何週間もかけていたアプリの解析が、今はLLMのサブスク1つで午後のうちに終わってしまう。僕の感覚もこちらに近いです。

さらに、AIを使ったデコンパイル（→ アプリの実行ファイルを人が読めるコードに戻すこと）や動的解析で、難読化（→ コードをわざと読みにくくする処理）されたアプリからもAPIの仕様が抜き出せるようになってきました。「難読化しているから大丈夫」という前提は、もう通用しません。

A2B攻撃の典型的な手口

攻撃者にとってアプリは目的地ではなく入口です。流れを図にすると次のようになります。

一つずつ見ていきます。

1. 静的解析：アプリを展開・デコンパイルし、LLMに関数を説明させながら、APIのエンドポイントやパラメータ、署名の仕組みを洗い出す
2. 秘密情報の抜き取り：アプリ内に埋め込まれたAPIキーを抜き、外部サービス（決済・地図・LLM APIなど）を不正利用する。Cybernewsが2025年に公表したiOSアプリ約15.6万本の調査では、71%に秘密情報がハードコード（→ コードに直接書き込まれた状態）されていました
3. 通信の傍受・改ざん：端末に独自の証明書を入れ、通信を盗み見たり書き換えたりする（いわゆるMitM＝中間者攻撃）
4. 正規アプリへのなりすまし：アプリ内の署名ロジックを再現し、アプリを使わず直接APIを叩く
5. APIの脆弱性を突く（ここが本丸）
   • BOLA/IDOR（→ URLやパラメータのIDを書き換えるだけで他人のデータが見えてしまう脆弱性）
   • 過剰なデータ返却：画面には出ていない項目までAPIが返してしまっている
   • 認可をアプリ側で判定している：「有料会員かどうか」をアプリが判断していて、改ざんで突破される
   • 古いAPIの放置：旧バージョンのアプリのために残したエンドポイントは保護が甘いことが多い
6. 自動化・Bot化：通信の仕組みを解析し尽くすと、アプリなしでスクリプトから大量にリクエストを送れるようになる。リスト型攻撃、データの抜き取り、クーポン不正などに使われます

⑤に並べたものは、OWASPのAPIセキュリティTop 10（2023年版）の項目にそのまま対応します。IDの書き換えはAPI1（Broken Object Level Authorization）、余計な項目の返却はAPI3（Broken Object Property Level Authorization。2019年版の「過剰なデータ露出」を含む）、古いAPIの放置はAPI9（Improper Inventory Management）です。NICTの注意喚起も、重点的に点検する対象の筆頭にIDOR/BOLAを挙げています。ちなみにSPAやLINEのLIFFアプリのように、JavaScriptがそのままブラウザに配られるものは、最初から中身が丸見えです。ネイティブアプリと同じ前提で考える必要があります。

守り方の基本方針

僕が一番伝えたいのはこれです。

アプリは信頼しない。難読化には頼らない。判断は全部サーバー側でやる。

その上で、AWSのサービスを「時間軸」で並べると、どこで何が効くのかがよく見えてきます。

前提となる構成と、各層で効くサービス

よくある構成を例にします。アプリ → CloudFront（→ 世界中に置かれた配信用の中継サーバー。CDN） → AWS WAF（→ 怪しいリクエストを入口で弾くファイアウォール） → ALB / API Gateway（→ リクエストを裏のサーバーに振り分ける受付窓口） → ECS Fargate（→ サーバー管理不要でコンテナを動かす仕組み） → RDS（→ AWSが管理してくれるデータベース）、という流れです。

サービスの名前が一度にたくさん出てくるので、先にどの層で何が守っているかを1枚にまとめておきます。

この図で赤くした層が、後半の話の伏線になります。

AWSで見た「攻撃の時間軸」と各サービスの役割

同じサービス群を、攻撃を受けてからの経過時間で並べ直します。時間はあくまで目安で、ログの配信遅延や設定によって前後します。

① 公開前（予防）

• Cognito（→ ログイン・会員管理のサービス）：アクセストークン（→ ログイン済みを示す一時的な通行証）を短命にし、PKCE（→ 通行証の横取りを防ぐログイン手順の仕組み）を使う。アプリ内に秘密の鍵を置かない
• Secrets Manager（→ パスワードやAPIキーを安全に保管する金庫）：外部APIのキーはサーバー側だけに置き、アプリは自社サーバー経由で呼ぶ
• Verified Permissions（→ 「誰が何にアクセスしてよいか」を判定する専用サービス）：Cedar（→ その判定ルールを書く言語）で、BOLAを設計段階で潰す。API Gateway（REST API）向けには、Cognitoと組み合わせた検問用のLambdaオーソライザーを自動で作る機能もあります
• Lambdaオーソライザー（→ リクエストを通す前に小さなプログラムで検問する仕組み）＋アテステーション（→ 「本物の改ざんされていないアプリ・端末か」をGoogle/Appleに証明してもらう仕組み。Play Integrity／App Attest）
• Inspector（→ 脆弱性の自動検査サービス）：ECR（→ コンテナイメージの保管場所）のイメージを検査

② 0〜1秒（リクエスト単位で即時遮断）

• AWS WAF
  • レートベースルール（→ 一定時間に回数を超えたら遮断するルール）：IPやユーザー単位で連打を止める
  • Bot Control（Targeted）：WAFのSDK（→ アプリに組み込む部品）が発行する証明トークンがないリクエスト、つまりアプリを使わず直接叩いているプログラムを弾く。A2B対策の中核です。ただし初期設定のままでは弾きません。トークンなしを見るルール（TGT_TokenAbsent）の既定の動作は記録（Count）だけなので、ルールグループの直後に「トークンなし」のラベル（awswaf:managed:token:absent）が付いたリクエストをBlockする独自ルールを置く必要があります
  • ATP／ACFP（→ ログイン悪用・アカウント大量作成の対策機能）：クレデンシャルスタッフィング（→ 他所で漏れたID/パスワードを大量に試す攻撃）を、漏えい済みの認証情報のデータベースと照らし合わせて検知。ログイン画面を自前で持つAPI向けで、Cognitoのユーザープールには使えません
  • マネージドルール（→ AWSが用意・更新してくれる既製の防御ルール集）
• API Gatewayのスロットリング（→ 1秒あたりの受付件数の上限設定）
• Shield（→ DDoS＝大量アクセスでサービスを落とす攻撃への防御）

③ 1〜5分（アラート）

• CloudWatch（→ AWSの監視サービス）のメトリクス（→ 数値の推移データ）＋異常検知アラーム：遮断数や4xx/2xx（→ HTTPの応答コード。4xxは拒否・エラー、2xxは成功）の比率の急変を通知
• Contributor Insights（→ ログから「上位N件の多い人・IP」を自動集計する機能）：アプリの構造化ログから、注文APIを叩いた回数が多いユーザーを常時ランキングする。ゆっくりしたID書き換え攻撃をWAFより先に捉えられる数少ない手段です（具体的な書き方は後のシナリオで）
• CloudWatch Logsの異常検知（→ ログのパターンがいつもと変わったら知らせる機能）：アプリのエラーログなどに新しいパターンが出たら知らせる。公式のFAQでは、アクセスログやVPCフローログには向かないとされているので、API悪用の検知はContributor Insightsのほうに任せます

④ 5〜15分（侵入後の兆候を検知）

• GuardDuty（→ AWS上の不審な動きを機械学習で検知するサービス）：ここで分かるのは「突破された後」の兆候です
  • Runtime Monitoring（→ 動いているコンテナ内部の監視）：不審なプロセスや通信
  • RDS Protection：Aurora（→ RDSの高性能版DB）への異常なログイン
  • IAM（→ AWSの権限・アカウント管理）の認証情報の不正利用
• Security Hub（→ 各種セキュリティ検知を一か所に集める管理画面）

⑤ 15分〜1時間（自動封じ込め）

• EventBridge（→ 「何かが起きたら次の処理を動かす」イベント配線係） → Lambda（→ 必要な時だけ動く小さなプログラム）／Step Functions（→ 複数の処理を手順通りに実行する仕組み）で自動対応
  • WAFのIPセット（→ 遮断対象IPのリスト）に追加
  • Cognitoの AdminUserGlobalSignOut（→ そのユーザーの通行証を全部無効にする命令）。注意点が一つあります。失効したアクセストークンを拒否するのはCognito自身のAPIなどに限られ、署名と有効期限だけを確かめる自前のバックエンドでは、期限が切れるまで通ってしまいます。アクセストークンを短命にしておく理由はここにもあります
  • キーのローテーション（→ 新しい鍵に交換し、古い鍵を使えなくする）
  • 該当APIを一時的に503（→ 「現在利用できません」応答）にする
• Slackなどに通知し、誤遮断の恐れがある操作だけ人間が承認する

⑥ 1〜24時間（調査）

• Detective（→ IP・ユーザー・リソースのつながりを図で追える調査ツール）
• Athena（→ 保存したログにSQLで直接検索をかけるサービス）、CloudTrail Lake（→ 「誰がAWSで何を操作したか」の記録を検索する機能）
• Bedrock（→ AWSで生成AIを使うサービス）でログの要約、攻撃パターンの分類、被害ユーザーの抽出
• Macie（→ S3＝ファイル保管庫の中の個人情報を見つけるサービス）で持ち出し対象を確認
• AWS Security Incident Response（→ AIエージェントによる初期調査と、AWSの専門対応チーム（CIRT）への相談窓口）。2025年11月から従量課金になり、月1万件までの検出結果は無料です

⑦ 数日〜（根本対策）

• 認可漏れの修正、レスポンス項目の削減、古いAPIの廃止
• 攻撃パターンを回帰テスト（→ 修正後に同じ問題が再発していないか毎回確かめる自動テスト）に組み込む

実際のシナリオで考えてみる

「アプリからAPIキーと署名ロジックを抜かれ、/api/orders/{id} のIDを1秒に1件ずつ書き換えて他人の注文を見ていく」というケースを想定します。1秒に1件なら1時間で3,600件。派手さはありませんが、一晩で相当な数の注文が覗かれます。

表にまとめると次のとおりです。

つまり、WAFとGuardDutyは「大量アクセス」と「侵入後」には強いけれど、正規っぽくゆっくりした認可破りには弱い。だからこそ、アプリ側で「誰が・どのIDに・どのAPIで」アクセスしたかを構造化ログとして残しておくことが、僕は一番大事だと考えています。

ログに何を残し、どう数えるか

API本体からは、たとえば次のような1行のJSONをCloudWatch Logsに出します。ポイントは、ルート（/api/orders/{id}のような型）と、実際に触ったID、それを触ったユーザーを分けて持つことです。

{"ts":"2026-10-14T02:13:05Z","userId":"u-8812","route":"/api/orders/{id}","orderId":"100423","ownerMatch":true,"status":200}

Contributor Insightsは、キーごとの件数（Count）か合計（Sum）を数える仕組みで、「何種類のIDを触ったか」というユニーク数は数えられません。そこで常時の見張りは「注文APIを叩いた回数が多いユーザー」のランキングにして、怪しい人が浮いたらLogs Insightsでユニーク数を確かめる、という二段構えにします。Contributor Insightsのルールは次のような形です。

{
  "Schema": { "Name": "CloudWatchLogRule", "Version": 1 },
  "LogGroupNames": [ "/app/api" ],
  "LogFormat": "JSON",
  "Contribution": {
    "Keys": [ "$.userId" ],
    "Filters": [ { "Match": "$.route", "In": [ "/api/orders/{id}" ] } ]
  },
  "AggregateOn": "Count"
}

浮いたユーザーについては、Logs Insightsで触ったIDの種類を数えます。

filter route = "/api/orders/{id}"
| stats countDistinct(orderId) as ids by userId
| sort ids desc
| limit 20

ふつうの利用者が見る自分の注文はせいぜい数件から数十件なので、1時間で数百種類という数字は目立ちます。認可チェックを入れたあとなら、ownerMatchがfalse（他人のIDを指定して403になった）の件数を数えるだけでも、ID書き換えを試している人が分かります。なお、ここに載せたルールとクエリは考え方を示すための例で、僕の環境でデプロイして検証したものではありません。countDistinctは種類が多いと近似値になる点にも注意してください。

防御側こそAIを使う

攻撃側がAIで解析を加速しているなら、守る側もAIを使わない手はありません。僕が効果的だと思うのは次のような使い方です。

• 自社アプリを先にAIで解析する：CIで自社のアプリやJSバンドルをLLMと解析ツールにかけ、攻撃者と同じ目線で秘密情報やエンドポイント、認可漏れをリリース前に見つける
• AIによるAPI振る舞い分析：ユーザーごとのアクセスの流れを学習し、IDの連番走査や、通常の画面操作では起きない呼び出し順を検知する
• API仕様と実トラフィックの差分監査：OpenAPIの定義と実際のログをLLMで突き合わせ、誰も把握していない古いAPIを洗い出す
• 認可テストの自動生成：エンドポイントごとに「他人のIDでアクセスしたらどうなるか」のテストケースをLLMに作らせ、回帰テスト化する
• アラートの要約と初動の自動化：WAFやAPI Gatewayのアラートを生成AIで相関・要約し、トークン失効やレート制限の発動まで自動で繋ぐ

ログを判定するAIの使い方は、Webサーバーのログ監査をJevに任せる記事でも書いています。検知の後に誰がどこまで自動で直すかは、AWSの自動修復はどこまで任せられるかが続きの話になります。

優先順位をつけるなら

費用対効果で並べると、僕なら次の順に手をつけます。

1. サーバー側の認可（BOLA対策）
2. アプリ内の秘密情報の撤廃
3. アテステーションとWAF Bot Control
4. アプリログ＋Contributor Insights＋AIによる振る舞い検知

派手な製品を入れるより、「アプリを信用しない設計」と「アプリ層のログ」という地味な土台が、結局いちばん効きます。

確認した資料

• NICT プレスリリース、CYNEX：【注意喚起】相次ぐ情報漏洩、その原因の一つは「アプリ解析からのサーバ攻撃」 — 2026年10月13日。A2B攻撃の定義、重点的な点検対象（IDOR/BOLAなど）。
• SecurityWeek：Digital.ai 2026 Application Security Threat Reportの報道 — 2026年5月20日。攻撃を受けたアプリの割合55%→87%、公開から1時間56分の事例。
• Malwarebytes：Cybernewsによる iOSアプリの秘密情報の調査 — 2025年3月14日。約15.6万本の71%にハードコード。
• OWASP API Security Top 10 2023 — API1・API3・API9。
• AWS WAF：Bot Controlルールグループ、トークンのないリクエストのブロック、モバイルSDK
• AWS WAF Fraud Control：ATP、ACFP
• CloudWatch Contributor Insights：ルールの構文、Logs Insights：stats（countDistinct）、ログの異常検知
• GuardDuty Runtime Monitoring、RDS Protection
• API Gateway：Verified Permissionsを使うLambdaオーソライザー、スロットリング
• Cognito：トークンの失効、PKCE
• Play Integrity API：判定の内容、Apple App Attest（WWDC21）
• AWS Security Incident Response：従量課金と無料枠、AIエージェントによる調査 — 2025年11月。