PCI DSSは、"Payment Card Industry Data Security Standard"の頭文字語となっており、単一のセキュリティ基準だけではなく、用語集や手順書、ASVやQSAなどの認定審査機関の認定の仕組みなど、様々な文書や制度を含めて、基準を取り巻く体系全体を指しています。
全ての文書は、PCI SSCのサイトからダウンロードすることができます。

• PCI SSCのサイト（英文）
• PCI SSC DOCUMENT LIBRARY

ここでは、PCI DSSの核であるセキュリティ基準の内容について解説します。

*当社ではPCI DSSトレーニング研修も取り扱っています。
PCI DSS基本コース

序文には、PCI DSSを適用する対象範囲の決定方法と、保護対象となるカード会員データの各要素に対する扱い方の基本的な方針が記載されています。ここでは、重要な点が3点挙げられますので、引用、解説します。

1. 適用範囲(スコープ)

   PCI DSSは、PAN(カード会員番号)を扱っている部分に適用されます。 「扱う」というのは、伝送、処理、保管のどれかを行っていることを指し、その業務でPANを扱っていない場合は、PCI DSSの適用義務はありません。

2. カード会員データとセンシティブ認証データの定義

   データ要素として、カード会員データとセンシティブ認証データの2種類に大別され、カード会員データを適切に保護すること、およびセンシティブ認証データはさらに厳密な対策を施す必要があること、が記載されています。

   カード会員データは、伝送、処理、保管する場合は暗号化など適切な対策を施す必要があり、センシティブ認証データは、オーソリゼーション（※）後に適切に破棄する必要があります。つまり、センシティブ認証データは、オーソリゼーション後に保持することが認められません。

   ※ オーソリゼーションとは、そのカード情報で決済しても良いかを、発行元カード会社が判断する処理のことで、カード決済しようとしている加盟店から、様々なネットワークを経由して発行元カード会社まで届き、決済の可否結果が加盟店に返るまでのプロセスを指します

   

3. スコープの縮小

   これは、1. の補足事項といえます。カード会員データ環境、つまりカード会員データを扱う環境と、それに接続された環境がPCI DSSの対象であり、サーバやネットワーク機器、無線機器などを含むことになりますが、適切にセグメンテーション、アクセス制御を行うことにより、対象範囲を縮小することもできます。

   これらの基本的な考え方を元に、それぞれの要素に対してどのような対策を行わなければならないのかが、要件1～12で示されています。

PCI DSS INDEXへ

本カテゴリーの2つの要件では、ファイアウォールとルータの安全な設定方法と運用方法、サーバやネットワーク機器においてデフォルト設定値を使用しないことを含む、セキュリティ強化基準の策定が求められています。

ファイアウォールとルータでは、外部ネットワークとDMZ、内部ネットワークの適切なセグメンテーション、業務上必要な通信に限定するためのアクセスリストの定義、安全なプロトコルの使用、設定内容の定期的なレビュー、また、これらを含む設定基準の文書化と運用が求められています。

要件2では主に、サーバやネットワーク機器において各種サーバやネットワーク機器の種別毎にセキュリティを強化するため、 NISTや SANS、 CISなどで定義されているものと同等の基準を策定、運用することが求められています。具体的には、

• 無線ベンダのデフォルトSSIDを使用しないこと
• Webサーバなどを構築する際、デフォルトでインストールされてしまう不必要な設定やコンテンツを削除すること
• サーバにデフォルトでインストールされるサービス、プロトコルを削除もしくは無効化すること

などが定められています。

PCI DSS INDEXへ

要件3では、「序文」で示された通り、センシティブ認証データをオーソリゼーション後に保持しないこと、カード会員データは必要最低限の量、必要最低限の期間のみ保管し、かつ安全に保管することが求められています。

