Tenable One Cloud Exposure 2025 年に完了した変更

変更内容

カスタムコンプライアンスのアップグレード (2025 年 1 月 26 日)の一環として、12 月 15 日以降、新しいカスタムコンプライアンス基準を作成した際に [すべて (既存のポリシーと将来のポリシー)] を選択するオプションを使用できなくなります。

この変更は、[すべて (既存のポリシーと将来のポリシー)] を選択するオプションがすでに選択されているカスタムコンプライアンス基準のみに影響します。

理由と意義

[すべて (既存のポリシーと将来のポリシー)] を選択するオプションから、より正確な階層型コンプライアンス構造の使用に移行することが推奨されます。これは、以下の理由により、新しいポリシーが自動的に追加されなくなることを意味します。

• カスタムコンプライアンス基準をより詳細に制御できるようになります。
• コンプライアンススコアは新しいポリシーの影響を受けません。こうすることで、スコアの精度が向上し、変更の影響を受けにくくなります

下位互換性

該当なし

変更内容

クラウド環境全体でインターネットに接続するリソースを動的にバリデーションします。

Tenable は、 ネットワーク評価によって検出された潜在的なネットワークエクスポージャーを動的にバリデーションする新しい機能として、ネットワークスキャナーを導入します。ネットワークスキャナーは、フラグが立てられたリソースに直接接続を試み、それらがインターネットから本当に到達可能かどうかを検証します。確認されたエクスポージャーは、ネットワークエンドポイントとして記録されます。

有効になると、スキャナーはサポートされているリソースのインターネット到達可能性のテストを開始します。[設定] > [クラウドサイバーエクスポージャー] > [ネットワーク] で [ネットワークスキャナー] を無効にできます。

影響と意義

• エクスポージャーに対するリアルタイムの能動的なバリデーションにより、静的な設定分析の範囲を超えてカバレッジを拡大します。
• EC2、RDS、Redshift、Azure VM、GCP インスタンスなどのサポート対象のリソース全体で、外部からの到達可能性に対する保証が向上します。
• 誤検出を減らし、確認されたエクスポージャーの修正に集中できます。
• 検証済みのインターネット接続リソース用のネットワークエンドポイントを自動生成します。

変更内容

この表は、クラウドサイバーエクスポージャー のアクセス許可カテゴリに対する変更の概要を示しています。既存の 5 つのカテゴリが 7 つに拡張され、より詳細な制御と明確化が実現します。

影響と意義

この変更の一環として、カスタムポリシーカテゴリは新しいアクセス許可カテゴリに合わせて移行されます。その結果、一部の新しい検出結果がオープンになったり、既存の検出結果がクローズになったりする可能性があります。

• マルチクラウド環境全体にわたるアクセス許可タイプの明確な内訳を顧客に提供します。
• コンソールのアクセスレベル機能によって実行される分析を強化します。

変更内容

Tenable は、AWS AMI スキャンをパブリック AMI (クラウドマネージド AMI) を含めるように拡大しました。この更新は、内部 (プライベート) AMI の既存のサポートに基づいています。管理フィルターを使用すると、環境内のスキャンされたパブリック AMI をすばやく特定できます。

影響と意義

AMI のスキャンにより、サーバーの起動に使用されるイメージが安全であることを先に確認してから実行できるようになるため、セキュリティが強化されます。パブリック AMI のスキャンをサポートすることで、潜在的なリスクをより広範に可視化し、全体的なセキュリティポスチャーを向上できます。

変更内容

Tenable は Entities クエリ API に互換性に影響する変更を実装し、異なるクラウドプラットフォーム間で Kubernetes リソースの参照およびクエリ方法を標準化、簡素化します。これらの変更は、主に GraphQL API ユーザーに影響を与えます。

この変更は、現在のすべての Kubernetes リソースに適用されます。

• KubernetesClusterRole
• KubernetesClusterRoleBinding
• KubernetesConfigMap
• KubernetesCronJob
• KubernetesDaemonSet
• KubernetesDeployment
• KubernetesGroup
• KubernetesIngress
• KubernetesJob
• KubernetesNamespace
• KubernetesNamespaceRole
• KubernetesNamespaceRoleBinding
• KubernetesNetworkPolicy
• KubernetesNode
• KubernetesPersistentVolume
• KubernetesReplicaSet
• KubernetesService
• KubernetesServiceAccount
• KubernetesStatefulSet
• KubernetesUser

要対応

影響を受けるすべてのクエリを更新する必要があります。プロバイダー固有のリソースクエリ (AwsResources など) を使用する代わりに、Entities ベースのクエリを使用し、同じ結果を得るには Provider 引数でフィルタリングする必要があります。

たとえば、AWS Kubernetes クラスタロールを取得するには、以下のように変更します。

変更対象のトップレベルのクエリ:
AwsResources (filter: {Types: [AwsKubernetesClusterRole]}){...}

変更後の必要な構造:
Entities (filter: {Types: [KubernetesClusterRole], Provider: [AWS]}){...}

Kubernetes リソース名とフィルタリングの標準化

一貫性を確保するために、Entities クエリで Kubernetes リソースが使用される場合、クラウドプロバイダーの明示的なプレフィックスがすべての Kubernetes リソースタイプから削除されます。

リソース名の標準化

Types 引数で汎用リソースタイプをフィルタリングし、必要に応じて Provider 引数を使用してクラウドプロバイダーを指定する必要があります。

• 従来の方法: プロバイダー固有のタイプ (Types: [AwsKubernetesClusterRole] など) でフィルタリング
• 使用する方法: 汎用タイプ (Types: [KubernetesClusterRole] など) でフィルタリングし、任意で Provider: [AWS] を追加

直接キャスト

クラウド固有の Kubernetes リソースタイプへのキャストはサポートされなくなりました。現在は、すべての Kubernetes 固有フィールドを含む、汎用 Kubernetes リソースタイプにキャストする必要があります。

• KubernetesResource: KubernetesLabels、KubernetesAnnotations、Cluster などのフィールドが含まれます。
• Inventory API コンテナイメージフィールドの再構築 (GraphQL の互換性に影響する変更) (2025 年 10 月 19 日): ContainerImages フィールドが含まれます。
• KubernetesNamespaceResource: Namespace フィールドが含まれます。

KubernetesResource の場合

• 従来のアプローチ: 特定のタイプにキャストします (例: AwsKubernetesClusterRole)。
• 新しいアプローチ: 汎用タイプ KubernetesResource にキャストします。

Inventory API コンテナイメージフィールドの再構築 (GraphQL の互換性に影響する変更) (2025 年 10 月 19 日) の場合

• 従来のアプローチ: 特定のタイプにキャストします (例: AwsKubernetesDeployment)。
• 新しいアプローチ: 汎用タイプ KubernetesWorkloadResource にキャストします。

Kubernetes リストのリソースの非推奨

Kubernetes リソースは、今後プロバイダー固有のリソースクエリには表示されなくなり、それらのクエリに含まれていたリソースフィルタータイプも削除されます。

• AwsResources
• AzureResources
• GcpResources
• OciResources
• OpResources

API クエリの比較例

query {
  Entities(
    filter: {Types: [AwsKubernetesDeployment]}
  ) {
    nodes {
      AccountId
      Region
      Name
      SyncTime
      ... on AwsKubernetesDeployment {
        ContainerImages {
          Labels
          Provider
          Findings {
            AccountPath
          }
          Region
          SyncTime
          Tags {
            Key
            Value
          }
          AccountId
          AccountName
          Id
          ... on ContainerImage {
            Digest
            ImageTags
            OperatingSystem
            OperatingSystemType
            Repository {
              Id
            }
            RepositoryUri
            ScanTime
            Used
          }
        }
        Namespace {
          Name
        }
      }
    }
  }
}

推奨されるクエリ例 (必須の形式)

query {
  Entities(
    filter: {
      Types: [KubernetesDeployment], 
      Provider: [AWS]
    }
  ) {
    nodes {
      AccountId
      Region
      Name
      SyncTime
      ... on KubernetesWorkloadResource {
        ContainerImages {
          Labels
          Provider
          Findings {
            AccountPath
          }
          Region
          SyncTime
          Tags {
            Key
            Value
          }
          AccountId
          AccountName
          Id
          ... on ContainerImage {
            Digest
            ImageTags
            OperatingSystem
            OperatingSystemType
            Repository {
              Id
            }
            RepositoryUri
            ScanTime
            Used
          }
        }
        Namespace {
          Name
        }
      }
    }
  }
}

影響と意義

