developersIO
WAF AutomatorでWeb ACLを新規作成したとき、他に何が作られる？CloudTrailでAWS APIと作成されたリソースを確認してみた

WAF AutomatorでWeb ACLを新規作成したとき、他に何が作られる？CloudTrailでAWS APIと作成されたリソースを確認してみた

WAF AutomatorでAWS WAFのWeb ACLを新規作成した際、AWSアカウント内でどのような処理が行われるのかをCloudTrailで確認しました。CyberNEOが利用するIAMロールや、ログ出力環境を含む関連リソースの作成・設定内容を解説します。
AWS WAFAWS IAMAWS CloudTrailAWSセキュリティ
2026.09.16

はじめに

クラウド事業統括本部 プロフェッショナルサービス事業本部 コンサルティング2部の山﨑です。

以前、WAF AutomatorのポータルからAWS WAFのWeb ACLを新規作成してみました。

WAF AutomatorでAWS WAFのWeb ACLを新規作成してみた

WAF Automator for AWSのサービス紹介ページには、CyberNEOポータルにWeb ACLの情報を入力すると、ログ出力環境、Web ACLやルールグループが自動展開されると記載されています。

また、お客様のAWSテナントへの接続では、CyberNEOのLambdaからAWS WAFとS3バケットへアクセスする構成であることも案内されています。

WAF Automator for AWS | クラスメソッドセキュリティ株式会社

Web ACLの作成に伴い、AWSアカウント内で実際にどのようなAWS APIが呼び出され、どのようなリソースが作成・設定されるのか気になりました。

そこで今回は、Web ACLを新規作成した際のCloudTrailイベントを確認し、AWSマネジメントコンソールでも作成されたリソースを確認してみます。

本記事は、2026年9月14日にap-northeast-1リージョンで実施した検証時のCloudTrailイベントを基にした確認結果です。
CyberNEOのすべての操作や、すべての構成で同一の結果になることを示すものではありません。

今回確認すること

CyberNEOポータルからWeb ACLを新規作成した際の下記内容を確認します。

  • CloudFormationで作成したIAMロールが実際に使用されているか
  • CyberNEOが実行したAWS API
  • Web ACL以外に作成されたAWSリソース
  • AWSマネジメントコンソール上でのリソース作成結果

先に結論

CloudTrailを確認した結果、CyberNEOはCloudFormationで作成した CyberNEO-Access-Role を AssumeRole で引き受け、cn_waf_session というセッション名でAWS APIを実行していました。

Web ACLの新規作成に伴い、今回の検証では以下の作成・設定イベントを確認できました。

サービス 確認できた作成・設定
AWS WAF Web ACLの作成、Regex pattern setの作成、ルールグループの作成、IP setの作成、Web ACLの更新、ログ出力設定
Amazon S3 WAFログ保存用バケットの作成、S3 Block Public Access設定、バケットポリシー設定
AWS Glue テーブルの作成

CloudFormationで作成したCyberNEO接続用IAMロールの確認

前回の記事では、CyberNEOポータルからAWSアカウントへ接続するため、CloudFormationを使用してIAMロールを作成しました。

作成したIAMロールは以下です。

IAMロール名：CyberNEO-Access-Role

信頼ポリシー

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<CYBERNEO_ACCOUNT_ID>:root"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "sts:ExternalId": "<EXTERNAL_ID>"
                }
            }
        }
    ]
}

