セキュリティ・コンプライアンス

CSPM・CWPP導入で週500件アラートの地獄を脱出した話

CSPM・CWPPを導入したら週500件のアラート地獄に。3ヶ月で実装した優先順位付け・自動修復・運用体制で、どうやって地獄から抜け出したのか。

セキュリティCSPMCWPPAWSクラウドセキュリティ

CSPMとCWPPに手を出して、地獄を見た

先日プロジェクトでCSPMとCWPPを導入したんですが、正直ハマりました。特に最初の3ヶ月は毎週500件以上のアラートが出ていて、チーム全体が「これどうすんの？」状態になってたんですよね。教科書的には「セキュリティの可視化が進む」みたいに書いてありますけど、実務は全然違う。今日は、うちのチームが痛い思いをしながら辿り着いたベストプラクティスを、素直に書こうと思います。

アラート週500件の地獄、何が起きてたか

最初は「セキュリティツール導入！よし監視だ」みたいなノリで、Prisma Cloud（旧Twistlock）とCrowdStrike Falcon Horizon を入れたんです。そしたら初日から大変。S3バケットの設定がちょっと甘いだけでアラート、IAMポリシーが最小権限じゃないのもアラート、CloudTrailログが古いのもアラート…要するに「既存環境の問題を全部見える化した」状態になっちゃった。

うちのチームは月額15万円のセキュリティ運用予算で対応してるんですが、500件/週だと1件あたり平均3分で処理しないと追いつかないんですよ。現実には不可能です。最初の3週間、朝礼でアラート数が増える増える言い合ってて、もう導入失敗した…と思ってました。

でも、実装を工夫してみたら劇的に変わったんです。

ステップ1：フィルタリングと優先度付けの仕組み化

一番効いたのは「全部対応する」から「本当に必要なのだけ対応する」に切り替えたこと。

ポリシーのカスタマイズ

ツール設定で最初から組み込まれてる検出ポリシーって、結構広めに作られてるんですよ。本来はそれでいいはずなんですが、うちの場合は以下みたいな除外ルールを設定しました：

# Prisma Cloud ポリシー除外例
excluded_resources:
  - tag:"Environment=dev" # 開発環境は許容
  - resource_name:"*-temp-*" # 一時リソースはスキップ
  - account_id:"xxxxxxx" # サンドボックスアカウント

risk_threshold: "high" # 初期段階はHighとCriticalだけ

これだけで週500件が週80件に減りました。アラート量が減ると、チームの心理状態も全然違うんですよね。「対応できそう」という感覚が生まれる。

自動修復パイプラインの構築

それでも週80件は多いので、次に「自動修復」を実装しました。うちで最も多かったアラートが以下3パターンだったので、これらは CloudFormation + Lambda で自動化しました：

  • S3パブリックアクセス設定が有効になってる → 自動で無効化
  • CloudTrailが無効になってる → 自動で再有効化
  • Security Groupで0.0.0.0/0からのSSHアクセス許可 → 自動削除
# Lambda による自動修復の例（S3パブリックアクセス設定）
import boto3

s3 = boto3.client('s3')

def remediate_s3_public_access(bucket_name):
    try:
        s3.put_public_access_block(
            Bucket=bucket_name,
            PublicAccessBlockConfiguration={
                'BlockPublicAcls': True,
                'IgnorePublicAcls': True,
                'BlockPublicPolicy': True,
                'RestrictPublicBuckets': True
            }
        )
        return {'status': 'success', 'bucket': bucket_name}
    except Exception as e:
        return {'status': 'failed', 'error': str(e)}

この自動修復で週80件が週40件に減りました。残りの40件は、人間の判断が必要なやつばっかり。つまり、チームが実際に考えるべきセキュリティ課題だけが残ったわけです。

AWS構成図：CSPM・CWPP統合の監視体制

graph TB
    subgraph "Multi-Account Environment"
        subgraph "Monitoring Account"
            CSPM["Prisma Cloud<br/>CSPM"]
            CWPP["Falcon Horizon<br/>CWPP"]
            SEC_HUB["AWS Security Hub"]
        end
        
        subgraph "Workload Accounts"
            Acc1["Account A<br/>Production"]
            Acc2["Account B<br/>Development"]
            Acc3["Account C<br/>Staging"]
        end
    end
    
    subgraph "Remediation Layer"
        EVENTBRIDGE["EventBridge<br/>Alert Router"]
        LAMBDA["Lambda<br/>Auto Remediation"]
        SSM["SSM Automation<br/>Manual Fix"]
    end
    
    subgraph "Alerting & Response"
        SLACK["Slack Notifications"]
        JIRA["Jira Tickets"]
        INCIDENT["On-Call PagerDuty"]
    end
    
    CSPM -->|"High/Critical Alerts"| EVENTBRIDGE
    CWPP -->|"Runtime Violations"| EVENTBRIDGE
    SEC_HUB -->|"Aggregated Findings"| EVENTBRIDGE
    
    EVENTBRIDGE -->|"Auto-fixable"| LAMBDA
    EVENTBRIDGE -->|"Manual review"| SSM
    
    LAMBDA -->|"Success/Failure"| JIRA
    SSM -->|"Remediation steps"| SLACK
    JIRA -->|"Critical"| INCIDENT
    
    Acc1 -->|"Agent installed"| CWPP
    Acc2 -->|"Agent installed"| CWPP
    Acc3 -->|"Agent installed"| CWPP

