Defaults.Exposed › 修正 › CDN / WAF とホスティング

CDN / WAF とホスティング の直し方

ウェブサイトの裏側の配管を2つの面から読み取ります。攻撃をろ過しトラフィックの急増を吸収する保護の盾（Web Application Firewall付きのCDN、Cloudflareのような）の背後にいるか、そして実際に誰があなたのDNS・ウェブサイト・メールを運用しているかの地図です。どちらも当社の採点では情報提供で—評点を動かしません—が、オリジンサーバーが攻撃や停止にどれだけさらされているか、プロバイダーがどれだけ絡み合っているかを描きます。前に盾があり、プロバイダーが賢く分散しているのが、回復力のあるビジネスの姿です。

あなたのビジネスにとっての結論： 前に盾のないウェブサイトは、すべての攻撃とすべてのトラフィック急増をオリジンサーバーで直接受けます—だからボットの洪水、ローンチ当日の殺到、あるいはひとつの自動攻撃が、何時間もあなたをオフラインにしかね、復旧はあなた次第です。前にCDN/WAF（無料枠あり）を置くと、自動攻撃の大半をろ過し、急増を吸収し、世界中でサイトを高速化します—たいていIT担当の一午後の作業で、ライセンス費用はゼロです。別途、DNS・ウェブサイト・メールがすべて1つのプロバイダーにあると、そこでのひとつの停止や侵害が、オンラインの存在全体を一度に落とします。プロバイダーの地図を知ることは、インシデントで最初に必要なものです。どちらの検査も評点を変えません—が、どちらも停止・失われた売上・遅く苦痛な復旧への実在の露出を描きます。

これで失いかねないもの

• 大きな販促の朝、盾のないサーバーにボットトラフィックの突発や小さなDDoSが当たります—サイトが這うか倒れ、顧客が決済でエラーを受け、ホストが奔走する間に当日の売上を失います。前にCDN/WAFがあれば吸収していました。
• DNS・ウェブサイト・メールがすべて1つのプロバイダーを通り、そのプロバイダーが停止し、サイト・予約システム・メールが同じ瞬間にすべて真っ暗になります—メールボックスも落ちているので『障害を認識しています』すら送れません。
• 自動攻撃が一晩中サイトを探ります—SQLインジェクションやログイン推測のスクリプトが、ろ過する防火層がないためオリジンを直接叩きます—そして何かが壊れて初めて気づきます。WAFはその雑音の大半がコードに届く前にブロックします。
• インシデントが起き、誰も基本的な問い『そもそも誰に電話すればいい？』に答えられません—ウェブサイトはメールと同じホストにある？ DNSは誰が運用している？ サイトが落ちたまま配管を地図化するだけで何時間も流れます。
• 見込み客のITチームが契約前にスキャンし、CDN/WAFのない裸のオリジンと、どのソフトウェア（とバージョン）を動かしているか正確に広告する漏れやすいサーバーバージョンヘッダーを見ます—最悪のタイミングで『基本を固めていない』という小さなシグナルです。

なぜ重要か。 ここの両方の検査は当社の方法論で情報提供です—0点で登録され決して評点を変えません—合否のセキュリティ制御をテストするのではなくインフラを描くからです。表に出すのは、実在のビジネスの露出を地図化するからです。CDN/WAFのないサイトは、すべての攻撃とトラフィック急増をオリジンで直接受け、ろ過も急増の吸収もありません。追加（Cloudflareの無料枠が一般的な道）は、小規模ビジネスができる最もてこの効く・最も低コストの回復力アップグレードのひとつです。そして明確なプロバイダーの地図—DNS・ウェブ・メールが分散しているか1つに積まれているかを知ること—は、何かが起きたとき最初に必要なもので、封じ込められたインシデントと全面的な暗転の分かれ目です。

これは何か、平易に言うと

すべてのウェブサイトはどこかのサーバーで動きます。このページが答える問いは：開かれたインターネットとそのサーバーの間に何が立つか—そして実際に誰があなたのオンラインの存在の各部分を運用しているか？

