業務システムのセキュリティ要件｜中小企業が最低限おさえるべき7つの項目

セキュリティ対策は後回しにして、まず動くものを作ろう。そう判断して開発を進め、稼働後しばらくしてから「顧客データが外部に流出した」「不審なログインが検知された」「バックアップが壊れていてデータを復元できない」という事態に直面した企業は少なくない。問題が起きて初めて、発注時に何も決めていなかったことに気づく。後からセキュリティを組み込むのは、完成した建物に耐震工事をするようなものだ。構造から作り直さなければならない箇所が生まれ、費用も工期も想定をはるかに超える。中小企業がシステム開発を依頼するとき、最低限どのセキュリティ要件を最初に確認しておくべきか。この記事ではその7つの項目を整理する。

なぜ中小企業のシステムがセキュリティリスクを抱えやすいか

「うちは中小企業だから、攻撃者に狙われるほどの規模じゃない」という認識は、現在の脅威環境に照らすと正確ではない。実際のサイバー攻撃の多くは、特定の企業を狙い打ちにするものではなく、脆弱性のあるシステムを機械的にスキャンして無差別に侵入を試みるものだ。規模は関係ない。むしろ、セキュリティ対策が手薄な中小企業のシステムは、攻撃者にとって「入りやすい場所」として認識されやすい。

構造的な問題もある。システム開発を発注する側の担当者は、要件定義の段階で「何の機能が必要か」に集中しがちで、「その機能をどのくらい安全に動かすか」は後回しになりやすい。開発会社の側も、セキュリティ要件を明示的に指定されなければ、最低限の対応だけで済ませることが多い。「言われなければやらない」という構造が、多くの現場で存在している。

その結果、稼働後に脆弱性が発見されてから対応コストが発生する。事前に組み込むコストの数倍から数十倍になることも珍しくない。セキュリティは最初から要件として定義する必要がある。

最低限おさえるべき7つのセキュリティ要件

①認証と権限管理（誰が何にアクセスできるかを設計する）

システムに誰がアクセスでき、何ができるかを明示的に設計することが基本だ。「管理者」「一般ユーザー」「閲覧専用」など、役割ごとにアクセスできる機能とデータを分ける。すべての社員が全データを見られる設計は、内部からの情報漏洩リスクを高める。退職者のアカウントが有効なままになっていないか、共有アカウントでログインが行われていないか、といった運用面の問題も、設計段階で防ぐ仕組みを作れる。多要素認証（MFA）の導入可否も、要件定義の時点で確認しておく必要がある。

②通信の暗号化（HTTPS/TLS対応、API通信の保護）

ブラウザとサーバーの間でやりとりされるデータが暗号化されているか。HTTPS対応は現在では標準的な要件だが、社内システムや管理画面では省略されているケースがある。また、外部サービスとAPI連携を行う場合、そのAPI通信が暗号化されているか、認証トークンが適切に管理されているかも確認が必要だ。通信が平文のまま行われていると、同一ネットワーク上での傍受リスクが生じる。クラウド上に構築する場合でも、ネットワーク設定を見直すことが求められる。

③入力値のバリデーション（SQLインジェクション・XSS対策）

システムへの入力フォームやURLパラメータを通じて、悪意のあるコードをデータベースに送り込む攻撃（SQLインジェクション）や、スクリプトを埋め込んで他のユーザーのブラウザで実行させる攻撃（XSS）は、適切なバリデーション処理を行わないシステムに対して今でも有効な手法として使われている。開発フレームワークが対策機能を持っていても、カスタム実装部分で抜け漏れが生じることがある。入力値の検証と出力時のエスケープ処理が実装されているかを確認する必要がある。

④ログの取得と保管（誰がいつ何をしたかを記録する）

「いつ、誰が、どのデータに、何をしたか」を記録するログは、問題発生時の原因調査だけでなく、抑止力としても機能する。ログが取られていないシステムでは、情報漏洩が起きても「いつ、どのデータが、どのルートで外に出たか」を特定できない。ログを取得する対象（ログイン・ログアウト・データ参照・変更・削除など）、保管期間、保管場所のセキュリティも要件として定義する。ログ自体を改ざんされないための保護も必要だ。

⑤定期的なバックアップと復旧テスト（バックアップがあっても戻せなければ意味がない）

