【AWS】採用ランディングページを CloudFront+S3 で公開した話

はじめに

魅力的なランディングページは、優秀な人材を獲得するために必要不可欠なコンテンツと言えます。

コンテンツを公開する手法はいくつか存在していますが、CMS（コンテンツ管理システム）としてサードパーティ製品を活用する場合、製品の脆弱性の管理と対策が重要な検討項目として挙げられます。

この記事では WordPress を利用した採用ランディングページの制作において、セキュリティの観点から静的コンテンツへの変換モジュールを活用し、Amazon CloudFront と Amazon S3 と連携してコンテンツをセキュアに公開するアーキテクチャについて説明します。

公開した採用ランディングページはこちらです。

本記事はアーキテクチャ検討の背景/選定理由を中心に執筆した記事となります。 WordPress の機能説明や構築手順、ソースコードなどに関する解説は含まれていません。

WordPressのセキュリティリスク

WordPressは非常に人気のあるCMSであり、多くのウェブサイトで利用されていますが、その人気と活用事例の多さから脆弱性活用を含めた攻撃手法も多く、セキュリティ対策を考えないままの利用は企業として非常に高いリスクを伴うと考えました。
以下では私たちが今回のコンテンツアーキテクチャを検討するにあたって、WordPressの問題点と捉えた事項を明確にし、それを最小化するためのアプローチについても記載します。

私たちが考えるWordPressの問題点①：脆弱性管理の必要性

WordPressはオープンソースのソフトウェアであり、テーマやプラグインの豊富さが最大の魅力と言えます。しかし、利用が活発なオープンソースであるが故に多数の脆弱性が潜んでいる恐れもあります。
JVN iPedia で WordPress に関する 2022年一年間の脆弱性は、緊急（CVSS v3スコア 9.0～10.0）と重要（CVSS v3スコア 7.0～9.8）に絞っても240件程となり、その大半がSQLインジェクションやXSRFといった脆弱性であり、情報漏洩につながりかねない危険なものです。
これらの脆弱性を検知し対応する必要性と頻度が他の製品よりも高いのではと懸念を抱きました。

私たちが考えるWordPressの問題点②：アップデート運用の負荷

導入するプラグインが増える事はアップデートやパッチ適用の機会が増える事を意味します。この為、システムとしてアップデートやセキュリティパッチを適用する運用が確立されていなければ、脆弱性管理が忘れさられ、アップデートされず放置され、結果的にセキュリティリスクが増大する状況になってしまいます。
便利で豊富なテーマやプラグインが日々産まれ、それを活用する事自体は決して否定されるべき事ではありませんが、運用を的確に実施してく前提が必須であると考えました。

セキュリティリスクを最小化するためのアプローチ

前述の問題に対して、以下のアプローチをとる事としました。

• そもそもWordPress自体を外部公開しない
  攻撃表面の縮小（ASR：Attack Surface Reduction）の考え方ですが、リスクが存在しそれを積極的に外部公開する必要がないのであればそもそも「外部ネットワークに晒さない」ことが最善と考え、WordPressをプライベートネットワーク内にとどめられないか、と考えました。
  その1つの実現方式としてWordPressプラグインでコンテンツを静的化し、S3にアップロードし、CloudFrontを介して公開する方式を採用することとしました。
  　
• 構成情報を可視化し、アップデートを行う
  WordPressのバージョン情報に加えて、利用されているプラグインとその情報を可視化する事が必要です。
  構成情報の可視化については弊社のこちらの記事で紹介した仕組みを活用する方針としています。
  アップデートについては運用の必要性を明確化し、コンテンツだけではなくシステム自体を運用保守担当に対してしっかりと引き継ぐ方針としました。
  　
• セキュリティプラグインの導入
  外部ネットワークに公開しないとはいえWordPress自体を守る必要性がなくなる訳ではありません。
  その為セキュリティプラグインを導入する方針としました。

サイトアーキテクチャ

前述の通り CloudFront+S3 のアーキテクチャを採用していますが、ここからはその説明となります。

CloudFront+S3について

Amazon S3とAmazon CloudFrontを使用したアーキテクチャを選択した理由としては以下の４点が挙げられます。

• セキュリティ向上
• 高可用性
• 高速な読み込み速度
• コスト効率

構成イメージとアーキテクチャの説明

各AWSサービスの利用用途は以下の通りです。

• Amazon S3
  静的コンテンツを格納し、外部公開。
• CloudFront
  S3に格納されたコンテンツをキャッシュし、高速な配信を実現。
• AWS WAF
  悪意のあるトラフィックからの保護。
• EC2
  WordPressが稼働。プラグイン wp2static を利用し、静的コンテンツへの変換/S3へのアップロードを実施。
• ALB
  ターゲットとしてEC2（WordPress）を指定し、セキュリティグループではコンテンツ管理者のみがアクセスできるようにルールを設定。

WordPressコンテンツの静的化とS3へのアップロード

前述したように、 WordPress コンテンツの静的コンテンツへの変換とS3へのアップロードはwp2static を利用しています。
アップロードする流れは以下の通りです。

1. ALBを介してEC2上で稼働するWordPressにアクセス
2. WordPress上でコンテンツ更新（記事作成など）
3. wp2static の機能で静的コンテンツへの変換、S3へのアップロードまでを自動で実施

最後に

この記事では、採用ランディングページのセキュリティリスクに焦点を当て、セキュアなアーキテクチャについて説明しました。

運用をシンプルにする方法として、CloudFront+S3のアーキテクチャを採用することもできます。
また、WordPressが稼働するEC2はコンテンツ更新用途であるため、EventBridge Schedulerを利用して休日夜間は停止状態にする仕組みを実装して、コスト削減を実現しています。

WordPressで制作したコンテンツが静的コンテンツの場合のみに限定されてしまいますが、皆さんも機会があれば紹介したアーキテクチャを検討してみてください。