env: prod

env: prod

prod,test

AKS、EKS、GKE に固有のラベルについては、「Kubernetes クラスタに関連するラベル」も参照してください。

次の情報は、シンプルな Kubernetes、OpenShift、およびサポートされているクラウドプラットフォーム（EKS、AKS、および GKE）で実行されている Kubernetes に適用されます。

Secure Workload は、オブジェクトタイプごとに、オブジェクトに関連付けられたラベルを含むインベントリを Kubernetes クラスタからリアルタイムでインポートします。ラベルのキーと値はそのままインポートされます。

Secure Workload では、Kubernetes オブジェクト用に定義されたラベルのインポートに加えて、これらのオブジェクトをインベントリフィルタで使用しやすくするラベルも生成します。これらの追加のラベルは、範囲とポリシーを定義する際に特に役立ちます。

サービス固有のラベル

次のラベルは、サービスに対してのみ生成されます。

キー	値
orchestrator_system/workload_type	サービス
orchestrator_system/service_name	<このサービスに指定された名前>

• （クラウドマネージド型 Kubernetes の場合のみ）ServiceType：LoadBalancer のサービスは、メタデータの収集に対してのみサポートされ、フローデータの収集やポリシーの適用に対してはサポートされません。

ヒント	orchestrator_system/service_name を使用して項目をフィルタリングすることと、 orchestrator_system/service_endpoint を使用することは同じではありません。 たとえば、フィルタ orchestrator_system/service_name = web を使用すると、web という名前のすべてのサービスが選択されますが、 orchestrator_system/service_endpoint = web は、web という名前のサービスを提供するすべてのポッドを選択します。

 - apiVersion: v1
 kind: Node
 metadata:
   annotations:
     node.alpha.kubernetes.io/ttl: "0"
     volumes.kubernetes.io/controller-managed-attach-detach: "true"
   labels:
     beta.kubernetes.io/arch: amd64
     beta.kubernetes.io/os: linux
     kubernetes.io/hostname: k8s-controller

ユーザーは、範囲フィルタを使用して、範囲の重複やクエリなど、さまざまな範囲の詳細をすばやく特定できます。フィルタ機能は、クエリの変更、親の変更などを特定するのにも役立ちます。

例：

[重複あり（Has Overlaps）]

範囲の重複の例

詳細については、「範囲の重複」の項を参照してください。

Parent Change

ドラフトで移動されたがまだコミットされていない範囲。

範囲の定義は階層型になっており、範囲のフルクエリは、すべての親と共に範囲の「論理積」として定義されます。上記の例では、アセットは Workloads:FrontEnd:Mongo に割り当てられています。

範囲の照合は次のようになります。

vrf_id = 676767 and (ip in 1.1.1.0/24) and (Hostname contains mongo).

vrf_id = 676767 はルート範囲クエリに基づき、1.1.1.0/24 の IP は親範囲クエリに基づきます。

（注）	同じレベルでクエリが重複しないようにすることを推奨します。これにより、順序付けの重要性がなくなり、混乱が軽減されます（「範囲の重複」を参照）。

範囲に対する読み取り、書き込み、実行、適用、および所有者の権限を付与できます。詳細については、『Cisco Secure Workload ユーザーガイド』の「Roles」の項を参照してください。

ユーザーには「サブツリー」へのアクセスが付与されます。つまり、指定された範囲とそのすべての子にアクセスできます。前述の例を使用すると、Workloads:FrontEnd 範囲への読み取りアクセス権があるユーザーには、継承により、以下を含む Workloads:FrontEnd の下にあるすべての範囲への読み取りアクセス権があります。

• Workloads:FrontEnd:Mongo

• Workloads:FrontEnd:ElasticSearch

• Workloads:FrontEnd:Redis

• etc. . .

複数の範囲にアクセスできるロールも定義できます。たとえば、「Mongo Admin」ロールには、範囲への所有者アクセス権がある場合があります。

• Workloads:FrontEnd:Mongo:MongoServer

• Workloads:FrontEnd:Mongo:MongoDBArbiter

ロールと機能により、ユーザーは範囲階層への水平なアクセス権を得られます。

範囲の機能も継承されます。たとえば、範囲に書き込み機能があると、その情報の読み取りも可能です。

