なぜマルチクラウド環境でCNAPPが必要なのか

はじめに

パーソル＆サーバーワークスの河野です。

AWSを中心としたクラウドインフラの設計・運用を担当しています。
最近は就業先でCNAPP（Cloud Native Application Protection Platform）の導入に関わる機会があり、AWS担当の立場からクラウドセキュリティについて学んでいます。

今回は 「なぜマルチクラウド環境でCNAPPが必要なのか」 について、
実際に導入に関わった経験をもとに紹介します。

CNAPPに関わり始めた経緯

就業先では AWS / Azure / Google Cloud を複数部門で利用していました。

しかし、クラウドごとに管理方法や評価基準が異なるため、
セキュリティ統制や監査、例外管理を全社で統一して実施することが難しい状況でした。

そこでセキュリティ部門とクラウド基盤部門が課題を整理し、
全社利用する3クラウドを対象にCNAPPを導入する方針となりました。

私はAWS担当として導入に関わることになり、CNAPPについて学び始めました。

CNAPPとは

CNAPP（Cloud Native Application Protection Platform）は、クラウド環境のリスクを横断的に検出・評価・管理する仕組みです。

CNAPPには複数のセキュリティ領域が含まれています。

CSPM（Cloud Security Posture Management）

クラウド設定や構成ミスを検出します。以下に例を示します。

• S3バケット公開
• Security Groupの過剰開放
• 暗号化未設定

DSPM（Data Security Posture Management）

機密データの発見や分類を行います。以下に例を示します。

• 個人情報
• 認証情報
• 機微データの露出

CWPP（Cloud Workload Protection Platform）

ワークロードの脆弱性を検出します。以下に例を示します。

• EC2
• コンテナ
• Lambda

CIEM（Cloud Infrastructure Entitlement Management）

権限を可視化し、過剰権限を発見します。以下に例を示します。

• 外部共有
• 未使用権限
• 過剰権限

Exposure Management

攻撃者から見たリスクを評価します。以下に例を示します。

• インターネット公開
• SSH/RDP公開
• 外部から到達可能なリソース

単なる設定ミスだけではなく、「本当に攻撃されやすいか」 という観点で評価することが特徴です。

AWSだけでもかなり対応できる

実はAWSだけであれば、多くのクラウドセキュリティ課題に対応できます。 代表的なサービスとして以下があります。

• Security Hub CSPM
• Inspector
• GuardDuty
• IAM Access Analyzer
• CloudTrail

AWS単体であれば、これらを組み合わせることで十分なセキュリティ体制を構築できます。

本当に難しいのはマルチクラウド

問題は、AWS / Azure / Google Cloud を横断して統制したい場合です。

例えば次のような課題があります。

• AWS / Azure / GCP を同じ基準で評価したい
• クラウドごとに機能やルールが異なる
• 全社共通ルールを適用したい
• 例外管理を一元化したい
• 監査結果を横断して説明したい
• 経営向けレポートをまとめたい

AWSだけならAWSのルールを理解すればよいですが、マルチクラウドでは各クラウドのサービスや評価基準を理解する必要があります。 導入検討時に感じたのは、クラウドごとの機能不足ではなく、全体をどう統制するか が課題だということでした。

CNAPPを使う理由① クラウドごとの差異を統制する

AWS・Azure・Google Cloudには似た機能があります。

しかし、以下は統一されていません。

• サービス名
• 実装方法
• ルール体系

CNAPPの目的は、各クラウドの機能を置き換えることではありません。
中央管理部門が、以下を実施できるようにすることです。

• リスクの集約
• 横断的な評価
• 利用部門への対応依頼

CNAPPを使う理由② 利用者の自己解決を支援する

CNAPP製品の多くは、利用者自身が問題を解決しやすい機能を提供しています。

例えば、

• インターネット公開経路の可視化
• 修正方法の提案
• AIによる支援
• 推奨修正の提示

などです。

利用者は自力で問題を調査しやすくなり、セキュリティ部門や運用担当者の負荷も軽減できます。
クラウド利用が拡大しても運用がスケールしやすいことも大きなメリットです。

CNAPPを使う理由③ 攻撃経路を考慮して優先順位を判断する

CNAPPの大きな特徴の一つが、複数のリスク情報を組み合わせて優先順位を判断できること です。

例えば、

• CriticalなCVE
• 高いEPSS
• インターネット公開状態
• 過剰権限の存在

という条件が重なる場合、優先度は高くなります。
逆に深刻度が高い脆弱性であっても、到達不可能な環境であれば優先順位は下がるかもしれません。
単純に脆弱性件数だけを見るのではなく、攻撃経路を踏まえて本当に危険なものから対処する ことができます。

CNAPPなしとCNAPPあり

CNAPPなし

• 各クラウドを個別管理
• 監査結果を手作業集計
• 優先順位は担当者依存

CNAPPあり

• リスクを横断集約
• 統一基準で評価
• 優先順位を自動算出
• 監査報告を一元化

マルチクラウド環境では、この差が運用負荷や監査対応に大きく影響します。

まとめ

• AWS単体ならネイティブサービスで対応可能
• 難しいのはマルチクラウド統制
• CNAPPはリスクを横断集約し統一基準で評価する
• 攻撃経路を考慮して優先順位付けできる
• 運用負荷の低減にもつながる

今回の結論はシンプルです。

CNAPPは「クラウドを守る製品」ではなく、「マルチクラウドを同じ基準で統制するための仕組み」です。

マルチクラウド活用が進む組織では、セキュリティ機能そのものよりも、全体をどのように統制するかが重要になります。

また面倒が増えるのかと思うかもしれません。
ですが、その面倒さは全社でクラウド活用を推進するために必要なものでもあります。
そのための選択肢の一つがCNAPPなのではないでしょうか。

次回予告

CNAPPを導入すると決まったら次に考えることは、

• どの製品を選ぶのか
• どんな観点で比較するのか
• 本当に期待通りの動きをするのか

です。

次回は 「CNAPPの製品選定 ～ 動きを検証しよう」 について紹介したいと思います。

この記事は私が書きました

河野

記事一覧

ヨシ！