Security Architecture & Network Model
本プロジェクト「Docker Infrastructure」のセキュリティ設計、ネットワーク構成、および現在の実装におけるセキュリティ上の考慮点（メリット・リスク）について解説します。
1. ネットワーク境界とポート構成
本環境は、ホストOS（物理マシン/学校PC）とゲストOS（VirtualBox Debian）の間に明確な境界を持ち、必要最小限のポートのみを開放する 「最小権限の原則」 に基づいています。
ネットワーク構成図
ポート開放の理由
| Port | Service | 役割・理由 |
|---|---|---|
| 443 | HTTPS | Webサイトへのアクセス用。TLSv1.2/1.3のみ許可し、セキュアな通信を強制します。http(80)は開放しません。 |
| 4242 | SSH | 管理用アクセス。標準の22番ではなく4242番を使用することで、自動化された攻撃（Bot）を簡易的に回避します。 |
| 21 | FTP | コンテンツ編集用（ボーナス）。平文通信であるため、セキュリティリスクがあります（後述）。 |
| 21100-21110 | FTP(Passive) | FTPのデータ転送用。コンテナ環境(Docker)ではパッシブモードが必須であるため、範囲を指定して開放しています。 |
2. 安全なアクセス技術
2.1 SSHトンネリングによるGit操作 (Secure Git)
Git Daemon自体は暗号化機能を持たないプロトコル（ポート9418）ですが、SSHトンネルを使用することで安全な通信経路を確立しています。
メリット:
- 認証: SSHキーを持つ管理者のみがGitリポジトリにアクセス可能。
- 暗号化: 経路上の盗聴を防ぐ。
- 設定不要: ゲストOS側で新たにポートを開放する必要がない（既存のSSHポートを利用）。
2.2 SOCKSプロキシとドメイン解決
ホストOSのブラウザから https://local.dev のようなドメインでゲストOSにアクセスするために、SSHの Dynamic Port Forwarding (SOCKS Proxy) を利用しています。
- 仕組み: ブラウザの通信を全てSSHトンネル経由でゲストOSに送る。
- メリット:
/etc/hostsを書き換えずとも、ゲストOS視点でのドメイン解決が可能になる。DNS汚染のリスクがない。
3. 現在のセキュリティ課題 (FTP)
FTP (File Transfer Protocol) のリスク
現在の実装では、FTPサーバー（vsftpd）は 「Plain FTP（平文）」 で動作しています。
- 現状: ログインID、パスワード、転送ファイルの内容が全てネットワーク上にそのまま流れます。
- 対策: 本番環境では FTPS (FTP over SSL) または SFTP (SSH File Transfer Protocol) を使用すべきです。今回は教育的課題（FTPプロトコルの理解）のためにあえてプレーンなFTPを実装していますが、実際の運用では非推奨です。
4. アプリケーション層の防御 (WAF)
Nginxには ModSecurity (WAF) が組み込まれており、SQLインジェクションなどの攻撃を防ぎます。
- 検知: リクエストヘッダ、ボディに含まれる悪意あるパターンを正規表現でチェック。
- 防御: 攻撃と判断されたリクエストはWordPressに到達する前に遮断されます。
5. 理想的な運用環境 (Production) への改善案
実際の運用環境（Production）を目指す場合の改善アーキテクチャ案です。
推奨される改善点
- FTPの廃止: SFTPまたはデプロイメントパイプライン（CI/CD）のみを利用し、FTPポート(21)は閉鎖する。
- 踏み台サーバー (Bastion): SSHアクセスを専用の踏み台サーバー経由に限定する。
- DBの完全分離: MariaDBを外部から完全に遮断し、Private Network内でのみ通信させる（現在はDocker Network内ですが、ホストボリューム等は慎重に管理）。