Cortex Cloudでは、クラウド上の仮想マシンに専用のエージェントをインストールせずに、ディスク内の脆弱性やマルウェア、機密情報を検出できます。

この仕組みが、Agentless Disk Scanです。

Agentless Disk Scanには、主に次の2つのスキャン方式があります。

Cloud Scan
Outpost Scan

どちらも仮想マシンのディスクを解析する点は同じですが、どこでスキャンするのか、誰がスキャン用リソースを管理するのかが異なります。

本記事では、2つの方式の違いと選び方、Outpost Scanを利用する場合の構成や運用上の注意点を解説します。

弊社検証環境で調査した情報や、Palo Alto Networks社サポートの方からいただいた回答情報を許可を得て、盛り込んでおりますので公式ドキュメントよりも詳細に解説いたします。

結論：原則はCloud Scan、厳格な要件がある場合はOutpost Scan
Agentless Disk Scanとは
1. エージェントレス方式のメリット
補足：用語解説
1. Snapshot
2. メタデータ
Cloud ScanとOutpost Scanの比較
Cloud Scanの処理フロー
Cloud Scanのメリット
Outpost Scanの仕組み
1. Outpost Scanが必要になるケース
2. Outpost Scanの処理フロー
Outpost Scanの構築フロー
Terraformで作成される主なリソース
1. アカウント単位で作成されるリソース
2. リージョンごとに作成されるリソース
OutpostのスキャナーVMは常時起動ではない
Outpost Scanで発生する料金
Outpost構築時の注意点
Cloud Scanが推奨される理由
Outpost Scanを選ぶ前に確認したいこと
1. 本当にSnapshotを共有できないのか
2. 運用を担当するチームが決まっているか
まとめ

結論：原則はCloud Scan、厳格な要件がある場合はOutpost Scan

最初に結論を整理すると、基本的には次の基準で選択します。

方式	適しているケース
Cloud Scan	ディスク内のデータに対して特殊なセキュリティ要件がなく、コストや運用負荷を抑えたい場合
Outpost Scan	ディスクデータを一時的であっても自社管理環境の外に出せない場合

一般的には、構築や運用が容易で、スキャナーの実行料金もかからないCloud Scanが推奨されます。（Palo Alto Networks社推奨)

一方、金融、公共、医療業界などで厳格なコンプライアンス要件により、ディスクのSnapshotを外部のクラウドアカウントに共有できない場合は、Outpost Scanが選択肢になります。

Outpost Scanでは、専用のスキャン環境を利用者側で構築・管理します。そのため、Cloud Scanと比べて構築作業、クラウド利用料金、障害対応などの負担が増える点に注意が必要です。

Agentless Disk Scanとは

Agentless Disk Scanは、仮想マシンにエージェントを導入せずに仮想マシンに接続されているディスクを外部から解析する仕組みです。

次のような流れでスキャンがされます。

仮想マシンのディスクからSnapshotを作成する
Snapshotをもとにスキャン用のディスクを作成する
スキャナーがディスク内のファイルやソフトウェアを解析する
検出結果をCortex Cloudへ送信する（データはCortex Cloudへ送信されません。）
スキャン用に作成した一時リソースを削除する

エージェントレス方式のメリット

仮想マシンにエージェントを導入する方式と比較すると、次のようなメリットがあります。

エージェント導入の手間が不要
アプリケーションやOSへの影響を抑えられる
仮想マシンのCPUやメモリを消費しにくい

一方で、Agentless Disk Scanの仕組み上、Snapshotの作成やスキャン用リソースの起動が必要になるため、クラウドの権限、クォータ(クラウドのリソース利用量の上限)、ネットワーク設定などがスキャンに影響する場合があります。

補足：用語解説

Snapshot

Snapshotは、ある時点のディスクの状態を保存したものです。

バックアップに近い仕組みですが、Agentless Disk Scanでは、仮想マシンのディスクを直接操作するのではなく、Snapshotから作成したコピーを解析します。

そのため、稼働中の仮想マシンに負荷をかけずにスキャンできます。

メタデータ

Agentless Disk Scanでは、スキャン後に検出結果のメタデータがCortex Cloudへ送信されます。

メタデータには、例えば次のような情報が含まれます。

検出された脆弱性
インストールされているソフトウェア
マルウェアの検出情報
機密情報の検出結果
対象リソースやファイルに関する情報

ディスクそのものをCortex Cloudの管理画面へ送信するのではなく、主にスキャンによって得られた検出情報が送信されます。

Cloud ScanとOutpost Scanの比較

2つの方式の主な違いは次のとおりです。

