Tenable Cloud Security機能解説 ～ エージェントレスで実現する次世代のクラウドリスク管理　～　第1回　クラウド運用における現状と管理上の課題

Tenable Cloud Securityは、AWS (Amazon Web Services)、Azure (Microsoft Azure)、Google Cloud (旧GCP)、OCI (Oracle Cloud Infrastructure)といったマルチクラウド環境全体のセキュリティを統合管理するSaaS型プラットフォームです。APIを介して各クラウドと連携する「エージェントレス」な仕組みにより、インフラの構築段階（IaC: Infrastructure as Code）から本番稼働中のワークロードまで、環境全体をシームレスに可視化します 。

この網羅的な可視化をベースに、ライフサイクル全体を通じた一貫した保護を実現します 。本稿では、同製品のコアとなるリスク分析エンジンや、運用の自動化を支援する各種機能、ガバナンスを支える仕組みについて全3回に分けて解説します 。

第1回の今回は、まず、クラウド運用における現状と管理上の課題について掘り下げていきます。

クラウド運用における現状と管理上の課題

Tenable Cloud Securityは、以下の機能を統合した CNAPP（Cloud Native Application Protection Platform）^*1) です。

• 防御・管理（インフラからデータまで）：
  • クラウド上の各サーバーの脆弱性（CWPP：ワークロード保護）
  • クラウド環境の設定ミス（CSPM：クラウドセキュリティ態勢管理）
  • 構築プログラムの不備（IaC：Infrastructure as Code のセキュリティ）
  • Kubernetes^*2) やAIなどの複雑な実行環境におけるセキュリティ（KSPM：Kubernetesセキュリティ態勢管理、AI-SPM：AIセキュリティ態勢管理）
  • 保存されたデータの保護（DSPM：データセキュリティ態勢管理）
• 分析・検知（挙動と権限）：
  • 「誰が何にアクセスできるか」の制御（CIEM：アイデンティティ設定のセキュリティ）
  • リアルタイムの不正利用監視（CDR：脅威の検出）

これほど多岐にわたる機能が求められるのは、クラウドの普及に伴い、従来の「個別の設定確認」だけでは対応できない複雑な課題が浮き彫りになっているためです 。現場が直面している課題は、主に以下の3点に集約されます 。

① 資産把握の「死角」と管理の属人化

• 現状
  AWS、Azure、Google Cloudといった複数のクラウドを併用することが一般的になり、各環境内で多くの仮想マシン（VM：Virtual Machine）やコンテナが稼働しています 。
• なぜ課題か
  セキュリティ管理ツールがクラウドサービスごとに独立しているため、組織全体の資産状況をひと目で横断的に確認できる「共通の窓口」がありません
• リスク（可視性の欠如）
  各環境の管理が担当者任せ（属人化）になりやすく、全社的な視点では「どの環境に、どの程度の資産が、どのような状態で存在しているか」という正確な全体像をリアルタイムに把握し続けることが困難になります 。この可視性の欠如が、結果として安全でない設定のまま残されたリソースの見落としなどに繋がります 。

② 「数値」と「実効リスク」の乖離 ～ 優先順位付けの迷走と致命的欠陥の見落とし　

• 現状
  従来のセキュリティツールは、検出された脆弱性にCVSS^*3)（共通脆弱性評価システム）などの一般的な深刻度を付与して通知します。
• なぜ課題か
  CVSSは「脆弱性そのものの危なさ」を示しますが、「自社の環境において本当に攻撃可能か」という文脈を考慮しません。その結果、修正が不要な箇所に工数を割き、裏で本当に危険な設定ミスが放置されるという、リソース配分のミスマッチが発生しています 。
• 実務上のミスマッチ
  スコアが高いからと優先的に対応した箇所が、実はインターネットから遮断された安全な場所にあったり、逆にスコアが低くても「特定の権限」と組み合わさることで致命的な侵入経路になるケースを見逃してしまいます。その結果、膨大なアラートに埋もれ、真に対応すべきリスクへの対処が後手に回るというリソース配分のミスが発生しています 。