これは互換性に影響する変更であり、Entities API 内にある既存のすべての Kubernetes リソースクエリを更新する必要があります。新しく標準化された汎用タイプ名 (KubernetesClusterRole) を導入し、汎用キャスト (... on KubernetesResource) を使用する必要があります。また、Kubernetes クエリを非推奨の <cloud>Resources ルートから、Entities フィルターと Provider クエリを使用する形式に移行する必要があります。この必要な移行により、リソースタイプ名からプロバイダー固有のプレフィックスが廃止され、大幅な簡素化とマルチクラウドの一貫性が実現されます。これにより、多様なクラウド環境間でのセキュリティ体制クエリの作成、維持、スケーリングがより簡単になります。

変更内容

Snowflake アカウントで機密データリソースのスキャンのサポートを導入します。

開始方法

• 統合経由で Snowflake アカウントをオンボードする
• データプラットフォームのスキャンを設定する
• 「資産インベントリ」 で Snowflake リソース (ローカル、共有、マーケットプレースデータベース) を表示する
• 詳細については、Snowflake のよくある質問を確認するか、サポートにお問い合わせください

影響と意義

この更新では、クラウドサイバーエクスポージャー のデータ保護対象を拡大し、最も広く使用されているクラウドデータプラットフォームの 1 つである Snowflake が含まれます。このサポートにより、クラウドサイバーエクスポージャー は Snowflake の機密データを特定して検出できるようになるため、お客様はクラウドデータ環境全体の可視性を維持しながらリスクエクスポージャーを減らすことができます。

変更内容

Tenable は、GraphQL スキーマに対する後方互換性のない変更を実装しています。これにより、ContainerImages コレクション内でネストされているフィールドのプロジェクション方法が影響を受けます。この更新により、API でのフィールドのキャスト方法が標準化され、ContainerImage エンティティに固有のフィールドが、汎用エンティティフィールドから正しく区別されます。

要対応

Inventory API コンテナイメージフィールドの再構築 (GraphQL の互換性に影響する変更) (2025 年 10 月 19 日) タイプを返し、その中で ContainerImages フィールドを使用するクエリを更新する必要があります。ContainerImage タイプに固有のすべてのフィールドを、明示的なインラインフラグメント (... on ContainerImage {}) で囲む必要があります。このタイプ固有のラッピングを実装していないクエリは破損します。

たとえば、コンテナイメージの詳細を取得するには、次のように変更します。
変更前のプロジェクション
ContainerImages {Labels Id Digest ImageTags}
変更後の必要な構造
ContainerImages {Labels Id ... on ContainerImage {Digest ImageTags_jp}}

コンテナイメージフィールドの再構築

親エンティティ (例: KubernetesDeployment) から ContainerImages フィールドをプロジェクションする場合、ContainerImage タイプに固有のフィールドは、GraphQL の ... on ContainerImage {} ブロック内で明示的にリクエストする必要があります。

KubernetesWorkloadResource タイプ

• KubernetesJob
• KubernetesCronJob
• KubernetesDaemonSet
• KubernetesDeployment
• KubernetesReplicaSet
• KubernetesStatefulSet
• OpenShiftDeploymentConfig

以下のイメージ固有のフィールドは、ContainerImages で直接返されず、キャスティングブロック内でラップされる必要があります。

• Digest
• ImageTags
• OperatingSystem
• OperatingSystemType
• Repository (およびそのネストされたフィールド)
• RepositoryUri
• ScanTime
• Used

API クエリの比較例

現在のクエリ例 (サポート終了)

{
  Entities(
    filter: {Types: [KubernetesDeployment]}
  ) {
    nodes {
      AccountId
      Region
      Name
      SyncTime
      ... on KubernetesWorkloadResource {
        ContainerImages {
          Digest
          ImageTags
          OperatingSystem
          OperatingSystemType
          Repository {
            Id
          }
          RepositoryUri
          ScanTime
          Used
          Findings {
            AccountPath
          }
          Labels
          Provider
          Region
          SyncTime
          Tags {
            Key
            Value
          }
          AccountId
          AccountName
          Id
        }
        Namespace {
          Name
        }
      }
    }
  }
}

推奨されるクエリ例 (必須の形式)

{
  Entities(
    filter: {Types: [KubernetesDeployment]}
  ) {
    nodes {
      AccountId
      Region
      Name
      SyncTime
      ... on KubernetesWorkloadResource {
        ContainerImages {
          Labels
          Provider
          Findings {
            AccountPath
          }
          Region
          SyncTime
          Tags {
            Key
            Value
          }
          AccountId
          AccountName
          Id
          ... on ContainerImage {
            Digest
            ImageTags
            OperatingSystem
            OperatingSystemType
            Repository {
              Id
            }
            RepositoryUri
            ScanTime
            Used
          }
        }
        Namespace {
          Name
        }
      }
    }
  }
}

