SSL/TLSサーバー証明書の有効期間短縮に伴い、これまでよりも頻繁な証明書更新への対応が求められるようになります。
証明書の更新はACME（Automatic Certificate Management Environment：アクミー）によって自動化できますが、サーバーごとにACMEクライアントを導入する場合、設定や動作確認、更新状況の確認といった運用はサーバー側に残ります。
今回ご紹介するのは、オンプレミスで運用していたWebサイト基盤をAWSへ移行する中で、WebサーバーだけでなくCMSサーバーもALB配下に配置し、SSL/TLSサーバー証明書の管理方法をACM（AWS Certificate Manager）へ統一した事例です。
AWSへの移行だけでなく、CloudFrontによるコンテンツ配信、AWS WAFによるセキュリティ対策、構築後の監視・保守まで含めてWebサイトの運用体制を見直しました。
目次
オンプレ環境の保守負担とコスト見直しのご相談
ご相談いただいたお客様は、Webサイトをオンプレミス環境で運用していました。
既存環境では、OSのアップデートや脆弱性への対応が十分に追いついておらず、情報システム部門がWebサイト基盤の保守を継続して担うことにも負担が生じていました。
また、Webサイトのコンテンツ配信には既存のCDNを利用していましたが、配信にかかるコストも見直したいというご要望がありました。
クロジカは、現在のオンプレミス環境を継続する場合と、Webサイト基盤をクラウドへ移行する場合を比較し、今後の保守性や運用負担、コストを踏まえて構成を検討しました。
その結果、既存環境をそのまま維持するのではなく、Webサイト基盤をAWSへ移行し、構築後の監視・保守もクロジカが継続して支援する方針となりました。
AWSへの移行構成を検討する中で、新たな論点となったのが、今後のSSL/TLSサーバー証明書の更新方法です。
既存環境を活かし、Webサイト基盤と運用をAWSへ移行
既存環境では、コンテンツ管理用のCMSサーバーと、一般閲覧者向けの公開Webサーバーが分かれていました。
公開Webサーバーは複数台で冗長化されており、コンテンツ配信にはCDNを利用していました。
一方、CMSについては既存のシステムを継続利用する必要があり、AWSへの移行後も従来のコンテンツ更新方法を維持することが求められていました。
そのためクロジカは、オンプレミス上のサーバーをそのままAWSへ置き換えるのではなく、次の範囲をまとめて見直しました。
- 公開Webサーバーとコンテンツ配信基盤
- SSL/TLSサーバー証明書の管理
- セキュリティ対策
- 監視・障害対応
- OS・ミドルウェアの保守
- バックアップ
一般閲覧者向けの公開Webサーバーについては、ALBでHTTPS通信を受け、ACMでSSL/TLSサーバー証明書を管理する構成をご提案しました。
一方、CMSサーバーは当初、ALBの配下には置かず、サーバー上でSSL/TLSサーバー証明書を管理する想定でした。
しかし、このままでは、公開WebサーバーとCMSサーバーで証明書の更新・管理手順が分かれ、確認や対応をそれぞれ行う必要があります。
そこでクロジカは、公開Webサーバーだけでなく、CMSサーバーのSSL/TLSサーバー証明書をどのように更新・管理するかについても検討しました。
CMSサーバーもALB配下に配置し、SSL/TLSサーバー証明書管理をACMに統一
公開Webサーバーについては、ALBでHTTPS通信を受け、ACMでSSL/TLSサーバー証明書を管理する構成を想定していました。
一方、CMSサーバーはALBの配下に置かず、CMSサーバー上で証明書を管理する予定でした。
この場合、同じWebサイト基盤の中で、証明書の管理方法が次のように分かれます。
- 公開Webサーバー：ALBとACMで管理
- CMSサーバー：CMSサーバー上で個別に管理
SSL/TLSサーバー証明書の有効期間短縮を見据え、お客様からは、CMSサーバーでACMEを利用して証明書を自動更新できないかというご相談もありました。
ACMEで自動更新しても、サーバー側の運用は残る
ACMEを利用すれば、SSL/TLSサーバー証明書の取得や更新を自動化できます。
ただし、CMSサーバー上でACMEを利用する場合は、次のような対応が必要です。
- ACMEクライアントの導入
- 証明書取得・更新の設定
- Webサーバーへの反映設定
- 更新後の動作検証
- 更新状況やエラーの確認
- ACMEクライアント自体の管理
証明書を自動更新できるようにしても、証明書更新に関する運用がすべてなくなるわけではありません。
また、公開WebサーバーはACM、CMSサーバーはACMEという構成にすると、証明書の管理方法や確認手順も分かれます。
そこでクロジカは、CMSサーバーだけに個別の証明書運用を残すのではなく、CMSサーバーもALB配下に配置する構成をご提案しました。
公開WebサーバーとCMSサーバーのいずれも、ALBでHTTPS通信を受け、ACMでSSL/TLSサーバー証明書を管理する構成とすることで、CMSサーバー上で公開向けの証明書を個別に取得・更新・差し替える必要をなくしています。
ALB＋ACMを中心とした最終構成
最終構成では、一般閲覧者向けのアクセスとコンテンツ管理担当者向けのアクセスを分けながら、公開WebサーバーとCMSサーバーをALB配下に配置しました。
一般閲覧者からのアクセスは、CloudFrontを経由して公開Webサーバーへ配信します。
CloudFrontはコンテンツ配信を担い、AWS WAFによって不正アクセスや大量アクセスへの対策を行います。
コンテンツ管理者は、CMS用のアクセス先からALBを経由してCMSサーバーへ接続します。
ALBは、アクセス先のドメインやルーティング条件に応じて、公開WebサーバーとCMSサーバーへ通信を振り分けます。
利用者からのHTTPS通信はALBで受け、ACMで発行・管理するSSL/TLSサーバー証明書を利用します。
これにより、公開WebサーバーとCMSサーバーのそれぞれに、公開向けのSSL/TLSサーバー証明書を配置して更新する必要がない構成としました。
ALB＋ACMを中心とした構成で変わったこと
今回のAWS移行では、利用するクラウドサービスを変更しただけではありません。
サーバーごとに分かれる可能性があった証明書管理や、お客様が担っていた保守業務を見直し、構築後の運用体制まで含めて再設計しました。
| 見直し前・検討時の状態 | クロジカが行った対応 |
|---|---|
| 公開WebサーバーとCMSサーバーで 証明書管理が分かれる | CMSサーバーもALB配下に配置し、 ALB＋ACMを利用する管理方法へ統一 |
| CMSサーバーにACMEの導入・検証・運用確認が必要になる | CMSサーバー上で公開向けの証明書を個別に更新しない構成へ変更 |
| OS更新や脆弱性対応をお客様側で抱えていた | クロジカがMSP※としてアップデート・保守を継続 |
| 既存CDNのコストを見直したかった | CloudFrontを利用する配信構成へ変更 |
| 不正アクセスや大量アクセスに備える必要があった | AWS WAFを導入し、クロジカがルールを継続管理 |
| 障害時の調査や復旧をお客様側で担っていた | クロジカが監視、原因調査、復旧、報告を担当 |
このように、証明書管理の統一だけでなく、コンテンツ配信やセキュリティ対策、障害対応まで含めて、Webサイト基盤の運用体制を見直しました。
構築後も監視・復旧・アップデートを継続
AWSへ移行した後も、サーバーやAWSサービスを安定して運用するためには、継続的な監視やアップデートが必要です。
クロジカでは、ALBやCloudFrontを構築して完了とするのではなく、Webサイトの公開後も監視・保守を継続しています。
監視・障害対応
サーバーやWebサイトの状態を確認するため、次の監視を行っています。
- 死活監視
- ポート監視
- サービス監視
- リソース監視
監視によって異常を検知した場合は、クロジカの運用担当エンジニアへアラートを通知します。
サイトが停止している場合は、クロジカが原因調査と復旧対応を行い、お客様へ一次報告と復旧報告を実施します。
対応内容に応じて、障害報告書も作成します。
OS・ミドルウェア保守
サーバー上で稼働するOSやミドルウェアについて、クロジカが次の対応を行います。
- セキュリティアップデート
- 通常アップデート
- ログ調査
- 設定変更
重大な脆弱性やセキュリティアップデートが確認された場合は、お客様と対応内容やスケジュールを調整した上で適用します。
バックアップ
1日1回バックアップを取得し、3世代を保管します。
障害や操作ミスなどによってデータの復旧が必要になった場合は、お客様のご要望に応じて、取得済みのバックアップからリストアします。
AWSサービスの設定・管理
サーバーだけでなく、Webサイト基盤を構成するAWSサービスもクロジカが継続して管理します。
- ALBの設定・管理
- CloudFrontの設定・管理
- AWS WAFのルール設定
- 一定条件に該当するIPアドレスのブロック
- 誤検知時のAWS WAFルール設定の調整
AWS WAFについても、ルールを設定して完了とするのではなく、実際のアクセス状況や誤検知の有無を確認しながら、必要に応じて設定を調整します。
まとめ｜SSL/TLSサーバー証明書の更新方法だけでなく、管理場所まで見直す
今回のご相談は、オンプレミス環境における保守負担と、既存CDNを含む運用コストの見直しから始まりました。
クロジカでは、Webサイト基盤をAWSへ移行する中で、公開Webサーバーだけでなく、CMSサーバーのSSL/TLSサーバー証明書をどのように管理するかについても検討しました。
CMSサーバー上でACMEによる自動更新を行う方法もありましたが、その場合は、CMSサーバーだけにACMEクライアントの設定や更新確認といった個別の運用が残ります。
そこで、CMSサーバーもALB配下に配置し、公開WebサーバーとCMSサーバーの証明書管理をACMへ統一しました。
これにより、HTTPS通信の受付とSSL/TLSサーバー証明書の管理をWebサーバーから切り離し、CMSサーバー上で公開向けの証明書を個別に更新しない構成としています。
また、AWSへの移行後も、監視、障害時の原因調査・復旧、OS・ミドルウェアのアップデート、CloudFrontやAWS WAFの設定管理までクロジカが継続して対応しています。
SSL/TLSサーバー証明書の有効期間短縮へ対応する際は、自動更新できるかだけでなく、証明書をどこで管理し、更新失敗やサーバーの構成変更に誰が対応するのかまで含めて設計することが重要です。
SSL/TLSサーバー証明書の更新を含め、Webサイト基盤の構成を見直しませんか
SSL/TLSサーバー証明書の有効期間短縮に対応する方法は、Webサーバー上でACMEを利用する方法だけではありません。
サーバー構成や運用体制によっては、ALB＋ACMやCloudFront＋ACMを利用し、証明書管理をWebサーバーから切り離す方法も選択肢になります。
クロジカクラウドサーバー管理では、現在のサーバー構成、証明書の管理方法、更新時の作業、監視・保守体制を確認したうえで、どの方法が適しているかを整理します。
オンプレミスからAWSへの移行だけでなく、既存のAWS環境におけるALB・ACM・CloudFront・AWS WAFの構成見直しや、構築後の監視・保守まで対応しています。
次のような課題がある場合はご相談ください。
- SSL/TLSサーバー証明書をWebサーバー上で更新している
- 複数のサーバーで証明書の管理方法が分かれている
- ACMEを導入すべきか、ALB＋ACMへ変更すべきか判断できない
- 証明書の更新だけでなく、サーバーの監視・保守も任せたい
- オンプレミス環境や既存CDNを含めて構成を見直したい
現在の構成を確認し、証明書更新だけを部分的に自動化するべきか、証明書の管理場所から見直すべきかをご提案します。
コーポレートサイトをクラウドでセキュアに
クラウドサーバー管理
クロジカガイドブック
- コーポレートサイト構築・運用の課題を解決
- クロジカクラウドサーバー管理の主な機能
- 導入事例
- 導入までの流れ
