今回は、AWS Firewall ManagerのAWS Organizations連携機能を紹介します。AWS Firewall Manager自体はOrganizationsレベルでの利用が前提となっており、複数アカウントのネットワーク制御ルールを一元的に構成・管理するサービスです。本稿執筆時点で管理できる対象は以下です。

  • AWS WAF アクセスコントロールリスト（ACL）
  • AWS Shield Advanced
  • Amazon VPCセキュリティグループ
  • Amazon VPCネットワークアクセスコントロールリスト
  • AWS Network Firewall
  • Amazon Route 53 Resolver DNS Firewall
  • Palo Alto Networks Cloud NGFWなどのサードパーティーのファイアウォールポリシー

以下、Firewall Managerの具体的な利用方法や利用にあたっての注意点を説明します。

Firewall Managerの利用方法

初めにFirewall Managerの利用方法を説明します。Firewall Managerは前提となるサービスが多く、詳細は公式ドキュメントに前提条件として整理されています。前述のサードパーティ製品以外のAWSサービスの管理にあたってはAWS ConfigおよびAWS Resource Access Managerの有効化が前提となっています。AWS Configは第3回を参考に、AWS Resource Access Managerは公式ドキュメントの手順を参考にし、有効化を実施してください。

これまで紹介してきた機能と同じく、委任管理者として別のアカウントを指定することがベストプラクティスとされているため、まずは管理アカウントにて委任管理者の設定を行います。

管理アカウントの作業

（1）Organizationsの画面へ遷移します。
（2）サイドメニューから「サービス」をクリックします。
（3）Firewall Managerを見つけ、クリックします。

（4）「信頼されたアクセスを有効にする」をクリックします。

（5）表示されたポップアップで下記のように入力を行い、「信頼されたアクセスを有効にする」ボタンをクリックします。

（6）ステータスが変更されていることを確認します。

（7）「コンソールに移動する」ボタンをクリックします。

（8）サイドメニューの「Settings」をクリックし、「Create administrator account」ボタンをクリックします。

（9）管理アカウントのAWSアカウントIDを入力し、「Create administrator account」ボタンをクリックします（委任管理者のAWSアカウントIDではないので、ご注意ください）。

（10）Default administrator accountとして、管理アカウントが設定されていることを確認します。

（11）続いて委任管理者アカウントの登録を行います。再び「Create administrator account」ボタンをクリックします。

Firewall Managerは、他のOrganizations連携機能と異なり、委任管理の対象となるAWSアカウントを制限する機能を有しています。この機能を利用して、管理アカウント以外のAWSアカウントに対する権限を持つ委任管理者の設定を行ってみます。

（1）委任管理者として指定するAWSアカウントIDを入力し、Administrative Scopeとして「Restricted」を選択し、「Exclude only the specified accounts and organizational units, and include all others」を選択します。

（2）Exclude accountsとして管理アカウントのAWSアカウントIDを指定します。委任できるポリシータイプ（サポート対象のどのAWSリソースを管理できるか）およびリージョンの制限もできますが、今回はすべてのポリシータイプおよびすべてのリージョンを委任することとします。最後に「Create administrator account」ボタンをクリックします。

（3）Administrative scopeがRestrictedとなって、委任管理者が追加されていることを確認します。

Firewall Managerの委任管理者アカウントは最大で9つ（デフォルト管理者を除く）指定することが可能です。この数はハードリミットとなっており、拡張することはできませんが、この数の範囲ではOrganizations内で細やかに委任管理者を指定できます。

委任管理者アカウントの作業

それでは実際に委任管理者アカウントで各AWSサービスに対して、一元的に設定を行っていきます。本書では利用者が多いと想定される以下2つのAWSサービスについて、Firewall Managerでの設定方法を説明します。

（1）AWS WAF ACL
（2）Amazon VPCセキュリティグループ

AWS WAFの設定

Firewall Managerを利用すると、以下の3つのAWSサービスに対するAWS WAFの設定値が事前に定義したルールに沿った値となっているかを一括で確認し、必要に応じて修正することが可能です。

  • Amazon CloudFront
  • Application Load Balancer（ALB）
  • Amazon API Gateway

チェック対象のAWS WAFのACLが事前定義したルールを満たしている場合は、Compliantと表示され、それ以外はNon Compliantと表示されます。 Firewall Manager上でCompliantのステータスとなるのは、Firewall ManagerによってWAF ACLが新規作成され、該当のAWSリソースへアタッチされるか、既存のWAF ACLの設定変更がされたケースのみです。

そのため、既存のAWSリソースをFirewall Managerで管理する場合、CompliantとするにはFirewall Managerによる変更が必須となります。基本的には以下のようなステップで新規作成したAWSリソースをFirewall Managerで管理していくことになるでしょう。

