Help us understand the problem. What is going on with this article?

検証環境のURLが入ったメールを本番環境のユーザーに送ってしまった話

この記事は「本番環境でやらかしちゃった人 Advent Calendar 2020」24日目の記事です。
遠い昔、はるか彼方の銀河系での話です。

TL;DR

IAMの権限はしっかりやりましょう。検証環境と本番環境でアカウントを分けるとより安心できます。

何をやらかしたのか

やらかし前の状態

マッチングサービスの開発をしています。そのサービスにはサービス内でメッセージが届くとその旨をEメールで通知する機能があります。
システム的にはサービスを動かしているWebアプリケーションからSQSのメール用のキュー(以後Maill Queue)にメッセージを送信し、メール送信用のWorkerがMaill Queueからメッセージを取得、差出人やURLなどの情報を埋めてEメールを送信します。差出人やURLは本番環境、検証環境でそれぞれ別の値が入ります。

qita.001.png

また検証環境と本番環境は同一のAWSアカウント内にあり、WebアプリケーションとWorkerが動いているEC2インスタンスは検証環境と本番環境共に東京リージョン(ap-northeast-1)。その他のリソースは本番環境は東京リージョン、検証環境はオレゴン(us-west-2)に作成されていました。Maill Queueのリソース名は検証環境、本番環境共に同じでした。

qita.002.png

やらかしたこと

ある日EC2で動いていたWorkerをFargateへ移行することになりました。WebアプリケーションにはどのリージョンのAWSリソースを参照するか設定する場所があるのですが、移行の際にその設定が漏れてしまいました。
設定が漏れてしまった結果、検証環境のWorkerが本番の東京リージョンのMaill Queueからメッセージを取得してしまいました。

qita.003.png

やらかした結果何が起きたのか

検証環境のWorkerが本番環境のMaill Queueからメッセージを取得したことにより、検証環境のURLを埋め込んだ状態で本番環境のユーザーにメールを送ってしまいました。
正しいURLではありませんし、検証環境はそもそも接続できるIPアドレスを絞っているので、ユーザーはメールで送られてきたURLを開くことができません。

二度と惨劇を起こさないためにどうしたのか

まずEC2インスタンスのIAMロールの権限の見直しを行いました。
検証環境と本番環境のEC2インスタンスのIAMロールにはSQSFullAccess がアタッチされており、全てのリージョンのSQSにアクセスできる状態だったので、アクセスを制限しました。

次に検証環境と本番環境でAWSアカウントの分割を行い、権限周りでミスがあっても同じことが起こりにくい状態にしました。

さいごに

いろいろと助けてくださった方々、本当にありがとうございました。。。

明日の 本番環境でやらかしちゃった人 Advent Calendar 2020@tsumita7 さんの「S3「 お゛め゛ぇ゛に゛権゛限゛ね゛ぇ゛がら゛!」」です。

takoikatakotako
インフラをやったりアプリを作ったりしています。
http://swiswiswift.com/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away