EC事業を展開している企業や情報セキュリティを担当している方にとって、クレジットカード情報の安全な取り扱いは事業継続や顧客信頼に関わる重要なテーマです。カード会員データを保存・処理・伝送する、またはカード会員データ環境（CDE）のセキュリティに影響を与える可能性がある場合、PCI DSS（Payment Card Industry Data Security Standard）への対応を求められることがあります。一方で、「脆弱性診断やASVスキャンの違いが分からない」「どこまでを診断対象にすべきか判断しにくい」「監査対応で使える証跡をどう整理すればよいか不安がある」と悩む担当者も少なくありません。

この記事では、PCI DSS対応で整理しておきたい脆弱性診断、ASVスキャン、内部脆弱性スキャン、ペネトレーションテストの違いを解説します。さらに、診断前に重要となるスコープ定義の考え方や、診断結果・修正履歴・再スキャン結果を証跡として管理するポイントも紹介します。PCI DSS対応を進めるうえで、どの診断を、どの範囲に、どのタイミングで実施すべきかを整理するための参考にしてください。

INDEX

はじめに

PCI DSS対応で脆弱性診断が重要になる理由

PCI DSS対応で求められる脆弱性診断・スキャンの種類

ASVスキャンと通常の脆弱性診断の違い

PCI DSS対応で重要なスコープ定義の考え方

PCI DSS対応で診断結果を証跡として残すポイント

PCI DSS対応の脆弱性診断ベンダーを選ぶポイント

PCI DSS対応の脆弱性診断の実施フローと年間スケジュール例

PCI DSSの脆弱性診断に関するよくある質問

まとめ：PCI DSS対応では脆弱性診断・スコープ定義・証跡管理を計画的に進めよう

PCI DSS対応で脆弱性診断が重要になる理由

PCI DSS対応を進める企業にとって、脆弱性診断や脆弱性スキャンは、カード会員データを扱う環境のリスクを把握するための重要な取り組みです。脆弱性や設定不備が放置されていると、不正アクセスや情報漏洩、サービス停止、取引先・カード会社への説明対応など、事業に影響を及ぼす可能性があります。このようなリスクを抑えるためには、システムやネットワークの状態を定期的に確認し、発見された問題に対して修正・再確認まで進めることが重要です。

脆弱性診断は、システムに存在する弱点を洗い出し、攻撃者が悪用する前に先手を打って対策を講じるための手段です。PCI DSSでは、カード会員データを扱う環境において、脆弱性スキャンやペネトレーションテストなどに関する要求事項が定められています。診断によって見つかった脆弱性を修正し、修正履歴や再スキャン結果を証跡として残すことで、監査対応や社内説明に活用しやすくなります。

現代のサイバー攻撃は日々巧妙化しており、新たな脆弱性が常に生まれています。そのため、一度診断を実施したからといって安心できるわけではありません。継続的な脆弱性管理は、カード情報を保護し、顧客や取引先からの信頼を維持するために重要な取り組みです。

PCI DSSとは？カード情報を保護するためのセキュリティ基準

PCI DSSとは、Payment Card Industry Data Security Standardの略称で、クレジットカード情報を安全に取り扱うための国際的なセキュリティ基準です。これは、Visa、Mastercard、JCB、American Express、Discoverの主要なカードブランド5社によって設立されたPCI SSC（Payment Card Industry Security Standards Council）によって策定・管理されています。

この基準は、カード会員データを保存・処理・伝送する、またはカード会員データ環境のセキュリティに影響を与える可能性がある組織に関係します。PCI DSSは、ネットワークやシステムの保護、アクセス制御、脆弱性管理、監視、セキュリティポリシーなど、複数の領域にわたる要求事項で構成されています。PCI DSSに対応することで、カード会員データを保護するための技術的・運用的な管理策を整理しやすくなります。

PCI DSSへの対応が不十分な状態でカード情報漏洩などのインシデントが発生した場合、契約上の対応、調査・報告、追加対策、取引条件の見直しなどが必要になる可能性があります。企業の事業継続やブランドイメージにも影響するため、EC事業者やカード情報を取り扱う企業にとって、PCI DSS対応は計画的に取り組むべき重要なテーマです。

脆弱性スキャン・ペネトレーションテストが求められる背景

PCI DSSで脆弱性スキャンやペネトレーションテストに関する要求事項が定められている背景には、サイバー攻撃が企業のシステムを狙う主要な手段の一つであり、攻撃手法も日々変化していることがあります。システムの脆弱性は、攻撃者にとって最も狙いやすい侵入口となります。例えば、WebアプリケーションのSQLインジェクションやクロスサイトスクリプティング（XSS）のような既知の脆弱性が放置されていると、不正アクセスや情報漏洩につながる可能性があります。

このような脆弱性を発見しても修正せずに放置すると、企業のセキュリティリスクが高まる可能性があります。一度発生した情報漏洩は、金銭的損害だけでなく、企業の信頼回復に多大な時間と労力を要し、場合によっては事業の継続そのものが困難になることもあります。実際に、多くの情報漏洩事件は、既知の脆弱性や設定不備が悪用された結果として発生しています。

そのため、PCI DSSでは、定期的な脆弱性スキャンやペネトレーションテストを通じて、自社システムに存在する潜在的な弱点を把握し、必要な修正につなげることが求められます。これにより、攻撃に悪用される可能性のあるリスクを早期に把握し、カード会員データを保護するための管理策を継続的に改善しやすくなります。

PCI DSS v4.0以降で重視される継続的な脆弱性管理

