すべての記事

成人向けクラシファイド広告サイトのPCI DSS対応:コンプライアンス負担を実際に決めるもの

12 分で読めます

決済代行会社に成人向けクラシファイド広告サイトを受け入れてもらうこと自体がひとつの闘いであり、それに勝った時点で、ほとんどの運営者は難関を越えたと思い込む。実際にはそうではない。ようやく承認された口座には、年齢確認やモデレーション、州や検索エンジンが課すどんなルールとも無関係な、継続的な義務がついてくる。それはカードネットワーク自身が定めたセキュリティ基準であり、カード番号がビジネスのどの部分であれ触れた瞬間から、その規模に関係なく適用される。

以下は法律上の助言ではなく、実際にカード会員データを扱う者は、自らの状況をQualified Security Assessorに確認すべきである。これは、ほとんどの運営者が自分で下していると気づかないまま下している決断のかたちである。というのも、たいていはもっと洗練された決済ページを作りたい開発者がその決断を先に下してしまい、質問がビジネス側に届く頃にはもう決まっているからだ。

読まずに署名したルール

PCI DSS、すなわちペイメントカード業界データセキュリティ基準は、政府の法律ではなく、どの国家機関も執行していない。これは、すべての加盟店が買取銀行や決済代行会社と結ぶ契約に書き込まれた契約上の義務であり、Visa、Mastercardをはじめとするカードネットワークが、カード番号を保存・処理・伝送するあらゆるビジネスに対してこれを適用するよう、各アクワイアラーに義務付けていることから存在する。基準そのものを管理する団体は明確にこう述べている。直接であれ第三者経由であれ、カード会員データを扱うあらゆる事業体に適用され、規模や取引量による例外はないと。

これは、決済代行会社が口座開設に同意する前に尋ねる質問とは別のものだ。決済代行会社があなたと取引することに同意する前に知りたいことは、事業そのものについてである。所有者は誰か、広告はどう審査されているか、広告主の本人確認はどうしているか。PCI DSSはその口座が存在した後に始まり、実質的に終わることはない。ビジネスがカードを受け付ける限り毎年更新され、カードの受け付け方が変わるたびに、その形も変わる。

取引量は確かに関係するが、一般に想像されているのとは違う形でだ。取引量は加盟店の「レベル」を1から4まで決め、そのレベルがコンプライアンスの検証方法を決める。小規模な運営者は自己評価アンケートに記入すればよいが、年間数百万件の取引を処理する事業には外部監査人が必要になる。取引量がしないことがひとつある。それは誰かを免除することだ。月に数百件しか取引がない高リスクの加盟店も、大手チェーンとまったく同じ基準の根幹に縛られている。検証方法がより短い書式になるだけだ。

何年もの作業量を決めるたったひとつの決断

特定のビジネスに適用される書式は、自由に選べるものではない。それは完全にひとつの技術的事実によって決まる。カード番号が、経路のどこかの時点で、運営者が管理するシステムを通過するかどうかである。顧客を決済代行会社がホストする決済ページに送るか、その代行会社が提供する正しく隔離された決済用iframeを埋め込めば、カード番号は運営者自身のサーバーには決して触れない。逆に、カード番号を収集し、たとえ一瞬であっても転送前に自分自身のバックエンドへ送る決済フォームを構築すれば、触れることになる。

このたった一つの事実が、最も軽いアンケートと最も重いアンケートを桁違いに分ける。完全に外部委託する経路、SAQ Aと呼ばれるものは、およそ20項目の要件で済む。運営者自身のページが決済プロセスの一部を提供したり影響を与えたりする経路、たとえば自前でホストするフォームのフィールドがデータを転送するような場合は、カード番号そのものに直接触れなくても、SAQ A-EPに該当し、200項目近くに及ぶ。実際にカードデータを自分のシステム上で保存・処理・伝送する場合はSAQ Dに該当し、暗号化、鍵管理、ネットワークセグメンテーション、アクセスログ、アクセス制御など、基準の全管理策を網羅し、数百項目に達する。

ここでよくある誤解をすぐに解いておく価値がある。基準に適合したプロバイダーのiframeを使うだけでは、自動的により重いSAQ A-EPの階層に落ちるわけではない。正しく隔離されたサードパーティ製のiframeで、運営者自身のページが決済フィールドを見たり触れたりできるコードを一切含まない場合、通常は軽いSAQ Aの経路のままで済む。事業をひとつ上の階層へ押し上げるのは、運営者自身のコードがそのページに入り込むことだ。自前で構築したフォームであれ、決済を「改善」するために追加したスクリプトであれ、決済代行会社ではなく運営者が書いたコードを通じてブラウザがカードデータを送る旧式の実装であれ、それは同じことだ。

軽い経路が、去年から今も求めていること

かつては正しかったが今は違う思い込みを正す価値がある。外部委託の経路を選んだ運営者たちは、それによって基準の技術的負担の大部分から外れられることを正しく学んだが、それが継続的なセキュリティ検査が一切不要という意味だと今でも思い込んでいる者もいる。2025年4月から施行されているPCI DSSバージョン4.0.1以降、それはもう正しくない。SAQ Aには今、Approved Scanning Vendorによる四半期ごとの外部脆弱性スキャンという要件が含まれており、これはリダイレクトやiframeをホストしている運営者自身のウェブサイトに対して実施されるもので、そのサイト自体がカード番号を一度も見たことがなくても対象になる。

