Shopifyのセキュリティ対策と信頼性｜PCI DSS準拠と安全性

「Shopifyで個人情報や決済情報を扱って大丈夫だろうか」。ネットショップを始めるとき、多くの運営者が最初にぶつかる不安です。結論から言えば、Shopify本体はかなり堅牢です。ただし、安全かどうかは運用次第で変わります。

Shopifyはプラットフォームとして決済・通信・インフラのセキュリティを標準で提供しています。一方、アカウント管理やアプリの選定など、運営者が行う操作の安全性は運営者自身が担う構造です。城壁も金庫も、Shopifyが用意した堅牢なものが最初から備わっています。一方で、門の鍵を誰に渡すか、城の中に外から何を持ち込むかは、家主である運営者の判断に委ねられています。破られるとしたら、城壁ではなく、開けっ放しの門や、持ち込んだ怪しい荷物からです。

この記事では、Shopifyが標準で守る範囲と、運営者が自分で守る範囲を整理し、日々の運用で押さえる3つの対策を解説します。

1.決済・通信・インフラ——この3つはShopifyが守ってくれる

Shopifyのセキュリティを考えるとき、まず押さえたいのは「自分で守らなくていい範囲」です。決済・通信・インフラという土台は、Shopifyが標準で引き受けています。

1-1. PCI DSS Level 1｜カード決済を守る国際基準

ネットショップで最初に不安になるのが、お客さまのカード情報です。Shopifyはこれを、カード業界で最も厳しい基準「PCI DSS Level 1」を満たした環境で処理しています。しかも、運営者がカード番号そのものを見たり保管したりする場面はありません。

PCI DSSは、Visaやマスターカードなど国際ブランドが定めたカード情報の取り扱いルールです。加盟店（マーチャント）は取引規模に応じて4段階に分かれ、最上位のLevel 1が最も厳しい区分です。Shopifyはこの加盟店とは別に、決済基盤を提供する「サービスプロバイダー」としての最上位、Level 1認証を受けています。第三者機関による年次監査も受け続ける立場です。

そのため、Shopify Paymentsを標準のまま使う運営者は、PCI対応の重い部分をShopifyに任せられます。ただし責任がすべて移るわけではありません。運営者側にも簡易な自己問診（SAQ-A）が残り、決済ページに外部のアプリやスクリプトを乗せると、確認すべき範囲は広がります。なお、カード情報はShopifyのシステム内だけで暗号化・トークン化され、運営者の管理画面に完全なカード番号が表示されることはありません。

カード情報を守る一番重い部分は、Shopifyが引き受けている構造です。ただしこれは「カード情報」に限った話です。あとから入れたアプリや、自分で足したテーマ・コードのように、運営者が持ち込んだものまで覆うわけではありません。そのあたりが、漏洩リスクの入り口になります。

参考：PCI Compliant Hosting Provider（Shopify公式）

参考：Shopify Security（Shopify公式）

1-2. 常時SSL｜通信を暗号化して盗み見を防ぐ

お客さまがサイトを開いた瞬間から、通信はすべて暗号化されています。Shopifyでは決済画面だけでなく、商品ページも含めた全ページが常時SSLで保護されます。

SSL（正確にはTLS）は、ブラウザとサーバーの間でやり取りするデータを暗号化する仕組みです。暗号化がないと、同じWi-Fiにつないだ第三者に、入力した住所やパスワードを盗み見られるおそれがあります。暗号化されていれば、途中で通信を覗かれても中身は読み取れません。

自前でサイトを立てる場合、SSL証明書は取得も更新も運営者側の作業でした。Shopifyでは証明書の発行も更新も無料で自動です。有効期限が切れて「保護されていない通信」と表示されるトラブルも起きにくくなっています。

ここで守られるのは、あくまで移動中のデータです。カード情報の保管とはまた別の層で、通信経路上の盗み見や改ざんを防いでいます。

参考：Enabling secure connections to your Shopify store（Shopify Help Center）

参考：All Shopify Stores Now Use SSL Encryption Everywhere（Shopify公式ブログ）

