PCI DSSとは何ですか、またコンプライアンスはどのようにチェックされますか？

2015年の終わりに、 PayOnline電子決済システムは 、商人と支払人が信頼できる保護下にあることを8回目に証明しました。 また、2016年5月に、同社はPCI DSS標準バージョン3.1の要件に準拠しているという物理的な証明書を受け取り、世界最高レベルのセキュリティを確認しました。



このイベントの背景に照らして、PCI DSSとは何か、基準への準拠を確認する基準、および独自の証明書がなくてもオンラインストアがユーザーの財務データの安全性を確保する方法について詳しく説明したいと思います。







GoogleでPCI DSSの略語を採点したり、Habréで検索したりすると、この標準を説明する記事がかなりあります。 これらすべての資料の対象読者は、電子商取引に何らかの形で関係している人々であることがすぐに明らかになります。 これらは主に支払いアグリゲーターと処理センターであり、オンラインストアの開発者のみです。



どのような種類の電子商取引も、何らかの方法で、製品を購入したい購入者がその製品の代金を支払わなければならないという事実に基づいています。 （会議で宅配便業者にお金を与えるために）古風な方法で支払う能力がロシアで最も人気があるという事実にもかかわらず、買い手が彼の支払いカードを使用することを好む可能性が高いです。 ここで、ストアの開発者は、財務にも関連付けられているユーザーの個人データなどのデリケートな問題に対処する必要があります。 店舗の顧客の誰もがこれを公開したいとは思わないので、ここであなたは思慮深く繰り返しテストされたソリューションに頼らなければなりません。



オンラインストア全体をゼロから作成することは、簡単に言えば、難しい作業です。 したがって、市場には開発者を支援するフレームワークがかなりあります（たとえば、Magentoを聞いたことがある人は誰でも）。 最も重要なものの1つである支払いを受け入れるタスクは、お金に関連しているため、すべてのeコマースソリューションが含まれます。 これに対処した開発者は、これがかなり単純な一連の手順であることを知っています。これは、「XYZ支払いゲートウェイのライブラリコードをダウンロードする」、「構成する」ように見えます（通常は、ゲートウェイが彼は店を扱います）、「少しだけ仕上げます」、「生産にアップロードする」。



原則として、これは重大な問題を引き起こしません。 ただし、ストアのユーザーが選択した支払いゲートウェイの支払いページに移動し、支払いカードの詳細を入力して「支払い」ボタンをクリックした後、プロセスに介入することはできません。感謝（すべてがうまくいった場合）または謝罪（何かがうまくいかなかった場合）。



たとえば、資格のあるユーザーは、httpsがhttpよりも優れていることを知っており、多くのブラウザーがアドレスバーにサイト証明書情報を表示することを確認します。 ただし、支払いゲートウェイが発行銀行（カードを発行した銀行）および取得銀行（支払いを受け取る必要のある銀行）との「内部」トランザクションを開始すると、完全に論理的な疑問が生じる可能性があります。 結局のところ、httpsプロトコルを介したデータの転送はまだセキュリティの保証ではなく、情報の保護を保証する数百のパラメーターの1つにすぎません。



たぶん、このゲートウェイの人たちは自分でhttpsを設定し、証明書を購入し、ウェブサイトにすべてが非常によく、すべてが非常に保護されていることを大文字で書いたかもしれません。 しかし、これを検証する唯一の真に信頼できる方法は、支払いゲートウェイの内部コードのセキュリティを証明するいくつかの手順を実行することです。 そして、もちろん、このようなテストに合格することは、サイトに少し美しいHTMLを書くよりも難しいでしょう-「100％セキュリティ保証」。



このような手順を説明し、それが電子商取引業界の標準である理由を理解しようとします。 これはすべてPCI DSSの略語の下に隠れており、支払いゲートウェイにこの証明書が存在することで、支払いカードのデータ（つまり、支払人のお金）が問題なく宛先に届くことを意味します。

PCI DSSとは何ですか？

PCI DSS（ペイメントカード業界のデータセキュリティ標準）は、ペイメントカード業界のデータセキュリティ標準です。 言い換えれば、これはカード番号、有効期限、CVVコードなどを何らかの形で管理する場合にサービスが満たすべき基準のリストを備えたドキュメントです。



多くのペイメントカードをカウントできます（誰もがVisaとMasterCardを知っています）。これは業界標準であるため、すべての企業が安全と見なすものについて合意することは有益です。 これを行うために、PCI SSC（Payment Card Industry Security Standards Council）があります。これは、5つの最大の決済システムによって形成された、Payment Card Industry Security Standardsの評議会です。 「安全な遊び」のルールを作成するのは彼であり、切望されているPCI-DSS認定ラベルを受け取りたい企業は従わなければならないのは彼のルールです。 毎年認定に合格する必要があります。