③ 点の対策では防げない「複合リスク」の発生

• 現状
  クラウド環境は、サーバーの脆弱性、インフラの設定、ID・権限といった要素が網の目のように複雑に絡み合っています。これらを要素ごとに管理していても、要素間の依存関係が膨大かつ複雑すぎて、全体像を把握することが困難になっています。
• なぜ課題か
  攻撃者はこれらを単独ではなく、組み合わせて利用します。例えば、「脆弱性のあるサーバー」が「過剰な権限」を持っているといった、複数の小さな不備が繋がって一つの攻撃ルート（有害な組み合わせ）が完成する現象です 。現在のクラウド環境では、こうした「脆弱性×設定×権限」の組み合わせパターンが膨大かつ複雑すぎて、人間が目視や個別ツールで管理できる限界を超えています。 そのため、単体の不備を潰すだけの「点の対策」では、要素間の隙間に潜む侵入経路を特定・遮断できず、侵害を防ぎきれないのが実態です。
• リスク
  脆弱性スキャンや設定チェックといった単体（点）の対策だけでは、この「不備の繋がり」を見落としてしまいます。その結果、個々のリスクは低く見えても、実態としては深刻な侵入経路が放置されたままになり、侵害を防ぎきれないという事態を招きます。

*1) CNAPP（Cloud Native Application Protection Platform）
ガートナーの説明を引用すると、 クラウドネイティブアプリケーション保護プラットフォーム（CNAPP）は、クラウドネイティブのインフラストラクチャとアプリケーションを保護するために設計された、セキュリティとコンプライアンス機能を統合的に統合したプラットフォームです。
CNAPPには、アーティファクトスキャン、セキュリティガードレール、構成とコンプライアンス管理、リスク検出と優先順位付け、行動分析など、プロアクティブおよびリアクティブのセキュリティ機能が統合されています。
分析機能により、コード作成から本番環境ランタイムまでの可視性、ガバナンス、制御を実現します。CNAPPソリューションは、主要なクラウドプラットフォームプロバイダーとのAPI統合、継続的インテグレーション/継続的開発（CI/CD）パイプライン統合、エージェントおよびエージェントレスワークロード統合を組み合わせ、開発とランタイムのセキュリティを統合的にカバーします。（出典：Gartner　https://www.gartner.com/reviews/market/cloud-native-application-protection-platforms）

*2) Kubernetes（クバネティス/クバネテス/クーべネティス、K8sと略記される）
コンテナ化したアプリケーションのデプロイ、スケーリング、管理を行うための、コンテナオーケストレーションシステム。

*3) CVSS（Common Vulnerability Scoring System：共通脆弱性評価システム）
コンピューティングシステムにおけるセキュリティ脆弱性の深刻度を評価するためのオープンフレームワーク。スコアは、エクスプロイトの容易さと影響度を概算する複数の指標を用いた式に基づいて算出されます。スコアは0から10までで、10が最も深刻。

クラウド運用の現場では、資産の全体像が見えない「死角」や、優先順位のつかない「アラートの山」、そして個別管理では見落とされがちな「複合的なリスク」という、構造的な課題に直面しています 。これらの課題に対し、単にツールを増やすのではなく、資産が置かれている状況やほかのリソースとの関連性を多角的に分析し、真に対応すべきリスクをあぶり出すのが Tenable Cloud Security です 。
次回の第2回では、同製品がどのようにこれらの課題を解決するのか。その中核となる以下の仕組みを解説します。

1. API 連携（エージェントレス）による全資産の自動検出
2. 脆弱性の優先順位付け（独自指標 VPR）
3. クラウド資産の「外部曝露」状況の可視化
4. アイデンティティと権限の最適化
5. 脆弱性・設定・ポリシー・権限をまたぐ「リスクの多角的な評価」
6. 稼働中の資産を全方位で守る「継続的なリスク管理」