「登録完了メールが届かない」
それは、SESアカウントが迷惑メールの踏み台になって凍結されていたという事件の始まりだった。
担当不在ななか、元フロントエンドの自分がゼロから調べて解決した全記録です
自分は1ヶ月前までWordPressを触っていたフロントエンジニア。
SESもAthenaもSQLもCloudTrailも、何一つ知らない状態からスタートした。
👣 そもそもやろうと思ったきっかけ
「やらなきゃ」と思ったわけじゃない。
「え、これ何が起きてるの？」っていうただの好奇心だった。
最初はSlackを眺めてるだけだったけど、
気がついたらAthenaでSQL書いてCloudTrailの構造を読んでいた。
気づけば、オフショアチームとの調整、外部CTOへの報告、AWS構成の見直しまで自分が主導していた。
🔍 知識ゼロから始めた調査の流れ
やったことは以下のような流れ。
1. SESが凍結された理由を特定
- CloudWatch → GuardDutyの設定を追加
- AIに相談しつつ、Athenaでログを探索
- SESのSMTP送信はCloudTrailに記録されない罠に気づく
- IPアドレス・UserAgentでアクセス元を特定
2. 不審なアクセスを突き止める
- GitHub ActionsやAzure VMからの正規アクセスを確認
- オフショアチームが.envにキーを保存 → S3に手動アップロード
- GCP（外部）からの不正アクセスログがGuardDutyで検出
3. 対応・再設計
- SMTP用サービスアカウントのキーを無効化
- .env → Secrets Managerへの移行プランを提案
- CloudTrail + Athenaでログ基盤を整備
- S3バケット全体にアクセスログを有効化
- SES異常時にSlack通知が来るよう設定
📜 時系列でのインシデント概要
05/22 メール送信切替のためAPIキー共有（ZIP暗号化）
06/03 オフショアがSMTPキー作成 → .envファイル更新
06/05 本番反映
06/10 SESで迷惑メール検知
06/12 外部GCPからSMTP送信の痕跡（GuardDuty）
06/23 SES凍結（25,000通送信／バウンス率 0.06%）
06/30 サポートからの報告で発覚
07/07 SMTPキー無効化
🧠 工夫したこと
Slackでの共有方法：
- 「仮説 → 調査 → 結果 → 次のアクション」の形で毎回共有
- 誰でも追えるよう、AWSの画面キャプチャやAthenaのクエリも貼る
- 調査ログを流さず、CTOや上司がレビューしやすい構成にした
🤯 実際どうだった？
めちゃくちゃ楽しかった。
「また漏洩しないかな」と思うくらい（笑）
・・・いや、実際は二度と起きてほしくないんですが、それくらい学びが大きくて
調べて分かるたびに、勝手にテンション上がってた。
💡 やってみて分かったこと
- 「知らないからできない」は思い込みだった
- AI（ChatGPT）とログを見れば、ほとんどのことは分かる
- やると決めたというより、好奇心で勝手に手が動いてた
📦 使った技術・ツール一覧
- AWS SES / IAM / CloudTrail / GuardDuty / Athena / S3
- AWS Secrets Manager
- ChatGPT（クエリ生成・ログ構造解析・ヘッダ解析）
- Slackでの調整・交渉
- Markdownドキュメント化と構成整理
🧯 再発防止策（実施済）
- ✅ CloudTrail + Athenaでログ解析環境整備
- ✅ GuardDuty → Slack通知連携
- ✅ S3アクセスログをバケットで有効化
- ✅ Secrets Managerへの移行プラン提出
- ✅ ENVファイルDL時 → CloudTrail → Lambda → slack通知
🙌 まとめ
これは優秀なエンジニアの武勇伝ではない。
ただ、現場で誰もやらなかったから自分がやった記録です。
「わからないまま止まらなかった」
それだけが、自分にあった唯一のスキルだった。
🧵 最後に
この件を通して、AWSの設計・運用を引き受けることになりました。
同じように「知識ゼロからでも調べながらなんとかなるかも」と思ってもらえたら嬉しいです。