EC-CUBE 脆弱性の告知を「お客様が自分で見るもの」にしていないか──ECサイトの脆弱性対応と、構築した制作会社が結ぶべき保守の取り決め

この記事は、EC-CUBE 脆弱性をはじめとするECサイトの脆弱性に、構築した制作会社がどう備え、保守として何を取り決めるかを扱います。

「納品したあとのことは、聞いていません」

ECサイトの構築を終えて、2年。
ある日、お客様から電話が来ます。「カード会社から、うちのサイトで情報が漏れている可能性があると連絡が来ました」

保守契約は結んでいません。納品のときに「更新はご自身で」と伝えたはずです。
けれど、お客様の頭の中では、サイトを作った会社が、守る会社でもありました。

ECサイトの脆弱性対応とは、使っているソフトウェアとそのバージョンを把握し、開発元とJVNの情報で該当を判断し、決めた手順で更新する運用を、誰が担うか契約で決めておくことである

黒字化の外科医です。ECサイトの脆弱性対応を、構築した制作会社の立場で解剖します。

なお私は弁護士ではありません。実務の指針として読み、個別の判断は専門家や公的な窓口に確認してください。

ECサイトで、とくに取り決めが必要な理由は、三つあります。

第一に、ECサイトは、狙われたときの被害が大きいから。
IPAは2019年12月、EC-CUBEを使ったウェブサイトで、決済の画面が改ざんされ、クレジットカード番号が窃取される被害が多く起きているとして、注意喚起を出しました。そこで運営者に求めたのは、自社が使っているかの確認、バージョンの確認と最新版への更新、開発元のセキュリティ情報の確認と対策の実施、の3点です。

第二に、国の指針が、構築と運用の両方に対策を求めているから。
経済産業省とIPAは2023年3月、中小企業向けに「ECサイト構築・運用セキュリティガイドライン」を公開しました。経営者編と実践編に分かれ、構築時と運用時の対策要件と、チェックリストが付いています。読者には、構築や運用を受託する外部の事業者も含まれています。

第三に、ECはカスタマイズが多く、更新が簡単ではないから。
独自に改修した部分があると、更新で改修が消えたり、動かなくなったりします。「更新すればいい」の一言で済まないからこそ、誰がどこまでやるかを決めておく必要があります。

今すぐ試せる：ECサイトの「守る対象」を一覧にするプロンプト

私はWeb制作会社で、構築したECサイトの保守を見直しています。
次の情報から、脆弱性の確認に必要な「守る対象」の一覧を作ってください。

【サイトの情報】
・ECの基盤（パッケージ名／バージョン）：〔　〕
・入れているプラグイン・モジュール（名前／バージョン）：〔　〕
・独自に改修した箇所：〔　〕
・決済の方式（外部の決済画面へ移る／自社サイト内で入力 など）：〔　〕
・サーバー、PHP、データベースのバージョン：〔　〕

1. 脆弱性の情報を確認すべき対象を、一覧にする。
2. それぞれ、情報を確認する先（開発元の告知、JVN）を書く。
3. 更新するときに、改修の影響を受けそうな箇所を挙げる。

わからない項目は空欄のまま「要確認」とすること。

EC保守工場：脆弱性対応の手順と、取り決めの項目

1. 情報の確認先

・ECの基盤の開発元が公開するセキュリティ情報
・JVN（JPCERT/CCとIPAが共同で運営する、脆弱性対策情報のポータル）
・使っているプラグイン・モジュールの提供元の告知
・サーバー会社からの通知

JVNには、影響を受ける製品とバージョン、開発者が提供する対策へのリンクが載ります。対策は更新だけでなく、修正ファイルの適用や回避策のこともあります。

2. 該当したときの手順

① 構成表で、該当するバージョンかを確認する
② 該当すれば、お客様に第一報を入れる（対応の予定日を添える）
③ バックアップを取り、検証環境で更新または修正ファイルを適用する
④ 注文・決済・会員登録・管理画面の動作を確認する
⑤ 本番に適用し、同じ項目を確認する
⑥ 作業の記録を残し、お客様に完了を報告する

3. 保守契約に入れる取り決め

・守る対象（基盤、プラグイン、サーバー、PHP）と、対象外のもの
・脆弱性の情報を確認する頻度と、確認先
・緊急の更新の判断基準と、対応までの目安の日数
・改修部分が更新で動かなくなった場合の、対応範囲と費用
・バックアップの頻度と、保管の期間
・管理画面のアカウントの管理（誰が持つか、退職時の扱い）
・保守契約がない期間に起きたことの扱い

最後の項目が大切です。保守契約を結ばないお客様には、「納品後の脆弱性対応は、お客様の側で行う」ことを、納品のときに書面で伝えておきます。

4. 保守を断られたときに渡す1枚

【納品後のセキュリティについて】
このサイトは〔基盤名・バージョン〕で構築しています。
脆弱性の情報は、開発元の告知とJVNで公開されます。
定期的に確認し、更新や修正ファイルの適用を行ってください。
更新の作業が必要になった際は、別途お見積りでお受けします。

この1枚があるだけで、2年後の電話の中身が変わります。

構造的なリスク

逆説を指摘しておきます。

EC保守を引き受けると、守る責任が自社に移ります。
とくに、カード情報が漏れたときの調査や賠償の話は、保守の月額とは桁の違う金額になりえます。

だから、引き受ける範囲と、責任の上限を、契約で決めずに引き受けてはいけません。責任の範囲の考え方は、別の記事で扱います。

▶ Web制作会社の責任と損害賠償は「サイトが攻撃された日」に問われる──制作と保守で違う責任の形、契約で決める上限・免責・範囲外・お客様の義務

よくあるQ&A

Q. 古いバージョンのまま、更新できないECサイトはどうするか？

更新の見積もりと、別の基盤への移行の見積もりを、並べて出してください。開発元のサポートが終わっている版なら、移行も選択肢に入ります。

Q. ECの保守料は、通常のサイトより高くしてよいか？

守る対象が多く、確認の項目も多いので、工数が違います。自社の時間単価と、実際の作業時間で計算してください。

▶ EC運用代行の月額、制作会社は「売上の何%」で受けない──商品登録・特集・分析・広告の範囲の分け方と、成果報酬を避ける理由の計算例

Q. 決済は外部のサービスに任せているので、関係ないのでは？

カード情報を自社のサイトで扱わない方式でも、サイト自体が改ざんされれば、偽の画面に誘導される危険は残ります。カード決済の指針との関係は、別の記事で扱います。

▶ クレジットカード情報漏洩、EC制作会社は「非保持だから安心」と言えない──ガイドライン6.1版の脆弱性対策5項目と、制作・保守の役割分担表

最後に

ECサイトの脆弱性は、構築した会社に問い合わせが来ます。契約があってもなくても、です。

守る対象と手順を決め、引き受ける範囲を契約に書いた会社だけが、ECの保守を、事故の窓口ではなく、続く売上に変えられるのです。

これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。

#Web制作会社 #ECサイト #ECCUBE #脆弱性 #セキュリティ #制作会社経営 #中小企業 #保守契約 #ECサイト構築 #リスク管理