ホームページの発注側も知っておきたい ── IPA「安全なウェブサイトの作り方」をチェックリストとして使う

「うちのホームページ、セキュリティは大丈夫?」と聞かれて、根拠を持って「大丈夫」と答えられる会社は多くありません。

制作会社に任せているから大丈夫、会社案内だけのサイトだから狙われない、と思われがちですが、問い合わせフォームが1つあれば入力値を処理するプログラムが動いていますし、WordPressのようなCMSを使っていれば管理画面もプラグインも攻撃対象です。しかも攻撃の多くは会社を狙い撃ちにするのではなく、弱いサイトを機械的に探し出して行われます。

では、何を基準に「大丈夫」を確認すればよいのか。その基準として長く使われてきた公的資料が、IPA(独立行政法人情報処理推進機構)の安全なウェブサイトの作り方です。

この記事では、この資料が何を教えてくれるのかを、Webサイトを発注する側・運営する側にも分かる言葉で整理します。

1．まず結論

• 「安全なウェブサイトの作り方」は、IPAに実際に届出のあった脆弱性をもとに、ウェブサイトの弱点11種類と対策をまとめた資料。開発者だけでなく、発注・検収の基準としても使える
• 対策は「根本的解決」(原因を取り除く)と「保険的対策」(被害を軽減する)に分かれる。基本は根本的解決で、保険的対策はその上乗せ
• 付属の「セキュリティ実装チェックリスト」は、制作会社への発注時・検収時の確認項目としてそのまま使える
• 別冊「ウェブ健康診断仕様」は、運用中のサイトを定期点検するときの診断項目の基準になる
• 会社サイトの実務では、フォームなど入力を受け付ける部分と、CMS(WordPressなど)の運用が2大リスク。「作って終わり」にしない運用体制まで含めて発注時に決めておく

2．「安全なウェブサイトの作り方」とは

「安全なウェブサイトの作り方」は、IPAが届出を受けた脆弱性関連情報のうち、届出件数が多かった脆弱性や、攻撃された場合の影響が大きい脆弱性を取り上げ、ウェブサイトの開発者や運営者向けに対策をまとめた資料です。最新版は2021年3月公開の改訂第7版で、全115ページ。PDFのほか、脆弱性ごとのHTMLページも公開されています。

構成は3章立てです。

さらに、本編とは別に次の資料が公開されています。

• セキュリティ実装チェックリスト(Excel形式): 本編の対策を実装したかを確認する一覧表
• 別冊「安全なSQLの呼び出し方」: データベースまわりの脆弱性対策を深掘りした資料
• 別冊「ウェブ健康診断仕様」: 稼働中のサイトを診断するための13の診断項目をまとめた仕様

いずれもIPAのページから無償でダウンロードできます。

3．11の脆弱性を「何が起きるか」で読む

第1章が取り上げる11種類の脆弱性は、開発者向けの用語で並んでいますが、「放置すると自社のサイトで何が起きるか」に置き換えると、発注側にも他人事ではないことが分かります。

たとえば「メールヘッダ・インジェクション」は、会社案内サイトの問い合わせフォームがそのまま該当します。対策の甘いフォームは迷惑メールの発信元として悪用され、会社のドメインの信用(メールが相手に届くかどうか)まで傷つけます。フォームからのメールが届かなくなる問題は問い合わせフォームのメールが届かない原因で扱ったとおり、ビジネス機会の損失に直結します。

4．「根本的解決」と「保険的対策」── 対策の考え方

この資料の優れた点は、対策を2種類に分けて示していることです。

• 根本的解決: 脆弱性の原因そのものを取り除く実装。たとえばSQLインジェクションなら、SQL文の組み立てを文字列連結ではなくプレースホルダで行う
• 保険的対策: 脆弱性が残ってしまった場合に、攻撃の成功率や被害を下げる対策。たとえばエラーメッセージをそのままブラウザに表示しない

この分類は、発注側がセキュリティの説明を受けるときの物差しになります。「WAF(攻撃を検知・遮断する仕組み)を入れるので安心です」という説明は保険的対策の話であって、アプリケーション自体の根本的解決の代わりにはなりません。逆に、根本的解決を実装したうえでWAFを重ねるのは理にかなった構成です。どちらの層の話をしているのかを区別して聞くだけで、提案の妥当性がかなり見えるようになります。

5．発注・検収でどう使うか

「安全なウェブサイトの作り方」は開発者向けの資料ですが、発注側にとっての実用性は、要求と確認の基準に使えることです。

• 見積もり・要件の段階: 仕様書やRFPに「IPA『安全なウェブサイトの作り方』が挙げる脆弱性への対策を実装すること」と一文入れる。基準を名指しすることで、「セキュリティに配慮する」という曖昧な表現より要求が明確になる
• 検収の段階: セキュリティ実装チェックリストの該当項目について、確認結果の提出を求める
• 契約の段階: 公開後にCMS・プラグイン・サーバーの更新を誰が行うのか、脆弱性が見つかった場合の対応は保守契約の範囲か個別見積もりかを、文書で線引きする

