セキュリティの前に経路を描く
商品ページから入力フォーム、戻り先までをたどり、誰が運営し、どこで機密情報を入力するかを確認します。一体に見えるフォームと完全な外部ページでは、技術的な境界が異なる場合があります。
この違いは保護と確認の範囲に関わります。PCI SSCは2017年に複数のEC構成を扱う指針を公開しました。すべてを同じ決済システムと思わず、実際の仕組みを把握することが出発点です。
必要のない情報は集めない
販売には注文や連絡先が必要ですが、カード番号を自社で保存する必要まであるとは限りません。提供事業者が機密情報を扱い、自社は番号と検証済みの結果を保つ方法を検討します。
フォームが不便だからとメールでカード情報を求めないでください。複製・転送・保存の場所が増えます。入力の問題を解決し、管理しにくいチャネルへ情報を移さないことが重要です。
サイトを変更できる人の権限を守る
決済ページが安全でも、管理者アカウントが無防備なら十分ではありません。拡張機能、リンク変更、注文出力の権限を確認し、対応する範囲で個人ごとのアクセスを用意します。
ソフトウェアを保守し、使わない構成を外し、変更を確認する担当を決めましょう。無断で支払先が変わったとき、チームが気づけるかを考えてください。
提供事業者の責任を具体化する
どの部分を運営し、保護の説明を裏づける根拠が何かを聞きます。自社の義務は構成によって変わり、バッジや営業の説明だけでは範囲はわかりません。
事業者や評価機関と確認しましょう。ホスト型は直接触れるデータを減らせても、サイト全体のセキュリティ作業をなくす約束ではありません。双方の担当を記録します。
通知だけで発送を決めない
決済完了を知らせるメールが届いても、それだけで商品を発送しないようにします。管理画面で注文と取引を探し、決めた手順で確認してください。お客様のスクリーンショットは問い合わせの参考にはなりますが、決済記録の代わりではありません。
振込先の変更、返金、スタッフ権限の追加を誰が承認するかも決めます。担当者が退職した場合の権限回収まで確認しましょう。日々の操作に結びつけることで、スタッフも追加確認が必要な場面と不審な依頼の相談先を理解できます。
不審な変更への対応を用意する
決済先や動作が変わった場合に停止・調査する経路を用意します。正常な設定と担当連絡先を残し、サポートが不審な依頼を報告できるようにしましょう。
お客様が想定外の画面を見たという連絡を想定すると有効です。対応が決まっていれば、最初の開発者がいなくても技術的な保護を業務で使えます。
不要な決済データの処理を減らし、自社サイトの保護責任は明確に保ちましょう。