クラウドコンピューティングは、ネットワーク境界をなくし、制御をIDとAPIアクセスに移行させ、手動のSOCワークフローでは攻撃が必要とする速度で処理できない大量のテレメトリーを生成することで、セキュリティ運用を変革します。 手動のSOCワークフロー 攻撃が必要とする速度で処理できません。オンプレミスツールとオンプレミスワークフローでクラウドに移行したセキュリティチームは、データセンターで機能したものがクラウドでは通用しないことをすぐに発見しました。攻撃対象領域が異なり、テレメトリーが異なり、従来の検知ロジックの根底にある前提がもはや通用しないのです。
これらの変化を構造レベルで理解することが、クラウド環境で実際に機能するセキュリティ運用を構築するための出発点となります。
共有責任モデルが防御の責任範囲を変える
クラウドプロバイダーは共有責任モデルの下で運用されており、プロバイダーと顧客間のセキュリティ義務の分担は契約によって定義され、サービスタイプによって異なります。IaaS（Infrastructure as a Service）の場合、プロバイダーは物理インフラ、ネットワークハードウェア、ハイパーバイザーを保護します。オペレーティングシステム、アプリケーションランタイム、構成、ID管理、データ処理を含むハイパーバイザーより上のすべては顧客の責任です。
マネージドサービスやSaaS製品の場合、プロバイダーがより多くのスタックを担当しますが、顧客は依然としてアクセス制御、データ分類、アクティビティ監視の責任を負います。誤って設定された権限境界、過度に許可されたAPIトークン、または監視されていない管理者アカウントは、プロバイダーのインフラが正しく機能しているかどうかに関わらず、顧客側の障害となります。
これはセキュリティ運用にとって重要です。なぜなら、カバレッジモデルを変更する必要があることを意味するからです。ネットワーク層の制御とエンドポイントエージェントに依存していたチームは、今やコントロールプレーン、ID層、データプレーンを明示的に計測する必要があります。 NIST SP 800-210 は、クラウド環境におけるアクセス制御について考える上で有用なフレームワークを提供しますが、運用上の疑問はより単純です。もし明日、クラウドプロバイダーが鍵を引き渡したら、あなたの環境で何が起こったかすべて把握できるでしょうか？
攻撃対象領域が変化し、新しい検知モデルが必要となる
クラウドへの移行は攻撃対象領域を縮小しません。異なる検知アプローチを必要とする形で再構成します。
オンプレミス環境では、攻撃者は通常、境界を介して侵入し、内部ネットワークパスを介して横方向に移動しました。侵害された認証情報は目的を達成するための手段でした。クラウド環境では、 侵害された認証情報がしばしば最終目標となります。なぜなら、盗まれたIAMロールや長期間有効なAPIキーは、ネットワークを一切経由することなく、ストレージ、コンピューティング、データベース、デプロイメントパイプラインに直接アクセスを提供できるからです。MITRE ATT&CK cloud matrixによると、 MITRE ATT&CK cloud matrixクラウドIAMの誤設定による認証情報アクセスと特権昇格は、今やクラウドネイティブな侵入で最も一般的に観測される手法の一つです。
誤設定は、オンプレミスに実質的な同等物がない、第二の明確な攻撃対象領域のカテゴリを構成します。公開アクセス可能なストレージバケット、過度に許可されたインバウンドルールを持つセキュリティグループ、または本番インフラへの書き込みアクセス権を持つワークロードIDは、攻撃者が作成するために労力を費やす必要のない悪用可能な条件を作り出します。彼らはそれらを単に見つけるだけです。悪用される前に誤設定を特定する、または悪用と一致するアクセスパターンを検知する検知ロジックは、あらゆるクラウドセキュリティ運用プログラムの不可欠な部分です。
エフェメラルワークロードは第三の課題を生み出します。コンテナ化されたアプリケーション、サーバーレス関数、オートスケーリンググループは、置き換えられる前に数秒間実行されることがあります。エフェメラルワークロード内で発生する攻撃活動はリアルタイムで捕捉されなければなりません。なぜなら、人間のアナリストがアラートを確認する頃には、そのアーティファクトは存在しないためです。
クラウドコンピューティングがもたらすクラウドセキュリティリスク
クラウドコンピューティングへの移行はセキュリティリスクを再構成し、いくつかのケースでは、オンプレミスに直接的な同等物がないリスクのカテゴリを導入します。
誤設定は最も一般的なクラウドセキュリティリスクです。IBM IBM などの調査は、クラウド侵害における主要な初期アクセスベクトルとして誤設定を一貫して特定しています。インフラの変更が遅く手動でレビューされていたオンプレミス環境とは異なり、クラウド環境では、認証されたユーザーであれば誰でもAPIを介して数秒でリソース構成を変更できます。単一の過度に許可されたIAMポリシー、公開読み取りアクセス権を持つストレージバケット、または公開された管理ポートは、誰も気づかないうちに数ヶ月間持続する悪用可能な条件を作り出す可能性があります。
ID関連のリスクはクラウド導入とともに拡大します。新しいサービス、統合、チームごとに新しいIDが生成されます。ユーザーアカウント、サービスアカウント、マシン認証情報、OAuthトークン、APIキー、フェデレーションロールなどです。これらの多くは過剰な権限を持ち、文書化が不十分で、めったにローテーションされません。 CISAのクラウドセキュリティに関するガイダンス は、クラウドネイティブ組織にとって最も深刻なリスクカテゴリとして、認証情報の盗難とIDの悪用を一貫して強調しています。なぜなら、十分な権限を持つ盗まれたIDは、ネットワークレベルのアラートをトリガーすることなく、重要な資産に到達できるためです。
クラウドストレージサービスはデータを共有可能に設計されているため、データ漏洩のリスクが増大します。チームの生産性を高めるコラボレーション機能は、偶発的または意図的なデータ漏洩の経路も作り出します。データ損失に関連するクラウドセキュリティリスクは、外部の攻撃者からではなく、過剰な権限を持つ認証済みユーザーや誤設定された共有設定から発生することが多いです。
サプライチェーンとサードパーティのリスクは、クラウド固有の形をとります。SaaSアプリケーション、クラウドマーケットプレイス統合、CI/CDパイプラインの依存関係はすべて、組織が直接制御する範囲を超えて実効的な攻撃対象領域を拡大する信頼関係を表します。サードパーティ関係によって導入されるクラウドセキュリティリスクを理解し監視するには、OAuth付与、APIアクセス、およびほとんどのセキュリティ運用プログラムが不完全に監視しているSaaS間信頼チェーンに対する可視性が必要です。
これらのクラウドセキュリティリスクを認識することが第一歩です。より困難な作業は、これらのリスクが積極的に悪用されている時期を特定できる検知および対応機能を構築することであり、それこそが クラウドセキュリティ運用 が最終的に行うように設計されていることです。
クラウド環境に特有の検知の課題
クラウド環境は、オンプレミスのセキュリティ作業には直接的な類似物がない検知の問題を導入します。
ログの量は最もすぐに明らかになります。中規模のクラウド環境では、コントロールプレーンログ、VPCフローログ、データアクセスログ全体で1日に数億件のAPIコールを生成する可能性があります。それらすべてを 従来のSIEMに取り込むことは高価で、多くの場合非現実的です。そして、ログのサンプリングやフィルタリングによってコストを削減しようとするチームは、攻撃者が悪用する盲点を頻繁に作り出します。答えは必ずしもすべてをどこでも取り込むことではありませんが、何を監視し、何を監視しないかについて意図的で文書化された決定を下し、それらの決定が作り出す検知のギャップを実際に理解することです。
短命なリソースは、解決がより困難な可視性ウィンドウの問題を引き起こします。侵害されたLambda関数は、3秒の実行ウィンドウ内でデータを外部に持ち出し、終了する可能性があります。イベントを処理する前にバッファリングする検知システムは、その活動を完全に逃すでしょう。クラウドセキュリティ運用には、イベントストリームのほぼリアルタイム処理が必要です。
クロスアカウントアクティビティは、検知が最も一般的に破綻する場所です。ステージングアカウントの侵害された開発者IDから、引き受けたロールを介して本番アカウントに移動する攻撃者は、信頼境界をまたぐ多段階のチェーンを実行しています。ほとんどのSIEMは、アカウントレベルの監査ログを横断して相関させるようには構築されていません。それは、単一のネットワークセグメント内のイベントを相関させるのとは構造的に異なる問題であり、それに対処していない組織は、攻撃が最もエスカレートしやすいまさにその点で検知のギャップを抱えています。
SOCワークフローがどのように適応すべきか
クラウドコンピューティングのワークフローへの影響は、セキュリティ運用のあらゆる機能に及びます。
アラートトリアージ は、クラウド固有のコンテキストを考慮する必要があります。サービスアカウントが異常なリソースにアクセスしているというアラートは、そのアカウントの通常の動作、実効権限、およびアクセスが既知のデプロイパターンと一致するかどうかに応じて、まったく異なる意味を持ちます。このコンテキストをエスカレートする前に取得しないトリアージワークフローは、高い誤検知率を生み出し、良性のインフラ活動にアナリストの時間を浪費させます。
調査には新しいデータソースと新しいスキルが必要です。クラウドインシデントを調査するアナリストは、IAM構造、フェデレーションロールの引き受け、VPC構成、SaaSアプリケーションの権限モデルを理解する必要があります。オンプレミス環境で結果を出す調査スキル（Windowsイベントログの読み取りやネットワークキャプチャの分析など）は、直接転用できません。 MITRE ATT&CK for Cloud は、クラウドインシデント分析に有用な語彙を提供しますが、運用上の熟練度には、特にクラウド環境での実践的な経験が必要です。
クラウド環境での対応アクションはAPI駆動型であり、オンプレミスでの対応とは異なり、元に戻すことが可能です。これは利点であると同時にリスクでもあります。認証情報の取り消しやIAMポリシーの変更は数秒で完了し、スクリプト化できます。しかし、対応を迅速にする同じAPIアクセス性は、対応が包括的でない場合、足がかりを保持している攻撃者が封じ込めアクションを迅速に元に戻すことができることも意味します。
マルチクラウドの複雑さと検知カバレッジ
ほとんどの組織は単一のクラウドプロバイダーで運用していません。コンピューティングにはAWS、特定のマネージドサービスには別のプロバイダー、コラボレーション、ID、開発には様々なSaaSプラットフォームを組み合わせることで、単一のテレメトリーソースでは完全な可視性を提供できない異種混合環境を作り出します。
マルチクラウド環境では、プロバイダー固有のロギングスキーマ間で正規化する検知カバレッジが必要です。AWS CloudTrail、Azure Activity Logs、GCP Audit Logsはそれぞれ異なるイベント構造、異なるプリンシパル表現、異なるリソース命名規則を使用します。CloudTrail用に書かれた検知ルールは、GCP Audit Logsに直接転用できません。あるプロバイダー向けに検知ロジックを構築し、それが他のプロバイダーもカバーすると仮定する組織は、侵害によって明らかになるまで気づかないギャップを抱えています。
SaaSアプリケーションはさらなる正規化の課題を提示します。IDプロバイダー、コードリポジトリ、コラボレーションプラットフォーム、チケットシステムはそれぞれ独自の形式でイベントログを生成します。侵害されたOktaセッションからGitHubリポジトリ、クラウドデプロイメントパイプラインへと移動するIDベースの攻撃チェーンを相関させるには、4つの異なるロギングスキーマにわたるイベントを結合する必要があります。これは対処可能ですが、テレメトリーがどのように収集、正規化、分析されるかについて意図的なアーキテクチャ上の決定が必要です。
効果的な クラウドセキュリティ運用 を大規模に行うには、ギャップに事後的に気づくのではなく、それらのアーキテクチャ上の決定を明示的に行うことを意味します。
大規模なクラウドセキュリティ管理におけるAI SOCの役割
クラウドセキュリティの運用要件、すなわち広範なテレメトリーカバレッジ、迅速なトリアージ、クロスアカウント調査、継続的な24時間365日対応は、妥当な予算で完全に人間のチームで満たすことは困難です。イベントの量、クラウド攻撃がエスカレートする速度、正確なトリアージに必要なコンテキストの広さは、人員数に比例してスケールしないワークロードを生み出します。
ある AI SOC はこれに直接対処します。AIエージェントは機械の速度でクラウドテレメトリーを処理し、異常な活動と通常の活動を区別するために行動ベースラインを適用し、アナリストが迅速に情報に基づいた意思決定を行うために必要なコンテキストを提供する、調査準備の整った結果を生成できます。人間のアナリストが実効権限、最近のID活動、リソースアクセス履歴、脅威インテリジェンスをまとめてコンパイルするのに何時間もかかる調査負担は、数秒で組み立てることができます。
クラウド環境で最も効果的に運用するチームは、通常、構造的に予測可能な作業（一次トリアージ、証拠収集、初期リスク評価）を自動化したチームです。人間のアナリストは、検知エンジニアリング、複雑な多段階調査、および組織のコンテキストと説明責任を必要とする対応決定に焦点を当てます。その分業は現在のツールで達成可能です。それは、従来の方法で人員を配置できないチームにとって、広範なクラウドセキュリティ運用を持続可能にするモデルです。
もしあなたのSOCがまだオンプレミス環境向けに設計されたワークフローでクラウドセキュリティに取り組んでいるなら、あなたが検知しているものとあなたの環境で実際に起こっていることとの間のギャップは、現在のメトリクスが示唆するよりも大きい可能性が高いです。あなたの運用モデルが実際に防御している環境向けに設計されているかどうかを評価する価値があるかもしれません。
よくある質問
クラウドコンピューティングはセキュリティ運用にどのような影響を与えますか？
クラウドコンピューティングはネットワーク境界を排除し、主要な制御をIDとAPIアクセスに移行させ、現代の攻撃が必要とする速度で手動ワークフローでは処理できない大量のテレメトリーを生成します。SOCチームは、クラウド固有の攻撃対象領域、エフェメラルワークロード、マルチクラウド環境を考慮して、検知ロジック、調査ワークフロー、および対応手順を適応させる必要があります。
クラウドに移行すると検知に関して何が変わりますか？
クラウド環境での検知は、ネットワークトラフィックではなく、コントロールプレーンのアクティビティ、IDの挙動、SaaSイベントストリームに焦点を当てます。IAMの誤設定や公開されたクラウドリソースを含む新しい攻撃対象領域には、オンプレミスに直接的な同等物がない検知モデルが必要です。ログの量とクラウドワークロードの短命な性質も、バッチ取り込みではなく、ほぼリアルタイムの処理を必要とします。
共有責任モデルとは何ですか、そしてなぜセキュリティ運用にとって重要なのでしょうか？
共有責任モデルは、クラウドプロバイダーと顧客の間でセキュリティ義務を分担します。プロバイダーは物理インフラとマネージドサービスを保護します。顧客は構成、アクセス制御、アクティビティ監視、データ保護に責任を負います。セキュリティ運用チームは、責任を負うスタックの部分を計測し監視する必要があります。これはサービスタイプによって異なります。
マルチクラウドの複雑さはセキュリティ運用にどのように影響しますか？
マルチクラウド環境では、複数のプロバイダーからの異なるロギングスキーマ、IAMモデル、イベント形式間で正規化する検知カバレッジが必要です。あるプロバイダー向けに書かれた検知ルールは、別のプロバイダーに自動的に適用されません。明示的なクロスプロバイダー検知ロジックを持たないチームは、インシデントによって明らかになるまで見えないカバレッジギャップを抱えています。
AI SOCはクラウドセキュリティ運用にどのように役立ちますか？
AI SOCは、クラウドセキュリティ運用を手動で人員配置することを困難にする、大量でコンテキスト依存の作業（一次アラートトリアージ、実効権限分析、クロスアカウントタイムライン再構築、初期リスク評価）を自動化します。これにより、人間のアナリストは、検知エンジニアリング、複雑な調査、および組織的な判断を必要とする対応決定に専念できます。
