Webシステムのセキュリティ対策｜脆弱性の基本

01はじめに｜この記事でわかること

要点：この記事は、Webシステムを発注する側・運用する側のための解説です。脆弱性の意味、狙われやすい種類、責任の分かれ方、公開前後にやること、事故が起きたときの手続きまでを、判断できる順番で並べています。

「セキュリティは大丈夫ですか」と制作会社に聞くと、たいてい「対策しています」と返ってきます。その一言で安心し、何をどこまでやったのか確かめないまま公開する。よくある入口です。

Webシステムのセキュリティ対策の記事は、攻撃の名前と技術的な話が並んでいるものが多く、発注する側には「で、自分は何をすればいいのか」がわかりません。この記事では、2000年創業のWeb制作・システム開発会社ZenWeb Japanが、Webシステム開発のご相談でお伝えしている順番でご説明します。

まずは代表的な脆弱性を短くつかめる解説動画をご紹介します。

02脆弱性とは何か｜「バグ」とどう違うのか

要点：脆弱性とは、設計や実装の不備のうち、悪用されると被害につながるものを指します。動作としては正常に見えるため、ふつうのテストでは見つかりません。ここがバグとの一番の違いです。

バグは「動かない」不具合です。ボタンを押しても保存されない、金額の計算が合わない。使っていれば気づきます。

脆弱性はそうではありません。画面は正しく動きます。ただ、想定しない使われ方をしたときに、本来見えないはずの情報が見えてしまう。だからシステムテストの工程で「正しく動くか」だけを見ていると、公開まで残ります。

• バグは使っていれば気づきます。報告が上がり、修正され、また使えるようになります。
• 脆弱性は使っていても気づきません。気づくのは、攻撃する側か、意識して探した人だけです。
• 影響の出方も違います。バグは業務が止まりますが、脆弱性は情報が外に出ます。止まったほうがまだ気づけます。

もうひとつ大事なのは、脆弱性が自社のコードだけの問題ではないことです。使っているフレームワークやサーバーのソフトウェアに、後から欠陥が見つかることもあります。作ったときは安全でも、時間が経てば危なくなる。セキュリティ対策を「一度やって終わり」にできない理由がここにあります。

03狙われやすい脆弱性6種類｜名前だけ覚えれば十分です

要点：発注する側は、仕組みまで覚える必要はありません。名前と「何が起きるか」だけ押さえて、開発会社に対策の有無を聞ければ十分です。代表的なものは6つに絞れます。

公的な整理では、IPA（情報処理推進機構）の「安全なウェブサイトの作り方」が定番です。そのうち、業務で使うWebシステムに関係の深いものを表にまとめました。

使いどころは右の列です。この6つを順に聞いて、答えが返ってこない項目があれば、そこが確認すべき場所になります。WordPressで作る場合は、WordPressのセキュリティ対策で個別にまとめています。

04攻撃されると何が起きるか｜被害は3つの形で出ます

要点：被害は「情報が出る」「システムが使えなくなる」「加害者になる」の3つに整理できます。金額の面でいちばん重いのは3つ目です。取引先や利用者に迷惑がかかると、信頼の回復に時間がかかります。

IPAの情報セキュリティ10大脅威 2026では、組織向けの1位がランサム攻撃による被害、2位がサプライチェーンや委託先を狙った攻撃でした。2位が示すのは、取引先へ入る通り道として狙われる形が定着しているということです。

• 情報が外に出る。会員管理システムのように個人情報を扱う仕組みでは、影響が利用者全員に及びます。
• システムが使えなくなる。データを暗号化されたり削除されたりして、業務が止まります。
• 加害者になる。自社のサーバーが踏み台にされ、他社への攻撃の送信元にされます。この形がいちばん厄介です。

被害の重さは、盗まれた情報の量ではなく、取引先にどれだけ説明が必要になるかで決まります。

05脆弱性はいつ見つかっているか｜発見までの日数

要点：脆弱性が見つかるきっかけは、定期診断・メンテナンス中の点検・外部からの指摘・監視アラート・実害の5つです。実害で気づいた場合は、公開から平均340日が経っていました。気づくのが遅いほど、調べる範囲も広がります。

見てほしいのは、上の3つと下の2つの差です。自分たちの仕組みで見つけた場合は、公開から4か月以内に収まります。外から指摘された場合と実害で気づいた場合は、そこから一気に伸びます。

実害での発見が12%残っている点も見てください。システムの保守・運用費用を削るとき、最初に外されるのが監視と定期点検です。

06対策は「誰の責任か」で分けて考える

要点：セキュリティの責任は、開発会社・サーバー会社・自社の3者に分かれます。事故の多くは、この3つのすき間で起きます。どこが誰の担当かを一枚の表にして、契約書に紐づけてください。

この記事でいちばんお伝えしたいところです。技術的な対策よりも、責任の線引きのほうが事故に直結します。