影響と意義

この変更は KubernetesWorkloadResource タイプ内でネストされる ContainerImages フィールドをクエリするすべての GraphQL API ユーザーにとって互換性に影響する変更であり、クエリを更新しないと、イメージ固有のデータを返すことができません。イメージ固有のフィールド (Digest、ScanTime、RepositoryUri など) を ... on ContainerImage {} ブロック内でラッピングし、影響を受けるすべてのクエリを変更する必要があります。このスキーマ更新により、多態的なフィールドのベストプラクティスにデータ構造を整合させることで、GraphQL API の精度と一貫性が向上します。また、イメージ固有のデータが汎用エンティティフィールドから確実に区別されるようになり、API 構造がより予測しやすくなります。

変更内容

以下の GraphQL API 要素は非推奨になる予定です。

フィールド

¹ Policy.Category/Policy.Name は、Policy にネストされている Category Name フィールドをクエリする必要があることを意味します。

フィルター

理由と意義

クラウドサイバーエクスポージャー API フィールドとフィルター全体の一貫性と整合性を確保します。

下位互換性 (要対応)

クラウドサイバーエクスポージャー GraphQL API を使用する場合、ワークフローはこれらの変更の影響を受ける可能性があります。

変更内容

Tenable は、クラウドサイバーエクスポージャー の応答しない資産に関するスキャンデータの保持とステータスレポートをアップデートします。これにより、わかりやすさが向上し、検出結果に現在のクラウド環境が反映されます。

影響と意義

これは、以下の影響を及ぼします。

• 30 日より前のスキャンデータは、完全に削除されます。
• スキャンされていない期間が 14 日間を超えた資産は、「失敗」としてマークされます。
• 透明性を確保するため、前回正常にスキャンされた日時は引き続き表示されます。

これらの更新は、以下を目的としています。

• 古くなった、または誤解を招く検出結果を排除する
• スキャンの間隔をより明確に可視化する
• データの健全性をサポートし、運用ノイズを減らす
• 検出結果の速やかな解決とクローズを促進する

コンプライアンスまたは監査の目的で組織が履歴データを 30 日以上保持する必要がある場合は、リリース日より前にデータをエクスポートすることをお勧めします。

変更内容

Tenable は、クラウドサイバーエクスポージャー の応答しない資産に関するスキャンデータの保持とステータスレポートをアップデートします。これにより、わかりやすさが向上し、検出結果に現在のクラウド環境が反映されます。

影響と意義

これは、以下の影響を及ぼします。

• 30 日より前のスキャンデータは、完全に削除されます。
• スキャンされていない期間が 14 日間を超えた資産は、「失敗」としてマークされます。
• 透明性を確保するため、前回正常にスキャンされた日時は引き続き表示されます。

これらの更新は、以下を目的としています。

• 古くなった、または誤解を招く検出結果を排除する
• スキャンの間隔をより明確に可視化する
• データの健全性をサポートし、運用ノイズを減らす
• 検出結果の速やかな解決とクローズを促進する

コンプライアンスまたは監査の目的で組織が履歴データを 30 日以上保持する必要がある場合は、リリース日より前にデータをエクスポートすることをお勧めします。

変更内容

Tenable は、クラウドサイバーエクスポージャー の応答しない資産に関するスキャンデータの保持とステータスレポートをアップデートします。これにより、わかりやすさが向上し、検出結果に現在のクラウド環境が反映されます。

影響と意義

これは、以下の影響を及ぼします。

• 30 日より前のスキャンデータは、完全に削除されます。
• スキャンされていない期間が 14 日間を超えた資産は、「失敗」としてマークされます。
• 透明性を確保するため、前回正常にスキャンされた日時は引き続き表示されます。

これらの更新は、以下を目的としています。

• 古くなった、または誤解を招く検出結果を排除する
• スキャンの間隔をより明確に可視化する
• データの健全性をサポートし、運用ノイズを減らす
• 検出結果の速やかな解決とクローズを促進する

コンプライアンスまたは監査の目的で組織が履歴データを 30 日以上保持する必要がある場合は、リリース日より前にデータをエクスポートすることをお勧めします。

変更内容

