顧客データを扱うシステムで、最低限やっておくこと

顧客情報を扱うシステムを作るとき、セキュリティの話は「やり始めるときりがない」と敬遠されやすい。実際、上を見れば際限がない。

ただ、設計の段階で決めておけば費用がほとんどかからないのに、後から入れると高くつく項目がある。中小企業が現実的に守れる線として、その部分だけを挙げる。

1. 持たないデータを決める

最初にやるべきは、技術ではなく方針の話だ。保存しないデータは漏れない。

• 問い合わせフォームに、本当に生年月日や住所の欄が必要か
• クレジットカード番号を自社で保存する必要があるか（決済代行を使えば持たずに済む）
• ログに、氏名やメールアドレスをそのまま書き出していないか

3つ目は見落とされやすい。デバッグのために入れたログ出力が、そのまま本番で個人情報を書き続けていることがある。

2. 保存期間を決めて、消す

「念のため取っておく」を続けると、10年前の顧客情報が残ったデータベースができあがる。使わないのに、漏れたときの被害だけが増えていく。

• 問い合わせ内容は何年で消すか
• 退会した利用者のデータをいつ消すか
• バックアップは何世代残すか

決めたら、自動で消える仕組みにする。手作業の運用ルールにすると、忙しい時期に必ず止まる。

3. 通信を暗号化する（これは例外なく）

HTTPS は当然として、見落とされやすいのが次の2つ。

• 管理画面。公開ページだけ HTTPS で、管理画面が HTTP のままという構成が残っていることがある
• フォームの送信先。ページが HTTPS でも、送信先の指定が http:// になっていれば意味がない

サーバー側で HTTP を HTTPS へ強制的に転送する設定を入れておけば、取り違えを防げる。

4. パスワードは復号できない形で保存する

自社で認証を作る場合の必須項目。パスワードは暗号化ではなくハッシュ化する。暗号化は元に戻せるが、ハッシュは戻せない。戻せないから安全になる。

// 保存するとき
$hash = password_hash($plain, PASSWORD_DEFAULT);

// 照合するとき
if (password_verify($input, $hash)) {
    // ログイン成功
}

自前でハッシュ計算を組まないこと。password_hash() は、ソルトの付与も計算コストの調整も内部でやってくれる。

「パスワードを忘れた」で元のパスワードをメールで送ってくるサービスは、平文か復号可能な形で保存している証拠になる。自社ではやらないこと。

5. アクセスできる人を絞る

意外と多いのが、全社員が全データを見られる状態になっているケース。

• 権限を「管理者」と「一般」の2段階でいいので分ける
• 退職者のアカウントを消す運用を決める
• 共有アカウントを作らない（誰が操作したか分からなくなる）

3つ目は「面倒だから1つでいい」となりがちだが、何かあったときに原因を追えなくなる。人数分作るのが結果的に安い。

6. 何が起きたかを追える記録を残す

漏えいが疑われたとき、いちばん困るのは「何が起きたか分からない」状態だ。

• 誰がいつログインしたか
• 誰がどのデータを書き換えたか
• 管理画面から一括ダウンロードが行われたか

記録があれば、被害の範囲を特定して、必要な相手にだけ連絡できる。記録がないと、全員に「漏れたかもしれません」と通知するしかなくなる。信用の失い方がまったく違う。

7. 更新を止めない

技術的にはこれがいちばん効く。実際の被害の多くは、高度な攻撃ではなく既に公表されている脆弱性の放置から起きている。

• CMSやプラグインの更新を適用する
• 使っていないプラグイン・テーマは停止ではなく削除する
• サーバーのPHPバージョンを、サポートが切れたまま使わない

更新は手間だが、止めた瞬間から時間とともに危険度が上がり続ける。保守契約の価値の大半は、実はここにある。

完璧を目指さない

ここに挙げたのは、いずれも「設計時に決めれば追加費用がほぼ発生しない」ものばかりだ。逆に、稼働後に入れようとすると、データ移行や改修が必要になって数十倍の費用がかかる。

中小企業が国家レベルの攻撃に耐える必要はない。ただ、自動化された無差別のスキャンに引っかからない程度には固めておく。実際に被害を受けているサイトの大半は、狙われたのではなく、たまたま穴が開いていたところに当たっているだけだ。

システムの設計段階からご相談いただければ、この範囲は標準で組み込みます。既に動いているシステムについても、どこに穴が開きやすいかの確認からお引き受けしています（ホワイトハッカーAI社員）。