すべてのユーザーは、自分にアクセス権がある範囲ツリーを表示できます。ルート範囲の所有者権限を持つユーザーは、そのツリーの範囲を作成、編集、および削除できます。このビューにアクセスするには、以下を行います。

左側のナビゲーションバーで、[整理（Organize）] > [範囲とインベントリ（Scopes and Inventory）]をクリックします。

アクセス権のあるすべての範囲について、範囲階層全体（ルートまで）を横断できます。この完全な横断により、ユーザーが任意の範囲に対するポリシーを作成する際のコンテキストが提供されます。このページでは、いくつかのアクションを実行できます。

• 範囲階層の V 字の部分をクリックすると、その範囲の子が表示されます。

• 範囲カードをクリックすると、右側のペインが更新され、その範囲に関する詳細と、そのすべてのインベントリのフィルタ可能なリストが表示されます。

範囲ページには、ショートカットがいくつか用意されており、フローの一方または両方のエンドポイントが指定された範囲内にあるフローを検索する必要があるシナリオで役立ちます。

上の図に示すように、範囲ツリー（左側のパネル）で目的の範囲を選択した後、ユーザーは次の 3 つのオプションから選択できます。

1. [フロー検索 （コンシューマとして）（Flow Search - As Consumer ）] では、フロー検索ページへのショートカットが提供され、フローのコンシューマ範囲として選択された範囲でのフローの検索に役立ちます。つまり、フローのコンシューマエンドポイントまたは送信元エンドポイントは、選択した範囲に属します。

2. [フロー検索 （プロバイダーとして）（Flow Search - As Provider）] では、フロー検索ページへのショートカットが提供され、フローのプロバイダー範囲として選択された範囲でのフローの検索に役立ちます。つまり、フローのプロバイダーエンドポイントまたは宛先エンドポイントは、選択した範囲に属します。

3. [フロー検索 （内部トラフィック）（Flow Search - Internal Traffic）] では、フロー検索ページへのショートカットが提供され、選択した範囲に完全に制限されているフローの検索に役立ちます。つまり、フローの両方のエンドポイント（コンシューマとプロバイダー）は、選択した範囲に属します。

範囲を追加するときは、範囲の重複を避けることをお勧めします。範囲が重複すると、重複する範囲に対して生成されたポリシーが、エンドユーザーの混乱を招く可能性があります。この機能は、範囲メンバーシップが重複している場合、つまり、同じインベントリが範囲ツリー（兄弟範囲）の同じ深さで複数の範囲に属している場合に、プロアクティブにユーザーに通知します。その目的は、範囲ツリーの異なる部分に同じワークロードが存在することを避けることです。

複数の範囲に属するインベントリ項目を表示するには、範囲フィルタを使用し、Has Overlaps = true ファセットを入力します。

重複する範囲および対応する重複する IP アドレスのリストは、範囲ツリーを下に移動し、[重複する範囲（Overlapping Scopes）] タブを選択することで表示できます。

ルート範囲で SCOPE_OWNER 権限を持つユーザーのみが範囲を削除できます。サイト管理者は、すべての範囲の所有者です。

範囲名の編集

範囲名の編集は瞬時に完了しますが、更新が必要な子範囲の数によっては数分かかる場合があります。

（注）	範囲名を変更すると、範囲名によるフロー検索が影響を受けます。

範囲を削除できるのは、ルート範囲の所有者権限がある場合のみです。サイト管理者は、すべての範囲の所有者です。

範囲を削除すると、親範囲（親範囲のメンバーであるワークロード）のアプリケーション インベントリ メンバーシップに影響を及ぼします。範囲を削除すると、親範囲のステータスが「ドラフト変更」に変わります。ワークスペース、ポリシー、構成インテントなどの依存関係とともに変更をコミットします。詳細については、「変更のコミット」を参照してください。

依存オブジェクトのある範囲は削除できません。次の場合にエラーメッセージが表示されます。

• 範囲にワークスペースが定義されている。

• 範囲にインベントリフィルタが割り当てられている。

• 範囲を使用してコンシューマやプロバイダーを定義するポリシーが存在する。

• 範囲でエージェント構成インテントが定義されている。

• 範囲でインターフェイス構成インテントが定義されている。