Tenable は、今後 2 つのアップデートで脆弱性検出を改善します。

• 範囲指定された NPM パッケージのサポートを追加し、Node.js ワークロードへの可視性を向上させました。(予定: 10 月 22 日)
• Linux カーネルパッケージの精度が向上し、アップグレード後に残る未使用カーネルバージョンの脆弱性にフラグを立てることがなくなりました。(予定: 10 月 22 日)

影響と意義

• 範囲指定された NPM パッケージ: Tenable が範囲指定された NPM パッケージを完全に可視化するようになるため、検出される脆弱性が増える可能性があります。
• Linux ワークロード: Tenable が未使用カーネルバージョンの不要な検出結果にフラグを立てることがなくなるため、検出される脆弱性が少なくなる可能性があります。

変更内容

多くのコンソール URL の構造が、7 月 20 日に更新されます。これには、検出結果の URL などが含まれます。

理由と意義

これらの URL の変更は、コンソールのナビゲーションに対して今後行われる主要な改善に必要な土台となります。Tenable の目的は、より合理化された効率的なエクスペリエンスを提供し、リソースをより簡単に素早く見つけて管理できるようにすることです。

下位互換性

スムーズに移行できるよう、今後数か月間リダイレクトが行われます。つまり、すでに保存されている URL またはブックマークされた検出結果の URL は、この猶予期間の間も引き続き機能します。

ただし、この移行期間を過ぎると、古い URL が機能しなくなる可能性があります。Tenable は、中断が発生しないように、できるだけ早く特定のコンソール URL に関連付けられた保存済みリンク、ブックマーク、またはスクリプトを更新することを強く推奨します。

変更内容

システムパフォーマンスの向上と同期時間の短縮のために、クラウドサイバーエクスポージャー で特定のタイプのデータを保持する期間を更新しています。

以下の変更は、7 月 20 日に反映されます。

* 一部の一時的なリソース (一時的なコンピューティングインスタンスなど) は、今後もすぐに削除されます。

影響と意義

これは、以下の影響を及ぼします。

• 1 年以上前の解決済みの検出結果は完全に削除され、コンソールや API 経由でアクセスできなくなります。
• 削除されたリソース (例: クラウド環境で検出されなくなった VM やバケット) は、30 日後に削除されます。これらのリソースはすでにアクセスできない状態になっているため、運用上の影響はありません。また、コンソールに表示されなくなり、API 経由で利用できなくなります。
• 古いデータは保持されませんが、ダッシュボードのトレンドの視覚化で集約され、使用されます。
• チームがコンプライアンス、調査、トレンドのレポート作成に長期データを使用している場合、必要なデータを事前にエクスポートすることをお勧めします。

これらの更新は、以下を目的としています。

• パフォーマンスを向上させ、同期時間を短縮する
• 最近の実用データに焦点を当てることで、標準的なコンプライアンス慣習に沿ったものにする

変更内容

古いバージョンの Helm チャートのサポートが終了します。

バージョン 1.1 の Helm チャートのみサポートされます (古いバージョンの非推奨後)。6 月 30 日より、Tenable は Helm チャートバージョン 1.0 と 1.4 のサポートを正式に終了します。

すべてのユーザーは、サービスの利用を継続するために、唯一のサポート対象バージョンであるバージョン 1.1 にアップグレードする必要があります。

アップグレードの理由

古いバージョンは動作しなくなるため、最新バージョンにアップグレードする必要があります。

新しいバージョンにアップグレードするメリットは以下のとおりです。

• 継続的なプラットフォームの互換性 - バージョン 1.0 および 1.4 は、6 月 30 日以降、完全に動作しなくなります
• 新機能および今後利用可能になる機能へのアクセス
• パフォーマンスと安定性の向上
• 重要なバグ修正

アップグレード方法

アップグレード手順は、追加機能を含むクラスタのアップグレードを参照してください。
CI/CD パイプラインまたはクラスタに展開する自動化スクリプトで、Helm チャートのバージョンを必ず更新してください。

手順

1. プラットフォームの [クラスタ] ページにアクセスして、まもなく非推奨になるバージョン (レガシーまたは 1.0) を使用しているクラスタを特定します。
2. ドキュメントの手順を使用してバージョン 1.1 にアップグレードし、CI/CD パイプラインまたはクラスタに展開する自動化スクリプトで、Helm チャートのバージョンを必ず更新してください。

変更内容

