実際のインシデントに学ぶ、クラウドコスト異常検知

クラウドセキュリティインシデントの傾向：GCPとAWSの比較

Google Cloudのインシデントは、ほぼすべてが一つの要因に行き着きました。この1年でGemini APIとVertex AIの利用が爆発的に増加し、スピード重視の開発の中でAPIキーを無制限のまま放置することがいかに容易だったか、という点です。Gemini APIキー悪用への対策については、ブログのこちらで紹介しています。AWSのインシデントは、より従来型のパターンに偏っていました。漏洩したIAMキーがコンピュートリソースの不正利用につながるケースに加え、アカウントの完全な乗っ取りも数件ありました。両プラットフォームに共通して、根本原因がプラットフォームの脆弱性であることはほぼ皆無でした。ほとんどの場合、原因は認証情報に対して人間が行った（あるいは行わなかった）何かでした。

GCPのセキュリティインシデント：漏洩APIキーが最大の原因

根本原因	割合
漏洩した、または制限のないAPIキー（Gemini、Vertex、AI Studio）	77%
漏洩したサービスアカウントキーによる暗号資産マイニングや不正なCompute Engineフリートの起動	19%
管理者アカウントまたはセッションの乗っ取りによる請求情報の改ざん・管理者ロックアウト	2%
侵害されたサービスアカウント経由のデータ持ち出し	2%

最上段の項目がほぼすべてを占めています。過去6か月に確認したGCPインシデントの77%は、APIキー（多くはFirebaseのブラウザキーや、クライアントサイドコードに埋め込まれたMaps/Geminiキー）にHTTPリファラー制限もIP制限もAPIスコープ制限も設定されていなかったことが原因でした。攻撃者はまさにこのパターンを狙って公開リポジトリや露出したフロントエンドバンドルをスキャンしており、有効なキーを見つけると自動化スクリプトをGenerative Language APIに向けて走らせ続けます。こうしたインシデントによる不正なGemini課金は、数百ドルから20万ドル超まで、わずか数時間で発生したケースを確認しています。

2番目のクラスターである漏洩サービスアカウントキーは、展開こそ異なりますが始まりは同じです。長期間有効なキーがGitHubリポジトリ、CI/CD設定、開発者のノートPCに置かれている、という状況です。攻撃者はキーを手に入れると、API課金を積み上げるのではなく、コンピュートリソースを起動します。私たちが対応したある事例では、漏洩したGitLab CIのサービスアカウントキーによって、攻撃者が一晩のうちに単一のGCPプロジェクト内で10,500台以上の暗号資産マイニング用VMを起動しました。**しかも、クラウドプロバイダーへの返金申請が必ず承認されるとは限りません。**これは重く受け止めるべき点です。クラウドプロバイダーは「想定外の支出」に対するクレジット付与に厳格になりつつあり、特に再発性のあるインシデントや防止可能だったインシデントではその傾向が顕著です。請求に関する異議申し立てというセーフティネットが保証されない以上、封じ込めと予防の重要性はかつてなく高まっています。

AWSのセキュリティインシデント：IAMキー漏洩とアカウント乗っ取り

根本原因	割合
漏洩した、または制限のないIAMアクセスキー（開発マシン、CI/CD、コード）によるEC2、ECS、Fargate、Bedrockの不正利用	56%
ルートアカウントまたは管理者セッションの乗っ取りによる請求情報の改ざん・管理者ロックアウト	15%
侵害されたワークロードやアプリケーション（露出したサービス、誤設定された信頼ポリシー）によるラテラルムーブメントやシークレットの持ち出し	15%
侵害された顧客アカウントを介したプラットフォーム悪用、Amazon SES経由でのフィッシングやスパム送信	7%
認証情報の侵害を伴わないDDoSまたはネットワーク層への攻撃	7%

AWSの状況もGCPと似ています。漏洩した認証情報が全体の半数以上を占めています。開発者のマシンやCIパイプラインから漏洩したIAMアクセスキーは、暗号資産マイニングを実行する不正なEC2やFargateフリートに、そして最近ではモデル推論料金を積み上げる不正なBedrock API呼び出しへとつながっています。

セキュリティ責任者が最も警戒すべきなのは、ルートアカウント乗っ取りのケースです。復旧が最も困難だからです。あるインシデントでは、攻撃者がお客様のAWSルートアカウントのパスワードをリセットし、自分のMFAデバイスを登録して、本来の管理者を完全に締め出しました。そこから大規模なBedrock API呼び出しを実行し、アカウントが復旧されるまでに50万ドルを超える課金が発生しました。復旧には、AWSと直接連携して所有権を再確認し、アクセス権をゼロから再構築する必要がありました。通常対応にあたる担当者がアカウントに入れなければ、どれほど迅速な異常検知アラートも意味を成しません。

また、数は少ないものの実際に発生しているワークロードレベルの侵害も確認しました。インターネットに面したロードバランサーがPodを露出させ、誤設定されたOIDC信頼ポリシーを突かれ、攻撃者がラテラルムーブメントによってSecrets Managerから数千件のシークレットを持ち出した、というものです。これらは単一のキー漏洩というより、許容範囲の広いネットワーク設定とIAM設定が積み重なった負債の問題です。

アイデンティティ侵害：フィッシング、OAuth悪用、アカウント乗っ取り