今回はALBに関連付けたAWS WAFの設定を集中管理する設定について説明します。

（1）委任管理者アカウントにログインし、AWS Firewall Managerの画面へ移動します。
（2）「Create policy」ボタンをクリックします。

（3） 管理対象となるリージョンとして、東京リージョンを選択したうえで、「AWS WAF」にチェックを入れて、「Next」ボタンをクリックします。

（4）なんらかのPolicy名を入れて、次へ進みます。

（5）続いてWAF ACLとして追加したいルールを定義します。最初に処理されるルールと最後に処理されるルールを定義することが可能です。ここでは最初に処理されるルールとしてAWS managed rule groups内のCore rule set、最後に処理されるルールとしてAnonymous IP listを追加します。操作は以下の画像を参考にしてください。

（6）今回はブラックリスト方式の制御（ルールに合致した場合のみブロック）を行う前提での設定にします。そのためデフォルトアクションは「Allow」を選択しておきます。

（7）ログの集約設定を行うために、「Enabling logging」を選択し、「S3 bucket」を選択します。事前に委任管理者アカウント内にaws-waf-logs-から始まるS3バケットを作成するようにしてください。

ここで設定したS3バケットには、下記のようなバケットポリシーがFirewall Managerから自動的で設定されます。


{
 "Version": "2012-10-17",
 "Id": "AWSLogDeliveryForFirewallManager",
 "Statement": [
     {
         "Sid": "AWSLogDeliveryWriteFMS",
         "Effect": "Allow",
         "Principal": {
             "Service": "delivery.logs.amazonaws.com"
         },
         "Action": "s3:PutObject",
         "Resource": "arn:aws:s3:::{aws-waf-logs-から始まる集約用のS3バケット名}/{Firewall ManagerのPolicy ID}/AWSLogs/*",
         "Condition": {
             "StringEquals": {
                 "s3:x-amz-acl": "bucket-owner-full-control"
             }
         }
     },
     {
         "Sid": "AWSLogDeliveryAclCheckFMS",
         "Effect": "Allow",
         "Principal": {
             "Service": "delivery.logs.amazonaws.com"
         },
         "Action": "s3:GetBucketAcl",
         "Resource": "arn:aws:s3:::{aws-waf-logs-から始まる集約用のS3バケット名}"
     }
 ]
}

このままでも良いのですが、Conditionにaws:SourceOrgID条件を追加することで、Organizations外からの意図しないログ書き込みを防ぎ、セキュリティを強化できます。


{
 "Version": "2012-10-17",
 "Id": "AWSLogDeliveryForFirewallManager",
 "Statement": [
     {
         "Sid": "AWSLogDeliveryWriteFMS",
         "Effect": "Allow",
         "Principal": {
             "Service": "delivery.logs.amazonaws.com"
         },
         "Action": "s3:PutObject",
         "Resource": "arn:aws:s3:::{aws-waf-logs-から始まる集約用のS3バケット名}/{Firewall ManagerのPolicy ID}/AWSLogs/*",
         "Condition": {
             "StringEquals": {
                 "aws:SourceOrgID": "{o-から始まる自OrganizationsのID}",
                 "s3:x-amz-acl": "bucket-owner-full-control"
             }
         }
     },
     {
         "Sid": "AWSLogDeliveryAclCheckFMS",
         "Effect": "Allow",
         "Principal": {
             "Service": "delivery.logs.amazonaws.com"
         },
         "Action": "s3:GetBucketAcl",
         "Resource": "arn:aws:s3:::{aws-waf-logs-から始まる集約用のS3バケット名}",
         "Condition": {
             "StringEquals": {
                 "aws:SourceOrgID": "{o-から始まる自OrganizationsのID}"
             }
         }
     }
 ]
}

（8）リクエストのサンプルは無償であるため、基本的には有効にしておいたほうが良いでしょう。またトークンドメインリストは今回は設定しないでおきます。

（9）Web ACL Managementでは、「Manage unassociated web ACL」を有効にすることで、Firewall Managerの管理対象となるAWSサービスがない場合に不要なWAF ACLの作成を抑制できます。Manage web ACL source（チェック対象のAWSリソースのAWS WAF設定が不適切な場合の修正方法）には2種類ありますが、今回は2024年10月にリリースされた「Retrofit existing web ACLs」を選択します。

この設定は、既存のWAF ACLをFirewall Managerのポリシーに適合させます。Policy actionは、検知のみで自動修復は行わない「Identify resources that don’t comply with the policy rules, but don’t auto remediate.」を選択します。自動修復は行わないため、Manage web ACL sourceの設定は現時点では意味を持ちませんが、動作確認時に設定変更を行います。