PCI DSS v4.0以降では、脆弱性を一度確認して終わりにするのではなく、継続的に把握し、修正し、再確認する考え方がより重要になっています。現在はPCI DSS v4.0.1が公開されており、v4.0.1はv4.0に対する限定的な改訂として、要求事項の追加・削除ではなく、明確化や誤記修正を中心に行ったものです。

PCI DSS v4.xでは、外部・内部の脆弱性スキャンやペネトレーションテストに加え、検出された脆弱性の修正、再スキャン・再診断、証跡管理まで含めて運用することが重要です。また、内部脆弱性スキャンでは、対象システムの状況に応じて認証付きスキャンが求められる場合があります。認証付きスキャンは、認証情報を用いてシステム内部の設定やパッチ状況を確認する方法で、外部からの簡易的な確認だけでは見つけにくいリスクを把握しやすくなります。

v3.2.1からv4.xへの移行期間はすでに終了しているため、これからPCI DSS対応を進める場合は、現行のPCI DSS v4.0.1を前提に、要件の適用範囲や自社のSAQタイプ、監査・審査の方針を確認しながら、脆弱性管理の運用を整えることが重要です。

PCI DSS対応で求められる脆弱性診断・スキャンの種類

PCI DSSでは、カード会員データ環境（CDE）を保護するために、外部脆弱性スキャン、内部脆弱性スキャン、ペネトレーションテストなど、複数の確認が求められます。ただし、必要となる対応は、自社のカード情報の取り扱い方法、SAQタイプ、カード会員データ環境の構成、委託先との責任分界によって変わる場合があります。ここでは、PCI DSS対応で登場する主な脆弱性診断・スキャンの種類を整理し、それぞれの目的と対象範囲を解説します。

外部脆弱性スキャン（ASVスキャン）：外部公開システムの脆弱性を確認する

外部脆弱性スキャン、通称ASVスキャンは、インターネットに公開されているシステムやネットワーク機器に、外部から悪用される可能性のある脆弱性がないかを確認するためのスキャンです。PCI DSSの外部スキャン要件への対応では、PCI SSCによって認定されたASV（Approved Scanning Vendor）が実施する外部脆弱性スキャンが用いられます。

ASVスキャンは、PCI DSSの外部スキャン要件に対応するため、少なくとも3か月に1回実施することが求められます。スキャン対象は、PCI DSSのスコープに含まれる外部公開システムやネットワーク機器など、自社の環境に応じて整理する必要があります。スキャン後には、ASVからレポートが提供され、検出された脆弱性の情報や修正に関する情報が含まれます。このレポートは、PCI DSS対応における外部スキャンの結果を説明するための重要な資料として活用できます。

内部脆弱性スキャン：社内ネットワークやCDE内のリスクを確認する

内部脆弱性スキャンは、ファイアウォールの内側、つまり貴社の社内ネットワークやカード会員データ環境（CDE）内に存在する脆弱性を発見することを目的とした診断です。ASVスキャンが外部からの脅威を対象とするのに対し、内部スキャンは内部からの脅威や、外部から侵入された際の被害拡大を防ぐための脆弱性を特定します。

このスキャンでは、設定ミスやパッチ未適用、不要なサービスの稼働など、外部からは見えにくい内部システムの弱点を見つけ出します。内部脆弱性スキャンも、定期的な実施が求められる重要な確認です。PCI DSS v4.xでは、内部スキャンについても、対象システムの状況に応じて認証付きスキャンが求められる場合があります。認証付きスキャンを実施することで、パッチ適用状況や設定不備など、外部からは見えにくい内部のリスクを確認しやすくなります。

ペネトレーションテスト：攻撃シナリオに基づき侵入可能性を検証する

ペネトレーションテストは、脆弱性スキャンが検出した脆弱性を用いて、実際にシステムへの侵入を試みる実践的なテストです。単に脆弱性のリストを提示するだけでなく、専門家が攻撃者の視点に立ち、どのような経路で、どこまでシステムに侵入できるのか、もし侵入された場合にどのような被害が発生しうるのかを具体的に検証します。これにより、検出された脆弱性が悪用された際の影響範囲と、セキュリティ対策の有効性を総合的に評価します。

ペネトレーションテストは、PCI DSS対応において重要な確認項目の一つです。実施タイミングや対象範囲は、カード会員データ環境、ネットワーク構成、システム変更の有無などを踏まえて整理する必要があります。特に、CDEとその他のネットワークの境界をセグメンテーションで分離している場合、その分離が意図どおり機能しているかを確認する観点でも重要です。

セグメンテーションテスト：CDEの分離が有効かを確認する

セグメンテーションテストは、カード会員データ環境（CDE）と、それ以外のネットワーク（非CDE）が適切に分離されているかどうかを確認するためのテストです。CDEをファイアウォールなどのセキュリティ対策によって物理的または論理的に分離することで、PCI DSSの適用範囲を整理しやすくなり、対応範囲や診断対象を明確にしやすくなります。

このテストでは、設定されたセグメンテーションが意図どおり機能しているか、CDEと非CDEの間で想定外の通信経路が残っていないかを確認します。具体的には、CDEと非CDE間の通信制御、アクセス制御、迂回経路の有無などを確認します。セグメンテーションテストの結果は、CDEの分離状況やPCI DSSのスコープ整理を説明するための重要な資料として活用できます。

無線LAN・不正アクセスポイントの確認：対象環境に応じて無線リスクを確認する