• 範囲でフォレンジック構成インテントが定義されている。

  [範囲/フィルタ変更の影響を確認する（Review Scope/Filter Change Impact）] ページの範囲の依存関係に関する詳細については、[依存関係（Dependencies）] タブをクリックしてください。範囲/フィルタ変更の影響を確認範囲を削除する前に、冗長オブジェクトを削除します。

  （注）	子範囲のない範囲を削除します。 ルート範囲を削除するには、まず [テナント（Tenants）] ページから VRF を削除します。

  1. ナビゲーションウィンドウで、[整理（Organize）] > [範囲とインベントリ（Scopes and Inventory）] の順にクリックします。

  2. 対応する子範囲を表示する [範囲（Scope）] をクリックします。

  3. 削除する子範囲を選択します。

  4. [編集（Edit）] ボタンと [追加（Add）] ボタンの横にある [削除（Delete）] ボタンをクリックします。

  5. [範囲変更の影響の確認（Review Scope Change Impact）] リンクをクリックして、範囲変更を確認してから範囲を削除します。

  6. [戻る（Back）] をクリックしてページを閉じます。

     

     

  7. [削除（Delete）] をクリックして、範囲を削除します。

ある範囲のアプリケーション インベントリ クエリ定義は、その範囲のクエリとその直接の子のクエリによって定義されます。この場合、範囲は「ドラフト変更」があるとマークされ、範囲のクエリ、ワークスペース、およびクラスタは、[変更の確定（Commit Changes）] バックグラウンドタスクが実行されるまで変更されません。範囲がドラフトの場合、影響を受ける範囲アイコンごとに三角の注意マークが表示され、[変更の確定（Commit Changes）] ボタンが [範囲（Scopes）] ページに表示されます（右上）。このボタンをクリックして [変更の確定（Commit Changes）] バックグラウンドタスクを実行する必要があります。

範囲をドラフトとしてマークできるイベントは次の通りです。

• クエリの更新

• 任意の親クエリの更新

• 直接の子の追加

• 直接の子の削除

• 直接の子のクエリを更新

範囲の名前を変更しても、範囲のドラフト状態は変更されません。

（注）	[変更の確定（Commit Changes）] タスクは非同期です。通常は数秒かかりますが、大きな範囲ツリーでは数分かかることがあります。

（注）	範囲の更新タスクは、ルート範囲がドラフトでなくなると完了します。ページを更新して最新の状態を表示します。

サイト管理者およびルート範囲で SCOPE_OWNER 機能を持つユーザーは、右上のオーバーフローメニューの変更ログをクリックして、各範囲の変更ログを表示できます。

そのようなユーザーは、右上隅のオーバーフローメニューにある [削除された範囲の表示（View Deleted Scopes）] リンクをクリックして、削除された範囲のリストを表示することもできます。

子範囲の提案は、機械学習アルゴリズム（ネットワークでのコミュニティ検出など）を使用して、範囲として機能する可能性のあるグループを検出するツールです。このツールは、範囲階層を構築するときに役立ち、特定の範囲に対してより詳細な子範囲を定義するプロセスを容易にします。候補の子範囲は提案として表示され、選択して追加できます。

アルゴリズムの説明：親範囲の要求されていないメンバー間の通信に基づくグラフが最初に作成されて、グラフが処理されます（注：要求されていないメンバーとは、親の子範囲に属していないメンバーです）。たとえば、アルゴリズムでは、グラフ内の大部分を占める他のエンドポイントと通信するエンドポイントが識別されます。そのようなエンドポイントのグループが見つかった場合は、共通サービスグループの候補としてユーザーに表示されます。グラフの残りの部分は、コミュニティとして動作するグループを検出するために処理されます。コミュニティとして動作するとは、エンドポイントがグループ外のエンドポイントよりも不釣り合いに頻繁に（またはより多くのプロバイダーポートで）互いに通信することを意味します。そのような各グループは、アプリケーションまたは組織内の部門に対応している場合があります。そのようなパーティション分割により、範囲間でポリシーが希薄になる可能性もあります。

例：

次の図の 1 から 10 を個々のエンドポイント IP とします。入力（通信）グラフは次のようになっているとします。