許可ポリシー

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Action": [
				"wafv2:*"
			],
			"Resource": [
				"arn:aws:wafv2:*:<AWS_ACCOUNT_ID>:*/webacl/*",
				"arn:aws:wafv2:*:<AWS_ACCOUNT_ID>:*/rulegroup/*",
				"arn:aws:wafv2:*:<AWS_ACCOUNT_ID>:*/ipset/*",
				"arn:aws:wafv2:*:<AWS_ACCOUNT_ID>:*/regexpatternset/*",
				"arn:aws:wafv2:*:<AWS_ACCOUNT_ID>:*/managedruleset/*"
			],
			"Effect": "Allow",
			"Sid": "WAFv2Manage"
		},
		{
			"Action": [
				"s3:CreateBucket",
				"s3:DeleteBucket",
				"s3:ListBucket",
				"s3:GetBucketLocation",
				"s3:GetBucketAcl",
				"s3:PutBucketAcl",
				"s3:GetBucketPolicy",
				"s3:PutBucketPolicy",
				"s3:GetBucketNotification",
				"s3:PutBucketNotification",
				"s3:GetBucketPublicAccessBlock",
				"s3:PutBucketPublicAccessBlock"
			],
			"Resource": [
				"arn:aws:s3:::aws-waf-logs-cyberneo-*",
				"arn:aws:s3:::cn-waf-*"
			],
			"Effect": "Allow",
			"Sid": "WAFLogBucketManage"
		},
		{
			"Action": [
				"s3:GetObject",
				"s3:PutObject",
				"s3:DeleteObject",
				"s3:ListMultipartUploadParts",
				"s3:AbortMultipartUpload"
			],
			"Resource": [
				"arn:aws:s3:::aws-waf-logs-cyberneo-*/*",
				"arn:aws:s3:::cn-waf-*/*"
			],
			"Effect": "Allow",
			"Sid": "WAFLogBucketObjects"
		},
		{
			"Action": [
				"logs:CreateLogDelivery",
				"logs:DeleteLogDelivery",
				"logs:GetLogDelivery",
				"logs:UpdateLogDelivery",
				"logs:ListLogDeliveries",
				"logs:PutResourcePolicy",
				"logs:DescribeResourcePolicies",
				"logs:DescribeLogGroups"
			],
			"Resource": "*",
			"Effect": "Allow",
			"Sid": "VendedLogsDelivery"
		},
		{
			"Action": [
				"glue:GetDatabase",
				"glue:GetDatabases",
				"glue:CreateDatabase",
				"glue:UpdateDatabase",
				"glue:GetTable",
				"glue:GetTables",
				"glue:CreateTable",
				"glue:UpdateTable",
				"glue:DeleteTable",
				"glue:DeleteDatabase",
				"glue:GetPartitions",
				"glue:GetPartition",
				"glue:BatchGetPartition"
			],
			"Resource": [
				"arn:aws:glue:*:<AWS_ACCOUNT_ID>:catalog",
				"arn:aws:glue:*:<AWS_ACCOUNT_ID>:database/cyberneo_waf",
				"arn:aws:glue:*:<AWS_ACCOUNT_ID>:table/cyberneo_waf/*",
				"arn:aws:glue:*:<AWS_ACCOUNT_ID>:userDefinedFunction/cyberneo_waf/*"
			],
			"Effect": "Allow",
			"Sid": "GlueCatalogManage"
		},
		{
			"Action": [
				"athena:CreateWorkGroup",
				"athena:GetWorkGroup",
				"athena:UpdateWorkGroup",
				"athena:DeleteWorkGroup",
				"athena:ListWorkGroups",
				"athena:StartQueryExecution",
				"athena:StopQueryExecution",
				"athena:GetQueryExecution",
				"athena:GetQueryResults",
				"athena:GetQueryResultsStream",
				"athena:ListQueryExecutions",
				"athena:BatchGetQueryExecution"
			],
			"Resource": [
				"arn:aws:athena:*:<AWS_ACCOUNT_ID>:workgroup/cyberneo-waf",
				"arn:aws:athena:*:<AWS_ACCOUNT_ID>:datacatalog/AwsDataCatalog"
			],
			"Effect": "Allow",
			"Sid": "AthenaQuery"
		},
		{
			"Condition": {
				"StringLike": {
					"iam:AWSServiceName": "wafv2.amazonaws.com"
				}
			},
			"Action": [
				"iam:CreateServiceLinkedRole"
			],
			"Resource": [
				"arn:aws:iam::<AWS_ACCOUNT_ID>:role/aws-service-role/wafv2.amazonaws.com/AWSServiceRoleForWAFV2Logging"
			],
			"Effect": "Allow",
			"Sid": "WAFServiceLinkedRole"
		},
		{
			"Action": [
				"iam:CreateRole",
				"iam:CreatePolicy",
				"iam:AttachRolePolicy",
				"iam:DeleteRole",
				"iam:DeletePolicy",
				"iam:DetachRolePolicy",
				"iam:PassRole",
				"firehose:CreateDeliveryStream",
				"firehose:DescribeDeliveryStream",
				"firehose:DeleteDeliveryStream"
			],
			"Resource": [
				"arn:aws:iam::<AWS_ACCOUNT_ID>:role/CyberneoFirehoseRole-*",
				"arn:aws:iam::<AWS_ACCOUNT_ID>:policy/CyberneoFirehosePolicy-*",
				"arn:aws:firehose:*:<AWS_ACCOUNT_ID>:deliverystream/aws-waf-logs-*"
			],
			"Effect": "Allow",
			"Sid": "FirehoseDeployment"
		}
	]
}