安全に保管する方法として、一方向ハッシュ、トランケーション、インデックストークン、暗号化の4つの手法が挙げられています。つまり、必ずしも暗号化ではなく、一方向ハッシュなどの方法で判読不可能な状態にすることも含め、最善策の実施が求められています。業務上、カード会員番号の全桁を完全に復元する必要がないのであれば、トランケーションで必要な部分のみ保管することも選択肢として考えられます。もしくは、顧客サポートなどで一時的に手元のカード番号と電話口のカード番号を照合させるような場合は、一方向ハッシュを利用することも選択肢として考えられる場合もあるかもしれません。

また、ここで注意すべきことは、対策に暗号化を選択する場合のみ、追加の対策として鍵管理プロセスが求められることです。鍵が安全に管理されない暗号化は、全く意味を為さないものであり、極論をいえば暗号化していないのと同じ状態であると考えられるためです。例えば、暗号化していても、その暗号鍵が暗号化されたデータと同じ場所に保管されていては意味がありませんし、暗号鍵が容易に予測可能なものであっても効果は低いでしょう。また、1人の管理者が鍵全体を知っているような場合、その管理者1名のモラルに依存することになり、その鍵と暗号化されたデータの安全性は著しく低下することを理解する必要があります。

そこで、要件3.6では、暗号鍵の生成方法、配布、保管方法が安全であること、鍵を定期的に変更すること、分割管理、鍵の漏洩、盗難、紛失の際の交換方法を定めること、などが求められています。

要件4では、カード会員データの伝送路上の安全の確保が求められています。要件の項目としては少なく、小項目で数えても3項目しかありません。

カード会員データを公衆ネットワーク上で送受信しなければいけない場合、暗号化することが求められています。公衆ネットワークとしては、インターネットや無線ネットワーク、 GSM、 GPRSが挙げられていますが、日本においては GSMよりも一般的な 3Gや HSDPAネットワークも当てはまると考えられます。逆に、専用線や相手先を限定、もしくはコールバック機能を適用したダイヤルアップ通信などは、公衆ネットワークとは考えません。暗号化の手法としては、HTTPの場合はSSL/TLS、IPレイヤーで行う必要があればIPSECなどが必要です。無線ネットワークの場合は、 WEPのみに頼ることなく、 WPA、 WPA2、およびVPNやSSL/TLSとの併用、 WEPの共有鍵の定期的な変更や、MACアドレスによる制御なども求められます。

暗号化されていないカード会員データの電子メールによる送受信の禁止も、この要件の中で求められています。

PCI DSS INDEXへ

要件5はアンチウィルスソフトウェアの使用とその運用方法について、要件6では開発、保守フェーズにおける対策とパッチ適用についての要件となっています。アンチウィルスソフトウェアに関しては、多くの記述はありませんが、ウィルスの影響を受けやすいシステムへのアンチウィルスソフトウェアの導入、スパイウェア、アドウェアなどに対する検知、除去、防護が必要、とされていて、現在普及しているアンチウィルスソフトウェアを選択すれば、間違いはないでしょう。

アンチウィルスソフトウェアを導入しなければならない対象は、「ウィルスの影響を受けやすいシステム」とありますが、これは主にWindows系サーバおよびクライアントを指しており、UNIX系サーバやメインフレームなどは除外して問題ありません。もちろん、場合によってはLinuxサーバにアンチウィルスソフトウェアを導入することが無意味であるというわけではありませんが、最低限必要なのはWindows系サーバおよびクライアントであるといえます。

また、アンチウィルスソフトウェアは導入するだけでなく、パターンファイルやエンジンの最新化、定期的なスキャンおよびリアルタイムスキャンも必要です。定期的なスキャンの頻度としては、特に制限がなければ1日に1回行うのが最適でしょう。

要件6では、まず、OSやアプリケーションのパッチを迅速に適用するプロセスが求められています。もちろん、迅速に適用するには、最新の脆弱性情報を取り入れ、システムに与える影響範囲を特定することも必要ですし、適用するための変更管理プロセスも必要となります。これらは、文書化し、パッチのリリース後1ヶ月以内に適用することが求められています。