2つの部分があります：

1. CDN / WAF — 前の盾。 CDN（Content Delivery Network）は、サイトの前に座り、どこの訪問者にもコンテンツを速く配信し、トラフィックの急増を吸収するグローバルネットワークです。WAF（Web Application Firewall）は、入ってくるリクエストを調べ、悪意あるものをサーバーに届く前にブロックするろ過装置です。人気のサービス（Cloudflare、AWS CloudFront、Fastly、Akamai、Sucuriなど）はこれらを束ねています。サイトのレスポンスを見て、前に盾が見えるか報告し、どのウェブサーバーを動かしているかも記します。

2. ホスティング／プロバイダーの地図 — 誰が配管を運用しているか。 あなたのDNS（ドメインをアドレスに変える名簿）を誰が扱い、メールを誰が扱うかを示す公開レコードを読みます。そこから、DNS・ウェブサイト・メールがプロバイダーをまたいで分散しているか（回復力がある）、1つに積まれているか（便利だが単一障害点）を見分けられます。

最初に知るべき最重要事項： 当社の採点では、この両方が情報提供です。評点に影響しません。表に出すのは、ビジネスが停止や攻撃にどれだけさらされているかを描くからで—評点とは別の、とても実際的な問いです。

これが招きうる損失

抽象的なリスクではありません—盾のない、絡まった構成が小さな問題を悪い一日に変える日常的な形です。

• 最も重要な日にオフラインにされる。 サイトが前に何もない状態でオリジンサーバーにあります。ローンチや販促の朝、トラフィックが急増—あるいは中程度のボットの洪水が当たり—サーバーが対応できません。ページがタイムアウトし、決済がエラーになり、ホストが消火する間に当日の売上を失います。CDNは急増を吸収し、WAFは雑なトラフィックをろ過し、合わせて『忙しい日』と『午前中ずっとダウン』の分かれ目になります。

• すべてが一度に真っ暗になる。 DNS・ウェブサイト・メールがすべて単一のプロバイダーを通ります。そのプロバイダーが停止し（いずれどれにも起きます）、サイト・予約システム・メールが同時に消えます。注文を処理できず、認識していると顧客にメールすることすらできません—メールボックスも落ちているからです。プロバイダーを分散すれば、ひとつの障害は全面的ではなく封じ込められます。

• コードがすべての攻撃を直接受ける。 WAFがないと、すべての自動の探り—インジェクションの試み、ログイン推測、既知の悪用スキャナー—がろ過なしであなたのアプリケーションコードに当たります。ソフトウェアが永遠に欠陥なく完全にパッチされていると賭けているのです。WAFはその自動の雑音の圧倒的大半が届く前にブロックし、『絶え間ない背景の攻撃』を『ほぼろ過済み』に変えます。

• 誰も地図を持たない、遅くパニックなインシデント。 何かが壊れ、最初の1時間が『待って、誰がDNSを運用している？ メールは同じホスト？ 誰に電話する？』に浪費されます。プロバイダーの地図が不明確だと、すべてのインシデントがゼロから始まります。地図を前もって知れば、奔走が電話一本に変わります。

• 慎重な買い手への悪い第一印象。 見込み客のITチームが契約前にスキャンし、CDN/WAFのない裸のオリジンと、正確なソフトウェアとバージョンを公然と広告するサーバーヘッダーを見ます。小さなシグナルですが、まさに悪いタイミングで『基本を固めていない』欄にあなたを置きます。

これの実体

CDN / WAF — 保護層

訪問者（または攻撃者）がサイトを要求すると、リクエストはまっすぐオリジンサーバーへ行くか、まずCDN/WAFを通るかのどちらかです。前に盾があれば、その盾は：

• 悪意あるリクエストをろ過（WAF部分）： インジェクションの試み、ボット攻撃、既知の悪用パターンを、コードに届く前にブロックします。
• トラフィックを吸収（CDN部分）： 各訪問者の近くのサーバーからキャッシュされたコンテンツを配信し、急増を吸収するので、殺到（正規でも敵対的でも）がオリジンを潰しません。
• サイトを高速化： 近くのエッジサーバーから配信されるコンテンツは、世界中の訪問者に速く読み込まれます。

