はじめに
AWS Firewall Managerは、「他のVPC上のセキュリティグループIDを参照」するセキュリティグループ（以降、SG）を管理できるポリシールールが追加されました。
Firewall Manager は、AWS Organizations内にあるアカウントで、AWS WAFやSGなどの設定を一元的に管理するセキュリティサービスです。
先に用語の説明をします。
Firewall Managerでは、プライマリセキュリティグループとレプリカセキュリティグループの２つが存在します。
- プライマリSG
- 各アカウントのリソースに割り当てたいSGをプライマリSGとして、Firewall Managerに設定する
- Firewall Managerで設定したプライマリSG自体は、リソースに割り当てられません。レプリカSGが割り当てられます。
- レプリカSG
- Firewall Managerによって、プライマリSGと同じ設定内容のSGがコピーされ、レプリカSGとして対象アカウントに自動作成され、リソースに割り当てることもできます。
- Firewall ManagerでのSGの管理機能
- 対象のアカウント内にレプリカSGを作成したり、リソースに割り当てる
- SGルールを監査し、準拠していないルールを修正する
- 未使用および冗長なSGを検出する
下記は、対象のアカウント内のリソースにレプリカSGを適用するイメージ図です。
従来、Firewall ManagerのプライマリSGは、アウトバウンドやインバウンドルールのうち、送信先に「他VPCのSGのIDを参照する」ルールはレプリカSGとして自動作成することはできませんでした。
送信先に「他VPCのSGのIDを参照する」というのは、以下のような設定のことです。
アップデートによって、送信先に「他VPCのSGのIDを参照する」SGもレプリカSGとして、自動作成したり、リソースに割り当てることができるようになりました。
これによって、ピアリング接続された各VPC内の各リソースに割り当てられたSGは、相互参照することができ、導通することができます。また、Firewall ManagerでそのSGを管理できます。
利用例
具体的な使用例を、構成図をもとに説明します。
下記の構成は、アカウントAとBに存在するEC2インスタンス（①と②）が、アカウントBのプロキシサーバー経由でインターネットに出る構成です。
インターネットの出口を1つのVPCに集約させる構成は、よくありますね。
この構成の場合、①と②のEC2インスタンスのSGは、プロキシサーバーのSGのIDを参照し、アウトバウンドルールを許可する設定が必要です。
そのルールが設定されたSGは、本来、アカウントごとに手動で作成する必要がありますが、今回のアップデートによって、Firewall ManagerからプライマリSGを設定すると、各アカウントにレプリカSGが自動作成され、対象のEC2インスタンス（①と②）に自動で割り当てることができます。
下記のイメージです。
メリットとしては、アカウントごとに手動でSGを作成する必要がなくなり、Firewall Managerで一括管理できる点です。修正する際も、プライマリSGのみを修正すれば、全てのレプリカSGに反映されます。
前提条件
Firewall Managerを利用するには、以下を設定する必要があります
- Organizationsに参加する
- Firewall Manager 管理者アカウントを設定する
- Config を有効にする
また、今回は、下記の構成で検証してみるため、以下を事前に設定しました。
- AアカウントをFirewall Managerの管理アカウントにした
- AアカウントとBアカウントともにConfigを有効化
- AアカウントとBアカウントは、ともに同じリージョン（今回は東京リージョン）
- EC2インスタンス3台とも起動済み
- VPCピアリングし、ルートテーブルも反映済み
試してみた
以下の内容をやってみました。
- EC2インスタンスのタグ付け
- プライマリSGの作成
- Firewall Managerのセキュリティポリシーの作成
- EC2インスタンスの導通確認
EC2インスタンスのタグ付け、プライマリSGの作成
EC2のタグ付けとプライマリSG用のSGを作成します。
プロキシサーバー以外の①と②のEC2インスタンスに、タグを付与します。
- キー名：
Firewall Manager - 値：
ON
管理アカウントであるアカウントAで、プライマリSGを作成します。
outbound-sgという名前で、以下の設定で作成しました。
| - | タイプ | プロトコル | 送信先 |
|---|---|---|---|
| インバウンド | - | - | - |
| アウトバウンド | すべてのトラフィック | すべて | プロキシサーバーのSGのID |
作成後、アウトバウンドルールを見ると、送信先には、BアカウントID/プロキシサーバーのSGのIDと、BアカウントのアカウントIDも記載されてました。
Firewall Managerのセキュリティポリシーの作成
Firewall ManagerでSGのセキュリティポリシーを作成します。
- サービス：Security group
- ポリシータイプ：Common security groups（共通SG）
- Region：東京リージョン
ポリシールールは、今回のアップデート内容である下記を選択します。
- "Distribute security group references from the primary security group to the security groups created by the policy"
プライマリSGからポリシーによって作成されたSGにSG参照を配布する
プライマリSGは、先程作成したoutbound-sgを選択します。
また、ポリシーアクションは、自動修復を選択します。
対象のアカウントは、アカウントAとアカウントBを選択します。
リソースタイプは、EC2インスタンス、リソースタグは、キーFirewall Manager、値ONにします。
先程の自動修復設定によって、対象のタグを付与した①と②のEC2インスタンスに対して、レプリカSGを自動的に割り当ててくれます。
この設定で、セキュリティポリシーを作成します。
数分後、①と②のEC2インスタンスに対して、レプリカSGが自動的に割り当てられました。
下記は、プロキシサーバーと同じアカウントBに存在するEC2インスタンス（②）に割り当てられたレプリカSGです。
FMManagedSecurityGroup..-プライマリSGのID-VPCのIDという名前でした。
アカウントAのEC2インスタンス（①）に割り当てられたレプリカSGです。
VPCピアリング先のEC2インスタンスの導通確認
EC2インスタンス（①と②）からプロキシサーバー（プライベートIP：10.2.139.187）にpingしてみます。
どちらのEC2インスタンスからもプロキシサーバーにpingが通りました。
最後に、セキュリティポリシーを削除します。
セキュリティポリシーを削除すると、レプリカSGもきれいに削除されました。
最後
今回のアップデートでは、Firewall Managerは、他のVPC上のSGのIDを参照するSGを管理できるポリシールールが追加されました。
今回の利用例で示した構成の場合、アカウントごとに手動でSGを作成する必要がなくなり、Firewall Managerで一括管理できる点がうれしいですね。
修正する際も、プライマリSGのみを修正すれば、全てのレプリカSGに反映されますので、運用管理が楽になります。
2
