いわさです。
AWS Firewall Manager みなさん使ってますか。
AWS Organizations 環境における、ファイアウォールリソース（AWS WAF、Shield Advanced、セキュリティグループ、Network Firewall、Route 53 Resolver DNS Firewall）を統制管理できるサービスです。
スコープ内のアカウントやリソースが従うべき組織のルールをポリシーとして定義することで、非準拠リソースを検出したり、自動修復したりすることが出来ます。
本日のアップデートで、新たに「ネットワーク ACL」もポリシーで管理することが出来るようになりました。
ネットワーク ACL とは、サブネットレベルで特定のインバウンドまたはアウトバウンドのトラフィックを許可または拒否するセキュリティレイヤーです。
ポリシー作成
次のように Firewall Manager セキュリティポリシーの作成時に、対象 AWS サービスに「ネットワーク ACL」を選択出来るようになっています。
インバウンドルールとアウトバウンドルールを設定出来ます。
他のポリシーと同様に優先順（順序）の概念があります。
なので、間にアカウントごとのカスタムルールを設定することが出来ますね。
非準拠の場合の修復も可能です。
最初のルールか最後のルールのみという適用の仕方も出来ますし、全部強制適用も可能です。
やってみる
実際に試してみましょう。
適当に次のようなルールのポリシーを作成しました。
ポリシーアクションはとりあえず「Identify resources that don't comply with the policy rules, but don't auto remediate.」を選択します。非準拠の検出のみで修復までは行わないモードですね。
スコープは Firewall Manager の他の対象リソースと指定方法は同じなのですが、このポリシーで設定出来るリソースタイプは「サブネット」のみになってますのでご注意ください。
ネットワーク ACL ではなくサブネットが評価・検出対象になってます。
なので、ルールに一致しないネットワーク ACL ルールが作成されただけでは検出はされません。サブネットに関連付けられて初めて評価されます。
検出してみた
デフォルトのネットワーク ACL だけが関連付けられている AWS アカウントをスコープに入れました。
少し待つと非準拠のアカウントとして検出されました。
アカウントを選択すると、やはりサブネットが非準拠リソースとして挙がっていますね。
さらにサブネットを見てみるとどのルールが違反しているのか具体的に確認することが出来ます。
以下の場合だと First Rule も Last Rule もどちらも準拠していないですね。
期待されている状態と、現状を確認することが出来るので、ここを確認して是正のための参考情報とすることが出来ます。
さらに「Possible remediation actions」タブを見てみると、準拠するためのより詳細なステップが案内されています。
例えば以下だと、NACL を作成して 2 つのルールを追加しサブネットへ関連付けることが案内されていますね。
準拠するように修正してみる
ちなみに Firewall Manager 全般ですが、内部では各スコープアカウントへ Config ルールがデプロイされており、リソースのチェックを行っています。
なのでリソースの変更を行うとすぐにリソースが再評価されます。
次のように新しくネットワーク ACL を作成し、Firewall Manager ポリシーに準拠するようにルールを作成してみました。
なお、Last Rule はデフォルトルール（ルール番号「」のもの）は対象外なので、デフォルトルールと同じ内容ですが追加しています。追加しないと非準拠と判断されます。
冗長になるのでルール番号「」に相当するルールは Firewall Manager セキュリティポリシー上は不要ですね。
上記ネットワーク ACL をサブネットのひとつに関連づけしました。
少し待つと Config 上でリソースが準拠ステータスに変更されました。
同じように全てのサブネットを準拠状態に変更したところ、Firewall Manager 上でも次のようにアカウントが準拠状態であると判断されました。良いですね。
こちらのステータス反映は少しタイムラグ（数分）があるようなので注意してください。
自動修復もしてみる
先ほどは手動でリソースを変更しポリシーに準拠させましたが、自動修復も試してみます。
先ほどのネットワーク ACL は削除し、もう一度デフォルトのネットワーク ACL を関連付けした状態から始めます。
強力な統制機能ではありますが、予期せずネットワークアクセス上の問題が生じる可能性もありますので慎重に使ってください。
公式ドキュメントではまず検出モードで試して、確認出来たら自動修復に切り替えるように推奨されていました。
ポリシー詳細画面からポリシーアクションを変更しましょう。
「Auto remediate any noncompliant resource.」を選択します。
修復時の動作を設定するのですが、今回は First Rule と Last Rule どちらも強制適用するようにします。
ポリシーを更新して少し待つと、新しいネットワーク ACL が自動作成されていることが確認出来ました。
ルール番号 5000 が 0.0.0.0/0 のインバウンドを全てで許可しています。これはサブネットに元々関連づいていたネットワーク ACL からコピーしたルールです。
このように Firewall Manager でネットワーク ACL を自動作成する際には、置き換え対象のネットワーク ACL のルールをまずコピーし、そこに First Rule や Last Rule を追加するような動きをします。
ちなみに、Firewall Manager が自動作成したネットワーク ACL は、次のように「FMManaged」タグが設定されます。
このタグは変更しないように注意してください。公式ドキュメントでも言及されていますが、自動修復が正しく動作しなくなる場合があります。
ネットワーク ACL の自動修復ですが、サブネットへの自動適用までも行われます。
そのため、自動修復の結果がワークロードに影響を及ぼす場合があります。十分注意してください。
さいごに
本日は AWS Firewall Manager で組織のポリシーとしてネットワーク ACL も管理できるようになったので確認してみました。
例えば限定された範囲のみインバウンドルール・アウトバウンドルールを設定することが許可されているような組織ポリシーがある場合は、この機能を使うことで複数アカウント、複数ワークロードのファイアウォールルールとして管理することが出来ます。
検出モードの場合は安全に使うことが出来るので、ネットワーク ACL の組織ポリシーをお持ちの方は是非試してみてください。
13