次に、エンドポイント 1 ～ 4、5 ～ 7、および 8 ～ 10 では、相互に比較的高度な通信（エッジの数）が行われ、他のエンドポイントとの通信が比較的少ないため、一緒にグループ化されます。

目的の範囲の範囲の提案を開始するには、範囲のページで範囲を検索して選択する必要があります。

このウィンドウでは、ユーザーはインベントリ「未分類のインベントリ項目」を参照できます。つまり、現在選択されている範囲に属し、現在選択されている範囲のいずれの子範囲にも属さない項目を参照できます。未分類のインベントリ項目をクリックすると、このリストを表示できます。

範囲を選択した後、ユーザーは [子範囲の提案（Suggest Child Scopes）] をクリックし、[範囲の提案の開始（Start Scope Suggestion）] をクリックできます（または、これが初めてでない場合は [再実行（Rerun）] をクリックします）。範囲提案の実行の入力は、分類されていないインベントリ項目になることに注意してください。

ユーザーは、範囲提案の入力として日付範囲を設定し、[範囲の提案（Suggest Scopes）] をクリックできます。範囲の提案の実行は、全体的な負荷が中程度の場合は高速であることが多く、数万回の通信で 10 から数千のエンドポイントを処理するのに数分しかかかりません。

出力は、候補のリストとしてユーザーに表示されます。現在、最大 20 のグループが表示され、それぞれにグループの信頼度（品質）、候補範囲名、クエリなどの情報が付随しています。検出された各グループには、関連付けられた [グループコミュニティ信頼度（Group Community Confidence）] があり、次の値のいずれかが示されます。[非常に高（Very High）]、[高（High）]、[中（Medium）]、[低（Low）]。これは、グループの [コミュニティ（Community）] プロパティの基準となります。信頼度が高いほど、エンドポイントの特定のグループのコミュニティプロパティが高くなります（グループの内側に多くのエッジがあり、外側のエッジが比較的少ない）。表示されているグループのサブセットは、 [グループコミュニティ信頼度（Group Community Confidence）] に基づいて選択されています。検出されたグループは、現在、次の 4 つのグループタイプのいずれかに分類されます。

• [一般グループ（Generic Group）]：コミュニティプロパティに基づいて機械学習によって検出されたすべてのグループ。以下の特別なタイプで明示的に指定されていないグループは、一般グループであることに注意してください。

• [共通サービス（Common Service）]：このグループは、入力インベントリの多くと通信するエンドポイントで構成されます。これらのエンドポイントは、何らかの共有サービスを実行している可能性があります。

• [共通サービスクライアント（Common Service Clients）]：このグループは、[共通サービス（Common Service）] グループとのみ通信するエンドポイントで構成されます。

• [グループ化解除（Ungrouped）]：このグループは、十分な通信がないためにグループ化できないエンドポイントで構成されます。

ユーザーは、検出されたグループをクリックして、選択したグループに対して生成されたクエリのリストを表示できます。ユーザーは、検出されたグループを厳密に定義するクエリの範囲と一致するインベントリをプレビューできます。クエリは、IP 範囲、サブネット、ホスト名、およびユーザーがアップロードしたラベルで構成されます。各グループに関連付けられた信頼度基準があり、[クエリの信頼度（Query confidence）] と呼ばれます。次の値の範囲のいずれかとなります。 [完全（Perfect）]、[非常に高（Very High）]、[高（High）]、[中（Medium）]、[低（Low）]。クエリ生成では、まずグラフ処理と機械学習によってグループが検出され、次にグループごとにクエリが生成されます。[クエリの信頼度（Query confidence）] は、クエリの範囲がエンドポイントとどの程度一致するかの基準です。 [完全（Perfect）] のクエリ信頼度は、提案された（検出された）グループがクエリの範囲と正確に一致していることを示します。反対に、クエリの信頼度が [低（Low）] の場合は、クエリは多くの提案されたグループを取りこぼし、正確に一致できていないことを示しています。これは、クエリの範囲が[過剰なIP（Extra IPs）]となっている（検出されるグループの範囲外である）、またはクエリに多くの [欠落IP（Missing IPs）] がある（クエリの範囲外である）ことを意味します 。