また、開発環境とテスト環境、本番環境を分離し、アカウントやデータをそれぞれの環境で互いに使い回さないこと、本番環境へリリースを行う場合はその変更による影響範囲や管理者による承認、テスト内容や結果、回復手順を盛り込んだ変更管理の手順の整備とその記録が求められています。とくに、外部からの不正アクセスによる被害を最も受けやすいWebシステムについては、コーディング段階から排除する必要のある脆弱性について、詳細に記載されています。

ここではOWASP(Open Web Application Security Project)の脆弱性トップ10が記載されており、OWASPトップ10とPCI DSSのリリース時期のタイミングのずれにより、現在(2008年7月) PCI DSSバージョン1.1で参照されているOWASPトップ10と、OWASPが公開している最新のトップ10に違いが見られますが、PCI DSSバージョン1.1の内容を参照するよりも、OWASPのWebサイトで公開されているトップ10を参照するべきです。

また、Webアプリケーションについてはコーディング段階から考慮すべきこれらの脆弱性への対応だけでなく、Webアプリケーションファイアウォールの導入、もしくはソースコードレビューが求められています。これについては、次回、解説します。

PCI DSS INDEXへ

本カテゴリーの3つの要件で求められているのは、アクセス制御です。 要件7と8では、アカウントおよびパスワードの適切な設定と管理が求められています。

まず、必要最低限のアクセス許可を施すことが大前提として求められており、加えて、アカウントは共有せず、必ず一人のユーザと一つのアカウントが結びつくよう、個別のアカウントを割り当てること、ユーザの認証には、個別アカウントの割り当ての他にパスワードやトークン、生体認証などを実施することも求められています。 さらに、リモートアクセスを行う場合には、2要素認証が求められます。2要素認証では、 RADIUSや TACACS(+)、証明書の利用などの組み合わせが必要です。

アカウント管理を行う上で、アカウントの追加や変更、削除を適切に行う手順の文書化と運用、パスワードの変更や複雑なパスワードの使用、連続したアクセス試行時のロックアウトなど、細かい要求事項があります。これらは、WindowsやUNIXの場合、システムで強制することが求められると考えて下さい。メインフレームなどの場合は、実装が難しい場合が多いと考えられますので、システムで強制することと同等の対策を行う必要があります。

要件9もアクセス制御の要件ですが、要件7、8と違い、物理的なアクセス制御に関する要件です。具体的には、ビルへの入退館、マシンルームへの入退室、および監視カメラの設置や従業員カードの着用、紙や電子媒体などの情報種別管理、細かい部分では紙媒体廃棄時のクロスカットでの裁断などが求められています。とくに監視カメラや各種入退の記録は、3ヶ月以上の保管が必要です。

入退室の記録は3ヶ月以上、半永久的に保管されていることが多いものの、監視カメラの記録はデータ量が膨大になる可能性が高く、通常1ヶ月程度しか保管されない場合が多いため、データセンタなどに運用を任せている場合は確認が必要となるでしょう。

PCI DSS INDEXへ

本カテゴリーでは、要件10のログ管理と、要件11の定期的なテストが盛り込まれています。

要件10では、カード会員データへのアクセスの追跡と監視、および不正アクセスの早期発見と追跡可能性を満たすためのログ管理に関連する要件が挙げられています。本要件では、取得するアクセスログの種類と取得したログの保護、および取得したログの監視が求められていますが、カード会員データに関連する部分で、誰が、いつ、何をしたのか、を確実に取得し、保護、監視することが求められていると考えて下さい。特に、アクセス制御と関連する部分ではありますが、特権ユーザ(rootやAdministrator)による操作ログは重要であり、より詳細に、確実に取得し、頻繁に内容を確認する必要があります。

