お漏らししまくりの今だからこそIAPを再度推していく

3行で

• アプリ側のログインは「アプリに届いてから」判定するので、言語やフレームワークの脆弱性には無力
• 「アプリに届く前」に防ぐ方法なら認証するので、未ログインの攻撃リクエストはPHPまでたどり着かない。IAPはその1手段。
• 銀の弾丸ではない。利用シーンは限られるし、認証を通った人からの攻撃は普通に届くし、パッチ適用もアプリ側の認可も引き続き必要

読まなくてもいい前書き

昨今、通称PHPの脆弱性、php2shellが話題になりました。
総理大臣がXで「今夜対応を」と呼びかけ、国内でも数多くの組織が修正版の公開に合わせてサービスを止めるという、なかなか見ない光景になりましたね。

今回の攻撃は

• mod_phpの構成では、アプリケーションのコードが動く前に攻撃が成立する
• リモートコード実行まで行かなくても、パスワードやAPIキーなどの秘密情報をプロセスのメモリから認証なしで読み出せることが実証された

つまり、今回の件で言うとアプリ側でどれだけ丁寧にセキュアコーディングをしていても関係ないってことですね。
認証とのためにアプリでログイン機能をばっちり作っていても攻撃が成立するということになります。
ログイン判定のコードにたどり着く前に、その下の言語ランタイムで刺さるので。

しかも公表の4日前には、すでに攻撃の試行が観測されていたそうです¹。「パッチが出たらすぐ当てる」は大前提ですが、ゼロデイ攻撃など間に合わない場面がある、という話でもあります。

付け加えるのならばセキュリティ界隈では「PHPは微妙」という声も大きいですが、
本問題自体は別にPHPでなくとも発生するリスクであると思います。

また、Vibe Codingの功罪と言いますか、ソフトウェア知識がない人が誰でも開発できるようになったが故にこのような脆弱性を含むサイトは今後増えていくのではないかと思います。

「えー、じゃあシロウトがWebアプリを作るのは危ないの？」と尻込みして、今の1億総プログラマ時代を終わらせるのはもったいないと思います。

じゃあどうするのか。というところで
「未ログインのリクエストを、そもそもアプリに届かせなけりゃいいじゃないか」　ということを訴えたいと思います。
Google Cloudなどで提供されるIAP(Identity-Aware Proxy)がこれにあたります。

この機能はまったく目新しい技術ではないし、使えるシーンも限られるのですが、
社内ツールとして作ったものや自分や仲間たちで使うという用途範囲内であれば
VibeCodingによる初級者でもアプリ側にいくらバグがあろうとPHPにいくら脆弱性があろうと無敵になります。(後述しますが過言です)

「手前で止める」手段いろいろ

アプリの手前でアクセスを絞る方法はIAP以外にもあります。ざっくり並べるとこんな感じです。

手段	何を見て通すか	弱いところ
IP制限	接続元のIPアドレス	外出先やリモートワークと相性が悪い。そもそもIPは本人確認ではない
VPN	ネットワークに入れるか	VPN機器そのものが攻撃対象になる。入った後は広く見えてしまいがち
Basic認証等	共有のID・パスワード	使い回されがち。退職者対応や2段階認証ができない
WAF	既知の攻撃パターンに合致するか	未知の攻撃や変種は通りうる
ID認識型プロキシ(IAPなど)	誰なのか(＋端末やIPなどの条件)	認証を通った人からの攻撃は通る

今回の件でもWAF各社はすぐに遮断ルールを出しましたが、各社とも「あくまで更新までの補完策」という位置づけでした¹。WAFは攻撃の形を知っていて初めて止められる仕組みなので、これは仕方ないところです。

ちなみにVPNや管理画面も他人事ではなくて、今回はファイアウォール製品の管理画面(中でPHPが動いている)が狙われて侵害された事例も報告されています¹。「守る側の機器」も同じ土俵にいるわけですね。

CloudIAPと同じ思想のサービスは他のクラウドにもあります。今回はこれらを総称して「IAP」と呼んでます。

• AWS：ALBの認証機能＋Cognito、Verified Access
• Cloudflare：Cloudflare Access
• Microsoft：Entraアプリケーションプロキシ

本記事ではGoogle CloudのIAPを例に進めますが、考え方はどれも共通です。

IAPとは

CloudIAPは、アプリの手前に立ってGoogleアカウントでの認証と権限チェックを行うプロキシです²。

流れはシンプルです。

1. ユーザーがアプリのURLにアクセスする
2. 未ログインならGoogleのログイン画面に飛ばされる
3. ログイン後、そのユーザーに権限(IAMロール)があるかをIAPがチェックする
4. OKならリクエストがアプリに転送される。NGならここで終了

ポイントは、2と3をやっているのが自分のアプリではなくGoogleの基盤だという点です。
自分のサーバーでPHPが動き出すのは、4でリクエストが転送されてきてからです。

アプリ側ログインとIAPの比較

Webアプリ側でログイン機能を実装した場合とIAPがどう違うのか見ていきます。

アプリ側でログインを実装している場合

未ログインのリクエストでも、ログイン判定にたどり着くまでにWebサーバー、PHP本体、フレームワークを通ります。
赤いところに脆弱性があれば、ログイン判定の出番が来る前にやられます。今回のphp2shellがまさにこれです。

IAPを手前に置いた場合