3点目は特に重要です。Webサイトのセキュリティは作った時点で完成ではなく、公開後に見つかる新しい脆弱性への追従で維持されます。この「誰が面倒を見続けるのか」は、受託開発・運用保守の契約の記事で整理した保守範囲の話と同じ構図です。

6．運用中のサイトは「健康診断」する

すでに公開しているサイトについては、別冊の「ウェブ健康診断仕様」が役立ちます。これは、稼働中のウェブサイトに対して安全性を点検するための診断項目(13項目)をまとめた仕様で、脆弱性診断サービスを利用するときの内容の目安にもなります。

中小企業の会社サイトで、実務上とくにリスクが集中しやすいのは次の2か所です。

• 入力を受け付ける部分: 問い合わせフォーム、検索窓、会員ログインなど。第1章の脆弱性の多くはここに関係する
• CMSの運用: WordPressなどの本体・テーマ・プラグインの更新が止まっているサイトは、既知の弱点を突かれて改ざんされる典型パターン。更新が誰の仕事か決まっていないまま放置されているケースが非常に多い

CMSの更新負担を運用体制ごと見直したい場合は、WordPressからの移行を扱った記事も参考になります。また、そもそも動的な処理を減らした静的サイト構成にすることで、攻撃対象面そのものを小さくするという設計判断もあります。当社がサイト制作でデジタル庁デザインシステムを土台にした静的構成を採用しているのも、この考え方の延長です。

なお、Webサイトの安全な運用は、IPAの「中小企業の情報セキュリティ対策ガイドライン」第4.0版の自社診断でも確認項目として挙げられています。会社全体のセキュリティ対策の中での位置づけは、ガイドライン第4.0版の解説記事をご覧ください。

まとめ

IPA「安全なウェブサイトの作り方」のポイントを整理します。

• 実際にIPAへ届出のあった脆弱性に基づく、ウェブサイトの弱点11種類と対策の定番資料(改訂第7版・全115ページ)
• 対策は根本的解決と保険的対策の2層。WAFなどの保険的対策は根本的解決の代わりにならない
• 発注側は、要件に資料名を明記し、チェックリストで検収し、公開後の更新体制を契約で決める、という使い方ができる
• 運用中のサイトは「ウェブ健康診断仕様」を目安に定期点検する
• 会社サイトの現実的なリスクは、フォームなどの入力処理とCMSの放置に集中しやすい

セキュリティは「専門家に言われるままに費用をかける」か「何もしない」かの二択になりがちですが、公的な基準を知っているだけで、要求も確認も自分の言葉でできるようになります。

ホームページの制作・リニューアルをご検討の方へ

合同会社小村ソフトでは、ホームページの制作・リニューアルの際、この記事で紹介した考え方に沿って、フォームまわりの実装、CMSに依存しすぎない静的構成、公開後の更新体制までを含めてご提案しています。「今のサイトがどうなっているか分からない」という段階の現状確認からご相談いただけます。

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

「安全なウェブサイトの作り方」はどんな資料ですか？

IPA(独立行政法人情報処理推進機構)が公開している、ウェブサイト開発者・運営者向けのセキュリティ資料です。IPAに届出のあった脆弱性関連情報のうち、届出件数が多かったものや影響度の大きいものを取り上げ、脅威と対策を解説しています。最新の改訂第7版は2021年3月公開で、全115ページ。本編のほか、セキュリティ実装チェックリスト、別冊「安全なSQLの呼び出し方」「ウェブ健康診断仕様」が無償で公開されています。

会社案内程度のホームページでも、セキュリティ対策は必要ですか？

必要です。問い合わせフォームがあれば入力値を処理するプログラムが動いていますし、WordPressなどのCMSを使っていれば管理画面やプラグインが攻撃対象になります。攻撃者は会社の規模を選んで攻撃するとは限らず、脆弱なサイトを機械的に探して、改ざんやウイルス配布の踏み台、迷惑メールの送信元として悪用します。被害者であると同時に、取引先や訪問者への加害側になってしまうのがWebサイトの怖さです。

根本的解決と保険的対策の違いは何ですか？

「安全なウェブサイトの作り方」では、対策を2種類に分けて示しています。根本的解決は、脆弱性の原因そのものを取り除く実装方法(例:SQL文の組み立てにプレースホルダを使う)です。保険的対策は、脆弱性が残ってしまった場合に攻撃の成功率や被害を下げる対策(例:エラーメッセージをそのまま表示しない)です。保険的対策だけでは原因が残るため、根本的解決を基本とし、保険的対策を上乗せするのが正しい順番です。

制作会社に発注するとき、セキュリティについて何を確認すればよいですか？

少なくとも、①「安全なウェブサイトの作り方」が挙げる脆弱性への対策を実装しているか、②付属のセキュリティ実装チェックリストなどで確認結果を示せるか、③公開後にCMSやプラグインの更新を誰が行うのか(運用・保守の契約範囲)、の3点を見積もり段階で確認することをおすすめします。セキュリティ要件は後から追加すると手戻りが大きいため、契約前に文書で確認しておくことが重要です。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。