はじめに
AWS を触り始めたばかりの頃にやらかした初歩的なミスをまとめたアドベントカレンダー、題して「AWS初歩ミス図鑑」の 2 日目です。
今回は EC2 のセキュリティグループでわけもわからず0.0.0.0/0を開けていた話を書いていきます。
やってみたこと
前日の記事でも書かせていただいた通り、当時の私は AWS というものを理解していなかったので、なじむための練習として、検証用のアカウント（所属していた課のだれもがアクセスでき、リソースを作成できる）で以下の構成を作ろうとしていました。
- ALB のエンドポイントで HTTP アクセスを受ける
- EC2インスタンスで簡単なWebアプリを動かす
- ALB のエンドポイントへアクセスすると EC2 で動いているアプリが表示される！
結果
ALB、EC2 のセキュリティグループでわけもわからず0.0.0.0/0を許可してしまい、アカウント全体に設定されていた GuardDuty で検知 → そのまま所属している課専用のSlackチャンネルでインシデントとして全体に周知されてしまい、同じ課の皆さんを一瞬緊張させてしまいました。
何を考えていたのか
本当に初心者すぎてお話にならないですが、そもそも IPアドレス というものを深く理解していませんでした……。
当然そんな理解では「検証アカウントで、しかも限られた人間しかアクセスしないんだから、社内IPからのみアクセスできるようにしよう」などという考えが浮かばず、結果「参考にした本番環境の ALB セキュリティグループは0.0.0.0/0が許可されている……じゃあ検証環境の ALB や EC2 も同じでいいんだろうな！」という軽い気持ちで設定をしました。愚かでした。
まとめ
セキュリティグループの設定ミスは、検証環境であっても実際のセキュリティリスクにつながります。特に共有アカウントでは、他のメンバーにも迷惑をかけてしまいます。（私がやってしまったように…。）
この件に関して、気を付けなくてはいけないことは以下です。
- セキュリティグループは常に最小権限で設定
-
0.0.0.0/0を使う前に、本当に必要か確認 - 検証環境でも本番同等のセキュリティ意識
- 共有アカウントで作業をする場合、設定前にそのアカウントを使用しているメンバーに確認をとる。
初心者の頃は「仕組みはともかく動けばいいんだ」と考えがちですが、セキュリティは後から修正するより最初から適切に設定する方が楽、信用もされるということを痛感しました。
GuardDuty のアラートでチーム全体を慌てさせ、業務の手を止めさせてしまい、本当に申し訳なかったと反省しています。