PCI DSSとは？12要件・対象企業・準拠方法をわかりやすく解説

クレジットカード決済を導入する企業にとって、カード番号や認証情報の漏えいは、顧客への損害だけでなく、信用低下、決済停止、調査費用、システム改修費用などにつながる重大な問題です。決済処理を外部サービスへ委託している企業であっても、カード情報の安全性に関する責任が完全になくなるわけではありません。

PCI DSSは、クレジットカード情報を保存、処理、送信する組織や、カード会員データ環境の安全性に影響を与える組織を対象とするセキュリティ基準です。加盟店、決済代行事業者、カード発行会社、加盟店契約会社、その他のサービス提供事業者などが対象になり得ます。I DSSの意味や対象範囲だけでなく、12の要件、ECサイトで必要になる対策、自己問診と外部審査の違い、設定例、導入手順まで詳しく解説します。ただし、実際に必要となる準拠確認方法は、加盟店契約会社、国際カードブランド、決済代行事業者などの判断によって異なるため、最終的には契約先への確認が必要です。I DSSとは

PCI DSSとは、クレジットカードなどの決済カード情報を安全に取り扱うために設けられたセキュリティ基準です。単なる技術設定の一覧ではなく、ネットワーク、サーバー、アプリケーション、従業員、委託先、物理設備、監視、教育、事故対応までを含む包括的な管理体系になっています。

1.1 PCI DSSの正式名称

PCI DSSは「Payment Card Industry Data Security Standard」の略称で、日本語では「決済カード業界データセキュリティ基準」などと表現されます。カード情報を取り扱う環境に共通する最低限の安全対策を定め、情報漏えいと不正利用の危険を抑えることが主な目的です。

対象はカード番号を直接保存するシステムだけではありません。カード情報を通過させるネットワーク、決済画面に影響を与えるウェブサーバー、管理者が接続する端末、ログ管理基盤なども対象範囲に含まれる可能性があります。

1.2 PCI SSCの役割

PCI DSSを策定し、関連資料、教育制度、審査員制度などを運営している組織がPCIセキュリティ基準審議会です。同審議会は基準や評価手順を提供しますが、個々の加盟店に対して直接準拠を強制する機関ではありません。

実際の準拠確認や報告を求める主体は、国際カードブランド、加盟店契約会社、決済代行事業者などです。そのため、自社がどの確認書類を提出すべきかについては、一般的な情報だけで判断せず、契約先から示された条件を確認する必要があります。PCI DSSが求められる理由

カード番号は、漏えいした後に不正決済や詐欺へ利用される可能性がある重要情報です。決済システムでは、ウェブアプリケーション、業務端末、委託先、外部スクリプトなど複数の要素が接続されるため、一つの弱点が環境全体への侵入口になることがあります。

PCI DSSは、暗号化だけに依存せず、多層的な安全対策を求めています。ネットワーク制御、不要な保存の禁止、アクセス制限、本人確認、ログ監視、脆弱性検査、従業員教育を組み合わせることで、攻撃の発生防止と早期発見の両方を実現します。

1.4 法律との関係

PCI DSSは、日本の法律そのものではなく、決済カード業界が定めるセキュリティ基準です。しかし、加盟店契約や決済サービスの利用条件に準拠義務が含まれることがあり、実務上は無視できない基準となっています。

個人情報保護法などの法令を守っているからといって、PCI DSSへの対応が自動的に完了するわけではありません。反対に、PCI DSSへ準拠していても、個人情報保護、消費者保護、業界固有の法令など、別の義務を満たしたことにはなりません。

1.5 PCI DSS準拠の意味

PCI DSS準拠とは、評価対象となる時点で、対象範囲に適用される要件を満たしていることを確認した状態です。一度審査を通過すれば永続的に安全だという認証ではなく、日常的な運用を継続することが前提です。

新しいサーバーの追加、決済画面の変更、委託先の変更、組織再編、クラウド移行などがあれば、対象範囲や対策内容も変化します。準拠確認を年に一度だけ行う行事と考えず、通常業務の中で安全性を維持することが重要です。

2. PCI DSSの対象となる事業者

PCI DSSの対象かどうかは、会社の規模や業種名だけでは決まりません。カード会員データを保存、処理、送信しているか、またはカード会員データ環境の安全性に影響を与えられるかによって判断します。実店舗の加盟店

店舗の決済端末でクレジットカードを受け付ける小売店、飲食店、宿泊施設、医療機関などは、PCI DSSの対象になり得ます。端末自体にカード番号を保存していなくても、端末が接続されるネットワークや管理方法が評価対象になることがあります。

承認済みの決済端末を導入しただけで、店舗環境全体が自動的にPCI DSS準拠になるわけではありません。端末の改ざん確認、初期パスワードの変更、ネットワーク分離、委託先管理なども確認する必要があります。

2.2 ECサイト運営企業

ECサイトでカード決済を提供している事業者も対象です。決済画面を自社サーバーで処理する方式だけでなく、外部決済画面へ転送する方式や、外部事業者の入力画面を埋め込む方式でも、一定の責任が残ります。

特に埋め込み型の決済画面では、自社ページに読み込まれる不正なスクリプトが決済情報を盗み取る可能性があります。そのため、外部委託を理由に自社サイトの更新管理やスクリプト管理を省略することはできません。決済代行事業者

