クラウド侵害は請求書にも現れる──FinOpsを「経理の後処理」から防御センサーへ

クラウドが侵害された時、最初に異変へ気づくのはsecurity dashboardとは限らない。

見覚えのないregionでGPUが立ち上がる。通常の十倍のAPIが呼ばれる。止めたはずのtest環境が、深夜も計算を続けている。

そして翌朝、請求額だけが先に跳ね上がる。

2026年8月7日、Google Cloudはemerging threatへの対応を説明する中で、Cloud Audit Loggingと並べてanomaly spending alertを挙げた。account takeoverによるunexpected resource changeや、compromised workloadが生む急な費用増を捉えるためだ。

ここには、企業ITの役割分担を少し変える話がある。

クラウド費用は、経理が月末に読む結果ではない。攻撃の途中で使えるsecurity signalでもある。

攻撃者も、クラウドを使えばメーターを回す

THREE DIFFERENT WINDOWSidentity、runtime、costは別方向から同じincidentを見る。

一つのsensorが黙っても、別のtelemetryが異常の輪郭を返す。costは補助線であって万能検知器ではない。

01IAM誰が

02RUNTIME何が

03COSTどれだけ

クラウドでは、compute、GPU、storage、network、API callの多くがmetered resourceである。

攻撃者が盗んだcredentialでcryptominingを始める。大量のinferenceを回す。別の攻撃を中継するためにresourceを増やす。その活動が課金対象なら、不正利用は費用の波形にも残る。

Googleは2023年、2022年のThreat Horizonsを引用し、compromised cloud accountの65%でcryptocurrency miningが確認されたと説明していた。単一attackが数日で数十万USDのunauthorized compute costになり得るとも述べている。

これは古い観測なので、「2026年も65%」とは言えない。

ただ、credentialを盗まれるとdataだけでなく、組織のcompute capacityと支払能力まで盗まれることを示すには十分だ。

cost signalの強みは、既存のsecurity logと違う角度から同じ出来事を見られることにある。

IAMは、誰の権限が使われたかを見る。
audit logは、何が変更されたかを見る。
runtimeとnetworkは、resourceの中で何が起きたかを見る。
costは、その活動がどれだけmeterを回したかを見る。

同じ窓をもう一枚増やすのではない。別の壁に、窓を開ける。

しかし、請求額は「侵害センサー」であって「侵害判定」ではない

ここを混同すると、危ない。

費用が急増したからといって、攻撃とは限らない。新製品が売れた。campaignが当たった。大きなmigrationを始めた。研究teamが正当なGPU jobを投入した。嬉しい成長も、cost detectorから見れば異常になり得る。

逆に、費用が増えていないから安全とも言えない。

Google CloudのH1 2026 Threat Horizonsでは、Google/Mandiantが観測した主要cloud/SaaS incidentの83%でidentity issueがinitial accessに関与し、cloud-related incidentの73%でdataがtargetになった。盗まれた正規sessionで静かにdataを抜けば、請求の山を作らない場合もある。

だからcost anomalyは、SIEMやEDRの代わりではない。

costだけで黒白を決めず、identity、audit、runtime、networkと重ねる。

新しいcredentialが作られた。同時刻に、普段使わないregionでGPUが増えた。egressが跳ね、請求見込みも上がった。

一つなら誤報かもしれない。三つが同時なら、優先順位は変わる。

三大cloudには検知機能がある。でも、時計の速さは同じではない

Google Cloud、AWS、Azureには、それぞれcost anomalyを見つける仕組みがある。

Google Cloudはhistorical patternと比べてcost spikeを検出し、service、region、SKUなどのroot causeを表示する。emailやPub/Subへ通知でき、AI workload向けにはnear-real-time estimateを使うearly anomalyもpreviewで提供している。2026年8月26日更新の公式docsでは、Gemini APIとVertex AI向けのearly anomalyは利用から20〜40分程度で通知される見込みとされる一方、広いproject単位のstandard anomalyは翌日の経路に残る。

AWS Cost Anomaly Detectionは、billing dataの処理後、net unblended costをおよそ一日三回評価する。AWS service、account、Region、usage typeから、費用への寄与が大きい原因をrankする。

Azure Cost Managementは、subscriptionのdaily usageを直近60日のforecastと比較する。alert mailをLogic Appsで受け、Microsoft SentinelやITSM ticketへつなぐ構成も公式documentで案内している。

便利だ。

ただし、security teamが期待する「今この瞬間」と、billing systemのnear-real-timeは同じではない。

Googleはcost detailが通常一日以内に見える一方、24時間を超える場合もあると明記している。Azureのcost/usage dataは通常8〜24時間でavailableになり、budgetは24時間ごとに評価される。FinOps Foundationのworking groupは、cloud billing detailによるanomaly identificationがevent開始から最大36時間遅れる場合もあると注意している。

一時間で回り切る攻撃を、翌日の請求だけで止めることはできない。

cost signalは、早期発見に役立つことがある。同時に、遅れて届くforensic clueにもなる。両方の性質を持つ。

「予算を設定したから止まる」は、かなり危ない思い込み

BILLING IS NOT REAL TIME検知より、気づいて止めるまでの時計を測る。

MTTO、MTTA、MTTCを一つのincident timelineへ置き、遅延するbilling signalを正しく扱う。

01OBSERVE
02ACKNOWLEDGE
03CONTAIN

budgetとspend capも、分けて考えたい。

Google Cloudのalerts-only budgetは、thresholdを超えてもusageやbillingを自動停止しない。Azureも、budget notificationによってresourceは止まらないと明記している。