PCI DSSでは、無線LAN環境に関する確認も重要な管理項目の一つです。CDE内で無線LANを使用している場合や、CDEに影響を与える可能性がある無線環境が存在する場合は、不正なワイヤレスアクセスポイントが設置されていないかを確認する運用を整理しておく必要があります。具体的な確認頻度や方法は、自社の環境、適用される要件、監査・審査の方針に沿って整理します。

これは、オフィスや店舗などで利用される無線LANが、外部からの不正侵入の経路となったり、内部からカード情報が漏洩するリスクにつながったりする可能性があるためです。無線環境の確認を運用に組み込むことで、CDEに影響を与える可能性のある接続や不正アクセスポイントを把握しやすくなります。

※横にスクロールしてご覧ください。

ASVスキャンと通常の脆弱性診断の違い

PCI DSS対応を進める中で、多くの担当者様が「ASVスキャン」と「通常の脆弱性診断」の違いについて疑問を持たれます。このセクションでは、これら二つの診断の目的、実施者、報告書の用途がどのように異なるのかを整理し、自社の状況に応じた使い分けの考え方を解説します。

ASVスキャンはPCI SSC認定ベンダーが実施する外部スキャン

ASVスキャンは、PCI DSSの外部脆弱性スキャン要件への対応で用いられる外部スキャンです。このスキャンは、PCI SSC（Payment Card Industry Security Standards Council）によって認定されたASV（Approved Scanning Vendor）が実施します。ASVは、PCI SSCが定める基準に沿って外部スキャンを実施し、その結果をレポートとして提供します。

ASVスキャンでは、インターネットに公開されているWebサーバー、ネットワーク機器、その他の外部公開コンポーネントに対し、外部から悪用される可能性のある脆弱性を確認します。スキャンで脆弱性が検出された場合は、修正後に再スキャンを行い、対応状況を確認します。

したがって、ASVスキャンは通常の脆弱性診断と目的が異なり、PCI DSSの外部スキャン要件に対応するための手続きとして位置付けられます。

通常の脆弱性診断は対象範囲や深さを柔軟に設計できる

ASVスキャンとは異なり、通常の脆弱性診断は、PCI DSS準拠のためだけでなく、より広範なセキュリティ目的のために実施されます。この診断は、特定のアプリケーションに特化した深掘り調査や、開発ライフサイクル（SDLC）に組み込んで開発段階から脆弱性を検出するなど、お客様のニーズに合わせて診断範囲、対象、深度を柔軟に設計できる点が大きな特徴です。

例えば、Webアプリケーション診断ではクロスサイトスクリプティング（XSS）やSQLインジェクションといったアプリケーション固有の脆弱性を詳細に検査し、ホスト診断ではOSやミドルウェアの設定不備、アカウント情報の脆弱性までを網羅的に確認します。

これらの診断は、ASVスキャンとは別に、一般的なセキュリティベンダーへ依頼することもできます。PCI DSS対応の証跡としてどこまで利用できるかは、診断の目的、対象範囲、報告書の内容、監査・審査の方針によって異なるため、事前に確認しておくことが重要です。

通常の脆弱性診断は、ASVスキャンではカバーできない内部ネットワークのシステムや、Webアプリケーションのロジックに潜む脆弱性など、幅広いリスクを特定し、より堅牢なセキュリティ体制を構築するために役立ちます。

ASVスキャンだけでPCI DSS対応が完了するわけではない

ASVスキャンはPCI DSSの重要な要件の一つですが、これだけでPCI DSSへの対応が完了するわけではない点に注意が必要です。PCI DSSでは、外部脆弱性スキャン（ASVスキャン）だけでなく、内部脆弱性スキャン、ペネトレーションテスト、無線LAN環境の確認など、複数の確認項目が関係します。必要な対応は、自社のスコープ、SAQタイプ、カード会員データ環境の構成、監査・審査の方針によって異なります。

例えば、ASVスキャンが外部からの脅威に対する対策状況を確認するのに対し、内部脆弱性スキャンはファイアウォールの内側にあるシステムやCDE（カード会員データ環境）内のリスクを特定します。また、ペネトレーションテストは、攻撃者の視点からシステムへの侵入を試み、実際に脆弱性が悪用された場合にどのような影響があるかを評価する実践的なテストです。

このように、PCI DSS対応では、それぞれの診断が持つ目的と範囲を理解し、自社のスコープやSAQタイプに応じて必要な対応を整理することが重要です。ASVスキャンは重要な確認の一つですが、内部スキャン、ペネトレーションテスト、修正履歴、再スキャン結果、証跡管理まで含めて考える必要があります。

※横にスクロールしてご覧ください。

PCI DSS対応で重要なスコープ定義の考え方

PCI DSS対応で脆弱性診断を実施する前に重要となるのが「スコープ定義」です。スコープ定義が曖昧なままだと、必要な診断が漏れたり、反対にPCI DSSの適用範囲外のシステムまで診断対象に含めてしまい、コストや工数が増えたりする可能性があります。スコープを明確にしておくことで、診断対象・対象外範囲・前提条件を説明しやすくなり、監査対応やベンダーとの調整も進めやすくなります。

カード会員データ環境（CDE）を特定する

スコープ定義の最初のステップは、カード会員データ環境（CDE）を正確に特定することです。CDEとは、カード会員データを保存・処理・伝送するシステムコンポーネントや、それらに関係する人・プロセスを含む環境を指します。