ユーザーは、[+範囲（+ Scope）] ボタンをクリックして、グループ名とグループクエリを編集できる編集ウィンドウに移動できます。ユーザーは、クエリおよび一致する IP を調べ、クエリを調整して一部の IP を追加または削除する必要があるかどうかを判断できます。問題がなければ、ユーザーは [次へ（Next）] をクリックして確認し、ドラフトビューキャンバスでグループを範囲に変換できます。

提案されたグループを範囲に変換すると、グループスロットが緑色になり、[未分類のインベントリ項目（Uncategorized Inventory Item）] の数が減少します。

ユーザーは、グループの残りのリストから範囲作成のプロセスを繰り返すことができます。推奨されるワークフローは、1 つ以上の範囲を作成してから、範囲の提案を再実行することです。[未分類のインベントリ項目（Uncategorized Inventory Item）] の数がゼロの場合は、（現在選択されている親範囲について）さらに範囲を限定するインベントリが残っていないことを示します。

範囲の作成プロセスが完了したら（未分類の数は 0）、ユーザーは、新しく作成された子範囲でこのプロセスを繰り返して、必要に応じてより深い範囲ツリーを生成できます。

（注）	範囲内の未分類の項目がうまく分類されない可能性もあります（例：コミュニティを形成しない）。その場合、アルゴリズムはグループ化を返さないことがあります（空の結果）。

メンバーシップビューのインベントリテーブルには、デフォルトですべての列が表示されます。表示する行は選択できます。さらに、インベントリが [ゲイン（Gained）]、[喪失（Lost）]、[変更なし（Unchanged）] のいずれかであるかを識別する追加の Diff 列を含む、選択したメンバーシップ列と行の csv または json をダウンロードできます。ダウンロードに必要なすべてのテーブルの選択がテーブルビューに表示されていることを確認してください。

[依存関係の確認（Review Dependencies）] をさらに選択することで、ネストされた依存関係までトラバースできます。

該当する親リンクを選択することで、依存関係ツリーをトラバースできます。

存在する可能性のある範囲の依存関係は次のとおりです。

存在する可能性のあるフィルタの依存関係は次のとおりです。

[パッケージ（Packages）] タブには、ホストにインストールされているパッケージと、それらに影響を与える脆弱性が一覧表示されます。

存続期間の長いプロセスは、プロセスリストタブに表示されます。

[プロセススナップショット（Process Snapshot）] タブの下の下にあるプロセスツリーには、すべてのプロセスに関する脆弱性情報が表示されます。

[脆弱性（VULNERABILITIES）] タブには、ワークロードで Cisco Secure Workload によって特定された CVE が表示されます。

CVE ごとに、基本的な影響指標に加えて、脅威インテリジェンスに基づくエクスプロイト情報が表示されます。

• エクスプロイト数：昨年、CVE が実際に悪用されたのが確認された回数

• 最終エクスプロイト：脅威インテリジェンスによって、CVE が実際に悪用されたのが最後に確認された時間

CVE ID を使用して作成されたインベントリフィルタを使用すると、特定の CVE の影響を受けるホストを検索できます。

特定の CVE の影響を受けるホストを検索するには、CVE ID を CVE-XXXX-XXXX の形式で入力します。

次の操作がサポートされます。

• [=]：CVE ID の影響を受けるパッケージを持つホストを返します。

• [≠]：CVE ID の影響を受けないパッケージを持つホストを返します。

• [含む（contains）]：入力文字列に存在する CVE の影響を受けるパッケージを持つホストを返します（「cve」と入力すると、CVE の影響を受けるホストが返されます）。