「メンテナンス契約しだい」の行が要注意です。請負と準委任の違いを押さえたうえで、メンテナンスの範囲に何が入っているかを一項目ずつ確かめてください。運用が始まってから「それは範囲外です」と言われるのが、いちばん困ります。

07実際に手が回っていない対策はどれか

要点：通信の暗号化はほぼすべてのシステムで済んでいます。一方で、操作ログの保存とバックアップからの復旧確認は、公開1年後でも半数前後が手つかずでした。目立たない項目ほど後回しになります。

実施率の低い3つには共通点があります。やらなくても画面は動く、という点です。だから見積りの調整局面で真っ先に削られます。

ただ、事故のときに効果的なのはまさにこの3つです。ログがなければ、何が持ち出されたのかを説明できません。Webシステム開発のご相談では、この3項目を最初に確認しています。

08開発の段階でやっておく5項目

要点：開発中にやるべきことは、入力値の扱い、権限の設計、ログの設計、通信の暗号化、テスト工程での確認の5つです。どれも後から足すと費用がかさむため、要件定義の段階で決めておいてください。

• 入力値を必ず点検する。利用者が入れた文字を、そのままデータベースや画面に渡さない。これだけで大半は防げます。
• 権限を先に設計する。誰がどの画面とデータを見られるかを、機能一覧と一緒に決めます。後から足すと抜けが出ます。
• ログの項目を決めておく。誰が・いつ・何をしたかを残します。保存期間も先に決めてください。
• 通信をすべて暗号化する。公開部分だけでなく、管理画面も社内向け画面も含めます。
• テスト工程に確認を入れる。権限のない操作がきちんと弾かれるかも試します。

この5つは、要件定義の進め方の段階で決まっていれば、追加費用はほとんど発生しません。逆に、公開後に「ログを残したい」と言うと、既存機能の作り直しが必要になります。

09公開したあとに続ける5項目

要点：公開後は、ソフトウェアの更新、IDの棚卸し、バックアップの復旧テスト、監視、脆弱性情報の確認の5つを回します。頻度を決めて担当者を割り当てるところまでが、運用の設計です。

IDの棚卸しだけは自社の仕事です。退職者や異動者のIDは、人事情報を持っている側でないと判断できません。WordPressの保守のように更新を任せていても、この一項目は手元に残ります。

10気づくのが遅れると費用はどう変わるか

要点：同じ脆弱性でも、気づく時期が遅いほど費用は膨らみます。開発中なら修正だけで済みますが、実害が出たあとは調査・報告・通知が加わります。金額の差は作業量ではなく、付随する対応から生まれます。

3行目と4行目の差を見てください。修正そのものの作業量は、実はあまり変わりません。増えているのは、調べる・報告する・お知らせする部分です。

社内向けだから大丈夫とも言い切れません。在庫管理システムでも、外部から接続できる形なら同じ対応が必要です。

11脆弱性診断は必要か｜種類と費用の考え方

要点：個人情報や決済を扱うシステムなら、公開前に一度は診断を受けてください。診断はツールによる自動診断と、技術者が手を動かす手動診断に分かれます。まずは自動診断から始めるのが現実的です。

• ツール診断。公開されている手口を機械的に試します。費用を抑えられ、公開前の一次確認に向いています。
• 手動診断。技術者が業務の流れを理解して試します。権限のすり抜けなど、ツールでは拾えない問題が見つかります。
• 組み合わせが現実的です。公開前にツール診断、情報が重い部分だけ手動、という分け方がよく使われます。

判断の目安は、扱っている情報です。氏名と連絡先だけの社内システムと、決済情報を扱う仕組みでは必要な深さが変わります。Webシステム開発のご相談では、扱う情報を洗い出してから範囲を決めています。

12相談のタイミングはこの5年で変わった

要点：セキュリティのご相談は、事故が起きたあとから、公開前の要件相談へと移ってきました。2021年に22%だった事故後の相談は、2026年には6%まで下がっています。前もって備える形が広がっています。

変化は2つあります。公開前の要件相談が22%から38%へ増えたこと。そして診断の依頼が15%から27%へ増えたことです。どちらも、公開してから考える形から、設計の段階で決める形への移り方を示しています。

背景には取引先からの要求もあります。大手との取引でセキュリティ対策の実施状況をチェックシートで求められ、そこで初めて自社の状態を確認する。会員管理システムの開発では、この確認が発注の条件になることもあります。

13情報が漏れたら何をするのか｜報告の義務

要点：個人データの漏えいが起きた場合、条件に当てはまると個人情報保護委員会への報告と本人への通知が必要になります。速報はおおむね3〜5日以内です。この期限があるため、日ごろの記録が効いてきます。

ここは法律で決まっています。個人情報保護委員会の漏えい等報告・本人への通知の義務化についてによると、2022年4月1日から、個人の権利利益を害するおそれがあるときは報告と通知が必要です。

報告の対象になるのは、次の4つの事態です。

1. 要配慮個人情報が含まれる事態。健康や信条に関する情報の場合です。
2. 財産的被害が生じるおそれがある事態。クレジットカード情報などです。
3. 不正の目的をもって行われた漏えい等。外部からの攻撃はここに入ります。
4. 1,000人を超える漏えい等。件数で判断される区分です。