比較項目	Cloud Scan	Outpost Scan
スキャン場所	Palo Alto Networksが管理するスキャン環境	利用者が管理する専用クラウド環境
Snapshotの扱い	Palo Alto Networksのスキャン環境へ共有	利用者の管理環境内で処理
スキャン用ディスク	Palo Alto Networksの環境に作成	利用者の管理環境に作成
主なメリット	コストと運用負荷を抑えられる	データを自社管理環境内に留められる
環境構築	原則として不要	Terraformによる事前環境の構築が必要
スキャナーVM料金	利用者側の負担なし	利用者側の負担
Snapshot料金	利用者側で発生	利用者側で発生
クォータの影響	利用者環境の影響を受けにくい	VPCやEC2などのクォータの影響を受ける
エラーの発生要因	比較的少ない	権限、ネットワーク、クォータなどでエラーになりやすい
Cortex Cloudへの送信内容	検出結果のメタデータ	検出結果のメタデータ

Cloud Scanの仕組み

Cloud Scanは、Palo Alto Networksが管理するクラウド環境でディスクをスキャンする方式です。

利用者がスキャナー用の仮想マシンやネットワークを構築する必要はありません。

Cloud Scanの処理フロー

1. 利用者環境でSnapshotを作成

スキャン対象となる仮想マシンのディスクから、一時的なSnapshotを作成します。

Snapshotの作成処理は、利用者のクラウド環境内で行われます。

2. Snapshotを再暗号化

利用者が管理するキーで暗号化されたSnapshotは、別のクラウドアカウントから復号できないため、そのまま利用できない場合があります。

そのため、Palo Alto Networksが管理する一時的な暗号化キーを利用して、スキャン用のSnapshotコピーを作成します。

この処理も、利用者のクラウド環境内で行われます。

3. Snapshotをスキャン環境へ共有

再暗号化されたSnapshotを、Palo Alto Networksが管理するスキャン専用アカウントへ共有します。

ここでの「共有」とは、データを外部へ転送するのではなく、クラウド上でSnapshotの「利用権限」のみを付与するするクラウド上の操作を指します。

その後、共有されたSnapshotをもとに、Palo Alto Networks側のスキャン環境にスキャン用ディスクを作成します。

データそのものがインターネットを経由して外部へコピーされるわけではないため、情報漏洩のリスクを抑えつつ、安全にスキャンを実行できる点が重要なポイントです。

4. スキャナーVMでディスクを解析

Palo Alto Networksの環境でスキャナーVMが起動し、作成されたディスクを解析します。

スキャンでは、主に次のような情報が確認されます。

OSやミドルウェアに含まれる脆弱性
不審なファイルやマルウェア
パスワードや秘密鍵などの機密情報
インストール済みパッケージ

5. 検出結果を送信

スキャンによって検出された結果のメタデータをCortex Cloudへ送信します。

6. 一時リソースを削除

スキャン完了後、スキャンのために作成されたSnapshotコピーや関連リソースは自動的に削除されます。

Cloud Scanのメリット

Cloud Scanの大きなメリットは、利用者がスキャン基盤を管理する必要がないことです。

スキャナーVMを構築しなくてよい
スキャナーVMの料金を負担しなくてよい
VPCやサブネットを用意しなくてよい
スキャナーの障害対応が不要
クォータ不足の影響を受けにくい

なお、利用者環境内で作成されるSnapshotについては、クラウド事業者のSnapshot利用料金が発生する場合があります。

Outpost Scanの仕組み

Outpost Scanは、利用者が管理する専用クラウド環境内でスキャンを実行する方式です。

Snapshotやスキャン用ディスクをPalo Alto Networksのクラウドアカウントへ共有せず、利用者の管理環境内で処理を完結させられます。

Outpost Scanが必要になるケース

Outpost Scanは、主に次のような要件がある場合に利用します。

Snapshotを外部アカウントへ共有できない
ディスクデータを自社管理環境の外に出せない
組織のセキュリティポリシーで外部環境の利用が禁止されている
法令や業界ルールにより、データの保存場所が厳格に定められている

ただし、Outpost Scanであっても、検出された脆弱性などのメタデータはCortex Cloudへ送信されます。

そのため、「外部へ一切の情報を送信できない」という要件の場合は、メタデータの送信内容も含めて事前に確認する必要があります。

Outpost Scanの処理フロー

利用者がOutpost専用のクラウド環境を用意する
Terraformを利用してスキャン基盤を構築する
Cortex Cloudに監視対象クラウド環境を接続する
スキャナーVMが自動起動する
利用者の管理環境内でディスクをスキャンする
検出結果のメタデータをCortex Cloudへ送信する
スキャン完了後にスキャナーVMを終了する