• [含まない（doesn't contain）]：入力文字列に存在する CVE の影響を受けないパッケージを持つホストを返します（「cve」と入力すると、CVE の影響を受けないホストが返されます）。

• [一致（matches）]：入力文字列に一致する CVE の影響を受けるパッケージを持つホストを返します。

共通脆弱性評価システム（CVSS）ベースのフィルタを使用すると、スコアを数値形式で入力することにより、指定された CVSS V2 または CVSS V3 影響スコアの CVE を持つホストを検索できます。

たとえば、CVSS V2 影響スコアが 7.5 を超える CVE を持つホストを検索する場合、クエリは CVE Score v3 > 7.5 です。

次の操作がサポートされます。

• =：指定された CVSS V2 または V3 影響スコアの CVE を持つホストを返します。

• ≠：指定された CVSS V2 または V3 影響スコアの CVE を持たないホストを返します。

• >：指定された CVSS V2 または V3 影響スコアよりも大きい CVSS V2 または V3 影響スコアの CVE を持つホストを返します。

• ≥：指定された CVSS V2 または V3 影響スコア以上の CVSS V2 または V3 影響スコアの CVE を持つホストを返します。

• <：指定された CVSS V2 または V3 影響スコアよりも小さい CVSS V2 または V3 影響スコアの CVE を持つホストを返します。

• ≤：指定された CVSS V2 または V3 影響スコア以下の CVSS V2 または V3 影響スコアの CVE を持つホストを返します。

インベントリフィルタは、脆弱なホストを特定するため、Access Vector とアクセスの複雑さを使用して作成できます。フィルタでは、次の操作がサポートされています。

• =：フィルタに一致する脆弱性の影響を受けるパッケージがあるホストを返します。

• ≠：フィルタに一致する脆弱性の影響を受けないパッケージがあるホストを返します。

CVSS V3 スコアに影響を与えるために必要な攻撃元区分、攻撃の複雑さ、および特権を、インベントリフィルタで使用できます。フィルタでは、次の操作がサポートされています。

• =：フィルタに一致する脆弱性の影響を受けるパッケージがあるホストを返します。

• ≠：フィルタに一致する脆弱性の影響を受けないパッケージがあるホストを返します。

Cisco Security Risk Score ベースのフィルタを使用すると、スコアを数値フォーマットで入力することで、指定した Cisco Security Risk Score の CVE を持つホストを検索できます。たとえば、Cisco Security Risk Score が 67 を超える CVE を持つホストを検索する場合、クエリは「Cisco Security Risk Score ≥ 67」です。

Cisco Security Risk Score の範囲の重大度は次のとおりです。

• [高（High）]：67 ～ 100 のスコア範囲

• [中（Medium）]：34 ～ 66 のスコア範囲

• [低（Low）]：0 ～ 33 のスコア範囲

フィルタクエリでは、次の操作がサポートされています。

• =：指定された Cisco Security Risk Score の CVE を持つホストを返します。

• ≠：指定された Cisco Security Risk Score の CVE を持たないホストを返します。

• >：指定された Cisco Security Risk Score よりも大きい Cisco Security Risk Score の CVE を持つホストを返します。

• ≥：指定された Cisco Security Risk Score 以上の Cisco Security Risk Score の CVE を持つホストを返します。

• <：指定された Cisco Security Risk Score よりも小さい Cisco Security Risk Score の CVE を持つホストを返します。

• ≤：指定された Cisco Security Risk Score 以下の Cisco Security Risk Score の CVE を持つホストを返します。

Cisco Security Risk Score 属性は、インベントリフィルタで使用できます。クエリフィルタでは、次の操作がサポートされています。

• =：フィルタに一致する脆弱性の影響を受けるパッケージを持つホストを返します。

• ≠：フィルタに一致する脆弱性の影響を受けないパッケージを持つホストを返します。

属性の値はブール値です。true または false を入力して、属性に基づいて CVE をフィルタ処理します。

デフォルトでは、既知の悪意のある IP アドレスを識別する機能は無効になっています。この機能を有効にすると、[悪意のあるインベントリ（Malicious inventories）] フィルタを使用して、既知の悪意のある IPv4 アドレスをすべて識別できます。ワークロードから既知の悪意のある IPv4 アドレスへの通信をブロックするポリシーを作成してワークロードに適用するには、読み取り専用フィルタを使用します。

デフォルトでは、[悪意のあるインベントリ（Malicious inventories）] フィルタのクエリは * Is_malicious = true に設定されます。

以下のトピックの詳細については、対応するセクションを参照してください。

• 悪意のあるコンシューマおよびプロバイダーの IP アドレスの検出を有効にする方法については、既知の悪意のある IPv4 アドレスの可視性を参照してください。

• マイクロセグメンテーション ポリシーを作成するには、ポリシーの作成と検出を参照してください。

• ワークロードにポリシーを適用するには、ポリシーの適用を参照してください。