SSL/TLSサーバー証明書の更新方法には、Webサーバー上でACME（Automated Certificate Management Environment：アクミー）を利用する方法や、ACM（AWS Certificate Manager）で証明書を管理する方法などがあります。
ACMEを利用すれば証明書の取得・更新を自動化できますが、ACMEクライアントの設定や更新結果の確認、Webサーバーへの反映といった運用はサーバー側に残ります。
今回ご紹介するのは、コーポレートサイトのリニューアルに伴い、WordPressを稼働させるAWS環境を構築し、ALB（Application Load Balancer）＋ACMでSSL/TLSサーバー証明書を管理する構成を採用した事例です。
今回の要件ではサーバーの冗長化は求められていなかったため、当初はWordPressを単一のAmazon EC2で稼働させる構成を想定していました。
しかし、サイト公開後の継続的な運用まで考え、SSL/TLSサーバー証明書の管理をEC2から切り離すため、Application Load Balancer（ALB）とACMを利用する構成を採用しました。
ALBの導入後も、サーバーやCMSのアップデート、監視・復旧、WAF、DNS、バックアップまでクロジカが継続して管理しています。
目次
保守・セキュリティ体制を含めてコーポレートサイトを刷新
お客様は、既存のコーポレートサイトをリニューアルし、情報発信の方法やデザイン、CMSの操作性を見直すことを検討していました。
一方、課題はWebサイトの見た目や更新機能だけではありませんでした。
既存サイトでは、表示崩れやWordPressのアップデートに伴う不具合が発生した際に、速やかに対応できる保守体制が十分に整っていませんでした。
WordPress関連のメンテナンスも不足しており、過去にサイバー攻撃を受けたこともありました。
そこで、サイトリニューアルに合わせて、次の範囲を含むインフラと運用体制を再構築することになりました。
- AWS上のサーバー構築・管理
- WordPressとセキュリティ対策の保守
- サーバーやWebサイトの監視・障害対応
- バックアップ
- OS・ミドルウェアのアップデート
お客様からは、サーバーの管理・保守を外部へ委託し、問い合わせや障害発生時の対応フローを明確にしたいというご要望もありました。
クロジカは、コーポレートサイトを稼働させるAWS環境の構築だけでなく、公開後の監視・保守まで含めて構成を検討しました。
単一EC2構成ではSSL/TLSサーバー証明書の更新・管理がWebサーバーに残る
今回の要件では、複数台のサーバーによる冗長化は求められていませんでした。そのため、WordPressを単一のEC2で稼働させ、本番環境とステージング環境を同じサーバー内に配置する構成を想定していました。
また、次の要件にも対応する必要がありました。
- 全ページへのSSL/TLS適用
- WAFの導入
- 1日1回のバックアップ
- サーバーやWebサイトの監視
- 障害発生時の復旧対応
- WordPressの継続的なアップデート
この構成でEC2上のApacheがHTTPS通信を受ける場合、SSL/TLSサーバー証明書もEC2上で管理することになります。
具体的には、次のような対応がWebサーバー側に残ります。
- SSL/TLSサーバー証明書の取得
- 証明書と秘密鍵の配置
- Apacheへの設定
- 証明書更新時の差し替え
- 設定の再読み込み
- 更新後の動作確認
- 更新エラーの確認
ACMEを利用すれば、証明書の取得や更新は自動化できます。
ただし、ACMEクライアントや秘密鍵、更新設定はEC2上に置かれます。証明書が正しく更新されたか、Apacheへ反映されたか、エラーが発生していないかを確認する運用も必要です。
そこでクロジカは、EC2上で証明書更新を自動化するだけでなく、HTTPS通信の受付と証明書管理そのものをWebサーバーから切り離す構成を検討しました。
ALB＋ACMでHTTPSの受付とSSL/TLSサーバー証明書の管理をEC2から分離
クロジカは、EC2の手前にALBを配置し、利用者からのHTTPS通信をALBで受ける構成を採用しました。
SSL/TLSサーバー証明書はACMで発行・管理し、ALBへ関連付けます。
ALBからEC2へ通信を転送することで、EC2上では公開向けのSSL/TLSサーバー証明書を直接管理しない構成としました。
ALB＋ACMを利用した構成
この構成では、各サービスが次の役割を担います。
| サービス | 役割 |
|---|---|
| ALB | 利用者からのHTTPS通信を受け、EC2へ転送する |
| ACM | SSL/TLSサーバー証明書を発行・管理する |
| EC2 | WordPress、Apache、PHP、MariaDBを稼働させる |
| SiteGuard | Webアプリケーションへの攻撃を検知・防御する |
EC2上で公開向けの証明書を取得・更新・差し替えるのではなく、ALBとACMの組み合わせでHTTPS通信と証明書を管理します。
これにより、EC2を再構築する場合でも、ALBで利用する公開向けの証明書を新しいEC2へ配置し直す必要がありません。
ALBの構築後も、クロジカが設定・管理を継続しています。
ALB＋ACMを採用した理由
SSL/TLSサーバー証明書の更新に対応する方法は、ALB＋ACMだけではありません。
今回の要件に対して考えられる主な選択肢を整理すると、次のとおりです。
| 構成 | 特徴 | 主な留意点 |
|---|---|---|
| EC2＋ACME | EC2とApacheを中心とした構成を大きく変えず、証明書の取得・更新を自動化できる | ACMEクライアント、秘密鍵、更新設定、Apacheへの反映確認をEC2上で管理する |
| CloudFront＋ACM | CDNやキャッシュ配信を利用し、利用者とCloudFront間の証明書をACMで管理できる | CloudFrontを導入する目的や、CloudFrontからEC2までの通信方式を別途設計する必要がある |
| ALB＋ACM | HTTPS通信の受付と証明書管理をEC2から分離できる | ALBの設定・管理が必要になる |
EC2＋ACMEでは、Webサーバー側の構成を維持しながら証明書更新を自動化できます。一方で、ACMEクライアントや秘密鍵、更新処理、Apacheへの反映確認はEC2上に残ります。
CloudFront＋ACMは、コンテンツのキャッシュ配信やオリジンサーバーへの負荷軽減を目的とする場合に有力な選択肢です。ただし、今回の案件ではCDNやキャッシュ配信の導入が主目的ではありませんでした。
今回重視したのは、証明書の更新だけを自動化することではなく、次の状態を実現することです。
- HTTPS通信の受付をEC2から分離する
- 公開向けの証明書管理をEC2上に残さない
- EC2上で公開向けの証明書を差し替えない
- EC2を再構築する場合も証明書を再配置しない
- サーバー保守とALBの管理をクロジカが継続する
これらの条件に合わせ、ALB＋ACMを採用しました。
ACMで発行した証明書は、必要な条件を満たしていれば自動更新の対象となります。
ALB導入後もサーバー・CMS・セキュリティを継続管理
今回の対応は、ALBとACMを導入して完了ではありません。
クロジカは、AWS環境の構築後も、サーバー、CMS、セキュリティ製品、DNS、バックアップを含めて継続的に管理しています。
監視・復旧
Webサイトやサーバーの異常を検知するため、次の監視を行っています。
- 死活監視
- ポート監視
- サービス監視
- リソース監視
監視システムが異常を検知した場合は、クロジカの運用担当エンジニアへアラートが通知されます。
サイトが停止している場合は、クロジカが原因を調査し、復旧対応を行います。
その後、お客様へ状況の一次報告と復旧報告を実施し、必要に応じて障害報告書を作成して報告します。
OS・ミドルウェア保守
構築時には、次の環境を設定しました。
- AlmaLinux
- Apache
- PHP
- MariaDB
公開後は、OSやミドルウェアについて次の対応を行います。
- セキュリティアップデート
- 通常アップデート
- ログ調査
- 必要に応じた設定変更
- パフォーマンスや稼働状況に応じた構成の確認
重大なセキュリティアップデートが公開された場合は、お客様へ連絡し、対応内容や実施スケジュールを調整します。
CMS保守
WordPressについても、サイト公開後の保守を行っています。
- WordPress本体・プラグインの定期アップデート（年2回）
- セキュリティアップデート公開時の前倒し対応
- CMSに関する問い合わせ対応
- 異常発生時のログ調査と対応方針の案内
定期的なアップデートだけでなく、セキュリティ上の緊急性が高い場合は、お客様と調整したうえで予定を前倒しして対応します。
AWS・セキュリティ管理
AWS環境やセキュリティ製品について、次の管理を行っています。
- ALBの設定・管理
- DNSレコードの設定・変更
- SiteGuardの検知内容の確認
- 誤検知時の除外設定
SiteGuardについては、検知内容を確認し、誤検知と判断した場合は、お客様と相談したうえで除外設定を反映します。
バックアップ
バックアップについては、次の対応を行っています。
- 1日1回のバックアップ取得
- 3世代のバックアップ保管
- お客様の要望に応じたリストア
このように、ALBや証明書だけでなく、サイト公開後の監視、アップデート、セキュリティ対策、バックアップまで含めて管理しています。
ALB＋ACMの導入によって変わったこと
ALB＋ACMを採用したことで、SSL/TLSサーバー証明書の管理方法と、HTTPS通信を受ける場所が次のように変わりました。
| ALB追加前の想定 | ALB＋ACM採用後 |
|---|---|
| EC2上でSSL/TLSサーバー証明書を管理 | ACMで証明書を管理し、ALBへ関連付け |
| 証明書更新時にEC2への配置とApacheへの設定反映が必要 | EC2上で公開向けの証明書を差し替えない構成へ変更 |
| HTTPS通信の受付とWebサイトの処理を同じEC2上で実施 | HTTPS通信の受付をALBへ分離 |
| ACMEを利用する場合は、ACMEクライアントをEC2上で管理 | EC2上に公開向けの証明書更新処理を置かない |
| ALBを利用しない構成 | ALBの設定・管理もクロジカの保守範囲に追加 |
なお、EC2は1台のままであるため、ALBを追加しただけでWebサイト全体を冗長化したわけではありません。
今回の主な変更点は、HTTPS通信の受付と、公開向けの証明書の取得・更新・差し替えをEC2から切り離したことです。
まとめ｜SSL/TLSサーバー証明書管理をEC2から切り離すためALB＋ACMを採用
今回の案件では、複数のEC2への負荷分散やサーバーの冗長化を主目的としてALBを採用したわけではありません。
コーポレートサイトの継続運用を見据え、SSL/TLSサーバー証明書の更新に伴う運用負荷を抑えるため、証明書を管理する場所から見直しました。
EC2上でACMEを利用する方法もありますが、その場合は証明書の更新処理や確認作業がWebサーバー側に残ります。そこでクロジカは、ALBでHTTPS通信を受け、ACMでSSL/TLSサーバー証明書を管理する構成を採用しました。
これにより、EC2上で公開向けの証明書を取得・更新・差し替えない構成としています。
また、構築後もALBの設定・管理、サーバー監視、障害時の調査・復旧、OS・ミドルウェア、WordPress、SiteGuard、DNS、バックアップまでクロジカが継続して管理しています。
SSL/TLSサーバー証明書の更新方法とAWS構成をご相談ください
SSL/TLSサーバー証明書の更新方法は、EC2上でACMEを利用する方法だけではありません。
現在のサーバー構成やWebサイトの配信方法、運用体制によっては、ALB＋ACMやCloudFront＋ACMを利用し、証明書管理をWebサーバーから切り離す方法も選択肢になります。
クロジカサーバー管理では、次のような内容を確認したうえで、運用要件に適した構成をご提案します。
- 現在のSSL/TLSサーバー証明書の管理方法
- 証明書更新時に行っている作業
- WebサーバーやCMSの構成
- ALBやCloudFrontの利用状況
- 証明書更新に失敗した場合の対応体制
- サーバーやCMSの監視・保守体制
証明書の更新だけを自動化するべきか、HTTPS通信の受付や証明書の管理場所から見直すべきか判断できない場合もご相談いただけます。
SSL/TLSサーバー証明書の更新方法とAWS構成を相談する
コーポレートサイトをクラウドでセキュアに
クラウドサーバー管理
クロジカガイドブック
- コーポレートサイト構築・運用の課題を解決
- クロジカクラウドサーバー管理の主な機能
- 導入事例
- 導入までの流れ