Outpost Scanの構築フロー

Outpost Scanを利用する場合は、Cloud Scanとは異なり、事前に専用のスキャン環境を構築する必要があります。

大まかな流れは次のとおりです。（以下はAWSの場合）

ステップ	作業内容
1	Cortex CloudからOutpost作成用のTerraformテンプレートをダウンロードする
2	Terraformを実行し、VPC、S3、SQS、Security Groupなどを構築する

Outpostを削除する場合は、基本的に先に監視対象アカウントの接続を解除し、その後Outpost基盤を削除します。

リソースの状態によっては、一部のリソースを手動で削除する必要があります。

Terraformで作成される主なリソース

Outpost用のTerraformを実行すると、スキャンに必要なさまざまなリソースが作成されます。（以下はAWSの場合）

アカウント単位で作成されるリソース

リソース	用途
IAMロール	スキャナーの起動やS3へのアクセス
EC2インスタンスプロファイル	EC2へIAM権限を付与
S3バケット	テンプレートやアーティファクトの保存

IAMロールには、ディスクスキャン用やレジストリスキャン用など、用途ごとに複数のロールが作成されます。

リージョンごとに作成されるリソース

リソース	用途
VPC	スキャナーVMを動作させる専用ネットワーク
サブネット	Availability Zoneごとのスキャナー配置先
Security Group	スキャナーVMへの通信制御
S3バケット	リージョン内の一時データ保存
SQSキュー	スキャンジョブの通知や連携
VPC Endpoint	S3やDynamoDBへのプライベート接続
Internet Gateway/ルートテーブル	通信経路の制御
S3ライフサイクル設定	一時データの自動削除
エンドポイントポリシー	VPC Endpoint経由のアクセス制御

複数リージョンへ展開する場合、それぞれのリージョンにVPCやサブネットなどが作成されます。

そのため、利用する予定のないリージョンまで展開すると、リソース管理が複雑になる可能性があります。

OutpostのスキャナーVMは常時起動ではない

Outpost Scan用のEC2インスタンスは、Terraformを実行した時点で常時起動するわけではありません。

監視対象クラウドをCortex Cloudへ接続した後、スキャン対象が存在する場合に、Cortex CloudがAPIを通じて必要なスキャナーVMを起動します。

スキャナーVMの種類

スキャンの種類によって、利用されるEC2インスタンスが異なります。（以下はAWSの場合）

スキャン種別	インスタンスタイプの目安	用途
ディスクスキャン	`m5d.large`	EBS Snapshotをもとにしたディスク解析
レジストリスキャン	`t3.medium`	コンテナイメージの解析
サーバレススキャン	`t3.medium`	サーバレス関数のコード解析

これらのインスタンスタイプは目安であり、検証時に確認したものです。製品バージョンやテンプレートの変更によって異なる可能性があります。

スポットインスタンスの利用

コストを抑えるため、スキャナーVMには原則としてスポットインスタンスが利用されます。

スポットインスタンスは通常料金より安く利用できますが、AWS側の都合により中断される場合があります。

スキャンシステムは、このような中断を前提としてスキャナーを制御します。

起動台数

スキャン対象となるディスクやコンテナイメージの量によっては、複数のスキャナーVMが同時に起動します。

弊社検証時の場合、5～10台程度が並行して稼働する場合がありました。スキャン対象が存在しない場合、スキャナーVMは起動しません。

スキャン完了後の動作

スキャンが完了すると、スキャナーVMは自動的に終了または削除されます。

異常終了などによりEC2インスタンスが残った場合は、AWSマネジメントコンソールから手動で終了できます。

ただし、処理中のインスタンスを手動削除するとスキャンに失敗する可能性があるため、削除前に稼働状況を確認する必要があります。

Outpost Scanで発生する料金

Outpost Scanでは、スキャン基盤を利用者のクラウド環境に構築するため、関連するクラウド利用料金を利用者が負担します。

主に発生する可能性があるのは、次の料金です。（以下、AWSの場合）

EC2スポットインスタンス料金
Snapshot料金
S3料金
SQS料金
データ転送料金
VPC Endpoint料金
その他のネットワーク関連料金

スキャナーVMの月額費用は、スキャン対象量や実行頻度により異なります。

Cloud Scanでは、Palo Alto Networks側で動作するスキャナーVMの料金は利用者に請求されません。

Outpost構築時の注意点

以下では主にAWSの場合が多いですが、注意点をご紹介します。

Terraformの実行に時間がかかる

展開対象となるリージョン数によっては、terraform applyの完了まで30分以上かかる場合があります。

多数のVPC、サブネット、S3バケット、IAMロールなどを作成するためです。

