WordPress は、さまざまな目的で、あらゆる規模の Web サイトの作成に使用される汎用的で人気の高いコンテンツ管理システムです。 小規模な個人用ブログから大規模な企業サイトや eコマース ストアまで、WordPress はさまざまなニーズに合わせて広範囲の機能とカスタマイズを提供します。 ただし、インストールのサイズとユース ケースが多岐にわたるため、WordPress にはトラフィック量やストレージ ニーズなどの要因に応じた独自のホスティング要件もあります。
この記事では、Azure での WordPress のデプロイについて説明します。 この記事には、セキュリティで保護され、スケーラブルでコスト効率の高いインストールを確保するために何を考慮し、実装すべきかについてのガイダンスが記載されています。
WordPress のセキュリティとパフォーマンスに関する一般的なヒント
圧倒的な人気を誇るため、WordPress はハッカーの標的になっています。 プラットフォームで実行される Web サイトは、マルウェアやフィッシング攻撃などのセキュリティの脅威に対して脆弱になる可能性があります。 次のヒントは、より安全でパフォーマンスの高い WordPress インストールを作成することで、これらのリスクに対処するのに役立ちます。
ホスティング アーキテクチャに仮想マシン (VM) または Azure App Service のどちらかを使用する場合も、他のソリューションを使用する場合も、これらのヒントを適用できます。
Azure Web Application Firewall を使用する
Web Application Firewall は、一般的な Web ベースの攻撃から Web サイトをセキュリティで保護するのに役立ちます。 Web Application Firewall は Web サイトとインターネットの間のフィルターとして機能します。 この機能により、Web Application Firewall は受信トラフィックを監視し、Web サイトのコードの脆弱性を悪用する可能性のある悪意のある要求をブロックします。 Web Application Firewall は、SQL インジェクション、クロスサイト スクリプティング (XSS)、クロスサイト リクエスト フォージェリ (CSRF) など、さまざまな攻撃から Web サイトを保護することに役立ちます。
Azure Front Door 上の Web Application Firewall (WAF) を使用して Web アプリケーションに対する一元的な保護を提供する必要があります。 Azure Front Door は、アプリケーションの静的 Web コンテンツと動的 Web コンテンツへの高速で信頼性の高い安全なアクセスを世界中のユーザーに提供するコンテンツ配信ネットワークです。 Azure Front Door に Web Application Firewall をデプロイすることで、一般的な悪用や脆弱性から Web サービスを保護することに役立ちます。
未使用のプラグインとテーマを削除する
WordPress インストールから未使用のプラグインとテーマを削除する必要があります。 WordPress Web サイトを安全に保ち、Web サイトのパフォーマンスを最適化するには、この手順が重要です。 積極的に使用していないプラグインやテーマであっても、古いコードやメンテナンスされていないコードの脆弱性をハッカーが悪用するためのエントリ ポイントになることで、セキュリティ上のリスクを引き起こす可能性があります。 また、Web サイトに大量のプラグインやテーマがインストールされていると、読み込み時間とサーバー リソースの使用量が増大するため、パフォーマンスが低下する可能性があります。
PHP プロセッサから静的コンテンツをオフロードする
PHP プロセッサの負荷を軽減するには、画像、ビデオ、CSS ファイルなどの静的コンテンツをオフロードする必要があります。 静的コンテンツをオフロードすることは、Web サイトのパフォーマンスを最適化し、サーバーの負荷を軽減するのに役立ちます。 ユーザーが Web サイトにアクセスすると、サーバーは PHP コードを処理し、HTML コンテンツを動的に生成します。 このプロセスは、リソースを集中的に消費します。 ただし、静的コンテンツは頻繁に変更されないため、サーバー ファイル システムやコンテンツ配信ネットワークから静的コンテンツを直接提供することができます。 これらのアセットをオフロードすることで、サーバーの CPU と RAM の負荷を軽減できます。 この構成により、ページの読み込み時間が短縮され、Web サイトのパフォーマンスとユーザー エクスペリエンスが向上します。
Azure Front Door などのコンテンツ配信ネットワーク サービスから静的リソースを提供することには他にも利点があります。 たとえば、静的コンテンツをオフロードすれば、ユーザーの地理的な場所の近くにサーバーを配置することで、待機時間を短縮し、Web サイトを高速化することができます。
注意
プライベート エンドポイントを使用して Azure Front Door で配信元をセキュリティで保護するには、Azure Front Door の Premium SKU を使用する必要があります。 詳細については、「Private Link を使用した配信元のセキュリティ保護」を参照してください。
コンテンツ配信ネットワーク キャッシュの無効化
Azure Front Door や Azure Content Delivery Network などのコンテンツ配信ネットワークを使用する大規模な WordPress インストールでは、キャッシュ無効化ロジックを実装する必要があります。 新しいイベントが発生するたびに、影響を受けるページに対応するコンテンツ配信ネットワーク内のキャッシュを無効にする必要があります。 イベントの例には、新しい記事の公開、既存のページの更新、コメントの追加などがあります。 無効化ロジックでは、変更の影響を受けるすべての URL を見つける必要があります。 具体的に言えば、ロジックでは、コンテンツ配信ネットワーク キャッシュ内のカテゴリやアーカイブなど、動的に生成されるページを見つけて無効にする必要があります。 一部のテーマやプラグインがインストールされていると、軽微な変更であっても、すべてのページが影響を受ける可能性があります。
検出ロジックを実装する簡単な方法は、すべての URL に対するキャッシュの無効化を手動でトリガーできるプラグインを使用することです。 ただし、すべての URL を一度に無効にすると、WordPress サイトのトラフィックが急増する可能性があります。 コンテンツ配信ネットワークでのキャッシュ無効化ロジックの例については、「Azure キャッシュのフラッシュとデプロイ フックの GitHub への実装」を参照してください。
2 要素認証を有効にする
2 要素認証は、インストールのセキュリティを強化し、未承認のアクセスや攻撃から管理者アカウントを保護することに役立ちます。 2 要素認証を活用するには、miniOrange 認証プラグインなどのプラグインを使用することができます。 このプラグインには、管理者として WordPress サイトにサインインするユーザーに対する 2 要素認証方法として Microsoft Authenticator を構成する手段を提供する機能もあります。
XML-RPC アクセスを無効にする
XML-RPC は、 Web サイトのサーバーを操作する手段をサードパーティ製アプリケーションに提供するリモート プロトコルです。 ただし、このプロトコルはハッカーの一般的なターゲットでもあり、ハッカーはこのプロトコルを利用してブルート フォース攻撃を仕掛けたり、コンテンツ管理システムの脆弱性を悪用したりします。 Azure Front Door を使用すれば、 /xmlrpc.php 形式の URL に対して拒否ルールを設定することで、XML-RPC を無効にすることができます。
管理パネルへのアクセスを制限する
既定では、アカウント資格情報と正しい (/wp-login.php 形式または /wp-admin 形式の) URL を持つすべてのユーザーが WordPress 管理パネルにアクセスできます。 その結果、ハッカーやその他の悪意のあるアクターが、アクセス権を取得するために、資格情報の推測、セッション ハイジャックの実行、ブルート フォース攻撃の実行、WordPress の脆弱性の悪用を試みる可能性があります。
Web Application Firewall は一部の攻撃の防止に役立ちますが、多くの管理者はネットワーク レベルで WordPress 管理パネルへのアクセスを制限する手法を好みます。
たとえば、Azure Front Door ではプライベート URL へのアクセスをブロックできます。 そのうえで、Azure Application Gateway を使用して、ハブアンドスポーク トポロジを使用しているプライベート ネットワークから内部アクセスを提供できます。 Application Gateway の内部インスタンスは、Web Application Firewall ルールと Azure Front Door ルールをサポートします。 これらのルールは、内部攻撃から WordPress インストールを保護することに役立ちます。 内部攻撃のリスクを許容できる場合は、Application Gateway ではなく、Azure Load Balancer の内部インスタンスを使用することができます。 Load Balancer は、開放型システム間相互接続 (OSI) モデルのレイヤー 4 で動作します。
このアーキテクチャの Visio ファイルをダウンロードします。
特定の WordPress プラグインでは、/wp-admin/admin-ajax.php 形式の URL をパブリック アクセス可能にして、この拒否ルールから除外する必要があります。
Azure Key Vault にシークレットを格納する
Azure での WordPress デプロイのセキュリティを確保するために、データベース パスワード、TLS 証明書や SSL 証明書などのシークレットをキー コンテナーに保存することをお勧めします。 このクラウドベースのサービスは、暗号化キー、証明書、シークレットの安全なストレージと管理を提供します。
キー コンテナーは、承認済みのアプリケーションとサービスがシークレットに安全にアクセスするのに役立ちます。 WordPress コンテナーのイメージ内またはアプリケーション コード内にプレーン テキストでシークレットを保存する必要はありません。
パフォーマンスを調整する
WordPress のパフォーマンスを最適化するには、さまざまな設定をチューニングしたり、プラグインを使用したりする必要があります。次のプラグインは、WordPress インストールのデバッグに役立ちます。
- クエリ モニターは、各 SQL クエリやその他のアクションにかかる時間の内訳を示します。 表示される例としては、PHP エラー、フックとアクション、ブロック エディターのブロック、エンキューされたスクリプトとスタイルシート、HTTP API 呼び出しなどがあります。
- Laps は、WordPress ページの読み込みにかかる時間の内訳を示します。
WordPress のホスティングの課題
WordPress アプリケーションのアーキテクチャには、次のようないくつかのホスティングの課題があります。
- スケーラビリティ。 ホスティング アーキテクチャは、トラフィックのピーク期間中にスケールアウトする機能を備えている必要があります。
- ReadWriteMany (RWX) ストレージ。 既定では、WordPress は、すべての静的アセット、プラグイン、テーマのソース コードを
/wp-content/ディレクトリに保存します。 スケールアウト時は、すべてのノードがそのディレクトリに対する読み取りと書き込みを実行できる必要があります。 - 1 秒あたりの入出力操作 (IOPS) ストレージ クラス。 WordPress は、PHP プロセッサが受信要求時に参照し、読み込み、実行する 1,000 個を超える小さな .php ファイルから構成されています。 一部のプロトコルでは、大量の小さなファイルの読み込みがオーバーヘッドの増加を引き起こす可能性があります。 その場合は、同じ合計サイズの 1 つのファイルを読み込むときより全体的なパフォーマンスが低下します。 その結果、ストレージ ソリューションによる高い IOPS のサポートが必要になります。
- キャッシュの無効化。 新しい記事を公開するときなど、アプリケーションに新しいアクティビティがあるときは、すべてのノードにわたってキャッシュを無効にする必要があります。
- キャッシュの構築に要する時間。 特定のノードの最初のユーザーに対しては、キャッシュが構築されるまでの応答時間が遅くなる可能性があります。
Azure での WordPress のホスティング オプション
WordPress は、App Service、Azure Kubernetes Service (AKS)、Azure Virtual Machines で実行できます。 インストールのサイズは、選択するホストの重要な要素です。 小規模から中規模のインストールの場合は、App Service がコスト効率の高いオプションです。 ただし、大規模なインストールの場合は、AKS または VM ホスティングを検討する必要があります。
App Service 上の WordPress
Microsoft は、App Service on Linux VM で WordPress を実行するためのフル マネージド ソリューションを提供しています。 詳細については、「WordPress サイトの作成」を参照してください。 このソリューションの内容:
- WordPress インストールをすばやく簡単にデプロイできるように設計されています。
- 小規模から中規模の WordPress インストールに最適です。
- 複雑な構成や管理を必要とせずに Azure プラットフォームのスケーラビリティ、信頼性、セキュリティを提供します。
- サイトを常に使用可能にするために、自動更新、バックアップ、監視を実行します。
詳細については、「App Service 上の WordPress」を参照してください。
ストレージ集中型のワークロード
大規模な WordPress インストールは、ストレージを集中的に使用する可能性があります。 これらのシナリオでは、高 IOPS クラスで低待機時間のストレージ ソリューションを使用する必要があります。 Azure NetApp Files の使用をお勧めします。 Azure NetApp Files は、ストレージを集中的に使用する WordPress デプロイをサポートできます。 また、データ保護、バックアップと復元、リージョン間レプリケーション、ディザスター リカバリーなどの追加機能も提供します。
WordPress のコンテナー デプロイには、AKS を使用する必要があります。 Azure NetApp Files では、Kubernetes Container Storage Interface (CSI) ドライバーを使用してストレージを実装します。 Azure NetApp Files には、ReadWriteManyすべてのノードが同じストレージに対する読み取りと書き込みを行えるモードが用意されています。 詳細については、「AKS WordPress アーキテクチャ」を参照してください。
VM 上で実行される大規模な WordPress インストールの場合は、ネットワーク ファイル システム (NFS) プロトコルを使用して Azure NetApp Files をマウントする必要があります。 詳細については、「仮想マシン上の WordPress」を参照してください。
不変 WordPress コンテナー
従来のホスティング方法に代わるアプローチは、WordPress を不変コンテナー内にデプロイすることです。 このアプローチには長所と短所があります。 不変コンテナー内のソース コードとすべてのリソースは固定されており、デプロイ後に変更することはできません。 コンテナー イメージのバージョンが更新された場合は、新しいプラグインのインストールや WordPress コアの更新を含むすべての変更が必要になります。 この方法は一貫性の確保とロールバックの簡易化に役立ちますが、変更を加えるためのデプロイ パイプラインを構築する必要があります。 また、不変コンテナーでは、提供される永続ストレージ オプションが制限される場合があります。 メディア ファイルやその他のデータを処理するためのソリューションの開発が必要になる場合があります。 これらの制限にもかかわらず、不変コンテナーのデプロイには、セキュリティ、スケーラビリティ、移植性の点で利点があります。
カスタム コンテナー イメージを使用して、Azure Container Apps、AKS、App Service など、さまざまなプラットフォームに WordPress の不変コンテナー化バージョンをデプロイすることができます。 Azure Container Registry でコンテナー イメージをホストすることができます。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Vaclav Jirovsky | クラウド ソリューション アーキテクト
その他の共同作成者:
- Adrian Calinescu | シニア クラウド ソリューション アーキテクト
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。
次の手順
製品ドキュメント:
- Azure Front Door とは
- Azure Web アプリケーション ファイアウォールとは
- Azure Key Vault について
- Azure Load Balancer の概要
- Azure Application Gateway とは
- Azure Virtual Network とは
- Azure Firewall とは
- VPN ゲートウェイとは
トレーニング モジュール: