マルチクラウド時代、ネイティブセキュリティだけでは守れない理由 ― AWS・GCP・Azureを横断する「攻撃」をどう防ぐか

Last updated at 2026-03-18Posted at 2026-03-18

title: マルチクラウド時代、ネイティブセキュリティだけでは守れない理由 ― AWS・GCP・Azureを横断する「攻撃」をどう防ぐか
tags:

AWS
GCP
Azure
Security
CNAPP
private: false

結論（先に）

マルチクラウド環境では、ネイティブセキュリティだけでは守れません。

理由はシンプルです。

攻撃者はクラウドをまたいで動く
ID（認証情報）はクラウドを横断する
ログと検知が分断されている

だから「統合」が必要になります。

この記事では、マルチクラウドセキュリティの構造的な問題を整理し、現実的な対策レイヤーを解説します。

想定読者

AWS・GCP・Azureのうち2つ以上を使っている
セキュリティ担当者、インフラ担当者
「ネイティブのセキュリティサービスで十分では？」と思っている人

よくある事故（リアル）

こういうインシデントは珍しくありません。

なぜ誰も気づかなかったか？

AWSチームはAWSしか見ていない。GCPチームはGCPしか見ていないから。

これがマルチクラウドのセキュリティ盲点です。

問題の本質：監視が「縦割り」になっている

ネイティブだけの世界（現状）

この構造の問題は「全体像を誰も持っていない」ことです。

統合された世界（目指す姿）

攻撃は「点」ではなく「線」で起きます。 縦割りの監視では線は見えません。

マルチクラウドが難しい3つの理由

① IAMポリシーの設計思想が全部違う

「最小権限の原則」はどのクラウドも同じですが、実装が全然違います。

クラウド	IAMの仕組み	権限のアタッチ先
AWS	Role / Policy	ユーザー・ロール・グループ
GCP	Binding（誰が・何を・どこに）	リソース階層
Azure	RBAC（ロールベース）	スコープ（サブスク/RG/リソース）

たとえばAWSの「S3 ReadOnly」に相当する権限を3クラウドで揃えるだけでも、設計コストが3倍かかります。

しかも「相互に参照できる構成（Workload Identity連携など）」を取ると、一方の設定ミスが他方への侵害につながります。

② ログの形式が統一されていない

3クラウドのAPIログをSIEMに集約しても、「同じユーザー」の行動を相関させるのが難しいです。

// AWS CloudTrail
{
  "userIdentity": {
    "userName": "john.doe",
    "arn": "arn:aws:iam::123456789:user/john.doe"
  }
}

// GCP Cloud Audit Logs
{
  "authenticationInfo": {
    "principalEmail": "john.doe@example.com"
  }
}

// Azure Activity Log
{
  "identity": {
    "claims": {
      "upn": "john.doe@example.com"
    }
  }
}

フィールド名が違う、形式が違う、タイムスタンプのタイムゾーンも違う。

これを手動で相関させるのは現実的ではありません。

③ チームが分断される（組織の問題）

技術的な問題だけでなく、組織の問題も大きいです。

「全体像を持つ人間がいない」というのが、マルチクラウドにおける最大のリスクです。

ネイティブツールの正直な評価

AWS Security Hub

得意： AWSリソースのコンプライアンス評価、GuardDutyとの統合
限界： AWSの外は見えない。GCP・Azureのイベントと相関できない。

GCP Security Command Center (SCC)

得意： GCPアセットの可視化、脅威検知
限界： GCP内で完結。他クラウドとの統合は限定的。

Microsoft Defender for Cloud

得意： Azure中心の脅威保護。AWSとGCPのエージェント接続も一部可能
限界： マルチクラウド対応はあるが、GCP・AWSのカバレッジはAzureより弱い。

カテゴリ	Security Hub	SCC	Defender for Cloud
自クラウド検知	◎ 90	◎ 90	◎ 90
他クラウド検知（2つ）	× 20	× 20〜60	△ 30〜50
ID・権限管理	△ 60	△ 50	○ 70
攻撃経路分析	△ 50	△ 40	△ 50
Runtime検知	△ 60	△ 60	○ 70