同じページでは、速報を「速やか（概ね3〜5日以内）」に行うこととされています。この数日で、何が起きたのか、どこまで及ぶのかを説明しなければなりません。第7章で挙げた操作ログの保存が効いてくるのが、まさにこの場面です。

14発注時にセキュリティ要件を書く5つの手順

要点：「セキュリティに配慮すること」とだけ書いても、見積りには反映されません。扱う情報を洗い出し、参照する基準を指定し、担当を割り振り、確認方法を決め、契約書に紐づける。この5段階で具体化します。

セキュリティ要件を要件定義書に落とし込む手順

下の5段階で進めると、要件が見積りの項目として扱われます。順番に意味があるため、上から進めてください。

1. 扱う情報を洗い出す。氏名、連絡先、決済情報などシステムに入る情報を一覧にします。ここで重さが決まります。
2. 参照する基準を指定する。「IPAの安全なウェブサイトの作り方に沿って実装すること」のように文書名を書きます。
3. 担当を割り振る。第6章の表を使い、6つの領域に担当者を書き込みます。空欄を残さないでください。
4. 確認方法を決める。診断を行うのか、チェックリストで確認するのか、誰が合格を判定するのかを決めます。
5. 契約書に紐づける。ここまでの内容を、メンテナンス契約の範囲と対応時間の条項につなげます。

画面と機能を並べるワイヤーフレームの段階で権限とログの扱いも書き込んでおくと、この5段階がぐっと楽になります。契約の形は、請負と準委任の使い分けとあわせて決めてください。

15よくある失敗｜「入れたから安心」で止まる

要点：いちばん多い失敗は、WAFなどの製品を導入した時点で満足してしまうことです。製品は攻撃の一部を止めますが、権限設計の不備や退職者のIDまでは面倒を見ません。道具と運用は別の話です。

WAFはWebアプリケーションを守る仕組みで、知られた攻撃パターンを遮ります。入れる価値はあります。ただ、そこで安心して止まる例が本当に多いのです。

• 権限の抜けは止められません。正しいIDでログインした人が、本来見えない画面を開けてしまう。正常な通信なので遮断されません。
• 退職者のIDも止められません。そのIDが有効である限り、通信としては正しいものです。
• 更新の遅れも埋められません。古いソフトの穴を一時的にふさげても、根本の修正にはなりません。

もうひとつは、公開時に一度だけ診断を受けて数年が過ぎるパターンです。機能を追加すれば、そのたびに新しい入口ができます。システム開発の見積書のどこに継続的な確認が入っているかも見てください。

16まとめ｜まず確認する3点

要点：今日から確認できるのは、責任の線引き、ログの保存、バックアップからの復旧確認の3点です。この3つが埋まっていれば、事故が起きても説明と復旧ができます。

1. 責任の線引きを表にする。6つの領域それぞれに担当者の名前が入っているか確かめます。
2. ログが残っているか確認する。誰が・いつ・何をしたかを、実際に画面で見られるか試してください。
3. バックアップから戻せるか試す。取得と復旧は別です。年に一度は実際に戻してみてください。

技術的な対策は開発会社に任せられます。ただ、この3点は発注する側でないと決められません。Webシステム開発のご相談でも、この3点から確認しています。

17よくある質問

1. 小規模なシステムでもセキュリティ対策は必要ですか？

必要です。攻撃の多くは相手を選ばず、機械的に探して回っています。規模が小さいから見つからない、ということはありません。ただ、セキュリティ対策の深さは扱う情報にあわせて決められます。個人情報を持たない仕組みなら、更新とID管理を回すだけでも効果があります。

2. 脆弱性診断は毎年受けるべきですか？

機能の追加があった年は受けてください。追加した部分が新しい入口になるためです。変更がない年は、ツールによる自動診断だけでも構いません。基準は年数ではなく、変更が入ったかどうかです。

3. 開発会社に任せておけば安心ではないのですか？

プログラムの部分は任せられますが、全部は任せられません。IDと権限の管理は、人事情報を持っている側でないと判断できないためです。契約書で担当が決まっていない項目は、誰の仕事にもなりません。まずは責任の線引きを表にしてください。

4. メンテナンス契約にセキュリティ対応は含まれていますか？

契約によって異なります。監視だけの契約もあれば、更新作業まで含む契約もあります。確認すべきは、ソフトウェアの更新、脆弱性情報の確認、事故時の一次対応の3つです。入っていなければ、誰がやるのかを別途決めてください。

5. 情報が漏れたら必ず報告しなければいけませんか？

条件に当てはまる場合に必要です。個人情報保護委員会は、要配慮個人情報が含まれる事態、財産的被害のおそれがある事態、不正の目的をもって行われた漏えい等、1,000人を超える漏えい等の4つを挙げています。外部からの攻撃は3つ目に当たるため、件数が少なくても報告の対象です。