ステップ2：チーム責任分担と運用体制

アラート数を減らすだけじゃ足りなくて、「誰が対応するのか」という運用体制も決める必要があったんです。

セキュリティ対応SLAの定義

うちは以下のような対応時間を決めました。これがあるとないじゃ、チームの動き方が全然違うんですよね。

リスク水準検出パターン対応時間対応者
Criticalネットワーク外部公開、認証情報露出1時間Security Engineer
High暗号化未設定、ポリシー逸脱24時間Infrastructure Team
Mediumロギング設定、タグ付け漏れ1週間各チーム
Lowベストプラクティス違反要検討Documentation

これを決めてから、属人化が減りました。「あのアラートは誰が見るんですか？」という質問もなくなったし、対応漏れも減った。

週次セキュリティレビュー

毎週水曜の10時に15分間の「セキュリティハイライト」というミーティングを設定しました。そこでやることはシンプル：

  1. 週のアラート傾向（増減パターン）
  2. 自動修復が成功した件数
  3. 「解決すべき」ものリストの更新
  4. ブロッカーがあれば共有

最初は「また15分？」みたいな顔してたけど、3週目くらいから「あ、このアラート増えてるな」みたいに気づき始めたんですよね。セキュリティが「他人事」から「自分たちの問題」に変わっていく瞬間でした。

ステップ3：False Positiveとの付き合い方

正直ね、CSPM・CWPPを使うと「これセキュリティ問題じゃなくね？」みたいなアラートも増えるんです。

例えば、うちの開発環境専用のS3バケット。テスト目的で一時的にログを保存するのに、ツールは「CloudTrail設定がない」ってアラートを出してた。でも開発環境だし、そんなに必要ないんですよ。

False Positiveの分類

こういう「実際には問題じゃない」アラートを整理するために、以下のように分類しました：

{
  "false_positive_categories": {
    "environment_specific": {
      "description": "開発環境など、リスク許容度が高い環境",
      "action": "除外ルール追加",
      "approval": "Team Lead"
    },
    "operational_necessity": {
      "description": "セキュリティと業務効率のトレードオフ",
      "action": "リスク承認書",
      "approval": "Security + PO"
    },
    "tool_limitation": {
      "description": "ツールの検出ロジック不完全",
      "action": "ベンダーに報告、ポリシーカスタマイズ",
      "approval": "Security Engineer"
    }
  }
}

「なぜこのアラートが出てるのか」を理解することで、実は何が大事かが見えてくるんです。単純に「アラート消す」じゃなくて「このアラートの背後にあるリスクは何か」を考えるクセがつくんだ。

ステップ4：ベストプラクティス—実装レベルでのCSPM活用

3ヶ月目から、うちはCSPM・CWPPを「検知ツール」から「自動化の仕組み」に昇華させました。

IaC（Infrastructure as Code）との統合

CloudFormation や Terraform にポリシーチェックを組み込むことで、そもそも問題のあるリソースを作らない作戦です。これが地味に便利で、デプロイ段階でバグを潰すみたいにセキュリティも潰せるんですよね。

# CloudFormation Hooks を使った事前チェック
Resources:
  MyS3Bucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub 'my-secure-bucket-${AWS::AccountId}'
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: AES256
      VersioningConfiguration:
        Status: Enabled
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true

こういう「セキュアなデフォルト」をテンプレート化することで、検知→修復のループが高速化しました。

CI/CDパイプラインへの組み込み

Prisma CloudのCLIツールをGitHub Actionsに組み込んで、PRの段階でセキュリティチェックができるようにしました。

name: CSPM Security Scan
on: [pull_request]
jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Scan IaC with Prisma Cloud
        run: |
          prisma cloud code scan \
            --files . \
            --format json \
            --severity high,critical
      - name: Comment on PR
        if: failure()
        uses: actions/github-script@v6
        with:
          script: |
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: '⚠️ セキュリティチェックで問題が見つかりました。詳細はスキャン結果を確認してください'
            })

これで「セキュリティは本番環境で対応するもの」から「開発段階で解決するもの」に変わりました。レビュー時点で「あ、これセキュリティ的にダメだ」って気づけるから、本番で慌てなくていいんです。

アラート推移とROIの見える化

実装から3ヶ月で、うちのチームはこんな変化を実現しました：

xychart-beta
    title CSPM・CWPP導入3ヶ月のアラート推移
    x-axis [Week1, Week2, Week3, Week4, Week5, Week6, Week7, Week8, Week9, Week10, Week11, Week12]
    y-axis "Weekly Alerts" 0 --> 550
    line [520, 510, 505, 200, 190, 150, 140, 85, 80, 75, 45, 40]
    line [0, 0, 0, 0, 0, 0, 15, 30, 40, 45, 50, 48] title "Auto Remediated"

