メインコンテンツへスキップ
BilgeQor

セキュリティサービス

WordPressとPHPのWebサイトハードニング解説

6分で読めます

Webサイトのハードニングとは、稼働中のWebサイトやWebアプリケーションの設定や保護設定を改善し、避けられるはずの露出を減らす実践的な作業です。合意した領域で避けられる露出を減らし、サイトの継続的な管理と並行して機能するよう設計されています。初期設定のまま、古いプラグイン、古いPHPバージョン、ホスティング体制の変更、急いだ公開判断などによって積み重なった、WordPress、PHP、その他のWebサイトによくある弱点に集中して対処する方法です。その結果、何を変更したか、何がスコープ外のまま残っているか、担当チームが何を監視すべきかについて判断を記録した、より明確で意図的な設定が得られます。

何であるのか

Webサイトのハードニングでは、公開サイトやアプリケーションに関わる合意済みの技術設定を確認し、改善します。スコープは書面で確定し、HTTPセキュリティヘッダー、TLSとCookieの設定、認証関連の管理策、サーバーやプラットフォームの設定、公開されている管理画面へのルート、外部スクリプト、基本的な更新体制などを対象にできます。目的は、合意した範囲全体で、よくある避けられる露出経路を減らし、各所見を証跡で裏付けることです。確定したアクセス権の範囲内で、当社チームが合意した変更を適用し、各変更を書面の変更前後記録に残します。貴社の開発者、ホスティング事業者、CDN事業者による対応が必要な項目は、それぞれに向けて文書化します。責任範囲は作業開始前に確定します。ハードニングが特に有効なのは、サイトが評価できる程度に安定しており、関係する担当者が意図した動作を確認でき、変更をリリース前後にテストする明確な方法がある場合です。

誰のために

Webサイトのハードニングは、次のような企業に適しています。

  • 顧客向けのフォーム、アカウント、決済など、事業上重要な機能を持つ公開Webサイトやアプリケーションを運営している企業
  • 過去のレビュー、スキャン、社内チェックリストで、実際の対応が必要な設定項目が見つかっている企業
  • 公開、リニューアル、ホスティング移行を控え、確認されていない初期設定への依存を減らしたい企業
  • 重要なセキュリティ設定の担当をめぐり、製品、開発、マーケティング、ホスティングの各チーム間でより明確な引き継ぎが必要な企業

明確にするのに役立つこと

ハードニングでは、次の点が明確になります。

  • 合意した設定上の弱点のうち、現在露出しているものと、Webサイトの範囲内で対処できるもの
  • 簡単に適用できる変更と、アクセス解析、埋め込みコンテンツ、ログインの流れなどサイトの動作に影響し得るため判断が必要な変更
  • 外部スクリプト、ホスティングの管理機能、管理者アクセスについて、担当者の明確化や別途のレビューが必要な箇所
  • 変更済みまたは推奨済みの内容、引き続きフォローアップが必要な内容、未解決のまま残る項目

含まれる内容

  • 対象となるサイト、ドメイン、環境、設定領域を明記した書面によるスコープ確認
  • 合意したWordPress、PHP、その他のサイト設定のレビュー(対象プラグイン、HTTPヘッダー、TLSとCookieの設定、認証関連の管理策、外部スクリプト、プラットフォームやサーバーの設定を含む)
  • 指摘事項と変更案を文書化した一覧(各項目の実務上の理由の説明付き)
  • 合意した設定変更の承認済みの実施と、書面の変更前後記録
  • 合意した変更の基本的な検証と、作業中に判明した機能面のトレードオフについての協議
  • 引き渡し、残る担当範囲、妥当な次の対応について話し合うレビューの打ち合わせ1回

含まれていないもの

  • ペネトレーションテスト、能動的な攻撃の実施、考えられるすべての脆弱性を発見するという約束
  • コンプライアンス認証、監査上の承認、サイトがあらゆる法的要件や業界要件を満たしているという約束
  • 業務終了後の継続的な監視、インシデント対応、継続的な運用管理
  • 合意したスコープに記載されていないドメイン、システム、プラグイン、連携のレビュー
  • 別途スコープを定めない限り、アプリケーションレベルのコードレビュー、決済フローのレビュー、より広範な製品セキュリティ作業

それを選ぶべきとき

既知の設定上の懸念がある場合、公開準備に絞った対応が必要な場合、あるいは管理された変更に落とし込むべき過去の指摘事項が明確にある場合は、Webサイトのハードニングをお選びください。ベースラインレビュー、脆弱性スキャン、プラットフォーム移行の後の次の一手として妥当なことが多くあります。複数のサプライヤーがサイトを保守してきて、どの初期設定やスクリプトがまだ使われているかを誰も確信できない場合にも適しています。中心となる課題がまだ明確でない場合は、Security Baseline Reviewから始めることで、設定の作業と、より広いアクセス、コード、プロセスの問題とを区別できます。ハードニングが最も効果を発揮するのは、変更に合意する前に、サイトの責任者、技術担当者、許容できるテスト時間帯を企業側で示せる場合です。

私たちのアプローチ

まず、サイトの範囲と実施方法を書面で定めます。概要書では、ドメイン、環境、設定領域、必要なアクセス、変更の責任分担を明記します。変更は、この確認が得られた時点で適用します。外部スクリプトの動作を変えてしまう厳しいブラウザーポリシーのように、変更が機能に影響し得る場合は、作業を進める前にそのトレードオフを説明します。合意した変更はスコープの現実的な範囲内で検証し、適用したもの、見送ったもの、別の担当者に委ねたものを記録します。コードレベルの弱点、サプライヤーのリスク、より広いセキュリティ上の問題を示す懸念に気づいた場合は、合意なく作業を広げるのではなく、その指摘事項を記録します。引き渡し資料は、貴社の開発、ホスティング、社内運用の各チームが、長いセキュリティ用語の一覧を読み解かなくても結果を理解できるように作成します。

Website Hardeningのサービスページを見る

よくある質問

関連記事

始めよう

Webサイトの設定をより意図的なものにしませんか?

スコープは、お支払いやお約束の前に書面で確定します。簡単なご依頼から始めていただければ、対象を絞ったWebサイトのハードニングが、現在のサイト、時期、担当体制に合っているかを一緒に確認します。

Webサイトのハードニングについて相談する