CloudTrailで確認してみる

CyberNEOポータルからWeb ACLを新規作成した際に、どのような処理が実行されたのかを確認するため、AWS CloudTrailのイベント履歴を確認します。

今回は、以下の条件を目印にイベントを確認しました。

項目 値
リージョン ap-northeast-1
IAMロール CyberNEO-Access-Role
ロールセッション名 cn_waf_session

CloudTrailログの抜粋

CreateWebACL が記録された日時前後のイベントを確認しました。

なお、今回の検証アカウントには、以前にWAF Automatorから作成したWeb ACLが存在していました。

そのため、一部のエラーイベントには、以前の操作で作成された関連リソースが影響している可能性があります。

イベント履歴には Get* や List* などの参照系APIも含まれますが、ここではリソースの作成・設定・更新に関係する主なイベントを抜粋します。

Event time (UTC) Event source Event name Error code 確認できた処理
2026-09-14 05:15:36 wafv2.amazonaws.com CreateWebACL — Web ACLの作成
2026-09-14 05:15:37 s3.amazonaws.com CreateBucket — S3バケットの作成
2026-09-14 05:15:37 s3.amazonaws.com PutBucketPublicAccessBlock — S3 Block Public Access設定
2026-09-14 05:15:37 s3.amazonaws.com PutBucketPolicy — S3バケットポリシー設定
2026-09-14 05:15:37 wafv2.amazonaws.com PutLoggingConfiguration — Web ACLのログ記録設定
2026-09-14 05:15:38 glue.amazonaws.com CreateTable — Glueテーブルの作成
2026-09-14 05:15:38 glue.amazonaws.com CreateDatabase AlreadyExistsException 既存のGlueデータベースと同名のデータベース作成を試行
2026-09-14 05:15:38 athena.amazonaws.com CreateWorkGroup InvalidRequestException Athenaワークグループ作成を試行
2026-09-14 05:15:41 wafv2.amazonaws.com CreateRegexPatternSet — Regex pattern setの作成
2026-09-14 05:15:42 wafv2.amazonaws.com CreateRuleGroup WAFUnavailableEntityException ルールグループ作成を試行
2026-09-14 05:15:43〜05:15:55 wafv2.amazonaws.com CreateRuleGroup — ルールグループの作成
2026-09-14 05:15:44〜05:15:57 wafv2.amazonaws.com UpdateWebACL 一部で WAFUnavailableEntityException Web ACLの更新
2026-09-14 05:15:51〜05:15:54 wafv2.amazonaws.com CreateIPSet — IP setの作成

S3バケットについては、CreateBucket のリソース情報に以下の形式のバケット名が記録されていました。

aws-waf-logs-cyberneo-<UUID>

また、PutBucketPolicy と同じ時刻に、 GetBucketPolicy が NoSuchBucketPolicy で記録されていました。

