はじめに
kyonosukeです。
GuardDutyのインシデント調査といえば、膨大な量のログ確認と専門的なセキュリティスキルが求められるタスクです。
しかし生成AIの登場によっていままでのインシデント対応が過去のものになりました。
今回はいままでの調査方法を振り返った後に、Amazon Q Developer CLIを利用した革命的な調査対応を実施してみました。
目次
前提
今回は以下のGuardDuty検知タイプを題材として調査をします。
Policy:S3/BucketPublicAccessGranted
これはバケットポリシーやACLを変更することで、すべてのユーザにS3バケットへのパブリックアクセスを許可する操作を異常として判断する検知タイプです。
本来はプライベートに使用するつもりだったS3バケットが、パブリックに誰でもアクセスできていまい、意図しない不正利用を行われることが想定されます。
適当にS3バケットを作成し、以下のバケットポリシーを設定します。この段階ではアカウント内のユーザしかアクセスできない状態です。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSpecificAccount",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::XXXX:root"
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::test-my-secret-bucket-kyonosuke-202507021744",
"arn:aws:s3:::test-my-secret-bucket-kyonosuke-202507021744/*"
]
}
]
}
これを以下のように変更してみます。プリンシパルが*なので誰からでもアクセスできるようになりました。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSpecificAccount",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::test-my-secret-bucket-kyonosuke-202507021744",
"arn:aws:s3:::test-my-secret-bucket-kyonosuke-202507021744/*"
]
}
]
}
今までのGuardDuty調査対応
Amazon Q を利用する前に、これまでのGuardDuty調査対応を振り返ってみましょう。
GuardDutyコンソール確認
まずはGuardDutyコンソールを確認して、インシデントの概要を把握します。
バッチリ検出してますね。
JSONを解読し、「GuardDutyが異常と判断した箇所」を特定します。
GuardDutyコンソールから得られるJSON（一部マスキング）
[
{
"AccountId": "XXXX",
"Arn": "arn:aws:guardduty:ap-northeast-1:XXXX:detector/XXXX/finding/dccbe52fade6cbf534a90ef0604d3359",
"CreatedAt": "2025-07-02T09:02:16.525Z",
"Description": "The Amazon S3 bucket test-my-secret-bucket-kyonosuke-202507021744 was granted public anonymous access by AWSReservedSSO_AWSAdministratorAccess_XXXX calling PutBucketPolicy. If this behavior is not expected, it may indicate a configuration mistake or that your credentials are compromised.",
"Id": "dccbe52fade6cbf534a90ef0604d3359",
"Partition": "aws",
"Region": "ap-northeast-1",
"Resource": {
"AccessKeyDetails": {
"AccessKeyId": "XXXX",
"PrincipalId": "AROA6D2FUA7DXAO7WIIFO:XXXX@gmail.com",
"UserName": "AWSReservedSSO_AWSAdministratorAccess_XXXX",
"UserType": "AssumedRole"
},
"S3BucketDetails": [
{
"Arn": "arn:aws:s3:::test-my-secret-bucket-kyonosuke-202507021744",
"Name": "test-my-secret-bucket-kyonosuke-202507021744",
"Type": "Destination",
"CreatedAt": "2025-07-02T08:55:59.000Z",
"Owner": {
"Id": "c5d39fb3aae42321f67fee6dbc04b5323918949d7a4c6d1b4c0614caceda2fce"
},
"DefaultServerSideEncryption": {
"EncryptionType": "AES256"
},
"PublicAccess": {
"PermissionConfiguration": {
"BucketLevelPermissions": {
"AccessControlList": {
"AllowsPublicReadAccess": false,
"AllowsPublicWriteAccess": false
},
"BucketPolicy": {
"AllowsPublicReadAccess": true,
"AllowsPublicWriteAccess": true
},
"BlockPublicAccess": {
"IgnorePublicAcls": false,
"RestrictPublicBuckets": false,
"BlockPublicAcls": false,
"BlockPublicPolicy": false
}
},
"AccountLevelPermissions": {
"BlockPublicAccess": {
"IgnorePublicAcls": false,
"RestrictPublicBuckets": false,
"BlockPublicAcls": false,
"BlockPublicPolicy": false
}
}
},
"EffectivePermission": "PUBLIC"
}
}
],
"ResourceType": "AccessKey"
},
"SchemaVersion": "2.0",
"Service": {
"Action": {
"ActionType": "AWS_API_CALL",
"AwsApiCallAction": {
"Api": "PutBucketPolicy",
"CallerType": "Remote IP",
"RemoteIpDetails": {
"City": {
"CityName": "XXXX"
},
"Country": {
"CountryName": "Japan"
},
"GeoLocation": {
"Lat": XXXX,
"Lon": XXXX
},
"IpAddressV4": "XXXX",
"Organization": {
"Asn": "9824",
"AsnOrg": "JCOM Co., Ltd.",
"Isp": "J:COM",
"Org": "J:COM"
}
},
"ServiceName": "s3.amazonaws.com",
"AffectedResources": {
"AWS::S3::Bucket": "test-my-secret-bucket-kyonosuke-202507021744"
}
}
},
"Archived": false,
"Count": 1,
"DetectorId": "XXXX",
"EventFirstSeen": "2025-07-02T08:56:36.000Z",
"EventLastSeen": "2025-07-02T08:56:36.000Z",
"ResourceRole": "TARGET",
"ServiceName": "guardduty",
"AdditionalInfo": {
"Value": "{}",
"Type": "default"
}
},
"Severity": 8,
"Title": "Amazon S3 Public Anonymous Access was granted for the S3 bucket test-my-secret-bucket-kyonosuke-202507021744.",
"Type": "Policy:S3/BucketAnonymousAccessGranted",
"UpdatedAt": "2025-07-02T09:02:16.525Z"
}
]
うーんむずかしい。
熟練のセキュリティエンジニアなら解読できますが、初心者にはちょっと難しいですよね。
しかもすべてのGuardDuty検知タイプが同じフォーマットでログを吐き出すわけではなく、微妙に少しずつ違うのも厄介です。
今回の場合はS3バケット"arn:aws:s3:::test-my-secret-bucket-kyonosuke-202507021744"のバケットポリシーを、"PrincipalId": "AROA6D2FUA7DXAO7WIIFO:XXXX@gmail.com"が変更したことを検知しています。
Descriptionを翻訳するとこんな感じです。
"AWSReservedSSO_AWSAdministratorAccess_XXXXがPutBucketPolicyを呼び出すことで、Amazon S3バケットtest-my-secret-bucket-kyonosuke-202507021744に公開匿名アクセスが付与されました。
この動作が予期されない場合は、設定ミスまたは認証情報が漏洩している可能性があります。"
各種ログ確認
必要に応じてCloudTrailログやVPCフローログを確認します。
今回はS3バケットに対するAPIコールを検知してるので、CloudTrailを見に行きましょう。
ここで見るべき観点は、バケットポリシーをどのように変更したかという点です。
このあと作業者にこの操作が意図したものかを確認しますが、その際に「どんなリクエストをしたのか」を明確にしておく必要があります。作業者との円滑なコミュニケーションのために、セキュリティ担当者が調べられることは先に用意しておくべきです。
GuardDutyから得られたログによると、2025-07-02 17:56:36に最初の操作が行われたことを確認できます。この情報をもとにCloudTrailを確認すると、以下のようなAPIリクエストが見つかりました。
"requestParameters": {
"bucketPolicy": {
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSpecificAccount",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::test-my-secret-bucket-kyonosuke-202507021744",
"arn:aws:s3:::test-my-secret-bucket-kyonosuke-202507021744/*"
]
}
]
},
"bucketName": "test-my-secret-bucket-kyonosuke-202507021744",
"Host": "test-my-secret-bucket-kyonosuke-202507021744.s3.ap-northeast-1.amazonaws.com",
"policy": ""
}
"Principal": "*"に変更したことを記録していますね。
CloudTrailログを読むのもなかなかストレスがかかる作業ですが、何とか見つかりました。
これで情報が揃いました。
1点注釈です。本ブログでは簡略化のため、CloudTrailのイベント履歴を直接検索しています。業務利用であればS3に保存したCloudTrailログをAthenaで分析したり、CloudTrail Lakeを使用してクエリを行うのが一般的かと思います。
今回これらまで紹介すると本ブログの趣旨からそれて冗長になってしまうので省略します。
これらクエリ機能については以下の記事が参考になります。
CloudTrailの操作履歴ログをAthenaで分析する手順
S3に格納されているVPCフローログをAthenaでサクっと抽出する手順
[アップデート] CloudTrailログ分析環境が超絶簡単に手に入る！「CloudTrail Lake」がリリースされました
作業者への操作確認
作業者とその行動が特定できたので、作業者に事実確認の連絡をしましょう。
以下のような形式で、作業者に問い合わせを行いましょう。
@ XXXX@gmail.comさん
GuardDutyインシデントを検知したのでご連絡します。
以下の操作について、意図した操作かをご確認ください。
概要：バケットポリシーの変更し、S3バケットに制限なしアクセスを許可
日付：2025-07-02 17:56:36
AccountId：XXXX
実行したAPI：PutBucketPolicy
対象リソース：test-my-secret-bucket-kyonosuke-202507021744
作業者の意図した操作ではない場合の対応
作業者の意図した操作の場合は、インシデントはクローズとしてよいかと思います。
作業者への問い合わせの結果、作業者の意図した操作ではない場合はリソースが侵害されているおそれがあります。
上記のCloudTrailログやS3データアクセスログなどをソースとして、情報流出や攻撃の形跡がないかを即座に調査する必要があります。本ブログでは省略します。
インシデントレポート作成
顧客によっては検出したインシデントのレポート作成を求められるかもしれません。
ここまでをサマリしてパワポなりを作成するのが通例ですが、ご想像の通りかなり手間のかかる作業です。本ブログでは省略します。
ここまでまとめ
従来のGuardDuty調査対応を見てみましたが、結構大変な作業であることがわかってもらえたでしょうか。GuardDutyを読み解くのには専門知識が必要であり、経験の浅い新人には少し難しいタスクかもしれません。セキュリティ人材が不足していると言われて久しいですが、毎日こんな対応を続けていたら担当者がアラート疲れに陥ってしまいます。
フローチャートにするとこんな感じです。
以降はこの作業をAmazon Q Developer CLI を使って効率化することを目指します。
Amazon Q Developer CLI を利用したインシデント調査
ではいよいよAmazon Q Developer CLI を利用してGuardDutyのインシデント調査を行ってみます。
Amazon Q Developer CLI 導入方法
本書の趣旨から逸れるので詳細は省きます。公式ドキュメントなどを参考にインストールをしてください。
q chatでAmazon Qと対話ができるようになったらOKです。
コマンドライン用の Amazon Q をインストールする
MCPサーバの設定
AWSのドキュメントを参照しながら最新のベストプラクティスに沿った提案をしてくれたらうれしいので、awslabs.aws-documentation-mcp-serverを設定します。サイバーセキュリティの脅威は日々変化・進化しており、その対策方法のリアルタイムなキャッチアップはとても大切です。社内のプレイブックをそのたびに更新してたらキリがないです。公式のドキュメントを直接参照する方が圧倒的に効率がよく、さらにセキュリティの担保がされます。
そもそもMCPってなに？って人は以下の記事が参考になります。
MCPサーバは以下のように設定します。
touch ~/.aws/amazonq/mcp.json
{
"mcpServers": {
"awslabs.aws-documentation-mcp-server": {
"command": "uvx",
"args": [
"awslabs.aws-documentation-mcp-server@latest"
],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR"
},
"disabled": false,
"autoApprove": [
"read_documentation"
]
}
}
}
これで次回以降のAmazon Q の起動のたびに、MCPサーバを読み込めるようになりました。
q chatでインシデント調査
q chatと入力し、Amazon Qとの会話を開始しましょう。
まずは以下のプロンプトを与えてみます。
アカウントXXXXにサインインし、GuardDutyの検出結果ID'dccbe52fade6cbf534a90ef0604d3359'について調べてください。
するとまずDetecotorIDの取得から始まりました。
> GuardDutyの検出結果を調べます。まず、GuardDutyの検出結果を取得するためには、DetectorIdが必要です。最初にアクティブなDetectorを確認して
から、検出結果の詳細を取得します。
🛠️ Using tool: use_aws (trusted)
⋮
● Running aws cli command:
Service name: guardduty
Operation name: list-detectors
Parameters:
Profile name: XXXX
Region: ap-northeast-1
Label: GuardDuty Detectorの一覧取得
⋮
● Completed in 2.335s
次にDetectorIDを用いてGuardDutyの検出結果を見つけてきました。
> DetectorIdが確認できました。次に、指定された検出結果IDの詳細を取得します。
🛠️ Using tool: use_aws (trusted)
⋮
● Running aws cli command:
Service name: guardduty
Operation name: get-findings
Parameters:
- detector-id: "XXXX"
- finding-ids: ["dccbe52fade6cbf534a90ef0604d3359"]
Profile name: XXXX
Region: ap-northeast-1
Label: GuardDuty検出結果の詳細取得
⋮
● Completed in 2.441s
最後に検出結果の概要をまとめてくれました。
> GuardDutyの検出結果の詳細を取得しました。以下が検出結果の概要です：
## 検出結果の概要
検出タイプ: Policy:S3/BucketAnonymousAccessGranted
重要度: 8.0 (高)
ステータス: アクティブ（アーカイブされていない）
## 検出内容
問題: S3バケット test-my-secret-bucket-kyonosuke-202507021744 に対してパブリック匿名アクセスが許可されました。
実行されたアクション:
• API: PutBucketPolicy
• 実行者: AWSReservedSSO_AWSAdministratorAccess_XXXX
• 実行日時: 2025年7月2日 08:56:36 UTC
## セキュリティ上の懸念
現在の権限設定:
• パブリック読み取りアクセス: 有効
• パブリック書き込みアクセス: 有効
• Block Public Access設定: すべて無効
アクセス元情報:
• IPアドレス: XXXX
• 場所: XXXX
• ISP: J:COM
## 推奨対応
1. 即座の対応: このバケットが意図的にパブリックアクセスを必要としない場合は、バケットポリシーを削除または制限してください
2. Block Public Access設定の有効化: S3バケットのBlock Public Access設定を有効にすることを検討してください
3. アクセスログの確認: 不正なアクセスがないか、CloudTrailログを確認してください
この検出は、機密データを含む可能性のあるS3バケットが意図せずパブリックアクセス可能になったことを示しており、早急な対応が必要です。
めちゃくちゃいい感じですね！いままで人力で読み解かなきゃいけなかった難解なGuardDutyが、わずか数秒でAmazon Q によって翻訳されました。
続いてCloudTrailを参照させて、APIリクエストを確認しましょう。
CloudTrailログを参照し、test-my-secret-bucket-kyonosuke-202507021744がどんなバケットポリシーに変更されたのかを確認してください。
まずはCloudTrailでPutBucketPolicyを探し始めました。
🛠️ Using tool: use_aws
⋮
● Running aws cli command:
Service name: cloudtrail
Operation name: lookup-events
Parameters:
- lookup-attributes: [{"AttributeKey":"EventName","AttributeValue":"PutBucketPolicy"}]
- end-time: "2025-07-03T00:00:00Z"
- start-time: "2025-07-02T00:00:00Z"
Profile name: audit
Region: ap-northeast-1
Label: Search CloudTrail events for S3 bucket policy changes
● Completed in 0.887s
次に該当のS3バケットについて調査を始めました。
さらに詳細な情報を得るため、パブリックアクセスブロック設定の変更履歴も確認しましょう：
🛠️ Using tool: use_aws (trusted)
⋮
● Running aws cli command:
Service name: cloudtrail
Operation name: lookup-events
Parameters:
- lookup-attributes: [{"AttributeKey":"ResourceName","AttributeValue":"test-my-secret-bucket-kyonosuke-202507021744"}]
- end-time: "2025-07-03T00:00:00Z"
- start-time: "2025-07-02T00:00:00Z"
Profile name: audit
Region: ap-northeast-1
Label: Search CloudTrail events for S3 public access block changes
⋮
● Completed in 0.976s
最後にサマリをしてくれました。
## CloudTrail調査結果レポート
バケット: test-my-secret-bucket-kyonosuke-202507021744
調査期間: 2025年7月2日
実行者: XXXX@gmail.com (AWSReservedSSO_AWSAdministratorAccess_XXXX)
### **危険なパブリックポリシー設定** (17:56:36 JST) - 成功 ⚠️
• **イベント**: PutBucketPolicy
• **EventID**: 7e161bc6-089b-4edf-b933-3af351b08648
• **設定されたポリシー** (現在も有効):
json
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "AllowSpecificAccount",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::test-my-secret-bucket-kyonosuke-202507021744",
"arn:aws:s3:::test-my-secret-bucket-kyonosuke-202507021744/*"
]
}]
}
### **重要な発見事項**
1. 意図的な設定変更: ユーザーは最初にセキュアな設定を試みたが、その後意図的にパブリックアクセスを許可する設定に変更
2. セキュリティ機能の迂回: パブリックアクセスブロック機能が最初はパブリックポリシーの設定を阻止していたが、ユーザーがこれを無効化してからパブリッ
クポリシーを適用
3. 段階的な設定変更:
• 正常なアカウント限定ポリシー → パブリックアクセスブロック無効化 → 完全パブリックアクセス許可
4. GuardDutyアラートのタイミング: 最後のパブリックポリシー設定から約6分後にGuardDutyがアラートを発報
### **結論**
この設定変更は**意図的**に行われており、ユーザーがセキュリティ制御を意図的に迂回してパブリックアクセスを許可したことが明確です。テスト目的の可能
性もありますが、現在の設定は極めて危険な状態です。
すごくいい感じです。CloudTrailを時系列で追ってくれており、作業者がどういう流れでバケットポリシーを変更したのかを説明してくれています。
作業者への操作確認
作業者とその行動が特定できたので、作業者に事実確認の連絡をしましょう。
ここは今までと同じです。生成AIが介入する余地もありそうですが、個人的には人間同士のやり取りをしたほうがスピーディに解決する気がします。
ただ作業者への連絡メッセージは作成できます。
以下の形式で作業者に操作の事実確認を行います。得られた洞察から空欄を埋めてください。
概要：
日付：
AccountId：
実行したAPI：
対象リソース：
CloudTrail調査結果から得られた洞察を基に、以下の形式で事実確認を行います：
概要： S3バケットに対してパブリックアクセスブロック設定を無効化し、その後完全なパブリックアクセスを許可するバケットポリシーを意図的に設定。セキ
ュリティ制御を段階的に迂回してパブリック公開状態を実現。
日付： 2025年7月2日 17:55:58 - 17:56:36 JST（パブリックアクセスブロック無効化からパブリックポリシー設定まで）
AccountId： XXXX
実行したAPI：
• PutBucketPublicAccessBlock（パブリックアクセスブロック無効化）
• PutBucketPolicy（パブリック匿名アクセス許可ポリシー設定）
対象リソース： S3バケット test-my-secret-bucket-kyonosuke-202507021744
補足情報：
• 実行者：XXXX@gmail.com（AWSReservedSSO_AWSAdministratorAccess_XXXX）
• アクセス元IP：XXXX
• 設定されたポリシー：Principal "*"、Action "s3:*" による完全パブリックアクセス許可
すごすぎますね。このまま作業者に投げていいレベルです。
頼んでもないのに補足情報まで記載してくれており、作業者にとって親切な内容になっています。
リソースの修正対応
必要に応じてリソースの修正対応を行います。
せっかくなのでAmazon Q に修正を行ってもらいましょう。
問題と思われるバケットポリシーを修正してください。S3パブリックアクセスブロックを有効化に設定し、無制限アクセスを許可しないようにしてください。
まずはバケットポリシーの削除から始まりました。
## 1. 現在の危険なバケットポリシーを削除
🛠️ Using tool: use_aws (trusted)
⋮
● Running aws cli command:
Service name: s3api
Operation name: delete-bucket-policy
Parameters:
- bucket: "test-my-secret-bucket-kyonosuke-202507021744"
Profile name: XXXX
Region: ap-northeast-1
Label: Delete dangerous public bucket policy
⋮
● Completed in 2.960s
続いてパブリックブロックアクセスの有効化を設定しています。
## 2. パブリックアクセスブロックを有効化
🛠️ Using tool: use_aws (trusted)
⋮
● Running aws cli command:
Service name: s3api
Operation name: put-public-access-block
Parameters:
- public-access-block-configuration: {"BlockPublicAcls":true,"BlockPublicPolicy":true,"IgnorePublicAcls":true,"RestrictPublicBuckets":true}
- bucket: "test-my-secret-bucket-kyonosuke-202507021744"
Profile name: XXXX
Region: ap-northeast-1
Label: Enable S3 public access block settings
⋮
● Completed in 1.126s
次にセキュアなバケットポリシーの設定をしています。
## 3. セキュアなバケットポリシーを設定（アカウント内のみアクセス許可）
🛠️ Using tool: use_aws (trusted)
⋮
● Running aws cli command:
Service name: s3api
Operation name: put-bucket-policy
Parameters:
- bucket: "test-my-secret-bucket-kyonosuke-202507021744"
- policy: "{\"Version\":\"2012-10-17\",\"Statement\":[{\"Sid\":\"AllowAccountAccess\",\"Effect\":\"Allow\",\"Principal\":{\"AWS\":\"arn:aws:iam::XXXX:root\"},\"Action\":[\"s3:GetObject\",\"s3:PutObject\",\"s3:DeleteObject\",\"s3:ListBucket\"],\"Resource\":[\"arn:aws:s3:::test-my-secret-bucket-kyonosuke-202507021744\",\"arn:aws:s3:::test-my-secret-bucket-kyonosuke-202507021744/*\"]}]}"
Profile name: XXXX
Region: ap-northeast-1
Label: Apply secure bucket policy for account-only access
⋮
● Completed in 1.115s
コンソールで確認したらちゃんと修正されています。素晴らしすぎる！！
ただ生成AIにリソースを操作させるのは社内ポリシー的によくない組織もあると思うので、ちゃんと承認を取ってから実施するようにしましょう。
インシデントレポート作成
業務上重大なインシデントであった場合は、ステークホルダーに周知を行う必要があります。
これもAmazon Qに作成してもらいましょう。
以下のプロンプトを与えて、Marp形式でPDF化します。
AWSの公式ドキュメントを参照し、今回の調査で得られた洞察をMarkdownファイルとしてまとめて報告資料にしてください。Marp形式であとからPDFに変換します。
まずはMCPによるawslabsaws_documentation_mcp_serverの実行から始まりました。
AWS公式ドキュメントを参照して、今回の調査結果をMarp形式のMarkdownファイルとして作成します。まず、関連するAWSドキュメントを検索して情報を収集します。
🛠️ Using tool: search_documentation from mcp server awslabsaws_documentation_mcp_server
⋮
● Running search_documentation with the param:
⋮ {
⋮ "arguments": {
⋮ "limit": 5,
⋮ "search_phrase": "GuardDuty S3 bucket policy public access detection"
⋮ },
⋮ "name": "search_documentation"
⋮ }
そして生成されたインシデントレポートがこちらです。
これまでの調査のサマリをし、顧客に説明できるようにまとめてくれました。
MCPサーバを利用してAWS公式ドキュメントを参照し、最新の情報に基づいた適切な対応方法を記載してくれています。
絵文字の多用や不自然な改行など気になるところはありますが、少し修正すれば十分使用できます。
マークダウンファイル全文は以下に添付しておきます。
GuardDuty_S3_Security_Investigation_Report.md
---
marp: true
theme: default
paginate: true
header: 'AWS GuardDuty S3セキュリティインシデント調査報告書'
footer: 'Confidential - Internal Use Only'
---
# AWS GuardDuty S3セキュリティインシデント調査報告書
**調査対象**: GuardDuty Finding ID `dccbe52fade6cbf534a90ef0604d3359`
**調査日**: 2025年7月3日
**対象アカウント**: XXXX
**対象リージョン**: ap-northeast-1 (東京)
---
## 📋 エグゼクティブサマリー
### インシデント概要
- **重要度**: HIGH (8.0/10)
- **タイプ**: `Policy:S3/BucketAnonymousAccessGranted`
- **対象リソース**: S3バケット `test-my-secret-bucket-kyonosuke-202507021744`
- **発生日時**: 2025年7月2日 18:02:16 JST
### 主要な発見事項
✅ **意図的な設定変更**: セキュリティ制御を段階的に迂回してパブリックアクセスを許可
⚠️ **極めて危険な状態**: 完全なパブリック読み書きアクセスが許可されている
🔍 **証跡確認済み**: CloudTrailログで全ての操作履歴を確認
---
## 🚨 現在のセキュリティ状況
### 危険な設定内容
**バケットポリシー**:
```json
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "AllowSpecificAccount",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::test-my-secret-bucket-kyonosuke-202507021744",
"arn:aws:s3:::test-my-secret-bucket-kyonosuke-202507021744/*"
]
}]
}
```
**パブリックアクセスブロック**: 全て無効化済み
---
## 📊 GuardDuty検知詳細
### Finding情報
- **Finding ID**: `dccbe52fade6cbf534a90ef0604d3359`
- **検知時刻**: 2025-07-02 09:02:16 UTC
- **実行者**: `AWSReservedSSO_AWSAdministratorAccess_XXXX`
- **プリンシパルID**: `AROA6D2FUA7DXAO7WIIFO:XXXX@gmail.com`
### アクセス元情報
- **IPアドレス**: `XXXX`
- **地理的位置**: XXXX
- **ISP**: J:COM Co., Ltd.
- **ASN**: 9824
---
## 🔍 CloudTrail調査結果
### 時系列での操作履歴
| 時刻 (JST) | API操作 | 結果 | 説明 |
|------------|---------|------|------|
| 17:45:12 | CreateBucket | ✅成功 | バケット作成 |
| 17:48:25 | PutBucketPolicy | ❌失敗 | 無効なプリンシパル |
| 17:48:53 | PutBucketPolicy | ✅成功 | アカウント限定ポリシー |
| 17:55:01 | PutBucketPolicy | ❌失敗 | パブリックアクセスブロック制限 |
| 17:55:58 | PutBucketPublicAccessBlock | ✅成功 | **セキュリティ制御無効化** |
| 17:56:36 | PutBucketPolicy | ✅成功 | **危険なパブリックポリシー設定** |
---
## 🔐 セキュリティ制御の迂回プロセス
### 段階的な設定変更
1. **初期状態**: セキュアな設定でバケット作成
2. **テスト段階**: 正常なアカウント限定ポリシーを設定
3. **制御確認**: パブリックポリシー設定を試行 → ブロックされる
4. **制御迂回**: パブリックアクセスブロックを意図的に無効化
5. **危険な設定**: 完全なパブリックアクセスを許可
### AWS公式ドキュメントによる推奨事項
> **重要**: パブリックアクセスは、アクセス制御リスト（ACL）、アクセスポイントポリシー、バケットポリシー、またはすべてを通じてバケットとオブジェクトに付与されます。すべてのAmazon S3アクセスポイント、バケット、およびオブジェクトのパブリックアクセスがブロックされるようにするため、アカウントのパブリックアクセスブロックの4つの設定をすべて有効にすることをお勧めします。
*出典: [Blocking public access to your Amazon S3 storage](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html)*
---
## ⚠️ リスク評価
### 現在のリスクレベル: **極めて高い**
#### データセキュリティリスク
- 🔓 **完全なパブリックアクセス**: 誰でもバケット内容の読み取り・書き込み・削除が可能
- 📊 **データ漏洩**: バケット内のすべてのオブジェクトが公開状態
- 🗑️ **データ改ざん・削除**: 悪意のあるアクターによるデータ破壊の可能性
#### 運用・コストリスク
- 💰 **予期しない課金**: 大量のデータ転送による高額請求
- 🚫 **サービス拒否**: 悪意のあるトラフィックによるサービス影響
- 📈 **レピュテーションリスク**: データ漏洩による企業信頼性への影響
---
## 🛠️ 緊急対応手順
### 即座に実行すべき対応
#### 1. バケットポリシーの削除
```bash
aws s3api delete-bucket-policy \
--bucket test-my-secret-bucket-kyonosuke-202507021744 \
--profile audit --region ap-northeast-1
```
#### 2. パブリックアクセスブロックの有効化
```bash
aws s3api put-public-access-block \
--bucket test-my-secret-bucket-kyonosuke-202507021744 \
--public-access-block-configuration \
"BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true" \
--profile audit --region ap-northeast-1
```
---
## 📋 推奨される追加対応
### 短期対応 (24時間以内)
1. **バケット内容の監査**
- 格納されているデータの機密性レベル確認
- 不正なオブジェクトの有無確認
2. **アクセスログの詳細分析**
- S3アクセスログの有効化と分析
- 不審なアクセスパターンの調査
3. **類似設定の確認**
- 他のS3バケットの設定確認
- アカウント全体のパブリックアクセス設定監査
### 中長期対応 (1週間以内)
1. **セキュリティ統制の強化**
- アカウントレベルでのパブリックアクセスブロック設定
- IAMポリシーによる権限制限
2. **監視体制の強化**
- GuardDutyアラートの自動対応設定
- CloudWatchアラームの設定
---
## 📚 AWS公式ガイダンス
### GuardDutyによる侵害されたS3バケットの修復手順
AWS公式ドキュメントでは、以下の手順を推奨しています：
1. **侵害された可能性のあるS3リソースの特定**
2. **疑わしい活動のソースとAPIコールの特定**
3. **コールソースがリソースへのアクセスを許可されているかの判断**
4. **S3バケットが意図的にパブリックであるかの判断**
*出典: [Remediating a potentially compromised S3 bucket](https://docs.aws.amazon.com/guardduty/latest/ug/compromised-s3.html)*
### S3セキュリティベストプラクティス
- パブリックアクセスブロック設定の有効化
- 最小権限の原則に基づくアクセス制御
- 定期的なアクセス権限の監査
- CloudTrailによる操作ログの記録と監視
---
## 🎯 結論と推奨事項
### 調査結論
- **意図的な設定変更**: テスト目的と推測されるが、極めて危険な状態
- **セキュリティ制御の迂回**: AWS標準のセキュリティ機能を意図的に無効化
- **即座の対応が必要**: 現在の設定は本番環境では絶対に許可されない
### 最優先推奨事項
1. **即座にパブリックアクセスを無効化**
2. **バケット内容の緊急監査実施**
3. **類似設定の全社的な確認**
4. **セキュリティ教育の実施**
### 長期的改善策
- アカウントレベルでのガバナンス強化
- 自動化されたセキュリティ監視の導入
- 定期的なセキュリティ監査の実施
---
## 📞 連絡先・参考資料
### 緊急連絡先
- **セキュリティチーム**: [連絡先情報]
- **AWS サポート**: [サポートケース番号]
### 参考資料
- [AWS S3 Security Best Practices](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html)
- [AWS GuardDuty User Guide](https://docs.aws.amazon.com/guardduty/latest/ug/)
- [AWS CloudTrail User Guide](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)
---
**報告書作成者**: Amazon Q
**作成日時**: 2025年7月3日
**分類**: 機密 - 社内使用のみ
まとめ
今回は従来のやり方とAmazon Q Developer CLI を使った方法の2パターンでGuardDutyのインシデントを調査してみました。どちらが効率的で人の手がかからないかは明らかでしょう。
ログの調査はさることながら、AWSリソースの修正対応やインシデントレポートの作成までも自動化でき、セキュリティ運用に革命が起きているといえます。
今後もAmazon Qを活用したセキュリティ運用を考察します。
本記事がセキュリティ運用に困っているあなたの力になれば幸いです。