加盟店に決済機能を提供する決済代行事業者は、多数の取引やカード情報を扱う可能性があります。加盟店よりも広いシステム環境を管理することが多く、サービス提供事業者として高度な確認が必要になる場合があります。

決済代行事業者が準拠していても、利用する加盟店の責任がすべて移転するわけではありません。どの要件を委託先が担当し、どの要件を加盟店側が担当するかを、契約書や責任分担表で明確にする必要があります。

2.4 コールセンターと予約受付

電話でカード番号を聞き取り、予約や注文を処理するコールセンターも対象になり得ます。通話録音、手書きメモ、業務端末の画面、入力システムなど、複数の場所にカード情報が残る危険があります。

カード確認コードを通話録音へ残したり、担当者が紙へ書き写したりする運用は、重大な危険につながります。録音停止機能、音声の伏せ字処理、専用端末、持込物制限など、業務手順と技術対策を組み合わせることが必要です。

2.5 外部委託している加盟店

決済処理を完全に外部委託し、自社がカード番号を保存、処理、送信しない加盟店でも、PCI DSSに関する責任がなくなるわけではありません。委託先の準拠状況を確認し、責任を記載した契約を維持し、少なくとも年に一度は委託先の状況を監視する必要があります。、自社へ直接適用される要件を減らせる可能性はあります。ただし、決済ページへ影響を与えるウェブサイト、管理者アカウント、委託先の選定、契約管理などは引き続き自社の責任になります。

3. PCI DSSで保護するデータ

PCI DSSでは、すべての決済関連情報を同じように扱うわけではありません。保存できる情報、保護措置を講じれば保存できる情報、取引承認後には保存してはならない情報を区別する必要があります。

3.1 カード番号

カード番号は、カード会員データの中心となる情報です。保存する必要がある場合は、暗号化、切り詰め、トークン化、強力な暗号技術を利用した一方向変換などにより、読み取れない状態にしなければなりません。

画面や帳票に表示する場合も、業務上の必要性がない利用者へ全桁を見せない設計が重要です。表示時の伏せ字と、保存時に一部を削除する処理は目的が異なるため、同じ対策として混同しないようにします。カード名義人と有効期限

カード名義人、有効期限、サービスコードなどは、カード番号と一緒に扱われることが多い情報です。これらの情報だけではPCI DSSの中心となるカード番号と同じ扱いにならない場合がありますが、カード番号と組み合わされる環境では保護が必要です。

保存目的が不明確なまま、注文データや顧客管理データへ長期間残すべきではありません。業務上、法令上、契約上必要な保存期間を定め、期限を過ぎた情報を安全に削除する仕組みを設けます。

3.3 カード確認コード

カード裏面や表面に記載される3桁または4桁のカード確認コードは、非対面取引で本人がカードを所持していることを確認するために利用されます。一般に、カードブランドごとに異なる名称で呼ばれています。

カード確認コードは、特定取引の承認前に取得することはできますが、取引承認後に保存することは認められていません。顧客本人から保存の同意を得た場合でも、保存を正当化することはできません。磁気ストライプと暗証番号データ

磁気ストライプやチップに含まれる完全な読み取りデータ、暗証番号、暗証番号ブロックなどは、機密認証データとして扱われます。これらは、不正カードの作成や本人認証の突破に悪用される危険が高い情報です。

取引承認後は、暗号化していても原則として保存できません。システム設計時には、保存先を暗号化するだけでなく、そもそもデータベース、ログ、例外情報、監視画面へ書き込まれないことを確認する必要があります。

3.5 保存期間と削除

カード情報の保存は、「将来使うかもしれない」という理由で続けるべきではありません。利用目的、保存場所、管理責任者、保存期間、削除方法を明文化し、定期的に不要データを検索して削除します。

本番データベースだけでなく、バックアップ、表計算ファイル、電子メール、チャット、監視ログ、試験環境、開発者の端末なども確認対象です。意図せず作成された複製が、正式なデータベースより長く残っているケースに注意が必要です。

4. PCI DSS v4.0.1で変わった点

2026年7月時点でPCI SSCがサポートする現行版はPCI DSS v4.0.1です。PCI DSS v4.0は2024年12月31日に廃止され、v4.0.1のみが現行版となっています。v4.0.1の位置付け

PCI DSS v4.0.1は、v4.0の限定的な改訂版として2024年6月に公開されました。新しい要件を追加する改訂ではなく、表記上の修正、説明の明確化、適用上の注意事項の追加などが中心です。

要件が追加または削除されたわけではないため、v4.0から対応を進めていた企業がすべての仕組みを作り直す必要はありません。ただし、説明の変更によって、自社の解釈や証跡が適切かを再確認する必要があります。2025年3月31日の期限

PCI DSS v4.xでは、組織が準備期間を確保できるよう、一部の新要件が将来日付付き要件として扱われていました。これらの要件は2025年3月31日から正式に有効となっているため、現在は任意の推奨事項ではありません。

対象には、決済ページのスクリプト管理、改ざん検知、対象範囲の定期確認、危険度に基づく分析などが含まれます。v4.0.1への改訂によって、2025年3月31日という有効日は変更されていません。個別危険度分析

v4.xでは、特定の管理策について実施頻度などを決定するための個別危険度分析が導入されました。資産、脅威、脆弱性、発生可能性、影響などを評価し、その環境に適した管理方法を説明する仕組みです。

分析結果は、単に「危険が低い」と記載するだけでは不十分です。対象資産、想定する脅威、既存の対策、判断した頻度、承認者、見直し日などを記録し、監査時に判断根拠を示せる状態にします。標準的な方法と個別設計方法

