Tenable Cloud Security機能解説 ～ エージェントレスで実現する次世代のクラウドリスク管理　～　第2回　Tenable Cloud Security の仕組み

API 連携（エージェントレス）による全資産の自動検出

• 仕組み
  仮想マシン（VM）やコンテナなど、クラウド上の様々な資産（リソース）に対して、調査用のソフトウェア（エージェント）を導入する必要はありません。クラウド事業者が提供する API を介して、環境全体の構成を直接読み取ります。
• 解決できること
  稼働中のサービスやシステム運用に一切の影響を与えることなく、インベントリ（資産一覧）、設定状況、操作ログを即座に取得できます。これにより、管理者が把握できていなかった資産を漏れなく特定し、マルチクラウド環境全体の資産を共通の管理下に置くことが可能になります。

「探索」メニューの展開画面
コンピューティングから IAM、ネットワーク、データまで、API 経由で取得したマルチクラウド上の全資産が、エージェントレスで一元的にリスト化されます。

脆弱性の優先順位付け（独自指標 VPR）

【課題】CVSS（理論上のリスク）のみに依存する管理の限界

脆弱性管理の国際標準である「CVSS」は、あくまで「その脆弱性が理論上どれだけ危ないか」を示す指標です。しかし、日々公開される脆弱性のうち、実際に攻撃へ悪用されるものはごく一部です。 CVSSスコアのみを基準に画一的な対応を行おうとすると、現場は膨大なアラートへの対応に追われ、「優先順位付けの機能不全」や「運用リソースの枯渇」を招く恐れがあります。

【解決策】Tenable独自の指標「VPR（Vulnerability Priority Rating）」で「真のリスク」を特定

Tenableは、CVSSに最新の脅威インテリジェンスを掛け合わせた、独自の VPRスコア を提供しています。

VPRのメカニズムと定義

VPRは、脅威アクターの活動、エクスプロイトコードの成熟度、脆弱性の経過期間など、複数の動的要因を分析する機械学習モデルを用いて、悪用される可能性を予測します。この予測値とCVSSの影響度スコアを組み合わせることで、最終的なVPRスコア（0.1〜10.0）が生成されます。

• CVSSスコア： 脆弱性が持つ「理論上の深刻度」。
• VPRスコア： 悪用される可能性と緊急性を示した「実効的な優先度」。

【例】リスクベースの優先順位付け

脆弱性一覧において、CVSSスコアが「9.9」と非常に高いものであっても、VPRスコアでは「9.5」や「7.7」といった差異が生じます。これにより、対応の優先度を明確に切り分けることが可能です。

• CVSSもVPRも高いもの： 最優先で今日中に直すべきもの。
• CVSSは高いがVPRは低いもの： 理論上の危険性は高いものの、現時点では悪用が難しいため、対応を後回しにできる（計画的対応が可能な）ものです。

VPRを活用することで、限られたリソースを「今、組織にとって真に脅威となっている脆弱性」に集中させ、防御効率を最大化できます。

2026年2月現在、従来の「VPRスコア」に加え、業界や地域別のメタデータを組み込み、よりコンテキスト（背景）を重視した分析を行う「VPRスコア（ベータ）」も提供されており、組織環境に応じたより精密な判断を支援します。

クラウド資産の「外部曝露」状況の可視化

クラウド運用において、最も警戒すべきリスクの一つが「意図しないリソースの外部公開」です。Tenable Cloud SecurityはAPIを通じてクラウド内部の設定を直接読み取り、「どの資産がインターネットからアクセス可能な状態か」をリストアップします。設定ミスによってリソースが外部に晒されている状態を特定するには、まず 「クラウドの検出結果」 メニューを確認します。

膨大なリスクを効率的に「トリアージ」する

毎日発生する膨大なアラートを一つずつ確認するのは現実的ではありません。このページを活用することで、以下のような「効果的かつ効率的なトリアージ」が可能になります。

• 優先順位の自動判定：本番環境における「重大」なリスクを優先的に抽出して対応する。
• 特定リスクの即時特定：「パブリック S3 バケット」のような、即座に修正が必要な設定ミスをピンポイントで探し出す。
• コンプライアンスの遵守：CSA や ISO といった特定のセキュリティ基準に違反している箇所を可視化。

それでは、このトリアージの結果として特定されたいくつかの具体的なリスク例を見ていきましょう。

