Cortex Cloudでは、クラウド上の仮想マシンに専用のエージェントをインストールせずに、ディスク内の脆弱性やマルウェア、機密情報を検出できます。
この仕組みが、Agentless Disk Scanです。
Agentless Disk Scanには、主に次の2つのスキャン方式があります。
- Cloud Scan
- Outpost Scan
どちらも仮想マシンのディスクを解析する点は同じですが、どこでスキャンするのか、誰がスキャン用リソースを管理するのかが異なります。
本記事では、2つの方式の違いと選び方、Outpost Scanを利用する場合の構成や運用上の注意点を解説します。
弊社検証環境で調査した情報や、Palo Alto Networks社サポートの方からいただいた回答情報を許可を得て、盛り込んでおりますので公式ドキュメントよりも詳細に解説いたします。
結論：原則は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社へ確認してください。