CloudTrailのイベント時刻は秒単位のため、同一秒内の厳密な実行順序は判断できません。

GetBucketPolicy がNoSuchBucketPolicy となっていましたが、PutBucketPolicyは成功しており、最終的に対象バケットへバケットポリシーが設定されていることをAWSマネジメントコンソールで確認できました。

なお、CreateDatabase は AlreadyExistsException、CreateWorkGroup は InvalidRequestException となっていました。

イベントを時系列で整理する

抜粋したイベントを整理すると、今回のWeb ACL新規作成では、概ね以下の順番で処理が実行されていました。

CloudTrailのイベント時刻は秒単位であり、同じ時刻に複数のAPIが記録されています。また、一部のAPIは実行時間帯が重複しています。そのため、以下は厳密な実行順序ではなく、イベント時刻と処理内容を基に整理した概略です。

1. AWS WAFでWeb ACLを作成する
2. WAFログの保存先となるS3バケットを作成する
3. S3バケットにパブリックアクセスブロックとバケットポリシーを設定する
4. Web ACLにログ記録設定を追加する
5. Glueテーブルを作成する
6. Regex pattern setを作成する
7. ルールグループを作成する
8. Web ACLを更新する
9. IP setを作成する
10. Web ACLを更新する

この流れから、CyberNEOポータルでWeb ACLを新規作成する操作では、Web ACL単体を作成するだけではなく、以下のリソース・設定もあわせて作成または更新されることが分かります。

  • WAFログ保存用のS3バケット
  • S3 Block Public Access設定
  • S3バケットポリシー
  • Web ACLのログ記録設定
  • Glueテーブル
  • Regex pattern set
  • ルールグループ
  • IP set
  • Web ACLのルール構成

一部の CreateRuleGroup や UpdateWebACL では WAFUnavailableEntityException が記録されていました。しかし、その後に同じAPIの成功イベントも記録されています。

CloudTrailのイベント履歴からは、処理の途中で一時的なエラーが発生した後にも、後続の作成・更新処理が行われていたことを確認できました。

AWSマネジメントコンソールで確認してみる

Web ACLを確認する

まず、CloudTrailで CreateWebACL が成功していたため、AWS WAFコンソールでWeb ACLが作成されているか確認します。

マネジメントコンソールの「リソースと保護パック (ウェブ ACL)」を開くと、CyberNEOポータルで指定した名前のWeb ACLを確認できました。

WAF Automator新規作成リソース確認1

対象のWeb ACLを開き、ルールを確認します。

WAF Automator新規作成リソース確認2

CloudTrailでは、Web ACL作成後に複数回の UpdateWebACL が記録されていました。

コンソール上でも、Web ACLにルールが設定されていることを確認できました。

WAFログ保存用S3バケットを確認する

続いて、CloudTrailで CreateBucket、PutBucketPublicAccessBlock、PutBucketPolicy が成功していたS3バケットを確認します。

Amazon S3コンソールを開くと、以下の形式のバケットが作成されていました。

aws-waf-logs-cyberneo-<UUID>

WAF Automator新規作成リソース確認3

対象バケットの「アクセス許可」タブを開きます。

CloudTrailで PutBucketPublicAccessBlock が記録されていたため、パブリックアクセスのブロック設定を確認します。

WAF Automator新規作成リソース確認4

パブリックアクセスをすべてブロックが有効に設定されていることを確認できました。

続いて、CloudTrailで PutBucketPolicy が記録されていたため、バケットポリシーを確認します。

WAF Automator新規作成リソース確認5

バケットポリシーが設定されていることを確認できました。

Web ACLのログ記録設定を確認する

CloudTrailでは、S3バケット関連の設定と同じ時刻に、AWS WAFの PutLoggingConfiguration が成功していました。

そのため、Web ACLのログ記録設定を確認します。

対象のWeb ACLを開き、ログ記録送信先を確認します。

WAF Automator新規作成リソース確認6

ログ出力先として、先ほど確認した aws-waf-logs-cyberneo-<UUID> 形式のS3バケットが設定されていることを確認できました。