例① パブリックS3バゲット　～　中の「機密性」まで踏み込んでリスクを判定　

まずは一つ目の例として、パブリック設定となっているS3バゲットをリストアップします。また、リスクの実態に合わせて深刻度（重大、高、中、低）を分類しリストアップします。

ここで、深刻度が最大とされているS3の詳細を見てみます。（オープン時刻、深刻度、ポリシー、アカウント部分をクリックする）

この深刻度が重大と表示されているS3バゲットは、バケットポリシーまたはアクセス制御リスト (ACL) を介してパブリックにアクセス可能です、とあります。データラベルにはPII、PCIとがあるため、機密性が制限付きのPIIデータ、機密性が制限付きのPCIデータが格納されているようです。では、バゲットポリシーの詳細を見ていきます。

4～18行目
Principal　"AWS": "*" 　 世界中のすべてのAWSユーザーに対して。
Action　"s3:ListBucket"（中身の一覧表示）と "s3:GetObject"（ファイルのダウンロード）　を許可しています

19行目～30行目
Principal　塗りつぶしているところに指定されているユーザー
Action　"s3:*": すべてのS3操作（削除や設定変更なども含むすべて）を拒否しています。

つまり、機密性が制限付きのPIIデータ、機密性が制限付きのPCIデータが格納されているS3バゲットのアクセス設定が「世界中の誰にでも閲覧は許可するけれど、特定の人たちにだけは一切の操作をさせない」という設定になっているということをTenable Cloud Securityは検出しています。

修正をクリックするとTenable Cloud Securityからの修正の提案内容が確認できます。

IaCをクリックするとTerraformのどの部分を確認すべきかをリストアップします。

この深刻度が重大とラベルされたS3バゲットに対し、設定の即時修正とTerraformのコード修正という2段階のステップを提案しています。「今すぐ直すべき手順」と「将来にわたって安全を保つためのコード」をセットで提示することで、運用の現場と開発の現場を強力にバックアップします。

パブリックS3バゲットのリスト表示のS3バゲットをクリックすると、そのS3バゲットの詳細が表示されます。

検出結果(62)をクリックすると次のようなリストが表示され、このS3バゲットに深刻度重大から情報レベルまで合計62件の指摘があることが分かります。

Cross-Account Data Access Monitor (クロスアカウント データ アクセス モニター) とは
検出結果には、ポリシー列に「Cross-Account Data Access Monitor」と表示されているものがあります。これは、同じ組織内であっても、異なる「アカウント」や「サブスクリプション」をまたいでリソースにアクセスしている状況を監視する機能です。具体的には、あるサブスクリプションで管理されている 「マネージド ID」や「プリンシパル（操作主体）」 が、別のサブスクリプションにあるリソースへアクセスする 「クロスアカウント アクセス」 が行われた際に、その付与された権限に問題がないかをチェックします。

例② パブリックKMSキー　～　キーポリシーを解析しリスクを特定

次の例として、パブリック公開となっているKMSキーをリストアップします。 例えば、S3バケットを非公開に設定していても、その中身を暗号化している「KMSキー」自体のポリシーが不適切だと、外部からデータを復号されるリスクが生じます。

1つ目の重大ラベルがついたパブリックKMSキーの指摘を見ていきます。（オープン時刻、深刻度、ポリシー、アカウント部分をクリックする）

Principal　 "AWS": "*"　世界中のすべてのAWSユーザーに対して。
Action　"kms:*"　KMS（鍵管理サービス）に関するすべての操作を許可している。

この　kms:*　は、データの暗号化・復号だけでなく、「鍵の削除」や「設定変更」まですべての権限を含みます。 もし悪意のある第三者がこの鍵を見つけたら、暗号化されたデータを勝手に復号するだけでなく、鍵を削除してデータを二度と開けられなくすることも物理的に可能になってしまいます。

修正をクリックすると修正内容の提案を確認できます。

パブリックKMSキーのリストの確認したい指摘のある行のKMSキーのアイコンをクリックするとキーの詳細やそのキーに関連する指摘が確認できます。

例③ パブリックRDSインスタンス ～ データベースの直接曝露を未然に防ぐ

次の例として、組織にとって最も守るべき資産の一つにデータベースがあります。

1つ目の深刻度高ラベルがついたパブリックRDSインスタンスの指摘を見ていきます。（オープン時刻、深刻度、ポリシー、アカウント部分をクリックする）

