Cloudflareを使用してください。セキュリティプラグインをインストールし、WordPressを定期的に更新してください。
一般的なWordPressセキュリティ専門家の提案
小規模なブログの場合、このアドバイスはほとんどの場合有効ですが、更新によってサイトが壊れる可能性があるため、ステージング環境を追加して、更新がステージング環境でサイトを壊していないことを確認し、確認後に本番環境にデプロイすることを検討する必要があります。
HRPeakについて考えてみましょう。数千の求人情報を持ち、かなり大規模なエンタープライズ顧客基盤を持つ、ATS組み込み評価センターのスケールアップ企業です。クライアントは数千の求人を持ち、サイトはトラフィックを受け、フォームは独自のカスタムAPIエンドポイント経由で送信される必要があります。公開サイトで証明書検証に使用されるWebアプリケーションを追加します。データセンター障害でもオンラインを維持できるでしょうか？
プライマリデータセンターで、データセンターとISPに関連する問題により15時間のオフラインを経験しました。しかし、これは想定内であり、サイトは独立した第2のデータセンターから引き続きオンラインでした。これが可能だったのは、セキュリティやバックアップのための別のWordPressプラグインではなく、望ましくない状況下でもWebサイトをオンラインに保つアーキテクチャだからです。
標準的なWordPressセットアップが失敗する理由
典型的なWordPress推奨事項がエンタープライズに機能しない理由について率直に説明しましょう。
問題1: すべてが一箇所に
ほとんどのWordPressセットアップとは: Webサイト、フォーム、カスタムアプリ、その他すべてを1つのWordPressインストールに配置し、さらに悪いことに、すべてのWebサイトを1つのアカウントに配置して、1つがハッキングされると他のサイトもハッキングされるようにします。
実際に起こること:
- 1つのセキュリティ問題がすべてに影響
- すべてのパフォーマンスが低下（リソース共有が多すぎる）
- サイト全体をリスクにさらさずに一部を更新できない
- バックアップと復旧はオールオアナッシング
- さらに悪いことに、複数の企業Webサイトが同じユーザー/フォルダーの下に配置される
簡単に言えば: すべての貴重品を1つの部屋に保管するようなものです。その部屋で何か問題が発生すると、すべてを失います。より簡潔に言えば、すべての卵を1つのバスケットに入れることです。
問題2: WordPress更新の罠
WordPressコア、プラグイン、テーマを定期的に更新する必要があります。多くのプラグインがある場合、これは複雑になります。更新によってサイト全体または部分的に壊れる可能性があります。更新しないとセキュリティ問題が発生します。ステージング環境の使用には時間と労力がかかります。すべてのWordPress所有者が直面する不可能な選択は次のとおりです:
オプションA: セキュリティパッチが出たらすぐにWordPressを更新
- ハッカーから安全を保つ
- Webサイト全体を壊すリスク
- フォームが動作しなくなる可能性
- カスタム機能が壊れる可能性
オプションB: ステージング環境で更新を慎重にテストしてから適用
- 何も壊れないことを確認
- ハッカーが脆弱性を悪用すると、ハッキングされる
- テストに時間がかかる
選択は不可能です。 速く更新して物を壊すか、ゆっくりテストして脆弱なままでいるか。すべてが1つのWordPressインストールを共有している場合、良い選択肢はありません。
簡単に言えば: 家が緊急修理を必要としているが、修理を行うには全員が1週間引っ越さなければならないことを意味する想像してください。これがWordPress更新の罠です。
問題3: セキュリティプラグインは実際には分離しない
セキュリティプラグインは保護を追加しますが:
- サイトを遅くする（すべてをチェック）
- WordPressを依然として公開する（いくつかのドアに警備員がいるだけで、裏口にはいないかもしれない）
- すべての攻撃を防ぐことはできない（事後対応であり、事前対応ではない）
- 他の機能とプラグインの競合を作成
- セキュリティプラグイン自体がセキュリティ問題を引き起こすこともあります。数百万のWordPressサイトでセキュリティ問題を引き起こした広く使用されているセキュリティプラグインをこちらで確認してください
簡単に言えば: セキュリティプラグインは空港の警備員を雇うようなものですが、空港内には本当にチェックできない多くの入口と独立したユニットがあります – 清掃会社がセキュリティ脅威に変わる可能性があり、訪問者は警備員をバイパスできる未知の方法を使用する可能性があります。何もないよりはましですが、真のセキュリティではありません。
我々が構築したもの: アーキテクチャによってWordPressを公開から分離しながらWordPressを使用
1つの脆弱なシステムの代わりに、自動フェイルオーバーを備えた複数のデータセンターにわたる冗長インフラストラクチャを構築しました。
Copied!パブリックインターネット ↓ CLOUDFLARE (DNS & フェイルオーバー) ↓ GLOBALISERエッジデータセンター (複数の地理的ロケーション) ├─ エッジロケーション1 ├─ エッジロケーション2 └─ エッジロケーション3+ ↓ 専用バックエンドサーバー ├─ WordPress（メインWebサイト） ├─ 証明書管理 ├─ 検証システム └─ メールバックエンド（クライアント）
簡単に言えば: ユーザーは当社のエッジデータセンター（複数のロケーション）に接続します。これらのエッジデータセンターは、特定の機能のために設計された専用のバックエンドサーバーに接続します。1つのエッジデータセンターが障害した場合、Cloudflareは他のデータセンターにトラフィックをルーティングします。1つのバックエンドシステムに問題がある場合、他のシステムは動作し続けます。
このアーキテクチャの仕組み
公開向け（複数のエッジデータセンター）
ユーザーは異なる地理的ロケーションにある当社のエッジデータセンターに接続します。各データセンターは以下を提供します:
- メインWebサイト（企業情報、サービス）
- 証明書検証（公開検索、45ms応答）
- お問い合わせフォーム（フロントエンドインターフェース）
1つのデータセンターのISPが障害した場合 → Cloudflareは他のデータセンターにルーティング → ユーザーは気づかない。
隠しバックエンド（公開アクセス不可）
- コンテンツ用WordPress – プライベートネットワークで実行、公開されていない
- 証明書管理 – 別のWordPress、プライベートURLのみ、スタッフアクセス
- 検証バックエンド – 直接データベースクエリ、読み取り専用アクセス
- メールシステム – クライアントのSOAP API、完全に別個
簡単に言えば: 公開は店頭（エッジデータセンター）を見ます。倉庫とオフィス（バックエンドシステム）は完全に隠されています。1つの店頭が停電した場合、顧客は自動的に他の店頭に行きます。倉庫は状況に関係なく動作し続けます。
15時間のデータセンター停止: 実世界の証明
数週間前、当社のエッジデータセンターの1つでISP障害が完全に発生しました。そのデータセンターへのインターネット接続が15時間完全に切断されました。
典型的なWordPressホスティングの場合: 完全なブラックアウト。Webサイトなし、フォームなし、証明書検証なし。すべてオフライン。
実際に起こったこと
0時間目: データセンター1のISP障害
- プライマリエッジデータセンターがインターネット接続を失う
- Cloudflareヘルスモニタリングがデータセンターに到達できないことを検出
- 数秒以内に: Cloudflareはそこへのトラフィックルーティングを停止
15時間中: ビジネスは正常に継続
- Cloudflareはすべてのトラフィックをエッジデータセンター2、3などに自動的にルーティング
- メインWebサイトはオンラインのまま（動作中のデータセンターから提供）
- 証明書検証は動作し続ける（他のデータセンターがリクエストを処理）
- お問い合わせフォームは完璧に動作（動作中のロケーションにルーティング）
- バックエンドシステムは影響を受けない（異なる接続、異なるISP）
- ユーザーは1つのデータセンターがオフラインであることを決して知らない
15時間目: ISP修復
- 影響を受けたエッジデータセンターへの接続が復元
- Cloudflareはオンラインに戻ったことを検出
- すべてのデータセンターにトラフィックを段階的にルーティング
- すべてのロケーションが再び提供中
結果
- ユーザー向けダウンタイム: 0〜5分
- 失われたフォーム: ゼロ
- 失われた広告予算: ゼロ
- 証明書検証アプリは影響を受けたか？ いいえ
- 顧客からの苦情: ゼロ
- 緊急対応コスト: ¥0
- 必要な手動介入: なし（自動フェイルオーバー）
簡単に言えば: 当社の店舗の1つが15時間停電しました。Cloudflareはすべての顧客を自動的に他の店舗に送りました。顧客は気づきませんでした。電力が戻ったとき、その店舗は再び開きました。売上損失なし、怒った顧客なし。
これは運ではありませんでした。これはアーキテクチャでした。
これがWordPress更新の罠をどう解決するか
不可能な選択を覚えていますか？すべてを壊すリスクで更新するか、ゆっくりテストして脆弱なままでいるか？
当社のアーキテクチャでは、このジレンマは消えます – そしてここに重要な洞察があります:
WordPressは公開アクセス不可 = 緊急性の低い更新
従来のセットアップ:
- WordPressは公開
- ハッカーはWordPressを直接攻撃できる
- セキュリティパッチが出たらすぐに更新する必要がある
- しかし更新は物を壊す
当社のアーキテクチャ:
- WordPressはプライベートネットワークで実行
- インターネットから直接アクセスできない
- エッジデータセンターのみが接続
- WordPressが攻撃対象ではないため更新を適切にテストできる
簡単に言えば: 倉庫が通りにない場合（ロックされたゲートの後ろにある場合）、新しいロックがあるたびに倉庫セキュリティシステムをパニック更新する必要はありません。最初に新しいロックを適切にテストできます。
セキュリティの優位性
セキュリティは1つのプラグインではありません。複数の独立した障壁です。
仕組み
公開が見るもの: エッジデータセンター（レート制限、DDoS保護）
公開が見られないもの: メインサイトWordPress管理者、WordPress証明書管理アプリ、メールバックエンド
公開証明書検証アプリのデータベースアクセス: 検証用の読み取り専用（クエリ可能、変更不可）
管理者アクセス: プライベートURLのみ（公開Webサイトから見つけられない）
これは管理に摩擦がなく、従来通りWordPressを使用しますが、公開の目から遠ざけ、セットアップ全体に高可用性プラクティスを適用します。
攻撃対象領域の削減
理由:
- WordPressは公開アクセス不可（到達できないものは攻撃できない）
- 証明書管理は隠されている（プライベートURLのみ）
- 検証アプリはWordPressを使用しない（WordPress脆弱性なし）
- システムは分離（1つを侵害しても連鎖しない）
最近のセキュリティ監査:
- SQLインジェクション試行 → ブロック
- WordPress攻撃 → WordPressが見つからない（公開されていない）
- システム間攻撃 → 失敗（システムは分離）
簡単に言えば: 警備員が必要な500のドアの代わりに、2つのドアがあります。そして最も貴重な部屋（WordPress管理者、証明書管理）は公開ビルからアクセスできません。
実際のパフォーマンス数値
Globaliserエッジネットワーク（複数のデータセンター）
- ローカル応答時間: 100ms未満
- ページが完全に読み込まれる: 2.5秒未満（モバイル絞り込み接続でのLCP）
- 単一障害点なし: 複数のデータセンター
証明書検証アプリケーション
- 平均応答: 45ms
- WordPress REST APIアプローチ: 280ms（6倍遅い）
- セキュリティプラグイン付きWordPress: 450ms（10倍遅い）
なぜ速いのか:
- WordPressの読み込みなし（50以上のファイルとプラグイン）
- 直接データベース接続
- 検証専用のカスタム小型アプリ
お問い合わせフォーム
- フォーム送信: 平均300ms
- ルート先: HRPeakのSOAP API（彼らのインフラストラクチャ）
- 使用していない: WordPressメールまたはSMTP
- 信頼性: エンタープライズメールバックエンド、WordPressプラグインではない
このアーキテクチャが意味を持つ時
これが必要な場合:
ダウンタイムがお金を失う:
- Eコマースサイト（ダウンタイム中に販売が停止）
- マーケティングに使用されるサイト（マーケティングROI増加、広告予算節約）
- ブランド（評判の損傷、顧客の信頼）
- SaaSプラットフォーム（契約SLA違反）
一度正しく構築することを理解している:
- より高い初期投資
- しかし強制的な再構築なし
- 実証された災害復旧（15時間のテスト合格）
- 実際の障害条件下での安心
これが必要ない場合:
- シンプルなブログまたはポートフォリオサイト
- 非常に限られた予算（適切なアーキテクチャに投資できない）
- 重要なビジネス運用なし（ダウンタイムは迷惑だがコストがかからない）
投資の質問
ここでは具体的な価格をリストしません（すべてのエンタープライズには独自の要件があります）が、考え方は次のとおりです:
「シンプルに始めて、後で再構築」の罠
当初は良さそう:
- より低い初期コスト
- より速く立ち上げ
- 実用的に見える
18〜24ヶ月後に起こること:
- パフォーマンスが低下（サイトが遅くなる）
- WordPress更新が怖い（すべてを壊す可能性）
- ゼロから再構築する必要（元の「シンプル」コストの2〜3倍）
- データ移行が複雑
- 移行中のダウンタイム
- 失われた勢い
エンタープライズアーキテクチャアプローチ
中程度の初期投資、しかし:
- 一度正しく構築
- 再構築の必要なし
- 実証された回復力（15時間のデータセンター障害 = 0ダウンタイム）
- 独立したシステム更新（連鎖障害なし）
- データセンターを追加してスケール（アーキテクチャはすでにサポート）
本当の質問: 15時間のダウンタイムはあなたのビジネスにいくらかかりますか？
数千の求人情報とエンタープライズクライアントを持つHRPeakにとって、15時間のオフラインは次のことを意味したでしょう:
- 失われたリード
- エンタープライズクライアントとの評判の損傷
- 潜在的な契約違反
- 緊急復旧コスト
- 修正のためのスタッフ残業
その停止を防ぐことは、アーキテクチャ投資の何倍も支払いました。
このアーキテクチャが機能する理由
実際の条件下でテストされた
理論的な災害復旧ではない:
- 15時間のISP障害: マルチデータセンターアーキテクチャ経由でオンラインを維持
- WordPress更新が壊す: 0ユーザー影響（システム分離）
- セキュリティ監査: 99%攻撃対象領域削減
- パフォーマンス: WordPressアプローチより6倍速い
15時間の停止は訓練ではありませんでした。 これは当社のエッジデータセンターの1つへの実際のISP障害であり、アーキテクチャは設計どおりに正確に機能しました。ユーザーは何も気づきませんでした。
実際の問題を解決
すべてのWordPress所有者が知っている問題:
- WordPress更新が物を壊す → システム分離がそれを解決
- 単一障害点 → 複数のデータセンターがそれを解決
- リスクなしで更新できない → 分離がそれを解決
- セキュリティ対パフォーマンスのトレードオフ → アーキテクチャが両方を解決
エンジニアリング原則に基づく
数百の操作で機能する原則は数百万で機能します:
- 複数のエッジデータセンター = 実際に機能する災害復旧
- 専用バックエンドシステム = それぞれの目的に最適化
- システム分離 = 連鎖障害なし
- プライベートインフラストラクチャ = 管理操作は公開から隠される
スケールは原則を変えません。 数百または数百万の操作があっても、アーキテクチャアプローチは同じままです。
希望や運に頼らず構築します。テスト済みのインフラストラクチャに基づいて構築します。
HRPeakのエッジデータセンターの1つが15時間接続を失ったとき、ユーザーは何も気づきませんでした。証明書検証は続きました。フォームは機能しました。求人情報はアクセス可能でした。エンタープライズクライアントは問題があることを決して知りませんでした。
これは特定の目的のために設計された専用システムです。これは関心事の分離と独立した操作です。
これはエンタープライズアーキテクチャです。
結論: プラグインではなく、アーキテクチャによるセキュリティ
WordPressはコンテンツ管理に優れています。セキュリティプラグインは基本的な保護に役立ちます。しかし、どちらもエンタープライズ災害復旧や真のシステム分離のために設計されていません。
結果: 1つのエッジデータセンターがISP障害により15時間オフラインになったとき、Cloudflareは自動的に他のデータセンターにトラフィックをルーティングしました。証明書検証は続きました。フォームは機能しました。求人情報はアクセス可能でした。ユーザーは何も気づきませんでした。
「バックアップと災害復旧計画がある」と「機能する災害復旧がある」の違いは、実際の障害条件下でテストされたときにサイトが実際に稼働し続けるかどうかです。
HRPeakのアーキテクチャはテストされました。機能しました。
エンタープライズWordPress = スケーリング & 高可用性 & セキュリティ & 速度 & 保守性
アーキテクチャは、エンタープライズWordPressセキュリティがより多くのプラグインをインストールすることではないことを示しています – WordPressを公開アクセスから分離し、関心事を適切に分離し、インフラストラクチャが障害しても動作し続けるシステムを構築することです。
エンタープライズ運用のためのマルチデータセンターアーキテクチャとWordPress分離について議論したいですか？ Globaliserにお問い合わせください。
About the Author
コメントを残す