中小企業のWebシステムに最低限必要なセキュリティ対策

自社の Web システムを持つと、「セキュリティ対策は何をすれば十分なのか」という不安がつきまといます。専門の担当者がいない中小企業では、考えられる対策をすべて実施するのは現実的ではありません。この記事では、規模を問わず最低限おさえておきたい対策を、優先順位をつけて整理します。すでにシステムを運用している方は、自社の状況と照らし合わせながら読み進めてください。

通信を暗号化する

SSL/TLS（通信を暗号化する仕組み）は、Web システムの土台になる対策です。ログイン画面や入力フォームがあるなら、すべてのページを https で配信するのが前提になります。暗号化されていない通信は、途中で内容を盗み見られたり、書き換えられたりする可能性があります。

対応の要点は次のとおりです。

• サイト全体を https にし、http でのアクセスは https へ転送する
• 証明書の有効期限を管理し、自動更新の仕組みを使う
• 管理画面や API（システム同士が通信する窓口）も例外にしない
• 古い暗号方式を無効化し、サーバーの設定を定期的に見直す

証明書が切れるとブラウザに警告が表示され、利用者が離れてしまいます。誰が更新を管理するのかを、保守の範囲に含めておくと安心です。証明書の種類や取得方法は ドメインと SSL の基礎 で解説しています。

認証とパスワード、多要素認証

外部からの侵入で多いのは、高度な攻撃よりも「推測されやすいパスワード」や「使い回し」を突かれるケースです。認証まわりは、設定と運用ルールだけで大きく改善できる領域です。

想定例：営業担当が退職したあと、共有していた管理者アカウントのパスワードが変更されないままになっていた、という状況は珍しくありません。個人ごとの ID にしておけば、退職時にその ID を止めるだけで済みます。

パスワードの保存方法も重要です。システムがパスワードを平文（そのままの文字列）で保存していないか、開発会社に確認しておきましょう。適切なシステムでは、元に戻せない形に変換して保存しています。

権限は最小限に

「必要な人が、必要な範囲だけ操作できる」という原則を、最小権限といいます。全員が管理者権限を持っていると、誤操作の影響も、アカウント乗っ取り時の被害も大きくなります。

• 一般利用者・編集者・管理者のように役割を分ける
• 顧客情報の閲覧やエクスポートは、業務上必要な人だけに限定する
• 開発会社に渡すアカウントも、作業に必要な範囲に絞る
• 退職・異動があったら、速やかにアカウントを停止または権限変更する
• 誰がどの権限を持っているかの一覧を定期的に棚卸しする

想定例：アルバイトを含む全員が同じ管理者アカウントで注文データを見られる状態だと、誰がいつ何を操作したのか追えず、情報の持ち出しにも気づけません。役割ごとに権限を分けると、こうしたリスクを小さくできます。

権限の設計は、要件定義の段階で「誰が何をできるか」を表にしておくと、開発後に慌てずに済みます。

アップデートとバックアップ

ソフトウェアには、後から見つかる欠陥（脆弱性）があります。修正版が公開されているのに適用していない状態は、鍵の壊れた扉を放置しているのと同じです。

アップデートの考え方

• OS、Web サーバー、言語、フレームワーク、CMS（コンテンツ管理システム）とそのプラグインを対象にする
• 修正の重要度が高いものは、通知を受けたら早めに適用する
• 本番に適用する前に、ステージング（本番と同じ構成の確認環境）で動作を確認する
• 誰が通知を受け、誰が判断し、誰が作業するかを決めておく

更新で表示が崩れることを恐れて、長期間放置してしまう例は少なくありません。放置期間が長いほど、いざ更新するときの影響も大きくなります。小まめに更新するほうが、結果として作業は軽くなります。

バックアップの考え方

バックアップは「取っていること」より「戻せること」が重要です。

想定例：ランサムウェア（データを暗号化して金銭を要求する攻撃）の被害に遭った場合、同じサーバー上のバックアップも一緒に暗号化されることがあります。別の場所への保管が効いてくる場面です。

ログと個人情報の扱い

対策を入れるだけでなく、「何が起きたか後から分かる状態」と「守るべき情報がどこにあるか把握している状態」を作ることも同じくらい重要です。この2つは、事故が起きたときに被害の範囲を確かめる手がかりになります。

ログを残す

何かが起きたとき、ログがなければ原因も影響範囲も分かりません。最低限、次の記録を残しておきましょう。

• ログインの成功・失敗（誰が、いつ、どこから）
• 重要なデータの作成・変更・削除
• 管理画面での設定変更
• サーバーへのアクセス記録とエラー

ログは保存期間を決め、簡単に消せない場所に置きます。定期的に「見慣れないアクセスがないか」を眺める習慣も効果があります。異常に気づく早さが、被害の大きさを左右します。

個人情報を集めすぎない

顧客情報を扱うシステムは、個人情報保護の観点も欠かせません。

• 業務に必要な項目だけを集め、不要になった情報は消す
• 誰がどの情報を閲覧できるかを権限で制御する
• 外部にデータを渡す場合は、範囲と目的を契約で明確にする
• 漏えいが起きた場合の連絡先と手順をあらかじめ決めておく

「集めない」「残さない」は、もっとも確実な対策です。フォームの項目を見直すだけでも、リスクは下がります。

一度きりではなく、運用として続ける

セキュリティ対策は、一度やって終わりではなく、運用の一部として続けるものです。優先順位をつけると、次の順で取り組むのが現実的です。

1. SSL/TLS と認証（多要素認証・個人ごとの ID）
2. 権限の見直しとアップデート体制
3. バックアップの復元テストとログの確認
4. 個人情報の棚卸しと漏えい時の手順

すべてを自社で抱える必要はありません。システム保守・サポート のように、外部と分担する形でも構いません。開発を依頼する段階でこれらを要件に含めておくと、後付けよりも費用と手間を抑えられます。ご不明な点は お問い合わせ からご相談ください。

一般的な情報であり、個別の事案は専門家・所管官庁にご確認ください。