EC-CUBEを導入するかどうかを検討する際に、かならずテーマになるのはセキュリティです。中でも、クレジットカード情報の漏洩が発生すると被害甚大なので最重要です。事件が発生すると、何カ月もの期間、ECサイトの営業停止を余儀なくされますし、被害者への補償も必要になり、金額的な被害も大きいです。ズバリ言って、EC-CUBEで大丈夫なのでしょうか？！

クレジットカード情報の扱いが安全かどうかを判断する際に、一番注目すべきポイントはEC-CUBE本体よりも決済プラグインです。

2018年6月1日から施行された改正割賦販売法により、クレジットカード決済を導入しているECサイトは「カード情報の非保持化」が求められるようになりました。（改正割賦販売法については経済産業省のこちらの資料をご覧ください。）

それ以前でも、EC-CUBE本体にはそもそもクレジットカードの決済機能はないので、購入者が入力したクレジットカード番号をデータベースに保存するような仕組はありませんでした。クレジットカード決済機能は決済代行会社の決済モジュールやプラグインにより追加される機能でしたが、ほとんどの決済モジュールや決済プラグインもクレジットカード番号をデータベースに保存するような動作にはしていませんでした。そのような動作であれば、サーバに侵入されても過去の取引に使われたクレジットカード情報まで窃取されることはありません。

ですが、カスタマイズによってカード番号をデータベースに保存したり、ログに落としたりしているサイトもあったようです。実際にそのようなカスタマイズをベンダーに依頼し、クレジットカード情報漏洩が発生したECサイトについて裁判になった事例がありました。脆弱性を放置していたため侵入されたのですが、カード番号を保持するように変更したので、それまでに購入した顧客クレジットカード情報7,316件が流出しました。

そのような事件が増えたこともあり、「カード情報非保持化」が求められるようになりました。それで非保持化が義務化される2018年に向けて決済代行会社各社は決済モジュールのカード情報非保持化に対応しました。

現在では、4系のEC-CUBEと4系に対応した公式サイトで配布される決済プラグインで、EC-CUBEを稼働させるサーバにカード情報を保持するものはありません。この状態が保持されているかぎりは、EC-CUBEでカード情報の漏洩は絶対に発生しません。

ちなみに「カード情報非保持化」したプラグインには２つのパターンがあります。「トークン決済方式」と「リンク決済方式」です。
「トークン決済方式」では、クレジットカード情報をECサイトのサーバに送信するのではなく、JavaScriptによって決済代行会社のサーバに対して送信し、決済代行会社サーバが発行した「トークン」をECサイトに送り、ECサイトと決済代行会社はクレジットカード情報の代わりに「トークン」を利用して取引を進めます。「リンク決済方式」はもっと分かりやすく、決済時には決済代行会社の画面に遷移してそこでクレジットカード情報を入力します。いずれの方式でも、ECサイト側のサーバには一度もクレジットカード情報が送信されることもありませんので、データベースにもログファイルにも保存されないのは当然ながら、メモリ上にすらクレジットカード情報がコピーされることはありません。

EC-CUBEのサイトを運営されていて心配な方は、まず決済モジュールが「カード情報非保持化」に対応しているか確認しましょう。特に2018年以前にローンチして、決済プラグインを最新化していない場合は要注意ですが、ほとんどの場合、決済代行会社から「カード情報非保持化」したプラグインへのアップデートが案内されていると思います。

上記のとおり、安全な決済プラグインを使っている限り、ECサイト側からカード情報が漏洩してしまうことは理論上ありません。逆に言えば、決済プラグインを作り変えてしまえば安全なサイトが危険なサイトになってしまう可能性があるということです。

そのような事態が発生するとすれば、考えられる理由は２つあります。

1つは先ほど挙げた裁判になった例のように、意図してカスタマイズすることです。何らかの理由で顧客が入力したクレジットカード情報を利用しようとしてデータベースに保持したり、ログに記録しておいたりすることです。例えば、コールセンターに問い合わせがあったときに、顧客の入力したカード番号が分からないと顧客の質問に答えられないことがある、といったことを考えてカード番号を保持するカスタマイズをするといったことです。コールセンターのオペレーターでもカード番号が見えてしまいますので、そもそも危険です。現在、このような運用を続けている事業者はないとは思いますが、もしそうなっているとすればすぐに改善するべきです。

