技術
システム開発のセキュリティ対策|発注側が知っておくべき基本と確認ポイント
システム開発では、機能だけでなくセキュリティ対策が欠かせません。情報漏えいや不正アクセスは、事業に深刻な打撃を与えます。とはいえ「専門的すぎて、何を確認すればいいのか分からない」という声も多いはずです。この記事では、発注側が知っておくべきセキュリティの基本、代表的な脅威、必要な対策を1つずつ、そして開発会社に確認すべきポイントや費用感まで、専門知識がなくてもわかるように整理します。
なぜセキュリティ対策が重要なのか
情報漏えいや不正アクセスが起きると、顧客の信頼を失い、損害賠償や事業停止につながることがあります。特に個人情報や決済を扱うシステムでは必須です。
見落とされがちですが、セキュリティは「作った後に足す」ものではありません。家に例えるなら、防犯対策は間取りを決める段階から考えるもので、完成後に頑丈な壁を後付けするのは難しいのと同じです。設計・開発の段階から組み込むことで、無理なく・安く・確実に守れます。
被害が起きたときのコストは、対策コストよりはるかに大きくなりがちです。目安として、次のような負担が一度に発生します。
- 直接的な損害:復旧作業、原因調査(フォレンジック)の外注費。
- 賠償・補償:被害者への謝罪対応、見舞金、損害賠償。
- 信用の失墜:取引停止、解約、新規獲得の停滞。
- 事業の停止:システム停止中の売上機会の損失。
「起きてから対応する」より「起きないように設計する」ほうが、結果的に安く済みます。
よくある脅威 — 不正アクセス・情報漏えい・改ざん
まず、どんな脅威があるのかを知っておくと、対策の意味が理解しやすくなります。代表的なものは次の3つです。
| 脅威 | どんなことが起きるか | 主な入口 |
|---|---|---|
| 不正アクセス | 他人がIDを乗っ取り、管理画面や顧客データに侵入 | 弱いパスワード・使い回し・認証の甘さ |
| 情報漏えい | 顧客情報・決済情報・個人情報が外部に流出 | 通信の盗聴・データの平文保存・権限の不備 |
| 改ざん | サイトの内容やデータを勝手に書き換えられる | 脆弱性の放置・古いソフトの利用 |
このほか、大量アクセスでサービスを止める攻撃(DDoS)、入力欄から不正な命令を送り込む攻撃(SQLインジェクションなど)もよく知られています。難しい名前ですが、要は「入口をふさぐ」「中身を暗号化する」「異常に気づく」の3方向で守るのが基本です。
注意したいのは、攻撃の多くが特定の企業を狙い撃ちにするものではないという点です。「うちは小さいから狙われない」という思い込みは危険で、実際にはインターネット上を機械的に巡回し、弱点のあるサイトを片っ端から突く攻撃が大半です。規模に関係なく、穴があれば入られる——これが前提です。
対策を怠るとどうなるか(一般化した例)
抽象的な話だけではイメージしにくいので、よくある失敗のパターンを一般化した例で示します(いずれも架空のケースです)。
- 例:顧客名簿を平文で保存していたケース。 管理画面のパスワードが破られ、暗号化していなかった顧客情報がそのまま流出。謝罪と補償対応に追われ、通常業務が数週間止まった。暗号化していれば、漏れても中身は読めなかった。
- 例:権限を分けていなかったケース。 アルバイトを含む全員が管理者権限を持っていたため、退職者のアカウント経由でデータを削除された。役割ごとに権限を絞り、退職時にアカウントを止めていれば防げた。
- 例:脆弱性診断を省いたケース。 「安く早く」を優先して公開前チェックを飛ばした結果、問い合わせフォームから不正な操作をされ、サイトを改ざんされた。公開前の診断1回で見つけられた穴だった。
共通するのは、どれも特別な攻撃ではなく、基本対策の抜けを突かれたという点です。逆に言えば、基本を押さえるだけで多くの被害は防げます。派手な最新技術より、当たり前の積み重ねが効く世界です。
必要な対策を1つずつ理解する
「セキュリティ対策」とひとくくりにされがちですが、中身は複数の対策の組み合わせです。発注側がすべてを実装する必要はありませんが、それぞれが何のためのものかを知っておくと、会社の説明が理解でき、抜けにも気づけます。
1. 認証・パスワード
「本人かどうか」を確かめる仕組みです。ログイン時のパスワードに加え、スマホのコードを併用する**二段階認証(多要素認証)**があると、パスワードが漏れても侵入されにくくなります。管理画面など重要な入口には特に有効です。
2. 通信の暗号化(SSL/TLS)
利用者とシステムの間でやり取りされるデータを暗号化し、途中で盗み見されても読めないようにします。URLが「https」で始まり、鍵マークが付いているのがその証です。今はほぼ必須で、無い時点で信頼性に関わります。
3. 脆弱性対策
ソフトウェアの「穴(弱点)」を突かれないようにする対策です。使用する部品(ライブラリ)を最新に保ち、開発中・公開前に脆弱性診断でチェックします。新しい穴は日々見つかるため、公開後も継続的な対応が要ります。
4. アクセス制御・権限管理
「誰が・どこまで操作できるか」を役割ごとに分ける仕組みです。全員が管理者権限を持つのは危険で、担当者は自分の業務に必要な範囲だけ触れるようにします。退職者のアカウントを速やかに止める運用も含みます。
5. データの暗号化・バックアップ
顧客情報やパスワードは、そのままではなく暗号化して保存します(万一漏れても中身を読めなくする)。あわせて、障害や攻撃に備えて定期的なバックアップを取り、復旧できる状態にしておきます。「バックアップがなく復旧できない」は最悪の事態です。
6. ログ監視
「いつ・誰が・何をしたか」の記録(ログ)を残し、異常なアクセスに気づけるようにします。事故が起きた際の原因究明にも不可欠です。記録を取るだけでなく、おかしな動きを検知して知らせる仕組みまであると安心です。
7. 不正対策
問い合わせフォームや決済まわりでの、いたずら・なりすまし・スパムを防ぐ対策です。入力チェック、送信回数の制限、決済代行サービスの利用などで、悪用されにくくします。
これらは単体ではなく、重ねて効果を発揮します。1つの対策が破られても次で止める「多層防御」が基本の考え方です。玄関に鍵をかけても、窓が開いていれば意味がないのと同じで、どこか一箇所でも抜けていると全体の安全性が下がってしまいます。予算の都合で一部を省くときも、「どのリスクを受け入れることになるか」を開発会社と確認してから決めるのが安全です。
発注時に開発会社へ確認すべきこと
専門知識がなくても、次を質問できれば十分です。答え方そのものが、その会社の姿勢を映します。
- どんなセキュリティ対策をするか:具体名(SSL・二段階認証・脆弱性診断など)で説明できるか。
- 個人情報・決済をどう守るか:扱うデータに応じた対策があるか。決済は自前で持たず代行サービスを使うか。
- 脆弱性診断・テストは含まれるか:見積りに入っているか、別料金か。
- 公開後の対応はどうなるか:脆弱性が見つかったときの修正体制・費用は。
- 権限やログの設計はあるか:管理者と一般利用者を分けているか。
セキュリティの話を避ける・専門用語ではぐらかす・「大丈夫です」だけで具体が出ない会社は要注意です。逆に、良い会社ほど「扱うデータは何か」を先に聞き、それに見合った対策を提案してくれます。むやみに高価な対策を積むのでも、丸ごと省くのでもなく、リスクに応じて過不足なく選べるかが分かれ目です。会社選びの視点は悪い開発会社の見分け方もご覧ください。
なお、見積りに「セキュリティ」の項目がまったく無い場合、対策が省かれている可能性があります。安さの理由がテスト省略にあると、後で大きな損害につながります(→安いシステム開発のリスク)。
個人情報保護法など、守るべきルール
顧客情報を扱う以上、法律への対応も欠かせません。難しく考えず、**「個人情報を集めるなら、目的を伝え、安全に管理し、勝手に使わない」**が基本と押さえておけば十分です。
- 個人情報保護法:氏名・連絡先・購入履歴などを扱う事業者が対象。利用目的の明示、適切な管理(安全管理措置)、漏えい時の報告義務などが定められています。
- プライバシーポリシーの整備:何を・何のために集め、どう扱うかをサイトに明記します。
- 決済まわりの基準:クレジットカード情報を扱う場合は専用の基準(PCI DSS)があり、通常は決済代行サービスに任せて自社で情報を持たない形が安全です。
システムの作り自体が、これらの要件(暗号化・アクセス制御・ログ)を満たしている必要があります。発注時に「個人情報保護法に対応した作りにしてほしい」と一言伝えておくとよいでしょう。
万一、漏えいが起きてしまった場合の流れも知っておくと安心です。おおまかには「①被害の範囲を調べて止める → ②個人情報保護委員会へ報告 → ③対象となった本人へ通知 → ④原因を調べて再発を防ぐ」という順で対応します。一定の漏えいは報告・通知が法律上の義務とされているため、「気づいたが黙っていた」は通用しません。だからこそ、そもそも漏らさない作りと、異常に早く気づけるログ・監視が重要になります。
中小企業が最低限やるべきこと
「大企業のような対策は無理」と感じるかもしれませんが、土台の数項目を押さえるだけでもリスクは大きく下がります。まずここから始めましょう。
- 全ページSSL化(httpsにする)。
- 管理画面に二段階認証を付ける。
- パスワードの使い回しを禁止し、推測されにくいものにする。
- 重要データは暗号化して保存+定期バックアップ。
- 権限を役割ごとに分ける(全員管理者にしない)。
- 使っているソフト・部品を最新に保つ。
- 公開前に脆弱性診断を1回は実施する。
一度に全部でなくても構いません。「入口(認証)」「経路(通信)」「保管(データ)」の3か所から手を付けると、費用対効果が高くなります。あわせて、これらの対策や公開後の保守範囲を契約書に明記しておくと、「言った・言わない」のトラブルを避けられます(→システム開発の契約で確認すべきこと)。
セキュリティ対策の費用感と、公開後の保守
「別途、高額な費用がかかるのでは」と心配されますが、基本的な対策の多くは、まっとうな開発なら標準工程に含まれるものです。目安として次のように考えられます。
| 対策 | 費用の目安 |
|---|---|
| SSL化・基本的な認証・権限設計 | 通常は開発費に含まれる |
| 二段階認証・暗号化などの追加実装 | 数万〜数十万円が目安(範囲による) |
| 公開前の脆弱性診断 | 数万〜数十万円が目安(規模による) |
| 公開後の監視・アップデート保守 | 月額の保守契約に含めるのが一般的 |
金額は規模や要件で幅がありますが、「後から穴を塞ぐ」より「最初から作り込む」ほうが安いのは共通しています。D-oneApp は総額を着手前に確定する料金体系のため、「後から想定外のセキュリティ費用が積み増される」心配がなく、必要な対策を含めた形で見積りを提示します。
公開後の保守・アップデートとの関係
セキュリティは「作って終わり」ではありません。公開後こそ本番です。ソフトの新しい弱点は日々見つかるため、放置すると時間とともに危険度が上がっていきます。
- アップデート:使用中の部品に脆弱性が見つかったら、修正版へ更新する。
- 監視:異常なアクセスやエラーに気づける状態を保つ。
- バックアップの確認:いざというとき本当に復旧できるか、定期的に確かめる。
これらは月額の保守契約でカバーするのが一般的です。開発費だけを見て「保守は不要」と切ると、数年後に脆弱性を抱えたまま動き続けることになります。発注時に保守の範囲と費用まで含めて確認しておきましょう。
例:小さなECサイトのケース。 公開時はきちんと対策していても、1年間アップデートを止めていたために、使用していた決済プラグインの古い脆弱性を突かれてしまう——こうした事故は、月々の保守で最新に保っていれば防げたはずのものです。派手な攻撃より、「更新を止めた放置」が原因の被害のほうが実は多いのです。
発注側と開発会社、どちらの責任か
事故を防ぐには、「作りの安全」と「使い方の安全」の両方が必要です。片方を相手任せにすると穴ができます。おおまかな役割分担は次のとおりです。
| 守る対象 | 主に担う側 | 具体例 |
|---|---|---|
| システムの作り | 開発会社 | 暗号化・脆弱性対策・権限やログの設計 |
| 公開後の維持 | 双方(保守契約) | アップデート・監視・バックアップ確認 |
| 日々の使い方 | 発注側(利用側) | パスワード管理・退職者アカウントの停止・不審メールへの注意 |
どんなに堅牢に作っても、管理者パスワードを付箋に書いて貼っていては意味がありません。逆に、利用側が気をつけていても、作りに穴があれば守れません。**「作りは開発会社、運用は自社」**という前提で、契約時に責任範囲を確認しておくと、後々のトラブルを避けられます。
外部のサービス(決済代行やクラウド)を組み合わせる場合は、「どこまでがそのサービスの責任で、どこからが自社の責任か」も整理しておきましょう。特に決済情報は、自社で持たずに専用サービスへ任せるのが安全かつ現実的です。
発注前チェックリスト
最後に、発注前に確認したい項目をまとめます。すべて「はい」に近いほど安心です。
- 全ページがSSL(https)で暗号化されているか
- 管理画面に二段階認証など、認証強化の仕組みがあるか
- 顧客情報・パスワードは暗号化して保存されるか
- 定期バックアップと、復旧手順が用意されているか
- 権限が役割ごとに分かれているか
- 公開前の脆弱性診断・テストが見積りに含まれるか
- 個人情報保護法に対応した作り・運用になっているか
- 公開後のアップデート・監視(保守)の範囲と費用が明確か
- セキュリティについて、具体名で説明してくれるか
まとめ
セキュリティ対策は、機能と同じくらい重要で、設計段階から組み込むものです。中身は認証・通信暗号化・脆弱性対策・権限管理・データ暗号化とバックアップ・ログ監視・不正対策の組み合わせで、これらを重ねて守ります。
発注側は、すべてを理解する必要はありません。「どんな対策をするか」「データをどう守るか」「公開後の保守はどうか」を、具体名で説明してもらえるかを確認できれば十分です。安さのために対策やテストが省かれていないか、そして最初から作り込まれているかに注意しましょう。セキュリティを含めた進め方は、無料相談でもご説明します。
よくある質問
Qシステム開発でセキュリティ対策はなぜ重要ですか?
情報漏えいや不正アクセスが起きると、顧客の信頼を失い、損害賠償や事業停止につながることがあります。特に個人情報や決済を扱うシステムでは必須です。「作った後」ではなく、設計・開発の段階から組み込むことが大切です。
Q発注側もセキュリティの専門知識が必要ですか?
詳細な専門知識は不要です。ただし「どんな対策をしてくれるのか」「個人情報や決済をどう守るのか」を開発会社に確認できると安心です。セキュリティの話を避ける・説明できない会社は注意が必要です。
Q基本的なセキュリティ対策には何がありますか?
通信の暗号化(SSL)、不正アクセス対策、脆弱性への対応、適切な権限管理、データのバックアップなどが基本です。これらが標準で含まれているかを確認しましょう。
Q安い開発だとセキュリティが不安です。
安さの理由がセキュリティやテストの省略にある場合、後で大きな損害につながることがあります。総額が固定される料金体系で、セキュリティ対策が標準で含まれているかを確認するのが安全です。