---

WEEDS Trace 証跡管理ソリューションについて詳しく紹介した資料です。

---

1. PCI DSS（Payment Card Industry Data Security Standard）とは

PCI DSS（Payment Card Industry Data Security Standard）は、クレジットカードの会員データの保護を目的とした、セキュリティを推進および強化するための国際的なデータセキュリティ評価基準です。
2004年12月に国際カードブランド5社（American Express、Discover、JCB、MasterCard、VISA）によって策定され、2022年4月に現行のv4.0にバージョンアップされています。

1.1. PCI DSSの準拠メリット

• 具体的な要求事項が記載されており、カード情報の漏えいリスクを低減できる。
• 世界基準の情報保護対策に準拠していることが確認でき、対外的に表明することで企業価値の向上につなげられる。
• 万が一、カード情報が漏えいし不正利用された場合でも、国際カードブランドからの賠償が免除される可能性がある。

1.2. 日本におけるPCI DSS

クレジットカードのショッピング機能のうち、2ヵ月を超える2回払いや、分割払い・リボルビング払い・ボーナス一括払いが割賦販売法という法律の規制対象となります。
割賦販売法に規定するセキュリティ対策義務の「実務上の指針」として「クレジットカード・セキュリティガイドライン」が位置づけられており、「クレジットカード・セキュリティガイドライン」において「PCI DSS」の準拠もしくはカード情報の非保持化が求められています。つまりクレジットカードを扱う事業者は、「PCI DSS」に準拠するか、カード情報の非保持化の対応をしなければなりません。

「クレジットカード・セキュリティガイドライン」についてはこちらのコラムをご覧ください。
コラム – ECサイトのセキュリティ対策【クレジットカード不正利用対策】

1.3. PCI DSS v4.0の改定ポイント

2022年4月にPCI DSS v4.0 がリリースされました。前回のメジャーバージョンアップから8年（v3.2.1 からは約4年）ぶりのバージョンアップになりました。近年増加しているオンラインスキミングやフィッシングなどの新しい攻撃手法への対応が盛り込まれた改定となりました。
システムの構築・運用するうえで重要であると考えられる改訂ポイントをいくつかピックアップして説明します。

• 公開されているWebアプリケーションを保護するための要件が追加
• ユーザーやシステムのアカウント権限のレビューを実施
• カード会員データ環境へのすべてのアクセスは多要素認証を実装

Point1 公開されているWebアプリケーションを保護するための要件が追加

ECサイトでの取引量の増加とともに、ECサイトを狙ったサイバーインシデントの発生件数も年々増加しています。今回の改定では、近年のインシデントの発生状況を踏まえ、一般公開されているWebアプリケーションへの不正アクセスやオンラインスキミングを防止するための要件が追加されました。

要件	対策
公開しているWebアプリケーションへの攻撃対策	WAFの導入
決済ページからのカード会員データのスキミング防止対策	決済ページのスクリプト改ざん防止

Point2 ユーザーやシステムのアカウント権限のレビューを実施

過剰なアクセス権は悪意あるユーザーに不正に利用されたりと、システムリスクとなります。このようなリスクに対応するため、すべてのユーザーアカウントやアプリケーション、システムアカウントの権限が適切であるかレビューする要件が追加されました

対象	確認観点
ユーザーアカウント	職務権限に基づいて適切なアクセス権が設定されているか 不要なアカウントが削除されているか
アプリケーション、システムアカウント	アプリケーションまたはシステムの操作性に必要な最低限の権限になっているか アクセスは必要とされるシステム、アプリケーション、またはプロセスに限定されているか

Point3 カード会員データ環境へのすべてのアクセスは他要素認証を実装

カード会員データ環境へのすべての非コンソール管理アクセス、ならびにすべてのリモートアクセスは多要素認証を使用して安全に保護する必要があったが、今回の改定において、カード会員データ環境へのすべてのアクセスに多要素認証を使用することが求められています。
つまり事業体のネットワーク内からのアクセスにおいても、多要素認証を使用する必要があります。

多要素認証が必要なアクセス（改定前）	多要素認証が必要なアクセス（改定後）
非コンソール管理アクセス ネットワーク外からのリモートアクセス	・社内ネットワークを含めたすべてのアクセス

1.4. PCI DSS v4.0への対応スケジュール