アラートが92%削減されたのもあるけど、重要なのは「チームが対応すべきセキュリティ問題」が明確に見えるようになった点です。

地味だけど効いた工夫

1. Slack通知の工夫

最初はアラート全部をSlackに流してたんですが、チャンネルが地獄になりました。今は以下のように分けてます：

  • #security-critical ← 1時間対応のやつだけ
  • #security-weekly ← 日次ダイジェスト
  • #security-remediated ← 自動修復成功のログ（チームの安心感のため）

これだけで心理的な負担がめちゃくちゃ軽くなりました。通知疲れって本当にあるんですよね。

2. ダッシュボードの活用

Prisma CloudとFalcon Horizonのダッシュボードを、チームのモニタリングTVに映すことにしました。毎日目に入ることで、セキュリティ意識が自然に上がるんですよね。「あ、また同じ種類のアラート出てる」とか「数字が減ってきた」っていう変化に気づくようになる。

3. リスク定量化

アラート件数だけじゃなく、「このセキュリティギャップがあると何が起きるのか」を金銭的に定量化することにしました。例えば：

  • CloudTrailが無効 → 監査ログ喪失 → SOC2失格リスク → 既存顧客との契約違反
  • S3パブリック公開 → データ流出 → GDPR罰金 → 最大2000万円

こうやって「金銭リスク」で見ると、経営層とのコミュニケーションもずっと楽になります。セキュリティの話が「技術的な安全性」から「ビジネスリスク」に変わると、優先度の付け方も変わるんだ。

2026年時点でのツール比較

うちが導入前に検討した主要ツールの比較です。個人的な印象を正直に書いてます：

ツールCSPM機能CWPP機能自動修復価格帯オススメ度
Prisma Cloud⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐月$2000~⭐⭐⭐⭐⭐
Falcon Horizon⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐月$1500~⭐⭐⭐⭐
Wiz⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐月$3000~⭐⭐⭐⭐
Snyk⭐⭐⭐⭐⭐⭐⭐⭐月$1200~⭐⭐⭐

正直、CSPM・CWPPは「どのツール選ぶか」よりも「運用をどう設計するか」が99%重要なんですよね。うちがPrisma Cloud + Falcon Horizonで落ち着いたのは、統合が比較的スムーズだったからってだけです。Wzだって良いツールだけど、運用がしっかりしてなけりゃ同じ地獄になってたと思う。

まとめ

CSPM・CWPP導入で週500件のアラート地獄に落ちてから、3ヶ月で40件まで圧縮できたのは以下5つを実装したから：

  1. ポリシーカスタマイズ ── 除外ルール、リスク閾値を最初から適切に設定する
  2. 自動修復パイプライン ── パターン化できるアラートは即Lambda化する
  3. チーム運用体制 ── SLA定義、週次レビュー、責任分担を明確に
  4. False Positive整理 ── アラートの理由を「なぜ？」で掘り下げる
  5. IaC・CI/CDとの統合 ── 本番検知じゃなく、開発段階での品質チェック

セキュリティツールは「導入したら終わり」じゃなくて、むしろそこから運用が始まるんです。最初の3ヶ月が地獄なのは仕様。その先の3ヶ月で「セキュリティが自分たちの強み」に変わる。

個人的には、SOC2対応やZTA（ゼロトラストアーキテクチャ）の実装を検討してるなら、CSPM・CWPPは今から入れるべきだと思います。なぜなら、コンプライアンス審査までに時間があれば、運用を整えられるから。導入直後の地獄を乗り越えて、監査の時に「うちのセキュリティ体制、ちゃんと見える化できてますよ」と胸張って言える状態になれるんですよ。そこまでのプロセスはハードですけど、その先は本当に違う。

U

Untanbaby

ソフトウェアエンジニア｜AWS / クラウドアーキテクチャ / DevOps

10年以上のIT実務経験をもとに、現場で使える技術情報を発信しています。 記事の誤りや改善点があればお問い合わせからお気軽にご連絡ください。

関連記事

セキュリティ・コンプライアンス

CSPM・CWPP導入3ヶ月、アラート週500件の地獄から学んだこと｜AWSマルチアカウント運用記

セキュリティ・コンプライアンス

SCP本番1年半で発見した、IAMとの組み合わせで権限が機能しない7つのケース

セキュリティ・コンプライアンス

AWS WAFマネージドルールを全有効化したら本番が死んだ話と、1年半で辿り着いた設定戦略

セキュリティ・コンプライアンス

PrivateLink 3年本番運用で踏んだ地雷と、最初から知りたかった設計の話

セキュリティ・コンプライアンス

GuardDuty運用2年、アラート1日500件の地獄から抜け出した話

セキュリティ・コンプライアンス

SOC2審査で3ヶ月ハマったCloudTrail・Config失敗記。本当に動く監査設計を実装コード付きで

← 記事一覧に戻る