最近、AWSを頻繁に触る様になって、ブログに技術系の記事を残す様になりました。
情報の露出が多くなるほど、自分が情報流出していないかという被害妄想にかられます。
それは、心配から、AWSの恐怖体験を調べてしまうからかもしれません。
先駆者には、タイトルでわかる様に怖い体験をされた人がいらっしゃいます。
「AWS 怖い」等で検索すると色々な情報が得られますが、主な要因は請求額が想定を上回る事例です。
なぜ上回るかというと、次の様な事が言えます。
1番目と2番目はドキュメントの料金表を見たり、心がけ次第でどうにかなる問題だと思います。
今回は、3番目の対策について私の経験を踏まえてお伝えします。
この記事で得られる知識
- AWSでアカウントを守る方法が身につく
イントロダクション
コンソールを守る方法として次の7つを取り上げます。
- 不要なリソースは必ず消す
- rootアカウントで運用しない
- 作業ユーザーのポリシーは必要最低限の設定にする
- rootアカウントのセキュリティはできる限り強固にする
- 請求に関するアラームを設定する
- 公開する情報は念入りにチェックして扱う
- ユーザーのアクセスを監視する
コンソールを守る方法
対策は会社であろうと、個人であろうと何よりも優先してやるべきことです。
作業時間もあまり必要ないので、なるべく早く対応してしまうことをお勧めします。
1. 不要なリソースは必ず消す
AWSは良くも悪くも従量課金制なので、リソースを作れば作るほどお金は加算されて行きます。
もし、リソースが整理されていないと、いざという時に削除できなかったり、正体不明のリソースがあっても気づけません。
現在のリソースを把握し、不要なものは定期的に消す様にしてください。
また、EC2インスタンスのステータスは「停止≠削除」です。
停止させても、インスタンスが残るので費用が発生する可能性があります。
起動する予定が無いのであれば明示的に削除すると安心です。
docs.aws.amazon.com
完了したプロジェクトのリソースについて
私個人としては、プロジェクトが終了した段階で削除しても良いと考えます。
それは、次の様にしておけば復帰に手間がかからないからです。
2. rootアカウントで運用しない
rootアカウントとはAWSを契約した時に作成したユーザーの事です。
このユーザーは利用できるサービスに制限が無いため、悪用されてしまうと取り返しがつかない事になります。
そのため、担当者毎（最低でも担当作業毎）にIAMでユーザーを切り出すのが鉄則です。
3. ユーザーのポリシーは必要最低限の設定にする
ユーザーを設定すれば問題ないと言うわけではありません。
例えば、S3にアップロードするパーミッションする場合、下記の様にしていないでしょうか？
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": "*" } ] }
この状態では、全てのバケットに対してアップロードできてしまう事になるので、運用のリスクが生じます。 IAMにはパーミッションと呼ばれる利用できる権限を指定する事が可能なので、次の事をする事をお勧めします。
上記設定を一つ一つやると手間ですし、一括管理が面倒です。
その為、
- ユーザーをひとまとめに管理できる「グループ」
- サービスをひとまとまりに管理できる「ロール」
といった機能で効率よく管理していくと良いです。
4. rootアカウントのセキュリティはできる限り強固にする
物理的にrootアカウントを使わないとはいえ、IDとPasswordで管理する以上突破される可能性はあります。
rootアカウントのセキュリティは強固にする必要があります。
方法については、IAMを表示すると「セキュリティステータス」と言う情報が見れます。
rootアカウントでログインして、IAMを表示して見てください。
ここが全てチェックが着いた状態だと、より安全な環境ができます。
ステータスをそれぞれ押すと設定方法が表示されますので、その内容に沿って実施してください。
多要素認証 (MFA) については、スマートフォンに1タイムパスワードアプリを入れて連携させると言う方法もできますので、より個人を特定しないとできない認証にする事ができます。
5. 請求に関するアラームを設定する
もし、不正アクセスしてリソースを追加された場合、確実に請求額が変わります。
常に請求金額を見れば良いのですが、現実的ではありません。
そのため、アラームを設定して状況を速報で送る様に設定します。
予定金額の監視
期間と予定金額を設定し、その金額を超えたらアラームを出す様に設定します。
設定方法は下記を参照してください。
無料枠の監視
AWSのサービスによっては無料枠を設定されているものがあります。
1ヶ月の無料枠を超えそうな場合（超えた場合）、メールを送信する様に設定します。
設定方法は下記を参照してください。
6. 公開する情報は念入りにチェックして扱う
いくら用心していても、不注意でソースやwikiに接続情報を記載して公開してしまう可能性はあります。 実際にネットで見た失敗事例の中には、githubのwikiに接続情報を載せてしまったばかりに、不正アクセスされて請求金額が跳ね上がった人の話も聞きました。
これの対策方法としては、次の様な方法も良いかもしれません。
ソースは公開しないに越した事はないのですが、もし公開する場合は、個人が特定される情報が無いか？接続に必要なIDが入った状態のソースや画像が添付されていないかは今一度確認してください。
7. ユーザーのアクセスを監視する
上記で対策してもアクセスされるときはアクセスされます。
アカウントの行動をログを残す為に、AWSCloudtrailがあります。
いかがでしたでしょうか？
他の方が公開されている事と重なる部分もありますので、改めて見直す機会にしていただけると幸いです。
ネットの意見には、「AWSは個人には不要」と言う意見もあります。
一度失敗した身として、この意見には賛成です。
料金の面もそうですが、何より、個人で公開する程度のコンテンツにスケーリングやAWSのサービスは必須ではないからです。
しかし、開発と運用の効率を上げるには、AWSの各種サービスはとても魅力的です。
個人でも出来る限り対策して、安全な環境下で運用のノウハウを積めるにしたいですね。