AWS CloudShellでの実行は避ける

AWS CloudShellは、利用可能なメモリや実行環境に制約があります。

規模の大きいTerraformテンプレートを実行すると、メモリ不足などによりterraform applyが失敗する可能性があります。

そのため、次のような環境での実行が適しています。

管理者のローカルPC
Terraform実行用のEC2インスタンス
社内で管理しているCI/CD環境

クォータを事前に確認する

Outpostでは、利用者のAWSアカウント内にVPCやEC2などを作成します。

そのため、次のようなAWSサービスクォータに達していると、構築やスキャンに失敗する可能性があります。

VPC数
サブネット数
Security Group数
VPC Endpoint数
EC2インスタンス数
スポットインスタンスの上限
EBSボリュームやSnapshotの上限

構築前に、対象リージョンのクォータを確認しておくことが重要です。

複数リージョンへの展開範囲を確認する

Terraformテンプレートの設定によっては、多数のリージョンへVPCなどが展開される場合があります。

構築前に、次の点を確認する必要があります。

実際に監視するリージョン
利用が許可されているリージョン
リージョンごとのクォータ
リージョンごとのコスト
組織のリージョン制限ポリシー

Azureではテナント単位の設計に注意する

AzureでOutpost Scanを利用する場合、テナントごとにOutpost Scan用の専用環境が必要になります。

複数のAzureテナントを監視する場合は、必要となるOutpost環境の数や管理方法を事前に整理する必要があります。

Cloud Scanが推奨される理由

Cloud Scanは、Outpost Scanと比較して次の点で優れています。

専用環境の構築が不要
スキャナーVMの費用がかからない
スキャナーVMの管理が不要
利用者側のVPCやEC2クォータに影響しにくい
ネットワークや権限設定に起因するエラーが少ない
監視対象の接続後に自動でスキャンを開始できる

そのため、データレジデンシやコンプライアンス上の制約がなければ、Cloud Scanを選択するのが良く、
Palo Alto Networks社推奨のスキャン方式となります。

Outpost Scanを選ぶ前に確認したいこと

Outpost Scanの採用を決める前に、次の点を確認します。

本当にSnapshotを共有できないのか

「外部にデータを出したくない」という要件だけでなく、具体的に何が禁止されているのかを確認します。

Snapshotの別アカウントへの共有が禁止されているのか
スキャン用ディスクの外部環境への作成が禁止されているのか
検出結果のメタデータ送信も禁止されているのか

要件によっては、Cloud Scanでも許容できる可能性があります。

運用を担当するチームが決まっているか

Outpost Scanでは、利用者側で次の対応が必要になる可能性があります。

Terraformの実行
IAM権限の管理
クォータの管理
ネットワーク障害の調査
残存リソースの確認
クラウド利用料金の管理
製品アップデート時のOutpost環境リソースの更新対応

構築だけでなく、その後の運用を誰が担当するかも決めておく必要があります。

まとめ

Cortex CloudのAgentless Disk Scanには、Cloud ScanとOutpost Scanの2つの方式があります。

Cloud Scanは、Palo Alto Networksが管理する環境でスキャンを実行するため、利用者側の構築・運用負荷を抑えられます。

一方、Outpost Scanは、利用者が管理する専用クラウド環境内でスキャンを完結できるため、厳格なデータレジデンシやコンプライアンス要件に対応できます。

選定の基本方針は次のとおりです。

特殊な要件がなければCloud Scan
Snapshotを外部環境へ共有できない場合はOutpost Scan
Outpost Scanでは構築、費用、クォータ、障害対応の負担を考慮する

特にOutpost Scanは、単に「より安全そうだから」という理由だけで選択すると、不要なコストや運用負荷が発生する可能性があります。

まずは、組織のセキュリティ要件を具体化し、Snapshotの共有、メタデータの送信が許容されるかを確認したうえで、適切な方式を選択することが重要です。

弊社では、豊富な実績をもとにお客様の状況やご要件を丁寧にヒアリングしたうえで、お客様にとって最適なCortex Cloudの導入から設計支援、運用までをトータルでサポートしております。
「自社の環境にはどちらのスキャン方式が適しているのか」「導入後の運用に不安がある」など、Cortex Cloudについてお困りごとがございましたら、ぜひ弊社へお気軽にご相談ください。

【お問い合わせご相談窓口】
Email：cloud-security-tech@scsk.jp

本記事の記載内容は、Cortex Cloudの製品バージョンによって変わる可能性があります。実際の構築時には、Cortex Cloudから取得した最新の製品ドキュメントや仕様をPalo Alto Networks社へ確認してください。