本ブログの基盤アーキテクチャについて

この記事は、本ブログの基盤アーキテクチャを記録した技術ドキュメントである。
主な目的は、技術的背景に関心のある人が構成を把握できること、
および将来の自分が運用・復旧判断を行うための記録を残すことにある。

具体的な認証情報や設定値などの秘匿情報は、本記事には記載しない。

全体構成概要

本ブログは、ConoHa VPS 上で Docker コンテナとしてホストしている。
WordPress 本体およびデータベースは、それぞれ独立した Docker コンテナとして稼働しており、
HTTPS 終端およびリバースプロキシは Traefik によって管理している。

ドメインのネームサーバ（NS）は ConoHa VPS を利用しているが、
ドメインレジストラの詳細については本記事では公開しない。

WordPress およびデータベースの各コンテナは、
ホストネットワークから直接アクセスできない内部ネットワーク上に配置している。

外部からの通信は Traefik コンテナのみが受け付け、
WordPress への通信経路は Traefik を経由したものに限定している。

これにより、アプリケーションコンテナが
ホストネットワークや他サービスへ直接露出しない構成としている。

WordPress 本体のアップデートは、
Docker イメージの更新およびコンテナの再作成によって行う。

そのため、WordPress のアプリケーション領域は
コンテナ内で読み取り専用となっており、
実行中に書き込みが行われることはない。

一方で、プラグインおよびテーマについては
永続ボリュームとして切り出されており、
管理画面からのホットアップデートを許可している。

この構成により、

という運用と安全性のバランスを取っている。

WordPress およびデータベースの永続データは、
VPS 上のローカルブロックストレージに保存している。

バックアップは cron により定期的に実行され、
rclone sync を用いて暗号化されたリモートストレージへ同期される。

バックアップデータは、転送前にクライアント側で暗号化（E2EE）されている。
このため、バックアップ先の SaaS やストレージ事業者が侵害された場合であっても、
保存されているバックアップデータを復号することはできない。

復号鍵はバックアップ実行環境のみが保持しており、
バックアップ先には平文データおよび鍵情報は存在しない。

本ブログのセキュリティ設計は、ゼロトラストアーキテクチャの考え方に基づいている。

WordPress やプラグインに未知の脆弱性（ゼロデイ）が存在し、
将来的にアプリケーション層が侵害される可能性があることを前提としている。

そのため、「侵害を完全に防ぐ」ことではなく、
侵害された場合に影響範囲を局所化し、復旧可能であることを重視している。

コンテナ分離、単一の通信経路（Traefik）、
アプリケーション領域の読み取り専用化、
永続データの外部化、および E2EE によるバックアップは、
この前提に基づく設計である。

本構成は固定されたものではなく、
運用・脅威モデルの変化に応じて随時見直すことを前提としている。