これまでの記事で、業務用のデータベース（SQL Server 2022）とBI 環境（Metabase）を VPS 上に同居させた構成について書いた。
今回は、その構成の中で VPN をどうするか悩んだ末に WireGuard を選んだ理由 を、実務目線でまとめておく。
結論から言うと、
頑張ってアプリやシステム側を修正するより、VPN 化したほうが圧倒的に楽だった。
これに尽きる。
まず前提：軽さと安全性が最優先
今回の VPS には、
- SQL Server（業務DB）
- Metabase（BI）
などが同居している。
当然、リソースには余裕を持たせているとはいえ、
VPN サーバーだけ重たい構成にするのは避けたかった。
ここで重視したのは、
とにかく軽量で、構成がシンプルで、安全性が高いこと。
WireGuard について調べてみると、
- ソースコードが短い
- 実装がシンプル
- 攻撃対象になりにくい構造
といった評価が多く、
「これなら余計な事故を起こしにくそうだな」という安心感があった。
OpenVPN や IPSec も当然候補には上がったが、
設定項目の多さ、証明書管理、トラブル時の切り分けを考えると、
ひとり情シスとしては 運用負荷が一段上がる 印象が強かった。
もう一つの決定打：Android アプリ側の修正が面倒だった
実はもう一つ、かなり現実的な理由がある。
社内向けの 業務用 Android アプリ を内製していて、
そこからデータベースや FTP サーバーへ直接アクセスしている。
この通信を、きちんと SSL 化しようとすると、
- DB 接続ライブラリ側の修正
- FTP 通信の暗号化設定
- 証明書管理
- 端末側への配布
…と、地味にやることが多い。
正直なところ、
「セキュリティ的には正しいけど、運用としてはかなりしんどい」
というのが本音だった。
そこでふと、
もう VPN で囲ってしまえば、
通信経路ごと暗号化できるのでは？
と思った。
WireGuard で VPN トンネルを張ってしまえば、
- アプリ側は従来通りの接続
- DB / FTP 側も設定ほぼ変更なし
- 通信経路は自動的に暗号化
という形にできる。
技術的に見ると「逃げ」っぽく感じるかもしれないが、
業務では「安全性」と「運用の楽さ」のバランスが一番大事 だと思っている。
頑張って全修正 → 運用破綻
より、
VPN で包む → 安定運用
この方が結果的に健全。
VPN 化＝全部解決、ではないけど
もちろん、VPN にすれば何でも安全になる、というわけではない。
- 端末管理
- 鍵の配布
- 接続端末の制御
- 紛失時の対応
など、考えるべき点は増える。
ただ、それでも 通信経路の暗号化を一気にまとめて解決できる のは大きい。
個別に SSL 化を進めるよりも、
VPN で「安全な社内ネットワーク」を作ってしまう
という発想のほうが、
ひとり情シス的には管理しやすかった。
WireGuard を実運用してみた感想
構築自体もかなりあっさりしている。
- 設定ファイルはシンプル
- 再起動しても安定
- クライアント側の設定も楽
今のところ、
トラブルらしいトラブルは一度も起きていない。
CPU 使用率もほぼ誤差レベルで、
DB や BI と同居していても負荷を感じることはない。
実際にこの構成を検証・運用しているのが、
自分の環境では Xserver VPS のビジネスプラン（12GB） なので、
メモリと CPU に余裕があるのも助かっている。
この環境を前提に書いている。
「頑張る」より「仕組みで楽をする」
今回の WireGuard 導入は、
技術的に何かを極めた、というよりも、
自分の運用をどう楽にするか
を最優先に考えた結果だった。
- アプリ側を修正する
- 各通信を個別に SSL 化する
よりも、
- VPN でまとめて包む
このほうが、
- 実装が楽
- 運用が楽
- トラブル対応も楽
結果として、
自分が楽になる方向に設計を寄せるのが正解だった と感じている。
次は構築ログとして
WireGuard の選定理由はこんな感じだが、
実際の構築手順やポイントもそれなりにあった。
次回は、WireGuard 構築・運用について
実際にどう組んだか、まとめている。
同じように
「VPN どうしようかな…」と迷っている人の参考になれば嬉しい。
この環境の構成まとめ
次の記事