スコアは概念的な相対値（0〜100）です。各ツールは自クラウド内では強力ですが、クラウドをまたいだ分析には限界があります。

ネイティブツールが「不要」という話ではありません。後述しますが、ネイティブツールは基盤として不可欠です。

CNAPP（統合セキュリティプラットフォーム）とは何か

定義

CNAPP（Cloud Native Application Protection Platform）は、Gartnerが2021年に提唱した概念で、クラウドセキュリティの複数機能を1つのプラットフォームに統合したものです。

従来はバラバラのツールだったものを統合します。

CNAPPの3つの視点（ここが核心）

ただのツール統合ではありません。3つの視点を繋げて初めて意味を持ちます。

① Attack Path（攻撃経路分析）

「脆弱性 × 権限 × データ」を繋げて攻撃経路として可視化します。脆弱性単体では「深刻度: Medium」でも、権限とデータへの経路が繋がれば「実質的な最高リスク」になります。

② Identity（ID横断分析）

1つのIDが3クラウドでどんな権限を持っているかを横断的に把握します。

③ Runtime（実行時の挙動）

設定だけでなく「実際に何が動いたか」も監視します。
設定が正しくても、実行時に異常な挙動があれば検知します。

エージェントレス vs エージェント（よくある誤解）

誤解されていること

エージェントレス = 導入が簡単で十分
エージェント = 高度だが大変

これは誤りです。

正しい理解：補完関係

攻撃フェーズごとに役割が違います。

フェーズ	検知手段	エージェント要否
侵入（設定ミス起因）	CSPM	不要
権限昇格	CIEM	不要
マルウェア実行	Runtime Detection	必要
ファイル改ざん	File Integrity Monitoring	必要

「どちらが優れているか」ではなく「何を検知したいか」で選ぶ話です。

主要CNAPPツールの比較

ツール	強み	向いているケース
Wiz	攻撃経路分析（Attack Graph）が業界最強クラス。エージェントレス中心	攻撃経路の可視化を優先したい
Prisma Cloud（Palo Alto）	CWPP・CSPM・CIEMをフルカバー。エンタープライズ向け	大規模・規制業界
Orca Security	エージェントレスに特化。スナップショットベースのスキャン	導入コストを抑えたい
Lacework	機械学習による異常検知	振る舞い検知を重視したい
Sysdig	RuntimeとFalco統合が強い	コンテナ・K8sのRuntime監視が主目的

実践：現実的な3層構成

「全部入り」を一気に導入するのは難しいです。まずこの構成から始めましょう。

各レイヤーの役割

Layer 1（ネイティブ）
証跡・基本検知。CloudTrailは特に絶対に外せません。インシデント発生後の調査に必須です。

Layer 2（CNAPP）
横断的な可視化と相関分析。ここが「全体像を持つ」レイヤーです。

Layer 3（Runtime）
コンテナ・ホストレベルの実行時監視。Falcoはオープンソースで始められます。

Terraform実装例

CSPM用の読み取り専用ロール（AWS）

# CNAPP（Wizなど）がAssumeRoleするためのロール
resource "aws_iam_role" "cspm_role" {
  name = "cspm-readonly-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Principal = {
          AWS = var.vendor_account_arn  # CNAPPベンダーのAWSアカウントARN
        }
        Action = "sts:AssumeRole"
        Condition = {
          StringEquals = {
            "sts:ExternalId" = var.external_id  # 必須：Confused Deputy対策
          }
        }
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "cspm_readonly" {
  role       = aws_iam_role.cspm_role.name
  policy_arn = "arn:aws:iam::aws:policy/SecurityAudit"
}

# 追加で必要な権限（SecurityAuditに含まれない場合）
resource "aws_iam_role_policy" "cspm_extra" {
  name = "cspm-extra-permissions"
  role = aws_iam_role.cspm_role.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = [
          "access-analyzer:ListAnalyzers",
          "access-analyzer:ListFindings",
          "securityhub:GetFindings",
          "guardduty:ListDetectors",
          "guardduty:GetFindings"
        ]
        Resource = "*"
      }
    ]
  })
}