バックアップが取られていても、復旧手順が確立されていなければ意味がない。「バックアップはあります」という開発会社の回答に安心しがちだが、「どの頻度で取得しているか」「どのくらいの時間で復旧できるか」「復旧テストを定期的に実施しているか」まで確認する必要がある。ランサムウェアによる暗号化被害では、バックアップも同じネットワーク上にあれば同時に被害を受ける。バックアップの保管場所と世代管理の仕組みも含めて要件化する。

⑥ソフトウェアのアップデート管理（古いバージョンのままはリスク）

システムを構成するOS、フレームワーク、ライブラリには、定期的にセキュリティ上の脆弱性が発見される。発見された脆弱性はパッチで修正されるが、アップデートを適用しないまま稼働し続けるシステムは、既知の攻撃手法に対して無防備な状態になる。開発会社との契約で、アップデート管理が保守の範囲内に含まれているかを確認する。含まれていない場合、誰が対応するかを明確にしないと、長期間放置されるリスクがある。

⑦アカウント管理（退職者のアカウントを即無効化できるか）

退職した社員のアカウントがシステムに残っている場合、元社員による不正アクセスのリスクが生じる。「すぐに無効化できる仕組みがあるか」「管理者が自分でアカウントを停止できるか」「定期的なアカウント棚卸しの仕組みがあるか」という点を確認する。人事システムや入退室管理との連携でアカウント管理を自動化できれば理想だが、最低限、管理者が数分以内にアカウントを無効化できる操作性が確保されていることが必要だ。

発注前にベンダーに確認すべき3つの問い

セキュリティ要件を要件定義に組み込むにあたって、開発会社に対して発注前に確認しておくべき問いがある。

一つ目は「脆弱性診断はいつ、誰が行いますか？」という問いだ。開発完了後に第三者による脆弱性診断を行うのか、開発プロセスの中に組み込まれているのか、診断費用は見積もりに含まれているのかを明確にする。診断なしで本番稼働しているシステムは、問題を「まだ発見されていないだけ」の状態で動いている。

二つ目は「セキュリティインシデントが起きた時の対応フローはどうなりますか？」という問いだ。問題が発生したときに、最初に誰に連絡するか、どのくらいの時間で初動対応が始まるか、費用はどう発生するか。保守契約の内容に含まれているか否かによって、インシデント発生時の対応速度が大きく変わる。

三つ目は「上記7項目はデフォルトで対応していますか？追加費用はかかりますか？」という直接的な問いだ。開発会社によって、標準仕様として含まれている項目とそうでない項目が異なる。見積もりの段階で確認しておかないと、後から「その対応は追加費用が必要です」という話になる。

セキュリティ要件をどう予算化するか

セキュリティ対策を「コスト」として捉えると削減の対象になりやすいが、「後付け対応コスト」と「最初から組み込むコスト」を比較すると、判断は変わる。開発段階でセキュリティ要件を組み込む費用は、プロジェクト全体の10〜20%程度が目安とされることが多い。一方、情報漏洩が発生した場合の対応コストは、調査・原因特定・再構築・通知・信頼回復のための費用を含めると、数百万円から数千万円に達することがある。

セキュリティ対策費を削ることは、問題が起きた時の損失をそのまま引き受けることと同義だ。発注側が「後からでも対応できる」と考えている間に、開発会社側は「言われていないから対応しない」で進む。この認識のずれが、稼働後に問題として表面化する。

予算の組み方としては、初期開発費用の中にセキュリティ要件を明示的に含め、保守費用にもアップデート管理と定期診断の費用を組み込む形が現実的だ。「セキュリティにいくらかけるか」ではなく「リスクをどこまで下げるか」という問いとして設計する。

よくある質問

Q: 小さな業務システムにもセキュリティ要件は必要ですか？

規模に関係なく必要だ。社員10人の会社の顧客データも、外部に流出すれば取引先への影響や信頼の失墜につながる。小規模なシステムであっても、認証・暗号化・バックアップの3点は最低限確保することが求められる。

Q: クラウドSaaSを使えばセキュリティは自動的に担保されますか？

SaaSのインフラ側は提供会社が管理しているが、アカウント管理・権限設定・データの取り扱いポリシーは利用側の責任だ。「クラウドだから安全」ではなく、誰がどのデータにアクセスできるかの設定を利用側で適切に管理する必要がある。

Q: セキュリティ診断はいくらくらいかかりますか？

規模や対象範囲によって異なるが、Webアプリケーションの診断であれば数十万円から数百万円の範囲が一般的だ。ツールによる自動診断は比較的安価だが、手動診断に比べて検出できる脆弱性の種類が限られる。目的と予算に応じた診断方法を選ぶことが重要になる。