クラウドサイバーエクスポージャー は、OCI オブジェクトストレージリソースのデータ保護スキャンを導入します。

Tenable にこれらのリソースに対する必要なアクセス許可を付与し、オブジェクトストレージのスキャンを有効にした場合、この期間中にスキャンが自動的に開始されます。

理由と意義

追加のオブジェクトストレージリソースに対するデータスキャンサポートを追加します。

下位互換性

該当なし

変更内容

脆弱性の優先順位付けを決定するメトリクスを設定できるようになりました。以前は、このメトリクスは設定できませんでした。

さらに、以下の表に示すように、[ワークロード] > [脆弱性] ページ全体で使用されるデフォルトのメトリクスが変更されます。

[脆弱性] ページで使用される新しいデフォルトメトリクスは CVSS ですが、Tenable では VPR の使用を推奨しています。

• Tenable は、ほとんどの脆弱性について動的な VPR を計算します。VPR は、脆弱性の CVSS スコアによって提供されるデータに動的に追従するものです。
• VPR は Tenable の業界をリードする*予測に基づいた優先順位付けに基づいており、現在の脅威の状況を反映するように定期的に更新されるため、Tenable では、検出結果の深刻度を判断する上で VPR スコアがより関連性が高いと考えています。Tenable Research チームは、脆弱性データベースと VPR スコアリングが最新のエクスプロイトに対応できるように、24 時間体制で取り組んでいます。
• 多くのお客様が、VPR をデフォルトのメトリクスとしてすでに使用しています。

詳細については、脆弱性の深刻度メトリクスの設定 (2025 年 5 月)を参照してください。

この変更はプラットフォーム全体に反映されます。以下に例を挙げます。

• [ワークロード] > [脆弱性] ページ
  • [脆弱性] テーブルには 1 つの [深刻度] 列のみが表示され、値には設定したメトリクスが反映されます。
  • 選択したメトリクスに関係なく、CVSS スコアと VPR スコアの両方が引き続き表示されます。
  • Tenable は、ベンダーの深刻度評価を優先するのではなく、National Vulnerability Database (NVD) から取得した値に基づいて CVSS 深刻度スコアを決定します。これは、Tenable Vulnerability Management が深刻度を処理する方法と一致しています。この変更により、環境内の一部の検出結果に影響が生じ、検出結果がオープンまたはクローズされる可能性があります。
• 検出結果
  • 脆弱性検出結果の深刻度は、設定したメトリクスに基づきます。このデフォルトは CVSS です。
• API
  • API 経由で深刻度によって脆弱性をフィルターすると、設定した深刻度メトリクスに基づいて脆弱性が返されるようになりました。
• コンテナイメージ CI/CD のスキャン
  • CVSS とともに VPR スコアリングをサポートします。
  • Tenable ベースの CVE 検出の新しいアーキテクチャにより、このパラメーター --skip-send-results でのサポートは非推奨になり、以前はオプションであったパラメーター、--api-token string と --api-url string が必須になりました。CVE 評価のためにスキャン結果を クラウドサイバーエクスポージャー に送信するには、これらのパラメーターを指定する必要があります。CVE で評価されたスキャン結果は、Tenable によって報告され、以前と同じように CLI 出力に表示されます。また、スキャン結果は UI に表示されます。

理由と意義

• さまざまな Tenable 製品間で深刻度の計算を調整します。
• VPR は Tenable の業界をリードする*予測に基づいた優先順位付け*に基づいており、現在の脅威の状況を反映するように定期的に更新されるため、Tenable では、検出結果の深刻度を判断する上で VPR スコアがより関連性が高いと考えています。
• クラウドサイバーエクスポージャー の脆弱性評価を更新し、Tenable 独自の脆弱性検出メカニズムと連携するようにします。

下位互換性

上記のように、このパラメーター --skip-send-results のサポートは非推奨になり、以前はオプションであったパラメーター --api-token string と --api-url string が必須になりました。

変更内容

クラウドサイバーエクスポージャー は、Azure SQL データベースリソースのデータ保護スキャンを導入します。

Tenable にこれらのリソースに対する必要なアクセス許可を付与し、マネージドデータベースのスキャンを有効にした場合、この期間中にスキャンが自動的に開始されます。

理由と意義

追加のマネージドデータベースリソースに対するデータスキャンサポートを追加します。

下位互換性

該当なし

変更内容