PCI DSS v4.xでは、定められた要件に沿って対策を実施する標準的な方法に加え、要件の目的を別の管理策で達成する個別設計方法が用意されています。これにより、複雑なシステムや新しい技術を利用する組織にも一定の柔軟性が与えられます。

個別設計方法は、要件を省略するための方法ではありません。管理目的、実装内容、有効性、試験方法、危険度分析などを詳細に説明する必要があり、一般的には標準的な方法より高度な設計力と証拠が求められます。

4.5 v4.0.1で明確化された項目

v4.0.1では、カード番号を鍵付き暗号学的ハッシュで読み取れなくする場合の扱い、決済ページのスクリプト管理、フィッシング耐性を持つ本人確認、委託先との関係などが明確化されました。

また、重大な脆弱性に対する修正プログラムを30日以内に適用するという表現についても整理されています。企業は変更点の要約だけでなく、現行版の本文、適用上の注意、試験手順を確認して対応する必要があります。I DSSの12要件

PCI DSSは、6つの目標と12の主要要件で構成されています。12要件は独立しているのではなく、防御、制限、監視、改善を重ねる多層的な安全対策として連携します。安全なネットワークとシステム

要件1では、ネットワーク安全制御を導入し、維持することが求められます。要件2では、すべてのシステム構成要素に安全な設定を適用し、初期設定や不要な機能を残さないことが求められます。

境界防御装置を設置しただけでは十分ではありません。許可された通信経路、変更理由、設定の確認方法、管理責任者などを記録し、継続的に見直すことが重要です。

5.2 アカウントデータの保護

要件3では、保存されたアカウントデータを保護します。要件4では、公開されたネットワークを通じてカード会員データを送信する際に、強力な暗号技術を使用します。

保存しないことが最も効果的な保護策になる場合があります。必要なデータだけを保存し、通信経路では安全な暗号化を利用することで、漏えい時の影響と攻撃可能な範囲を小さくできます。

5.3 脆弱性管理

要件5では、悪意のあるソフトウェアからシステムとネットワークを保護します。要件6では、安全なシステムとソフトウェアを開発し、維持します。

ウイルス対策製品の導入だけでなく、脆弱性情報の収集、修正プログラムの適用、ソースコードの確認、変更管理、決済ページのスクリプト管理などが含まれます。

5.4 アクセス制御

要件7では、業務上必要な利用者だけにシステムとカード情報へのアクセスを許可します。要件8では、利用者を一意に識別し、適切な本人確認を行います。要件9では、カード情報への物理的なアクセスを制限します。

共有アカウントを使うと、誰が操作したかを追跡しにくくなります。個人別の識別子、役割に応じた権限、強力な本人確認、入退室管理を組み合わせることが必要です。

5.5 監視、試験、組織運用

要件10では、システムとカード情報へのアクセスを記録して監視します。要件11では、システムとネットワークの安全性を定期的に試験します。要件12では、方針、教育、危険度管理、委託先管理、事故対応などを運用します。

技術的な対策が正しく動いているかを、ログや検査によって確認しなければなりません。また、担当者が退職した場合や委託先を変更した場合でも対策が続くよう、組織的な手順として定着させます。

6. 要件1・2に対応するネットワークと設定

要件1と要件2では、カード情報を扱う環境へ不必要な通信や機能を持ち込まないことが重要です。境界制御、通信経路、初期設定、管理用接続、クラウド設定を継続的に管理します。

6.1 ネットワーク安全制御

外部と内部、業務環境とカード会員データ環境、信頼できる接続と信頼できない接続の境界に、安全制御を配置します。許可する通信は、送信元、送信先、通信番号、用途、責任者などを明確にします。

「社内ネットワークだから安全」という前提は避けるべきです。感染端末や不正な利用者からカード会員データ環境を守るため、内部通信にも必要最小限の制限を適用します。

6.2 ネットワーク分離

カード会員データ環境を他の業務環境から分離すると、PCI DSSの対象範囲を縮小できる可能性があります。店舗用無線通信、従業員用端末、開発環境などを決済環境と分ける設計が代表例です。

ただし、設定上分けたつもりでも、実際に通信できる状態なら分離は成立しません。通信試験、侵入試験、経路確認などを通じて、境界が有効であることを証明する必要があります。

6.3 初期設定の変更

機器やソフトウェアの初期利用者名、初期パスワード、初期の暗号鍵、不要な共同体文字列などは、導入時に変更します。初期設定は製品資料やインターネット上で知られている場合があり、攻撃に利用されやすいためです。

不要な利用者、通信機能、試験用画面、例示用アプリケーション、古い通信方式なども無効化または削除します。安全な構成基準を作成し、同じ種類のサーバーへ一貫した設定を適用します。

6.4 安全な通信設定

管理画面やカード会員データを送信する通信では、脆弱な暗号方式を無効化します。PCI DSSは特定のTLS版だけを一律に指定していませんが、SSL、TLS 1.0、TLS 1.1など既知の攻撃に弱い方式は強力な暗号技術として扱われません。、名称、信頼経路、秘密鍵の管理も確認します。通信が暗号化されていても、期限切れ証明書や弱い暗号方式を許可していれば、十分な保護にならない可能性があります。

Nginxの設定例