加えて、CDEのセキュリティに影響を与えるシステムがスコープに関係する場合もあります。具体的には、クレジットカード番号、有効期限、カード名義人などの情報が入力されてから、決済処理が完了するまでの間に、これらのデータがどこを通過し、どのシステムに保存されるのかを洗い出します。

この洗い出しには、データフロー図を作成することが非常に有効です。カード情報がどのようにシステム内を流れるかを可視化することで、関係するサーバー、ネットワーク機器、アプリケーション、データベースなどをすべて特定し、それらがCDEの一部となるかどうかの判断材料とします。このプロセスを通じて、自社のどの部分がPCI DSSの適用範囲となるかを明確にしていきます。

外部公開システム・決済関連システム・管理画面を整理する

CDEを特定した後は、診断対象となる具体的なシステム群を整理します。PCI DSSのスコープには、CDEに直接含まれるシステムだけでなく、CDEと接続しているシステムや、CDEのセキュリティに影響を与えうるシステムも含まれる場合があります。例えば、顧客がアクセスする外部公開Webサーバー、決済処理を行うシステム、そしてそれらのシステムを管理するための管理画面、監視サーバーなどが挙げられます。

これらのシステムを一つずつリストアップし、それぞれの役割とCDEとの関連性を明確に分類することが重要です。例えば、ECサイトのフロントエンドが直接カード情報を扱わない場合でも、バックエンドの決済システムと密接に連携している場合は、そのフロントエンドも診断対象に含めるべきかを検討します。このように広範な視点からシステムを整理することで、診断の抜け漏れを防ぎ、より包括的なセキュリティ対策を講じることができます。

決済代行サービスや外部委託先との責任分界点を確認する

EC事業者にとって、決済代行サービスやシステム運用を外部ベンダーに委託しているケースは少なくありません。このような場合、自社のPCI DSSスコープを定義する上で非常に重要となるのが、責任分界点の明確化です。自社がどこまでPCI DSSの要件に対する責任を負い、どこからが外部委託先の責任範囲となるのかを明確に理解し、文書化する必要があります。

この責任分界点は、契約書、サービス仕様書、そして委託先が提供するPCI DSS準拠証明書（AOC: Attestation of Compliance）などを確認することで特定できます。

例えば、決済代行業者が完全にカード情報を取り扱う場合（リダイレクト方式など）は、自社のスコープは最小限で済む可能性がありますが、API連携などで自社サーバーが一時的にでもカード情報に触れる場合は、その部分がスコープに含まれることになります。曖昧な責任分界点は、監査時の指摘や、万が一のインシデント発生時の対応遅延につながるため、ベンダーと密に連携し、事前にしっかりと確認しておくことが重要です。

ネットワークセグメンテーションによりスコープを整理する

PCI DSSの適用範囲を効率的に管理するための有効な手段として、「ネットワークセグメンテーション」があります。これは、カード会員データ環境（CDE）を、ファイアウォールなどのセキュリティデバイスを用いて、他の非CDEネットワークから物理的または論理的に分離することです。セグメンテーションが適切に行われている場合、PCI DSSの適用範囲を整理しやすくなり、対応範囲や診断対象を明確にしやすくなります。

しかし、単にネットワークを分離しただけでは不十分です。セグメンテーションが正しく機能し、CDEと非CDEの間で不正な通信が発生しないことを定期的に検証する必要があります。これを「セグメンテーションテスト」と呼び、ペネトレーションテストの一環として実施されることが一般的です。セグメンテーションの有効性を維持し、PCI DSSの適用範囲を最適化するためには、このテストを継続的に実施し、見直しを続けることが重要になります。

診断対象・対象外範囲・前提条件を文書化する

スコープ定義の最終段階として、これまでに特定・整理した情報をすべて文書化することが極めて重要です。この文書には、特定したCDEの範囲、診断対象とするシステムの一覧、診断対象外としたシステムとその判断理由、外部委託先との責任分界点、そしてネットワーク構成図などを明確に記載します。これにより、誰が見てもPCI DSSの適用範囲が理解できるようにします。

この文書は、脆弱性診断ベンダーとの打ち合わせで診断範囲を正確に伝えるための基本資料となるだけでなく、PCI DSS監査時に監査人に対して自社の対応状況を説明するための重要な証跡となります。明確に文書化されたスコープ定義は、監査人からの質問に対して迷いなく回答し、「監査で説明できるか」という不安を解消するための重要なプロセスです。今後の運用においても、システム変更時のスコープ見直しや、次回の診断計画策定の基礎情報として活用できます。

※横にスクロールしてご覧ください。

PCI DSS対応で診断結果を証跡として残すポイント

PCI DSS準拠を目指す上で、脆弱性診断は非常に重要なプロセスですが、診断を実施しただけでは不十分です。監査で指摘された際に、対応状況を明確に示すためには、診断結果を適切な「証跡」として管理することが重要になります。診断結果や修正履歴、再スキャン結果を整理しておくことで、監査人や社内関係者に対して対応状況を説明しやすくなります。このセクションでは、診断結果を効果的な証跡として残すための具体的なポイントを詳しく解説します。

診断報告書だけでなく修正履歴・再スキャン結果まで整理する

効果的な証跡管理では、診断ベンダーから受け取った最終的な報告書を保管するだけでなく、そこに至るまでのプロセス全体を記録することが重要です。監査対応では、検出された脆弱性に対して、「いつ、誰が、どのような対応を行ったのか」を説明できる修正履歴が重要になります。さらに、修正後には必要に応じて再スキャンや再診断を実施し、その結果を初回診断の指摘事項と紐付けて保管しておくと、対応状況を説明しやすくなります。

