OPNsense と AWS Security Group の比較：守る場所の違いと使い分け

OPNsense と AWS Security Group は、どちらも「通信を許可・遮断する」道具ですが、守る場所と得意分野がまったく違います。結論から言うと、AWS 上のサーバーを守る基本は Security Group で、OPNsense はネットワークの出入口でルーティング・VPN・侵入検知までまとめて扱いたいときに選ぶものです。この記事では両者の仕組みの違い、ルール評価の違い、ログの取り方、併用するときの注意点を整理し、自分の環境でどちらを（あるいは両方を）使うべきか判断できるようにします。

前提：2つはそもそも置かれる場所が違う

OPNsense はオープンソースのファイアウォール・ルーター用 OS です。FreeBSD をベースにしており、物理マシンや仮想マシンにインストールして「ネットワークの境界」に置きます。社内 LAN とインターネットの間、あるいは自宅ラボや拠点の出入口に置き、そこを通るすべての通信を検査するのが本来の使い方です。

AWS Security Group（以下 SG）は、AWS の VPC 内で EC2 インスタンスや RDS、ロードバランサーなどのネットワークインターフェースに付けるマネージドな仮想ファイアウォールです。機器として置くものではなく、リソースごとに「この通信は受け入れる」というルールを貼り付けるイメージです。

つまり、OPNsense は「門番」、SG は「各部屋の鍵」に近い存在です。比較するときはどちらが優れているかではなく、どの層を誰が守るかで考えると整理しやすくなります。

ルールの考え方の違い

Security Group は「許可だけ」を書く

SG のルールは許可（allow）のみで、拒否（deny）ルールは書けません。書かれていない通信はすべて拒否されます。また、ルールに順番はなく、付いているルールが全体として評価されます。複数の SG を同じリソースに付けた場合も、許可ルールの合算になります。

SG はステートフルです。インバウンドで許可した通信への応答は、アウトバウンドのルールに関係なく返せます。新しく作った SG は、インバウンドが空（何も受け入れない）、アウトバウンドがすべて許可、という初期状態になるのが一般的です。

便利なのは、送信元に IP アドレスだけでなく「別の SG」を指定できる点です。たとえば WordPress の EC2 には「ALB に付けた SG からの 80/443 だけ許可」と書けば、ALB の IP が変わってもルールを直す必要がありません。

特定の IP を明示的に遮断したい場合は、サブネット単位で効くネットワーク ACL（こちらはステートレスで、番号順に評価され deny も書ける）や、AWS WAF、AWS Network Firewall を使います。

OPNsense は「上から順に、最初に一致したもの」

OPNsense のインターフェースごとのルールは、上から順に評価され、最初に一致したルールが適用される方式が基本です（内部では FreeBSD 由来の pf が動いています）。許可も拒否も書けるので、「この国からの管理画面アクセスは拒否、それ以外の社内からは許可」のような細かい制御ができます。その分、ルールの並び順を間違えると意図しない通信が通ります。

OPNsense もステートフルで、許可した通信の戻りは自動で通ります。さらに、複数の IP やポートをまとめて名前を付けられるエイリアス、複数インターフェースにまたがって効かせるフローティングルール、NAT、ポリシーベースルーティングなど、境界ルーターとしての機能をまとめて持っています。

機能の比較

比較の観点が多いので、ここだけ表にします。各製品の機能はバージョンで変わるため、細部は公式ドキュメントで確認してください。以下は一般的な整理です（2026年10月現在）。

ログと調査のしやすさ

運用で差が出やすいのがログです。OPNsense はルールごとにログ記録を有効にでき、管理画面のライブビューで「どのルールで落ちたか」をすぐ確認できます。トラブル調査ではこれが大きな利点です。

SG は、どのルールで許可・拒否されたかを直接は記録しません。通信の記録が欲しい場合は VPC フローログを有効にし、ACCEPT / REJECT の記録から推測します。フローログは集計に少し時間がかかるため、リアルタイムの切り分けには向きません。「つながらない」と言われたときは、SG のルール、ネットワーク ACL、OS 側のファイアウォール（ufw や firewalld）、アプリの待ち受けポートの順に見ていくのが現実的です。

運用負荷と変更管理

SG は AWS のマネージドサービスなので、OS のパッチ当てや冗長化を気にする必要がありません。ルールは Terraform や CloudFormation でコードとして管理しやすく、変更履歴は CloudTrail に残ります。変更はほぼ即時に反映されます。