また、システム全体のログの整合性を保つため、時刻同期を行うことも求められます。取得したログを保護することも忘れてはいけません。これは、一度でも侵入を許してしまったシステムに存在するログは、信頼性を失ってしまっていることを、念頭に置く必要があります。このため、収集したログは改変を許さないためにテープや光ディスクなど、オフラインで保管する必要があることを意味しますが、事件や事故の発生時、もしくはその可能性がある時、迅速にログを追跡するために、オンライン(稼働しているシステム上)でもある程度保管しておく必要もあります。本要件では、オンラインでは3ヶ月、オフラインでは1年分のログを保管することが求められています。

要件11では、日々発見される新しい攻撃手法や、ソフトウェア、システムの変更に伴って発生しうる新たなリスクを識別、検知し、修正するための定期的なテストの要件が記載されています。具体的には、四半期に一回の内部および外部からの脆弱性スキャン、およびネットワークレイヤおよびアプリケーションレイヤに対するペネトレーションテストが求められています。また、IDSもしくはIPSの導入とトラフィックの検知および警告、サーバやネットワーク機器の設定やコンテンツなど、重要なファイルの完全性監視が求められています。本要件については、質問をいただくことも多いため、次回以降でさらに詳しく解説する予定です。

PCI DSS INDEXへ

最後のカテゴリーには情報セキュリティポリシー関連の要件が記載されています。本要件は、システム上の設定や具体的な手順よりも、情報セキュリティポリシーの管理が適切に行われていることが主な要求事項となっています。

本要件は、正式なリスク評価手順に基づいて情報セキュリティポリシーが運用されていること、教育が行われていること、インシデント発生時の手順を文書化し、毎年テストすること、外部委託先がある場合、委託先でのカード会員データの扱い方を把握、管理することなどが求められていますが、ISMSを取得している企業の場合、多くの要件はカバーできていると考えることができます。逆に、ここで求められる多くの要件は、実際の設定が行われているか、実質、そのように運用されているかではなく、ポリシーが存在し、そのポリシーのもと業務が運用されているかを問うものであるため、文書化され、適切に見直しが行われていることを確認していただく必要があるでしょう。

PCI DSS INDEXへ

付録Aとして、ホスティング・プロバイダに対する要求事項が挙げられていますが、ここで指すホスティング・プロバイダとは、複数の加盟店を同一のシステムでホスティングしているような、いわゆる「共有ホスティング・プロバイダ」が対象となります。共有ホスティング・プロバイダは、ホスティングを請け負うそれぞれの事業体に対するデータ、アクセス、ログを確実に分離し、侵害があった場合は迅速に調査を行うことができるようなシステム、体制を整えることが必要となります。

PCI DSS INDEXへ

付録Bで説明されているのが、代替コントロールです。前回述べた通り、PCI DSSには具体的で明確な対策項目が記載されている反面、柔軟性に欠ける部分があります。この欠点を補っているのが、代替コントロールの考え方であるといえます。

ある要件を、業務上の理由でどうしても実現できない場合、その要件と同等以上の対策を講じる事で、代替コントロールとして対応済みと判断することができます。ただし、むやみに代替コントロールを採ることができるわけでなく、技術上、もしくは業務上の制約でやむを得ず本来の要件が満たせない時に限ります。

また、代替コントロールは、代替であり、妥協策ではないため、同等以上の効果が認められる対策でない限り代替コントロールと認められることはありません。よって、代替コントロールを選択しようとしても、同等以上の効果が求められる故に、本来の要件よりもコストがかかる、もしくは複雑化してしまう、といったことも考えられます。

まずは本来の要件を満たすことを検討されるのが、最善となることが多いでしょう。例として挙げられているのはデータベースに保管されたデータの判読不能化で、これが実現できない場合に、代替コントロールとして、セグメンテーション、ネットワークアクセス制御、データベースへのアクセス制御、データベースへの攻撃の防止と検知、これら全ての対策を施すことで代替コントロールとしています。また、ここではデータベースに保管されたデータの保護についての代替コントロールが挙げられていますが、他の全ての要件について、必要に応じて代替コントロールを採ることができます。

PCI DSS INDEXへ