この変更の背景にある理屈は、口に出してみれば単純だ。顧客を決済処理会社へ送るページも、依然として攻撃対象領域の一部である。侵害された決済ページは、顧客を本物の決済処理会社とは異なる場所へリダイレクトしたり、iframeが読み込まれるより前にブラウザから直接カードデータを読み取る悪意あるスクリプトを読み込んだりできる。これは実際の加盟店を襲ったことのある攻撃パターンだ。同じ論理から、関連する二つの要件が生まれる。運営者は決済ページ上で動くすべてのスクリプトの一覧を維持しなければならず、そのページの内容への不正な変更を検知しなければならない。これらの義務がSAQ Aに存在するのは、まさに決済ページが運営者自身のものであるからで、カード番号自体が一度も運営者のものではなかったとしても変わらない。

軽い経路が今も回避できるもの、そしてこれこそが本当に重要な差なのだが、それはSAQ A-EPとSAQ Dが求める年次のペネトレーションテストであり、それらの階層が要求する深い内部統制、すなわち保存されたカードデータの暗号化、それを保護する鍵の管理、それに触れるあらゆるシステムを取り囲むネットワークのセグメンテーション、そしてすべてのアクセスの詳細な記録である。外部委託の経路を選ぶことは、セキュリティ関連の作業が一切なくなることを意味しない。それが意味するのは、そうしなければ事業が自ら保存することになっていたデータをめぐる恒常的なセキュリティプログラムの代わりに、年に数時間のスキャンとスクリプトの衛生管理で済むということだ。

これを誤ると何を失うか

これらはいずれも裁判所や規制当局が強制するものではなく、それが軽視されやすい理由のひとつでもある。カードネットワークは、その傘下の加盟店が基準に適合していない場合、買取銀行に罰金を科し、アクワイアラーは契約を通じてそのコストをそのまま加盟店に転嫁する。たいていは控えめな金額から始まり、不適合の状態が続くほど額が上がっていく。この金額をアクワイアラーごとに定める公開の一覧表は存在しない。この取り決めは公開ルールではなく、私的な契約の中にあるからだ。しかし方向性は一貫している。罰金は時間とともに増え、事業がその遅れをどれだけうまく説明できるかとは関係がない。

これは単に不適合であることのコストにすぎない。実際の侵害、すなわちSAQ Aがまさに避けさせるために設計されたデータを運営者が扱っていたせいで保存されたカード番号が漏えいするような事態は、まったく別の次元の出費となる。カードネットワークは、誰かが口座を再開できるようになる前に、専門会社によるフォレンジック調査を要求できる。その費用は結果にかかわらず加盟店が負担し、影響を受けたカードは加盟店の費用で再発行される。サイバー責任保険がこの種の穴を、こうした事業のために埋めてくれることはめったにない。成人向けコンテンツは、複数の大手保険会社のサイバー保険で除外業種のリストに載っており、つまりここで説明した損失は、単に高くつくというより、そもそも保険の対象外であることが非常に多い。

もっとも長く続く結果は、罰金でも、まして調査でもない。それは、侵害や長期にわたる不適合が記録に残った時点で、アクワイアラーがリスクを負い続けるのではなく口座を閉鎖するという決定であり、その閉鎖を、他のアクワイアラーが新規口座を開く前に確認できる形で記録するということだ。最初に構築するのに何ヶ月もかかった決済関係は、そうした履歴が事業に付いて回る状態では、再構築がはるかに難しくなる。

今月やるべきこと

まずは、今日実際に適用されるアンケートがどれなのかを、書面で確認することから始めよう。答えを推測するのではなく、決済代行会社に直接尋ねること。現在の決済がリダイレクトなのか、正しく隔離されたiframeなのか、それとも経路のどこかで運営者自身のサーバーに触れるものなのかを確認する。この質問への答えこそが、一文でまとめたコンプライアンスプログラムそのものだからだ。それは電話ではなくメールで得ること。それが以降のすべての判断の基準点になる。

カードの受け付け方を変更する要望はすべて、デザインの問題である前に、まずコンプライアンスの問題として扱うこと。ホストされたページが汎用的に見えるからとカスタムの決済フォームを作りたがる開発者や、決済用iframeをホストしているのと同じページにチャットや分析用スクリプトを追加する開発者は、誰がそう位置づけようとなかろうと、PCIに関わる決定を下している。そうした変更は、公開される前にレビューすべきであり、スキャンで指摘された後ではない。

年次の証明書は期限内に提出し、四半期ごとのスキャン結果は、何も変わらない退屈な回のものも含めて保管しておくこと。期限切れの証明書は、アクワイアラーの目には、一度も提出しなかったのとまったく同じに映るからだ。基盤となる仕組みが正しければ、これらはどれも難しいことではない。ホストされたページか正しく隔離されたiframeを中心に一度きちんと構築された決済は、これを年に一度繰り返す、午後ひとつ分の事務作業に変える。一方、いつの間にかカードデータに触れる習慣がついてしまった決済は、同じ義務を、事業がそもそも運用するつもりのなかった常設のセキュリティプログラムに変えてしまう。

DEMOを試す

エスコート情報サイトのシステム、すぐ使える