もう1つは悪意を持った誰かがEC運営者の意図に反してプログラムを改変することで、このような行為を改竄（かいざん）といいます。クレジットカード情報を後で窃取できるようにデータベースやファイルに保持するようにしたり、リンク決済のリンク先を書き換えて別のサイトにカードを入力するよう誘導したり、さまざまな手段があり得ます。

EC-CUBEでクレジットカード漏洩を起こさないサイトであるためには、「カード情報の非保持化」をした上で、改竄されないように対策をしている必要があります。

最も実行しやすい改竄の方法は、正規のIDとパスワードを盗み、正規の方法でサーバに接続することです。この方法でプログラムを書き換えられると、異常として検出するのは難しいです。

サーバへのアクセスするIDやパスワードは厳重に管理する必要がありますし、接続方法もセキュアな手段にしておく必要があります。暗号化されていないFTPで接続などは許してはいけませんし、接続元はIPや鍵で制限するべきです。

EC-CUBEの管理画面のアクセスも保護する必要があります。管理画面にアクセスされてしまうと、顧客の氏名や住所などの個人情報が流出してしまいます。管理画面も可能なら接続元IPで制限したり、Digest認証で保護したりします。パスワードも容易に推測できない強度にします。IDとパスワードをキーボードに付箋で貼っておくといったことは論外です。この管理画面はサーバにファイルをアップロードすることができます。何らかの脆弱性があると、危険なプログラムをアップロードされる危険があります。

いずれも内部犯行だと避けることが難しいですので、社員や委託先に必要な教育を施し、損害を発生させた場合の賠償も含めた契約を結んで置く必要があります。

表側からECサイトの脆弱性を突くよりも、裏側の管理者側からアクセスしたほうが、確実に意図通りの攻撃ができます。社内の情報セキュリティを定期的に確認することは最重要項目です。

管理側からの正規のサーバのアクセスをきっちり管理されていると、攻撃することは非常に難しくなります。その場合は、ECサイトの脆弱性（ぜいじゃくせい）を利用して、正規の方法ではない方法でサーバに侵入するしかありません。

脆弱とはもろくて弱いということです。ドアに立派な鍵がついていたとしても、ドアそのものが弱ければ、ドリルで穴を開けて針金を差し込んで鍵を開けられてしまうことがあります。同じようにサーバに、ちょっとした穴を開けられる可能性があれば、犯人はそこにチャレンジしようとしてきます。

サーバのOSや、EC-CUBEも、脆弱性が見つかると対策用のモジュールを配布しています。軽度の脆弱性だったとしても丁寧にそれらのモジュールを適用するようにしましょう。

針金を突っ込んでサムターンを回すという犯罪が増えた時に、サムターンを回されないようにとりつけるプラスチックのカバーを買って取り付けた人もいたと思います。脆弱性対応モジュールはそのプラスチックの鍵カバーのようなもので、攻撃の成功の可能性を減らします。

犯人の攻撃方法はどのようなものになるかわかりません。それで攻撃の足がかりになるかもしれないものは、なるべく潰しておいた方が良いです。一方で、そのような基本的な対策が施されていないサイトは、不用心な家の様に見えます。犯人に目を付けられやすくなる可能性もあります。

2018年以降、EC-CUBEと公式の決済プラグインはクレジットカード情報が理論上漏洩しない仕組みで作られています。それ以前にローンチしたサイトで不安がある場合は、構築したベンダーや決済代行会社に確認してください。

それでも、クレジットカード情報漏洩が発生するとすれば、EC-CUBE本体か決済プラグインが何か変更された場合です。それはカスタマイズのミスか、悪意の第三者による改竄（かいざん）が原因となります。

改竄が心配である場合は、インストールしたオリジナルのソースコードとサーバ側のソースコードに差異がないことを確認してみてください。

もし改竄されていた場合はすでに深刻な問題が発生している可能性があります。実際にカード情報の漏洩が発生していた場合の措置については次の記事でまとめてみようと思います。