Google Cloudは2026年7月、対象serviceを自動pauseするspend cap budgetをpreviewで追加した。けれど対象はGemini API、Gemini Enterprise Agent Platform、Cloud Run、Cloud Run functionsなどに限られる。persistent computeやstorageなど、動き続けるresourceは止まらない。

つまり、alertはブレーキではない。

一部のcapはブレーキになるが、車輪すべてにはつながっていない。

だから組織側で、次のresponseを設計する必要がある。

Observe──通知し、ownerへ届け、関連signalを集める。
Restrict──rate-limit、credential revoke、network isolationなどでblast radiusを狭める。
Stop──人間の承認、または狭く定義したpolicyでworkloadを止める。

いきなり全productionを止めるautomationは、攻撃より先に事業を止めるかもしれない。

money-saving botを、availability incidentの犯人にしてはいけない。

精度より先に、「誰へ届くか」を測る

cost anomaly導入の話になると、どのAI modelが高精度か、何%のspikeを拾えるかに目が向きやすい。

けれど現場では、detectした後に止まる。

billing adminのmailboxへalertが届く。担当者は費用の異常だと理解するが、どのteamのresourceか分からない。securityへ転送する。securityはproject名だけではservice ownerを探せない。Platform teamへ聞く。金曜の深夜で、返事は月曜になる。

detectorは仕事をした。

組織が、仕事を受け取れなかった。

Google Cloudの8月7日のguidanceがEssential Contactsを挙げているのは、地味だが重要だ。通知先が退職者のmailboxなら、最高の検知も無音になる。

見るべきKPIは、accuracyだけではない。

MTTO──異常からresource ownerへ届くまでの時間。
MTTA──ownerが確認を始めるまでの時間。
MTTC──containmentまでの時間。
False positive rate──正常なgrowthやbatchを何件誤認したか。
Prevented spend──放置した場合と比べ、どれだけ損失を抑えたか。

異常を見つけるAIより、異常を引き受けられる組織の方が、最後は強い。

Before──月末にFinanceが見つける

従来の運用では、Financeが月次差異を見つける。SecurityはSIEM、Platformはcloud console、Financeはspreadsheetを見ている。三者の時計も、resource名も、担当者表もつながっていない。

「この請求は誰のものですか」から調査が始まる。

After──costを一つのeventとして流す

新しい運用では、cost anomalyをsecurity/operationsのevent busへ流す。

project、account、subscription、service、region、SKUだけでなく、resource owner、environment、data sensitivity、直近deployment、予定campaignを付与する。同じ時間帯のIAM change、new credential、compute scale、egress、runtime alertと照合する。

Financeは金額の意味を読む。Platformはresourceの意味を読む。Securityは攻撃の意味を読む。

三つの専門性が、一つのincidentを囲む。

multi-cloudでは、「共通dashboard」より共通responseを作る

各cloudのnative toolingは、最初の一歩として強い。setupが速く、provider固有のservice、region、SKUを深く知っている。

一方、threshold、evaluation interval、root-cause field、notification schemaは揃っていない。native dashboardだけに運用知識を閉じると、cloudを増やすたびに別のon-call手順が増える。

FinOps FoundationのFOCUSは、cloud、SaaS、data center、AIなどのcost and usage datasetをnormalizeするopen specificationである。FOCUSそのものが侵害を検知するわけではないが、自社側に共通のcost languageを持つ助けになる。

大切なのは、全providerを一つの賢いmodelへ押し込むことではない。

検知はnativeでもいい。incidentの受け方、ownerの探し方、止め方は共通にする。

raw billing export、resource ownership、response receiptを自社側へ残せば、providerやFinOps toolを替えても、組織の学習まで失わずに済む。

cost dataにも、守るべき情報がある

費用情報をsecurityへ広く共有すればよい、と単純には言えない。

cost curveから、product launchの時期、customer activity、研究project、利用region、team規模が推測できる場合がある。詳細なbilling exportは、事業の動きを映すbusiness-sensitive telemetryだ。

また、anomaly detectionが無料でも、SIEMへのingest、長期retention、cross-cloud normalization、24時間のon-callには費用が出る。

だから、全明細を全員へ見せるのではなく、役割に応じて必要な粒度へ絞る。alertには調査を始める十分なcontextを付け、詳細billingへのaccessは監査する。

securityを強くするためのdata lakeが、次の大きな情報集積riskにならないようにしたい。

今日からできるaction plan

通知先を確認する。全billing accountのadmin、Essential Contacts、shared mailboxを棚卸しし、退職者や個人mailboxへの依存をなくす。
ownerを費用へ結びつける。project/account/subscriptionへservice、team、environment、data sensitivityのmetadataを付ける。
alertをticketへ変える。emailで終わらせず、Pub/Sub、EventBridge相当、Logic Appsなどからincident systemへ接続する。
security signalと重ねる。同時刻のIAM change、credential creation、region drift、GPU/compute scale、egressを照合する。
止め方を三段階にする。observe、restrict、stopを分け、automatic stopはnon-productionやisolated workloadから始める。
演習する。「金曜23時、普段の十倍のGPU spend」をtabletop exerciseにし、月曜まで放置されないか測る。

請求書は、事件の後に届くとは限らない

クラウドの請求は、使ったresourceの記録である。

正常な成長も、設計ミスも、暴走したloopも、不正利用も、その一部は同じメーターを回す。

だから、金額だけを見て犯人を決めてはいけない。

けれど、月末まで金額を見ない理由もない。

Financeが持っていた数字を、SecurityとPlatformが同じ時間軸で読む。

それだけで、請求書は後悔の記録から、被害を止めるsensorへ変わる。