例えば、CVSSスコアの高い脆弱性が検出された場合、修正までに要した期間、関わった担当者、具体的な修正内容（パッチ適用、設定変更など）、修正後に実施した再スキャン・再診断の結果を一連の記録として残しておくと、対応状況を説明しやすくなります。このように、初回の診断報告書から修正対応の記録、そして再検証の結果までを紐づけて管理することで、監査時に迅速かつ正確な情報提供が可能になります。

監査対応に使いやすい証跡の構成要素を把握する

監査人に提出・説明する際に、効率的で分かりやすい証跡を準備するためには、構成要素を事前に把握しておくことが重要です。具体的には、以下の情報が整理されていると、監査がスムーズに進みます。

まず、「診断の前提条件（スコープ、診断対象のIPアドレス、URLなど）」と「診断実施日および担当ベンダー名」は重要です。次に、「検出された脆弱性の一覧（脆弱性の内容、深刻度、CVSSスコアを含む）」を提示します。

これに対し、「各脆弱性に対する対応計画、担当者、対応期日」を明確にし、「修正作業の具体的な記録（実施日時、内容、証拠スクリーンショットなど）」を添付します。最後に、「修正後の再検証結果（再スキャンレポートや再診断報告書）」をまとめておくことで、診断から修正、再確認までの流れを説明しやすくなります。

脆弱性の優先順位と対応状況を説明できる形にする

検出されたすべての脆弱性を同時に修正することは、リソースの制約上、現実的ではありません。そのため、脆弱性への対応は優先順位をつけて計画的に進める必要があります。このとき、CVSSスコアや脆弱性が事業に与える影響度を基準に、なぜその脆弱性を優先的に対応したのか、あるいはなぜ現時点では対応を受容したのか（リスク受容）を論理的に説明できる準備が重要です。

例えば、重大な脆弱性であっても、影響を受けるシステムが限定的で、かつ他のセキュリティ対策でリスクが十分に低減されていると判断できる場合は、その理由を明確に記録し、監査時に説明できるようにします。このような優先順位付けとそれに基づく対応計画は、開発チームとの円滑な連携を促し、限られたリソースを最も効果的に活用することにも繋がります。定期的に対応状況を見直し、その進捗を記録することで、継続的なセキュリティ改善の証拠として提示できるようになります。

経営層への報告では事業影響と残存リスクを整理する

経営層に対して脆弱性診断の結果を報告する際は、技術的な詳細を羅列するよりも、それが事業に与える影響や残存リスクを明確に伝えることが重要です。経営層には、個々の脆弱性の技術的な内容よりも、「PCI DSS対応の状況」「カード情報漏洩が発生した場合の事業影響」「取引先・カード会社への説明対応」「現在のセキュリティ対策の進捗」「未対応の脆弱性や残存リスクをどのように管理しているか」といった観点で整理すると伝わりやすくなります。

報告の際は、検出された主要な脆弱性とその潜在的なリスクを簡潔に説明し、それらに対する対策がPCI DSS準拠にどのように貢献しているかを具体的な数値や事例を交えて伝えます。また、セキュリティ対応を単なるコストではなく、企業の信頼維持と事業継続に関わる取り組みとして説明することも重要です。定期的にセキュリティ体制の現状と今後の計画を報告し、経営層からの理解と協力を得ることが、効果的なPCI DSS対応に繋がります。

PCI DSS対応の脆弱性診断ベンダーを選ぶポイント

PCI DSS対応は、EC事業を継続する上で重要な取り組みの一つです。しかし、要件の複雑さや技術的な専門性から、自社だけですべてを整理・運用することが難しい場合もあります。そこで重要になるのが、信頼できる脆弱性診断ベンダー選びです。

適切なパートナーを見つけることで、スコープ整理、診断実施、修正後の再確認、証跡管理まで進めやすくなり、EC事業のセキュリティ対策を継続的に改善しやすくなります。このセクションでは、ベンダー選定に迷われている担当者の方に向けて、押さえておくべきポイントを具体的に解説いたします。

外部ASVスキャンを依頼する場合はASV認定を確認する

外部脆弱性スキャン（ASVスキャン）は、PCI DSS対応で重要となる確認の一つです。ASVスキャンを依頼する場合は、そのベンダーがPCI SSC（Payment Card Industry Security Standards Council）によって認定されたASV（Approved Scanning Vendor）であるかを確認する必要があります。

ASVスキャンは、インターネットに公開されているシステムの脆弱性を外部から検査するものであり、そのスキャンプロセスや報告書の内容はPCI SSCの厳格な規定に準拠していなければなりません。ASVスキャンとして提出・説明することを想定している場合、PCI SSCに認定されたASVによるスキャン結果であるかを確認しておくことが重要です。

一般的な脆弱性診断とASVスキャンは目的や扱いが異なるため、契約前にスキャン種別と報告書の用途を確認しましょう。ASVの認定状況は、PCI SSCの公式サイトで公開されていますので、契約前に必ずベンダー名を検索し、認定状況を確認するようにしましょう。

PCI DSS対応やEC・決済関連システムの支援実績を確認する

ベンダー選定においては、単に技術的な認定資格があるかだけでなく、これまでの支援実績も重要な判断基準となります。特に、ご自身の会社と同じようなEC事業者や決済関連システムのPCI DSS準拠支援実績が豊富にあるかどうかは、ぜひ確認しておきたい点です。