OPNsense は高機能な反面、OS とプラグインの更新、設定のバックアップ、障害時の切り替えまで自分で面倒を見る必要があります。OPNsense は年に2回のメジャーリリースが基本で、更新の前には設定のエクスポートを取り、可能なら検証機で先に試してください。止まると配下のネットワーク全体が止まる位置に置くことになるため、冗長構成を組むかどうかは最初に決めておくべき事項です。

どちらを選ぶか：よくあるケース

AWS 上で WordPress を動かすだけの場合は、SG が主役です。典型的な構成は次のとおりです。

• ALB の SG：インターネットから 443（と、リダイレクト用の 80）を許可
• EC2 の SG：ALB の SG からの 80/443 だけを許可
• RDS の SG：EC2 の SG からの 3306 だけを許可
• SSH は特定の IP に限定するか、22 番を開けずに Systems Manager Session Manager で接続

この形なら、OPNsense を追加する必要はほとんどありません。アプリ層の攻撃（ログイン総当たりや SQL インジェクションの試行）には SG では対処できないので、AWS WAF や WordPress 側のセキュリティプラグインと組み合わせます。

オフィスや拠点、自宅ラボの境界を守る場合は OPNsense の出番です。インターネット回線とLANの間に置いて、NAT、VPN 接続、IDS/IPS、DNS フィルタリングをまとめて担わせられます。

オンプレミスと AWS をつなぐ場合は併用になります。拠点側の OPNsense から AWS の Site-to-Site VPN や自前の VPN へ接続し、AWS 側では引き続き SG で各リソースを絞ります。境界で大まかに、リソースで細かく、という二段構えです。

AWS 上で OPNsense を動かすときの注意

「AWS の中でも OPNsense で一元管理したい」という要望もありますが、手間は増えます。主な注意点は次のとおりです。

• SG は残る：OPNsense を EC2 上で動かしても、そのインスタンス自体と配下のリソースには SG が付きます。SG を全開放して OPNsense に任せる設計は、OPNsense が止まったときや設定を誤ったときに無防備になるので避けてください。
• 送信元/送信先チェックの無効化：EC2 をルーターや NAT として使う場合、そのインスタンスの送信元/送信先チェックを無効にし、ルートテーブルで通信を OPNsense 経由に向ける必要があります。ここを忘れると「ルールは正しいのに通らない」状態になります。
• 単一障害点になる：1台構成だと、そのインスタンスの障害がネットワーク全体の障害になります。冗長化の方式はオンプレミスと同じようにはいかないことがあるため、事前に検証してください。
• 提供形態の確認：イメージの入手方法やライセンス形態は変わることがあるため、OPNsense の公式ドキュメントと配布元の案内を確認してください。

AWS 内で集中検査をしたい場合は、AWS Network Firewall や Gateway Load Balancer を使ったサードパーティ製アプライアンスの構成も選択肢です。どれを選ぶにしても、本番の前に検証用 VPC で通信経路を確認してから切り替えるのが安全です。

設定変更の前に確認すること

ファイアウォールの設定ミスは、自分自身の接続も遮断してしまいます。どちらの製品でも、次の点を作業前に確認してください。

1. 現在の設定のバックアップ（OPNsense は設定のエクスポート、SG は Terraform などのコードか、ルールの書き出し）
2. 管理用の接続経路が別にあるか（OPNsense ならコンソール、EC2 なら Session Manager など）
3. 変更後の確認手順（curl -I https://example.com/ や nc -vz <ホスト> 443 で疎通を確認する）

# 外部から 443 番に到達できるか
nc -vz www.example.com 443

# HTTPS 応答のヘッダーだけ確認
curl -I https://www.example.com/

まとめ

• OPNsense はネットワーク境界に置く多機能ファイアウォール、Security Group は AWS の各リソースに付けるマネージドな許可リスト
• SG は許可のみ・順序なし・他の SG を送信元に指定できる。拒否ルールが要るならネットワーク ACL や WAF を併用する
• OPNsense は上から順に評価し許可も拒否も書ける。ルールごとのログで調査しやすいが、OS 更新や冗長化は自分で担う
• AWS だけで完結する WordPress なら SG を主役にし、拠点やオンプレミスの境界には OPNsense、両方をつなぐなら併用で二段構えにする
• どちらも変更前にバックアップと別経路の管理アクセスを確保する

• AWS EC2 のセキュリティグループ設定
• ファイアウォールのルール設計とテスト方法