追加された要件は直ちに適用されるものと2025年4月以降に適用される（それまではベストプラクティスとされる）ものがあります。前バージョンのv3.2.1からの移行期間は2024年4月までとなり、それまでに直ちに適用される要件に対応しなければなりません。
ベストプラクティスに位置づけられた要件は、2024年4月までは移行するために必須の要件ではありません。ただ、対応のためにシステム等の改修が考えられますので、早めに対応することをおすすめします。

2. PCI DSSで求められる要件

PCI DSSでは6つの目標とそれに対応する12の要件が定められています。

目標	要件
安全なネットワークとシステムの構築と維持	要件1. ネットワークセキュリティコントロールの導入と維持
	要件2. すべてのシステムコンポーネントにセキュアな設定を適用する
アカウントデータの保護	要件3. 保存されたアカウントデータの保護
	要件4. オープンな公共ネットワークでの送信時に、強力な暗号化技術でカード会員データを保護する
脆弱性管理プログラムの維持	要件5. 悪意のあるソフトウェアからすべてのシステムおよびネットワークを保護する
	要件6. 安全なシステムおよびソフトウェアの開発と維持
強固なアクセス制御の実施	要件7. システムコンポーネントおよびカード会員データへのアクセスを、業務上必要な適用範囲（Need to Know）によって制限する
	要件8. ユーザーの識別とシステムコンポーネントへのアクセスの認証
	要件9. カード会員データへの物理アクセスを制限する
ネットワークの定期的な監視とテスト	要件10. システムコンポーネントおよびカード会員データへのすべてのアクセスをログに記録し、監視すること
	要件11. システムおよびネットワークのセキュリティを定期的にテストする
情報セキュリティポリシーの維持	要件12. 組織の方針とプログラムによって情報セキュリティをサポートする

2.1. 準拠対象

PCI DSSの要件は、カード会員データや機密認証データ（アカウントデータ）を保存、処理、または伝送する環境を持つ事業体に加え、アカウントデータを保存、処理、または伝送しない事業者であっても、カード会員データ環境（CDE）のセキュリティに影響を与える可能性のある環境を持つ事業体にも適応されます。例えば、カード会員データ環境（CDE） の支払業務または管理を外部に委託している事業体にも一部適用される場合があります。
また、カード会員データと機密認証データは以下のように定義されています。

カード会員データ	認証機密データ
プライマリアカウント番号（PAN） カード会員名 有効期限 サービスコード	フルトラックデータ カード検証コード PIN／PIN ブロック

2.2. 6つの目的と12の要件

12の要件における具体的な要求事項について、ピックアップして説明します。

要件1. ネットワークセキュリティコントロールの導入と維持

ネットワークセキュリティコントロールは、あらゆるコンピュータ・ネットワークに重要な保護メカニズムを提供することを目的としています。具体的には、セキュリティポリシーの運用、ネットワーク図やアカウントデータのデータフロー図の作成、運用などが求められています。また、カード会員データ環境へのネットワークアクセスの制限や信頼できないネットワークとの接続の制御も求められています。

要件2. すべてのシステムコンポーネントにセキュアな設定を適用する

潜在的な攻撃対象領域を減らすため、デフォルトパスワードの変更、不要なソフトウェア、機能、アカウントの削除、不要なサービスの無効化または削除が求められています。

要件3. 保存されたアカウントデータの保護

アカウントデータを保護するため、データの保存は最小限に留め、保存する場合は暗号化等のデータ保護対策が求められています。

要件4. オープンな公共ネットワークでの送信時に、強力な暗号化技術でカード会員データを保護する

アカウントデータの漏えいから保護するために、オープンな公共ネットワークを介した伝送中は強力な暗号化技術を使用してアカウントデータを保護することが求められています。

要件5. 悪意のあるソフトウェアからすべてのシステムおよびネットワークを保護する

マルウェア対策ソリューションやフィッシング攻撃を検知、防止する仕組みの導入が求められています。

要件6. 安全なシステムおよびソフトウェアの開発と維持

セキュリティの脆弱性を利用した不正アクセスからアカウントデータを保護するため、すべてのセキュリティコンポーネントには適切なソフトウェアパッチの適用が求められています。また、特注ソフトウェアおよびカスタムソフトウェアについては、ソフトウェアライフサイクル（SLC）プロセスや安全なコーディング技術を適用することが求められています。

要件7.システムコンポーネントおよびカード会員データへのアクセスを、業務上必要な適用範囲（Need to Know）によって制限する

許可されたユーザーのみがアカウントデータや重要なシステムへアクセスできるようにするため、アクセスを制御するシステムとプロセスを導入することが求められています。