何が正確にチェックされていますか？

実際、検証のすべての基準を記述することは困難です-288あります。多くの複雑な技術的問題をチェックする必要があるため、非常に長い手順があります。 12のグループに分けられた基準の完全なリストは次のとおりです。

• コンピューターネットワークの保護。
• 情報インフラストラクチャコンポーネントの構成。
• 保存されたカード会員データの保護。
• カード所有者の送信データの保護。
• 情報インフラストラクチャのウイルス対策保護。
• 情報システムの開発とサポート。
• カード会員データへのアクセスを管理します。
• 認証メカニズム
• 情報インフラストラクチャの物理的保護。
• イベントとアクションのログ。
• 情報インフラストラクチャのセキュリティを監視します。
• 情報セキュリティ管理。

ここでは、ソフトウェア部分と「物理コンポーネント」について話していることがはっきりとわかります。つまり、すべてがチェックされています。 さらに、「検証」という言葉は、検証されている会社のオフィスでこの検証を実行する人の文字通りの存在を意味します。 QSA（認定セキュリティ評価者-この法令はPCI SSCによって確認済み）のステータスを持つ認定監査人は、支払いゲートウェイの従業員と話し合う（このための特別なインタビュー手順があります）、システムコンポーネントの設定を調べ、スクリーンショットを撮り、「仕組み」を確認する権利があります。 PayOnlineは、近年Deiteriyによって監査されています。 彼女の結論は、国際決済システムVisa、MasterCard、MIR、American Express、Discover、JCBで認められています。



ライブラリ自体のプログラムコードは選択的にチェックされ、支払いカードデータを直接処理するコアに最も注意が払われますが、コードの脆弱性を検索して排除するための基本要件を説明する外部セキュリティ標準OWASPへの準拠に注意が払われます。 また、開発ビジネスプロセスにはコードレビューリンクがあり、実際には、コードの作成に関与していない別の開発者による追加検証が行われます。



サービスプロバイダー間、すなわち処理センターとデータセンター間、および買収銀行間のPCI DSS要件のフレームワーク内のすべての関係と責任は、いわゆる負債マトリックスに記録されます。 PCI DSS規格のバージョン3.1以降、サービスプロバイダー間の署名済み責任マトリックスの存在は必須要件になっています。 もちろん、データセンターには、処理センターが業務で使用するインフラストラクチャコンポーネント（仮想化、サービス、物理機器など）の最新のPCI DSSコンプライアンス証明書も必要です。



サーバー自体、および他のすべてのインフラストラクチャコンポーネント（ネットワーク機器など）も、必須の検証の対象となります。 ここでの主な要件は、PCI-DSSのステータスの関連性です。これは、ソフトウェア変更の頻度、ハードウェア構成、仮想マシン、および同様に重要な悪名高いHeartBleedなどの既知の脆弱性に直接依存します。 インフラストラクチャ管理者は、システムの内部/外部の脆弱性を監査し、インフラストラクチャコンポーネントをPCI DSS標準に準拠させる必要があります。



セキュリティ監査は2回実行されます。 初めて、既知の脆弱性の自動スキャナーが使用されます。これは、認証された組織ASV（承認済みスキャンベンダー）によって提供されます。 このテストに合格した場合、システムは、公式の意見で、手動で言うように、専門家によってもう一度安全性がチェックされます。

起こりうる困難

ここで私は個人的な経験から例を挙げたいと思います。 最新のPCI-DSS認証中に、当社の専門家が特別な監視サービスを組織し、データセンターと銀行間の取引が継続的に行われるようにしました。 潜在的な問題の原因は、一部の銀行がTLS 1.0証明書が事後バージョン1.2に更新されたと報告したことです。 古い証明書を所持している銀行と通信しようとしている一方で、すでに更新されている可能性があります。 現在、個別のトランザクション継続性監視サービスが提供されているため、この問題は発生しなくなりました。



一般に、検証の仕組みと、インフラストラクチャを要件に合わせた方法の例をいくつか示すことができます。 ご存じのように、PCI-DSSによれば、支払いシステムは、たとえばCVVまたはPINコード（後者は通常、スーパーマーケットのPOS端末から来ます）を含む、いわゆるクリティカル認証データ（CAD）を保存するべきではありません。 次のように実装されます。



トランザクションが処理センターから特別なステータスを受信すると、完了したことを示します（成功したかどうかに関係なく）、2つの問題を解決する特別なプログラムコードがシステムで開始されます。 何らかの理由でトランザクション中にデータがディスクに書き込まれた場合、このレコードを削除する特別な操作が最高の優先度を取得し、特別なワーカーによって実行されます。 ディスクへのアクセスがなかった場合は、さらに簡単です。トランザクションプロセスはサーバーのメモリから削除されるため、CADの固定は行われません。 保存できるデータは、PAN（プライマリアカウント番号）カード番号のみであり、排他的に暗号化されます。