残りのインシデントは、別の、しかし関連するパターンをたどっていました。フィッシングキャンペーンで認証情報が窃取され、それを使ってアカウントが乗っ取られ、侵害された送信者アイデンティティ経由でスパムが送信されたり、OAuth経由で連携先のサードパーティツールに侵入されたりするケースです。あるお客様では、侵害されたWorkspaceアカウントを使ってGoogle Adsアカウントに不正なマネージャーリンクが追加され、5万ドル近い不正な広告費が発生しました。別のお客様では、従業員のログイン情報を使ってサードパーティツールへのOAuthアクセスが許可され、不正な購入が行われました。

すべてのプラットフォームに共通する点はこうです。弱点はクラウドプロバイダーのインフラではなく、アイデンティティでした。

請求額は煙であって、火元ではない

コストの急増そのものを問題として扱いたくなりますが、コストの急増は多くの場合、認証情報侵害の最初に目に見える症状にすぎません。請求だけを解決しても、対処したのは症状です。認証情報の管理を徹底し、異常検知に本気で取り組んで初めて、根本原因に対処したことになります。

だからこそ私たちの推奨は、連動して機能すべき2つの要素で構成されています。悪用される前にギャップを塞ぐセキュリティ態勢レビューと、それでもギャップをすり抜けた場合に悪用を素早く検知するモニタリングです。

クラウドセキュリティインシデントを防ぐには：ギャップを塞ぐ

DoiTが推奨する2つのステップは次のとおりです。

ステップ1：クラウドセキュリティ態勢の見直し

上記のインシデントの大半は、標準的なクラウドセキュリティ態勢レビューに含まれるプラクティスで防止できたものです。APIキーを特定のリファラーやIPレンジに制限する、長期間有効なサービスアカウントキーをローテーション・廃止する、可能な限り静的な認証情報からワークロードアイデンティティ連携や短期トークンへ移行する、IDプロバイダー側でMFAとセッション有効期間の制限を強制する、オーナーレベルのIAMバインディングを作成・使用できる人を制限する、といった内容です。どれも特別なことではありません。地味で目立たないアクセス管理の基本作業ですが、まさにこれが、インシデントのたびに「欠けていたもの」として繰り返し浮かび上がっています。

ステップ2：クラウドコスト異常検知と通知の設定

DoiT Cloud Intelligence™ Real-Time Anomaly Detection（EnhancedおよびEnterpriseティアで利用可能）は、今回のデータセットのほぼすべてのインシデントに共通するギャップ、つまり「問題の発生」から「誰かが気づくまで」の遅延を埋めるために設計されています。請求データをもとにしたツールの多くは、遅延して更新されるエクスポートを読み取るため、支出急増を検知するのは発生から数時間〜数日後です。Real-Time Anomaly Detectionはランタイムの使用状況データを直接読み取り、過去の支出パターンと組み合わせることで、異常なアクティビティを数日ではなく数分以内に検知できます。すべてのアラートには深刻度スコアと、影響を受けたサービス・SKU・リソースについてのAIによる分析が添付されるため、チームはゼロから調査を始める必要がありません。

Essentialsティアのお客様も、標準搭載のクラウド異常検知を設定し、異常を特定・通知するための適切な通知を構成できますし、そうすべきです。Real-Time Anomaly Detectionへのアップグレードについては、DoiTのアカウントマネージャーにご連絡いただくか、DoiTコンソールのExpert Inquiryからチケットを送信してください。

異常検知を最大限に活用するために：

1. **異常検知の通知が、適切な人に、適切なチャネルで、適切なタイミングで届くよう設定されていることを確認する。**コスト異常通知にはCloud Analytics権限が必要で、デフォルトではAdmin、Power User、Finance User、Standard Userに送信されます。ただし、チーム内で実際に誰がこの設定を有効にしているか、そして通知への迅速な対応の重要性を理解しているかは、確認しておく価値があります。
2. **デフォルトの深刻度しきい値のままにしない。**組織で変化の激しいワークロード（CI/CD、生成AI推論、オートスケーリングフリート）を運用している場合は、午前2時に発生した中程度の深刻度の異常でも朝までに確認されるよう、レビューの頻度を調整してください。
3. **検知と通知の設定（または検証）には、DoiTのカスタマーサクセスマネージャーを活用する。**DoiTのCSMは喜んでサポートし、正しく設定されているかどうかを専門家の目で確認します。
4. **支出の急増と新規SKU使用の通知を設定する。**新規SKUの異常検知・通知は、活用が進んでいないものの極めて重要な機能です。組織がこれまで使ったことのないサービスやSKUを使い始めた瞬間に知らせてくれます。これはまさに、盗んだキーを持つ攻撃者が初めてGenerative Language APIを呼び出し始めたり、Bedrockの推論を起動したりしたときに起こることです。正当な新規SKUは、チームが新しいものをリリースしたときにたまに現れるものです。想定外のタイミングで現れた説明のつかない新規SKUは、すぐに確認する価値があります。
5. **クォータの枯渇やクレジット使用に関する通知の設定も検討する。**別の障害モード向けに作られた機能ですが、支出における想定外の挙動の全体像を補完してくれます。
6. 自動化の活用を検討する。DoiT Cloud Intelligence™ CloudFlowをコスト異常トリガーで実行するよう設定しましょう。Slackへの投稿、チケットの作成、修復手順の実行といったインシデント対応タスクを自動化できます。どこから始めればよいかわからない場合は、DoiTのカスタマーサクセスマネージャーがDoiTのForward Deployed Engineerとの作業セッションを調整し、CloudFlowの作成をサポートします。

異常検知と通知の設定について詳しくは、DoiTヘルプドキュメントの異常検知と通知をご覧いただくか、DoiTのカスタマーサクセスマネージャーにお問い合わせください。