1-3. インフラ｜攻撃と障害への備えはShopify側が持つ

アクセスが集中する時間帯やサイバー攻撃を受けたとき、サーバーを守るのはShopify側の仕事です。運営者が自分でサーバーを用意したり、増強したりする必要はありません。

ネットショップは、セール時のアクセス集中やDDoS攻撃（大量のアクセスを意図的に集中させてサービスを停止させる攻撃）といった負荷にさらされます。Shopifyは世界中の店舗を同じ基盤の上で動かし、その基盤の運用をプラットフォーム側でまとめて引き受けています。可用性やセキュリティの管理体制は、第三者監査であるSOC 2 Type II（米国公認会計士協会の基準にもとづき、情報管理体制を第三者が評価する監査制度）の報告書でも評価対象になっています。

自社サーバーで運用していると、深夜の障害対応や、急なアクセス増でサイトが落ちる心配がつきまといます。クラウド型のShopifyでは、この負担はプラットフォーム側が一括して引き受けています。

ここまでが、Shopifyが標準で守ってくれる土台です。箱そのものの頑丈さは、運営者が手を入れなくても保たれます。ただ、その箱をどう使うかは、運営者の側に委ねられています。

参考：Viewing Shopify’s compliance reports（Shopify Help Center）

参考：Shopify Security（Shopify公式）

2.それでも漏洩は起きる。原因の多くはShopifyの外側にある

土台が堅牢でも、漏洩がゼロになるわけではありません。ただ、漏れるとしたら原因の多くは同じ側に偏っています。

2-1. 責任分界｜Shopifyが守る範囲と運営者が守る範囲

Shopifyが守るのは、決済・通信・インフラという土台までです。その先のアカウント・アプリ・テーマは、運営者が引き受けます。この線引きを責任共有と呼びます。

土台はめったに崩れません。崩れやすいのは、運営者が日々触れる側です。守れるかどうかは、この管理範囲をどう扱うかで決まります。

2-2. 漏洩の原因｜盗まれたログインと持ち込んだ部品

ログイン情報は、フィッシングやパスワードの使い回しで盗まれます。持ち込んだ部品は、過剰な権限を持つアプリや、出所の怪しいコードです。運営者側の漏洩は、この2つのどちらかに行き着きます。

過去に報じられたShopify関連の漏洩を見ても、プラットフォームの土台が技術的に破られたケースは確認されていません。2020年は、Shopifyのサポートスタッフ2名が社内からアクセス権を悪用し、200店舗未満の顧客データを持ち出しました。Shopify自身が内部不正と認め、技術的な脆弱性が原因ではないと説明しています。2024年には約17万9千件のデータがフォーラムで売りに出されましたが、Shopifyは自社システムのインシデントを否定し、連携アプリが原因としています。ただしアプリ名は公表されず、第三者による確認は取れていません。

この2件のうち、運営者が自分で管理できるのは、アプリのように外から持ち込む部品の側です。守るべき領域は、アカウント・アプリ・テーマ／コードの3つに整理できます。

参考：What happened in the recent data incident involving less than 200 Shopify merchants?（Shopify Community）

参考：Shopify says two support staff stole customer data from sellers（TechCrunch）

参考：Shopify Data Breach Impacting 180,000 Users Tied to Third-Party App（CyberInsider）

3.守れるかどうかは、Shopifyの設定より日々の運用で決まる

守る主体が運営者側にあるなら、対策も日々の運用に落ちます。ただ、アカウント・アプリ・テーマ／コードの3つの領域は守り方が違います。アカウントは権限を絞ることで、アプリは入れた後の棚卸しで、被害の芽を減らせます。一方テーマ・コードは、権限や棚卸しでは防げないタイプの攻撃が入り込みます。順に見ていきます。

3-1. アカウント｜守るべき権限を見極めて絞る

退職したスタッフのアカウントが権限を持ったまま残るケースは、EC運営でよく見られます。