このRDSインスタンスはdefaultというセキュリティグループを介して外部と接続しています。defaultをクリックするとdefaultの設定が表示されます。defaultの設定は、タイプが All TCP、ポート範囲が ALL、そしてソースが 0.0.0.0/0 です。つまり、世界中の全IPから任意のTCP接続が可能な状態です。これにより、攻撃者がインターネット経由でRDSインスタンスにアクセスし、データベース内部へのアクセス、データベース設定変更、DoS/リソース消費といったサービス妨害などの不正操作やブルートフォース攻撃^*4)が行えるリスクがあります。パブリックRDSインスタンス画面では、この経路を自動解析し、ネットワークのエクスポージャーとして直感的に矢印付きで表示するため、外部からアクセス可能な経路（Exposure）を一目で確認できます。

修正をクリックすると修正内容の提案を確認できます。

*4) ブルートフォース攻撃：　IDとパスワードの組み合わせを自動プログラム等で総当たり的に試行し、正規の認証情報を力任せに割り出すサイバー攻撃

例④ 過剰な権限を持つ IAM ロール ～ 実際の「利用実績」から最小権限を導き出す

次の例として、IAM ロールの権限管理は最も形骸化しやすい領域の一つです。作業の利便性を優先して広範な権限を付与したまま、実際には一度も使われていない権限が放置されているケースは少なくありません。それでは、1つ目の指摘を見ていきます。

こちらはサードパーティのセキュリティサービス用に作成されたIAMロールのようで、次の指摘があります。

• 権限が広すぎる
  • 過剰なアクセス許可：186のサービスに対し、2,638個もの操作権限が付与されています。
  • 機密情報へのアクセス：本来制限されるべき「機密性の高いリソース」に対しても、2件の過剰なアクセス権限が設定されています。

業務に必要な範囲を大幅に超えた権限を渡している可能性があります。

• 11か月間1度も使われていない
  • 不使用の放置：過去11ヶ月間、一度も利用された形跡がありません。

11か月使用されていないということは、今すぐ必要のない権限といえます。使われていないアカウントは監視の目が届きにくいため、攻撃者に悪用された際の発覚が遅れる原因になります。

• 外部からの侵入パスになっている
  • サードパーティ信頼：サードパーティ側のアカウントを信頼する設定になっています。これは、自分のアカウントの権限が委譲できるAssumeRoleだと想定できます。
  • 外部アクセス：このロールは「外部」からアクセス可能な設定です。

もし外部ベンダー側の管理に不備があった場合、そこを踏み台にし、クラウド環境のほぼ全て（186サービス）が操作されるリスクがあります。

Risk（リスク） = Privilege（権限） × Exposure （公開経路）× Attack Path（攻撃経路）

• Privilege → 2638権限／186サービス　強すぎる権限
• Exposure → インターネット経由はないため 直接攻撃は不可
• Attack Path → サードパーティアカウントに権限移譲が可能なためサードパーティ側が侵害されるとこのロールを外部から操作可能になる。

直接攻撃はできないが高すぎる権限とサードパーティ側が侵害されるケースが存在しているため重大とラベルされていると考えられます。

権限と使用状況は権限マップ形式で過剰なアクセス許可がどこにあるのかを確認できます。

アイデンティティと権限の最適化

クラウド環境のセキュリティにおいて、最も管理が困難で、かつ攻撃者に狙われやすいのが「アイデンティティ（ID）」と「権限」です。Tenable Cloud Security の 「アイデンティティインテリジェンス」 機能は、環境内のあらゆる ID がもたらすリスクを詳細に調査し、評価します。

この機能は、単に「誰が何にアクセスできるか」を表示するだけではありません。

• あらゆる「アイデンティティ」を網羅
  ユーザーだけでなく、ロール、サービスアイデンティティ、さらにはサードパーティやフェデレーション ID までをすべて抽出します。
• リスクのマッピングと深刻度判定
  各 ID とそれに紐づくアクセス許可を、環境内の潜在的なリスクに自動でマッピングし、深刻度レベル別に内訳を表示します。 これにより、どの ID が最も「危険な特権」を持っているかが一目でわかります。
• 「権限の構造図」による可視化
  複雑な権限の繋がりをマップ形式で表示し、過剰なアクセス許可がどこにあるのかを視覚的に特定できます。