上記の通り認証前の攻撃者の赤線は一切自分のサーバーには届きません。
PHPにどんな脆弱性があろうと、アプリにどんなバグがあろうと、届かないものは刺さりようがないという理屈です。

	アプリ側ログイン	IAP
認証する場所	自分のアプリの中	アプリの手前(Googleの基盤)
未ログインのリクエスト	PHP・フレームワークまで届く	届かない
言語・フレームワークの脆弱性(認証不要のもの)	影響を受ける	未ログインからは突けない
ログイン機能そのもののバグ	自分の責任	Googleの責任範囲
2段階認証	自分で実装	Googleアカウント側の設定に乗れる

「認証不要で攻撃できる」という脆弱性の前提を、構成で潰してしまうイメージです。

※IAPを使った場合、完全にアプリで認証のための実装が不要なわけではなく
ユーザー識別のため、IAPから受け取ったヘッダ等を解析する作りは必要です

アプリでの実装範囲が
IAPなし：ログイン→認証→ログイン情報を基にユーザー識別
↓
IAP使用：IAPの情報を基にユーザー識別

と変わるイメージ

めっちゃいいじゃん、世の中全部これでいいじゃん！←？

・・・とはならず
基本的にはIAPは事前に認証ユーザーを登録しておく必要があります。
一般サービス向けの様な「ユーザー登録」をさせることで不特定多数のユーザーに認証を提供させるようなシーンにはあまり向いていません。
(※一応後ろの章に「おまけ」としてそれでも一般ユーザー向けに実装するとしたら、を載せてはいます。)

IAPで守れるのは認証だけです

当然ながら以下は守れません。

• 認証を通った人による攻撃(内部不正や、権限を持つ利用者からの攻撃)
• アカウントの乗っ取り(フィッシングなど)。アカウントの管理不備による漏洩。2段階認証は必須
• IAPを通らない別の入り口を作ってしまっていた場合(バッチ、Webhook、外部連携のAPIなど)

それでも、有名企業でもない限り、受ける攻撃はほとんどBotによるオポチュニスティック攻撃(なんか隙がありそうなところを自動で探して狙う攻撃)なので、
「不特定多数による攻撃」はほとんど防げると思います。

おまけ：一般向けサービスでもやるとしたら

前述の通り、基本的にIAPは「利用ユーザーが特定できている状態」に使うものです。

不特定多数が使う一般向けサービスの前段にIAPをそのまま置く、というのはあまり一般的な構成ではないと思います。
誰でも登録できるサービスでは攻撃者も「認証済みユーザー」になれるので、効き目が薄れるからです。

それでも考え方を取り入れるなら、こんな感じかもしれません。

• ログインやサインアップの処理は自前で作らず、認証サービス(IdP)に任せる
• LPなどの公開ページは静的配信にして、未ログインで叩ける自前のコードを減らす
• 管理画面や運用ツールだけはIAPの裏に置く

IAPにもGoogleアカウント以外(メール/パスワードやSNSログインなど)で認証できる外部IDという仕組みはあります³。ただ、こちらは取引先や会員など「限定された外部ユーザー」向けと捉えるのがよさそうです。

とりあえず3つ目の「管理画面だけでもIAPの裏に」は、一般向けサービスでもすぐ効くと思います。管理画面って、一番やられたくないのに一番雑に公開されがちなので。

補足：導入の手軽さと料金

以前はCloud RunでIAPを使うにはロードバランサが必須で、少し知識が必要でした。。。が
今はCloud Runのサービスに対して直接IAPを有効化でき、Web上のコンソールから１ボタンポチでいけます。

料金については、IAP自体には費用がかからず、Googleの公式ブログでも導入企業が「無料で導入も簡単」という点を挙げています⁴。直接有効化ならロードバランサ代もかかりません。

「やらない理由」がだいぶ減っているので、社内ツールや管理画面をアプリ側のログインだけで公開しているなら、一度見直してみる価値はあると思います。

まとめ

• アプリ側のログインは、アプリまで届いたリクエストに対する防御。その下の言語やフレームワークがやられると意味をなさない
• IAPのように手前で認証する構成なら、未ログインの攻撃はアプリに届かない
• ただし認証後の世界は別問題。パッチ適用、アプリ側の認可、2段階認証は引き続き必要

脆弱性は今後もなくなりませんし、AIで見つかるペースはむしろ上がっていきそうです。
「脆弱性があっても、届かなければ刺さらない」という層を1枚足しておく、というのは地味ですが効く対策だと思います。

参考

1. piyolog「PHPの2件の深刻な脆弱性(CVE-2026-109618、CVE-2026-109619)についてまとめてみた」 https://piyolog.hatenadiary.jp/entry/2026/10/21/174516 ／修正版の公開は2026年10月21日。深刻度はCVSS v4.0で9.2(Critical)。発見者による機密情報の読み出しの実証、公表前(10月17日)の攻撃試行の観測、WAF各社の対応、ファイアウォール製品の管理画面を狙った侵害事例は同記事のまとめによる。 ↩ ↩² ↩³

2. Google Cloud「Identity-Aware Proxyの概要」 https://cloud.google.com/iap/docs/concepts-overview?hl=ja ↩

3. Google Cloud「外部ID」 https://docs.cloud.google.com/iap/docs/external-identities?hl=ja ↩

4. Google Cloud Blog「Cloud RunサービスでIAP認証を直接有効にする」 https://cloud.google.com/blog/ja/products/serverless/iap-integration-with-cloud-run ↩