この記事は「本番環境でやらかしちゃった人 Advent Calendar 2020」24日目の記事です。
遠い昔、はるか彼方の銀河系での話です。
TL;DR
IAMの権限はしっかりやりましょう。検証環境と本番環境でアカウントを分けるとより安心できます。
何をやらかしたのか
やらかし前の状態
マッチングサービスの開発をしています。そのサービスにはサービス内でメッセージが届くとその旨をEメールで通知する機能があります。
システム的にはサービスを動かしているWebアプリケーションからSQSのメール用のキュー（以後Maill Queue）にメッセージを送信し、メール送信用のWorkerがMaill Queueからメッセージを取得、差出人やURLなどの情報を埋めてEメールを送信します。差出人やURLは本番環境、検証環境でそれぞれ別の値が入ります。
また検証環境と本番環境は同一のAWSアカウント内にあり、WebアプリケーションとWorkerが動いているEC2インスタンスは検証環境と本番環境共に東京リージョン（ap-northeast-1）。その他のリソースは本番環境は東京リージョン、検証環境はオレゴン(us-west-2)に作成されていました。Maill Queueのリソース名は検証環境、本番環境共に同じでした。
やらかしたこと
ある日EC2で動いていたWorkerをFargateへ移行することになりました。WebアプリケーションにはどのリージョンのAWSリソースを参照するか設定する場所があるのですが、移行の際にその設定が漏れてしまいました。
設定が漏れてしまった結果、検証環境のWorkerが本番の東京リージョンのMaill Queueからメッセージを取得してしまいました。
やらかした結果何が起きたのか
検証環境のWorkerが本番環境のMaill Queueからメッセージを取得したことにより、検証環境のURLを埋め込んだ状態で本番環境のユーザーにメールを送ってしまいました。
正しいURLではありませんし、検証環境はそもそも接続できるIPアドレスを絞っているので、ユーザーはメールで送られてきたURLを開くことができません。
二度と惨劇を起こさないためにどうしたのか
まずEC2インスタンスのIAMロールの権限の見直しを行いました。
検証環境と本番環境のEC2インスタンスのIAMロールにはSQSFullAccess がアタッチされており、全てのリージョンのSQSにアクセスできる状態だったので、アクセスを制限しました。
次に検証環境と本番環境でAWSアカウントの分割を行い、権限周りでミスがあっても同じことが起こりにくい状態にしました。
さいごに
いろいろと助けてくださった方々、本当にありがとうございました。。。
明日の 本番環境でやらかしちゃった人 Advent Calendar 2020 は @tsumita7 さんの「S3「 お゛め゛ぇ゛に゛権゛限゛ね゛ぇ゛がら゛！」」です。