実績が豊富なベンダーは、EC業界特有のシステム構成や決済フロー、セキュリティ上の課題に対する深い理解を持っています。そのため、貴社の状況に合わせた適切なスコープ定義の相談から、診断の実施、検出された脆弱性への対策提案、さらには監査対応まで、より実践的で的確なサポートが期待できます。具体的な事例やケーススタディの提示を依頼することで、ベンダーの専門性と対応力をより詳しく評価することができるでしょう。

報告書の分かりやすさと修正の実行しやすさを確認する

脆弱性診断は、報告書を受け取って終わりではありません。検出された脆弱性を開発チームが迅速かつ正確に修正できるかどうかが、セキュリティ対策の成否を分けます。そのため、診断報告書の品質は非常に重要です。

良い報告書とは、単に脆弱性のリストが並べられているだけでなく、検出された脆弱性の再現手順、具体的な修正方法の提案、そして開発担当者が理解しやすい記述が含まれているものです。専門用語ばかりで書かれた報告書では、開発チームが修正作業に取りかかるまでに時間がかかったり、誤った対応をしてしまったりするリスクがあります。

可能であれば、契約前にベンダーからサンプル報告書を提示してもらい、その分かりやすさや実用性を評価することをおすすめします。開発チームがスムーズに修正を実行できるような、質の高い報告書を提供してくれるベンダーを選びましょう。

修正後の再スキャン・再診断・追加相談の対応範囲を確認する

脆弱性診断は一度実施すれば完了というものではなく、検出された脆弱性の修正、そしてその修正が正しく行われたことを確認するための再スキャンや再診断までが一連のプロセスです。診断ベンダーを選定する際には、この修正後の対応範囲が料金プランに標準で含まれているのか、あるいは別料金でどこまで対応してくれるのかを事前に確認することが非常に重要です。

また、PCI DSS準拠の過程では、監査前に疑問点が生じたり、追加で相談したい事項が出てきたりすることが少なくありません。診断後のフォローアップ体制が充実しており、継続的な相談に対応してくれるベンダーを選ぶことで、担当者の方の負担を大幅に軽減できます。単発の診断に終わらず、自社のPCI DSS対応に継続的に伴走してくれるパートナーを選ぶことで、診断後の修正・再スキャン・証跡管理まで進めやすくなります。

PCI DSS対応の脆弱性診断の実施フローと年間スケジュール例

PCI DSS準拠に向けた脆弱性診断は、ただ実施するだけでなく、計画的かつ継続的に進めることが成功の鍵となります。ここでは、これまで解説してきた各種診断の知識を具体的なアクションに落とし込み、効率的にPCI DSSに対応していくための実施フローと年間スケジュール例を提示します。理論だけでなく、実際の業務でどのように診断を進め、何を準備すべきかという具体的なイメージを持つことで、PCI DSS対応に必要な作業を整理しやすくなります。

STEP1：スコープと診断対象を整理する

PCI DSS対応における脆弱性診断の最初のステップは、何よりも正確なスコープ定義です。まずは、カード会員データ環境（CDE）を特定するために、カード情報がシステム内でどのように「保存、処理、伝送」されているかを洗い出します。データフロー図を作成し、顧客がカード情報を入力してから決済が完了するまでの全プロセスで関わるサーバー、ネットワーク機器、アプリケーション、さらには担当者までを明確にしましょう。

次に、特定したCDEに直接関わるシステムだけでなく、CDEに接続するシステムや、CDEのセキュリティに影響を与えうる外部公開Webサーバー、決済処理システム、管理画面、監視サーバーなども診断対象としてリストアップします。さらに、決済代行サービスや外部委託先との責任分界点を明確にし、自社のPCI DSS準拠範囲を正確に把握することで、診断の無駄をなくし、必要な箇所にリソースを集中させることができます。

STEP2：ASVスキャン・内部スキャン・ペネトレーションテストの実施計画を立てる

スコープが明確になったら、それに基づいて具体的な診断の年間計画を策定します。PCI DSS対応では、ASVスキャンや内部脆弱性スキャン、ペネトレーションテストなどを、自社のスコープや要件に応じて計画的に実施する必要があります。

一般的に、外部スキャンは少なくとも3か月に1回実施することが求められるため、年間計画に組み込んでおくと運用しやすくなります。これらの要求事項や自社のシステム構成、ビジネス状況を踏まえ、無理なく継続できるスケジュールを立てることが重要です。

年間計画では、どのシステムに対して、どの種類の診断（ASVスキャン、内部脆弱性スキャン、ペネトレーションテストなど）をいつ実施するかを具体的に盛り込みます。診断ベンダーとの調整はもちろん、システムの稼働状況や大型キャンペーンなどのビジネスイベントを考慮し、システムへの影響を最小限に抑えられるようスケジュールを組む配慮も必要です。例えば、重要なキャンペーン期間中には診断を避けるといった工夫が有効でしょう。

STEP3：診断を実施し、検出された脆弱性を確認する

計画に基づき、選定した診断ベンダーが脆弱性診断を実施します。このフェーズでは、ベンダーが専門的なツールや手法を用いて、対象システムの脆弱性を徹底的に洗い出します。

診断完了後には、ベンダーから詳細な報告書が提出されます。この報告書の内容を精査し、検出された脆弱性がどのようなもので、どの程度の深刻度（CVSSスコアなど）を持ち、自社のシステムや事業にどのような影響を与える可能性があるのかを正確に理解することが重要です。不明な点があれば、すぐにベンダーに確認し、疑問を解消しておきましょう。

