この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
あけましておめでとうございます、中山（順）です。
令和2年の書き初めです。本日は、Firewall ManagerによるSecurity Groupの管理機能をご紹介します。
Firewall Managerとは？
Firewall Managerは、以下のサービスおよびリソースを複数のアカウント横断で管理するためのサービスです。
- AWS WAF Classic
- AWS Shield Advanced
- Amazon VPC security group
Security Groupの管理機能
Security Groupの管理機能は、2019/10/10に追加された機能となります。
AWS Firewall Manager now supports management of Amazon VPC security groups
この機能により、複数のアカウントに対する統制された設定と監査が容易になりました。
- 指定したアカウントとリソースに共通セキュリティグループを適用します。
- セキュリティグループルールを監査し、準拠していないルールを見つけて修正します。
- セキュリティグループの使用状況を監査し、未使用および冗長なセキュリティグループをクリーンアップします。
AWS Firewall Manager でのセキュリティグループポリシーのしくみ
セキュリティグループのためのポリシーは、どのように設定や監査を行うかを定義するポリシールールとポリシールールをどの範囲で適用するかを定義するスコープの2つで構成されます。
やってみた
以下の内容をやってみました。
- 前提条件の確認および設定
- 指定したEC2インスタンスにアタッチするSecurity Groupの作成と適用
- Security Groupの監査
- 冗長および未使用のSecurity Groupの検出
前提条件の確認および設定
Firewall Managerの利用を開始する前に以下の設定を実施する必要があります。
- AWS Organizations に参加する
- AWS Firewall Manager 管理者アカウントを設定する
- AWS Config を有効にする
AWS Organizations に参加する
Firewall Managerを利用するには、管理対象のAWSアカウントがAWS Organizationsのメンバーアカウントである必要があります。 Organizationの作成およびアカウントの追加手順の紹介は割愛します。 今回はマスターアカウントの配下にメンバーアカウントを2つ追加しています。
詳細は以下のドキュメントを参照してください。
ステップ 1: AWS Organizations に参加する
AWS Firewall Manager 管理者アカウントを設定する
次に、Firewall Managerの管理アカウントを指定します。 この管理アカウントは、Organizationのマスターアカウントである必要はありません。 今回はメンバーアカウントを管理アカウントに指定します。
簡単に手順を紹介します。
Organizationのマスターアカウントにサインインし、WAF & Shieldのコンソールから設定を開始します。
管理アカウントに指定するAWSアカウントのIDを入力します。 今回はメンバーアカウントを管理アカウントに指定します。
確認メッセージを確認し、問題無ければ次に進みます。
少し待つとAWSアカウントが表示されます。 これ以降、Firewall Managerの設定は管理アカウントに指定したAWSアカウント上で実施します。 改めてサインインするかスイッチロールしましょう。
なお、Organizationsのコンソールで設定を確認すると上記の作業を実行することでFirewall Managerが有効化されていました。
詳細は以下のドキュメントを参照してください。
ステップ 2: AWS Firewall Manager 管理者アカウントを設定する
AWS Config を有効にする
Firewall Managerを利用するにためにはAWS Configを有効化する必要があります。 Firewall Managerで管理したいリソースが存在する全てのリージョンでConfigを有効化します。 設定の手順は割愛します。
今回はメンバーアカウントの東京リージョンのみを有効化しました。
詳細は以下のドキュメントを参照してください。
以上で準備は完了です。
指定したEC2インスタンスにアタッチするSecurity Groupの作成と適用
最初に指定したEC2インスタンスにアタッチするSecurity Groupの作成と適用を行います。 このタイプのポリシーを利用することで、「基準となるSecurity Groupと同じSecurity Groupを複製」および「指定した条件のリソースにSecurity Groupを自動でアタッチ」が可能となります。
実際にやってみましょう。
WAF & Shieldのコンソールからポリシーの作成を開始します。
Policy TypeにはSecurity Groupを指定します。 併せて、Seurity Group Policy TypeにはCommon Security Groupsを指定します。
次にポリシーのルールを定義します。
最初にどのようにSecurity Groupを適用・維持するかを指定します。 既定ではポリシーのスコープ内のリソースに対して複製されたSecurity Groupを割り当てるだけですが、以下のようなことも可能です。
- "Identify and revert any local changes made to the security group rules created by this policy."
- Firewall Managerのポリシーに基づいて作成されたSecurity GroupをFirewall Managerを介さずに変更した場合、元に戻す。
- "Disassociate any other security groups from the AWS resources within the policy scope."
- スコープ内のリソースに対してFirewall ManagerでアタッチしたSecurity Group以外がアタッチされていた場合、管理外のSecurity Groupをデタッチする。
動作を確認してみたいので上記の2つのオプションを有効化します。
次にPrimary Security Groupsを指定します。 Primary Security Groupsは複製元となるSecurity Groupの集合です。 Firewall ManagerによってPrimary Security Groupがリソースに割り当てられることはありません。
この時点でPrimary Security GroupとなるようなSecurity Groupが存在しないので作成します。
Security Groupの作成を開始します。
Primary Security Groupは通常通りの手順で作成すれば問題ありません。
作成したSecurity GroupをPrimary Security Groupとして指定します。
Primary Security Groupの指定ができました。
Policy Actionを指定します。
Non-compliantであることを検知するだけとするか自動で修正するかを選択します。 今回は自動で修正させます。
次のステップではポリシーのスコープを定義します。
まず、対象となるAWSアカウントを指定します。 Organizationに含まれる全てのアカウントを対象にすることもできますし、指定したアカウントを含めること、もしくは指定したアカウントを除外することが可能です。
今回は2つのメンバーアカウント（マスターアカウントを除く）をスコープに含めます。
次にスコープに追加するリソースの種類を指定します。 今回はEC2インスタンスのみを指定します。
併せてスコープに含めるのリソースを指定します。 全てのリソースを含めることも可能ですし、指定したタグが付与されたリソースを含めること・指定したタグが付与されたリソースを除外することが可能です。 特定のタグが付与されたリソースをスコープに含めます。
これで設定は完了です。 メッセージを確認しポリシーの作成を完了します。
数分でポリシーの作成が完了します。
動作確認
先ほどスコープに指定したタグを付与したEC2インスタンスを作成します。 その際にdefault Security Groupを指定します。
作成したポリシーが正常に機能すれば、Primary Secrity Groupと同じルールのSecurity Groupがアタッチされ、同時にdefault Security Groupがデタッチされるはずです。
しばらく待つと、期待したとおりの動作となりました。
Policyの詳細画面でも、スコープ内のAWSアカウントがCompliantであることを示しています。
なお、Firewall Managerのポリシーを削除する際、ポリシーによって作成されたSecurity Groupをリソースからデタッチさせることが可能です。ただし、リソースに対してアタッチされているSecurity Groupが0になってしまう場合にはデタッチおよび削除が実施されませんので注意しましょう。
Security Groupの監査
次にSecurity Groupの監査機能を紹介します。
まずはやってみましょう。
Security Group Policy TypeにAuditing and Enforcement of Security Group Rulesを選択します。
このポリシータイプでは、「Audit Security Groupsと同じルールだけを許可する」もしくは「Audit Security Groupsと同じルールを拒否する」ことが可能です。 今回は前者でやってみます。
Policy Actionは検出のみを選択可能です。
次にスコープを定義します。
AWSアカウントは先ほどと同じメンバーアカウントとします。 リソースは全てのSecurity Groupとします。
設定は以上です。
動作確認
動作確認として、Audit Security Groupとは異なるCIDRからのアクセスを許可したSecurity Groupを作成しました。
しばらくすると、ポリシーの詳細からNon compliantであることと、問題のあるSecurity GroupのIDを確認することができました。
冗長および未使用のSecurity Groupを検出
最後に冗長および未使用のSecurity Groupを検出してみます。
Security Group Policy Typeに"Auditing and cleanup of unused and redundant secirity groups"を選択します。
次にルールを定義します。
Policy Rulesでは、どのようなSecurity Groupを検出するか（Non-compliantとするか）を指定します。 使用されていないSecurity Groupやルールが重複しているSecurity Groupを検出することができます。 今回は両方を選択しました。
Policy Actionでは、検出か自動修正を選択できます。 今回は検出を選択しました。
次にスコープを指定します。
AWSアカウントはこれまでと同じ2つのメンバーアカウントとしました。 リソースは、全てのSecurity Groupとしました。
しかし、Firewall Managerの管理アカウントを含めるかどうかを確認するメッセージが表示されました。 Primary Security GroupやAudit Security Groupをこのポリシーで誤って変更してしまうことを防ぐためかと思われます。 そのため、今回が除外しました。
動作確認
スコープ内のアカウントに同じルールを持つSecurity Groupを2つ作成しリソースにアタッチしないままにしてみたところ、以下の通り検出できました。
まとめ
VPCを大規模かつ長期間運用すると、Security Groupの数が増えたり、使っていないものが残っていたり、部分的にルールが重複したり、間違ったルールが設定されてたり、設定の意図が人々の記憶から消失したり、、、というように闇を抱えがちです。
現状がカオスな場合には、まずは重複や未使用のルールを削除して見通しを確保し、残った設定の意図をポリシーとして定義し移行していくといいのではないでしょうか。 この類いの問題には近道はありません。 AWSアカウントに保護すべきリソースがすでに存在する場合であれば、ポリシーアクションは検出に設定して運用を開始し、慣れたら自動修正へ移行するというアプローチもよいでしょう。 AWS環境を新規構築する場合には、最初から自動修正を適用して設計通りの状態を維持することでセキュアな環境を保つことができると思います。 現状を踏まえて導入・運用の流れを考えてみてはいかがでしょうか？
現場からは以上です。
13