実績に基づいた「最小権限」への是正

分析されたデータをもとに、以下のような実効性の高い対策が可能になります。

• 最小権限の適用（是正）
  「付与されている権限」と「実際の利用状況」を照らし合わせ、長期間使われていない不要な権限を特定・削減します。 これにより、万が一 ID が侵害された際も、被害範囲を最小限に抑えられます。
• JIT（Just-In-Time）アクセスとの連携
  アイデンティティインテリジェンスで「常時付与」のリスクが判明した ID に対し、必要な時だけオンデマンドで権限を付与する JIT 運用を組み合わせることで、さらに安全な状態へと導きます。

脆弱性・設定・ポリシー・権限をまたぐ「リスクの多角的な評価」

「3．クラウド資産の「外部曝露」状況の可視化」では、主に稼働中のリソースに関する「クラウドの検出結果」について書きましたが、Tenable の「リスク」メニューでは、ほかにも多角的なカテゴリーでリスクを確認できます 。

多角的な評価を支える各カテゴリーの役割

• IaC 検出結果：Terraform などの設計図をスキャンし、デプロイされる前の段階で設定不備を特定します 。
• 過剰なアクセス許可：多要素認証（MFA）が未設定のユーザーや、非アクティブなのに強い権限を持つ ID など、アイデンティティに潜むリスクを可視化します 。
• 脆弱性：ワークロード内でパッチ適用が必要な既知のソフトウェア脆弱性や、OS パッケージの不備を特定します 。
• 悪意のあるファイル：ワークロード内に潜むマルウェアなど、悪意のある可能性があるファイルを検出します 。
• コード / Container Image CI/CD：開発パイプラインやコンテナレジストリのスキャン結果を分析し、潜在的な問題を早期に特定します。

メリット：複合的な「有害な組み合わせ」を優先的に抽出

Tenable の真価は、これらのカテゴリーを横断して分析し、「外部からアクセス可能（クラウド設定）」×「脆弱な OS（脆弱性）」×「機密データへの特権（過剰な権限）」といった、実際に悪用可能な攻撃ルート（有害な組み合わせ）を優先的に抽出することにあります 。

単一のアラートを潰す「点の対策」ではなく、攻撃者の侵入経路を根底から断つ「線の対策」を、この一つの画面から実現できるのです 。

稼働中の資産ワークロードを全方位で守る「継続的なリスク管理」

クラウドには、その環境の上で稼働する仮想マシン、コンテナ、ストレージ等のワークロードがあります。クラウド全体の安全を維持するには、そういった稼働中のワークロードやそれに対するアカウント構成のセキュリティ状態を継続的に監視し、管理者の負担を抑えながら多層的な防御を維持することが不可欠です。
Tenable Cloud Security は、以下の 3 つの柱で、クラウド環境で稼働中のワークロードの安全を支えます。

• クラウド設定とデータの曝露防止
  単にS3バケットの設定ミスを拾うだけではありません。「誰がそのデータに触れるのか（アクセス権限）」と「その中に何が入っているのか（データの機密性）」を突き合わせて分析します。例えば、「機密情報（PII）が含まれるS3バケットに対し、過剰なアクセス権限が付与されている」といった、実質的なデータ漏洩リスクをピンポイントで特定・修正できます。
• ワークロードの継続的な脆弱性管理
  稼働中の仮想マシン、コンテナ、サーバーレス（AWS Lambda等）を横断してスキャン。エージェントを入れずに、最新の脆弱性やマルウェア、不適切な設定をリアルタイムに把握できます。
• 異常挙動の検知と調査
  操作ログ（アクティビティログ）を分析し、通常とは異なる動きや攻撃の兆候を即座に特定。万が一の際も、蓄積されたデータから迅速な調査を可能にします。

【例】　過剰な権限が付与、機密情報を含むリソースの外部曝露

赤枠で囲ったsplunk_serverは次の4つのラベルがついています。

• 特権：　深刻度「高」のアクセス許可を持っている
• パブリック：　パブリックIPからアクセス可能
• 脆弱性：　EC2インスタンスに脆弱性あり
• PII：機密性が制限付きのPIIデータ

この「splunk_server」はインターネットから直接アクセス可能な状態にあり、EC2インスタンスに脆弱性がある。またPIIラベルがついていることから機密性が高いデータがあると考えられるため早急な対応が必要ということが分かります。