現在、ユーザーは静的リストからポリシーをマッピングすることでカスタムコンプライアンス基準を作成できます。カスタムコンプライアンスのアップグレードにより、ユーザーは以下のことが可能になります。

• 階層構造を持つカスタムコンプライアンス基準を作成し、ポリシーをセクションとサブセクションに分類して整理できます。
• CIS などの既存の組み込みコンプライアンスを複製し、 それをテンプレートとして使用します。その後、セクションやポリシーを追加または削除することで変更できます。

アップグレードの一環として、新しいカスタムコンプライアンス基準を作成した場合、[すべて (既存のポリシーと将来のポリシー)] を選択するオプションは使用できなくなります。これは以下を意味します。

• このオプションが選択されている既存のカスタムコンプライアンス基準に、新しいポリシーは自動的に追加されなくなります
• コンプライアンススコアは新しいポリシーの影響を受けません。こうすることで、スコアの精度が向上し、変更の影響を受けにくくなります
• カスタムコンプライアンス基準をより詳細に制御できるようになります

理由と意義

このアップグレードにより、カスタムコンプライアンス基準内でポリシーを管理するための、より構造化された方法が導入され、より適切な整理と階層が可能になります。フラットリストのアプローチから脱却することで、ユーザーはネストされたセクションとサブセクションを作成し、より細かくコンプライアンスを追跡できます。

これにより、より正確な階層型コンプライアンス構造を作成できるようになります。

下位互換性

該当なし

変更内容

(AWS/Azure/GCP) 2024 年 1 月 5 日以降、クラウド組織全体をオンボーディングすると、Tenable によって関連するクラウドフォルダー (Azure など) の下に組織の専用ルートフォルダーが自動的に作成されます。

• このフォルダーの作成を無効にするオプションは、関連するすべてのクラウドのオンボーディング設定から削除されます。

  

• 以前にこのオプションを無効にして、このようなフォルダーを作成しないことを選択している場合も、2024 年 1 月 5 日よりフォルダーが組織構造に自動的に追加されます。

理由と意義

アカウント組織を合理化し、すべてのお客様の組織構造を同じように調整します。

下位互換性

該当なし

変更内容

GraphQL API の変更

以前は AWS リソースのみに使用されていた Region フィールドが、非推奨の Location フィールドの代わりに、Azure および GCP リソースにも使用されるようになります。以下の変更が GraphQL API で行われます。

非推奨フィールド

新しいフィールド

新しいサンプルクエリとレスポンス

以下のクエリ例は、Entities クエリで使用されている新しい Region フィールドを示しています。

query {
  Entities(
    filter: {
      CloudProviders: [
        AWS,
        Azure
      ]
    })
  {
    nodes {
      Name
      CloudProvider
      AccountId
      Region
      __typename
    }
  }
}

{
  "data": {
    "Entities": {
      "nodes": [
        {
          "Name": "$web",
          "CloudProvider": "Azure",
          "AccountId": "****b91f-642d-****-961c-482524db****",
          "Region": "eastus",
          "__typename": "AzureStorageStorageAccountBlobContainer"
        },
        {
          "Name": " (SupportedImages) - Ubuntu 14.04 LTS x86_64 LATEST - ****0610-88b63861-****-4d27-8367-fb8856db****",
          "CloudProvider": "AWS",
          "AccountId": "aws",
          "Region": "us-west-2",
          "__typename": "AwsEc2Image"
        },
        ...

理由と意義

Tenable は、GraphQL クエリでリソースのリージョン情報を取得する方法を更新しました。これにより、シンプルさと効率性が向上し、すべてのクラウドプロバイダーでこの情報を取得する方法が合理化されました。

下位互換性 (要対応)

クラウドサイバーエクスポージャー GraphQL API を使用してビジネスインテリジェンスツールにデータを送信する場合、ワークフローは以下の変更による影響を受ける可能性があります。

変更内容

2024 年 1 月の最初の 2 週間に、クラウドサイバーエクスポージャー は以下のマネージドデータベースリソースのデータ保護スキャンを導入します。

• AWS
  • RDS クラスタ
  • RDS インスタンス
• GCP
  • SQL インスタンス

Tenable にこれらのリソースに対する必要なアクセス許可を付与し、マネージドデータベースのスキャンを有効にした場合、この期間中にスキャンが自動的に開始されます。

理由と意義

追加のマネージドデータベースリソースに対するデータスキャンサポートを追加します。

下位互換性

該当なし