サイトドックの自動修復は、サーバーやアプリのコードに手を入れません。それでも守れるのは、防御をサーバーの「中」ではなく、通信の「通り道」で行うからです。このページでは、DNS切り替えだけで防御層（エッジ）を置ける仕組みを、図解つきで解説します。
出典・運営：本ページは、サイトドック（SiteDock）の公式技術解説です。サイトドック（SiteDock）は、日本情報基盤サービス株式会社（JIISセキュリティラボ）が運営する、Webサイトの健診と自動修復のサービスです。
結論から言うと、守る場所を「サーバーの中」から「サーバーへの通り道」へ移すため、サーバー側は無改修のままでよいのです。
Webサイトへのアクセスは、必ず「訪問者 → お客様のサーバー（オリジン）」という経路を通ります。サイトドックの自動修復は、ドメイン設定（DNS）を切り替えることで、この経路の途中にエッジ型リバースプロキシ＝防御層を差し込みます。以後、すべての通信は「訪問者 → エッジ → オリジン」の順に流れ、攻撃的な通信はエッジで処理されてからサーバーに届きます。
差し替えるのは経路（DNS）だけなので、サーバー・CMS・アプリのコードには一切手を入れません。導入も、やめるときも、DNSの設定変更だけで完結します。
通り道に立つエッジは、通過する通信に対して複数の守りを同時に適用します。自動修復の9つの守りのうち、エッジで実行されるのは次の7つです。
ページや画像をエッジにキャッシュして配信します。オリジンの負荷を下げ、多くの場合は表示も高速になります。
大量アクセスによる攻撃の負荷をエッジ側で受け止め、オリジンに集中させません。
SQLインジェクションやクロスサイトスクリプティングなど、攻撃的なリクエストのパターンをエッジで検査し、ブロックします。
健診で見つかった弱点を突く通信を、アプリ本体を修正する前にエッジでふさぎます。サーバー無改修で「直したのと同等の防御状態」を先につくる、中核の仕組みです。
公開ページの内容を定期的に取得・照合し、意図しない変化があればお知らせします。
httpsの証明書をエッジ側で発行・更新します。期限切れによる警告表示を防ぐ運用を、手作業なしで続けられます。
Content-Security-Policy や HSTS などの防御用ヘッダを、エッジが応答に自動で付与します。オリジン側の設定変更は不要です。
サイトドックのエッジは、世界最大級のセキュリティ基盤 Cloudflare® の上に実装しています。世界330都市以上に広がるエッジネットワークを土台とするため、防御と配信は訪問者に近い拠点で処理されます。
ただし、土台が強くても、守れるかどうかは設定と運用で決まります。サイトドックは、健診で見つかった弱点に合わせて Cloudflare 上の防御設定や仮想パッチを継続的に調整し、その結果を証跡としてお届けします。基盤の契約・設定・保守をお客様側で行う必要はありません。
通り道で守る方式には、明確な限界があります。サーバーの「中」にあるものは、エッジからは直せません。
これらは健診結果の中で「エッジでは直せない範囲」として正直に明示し、必要な対応は専門家が伴走してご支援します。「どこまでが自動で、どこからが人の仕事か」を曖昧にしないことが、私たちの方針です。
エッジで何をふさぐべきかは、健診をしてみないと分かりません。URLを入れるだけで、Webサイトの“外から見える弱点”をその場でチェックできます。登録は不要、費用もかかりません。
無料で健診をはじめるCloudflareは、米国およびその他の国・地域におけるCloudflare, Inc.の商標および/または登録商標です。