（10）対象となるAWSリソースを定義します。委任管理アカウントの設定時に管理アカウントは対象外としているので、「Include all accounts under my organization」を選択し、Resource typeでは、「Application Load Balancer」を選択します。対象外となるリソースは無しとして、「Include all resources that match the selected resource type」を選択します。

（11）Firewall Managerの管理対象外となった際のリソースのクリーンアップは有効化し、「Next」ボタンをクリックします。

（12）タグの設定はせずに「Next」ボタンをクリックします。

（13）内容を確認して、「Create policy」ボタンをクリックします。

AWS WAFの動作確認

それでは、実際に動作確認をしていきましょう。 まずは以下3種類のALBをFirewall Manager管理対象のAWSアカウント内に作っておきます。

　 ALB名 状態
1 test-alb-no-waf WAF ACLが付与されていない
2 test-alb-non-compliant-waf WAF ACLは付与されているがルールが条件を満たしていない
3 test-alb-compliant-waf 条件を満たすルールを持つWAF ACLが付与されている

  • 条件を満たさないWAF ACLのルール（Anonymous IP listを含んでいない）

  • 条件を満たすWAF ACLのルール（Core Rule SetもAnonymous IP listも含む）

  • 条件を満たすWAF ACLのログ設定など

なお、test-compliant-wafのログ設定を行うには、本稿執筆時点でマネジメントコンソールでの自アカウント外のS3バケットを指定できないため、AWS CLIでの設定が必要となります。にこちらの手順を参考に実施してください。その際は、以下2点に注意する必要があります。

（1）S3バケットポリシーの変更が必要です。上述のS3バケットポリシーの場合は、「aws wafv2 put-logging-configuration」コマンドを実行した際に、「An error occurred (WAFLogDestinationPermissionIssueException) when calling the PutLoggingConfiguration operation: Unable to deliver logs to the configured destination. You might need to grant log delivery permissions for the destination. If you’re using S3 as your log destination, you might have exceeded your bucket limit.」といったエラーメッセージが表示されます。

これはPutObjectを許可されている場所が「{aws-waf-logs-から始まる集約用のS3バケット名}/{Firewall ManagerのPolicy ID}/AWSLogs/」というFirewall Managerのログ集約場所に限定されていることが原因です。S3バケット全体へのPutObjectを許可することでこのエラーを回避することができます。


{
 "Version": "2012-10-17",
 "Id": "AWSLogDeliveryForFirewallManager",
 "Statement": [
     {
         "Sid": "AWSLogDeliveryWriteFMS",
         "Effect": "Allow",
         "Principal": {
             "Service": "delivery.logs.amazonaws.com"
         },
         "Action": "s3:PutObject",
         "Resource": "arn:aws:s3:::{aws-waf-logs-から始まる集約用のS3バケット名}/*",
         "Condition": {
             "StringEquals": {
                 "aws:SourceOrgID": "{o-から始まる自OrganizationsのID}",
                 "s3:x-amz-acl": "bucket-owner-full-control"
             }
         }
     },
     {
         "Sid": "AWSLogDeliveryAclCheckFMS",
         "Effect": "Allow",
         "Principal": {
             "Service": "delivery.logs.amazonaws.com"
         },
         "Action": "s3:GetBucketAcl",
         "Resource": "arn:aws:s3:::{aws-waf-logs-から始まる集約用のS3バケット名}",
         "Condition": {
             "StringEquals": {
                 "aws:SourceOrgID": "{o-から始まる自OrganizationsのID}"
             }
         }
     }
 ]
}

（2）AWS CLIによるS3バケットへのログ出力設定に加え、セキュリティポリシーで指定しているRedacted fieldsの設定を行う際は、AWS CLIでのRedactedFieldsの指定か、マネジメントコンソール上で次の画像のような追加操作が必要となります。

この状態でセキュリティポリシーの結果を確認してみると、いずれのケースでもNon Compliantのステータスとして表示されていることがわかります。前述の通り、Firewall Manager管理外のAWSリソースをCompliantのステータスにすることはできないことが確認できました。

  • 3つのALBと2つのWAF ACLがNon Compliantとして表示される

  • ルールおよびログ設定等をセキュリティポリシーに合わせたWAC ACLもNon Compliantとして表示される

では、この状態で自動修復を有効にしてみます。

少し待つと、「1. test-alb-no-waf」には新規でWAF ACLが作成され、関連付けがされていることが確認できます。

「2. test-alb-non-compliant-waf」および「3. test-alb-compliant-waf」には、既存のWAF ACLの前後にルールが追加されていることがわかります。

また事前にログ設定を行った「3. test-alb-compliant-waf」以外はS3へのログ転送設定が追加されていることも確認できます。

※こちらのドキュメントに記載の通り、WAF ACLにログ設定が事前にされている場合は、その設定が変更されません。