別の例は、オンラインストアで商品を購入したユーザーの1人に直接関係しています（実際、そのようなストーリーは多数ありますが、これはまさに最新のものです）。 何か「間違った」後、彼は十分に詳細なエラーメッセージを読みませんでしたが、単に両側で支払いカードの写真を撮りました（おそらく、最後の3桁を入力する必要があることを支払いの形で説明したためです）背面の磁気ストリップの後）、サポートチームに送信します。 バイヤーによると、これは彼の支払いのステータスを調べるのに役立つはずだった-「お金が引き出された」かどうか。 PCI-DSS規格では、このような好奇心が強いと同時に悲しいケースも規定されていると言わざるを得ません。



ユーザーのデータが侵害された場合、支払いシステムはユーザーと「照らされた」カードを発行した発行銀行に通知する義務があります。 さらに、メールサーバーだけでなく、サポートサービスオペレーターのクライアントメールプログラムから添付ファイル付きの文字を削除する必要がありました。 これはすべて、支払いカード業界のセキュリティを確保するという黄金のルールに従うために行われました。「この情報が必要ない場合は、保存しないでください。」

PayOnlineオンラインストアの統合

前述のように、特定のオンラインストアを支払いシステムに統合するタスクは、難しいとは言えません。 インターネットでは、多くのゲートウェイの多くの例を見つけることができます。 通常、サーバーに特別に作成されたライブラリをインストールし（さまざまなプラットフォーム用に多数あります）、ユーザーフォーム情報を収集して支払いゲートウェイに送信するクライアントコードの種類を記述します。 私が注意したい唯一のポイントは、支払いフォーム自体の場所であるべきです-それはオンラインストアの側にあるのでしょうか、それはPayOnlineの側で動作するのでしょうか。 多くの決定があなたのウェブサイトで直接支払いを受け入れることを可能にするかもしれないという事実にもかかわらず、商人が彼自身のPCI-DSS証明書を持っていない場合、支払いが支払いゲートウェイの側で行われるようにすべてを手配する必要があります。 正当化の理由は1つだけです。これは、ユーザーの財務データのセキュリティです。 この場合、支払いフォームは会社に合わせてカスタマイズできるため、エンドユーザーの拒否は発生しません。



Windows Phoneを含むデスクトップおよびモバイルソリューションの支払いを整理するためのライブラリがあります（ただし、ユーザー間の人気の点でこのプラットフォームの位置はAndroidまたはiOSの位置よりもはるかに弱いです）。 PHPのライブラリについても説明しません。これは実際には暗黙のうちに暗示されています。 .NETソリューション用のSDKもあります。 人々はしばしば、Androidに従来のアプローチ（Javaライブラリ）が選択されなかったのに、Node.jsが使用された理由を尋ねます。 この決定は少し前に行われました。このようなコードの統合は、Javaで書かれたものよりもわずかに簡単であり、PCI PA-DSS規格の要件も満たしています。 将来の統合については、WebViewを介してアプリケーションに統合され、すべてのPCI PA-DSS要件を満たすネイティブモバイルアプリケーションで最適に機能する適応支払いフォームが用意されています。

オンラインストアを取得するもの

PayOnline電子決済システムの主な利点の中で、成功した支払いへの変換を増やすことを目的とした当社の技術的能力を特に強調することができます。 まず第一に、これは3-D Secureを使用したデリケートな作業であり、不正取引に対する高いレベルの保護を維持すると同時に支払いの変換を増やすことができます。



技術の進歩に伴い年々変化する支払者の行動を注意深く研究しています。 データの入力と支払いの際に、支払いページでの人のコンバージョンと行動を測定できるため、技術的には、お客様が段階的にお客様の進路を追跡し、代わりに自己紹介し、統計に基づいて可能な限りユーザーエクスペリエンスを簡素化できます。 ただし、支払いを行うときに、何らかの理由で買い手が支払いを行えない場合、ストアは処理センターから拒否の正確な理由を受け取り、カスタマイズされた形式で拒否の理由を支払い者にブロードキャストします。 したがって、クライアントは、支払いが失敗した理由と、製品またはサービスを購入するために何をする必要があるかをすぐに理解します。



この機会に興味がある場合は、に連絡してください 。弊社のスペシャリストが追加情報を提供し、必要に応じて、PCI DSS 3.1標準の要件を満たすセキュアゲートウェイ上のWebサイトおよびモバイルアプリケーションで支払いの受諾を設定します。