STEP4：優先度に応じて修正し、必要に応じて再スキャン・再診断を行う

検出された脆弱性に対しては、報告書の内容を基に、その深刻度や事業への影響度を考慮して対応の優先順位を決定します。すべての脆弱性を一度に修正することは現実的ではないため、リスクの高いものから順に修正計画を立てることが効率的です。この計画に基づき、開発チームやインフラ担当者と連携して修正作業を進めていきます。

修正作業が完了したら、必要に応じて診断ベンダーに再スキャンや再診断を依頼し、修正状況を確認します。「修正したから大丈夫」と社内判断だけで終わらせるのではなく、合意した範囲で再確認を行い、その結果を記録として残すことが重要です。こうした「修正→再確認→証跡保管」のサイクルを整えることで、PCI DSS対応における脆弱性管理を説明しやすくなります。

STEP5：報告書・修正履歴・再検証結果を証跡として保管する

脆弱性診断プロセスの最終ステップは、すべての関連ドキュメントを適切に保管し、証跡としていつでも提示できる状態にすることです。初回診断の報告書から、各脆弱性に対する修正対応の記録、そして修正後の再スキャンや再診断の結果報告書まで、一連の文書を整理して安全な場所に保管しましょう。

これらの証跡は、PCI DSS対応や監査対応で説明材料として活用できます。監査人や社内関係者から質問があった際に、具体的なデータと対応履歴を基に説明できる状態にしておくことが重要です。また、これらの記録は、将来的なシステム改修やセキュリティポリシー見直しの際の貴重な情報源ともなるため、長期的な視点での管理が求められます。

年間を通じた計画的な診断スケジュール例

PCI DSS対応に必要な確認を計画的に進めるための年間スケジュール例を以下に示します。これはあくまで一般的なモデルであり、自社のシステムやリソースに合わせて調整が必要です。

第1〜4四半期（毎年3月、6月、9月、12月など）： 各四半期末にASVスキャン（外部脆弱性スキャン）および内部脆弱性スキャンを実施します。検出された脆弱性はその都度、優先順位をつけて修正し、必要に応じて再スキャンを行います。

6月〜9月頃（年1回）： 年次のペネトレーションテストおよびセグメンテーションテストを実施します。特にペネトレーションテストは、より実践的な攻撃シナリオに基づくため、専門性の高いベンダーとの綿密な調整が必要です。セグメンテーションテストも、CDEの分離が有効に機能しているかを毎年確認します。

システムに重大な変更があった場合： 新しいシステムの導入、大規模な機能追加、ネットワーク構成の大幅な変更など、CDEに影響を及ぼす可能性のある変更があった際には、随時、関連する範囲のペネトレーションテストや脆弱性スキャンを追加で実施します。

このような計画的なスケジュールに沿って診断を実施し、結果を適切に管理することで、PCI DSS対応に必要な脆弱性管理を継続しやすくなります。あわせて、診断結果、修正履歴、再スキャン結果を整理しておくことで、監査対応や社内報告にも活用しやすくなります。

▼年間スケジュール例

※横にスクロールしてご覧ください。

PCI DSSの脆弱性診断に関するよくある質問

この記事では、PCI DSS準拠を目指す皆様が抱えがちな疑問について、Q&A形式で解説していきます。本文中で触れきれなかった細かな点や、多くの担当者が悩むポイントに焦点を当て、簡潔な回答を提供することで、皆様の理解をさらに深めることを目的としています。具体的な疑問を整理し、PCI DSS対応を進める際の参考にしてください。

Q. PCI DSS対応ではASVスキャンだけ実施すればよいですか？

いいえ、PCI DSS対応では、ASVスキャンだけで十分とは限りません。PCI DSSでは、外部脆弱性スキャンに加えて、内部脆弱性スキャン、ペネトレーションテスト、必要に応じたセグメンテーションテストなど、複数の確認が関係します。どの対応が必要になるかは、自社のスコープ、SAQタイプ、カード会員データ環境の構成、監査・審査の方針によって変わります。

それぞれの診断は異なる目的と対象範囲を持っており、例えばASVスキャンはインターネットに公開されたシステムに対する外部からの脆弱性確認、内部脆弱性スキャンはファイアウォール内部のネットワークやサーバーの脆弱性確認、ペネトレーションテストは検出された脆弱性が悪用された場合の実際の侵入可否や影響範囲の評価を目的としています。

これらの診断を組み合わせることで、外部公開システム、内部ネットワーク、CDE、セグメンテーションの状況などを多角的に確認し、PCI DSS対応に必要な脆弱性管理を進めやすくなります。

Q. 脆弱性診断にかかる費用はどのくらいですか？

脆弱性診断にかかる費用は、診断対象のシステム規模や種類、診断の深度、依頼するベンダーによって大きく変動するため、一概に「いくら」と示すことは難しいです。例えば、Webアプリケーション診断であれば診断対象となるページの数や機能の複雑さ、インフラ診断であればIPアドレスの数やサーバーの台数、ネットワーク機器の数などが費用の決定要因となります。

また、診断の種類によっても費用は変わります。ASVスキャンのような定型的なスキャンに比べ、専門家が手動で詳細な脆弱性を深掘りするペネトレーションテストは費用が高くなる傾向があります。さらに、診断報告書の形式や、修正後の再スキャン・再診断が含まれるか、コンサルティングサポートの有無など、提供されるサービスの内容によっても費用は変動します。

