Struts2掲示板アプリケーション開発連載の最終回では、本番公開を想定したインフラ構成とセキュリティ設計について解説します。
🔰 前提:公開範囲を限定したい
本掲示板アプリケーションでは、インターネット側にはログイン画面のみを公開し、認証済ユーザーのみがアプリ本体(掲示板一覧や投稿画面等)へアクセスできる構成を想定します。
そのため、次のような構成が適切です:
1. Apache HTTP Server(公開)
-
HTTPS対応(Let's Encrypt等で証明書取得)
-
公開URLは
/login
のみ(mod_rewrite / mod_authz_host で制限) -
認証済みユーザーのみ
/app/*
や/thread/*
等のURLへアクセス可 -
ApacheがリバースプロキシとしてTomcatへ接続(ProxyPass / mod_proxy_ajp)
2. Tomcat(非公開)
-
ローカルのみ接続可(127.0.0.1 または内部サブネット限定)
-
Struts2で認証/認可処理、セッション管理を実装
3. その他
- AWS EC2構成であれば、Security GroupでHTTPポート(80, 8080)は閉じ、443のみ許可
🔐 Apache側の設定例(抜粋)
<VirtualHost *:443>
ServerName example.com
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
ProxyRequests Off
ProxyPreserveHost On
ProxyPass "/app" "http://127.0.0.1:8080/app"
ProxyPassReverse "/app" "http://127.0.0.1:8080/app"
# 公開範囲制限(ログイン以外を拒否)
<Location "/">
Require all denied
</Location>
<Location "/login">
Require all granted
</Location>
<Location "/app">
Require all granted
</Location>
</VirtualHost>
🧩 Struts2 側の認証処理(要点)
struts.xml の例
<interceptors>
<interceptor name="authInterceptor" class="com.example.interceptor.AuthInterceptor" />
</interceptors>
<action name="*" class="com.example.actions.*">
<interceptor-ref name="authInterceptor" />
<result name="login">/login.jsp</result>
<result name="success">/WEB-INF/view/xxx.jsp</result>
</action>
AuthInterceptor.java
public class AuthInterceptor extends AbstractInterceptor {
public String intercept(ActionInvocation invocation) throws Exception {
Map<String, Object> session = invocation.getInvocationContext().getSession();
if (session.get("user") == null) {
return "login"; // 未ログインの場合はlogin.jspへ
}
return invocation.invoke();
}
}
🔒 セキュリティ強化のための追加対策
-
ApacheでのIP制限(社内IPだけ許可など)
-
mod_security や WAFの導入(AWS WAF, Cloudflareなど)
-
HTTPS強制リダイレクト
-
セッション固定攻撃対策:ログイン時にセッションID再発行
-
CSRFトークンの導入(Struts2のTokenInterceptor活用)
-
Cookieに HttpOnly, Secure 属性を付与
✍️ まとめ
本記事では、Struts2掲示板アプリケーションを安全に本番公開するためのApache + Tomcat構成、およびセキュリティ設計の基本をご紹介しました。
公開はログイン画面のみに限定し、Tomcatは内部専用とする設計が堅牢で現実的です。
さらに実運用でのセキュリティ強化(WAF、脆弱性診断、ログ管理等)については、今後別途特集記事にて紹介予定です。
これにてVol.11シリーズ(全22回)を完結とします。 お読みいただきありがとうございました!
🧭 関連記事(Vol.11.xxxシリーズ)
連番 | タイトル | 内容分類 |
---|---|---|
Vol.11.0 | Struts2が提供してくれる便利機能まとめ9選 | 導入&概要 |
Vol.11.1 | 自動注入とステートレスActionの仕組み | フレームワーク内部理解 |
Vol.11.2 | UX改善に効く!アクション層設計と入力制御の極意(プロローグ) | UX設計・アクション層総論 |
Vol.11.2.1 | 【実践編】Struts2アクション層の役割と設計パターン(Command型 / UIアクション分離など) | アクション設計パターン |
Vol.11.2.2 | 【UX重視】戻るボタン・キャンセル処理の設計手法と「戻り先管理」のスマート実装 | 戻り先制御とUX設計 |
Vol.11.2.3 | 【設計ノウハウ】多画面遷移時のパラメータ受け渡し・保持戦略(セッション vs hidden vs URL) | パラメータ多重管理 |
Vol.11.2.4 | 【実践ガイド】ユーザー操作を考慮したアクション遷移設計(リダイレクト vs フォワードの使い分け) | UX遷移設計/Result制御 |
Vol.11.2.5 | 【トラブル防止】アクション層の共通処理とメンテナブルなBaseAction設計 | アクション共通化/保守性 |
Vol.11.3 | Struts2の defaultStack とは?Interceptorの中身を詳しく追ってみる | Interceptor |
Vol.11.3.2 | 🔧 Vol.11.3.2 独自Interceptorの作り方と使い所 Struts2のカスタマイズを“実践で使えるレベル”に一歩進めよう | Interceptor |
Vol.11.4 | 入門者のための「パラメータ自動バインディング」完全理解ガイド | 自動バインディング |
Vol.Vol.11.4.1 | 入門者のための自動バインディング実践パターン集 | 自動バインディング |
Vol.11.5 | Struts2の構成理解が“実務レベル”へと進化する決定版 | 設定ファイル構造 |
Vol.11.5.1 | Struts2の“画面遷移の全体像”を理解するためのマイルストーン記事 | 設定ファイル構造 |
Vol.11.6 | ActionSupport の便利メソッドと国際化対応 | ユーティリティ / i18n |
Vol.11.7 | validate() / input 戦略とUX設計 | 開発スタイルの違い |
Vol.11.8 | アノテーションベースの設定 vs XML定義の比較 | 開発スタイルの違い |
Vol.11.9 | バリデーション完全解説(XML / アノテーション) | バリデーション(※Vol.8補完) |
Vol.11.10 | Struts2の「OGNL」ってなに?しくみと使い方をやさしく解説 | 式言語OGNL解説 |
Vol.11.11 | ModelDriven インターフェースの使いどころと注意点 | Model駆動開発 |
Vol.11.12 | SessionAware と RequestAware でセッション/リクエスト管理 | セッション管理 |
Vol.11.13 | Resultタイプ完全解説(dispatcher / redirect / stream など) | 遷移パターン理解 |
Vol.11.14 | Vol.11.14 ValueStackの中身を理解する – 画面とActionの橋渡し役 | Action |
Vol.11.15 | Interceptorチェーンを自作してみよう(ログ / 認証フィルタ) | Interceptor |
Vol.11.16 | エラー処理と例外ハンドリングの実践パターン | ハンドリング設計 |
Vol.11.17 | Struts2でファイルアップロード機能を実装する方法 | 実装系Tips |
Vol.11.18 | 非同期通信(AJAX)とStruts2の連携方法 | フロント連携編 |
Vol.11.19 | セキュリティ対策(CSRF, XSS, パラメータ偽装) | セキュリティ対策 |
Vol.11.20 | 複数フォームを安全に扱う!セッション管理と動的フォームの考え方 | セッション管理 |
Vol.11.21 | Struts2でJSONを返す!REST API連携と非同期通信の基本設計 | セッション管理 |