CloudTrailのイベントとコンソール画面を照らし合わせることで、以下の流れを確認できました。

S3バケットを作成する
  ↓
S3バケットに公開防止・アクセス許可の設定を行う
  ↓
Web ACLのログ出力先としてS3バケットを設定する

Glueテーブルを確認する

CloudTrailでは、AWS Glueの CreateTable が成功していました。

AWS Glueコンソールでデータカタログのテーブルを確認します。

WAF Automator新規作成リソース確認7

対象のGlueデータベース内にテーブルが作成されていることを確認できました。

WAF Automator新規作成リソース確認8

CloudTrailでは CreateDatabase が AlreadyExistsException となっていたため、作成しようとしたGlueデータベースはすでに存在していました。

今回の検証アカウントには、以前にWAF Automatorから作成したWeb ACLが存在していたことから、その際に作成された共通のGlueデータベースを今回も利用した可能性があります。

一方で、CreateTable の成功イベントとコンソール上の表示から、既存のGlueデータベースに新しいテーブルが作成されたことを確認できました。

正規表現パターンセットを確認する

CloudTrailでは、AWS WAFの CreateRegexPatternSet が成功していました。

マネジメントコンソールの「正規表現パターンセット」を開きます。

WAF Automator新規作成リソース確認9

正規表現パターンセットが作成されていることを確認できました。

ルールグループを確認する

CloudTrailでは、CreateRuleGroup の成功イベントを確認できました。

一部のイベントでは WAFUnavailableEntityException が記録されていましたが、その後に成功イベントが記録されていました。

AWS WAFコンソールの Rule groups を開きます。

WAF Automator新規作成リソース確認10

今回の検証では、CloudTrail上で作成成功を確認できたルールグループが、コンソール上にも作成されていることを確認できました。

IP セットを確認する

CloudTrailでは、CreateIPSet の成功イベントを4件確認できました。

AWS WAFコンソールの「IP セット」を開きます。

WAF Automator新規作成リソース確認11

CloudTrailの作成イベントに対応するIP セットが作成されていることを確認できました。

また、CloudTrailでは UpdateIPSet のイベントも記録されていました。

まとめ

WAF AutomatorのCyberNEOポータルからWeb ACLを新規作成した際に、CloudTrailで実行されたAWS APIと作成・設定されたリソースを確認してみました。

今回の検証では、CyberNEOはCloudFormationで作成した CyberNEO-Access-Role を引き受け、cn_waf_session のロールセッションでAWS APIを実行していました。

Web ACLの作成に加えて、以下のリソース作成・設定がCloudTrailで確認できました。

  • WAFログ保存用S3バケットの作成
  • S3 Block Public Accessおよびバケットポリシーの設定
  • Web ACLのログ出力設定
  • Glueテーブルの作成
  • Regex pattern setの作成
  • ルールグループの作成
  • IP setの作成
  • Web ACLの更新

サービスページに記載されている「ログ出力環境」「Web ACL」「ルールグループ」の自動展開について、今回の検証ではCloudTrailイベントおよびAWSコンソールから関連する操作を確認できました。

CloudTrailを確認すると、マネージドサービス経由の操作であっても、どのIAMロールが利用され、どのAWSサービスに対してどのようなAPIが実行されたのかを追跡できることが分かりました。

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事

セキュリティ運用は Kiro CLI か AWS DevOps Agent のカスタムエージェントか？同じ SecOps タスクで比べてみた
ひろたこ
2026.07.13
【AWS研修レポート】Cloud Operations on AWS Day3 - セキュリティとストレージ編
yyamamoto-kakeru
2026.01.08
WAF AutomatorでAWS WAFのWeb ACLを新規作成してみた
山﨑 和真
2026.09.14
Athena で CloudTrail ログ（S3 データイベント）を直接クエリして、IAM ユーザーやロールが操作したオブジェクトを特定する
m.hayakawa
2026.09.04