要件8.ユーザーの識別とシステムコンポーネントへのアクセスの認証

システムやアカウントデータへアクセスし実施されたアクションは個人まで追跡できるようにすることが求められています。また、アカウントデータへのアクセスは多要素認証が実装されていることが求められています。

要件9.カード会員データへの物理アクセスを制限する

権限のない者がアカウントデータやアカウントデータを保存、伝送、処理するシステムへのアクセスを防ぐため、入館管理などによって物理的なアクセスは適切に制限されることが求められています。

要件10.システムコンポーネントおよびカード会員データへのすべてのアクセスをログに記録し、監視すること

データの漏えいの防止や検知、またはその被害を最小減にするため、ログ取得の仕組みを導入し、すべてのシステムやアカウントデータへのアクセスをすべて追跡、監視することが求められています。ただログを取得するだけでなく、毎日のログレビューが必要となります。また、膨大な量のログデータを手動でレビューすることは困難であるため、自動化されたメカニズムを使用することが求められています。

要件11.システムおよびネットワークのセキュリティを定期的にテストする

脆弱性の悪用を防ぐため、脆弱性を迅速に特定し、対処することが求められています。具体的には内部脆弱性スキャンや認定ベンダによる外部脆弱性スキャン、侵入テストなどの定期的な実施が求められています。
また、スキミング被害を防止するため、決済ページの変更や改ざん検知のメカニズムを使用することも求められています。

要件12.組織の方針とプログラムによって情報セキュリティをサポートする

PCI DSSの適用範囲の定期的な確認、担当者への情報セキュリティポリシーの周知やセキュリティ意識教育が求められています。また、内部脅威によるリスク低減のため、カード会員データ環境にアクセスする可能性のある担当者において、雇用前のスクリーニングを実施することを求められています。

3. PCI DSS準拠対応における課題

WEEDS SYSTEMSは創業当初からアクセスログ一筋の専門企業です。そんな弊社にお客様からよくご相談いただくPCI DSS対応における課題をご紹介いたします。これからPCI DSSの準拠をお考えの方は参考にしてください。

1. アクセス権の管理負担 – 要件7, 8
2. データベース（カード会員データ環境）の監査ログ取得によるパフォーマンスへの影響 – 要件10
3. Windows/Linuxサーバーのログ取得における課題 – 要件10

3.1. アクセス権の管理負担

アクセス権の管理でも特権IDの管理について多くのご相談をいただきます。特権IDを管理する上でよく課題となるのが以下の3点になります。

上記の対応を実施する一例として、サーバーごとにユーザーを管理し、都度アクセス権を付与する運用が考えられます。また、利用時には申請/承認を実施し、文書として管理する必要があります。
このような運用をしていると、管理の煩雑化や管理担当者の負担が課題となります。
これらの課題を解決するために「特権ID管理ソリューション」の導入をオススメします。
WEEDS Trace含め、他社様からも様々なツールが提供されております。予算や規模、監査ログ取得機能などと合わせてツールの検討をオススメします。

3.2. データベース（カード会員データ環境）の監査ログ取得によるパフォーマンスへの影響

データベースの監査ログは、設定や拡張機能によって取得可能ですが、大量の監査ログが出力され分析が困難になったり、ログ出力によるパフォーマンスへの影響が課題といえます。

WEEDS Traceでは、データベースから出力される監査ログと独自技術を組み合わせることで、パフォーマンス影響を極小化しつつ網羅的なアクセスログの取得が可能となります。
製品機能について詳しくはこちらをご覧ください。

機能紹介 – DBサーバーアクセスログ取得「DBT」

3.3. Windows/Linuxサーバーのログ取得における課題

また、データベース以外のシステムにおいても、OS標準ログで対応する場合、監査ログの改ざんや取得できない操作への対応が課題となります。特にお客様からのご相談で多いのが「必要な項目がログとして出力できない」というお声です。
WEEDS Traceは監査対象にインストールするエージェント型を採用しており、抜け漏れのない操作ログの取得が最大の特徴です。
エージェント型は対象のサーバーにそれぞれインストールする必要があり、導入に負担がかかるのではないかというご心配をなさるお客様も多くいらっしゃいますが、ご安心ください。弊社のエンジニアが責任をもって製品の導入をさせていただきます。
OS標準ログについて詳しく知りたい方はこちらのコラムをご覧ください。

・コラム – Unix/Linuxサーバーで標準出力されるログは監査証跡になるか？

・コラム – Windowsサーバーで標準出力されるイベントログは監査証跡になるか？