正確な費用を知るためには、まず自社の診断対象を明確にし、複数の脆弱性診断ベンダーに対してRFP（提案依頼書）を提示し、具体的な見積もりを取得することが重要です。複数のベンダーを比較検討し、費用対効果のバランスが取れたサービスを選ぶことをおすすめします。

Q. 診断で脆弱性が発見された場合、どう対応すればよいですか？

脆弱性診断で問題が発見された場合、まず慌てずに報告書の内容を正確に理解することが重要です。診断報告書には、検出された脆弱性の内容、深刻度（CVSSスコアなど）、再現手順、推奨される修正方法などが記載されていますので、これらを基に脆弱性の事業への影響を評価し、対応の優先順位を決定します。

次に、決定した優先順位に基づき、開発チームやインフラ担当者と連携して修正計画を策定し、修正作業を進めます。この際、診断ベンダーに具体的な修正方法について相談することも有効です。修正が完了したら、必要に応じて診断ベンダーに再スキャンや再診断を依頼し、修正状況を確認する「修正→再確認」のサイクルを回すことが重要です。この一連の対応履歴と検証結果は、後の監査で求められる重要な証跡となりますので、適切に記録・保管してください。

Q. 自己問診票（SAQ）を提出する場合でも脆弱性スキャンは必要ですか？

はい、自己問診票（SAQ）を提出する場合でも、SAQの種類によっては脆弱性スキャンが重要となります。PCI DSSのSAQは、EC事業者がクレジットカード情報をどのように取り扱っているかによってタイプが分かれており、それぞれのタイプで求められる要件が異なります。

例えば、カード情報の処理を決済代行事業者に委託している場合でも、自社サイトが決済ページの表示や遷移に関与するか、自社環境でカード情報を保存・処理・伝送するかによって、該当するSAQタイプや求められる対応は変わります。

SAQ A、SAQ A-EP、SAQ Dなどでは対象範囲や確認事項が異なるため、「SAQを提出するからスキャンは不要」と一律に判断するのではなく、自社のカード情報の取り扱い方法とSAQタイプを確認したうえで、必要な脆弱性スキャンやペネトレーションテストを整理することが重要です。

したがって、まずは自社がどのSAQタイプに該当するのかを正確に把握することが重要です。不明な場合は、PCI DSSの専門家や自社の決済代行事業者へ確認し、必要な脆弱性診断を計画的に実施してください。

Q. 決済代行サービスを利用している場合、診断対象はどこまでですか？

決済代行サービスを利用している場合の診断対象範囲は、利用している決済代行の方式によって大きく異なります。カード情報が自社環境を通過するのか、あるいは決済代行業者に直接送られるのか、その経路を正確に理解することがスコープ定義の鍵となります。

例えば、顧客が決済時に決済代行業者のページへ遷移する方式、自社サイト上に決済フォームやiFrameを表示する方式、APIで決済処理を連携する方式など、実装方法によって自社環境がカード情報にどの程度関与するかは異なります。

そのため、診断対象は「決済代行サービスを使っているかどうか」だけでは判断できません。自社サイト、決済画面、API連携、管理画面、ログ、委託先との責任分界点を確認し、カード会員データ環境やそのセキュリティに影響を与える範囲を整理することが重要です。

そのため、まずは利用している決済代行サービスの契約内容や技術仕様を確認し、自社と決済代行業者との「責任分界点」を明確にしてください。これにより、自社が実施すべき脆弱性診断の対象範囲や、決済代行事業者側に確認すべき事項を整理しやすくなります。PCI DSS要件への対応状況は、契約内容、技術仕様、SAQタイプ、監査・審査の方針も踏まえて確認しましょう。

まとめ：PCI DSS対応では脆弱性診断・スコープ定義・証跡管理を計画的に進めよう

PCI DSS準拠を目指す上で、脆弱性診断は非常に重要な要素です。しかし、ただ診断を実施するだけでは十分ではありません。重要なのは、診断の種類とその目的を正しく理解し、自社のカード会員データ環境（CDE）に応じてスコープを定義し、診断結果、修正履歴、再スキャン結果を証跡として整理する流れを計画的に進めることです。

これらのプロセスを場当たり的に対応してしまうと、診断漏れによるセキュリティリスクや、反対に過剰な診断によるコスト増、監査対応時の説明不足につながる可能性があります。特に、日々変化するサイバー攻撃やシステム変更に対応するため、PCI DSS v4.xでは継続的な脆弱性管理の重要性が高まっています。

記事を読み終えた今、まずは自社のカード情報が「保存、処理、伝送」される範囲をデータフロー図などで明確にし、CDEのスコープを再確認することから始めてみませんか。そして、信頼できる診断ベンダーに相談し、自社の状況に合わせた最適な診断計画と年間スケジュールを策定してください。計画的な脆弱性管理は、PCI DSS対応を進めるうえで重要な取り組みであり、EC事業の継続性や顧客からの信頼を守るための基盤づくりにもつながります。

関連するサービス

セキュリティ脆弱性診断

セキュリティ脆弱性診断

脆弱性診断は、Webアプリケーションやネットワーク機器などに潜むセキュリティ上の弱点を洗い出し、情報漏えいや不正アクセスなどのリスクを未然に防ぐための対策です。
当社の脆弱性診断サービスでは、経験豊富なセキュリティエンジニアが診断を行い、脆弱性の有無だけでなく、リスクレベルや具体的な対処方法まで報告します。診断結果をもとに改善策をご提案することで、実効性のあるセキュリティ対策を支援します。

資料請求・お問い合わせ