「クラウドのログさえ取っておけば、何かあっても後から追える」。クラウド移行を進めた現場で、一度はそう考えたことがあるのではないでしょうか。AWS CloudTrailやGoogle Cloud Loggingを有効にしておけば、不正なAPI呼び出しも、誰がいつ何をしたかも、すべて記録に残る。そう信じてログ取得を「対策完了」のチェック項目にしているチームは少なくありません。
ところが2026年6月、Palo Alto Networksの脅威インテリジェンス部門Unit 42が公開した分析が、その前提に冷水を浴びせました。防御側が頼みの綱とするクラウドログそのものが、攻撃者にとっては「消すべき証跡」であり、同時に「乗っ取って使える監視ツール」でもある、という指摘です。攻撃者はログを止め、消し、改ざんし、さらには自分のアカウントへ横流しして被害環境を継続監視する手口まで使い始めています。
この記事では、Unit 42が示したクラウドログ悪用の実態を一次情報から整理し、「ログ取得＝安心」という思い込みのどこが危ういのかを攻撃者視点で解き明かします。そのうえで、SOC（セキュリティ監視チーム）や情シスが明日から着手できる検知・最小権限・ログ保護の具体策まで、現場で使えるレベルで紹介します。攻撃手法を取り上げるのは、あくまで防御のためです。敵がどこを狙うかを知らなければ、守るべき場所も見えてきません。
Unit 42が指摘したクラウドログ悪用とは何か
今回の指摘の出どころは、Palo Alto NetworksのUnit 42が2026年6月に公開した分析レポート「Blinding the Watchmen: Abusing Cloud Logging Services for Defense Evasion and Visibility」です。タイトルを直訳すれば「見張り役の目を潰す」。クラウドのログ機能を、防御側の監視を無力化する道具として攻撃者がどう悪用するかを、AWSとGoogle Cloudの両方で具体的に検証した内容です。
ここで言う「クラウドログ」とは、AWSならCloudTrail（アカウント内のAPI操作を記録する監査ログサービス）、Google CloudならCloud Logging（旧Stackdriver Logging）を指します。どちらも「誰が、いつ、どのリソースに、どんな操作をしたか」を時系列で残すための仕組みで、インシデント発生後の調査では最初に頼る情報源です。逆に言えば、ここが汚染されたり消されたりすると、調査の足場そのものが崩れます。
Unit 42が整理した攻撃者の狙いは、大きく2つに分けられます。1つめは防御回避（Defense Evasion）。検知の仕組みに見つからないよう、ログの流れを止めたり壊したりして、SIEM（ログを集約して相関分析する監視基盤）やSOCのアナリストを「目隠し」する動きです。2つめは継続的な可視化（Continuous Visibility）。被害環境のログを攻撃者自身のアカウントへ横流しし、被害組織の動きを攻撃者側がリアルタイムで監視し続けるという、より高度な狙いです。
注意したいのは、これが「未知の脆弱性を突く攻撃」ではない点です。CloudTrailやCloud Loggingが本来備える正規の管理機能を、十分な権限を奪った攻撃者が「仕様どおりに」使うだけで成立します。つまりパッチを当てて塞ぐ類の話ではなく、権限設計とログ保護の運用そのものが問われる、という性質の問題です。
この攻撃の枠組みは、攻撃者の戦術・技術を体系化したMITRE ATT&CKでも「Disable or Modify Cloud Logs（クラウドログの無効化・改ざん）」として技術ID T1562.008 に整理されています。今回のUnit 42の分析は、この既知の技術がクラウド環境で実際にどう実装されるかを、AWS・Google Cloudの具体的なAPI操作レベルまで掘り下げたものと位置づけられます。
攻撃者はクラウドログをこう悪用する
では攻撃者は、奪った権限を使って具体的に何をするのか。Unit 42が示した手口を、防御を組み立てるための材料として順に見ていきます。いずれも「正規の操作の悪用」であり、新しいexploitコードが必要なわけではない点を押さえてください。
1. ログ記録を止める（停止）
もっとも単純で効果的なのが、ログ記録そのものを止めてしまう手口です。AWSではCloudTrailのstop-loggingというAPIを呼び出すだけで、対象の証跡（トレイル）の記録が停止します。Google Cloudでは、ログの転送先を定義するシンク（sink）を無効化することで同等の効果を狙います。記録が止まった後の操作は、当然ながらログに残りません。攻撃者が本格的な行動に出る直前にこの一手を打てば、以降の足跡は丸ごと消えることになります。
2. ログの保存先を消す（削除）
記録を止めるだけでなく、保存先そのものを破壊する手口もあります。AWSではCloudTrailのログが保存されるS3バケット（クラウド上のファイル置き場）をdelete-bucketで削除する、あるいはトレイル自体を削除する。Google Cloudではログバケットやシンクを削除する。これらが実行されると、すでに記録済みのログまで失われたり、新規ログの書き込み先がなくなったりします。調査の証拠が物理的に消える、もっとも厄介なパターンです。
3. 暗号鍵を握ってログを読めなくする
より巧妙なのが、暗号鍵を使ったロックアウトです。AWSではログの暗号化に使うKMS（鍵管理サービス）の鍵を攻撃者が管理する鍵に差し替えたうえでアクセスを剥奪する、Google CloudではCMEK（顧客管理の暗号鍵）で同様の操作を行う。すると、ログは存在していても復号できず、防御側は自分のログを読めなくなります。記録は残っているのに中身が見えない――鍵を人質に取られた状態です。削除と違ってログの「件数」上は異常が見えにくく、気づくのが遅れがちな点が危険です。
4. ログを改ざんする（ポイズニング）
ログファイルをいったんダウンロードし、自分にとって都合の悪いイベントだけを削除・書き換えてから元の場所へ再アップロードする手口です。Unit 42はこれをログの「ポイズニング（汚染）」と表現しています。ログの一部だけが書き換わるため、ファイルが消えたり止まったりするより発覚しにくく、調査側は「残っているログ」を正しいものと信じて分析を進めてしまう恐れがあります。完全性（記録が改ざんされていないこと）の検証が効いていないと、見抜くのは容易ではありません。
5. ログを攻撃者のアカウントへ横流しする（継続監視）
最後が、もっとも戦略的な手口です。AWSではupdate-trailでトレイルの出力先を外部のS3バケットへ向け替える、あるいは新しいトレイルを作って攻撃者管理の保存先へログを流す。Google Cloudではシンクを作成・付け替えて外部ストレージへログをルーティングする。これにより攻撃者は、被害組織の運用状況や防御側の動きを「被害組織自身のログ」を通じてリアルタイムで監視し続けられます。防御側が異常に気づいて対応を始めても、その対応の様子まで攻撃者に筒抜けになる、という事態すら起こり得ます。ログが防御ツールから、攻撃者の偵察・監視ツールへと裏返る瞬間です。
ここまでを一段引いて眺めると、共通しているのは「ログ機能を管理できるほどの権限を、攻撃者が先に奪っている」という前提です。つまりこの問題の本質は、ログそのものの脆弱性ではなく、ログ機能に手を出せる権限の広さと、ログ保護運用の薄さにあります。次の章では、そこを起点に防御の整理に入ります。
PR
AWSではじめるクラウドセキュリティ クラウドで学ぶセキュリティ設計/実装
CloudTrailやS3バケットポリシー、IAM権限設計をハンズオン形式で学べる一冊です。今回のようなログ悪用への耐性は、結局のところ権限とログ保護の設計で決まります。クラウドのセキュリティ設計を体系的に固めたい方の足場になります。
「ログを取っていれば安心」が崩れる理由
ここまでの手口を踏まえると、なぜ「ログ取得＝対策完了」という発想が危ういのかが見えてきます。論点を3つに分けて整理します。
1つめは、ログ機能そのものが攻撃対象になるという発想の欠落です。多くの現場では、ログは「取れているか／取れていないか」の2択で管理されています。しかし攻撃者にとって、稼働中のログ機能は「止められる対象」「消せる対象」「乗っ取れる対象」です。ログを有効化した時点で安心するのは、防犯カメラを設置したことに満足して、そのカメラ自体が壊されたり向きを変えられたりするリスクを考えないのに似ています。
2つめは、権限の広さが見えていないことです。前章の手口はすべて、CloudTrailやS3、KMS、あるいはCloud Loggingのシンクを操作できる権限が前提でした。日常運用で便利だからと管理権限を広く配ってしまうと、その一つが侵害されただけでログ機能ごと無力化されます。「誰がログ機能を止められるのか」を即答できない組織は、この攻撃に対して無防備に近い状態です。
3つめは、ログの完全性を検証していないことです。改ざん（ポイズニング）の手口が示すように、ログは「残っていること」と「正しいこと」が別問題です。改ざん検知の仕組みを入れていなければ、書き換えられたログを信じて誤った結論に至ります。インシデント調査において、土台となる証拠が汚染されていることほど危険な状況はありません。
つまり「ログを取る」は防御の出発点であって、ゴールではありません。取ったログを止められないように・消されないように・改ざんされないように・盗まれないように守るところまでが、本来のログ運用です。ここからは、その4つの守りを具体的な手順に落としていきます。
防御側がやるべきこと：検知・最小権限・ログ保護
Unit 42が示した対策と、SOC・情シスの現場運用を踏まえ、優先度の高い順に手順化します。いきなり全部は難しくても、上から順に潰していけば守りは着実に固まります。
1. ログ機能を触れる権限を絞る（最小権限）
最優先は権限の見直しです。CloudTrailの停止・削除・設定変更、S3バケットの削除、KMS鍵の操作、Google Cloudのシンク更新――これらの操作ができる権限を、本当に必要な少数の管理者だけに限定します。具体的には、AWSならcloudtrail:StopLoggingやcloudtrail:UpdateTrail、ログ保存用バケットへの削除・書き換え権限を、日常運用ロールから外します。Google Cloudならlogging.sinks.updateなどのシンク操作権限を絞り込みます。「ログを止められる人を数えられる」状態を作るのが第一歩です。
2. ログ保存先を分離・保護する
ログの保存先を、操作対象の環境から切り離すのが次の手です。理想は、ログ専用の別アカウント（あるいは別プロジェクト）にログを集約し、本番環境を侵害されてもログ保管先には手が届かない構成にすることです。AWSではS3バケットポリシーで「CloudTrail以外の書き込み・削除」を禁止し、バージョニングやオブジェクトロックで上書き・削除に耐性を持たせます。Google Cloudでは、削除できない_Requiredログバケットの活用や、保持期間をロックして変更不能にする運用が有効です。保存先が攻撃者と同じ土俵にある限り、削除も改ざんも防ぎきれません。
3. ログの完全性を検証する
改ざんを見抜くには、完全性の検証を仕込んでおく必要があります。AWS CloudTrailには「ログファイルの整合性検証（log file integrity validation）」機能があり、これを有効にしておけばログファイルが改ざん・削除されていないかを後から検証できます。さらにAWSには、API操作の履歴を90日間さかのぼれる「Event History」があり、トレイルが止められた後でも一定の証跡を確認できる場合があります。あくまで補完的な手段ですが、「トレイルだけに依存しない」備えとして押さえておく価値があります。
4. ログ機能への操作そのものを監視する
そして検知です。これまで多くのSOCは「ログに記録された不審な操作」を監視してきましたが、今後は「ログ機能に対する操作」自体を高優先度のアラート対象にすべきです。具体的には、CloudTrailのStopLogging、トレイルやログバケットの削除・更新、KMS鍵ポリシーの変更、Google Cloudのシンク作成・更新といったイベントを、SIEMで即時にアラート化します。これらは正規管理者でも頻繁には行わない操作のため、検知ルールとしてノイズが少なく、効果が高い領域です。「ログが止まった」という事実そのものを見逃さない仕組みが、最後の砦になります。
AWS・Google Cloudで押さえるべき対策の対応表
ここまでの守りを、攻撃者の手口ごとにAWS・Google Cloudの対策へ対応づけて整理します。自社環境のチェックリストとして使ってください。
| 攻撃者の手口 | AWSでの主な対策 | Google Cloudでの主な対策 |
|---|---|---|
| ログ記録の停止 | StopLogging権限を管理者に限定／停止イベントを即アラート | シンク無効化権限を制限／無効化を即アラート |
| 保存先の削除 | S3バケットポリシーで削除制限＋バージョニング／オブジェクトロック | 削除不可の_Requiredバケット活用／保持期間ロック |
| 暗号鍵の悪用 | KMS鍵ポリシー変更を制限・監視 | CMEK操作を制限・監視 |
| ログ改ざん | ログファイル整合性検証を有効化 | ログバケットのロック・完全性確認 |
| 外部への横流し | UpdateTrail権限を制限／出力先変更を即アラート | シンク作成・付け替えを制限・監視 |
表のとおり、対策の軸はどのプラットフォームでも共通しています。ログ機能を触れる権限を絞り、保存先を分離・保護し、完全性を検証し、ログ機能への操作を監視する。クラウドが変わっても、守りの原則は変わりません。
PR
詳解 インシデントレスポンス ―現代のサイバー攻撃に対処するデジタルフォレンジックの基礎から実践まで
ログが消されたり改ざんされたりした「その後」にどう調査を進めるか。証跡の保全からフォレンジックの実務までを体系立てて学べる定番書です。検知だけでなく、いざ侵害された後の調査力までチームで底上げしたい方におすすめします。
中小企業の情シスが今日からできること
専任のSOCを持たない中小企業でも、できることは確実にあります。予算や人手をかけずに着手できる順に、チェックリストとして挙げます。
・ログを止められる人を数える: CloudTrailやログバケットを停止・削除できる権限を持つアカウントを洗い出し、その数を最小限に絞る。まず「誰が止められるか」を把握するだけでも大きな前進です。
・停止・削除イベントの通知を設定する: CloudTrailの停止やトレイル削除を検知したらメールやチャットへ通知する仕組みを入れる。AWSのEventBridgeやGoogle Cloudのアラート機能で、コードを書かずに設定できます。
・ログ保存バケットに削除耐性を持たせる: S3バケットのバージョニングを有効にし、誤削除・改ざんに備える。設定は数クリックで完了します。
・ログファイル整合性検証を有効化する: AWS CloudTrailの整合性検証はオンにするだけで、改ざんの後追い確認ができるようになります。
・管理権限の棚卸しを定例化する: 半年に一度でも、誰がどんな強い権限を持っているかを見直す。退職者や異動者の権限が残っていないかを点検します。
すべてを一度にやる必要はありません。「ログを止められる人を絞る」と「止められたら通知が飛ぶ」の2つだけでも、攻撃者にとっての難易度は大きく上がります。完璧を目指して動けないより、できるところから一つずつ潰していく方が、結果的に守りは固まります。
よくある誤解と注意点
最後に、現場で生まれやすい誤解を整理しておきます。
・「ログを有効にしてある＝守れている」ではない: 有効化は出発点です。止められない・消されない・改ざんされない・盗まれないところまで守って初めて、ログは防御として機能します。
・「件数が正常＝改ざんなし」ではない: ポイズニングは一部のイベントだけを書き換えるため、ログの件数や容量からは異常が見えません。完全性検証を入れていなければ見抜けない、と考えてください。
・「これは特殊なゼロデイ攻撃」ではない: 今回の手口は正規の管理機能の悪用であり、パッチで塞げる種類の問題ではありません。だからこそ、権限設計と運用で守る必要があります。
・クラウド事業者の責任ではなく利用者の責任範囲: ログ機能の権限管理や保護設定は、クラウドの責任共有モデルにおいて利用者側が担う領域です。事業者が自動で守ってくれる前提は持たないでください。
クラウドのIAM（権限管理）設計の基礎は、姉妹サイトクラウドマスターズ.TOKYOでも実務目線で解説しています。権限まわりをもう一段深掘りしたい方は、あわせてご覧ください。
本記事のまとめ
Palo Alto Networks Unit 42の分析が突きつけたのは、「ログを取っていれば安心」という前提の危うさでした。攻撃者は十分な権限さえ奪えば、ログを止め、消し、暗号鍵で読めなくし、改ざんし、さらには自分のアカウントへ横流しして被害組織を監視し続けます。防御の要であるはずのクラウドログが、攻撃者の偵察・監視ツールへと裏返るのです。
守りの原則はシンプルです。ログ機能を触れる権限を絞り、保存先を分離・保護し、完全性を検証し、そしてログ機能への操作そのものを監視する。新しいツールを買い足す前に、まずは「誰がログを止められるのか」を数えるところから始めてください。攻撃者の視点でログを見直すことが、いちばん確実な防御の第一歩になります。
正しく知れば、正しく備えられます。クラウドログを「取って終わり」にせず、「守るべき防御資産」として運用していきましょう。
「用語解説・ニュース」の記事を読む
このテーマに関連する解説記事を一覧でまとめています。あわせてご覧ください。
よくある質問（FAQ）
Q1. CloudTrailを有効にしていれば、ログ削除攻撃は防げますか？
A. 有効化だけでは防げません。CloudTrailの停止・削除やログ保存先（S3バケット）の削除ができる権限を攻撃者が奪えば、ログ機能ごと無力化されます。停止・削除権限を最小限の管理者に絞り、保存先を分離・保護することまでが必要です。
Q2. ログが改ざんされたかどうかは、どうやって見抜けますか？
A. AWS CloudTrailの「ログファイル整合性検証」機能を有効にしておくと、ログが改ざん・削除されていないかを後から検証できます。改ざん（ポイズニング）はログの一部だけを書き換えるため件数からは見抜けず、完全性検証の仕込みが不可欠です。
Q3. ログを攻撃者のアカウントへ横流しされると、何が問題ですか？
A. 被害組織の運用状況や防御側の対応を、攻撃者がリアルタイムで監視し続けられる点が問題です。防御側が異常に気づいて対応を始めても、その動きまで攻撃者に把握される恐れがあります。トレイルの出力先変更（UpdateTrail）やシンクの付け替えを制限・監視することで対処します。
Q4. これは新しい脆弱性（ゼロデイ）ですか？パッチで対応できますか？
A. いいえ。CloudTrailやCloud Loggingが本来備える正規の管理機能を、権限を奪った攻撃者が悪用する手口です。パッチで塞げる種類の問題ではなく、権限設計とログ保護の運用で守る必要があります。MITRE ATT&CKでは技術ID T1562.008として整理されています。
Q5. SOCがない中小企業でも、最低限やるべきことは何ですか？
A. まず「ログを止められる権限を持つ人」を洗い出して数を絞ること、次に「ログ停止・削除イベントの通知設定」を入れることの2つです。この2点だけでも攻撃者の難易度は大きく上がります。加えてログ保存バケットのバージョニング有効化と整合性検証の有効化が、低コストで効果の高い対策です。
Q6. 自社のクラウド環境のどこから点検を始めればよいですか？
A. 「誰がCloudTrailやログバケットを停止・削除できるか」の権限棚卸しから始めてください。そのうえで、ログ機能への操作（停止・削除・出力先変更・鍵操作）を高優先度のアラート対象に設定すれば、攻撃の早期検知につながります。本記事の対応表をチェックリストとして活用してください。
