クラウド事故の主因は「脆弱性」よりID・設定・データにある

副題：6つの典型リスクとコントロール

想定読者：クラウドセキュリティ担当、IAM担当、SOC、システム設計者

第1回では、クラウドに移してもデータ、ID、アクセス管理の責任は利用者に残ることを見ました。本稿では、その「残る責任」の領域で実際に何が起きているのかを確認し、典型的なリスクと、それを抑えるコントロールを整理します。

1. 事例：基盤は破られていないのに、165組織が影響を受けた

2024年6月、MandiantはクラウドデータサービスSnowflakeの利用企業を狙った攻撃キャンペーンを報告しました。データの窃取と恐喝の対象として、約165の組織に通知が行われています。

注目すべきは原因です。Mandiantの調査では、Snowflake自体の環境が侵害された証拠は見つかっていません。攻撃者が使ったのは、利用者側の正規の認証情報でした。

どれも、第1回で見た「利用者に残る責任」の領域です。

Cloud Security Allianceが2024年8月に公表した「Top Threats to Cloud Computing 2024」でも、上位を占めたのは利用者側の管理に関わる項目でした。

システムの脆弱性は8位です。クラウドでは、ソフトウェアの欠陥より、使い方の誤りが事故を生むことがわかります。

図1　クラウドの6つの典型リスクと、予防・検出のコントロール（© ProSol）

リスク	典型的な状態	主なコントロール
① 過剰な権限	使っていない管理者権限、期限のないアクセスキー	最小権限、定期的な棚卸し、特権の一時付与
② 弱い認証	多要素認証なし、退職者やサービス用アカウントの放置	全アカウントの多要素認証、接続元の制限、条件付きアクセス
③ 公開設定の誤り	ストレージの一般公開、通信制御の全開放	組織ポリシーで禁止、設定の継続監視
④ 秘密情報の管理	コードや設定ファイルに埋め込まれたパスワードやキー	秘密情報の専用管理サービス、コードの検査、定期的な更新
⑤ SaaSの共有設定	「リンクを知っている全員」での共有、外部ゲスト、連携アプリへの過大な権限	外部共有の既定値を制限、連携アプリの承認制、SaaS設定の監視
⑥ 監査ログ不足	ログが無効、保存期間が短い、上位プランでしか取れない	契約時にログ要件を確認、SIEMへの連携

①と②はID、③と⑤は設定、④と⑥はデータと証跡の領域です。とくに①と②は、Series 03で扱ったID攻撃と同じ構図です。クラウドの管理者アカウントは、オンプレミスのドメイン管理者と同じ重さで守る必要があります。

クラウドの設定やIDは、日々の開発や運用で変わり続けます。年1回の診断では追いつきません。必要なのは、あるべき状態から外れていないかを継続的に点検する態勢の管理です。

金融庁のガイドラインも、クラウド利用時の基本的な対応事項として、情報公開等の設定にミスがないか確認すること、サービス仕様が変わる際に影響を確認することを求めています。監視については、責任分界に応じてクラウドサービスも対象に含めるよう求めています。

クラウドの事故は、基盤の高度な脆弱性よりも、多要素認証のないアカウント、開きっぱなしの設定、管理されていない秘密情報から起きています。どれも利用者の責任の領域であり、裏を返せば、自組織の取り組みで防げるリスクです。

次回は、自組織では防げないリスク、つまりクラウド事業者の大規模障害、特定事業者への集中、撤退（Exit）をどう管理するかを扱います。

本記事は公開情報に基づく一般的な解説です。事例は公表された調査報告に基づくもので、特定の事業者や製品の安全性を評価するものではありません。