ただし対策は、すべての権限を一律に絞ることではありません。財務や入金のように被害が大きい操作だけ権限を分ければ、業務効率を保ったまま安全を上げられます。

Shopifyの権限は、商品・注文・財務・アプリ管理など機能ごとに割り振れます。日々の出荷担当に財務まで開ける必要はありません。全員に管理者権限を渡すと、1つのアカウントの乗っ取りが店舗全体に及びます。2020年の事件も、アクセス権を持つ人間が必要以上のデータに届いた構造でした。

あわせて、Shopify Paymentsで入金を受けるアカウントには二段階認証が必須です。パスワードに加えてもう一段の本人確認が入るため、パスワードが漏れても乗っ取られにくくなります。

権限にメリハリをつけ、使わないアカウントは消す。この2つを習慣にできる運営者なら、ログイン起点の漏洩はかなり抑えられます。

参考：Securing your account with two-step authentication（Shopify Help Center）

3-2. アプリ｜入れた後の管理で穴を防ぐ

便利そうなアプリを次々入れて、そのまま使わなくなったものが残っている。アプリの棚卸しができていない店舗では、こうした状態になりやすいです。

アプリで危ないのは、入れる瞬間よりも入れた後に放置することです。定期的な棚卸しが穴を防ぎます。

アプリはインストール時に、店舗データへのアクセス権限を要求します。2024年の事例のように、連携アプリが漏洩の起点になることもあります。削除すればアクセスの入口は閉じますが、それまでにアプリ側へ渡ったデータは戻りません。スマホのアプリと同じで、消しても相手のサーバーにある情報までは消えないためです。

導入前に開発元と要求される権限を確認し、使わなくなったアプリは消す。半年に一度など時期を決めて見直せば、放置された権限は減ります。

アプリの数が増えた店舗ほど、棚卸しの効果は大きくなります。入れた数ではなく、管理できている数が安全を決めます。

3-3. テーマとコード｜決済の外で脆弱性を持ち込まない

自作のテーマやコードは、決済の外側で脆弱性を持ち込みかねません。出どころと更新の管理が要ります。

カード決済まわりはShopifyが守っても、独自に足した問い合わせフォームや外部スクリプトは、その守りの外にあります。ここから漏れるのは、氏名・住所・メールなどの個人情報です。

さらに厄介なのが、Webスキミングと呼ばれる攻撃です。決済ページなどに不正なスクリプトが仕込まれ、お客さまが入力した情報をブラウザ上で直接盗みます。Shopifyがカード情報を暗号化する守りを迂回するうえ、管理画面からは正常に見え、気づかれないまま続くことがあります。Shopify店舗を狙った事例も研究者から報告されています。

権限をどれだけ絞っても、この手の攻撃は防げません。効果的なのは、配布元のはっきりしたテーマやコードだけを使い、変更のたびに中身を確認することです。地味ですが、スキミングを遠ざける現実的な方法はこれに尽きます。

参考：Multi-platform card skimmer found on Shopify, BigCommerce stores（Bleeping Computer）

参考：Shopify PCI Compliance: What the Platform Covers and What It Doesn’t（Security Boulevard / Reflectiz）

4.まとめ

Shopifyという城は、もともと頑丈です。決済はPCI DSS Level 1、通信は常時SSL、インフラの運用もプラットフォーム側が引き受けています。城壁や金庫を、運営者が自分で用意する必要はありません。

最初の一歩は、いちばん被害の大きいアカウントからです。管理画面の「ユーザーと権限」を開き、使われていないアカウントを消し、財務や入金の権限を必要な人だけに絞る。二段階認証も有効にしておく。ここまでで、漏洩の入り口のひとつは大きく塞げます。アプリの棚卸しと、テーマ・コードの出どころ確認は、その次の週末にでも回せば十分です。大切なのは、完璧な体制を一度に作ることではなく、被害の大きい順に一つずつ潰していくことです。堅牢な土台が活きるのは、この一歩を踏み出してからです。

セキュリティ設計や運用体制の見直しは、Shopify構築の実績を持つ専門家に相談する選択肢もあります。