GCP用のサービスアカウント

resource "google_service_account" "cspm_sa" {
  account_id   = "cspm-readonly-sa"
  display_name = "CNAPP CSPM Service Account"
  project      = var.project_id
}

# 読み取り専用の閲覧者ロールをバインド
resource "google_project_iam_binding" "cspm_viewer" {
  project = var.project_id
  role    = "roles/viewer"

  members = [
    "serviceAccount:${google_service_account.cspm_sa.email}"
  ]
}

# セキュリティ関連の追加権限
resource "google_project_iam_binding" "cspm_security" {
  project = var.project_id
  role    = "roles/iam.securityReviewer"

  members = [
    "serviceAccount:${google_service_account.cspm_sa.email}"
  ]
}

ポイント

ExternalId は必須：Confused Deputy攻撃（第三者がロールをAssumeRoleするリスク）を防ぐために設定します
ReadOnly + AssumeRole が基本形：書き込み権限は絶対に付与しない
最小権限で始める：必要になったら追加するアプローチが安全

ネイティブツールの本当の価値（見直し）

「CNAPP があればネイティブ不要」という誤解があります。

逆です。ネイティブが基盤で、CNAPPはその上に乗るものです。

ネイティブツール	役割	代替可能か
CloudTrail / Cloud Audit Logs	証跡（フォレンジック）	不可
IAM	権限制御そのもの	不可
GuardDuty / SCC	ゼロレイテンシー検知	難しい

CloudTrailはインシデント後の「何が起きたか」を調べる唯一のソースです。これをオフにしたらサードパーティツールがあっても調査できません。

コストの現実

「ネイティブは無料で CNAPP は高い」という認識は不正確です。

ネイティブのみで3クラウドを適切に監視しようとすると、人件費と手動相関コストが積み重なります。

CNAPPの費用対効果を評価するときは、「ツール費用 vs ツール費用」ではなく「トータルコスト vs トータルコスト」で比較する必要があります。

一般的に、2クラウド以上を使い始めた時点でCNAPP導入のROIがプラスに転じるケースが多いです。

導入ステップ（現実的な進め方）

いきなり全部導入しようとすると失敗します。

Step 1：棚卸し（2〜3週間）

まず「何があるかを知る」ことから始めます。

全AWSアカウント・GCPプロジェクト・Azureサブスクリプションをリストアップ
IAMユーザー・サービスアカウントの棚卸し
ネイティブツール（CloudTrail・GuardDuty等）の有効化確認

棚卸しをサボるとPoCで偽陽性だらけになります。必ずやりましょう。

Step 2：PoC（30日）

1ベンダーに絞って30日間試します。

確認すること：

自社環境でのスキャンカバレッジ
アラートの質（偽陽性率）
既存ワークフローへの統合のしやすさ

Step 3：チューニング（2〜4週間）

PoCで出てきた大量のファインディングを仕分けします。

受け入れ可能なリスク（ビジネス上の例外）
即時修正が必要なもの
ロードマップで対応するもの

ここを丁寧にやらないと「アラートが多すぎて誰も見なくなる」状態になります。

Step 4：Runtime統合

安定してきたらRuntimeエージェントを展開します。
最初はステージング環境・重要なワークロードに絞るのが現実的です。

まとめ

マルチクラウドセキュリティの本質はこれです。

「ネイティブ × CNAPP × Runtime」の3層が今の正解です。

レイヤー	役割	代表ツール
ネイティブ	基盤・証跡・最速検知	GuardDuty, CloudTrail, SCC, Defender
CNAPP	横断可視化・攻撃経路・ID管理	Wiz, Prisma Cloud, Orca
Runtime	実行時挙動・コンテナ監視	Falco, Sysdig

マルチクラウドは複雑に見えますが、正しいレイヤーで分ければシンプルになります。

「うちはどこから手をつければいい？」という場合、まず Step 1の棚卸し から始めることをおすすめします。何があるかわからない状態でツールを入れても機能しません。

参考リンク

もし「うちの環境ではどうすればいい？」という具体的な話があれば、コメントでもXでも気軽にどうぞ。

@keitah0322

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up