盾は、これらのサービスがサイトのレスポンスヘッダーに残す指紋を見て検出します—例えばcf-rayヘッダー（Cloudflare）、x-amz-cf-id（Amazon CloudFront）、x-served-by（Fastly）、x-akamai-transformed（Akamai）、x-sucuri-id（Sucuri）。またServerヘッダーを読んで基盤のウェブサーバー（nginx、Apache、IIS、LiteSpeed、Caddyなど）を特定し、共有しすぎているX-Powered-Byヘッダーを指摘します。

『良い』状態とは： オリジンの前にCDN/WAFが検出され、Serverヘッダーが特定のバージョン番号を広告しないこと。

ホスティング／プロバイダーの地図 — インフラの依存

あなたのドメインは静かにいくつかの異なるサービスを指します：

• DNS — yourbusiness.comを実際のサーバーアドレスに変える名簿。ネームサーバー（NS）レコードを読み、一般的なプロバイダー（Cloudflare、AWS Route 53、Azure DNS、GoDaddy、Namecheap、DigitalOcean、Hetzner、Linode、地域のレジストラなど）を認識します。
• メール — メールが扱われる場所。MXレコードを読み、一般的なプロバイダー（Google Workspace、Microsoft 365、Proofpoint、Mimecast、Barracuda、Zohoなど）を認識します。

これらから、これらの責任がプロバイダーをまたいで分散しているか（ひとつの障害が他を落とさない）、単一プロバイダーに積まれているか（便利だが、ひとつの停止や侵害がすべてを取る）を見られます。

『良い』状態とは： 最低限、DNSが、すべてと同じアカウントに束ねられるのではなく、専用の信頼できるプロバイダーに保持されていること—ドメインの名簿がウェブサイトや受信トレイと運命を共にしないように。

修正方法（無料・約1午後）

IT担当やウェブ開発者にこれを渡してください。修正は無料です。 サイトの前にCDN/WAFを置くのは一般的な無料枠で費用ゼロ、サーバーバージョンを抑えるのは1行の設定です。買うライセンスはありません。（ここでの有料の選択肢は監視・ポートフォリオ追跡・監査だけで—修正そのものではありません。）オーナーの唯一の決定は：はい、サイトの前に盾を置く。

両方の検査が情報提供なので、これらはどれも採点されません—でもCDN/WAFは小規模ビジネスができる最も価値のある回復力アップグレードのひとつなので、やる価値があります。

1. サイトの前にCDN/WAFを置く

最も一般的で無料の道はCloudflareです：

1. 無料のCloudflareアカウントを作りドメインを追加します。
2. Cloudflareが既存のDNSレコードを読みます。正しく取り込まれたか確認します。
3. ドメインのネームサーバーを（レジストラで）Cloudflareがくれる2つに変えます。これがトラフィックをCloudflare経由にルーティングする切り替えです。
4. SSL/TLSモードを**Full (strict)**に設定し、訪問者 → Cloudflare → オリジンの間で暗号化がエンドツーエンドに保たれるようにします。（最後の区間を暗号化されないままにする『Flexible』は避けてください。）
5. CDNと基本的なWAFが有効になりました。後でWAFルールを調整できますが、既定でもかなりろ過します。

他の道、スタック次第：

• AWS CloudFront — オリジンを指すディストリビューションを作り、ろ過にAWS WAFを組み合わせます。すでにAWSにいるなら最適です。
• Sucuri WAF — DNSベースで、サーバーに変更不要。オリジンに触れられないなら良い選択です。
• Fastly / Akamai — 企業級のCDN/WAFで、通常はより大規模・高トラフィックのサイト向けです。

切り替え後、サイトをテストし、HTTPSがどこでも機能することを確認し、1日見守ります。個人的・ライブであるべきページ（ログイン領域、買い物かご、決済）を激しくキャッシュしないこと。