ポリシーにログ記録設定がある場合、Firewall Manager ACLは、ウェブがログ記録用にまだ設定されていないACL場合にのみ、ポリシーをウェブに追加します。ウェブにアカウントによって設定されたログ記録ACLがある場合、Firewall Manager は、改良中およびポリシーのログ記録設定に対するその後の更新時の両方で、そのログ記録をそのまま残します。

Amazon VPCセキュリティグループの設定

次に、Firewall Managerを利用したセキュリティグループの操作について説明します。Firewall Managerを利用することで、複数のAWSアカウントに対して、以下のことが実施できます。

＜1＞事前定義した共通的なセキュリティグループのコピーを作成する
＜2＞事前定義したルールに基づき、セキュリティグループの設定を確認し、必要に応じて修正する
＜3＞特定期間利用されていないセキュリティグループを検知し、必要に応じて削除する

本稿では、この中の1つ目の機能に関する設定方法を説明します。残り2つに関しては、Security Hubで提供されているAWS Foundational Security Best Practices v1.0.0 (FSBP) 標準のEC2に関するルールで類似のチェックができることから、多くのケースでFSBPによるチェックとすると思います。また、自動修復もリスクを感じられるプロジェクトも多いことから、あまり実施されることはないと思われます。ですが、1つ目の機能は、踏み台サーバなどの共通機能からの通信制御において利用されるセキュリティグループの作成という用途があると思います。

それでは、具体的な設定手順を見ていきます。

（1）Firewall Managerの画面で「Create policy」ボタンをクリックします。
（2）AWS servicesで「Security group」を選択し、Security group policy typeで「Common security groups」を選択し、「Next」ボタンをクリックします。

（3）Policy nameおよびPolicy Descriptionを入力し、Add security groupsから共通的に作成するセキュリティグループを追加し、自動修復は有効にせずに、「Next」ボタンをクリックします。

（4）管理対象の全AWSアカウントの特定のタグが付与されているEC2をチェック対象とする設定にします。以下の画像はFirewallManagerSG：Trueというタグを持つEC2を対象とする設定です。さらに管理対象外となった場合は、元に戻す設定も行っておきます。

（5）Policy tagsはデフォルトのままとし、「Next」ボタンをクリックします。 （6）最後に「Create policy」ボタンをクリックします。

Amazon VPCセキュリティグループの動作確認

それでは、動作確認をします。事前にいずれかのAWSアカウント内のEC2にFirewallManagerSG：Trueのタグを付与しておきます。そのうえでFirewall Managerのセキュリティポリシーを確認すると、以下のようにNon Compliantのステータスで表示されます。

続いて、この状態でセキュリティポリシーを変更し、自動修復を有効化します。

少し待つと、FirewallManagerSG：Trueのタグを持つEC2に、セキュリティポリシーで指定した共通セキュリティグループが付与されていることを確認できます。

課題となりやすいポイント

それでは最後に課題となりやすいポイントについて説明します。

  • すでに前述の手順でも触れていますが、Firewall ManagerでCompliantのステータスとするには、必ずFirewall Managerによる修正がされる必要があるため、既存のAWSリソースにFirewall Managerの管理対象とするのは非常に困難なことが多いでしょう。多くの現場では以下のような使い分けをすることになるので、Security Hub等のセキュリティサービスとの兼用を検討ください。

●Security Hub（またはConfig）：全AWSリソースがルールに準拠した設定となっているかの検知。必要に応じて手動で修正
●Firewall Manager：特定のタグが付与されているAWSリソースのみをルールに沿った形に自動修復

  • 細かな点ですが、Firewall Managerでは、管理対象をタグでしかコントロールができないため、例えばInternet-facingのALBのみを対象にするということができません。一般的にはInternal ALBはWAFが不要ですので、除外をしたいと考える方は多いと思うのですが、タグ以外の管理対象のコントロールができないことには、留意が必要です。

  • 本稿執筆時点で、WAF ACLの管理を行う場合、ログ出力先として指定可能なS3バケットは、Firewall Managerの（委任）管理アカウント内のS3バケットのみです。実案件ではFirewall Managerの管理アカウントとは別にログアーカイブアカウントを用意しているケースもあるので、ログの保管場所が分散してしまう可能性もあり得ますので、ご注意ください。

まとめ

今回は、AWS Firewall ManagerのOrganizations連携ステップと課題となりやすいポイントを詳しく紹介しました。本稿がOrganizations配下のAWSアカウントの運用管理のお役に立てば幸いです。

奥村康晃

奥村康晃

おくむらやすあき

NTTデータ入社以来、クラウドサービスのAPIを連携させることで効率的な管理を可能とするクラウド管理プラットフォームの開発に従事。現在では、クラウド導入の技術コンサルや組織での技術戦略立案にも携わる。 2023 Japan AWS Ambassadors受賞

この著者の記事一覧はこちら