server {    listen 443 ssl http2;    server_name payment.example.jp;    ssl_certificate     /etc/nginx/tls/payment.crt;    ssl_certificate_key /etc/nginx/tls/payment.key;    ssl_protocols TLSv1.2 TLSv1.3;    ssl_session_timeout 1d;    ssl_session_cache shared:TLS:20m;    ssl_session_tickets off;    add_header Strict-Transport-Security        "max-age=31536000; includeSubDomains" always;    location / {        proxy_pass http://payment_backend;        proxy_set_header Host $host;        proxy_set_header X-Forwarded-Proto https;    } }

この例は設定の一部を示すものであり、記載内容だけでPCI DSS準拠になるわけではありません。利用する暗号方式、負荷分散装置、証明書管理、接続先、例外設定を含めて評価します。

6.5 構成変更の管理

ファイアウォール規則やクラウドの安全グループを変更する際は、申請、影響確認、承認、試験、実施、記録の流れを定めます。緊急変更についても、実施後に承認と確認を行う手順が必要です。

古い規則を放置すると、過去のシステム向けに開けた通信経路が攻撃に利用される可能性があります。規則一覧を定期的に見直し、利用目的が確認できない設定を削除します。

7. 要件3・4に対応するデータ保護

要件3と要件4では、保存中と通信中のカード情報を保護します。暗号化製品を導入するだけでなく、保存量の削減、鍵管理、表示制限、ログ対策などを含めて設計します。

7.1 カード番号を保存しない設計

自社でカード番号を必要としない場合は、決済代行事業者が発行する顧客識別子や決済識別子を保存する方式が有効です。カード番号を自社環境に入れなければ、漏えい危険と管理対象を大きく減らせます。

ただし、識別子からカード番号へ戻せる仕組みを自社が管理している場合や、決済画面が自社環境を通過する場合は、対象範囲から外れない可能性があります。データの実際の流れを確認して判断します。

7.2 表示時の伏せ字処理

業務画面や帳票では、カード番号の全桁を確認する必要がある利用者を限定します。顧客問い合わせや取引照合だけが目的なら、末尾の数桁だけを表示する設計が一般的です。

画面上で伏せ字にしても、通信やデータベースに全桁が残っていれば、保存上の保護にはなりません。表示、保存、通信という場面ごとに、別々の対策を設ける必要があります。honによる表示用処理例

def mask_card_number(card_number: str) -> str:    digits = "".join(ch for ch in card_number if ch.isdigit())    if len(digits) < 10:        raise ValueError("カード番号の形式を確認してください")    visible_tail = digits[-4:]    masked_length = len(digits) - len(visible_tail)    return ("*" * masked_length) + visible_tail print(mask_card_number("4111111111111111")) # ************1111

この処理は表示用の伏せ字例です。元のカード番号を安全に保存する暗号化や切り詰め処理の代替にはなりません。

7.3 暗号鍵の管理

保存データを暗号化していても、暗号鍵を同じサーバーの同じ権限で読み出せる状態では、攻撃者に同時取得される危険があります。鍵の保管場所、利用権限、交換、失効、廃棄、バックアップを管理します。

鍵管理システムや機器を利用し、アプリケーション管理者が鍵の値そのものを簡単に閲覧できない設計を検討します。鍵の操作履歴を記録し、不正な復号処理を検知できるようにします。

7.4 ログへのカード番号混入防止

入力値、通信内容、例外情報をそのままログへ出力すると、カード番号や確認コードが記録される可能性があります。特に開発時の詳細記録を本番環境へ残すと、意図しない保存につながります。

禁止項目を定義し、共通のログ処理で削除または置換します。定期的にログ保管場所を検索し、カード番号に似た文字列が保存されていないかも確認します。

ログの伏せ字処理例

import logging import re CARD_PATTERN = re.compile(r"\b(?:\d[ -]*?){13,19}\b") class PaymentDataFilter(logging.Filter):    def filter(self, record: logging.LogRecord) -> bool:        message = record.getMessage()        sanitized = CARD_PATTERN.sub("[カード番号を削除]", message)        record.msg = sanitized        record.args = ()        return True handler = logging.StreamHandler() handler.addFilter(PaymentDataFilter()) logger = logging.getLogger("payment") logger.setLevel(logging.INFO) logger.addHandler(handler) logger.info("決済入力値: 4111 1111 1111 1111")

正規表現だけでは誤検知や見逃しが発生します。入力時点で機密情報をログへ渡さない設計を優先し、伏せ字処理は補助対策として利用します。

7.5 公開ネットワーク上の暗号化

インターネット、無線通信、外部事業者との接続など、公開または信頼できないネットワークを通じてカード情報を送信する場合は、強力な暗号技術を使用します。利用者のブラウザーから決済サーバーまでの経路だけでなく、内部の中継区間も確認します。

電子メール、一般的なチャット、平文のファイル転送などでカード番号を送らないよう、業務手順も整備します。従業員が安全でない方法を選ばなくて済むよう、承認済みの送信手段を用意することが重要です。

8. 要件5・6に対応する脆弱性管理

要件5と要件6では、悪意のあるソフトウェアと既知の脆弱性からシステムを守ります。製品導入だけで完了させず、情報収集、評価、修正、試験、開発、公開後の監視まで継続します。

8.1 悪意のあるソフトウェア対策

悪意のあるソフトウェアの影響を受ける可能性があるシステムには、検知、防止、隔離、削除などの機能を導入します。業務端末だけでなく、管理端末、サーバー、仮想環境なども評価します。

従来は攻撃対象になりにくいと考えられていたシステムでも、現在の脅威情報に基づいて判断します。対策製品の停止を利用者へ許可せず、定義情報、検知機能、記録機能を最新状態に保ちます。

8.2 脆弱性情報の収集

利用しているオペレーティングシステム、ウェブサーバー、枠組み、ライブラリ、機器について、信頼できる情報源から脆弱性情報を収集します。公開された脆弱性には危険度を付け、対象システムへの影響を評価します。

危険度の点数だけで優先順位を決めると、自社環境で悪用可能な脆弱性を見落とす場合があります。外部公開の有無、カード情報への到達可能性、攻撃コードの公開状況、既存対策などを含めて判断します。

8.3 修正プログラムの適用

重大な脆弱性に対する修正プログラムや更新は、公開後速やかに適用します。PCI DSS v4.0.1では、30日以内の適用に関する表現が重大な脆弱性を対象とすることが明確化されています。接適用するのではなく、試験環境で互換性や障害の有無を確認します。すぐに適用できない場合は、通信制限や機能停止などの暫定対策を実施し、例外理由と解消予定を記録します。

8.4 安全な開発工程

要件定義、設計、実装、試験、公開、保守の各段階に安全確認を組み込みます。入力値の検証、権限確認、機密情報の管理、外部部品の安全性などを、公開直前だけでなく開発中から確認します。

ソースコードの相互確認や自動検査を導入し、重大な問題を修正してから公開します。開発者が自分で作成した変更だけを確認する体制では、見落としや判断の偏りが生じやすいため、独立した確認を設けます。

入力値を連結しない処理例

import sqlite3 connection = sqlite3.connect("orders.db") def find_order(order_id: str):    cursor = connection.cursor()    cursor.execute(        """        SELECT order_id, customer_id, payment_status        FROM orders        WHERE order_id = ?        """,        (order_id,),    )    return cursor.fetchone()

入力値をSQL文へ直接連結せず、引数として渡します。ただし、安全な開発には権限設定、入力形式の確認、エラー処理、監査記録なども必要です。

8.5 公開ウェブアプリケーションの保護

公開ウェブアプリケーションは、定期的および重要な変更後に脆弱性を確認します。専門的な手動確認、自動検査、ウェブアプリケーション防御機能などを、環境に応じて組み合わせます。

防御装置を導入していても、アプリケーション自体の欠陥を放置してよいわけではありません。検知した攻撃、遮断した通信、例外規則を確認し、開発側の恒久修正へつなげます。

9. 要件7・8・9に対応するアクセス制御

アクセス制御では、誰が、どの情報へ、どの目的で、どのようにアクセスできるかを管理します。論理的な権限だけでなく、サーバー室、紙媒体、決済端末などへの物理的な接触も対象です。

9.1 必要最小限の権限

利用者には、担当業務を実施するために必要な権限だけを付与します。すべての担当者へ管理者権限を付与すると、一つのアカウントが侵害されたときの影響が大きくなります。

職種や担当業務ごとに役割を定義し、標準権限を割り当てます。例外的な権限は、理由、承認者、期限を記録し、不要になった時点で削除します。

9.2 個人別アカウント

複数人で同じ管理者アカウントを共有すると、操作した人物を特定できません。従業員、委託先、管理者には個人別の識別子を割り当て、操作記録と結び付けます。

システム処理用のアカウントについても、所有者、利用目的、権限、認証情報の管理方法を明確にします。利用されていないアカウントや退職者のアカウントを速やかに無効化します。

9.3 多要素認証

カード会員データ環境へのアクセスや管理用アクセスでは、多要素認証が重要です。知識情報、所持物、生体情報など、異なる種類の要素を組み合わせて本人を確認します。

パスワードを二つ入力させても、同じ種類の要素であるため多要素認証にはなりません。認証要素が独立しており、一方が侵害されても他方まで簡単に突破されない設計にします。

9.4 パスワードと認証情報

パスワードを認証要素として利用する場合は、十分な長さ、初期値の変更、不正試行への制限、安全な保存などを実施します。PCI DSS v4.xでは、原則として12文字以上のパスワードまたはパスフレーズが求められます。システムが対応できない場合の扱いも定められています。で保存せず、適切な一方向変換と無作為値を利用します。管理者が利用者の現在のパスワードを確認できる仕組みではなく、再設定手続によって対応します。

パスワード方針の設定例

authentication_policy:  minimum_length: 12  require_multi_factor: true  maximum_failed_attempts: 10  lockout_minutes: 30  prevent_known_compromised_passwords: true  require_initial_password_change: true  prohibit_shared_accounts: true

これは方針を表す例であり、実際の適合性は製品の動作、利用者区分、本人確認方式、例外処理などを含めて評価します。

9.5 物理的アクセス

サーバー室、通信機器、紙の帳票、記録媒体、決済端末などへ接触できる人物を制限します。入退室記録、来訪者証、監視、施錠、媒体の保管と廃棄などを運用します。

実店舗では、決済端末の外観、封印、配線、設置位置を定期的に確認します。不審な部品や交換の痕跡を発見した場合の報告先と、端末の利用停止手順も決めておきます。

10. 要件10・11に対応する監視と試験

安全対策は、導入した時点だけでなく、継続して正常に動作していることを確認しなければなりません。ログ監視、脆弱性検査、侵入試験、改ざん検知などによって、異常と弱点を早期に発見します。

10.1 監査ログの取得

利用者のアクセス、管理操作、認証成功・失敗、権限変更、重要設定の変更などを記録します。ログには、誰が、いつ、どのシステムで、何を行い、成功したか失敗したかを確認できる情報を含めます。

アプリケーション、データベース、クラウド、ネットワーク機器のログ形式が異なる場合は、集中管理基盤へ集約します。時計がずれていると事象の順番を追えないため、時刻同期も重要です。

10.2 ログの確認と警告

ログを保存するだけでは、攻撃を早期発見できません。重要システム、管理者操作、本人確認システム、安全制御などの記録を定期的に確認し、重大な事象には警告を設定します。

大量の警告が発生すると、担当者が重要な事象を見落とす可能性があります。危険度、カード会員データ環境への影響、発生元などを基に優先順位を付け、対応期限を定めます。

検知規則の例

rule:  name: "決済管理画面への連続認証失敗"  source: "payment-admin"  condition:    event_type: "login_failed"    count: 10    within_minutes: 5    group_by:      - user_id      - source_ip  severity: "high"  actions:    - "security_team_notification"    - "temporary_account_lock"    - "incident_ticket_creation"

実際には、正当な操作を誤って遮断しないよう試験を行い、警告を受け取る担当者と対応手順を定めます。

10.3 外部脆弱性検査

インターネットから接続できる対象システムについて、承認された検査事業者による外部脆弱性検査が必要になる場合があります。PCI SSCの用語では、この事業者を承認済みスキャン事業者と呼びます。なくとも3か月ごと、および重要な変更後に実施します。不合格となった脆弱性は修正し、再検査で解消を確認します。対象となる通信先を漏れなく申告することも重要です。

10.4 内部脆弱性検査と侵入試験

内部検査では、社内やカード会員データ環境の内部から見える脆弱性を調べます。外部からは到達できない管理画面、データベース、内部サーバーなどの弱点を発見できます。

侵入試験では、単一の脆弱性だけでなく、複数の弱点を組み合わせて重要情報へ到達できるかを確認します。ネットワーク分離を対象範囲の縮小に利用している場合は、分離が実際に有効かも試験します。

10.5 変更検知

重要ファイル、設定、決済ページ、通信ヘッダーなどが不正に変更されていないかを監視します。基準となる正常状態を記録し、差分が発生した場合は担当者へ通知します。

正規の更新作業による変更と、攻撃者による変更を区別できるよう、変更管理記録と検知結果を関連付けます。許可されていない変更が見つかった場合は、原因調査と復旧を実施します。

11. 要件12に対応する組織運用

要件12は、技術的な対策を組織として維持するための要件です。方針、責任者、教育、危険度評価、委託先管理、事故対応を整備し、担当者が変わっても運用を続けられる状態にします。

11.1 情報セキュリティ方針

経営者の承認を受けた情報セキュリティ方針を作成し、対象者へ周知します。方針には、目的、適用範囲、責任、禁止事項、例外管理、違反時の対応などを含めます。

方針を作成したまま保管するだけでは機能しません。組織、技術、脅威、契約の変化に合わせて定期的に見直し、変更内容を従業員と委託先へ伝えます。

11.2 役割と責任

各要件について、実施者、承認者、相談先、報告先を明確にします。例えば、修正プログラムの適用は情報システム部、危険度承認は責任者、委託先確認は購買部門というように分担します。

担当者名だけでなく役割として定義すると、人事異動があっても引き継ぎやすくなります。主担当者が不在でも作業を止めないよう、副担当者と代替手順を用意します。

11.3 従業員教育

カード情報を扱う従業員だけでなく、システム管理者、開発者、コールセンター、委託先管理担当者などへ、役割に応じた教育を実施します。一般教育と専門教育を分けることが効果的です。

教育では、フィッシング、認証情報の共有、カード番号の電子メール送信、画面の撮影、不審な端末、事故報告など、実際の業務に近い事例を扱います。受講記録と理解度も確認します。

11.4 委託先管理

カード情報の処理やシステム管理を委託する場合は、委託先の一覧、提供サービス、接続方法、担当要件、準拠状況を管理します。契約には、カード情報の保護責任を認識していることを含めます。

準拠証明書を一度受け取って終わりにせず、少なくとも年に一度は有効期限と対象サービスを確認します。証明書の対象範囲に、自社が利用するサービスが含まれているかも確認します。 事故対応計画

情報漏えい、悪意のあるソフトウェア、管理者アカウントの侵害、不正なスクリプトなどを想定した事故対応計画を作成します。連絡先、判断基準、証拠保全、遮断、復旧、顧客対応などを定めます。

計画は定期的に訓練し、連絡先や手順が実際に機能するかを確認します。訓練後は、判断が遅れた点、必要なログが不足した点などを改善し、計画を更新します。

12. ECサイトのPCI DSS対策

ECサイトでは、利用者のブラウザー上で動作するスクリプトがカード情報を盗み取る電子スキミング攻撃に注意が必要です。PCI DSS v4.xでは、決済ページのスクリプト管理と改ざん検知が重視されています。 決済方式の選択

自社サイトでカード番号を直接受け取る方式は、設計の自由度が高い一方で、対象範囲が広くなる傾向があります。外部決済画面への転送や、決済事業者が管理する入力画面を利用すると、自社が直接扱うカード情報を減らせます。

方式を選ぶ際は、開発費だけでなく、PCI DSS対応、障害対応、委託先管理、利用者体験を含めて判断します。決済方式を途中で変更した場合は、対象範囲と自己問診の種類も見直します。

12.2 決済ページのスクリプト管理

決済ページに読み込まれるスクリプトについて、一覧、提供元、利用目的、責任者、承認状況を管理します。広告、分析、接客、タグ管理など、決済と直接関係しないスクリプトは可能な限り減らします。

外部スクリプトは提供元の侵害によって不正な内容へ差し替えられる可能性があります。必要性を定期的に確認し、利用しなくなったスクリプトを削除します。

12.3 内容安全方針

内容安全方針を設定すると、ブラウザーが読み込めるスクリプト、画像、通信先などを制限できます。許可先を明確にすることで、不正な外部通信や未知のスクリプト実行を抑えられます。

最初から厳格な設定を適用すると、正規機能が停止する場合があります。報告専用の設定で違反内容を確認し、必要な通信先を整理してから段階的に遮断を有効化します。

内容安全方針の設定例

add_header Content-Security-Policy "  default-src 'self';  script-src 'self' https://payments.example-provider.jp;  connect-src 'self' https://api.example-provider.jp;  frame-src https://payments.example-provider.jp;  img-src 'self' data:;  object-src 'none';  base-uri 'self';  frame-ancestors 'self';  form-action 'self' https://payments.example-provider.jp; " always;

安易にすべてのインライン実行を許可すると、制限の効果が弱くなります。無作為値や暗号学的要約値を利用し、必要なコードだけを許可する設計を検討します。

12.4 スクリプトの完全性確認

外部ファイルの内容が想定したものと同じかを確認するため、ブラウザーの完全性確認機能を利用できる場合があります。ファイルが改変されると読み込みを拒否するため、外部配信元が侵害された場合の防御になります。

ただし、提供元が頻繁にファイルを更新するサービスでは、暗号学的要約値の更新運用が必要です。完全性確認だけに依存せず、スクリプト一覧、内容確認、変更検知を組み合わせます。

外部スクリプトの完全性確認例

<script  src="https://payments.example-provider.jp/sdk/v3/payment.js"  integrity="sha384-REPLACE_WITH_VERIFIED_HASH"  crossorigin="anonymous"> </script>

要約値は、信頼できる経路で取得した正規ファイルから生成します。例示された値をそのまま本番環境へ利用してはいけません。

12.5 決済ページの改ざん検知

決済ページの内容、スクリプト、重要な通信ヘッダーが変更された場合に、担当者へ警告する仕組みを設けます。サーバー上のファイルだけでなく、利用者のブラウザーで最終的に表示される状態を確認する方法も検討します。

PCI DSS v4.xの要件6.4.3と11.6.1は、決済ページのスクリプトの承認、完全性、改ざん監視などを通じて、電子スキミングの危険を抑えることを目的としています。CI DSS準拠の確認方法

PCI DSSの確認方法には、自己問診、外部審査報告書、準拠証明書、外部脆弱性検査などがあります。どの方法が必要かは、取引量、決済方式、事業者区分、契約先の基準によって異なります。

13.1 自己問診

自己問診は、自社に適用される要件について、対応状況を自ら確認するための書類です。各質問に対して、対応済み、未対応、対象外などを判断し、必要に応じて改善予定を記載します。

自己問診の種類は、決済方式やシステム構成によって異なります。質問数が少ない種類を選ぶのではなく、記載された利用条件をすべて満たしているかを確認して選択します。

13.2 自己問診A

自己問診Aは、カード情報の処理を適切な外部事業者へ委託し、自社環境でカード情報を電子的に保存、処理、送信しない特定の加盟店を対象とします。ただし、外部委託しているという理由だけで自動的に利用できるわけではありません。

埋め込み型決済画面を利用するECサイトでは、自社ページのスクリプトが決済の安全性へ影響する可能性があります。2025年には、EC加盟店に関する自己問診Aの利用条件について追加の明確化も行われています。 外部審査報告書

大規模な加盟店やサービス提供事業者などには、認定審査機関による評価と外部審査報告書が求められる場合があります。認定審査機関は、PCI SSCによって審査業務を行う資格を認められた独立組織です。けでなく、担当者への聞き取り、設定確認、証跡の確認、現場確認、技術試験などが行われます。審査直前に資料を作るのではなく、日常運用の中で証跡を残す必要があります。

13.4 準拠証明書

準拠証明書は、自己問診または外部審査報告書に記録された評価結果について、公式書式で準拠状況を表明する書類です。加盟店用とサービス提供事業者用など、対象に応じた書式があります。を受け取る際は、会社名と有効日だけを確認するのでは不十分です。対象サービス、対象拠点、評価方法、除外事項、担当要件などを確認します。

13.5 証跡の準備

審査や自己問診では、「対策を実施している」という説明だけでなく、実施を裏付ける証跡が必要です。設定画面、変更記録、教育記録、検査報告、委託先証明書、警告対応記録などを整理します。

証跡には、対象期間、対象システム、実施者、承認者、結果が分かる情報を含めます。画面画像だけでは実施日や対象が不明確になる場合があるため、元の記録と関連付けて保管します。

14. PCI DSS準拠を進める手順

PCI DSS対応では、いきなり12要件を順番に確認するより、カード情報の流れと対象範囲を明確にすることが先です。範囲が曖昧なままでは、不要な対策へ費用をかけたり、重要なシステムを見落としたりします。

14.1 決済経路の可視化

顧客がカード情報を入力してから、承認、売上処理、返金、問い合わせ対応に至るまでの流れを図にします。ウェブ画面、端末、通信、サーバー、外部事業者、保存先を記載します。

通常処理だけでなく、障害時の手作業、管理者による照会、帳票出力、データ移行も確認します。例外的な業務経路にカード番号が残っていることがあります。

14.2 資産一覧の作成

対象範囲に含まれるサーバー、端末、ネットワーク機器、アプリケーション、クラウドサービス、利用者、委託先を一覧化します。所有者、用途、設置場所、製品版、接続先も記録します。

自動検出だけでは、紙媒体や一時的なクラウド環境を把握できない場合があります。技術調査と担当者への聞き取りを組み合わせ、実際の運用を確認します。

14.3 不足点の確認

現状とPCI DSS要件を比較し、未対応または証跡不足の項目を整理します。技術的な不足だけでなく、責任者不在、文書不足、定期作業の未実施なども対象です。

不足点には、危険度、修正難易度、必要期間、担当者を設定します。外部公開されている重大な脆弱性や、禁止データの保存など、影響が大きい問題から優先的に対応します。

14.4 対象範囲の縮小

カード情報を保存しない、決済処理を適切な外部事業者へ移す、ネットワークを分離するなどの方法で、対象範囲を縮小できる可能性があります。対象範囲の縮小は、長期的な運用費用の削減にもつながります。

ただし、見かけ上カード情報を隠しただけでは縮小になりません。復号できる権限、接続経路、管理機能、決済ページへの影響を含めて、対象範囲外と判断できるかを確認します。

14.5 継続運用への移行

不足点を解消した後は、定期作業を年間予定へ組み込みます。脆弱性検査、アクセス権確認、委託先確認、教育、事故対応訓練、対象範囲確認などを忘れない仕組みが必要です。

担当者が個人の予定表だけで管理すると、異動や退職時に作業が止まる可能性があります。管理台帳、作業票、自動通知、責任分担表を利用し、組織として維持します。

15. PCI DSSと他の基準・制度の違い

PCI DSSは、決済カード情報の保護に焦点を当てた基準です。情報セキュリティ管理、個人情報保護、クラウド管理などを対象とする他の制度とは、目的、対象範囲、確認方法が異なります。

15.1 PCI DSSとISMSの違い

PCI DSSは、カード会員データ環境に対する具体的な安全要件を定めています。一方、ISMSは、組織が情報セキュリティ上の危険を管理し、継続的に改善する管理体制を構築することに重点を置きます。

ISMS認証を取得していても、PCI DSSの技術要件や評価手順をすべて満たしているとは限りません。ただし、方針、危険度管理、内部監査、教育など、両方で活用できる仕組みはあります。

15.2 PCI DSSとプライバシーマークの違い

プライバシーマークは、日本国内で個人情報を適切に取り扱う体制を評価する制度です。顧客、従業員、取引先などの個人情報全般が対象となります。

PCI DSSは、決済カード情報とそれを扱う環境へ重点を置きます。個人情報管理体制が整っていても、決済ページの改ざん検知や外部脆弱性検査など、PCI DSS固有の対応が別途必要になる場合があります。

15.3 PCI DSSと個人情報保護法の違い

個人情報保護法は、個人情報の取得、利用、提供、安全管理などを規律する日本の法律です。対象事業者には、法令に基づく義務が発生します。

PCI DSSは業界基準であり、法律とは性質が異なります。両方の対象となる場合は、どちらか一方だけを選ぶのではなく、法令上の義務とカード業界上の義務をそれぞれ満たします。

15.4 PCI DSSとクラウド認証の違い

クラウドサービスに関する認証や保証報告は、サービス事業者の管理体制や安全対策を確認する材料になります。しかし、クラウド事業者が一般的な認証を取得していても、そのサービスがPCI DSS準拠とは限りません。

PCI DSS対応のクラウドサービスを利用する場合も、利用者側の設定、アカウント、保存データ、アプリケーション、ネットワークなどは自社の責任です。責任共有表を確認し、担当範囲を明確にします。

15.5 PCI DSS準拠と安全性の違い

PCI DSS準拠は、一定時点で適用要件を満たしていることを確認した状態です。すべての攻撃を防止できることや、将来にわたって事故が発生しないことを保証するものではありません。

準拠確認後も、新しい脆弱性、認証情報の侵害、設定ミス、委託先事故などが発生する可能性があります。最低限の確認としてPCI DSSを利用しながら、脅威の変化に応じて対策を改善する姿勢が必要です。

おわりに

PCI DSSとは、カード番号を暗号化するだけの技術基準ではありません。ネットワーク、システム設定、データ保存、開発、アクセス権、物理設備、ログ、脆弱性検査、教育、委託先、事故対応までを継続的に管理するための基準です。

決済処理を外部事業者へ委託している企業でも、委託先の準拠状況、契約上の責任分担、自社のウェブサイトや管理アカウントを確認する責任が残ります。特にECサイトでは、外部スクリプトと決済ページの改ざんを前提とした対策が重要です。

対応を始める際は、最初にカード情報の流れと対象範囲を明確にしてください。そのうえで、保存情報の削減、環境の分離、不足点の改善、証跡の整備、継続運用へ順番に進めることで、審査のためだけではない実効性のあるカード情報保護につながります。