2. サーバーバージョンの広告をやめる

CDNを加えるかどうかに関わらず、サーバーが告知するバージョンを抑えてください—攻撃者に渡している無料の情報です。

Nginx：

server_tokens off;

Apache（メイン設定で）：

ServerTokens Prod
ServerSignature Off

共有しすぎているX-Powered-Byヘッダーを取り除く（例：PHPやアプリフレームワークから）—サーバーやCDNのレベルで。Cloudflareではレスポンスヘッダーのトランスフォームルールで剥がせます。

3. プロバイダーの地図を点検する（任意、約10分）

DNS・ウェブサイト・メールが実際どこにあるか見ます：

• 3つすべてが1つのプロバイダーのアカウントにあるなら、少なくともDNSを専用プロバイダーへ移すことを検討します（Cloudflare DNSは無料で速い）。その単一の分散だけで、ドメインの名簿がホスティングの停止を生き延びます。
• 地図を書き留めます—DNSプロバイダー、ウェブホスト、メールプロバイダー、レジストラ、それぞれのログイン／サポート窓口。この1枚は、インシデント中に手元にある最も役立つものです。

プラットフォームの注記

• Google Workspace / Microsoft 365： これらはあなたのメールプロバイダーで、ウェブサイトではありません。サイトの前にCDN/WAFを置いてもメールには触れず、逆もまた然り—別々の決定です。（メールをGoogle/Microsoftに、ウェブサイトをCloudflareの背後にするのは、まったく良い、意図的に分散された構成です。）
• マネージドサイトビルダー（Wix、Squarespace、Shopify）： これらは独自のCDNと一定レベルのWAF保護をプラットフォームの一部として含むので、当社のヘッダー検査がプロバイダーを名指ししなくてもすでに盾の中にいるかもしれません。通常、自分のCloudflareを前に置けません。それで構いません—プラットフォームが扱います。
• 自前ホスティングのWordPress： 前に無料のCloudflare層を置く理想的な候補です。アプリケーションレベルのルールには、セキュリティプラグインのファイアウォールと組み合わせましょう。

よくある間違い

• 『サイトが小さいから』裸のオリジンを動かす。 小さなサイトも大きなサイトと同じ自動攻撃やボットの洪水を受けます—ボットはまず売上を確認しません。無料のCDN/WAF枠はまさに小さなサイトのために存在し、使わないのは簡単な勝ちを放置することです。
• Cloudflareの『Flexible』SSLを使う。 鍵マークは出ますが、Cloudflareとオリジンの間の接続を暗号化されないまま残します。常に**Full (strict)**を使い、エンドツーエンドで暗号化しましょう。
• 間違ったものをキャッシュする。 ログイン済みページ・かご・決済を激しくキャッシュすると、ある顧客に別の顧客のコンテンツや古い価格を見せかねません。静的コンテンツをキャッシュし、個人的・取引のページはキャッシュしないでください。
• 気づかぬまま1つのプロバイダーにすべてを積む。 意識的な選択なら便利さは結構です—でも多くのビジネスは、3つすべてを落とす停止のときに初めて、DNS・ウェブ・メールが1つのアカウントを共有していると気づきます。発見ではなく決定にしましょう。
• サーバーバージョンを表示したまま残す。 忘れやすい、無料で1行の固めの一歩です。オフにしてください。

評点についての注記

完全に率直に：この2つの検査はどちらも評点に影響しません。 当社の方法論では0点の情報提供として登録され、盾のないオリジンや単一プロバイダーの構成で決して減点しません。報告するのは、停止・攻撃・遅いインシデント復旧への実在の露出を描くからで—そして無料のCDN/WAFの追加が小規模ビジネスができる最も価値のあるアップグレードのひとつだからです。ここで何もしなくても、評点は変わりません。サイトの前に盾を置きDNSを切り離せば、無料でビジネスを意味あるほど回復力のあるものにしたことになります。それがこのページの正しい読み方です。守る数字ではなく、取る価値のある回復力アップグレードです。

よくある質問