AWSの怖い話を教訓にしてAWSのコンソールを守る7つの方法

最近、AWSを頻繁に触る様になって、ブログに技術系の記事を残す様になりました。
情報の露出が多くなるほど、自分が情報流出していないかという被害妄想にかられます。

それは、心配から、AWSの恐怖体験を調べてしまうからかもしれません。
先駆者には、タイトルでわかる様に怖い体験をされた人がいらっしゃいます。

qiita.com

AWS 怖い」等で検索すると色々な情報が得られますが、主な要因は請求額が想定を上回る事例です。
なぜ上回るかというと、次の様な事が言えます。

  • リソースの消し忘れで、無駄な稼働費用がかかった。
  • 性能過多の設定をしてしまい、ランニングコストが大きくなってしまった。
  • 不正アクセスにより、リソースが勝手に作られてその費用が請求された。  

1番目と2番目はドキュメントの料金表を見たり、心がけ次第でどうにかなる問題だと思います。
今回は、3番目の対策について私の経験を踏まえてお伝えします。

この記事で得られる知識

  • AWSでアカウントを守る方法が身につく

イントロダクション

コンソールを守る方法として次の7つを取り上げます。

  1. 不要なリソースは必ず消す
  2. rootアカウントで運用しない
  3. 作業ユーザーのポリシーは必要最低限の設定にする
  4. rootアカウントのセキュリティはできる限り強固にする
  5. 請求に関するアラームを設定する
  6. 公開する情報は念入りにチェックして扱う
  7. ユーザーのアクセスを監視する

コンソールを守る方法

対策は会社であろうと、個人であろうと何よりも優先してやるべきことです。
作業時間もあまり必要ないので、なるべく早く対応してしまうことをお勧めします。

1. 不要なリソースは必ず消す

AWSは良くも悪くも従量課金制なので、リソースを作れば作るほどお金は加算されて行きます。
もし、リソースが整理されていないと、いざという時に削除できなかったり、正体不明のリソースがあっても気づけません。
現在のリソースを把握し、不要なものは定期的に消す様にしてください。

また、EC2インスタンスのステータスは「停止≠削除」です。
停止させても、インスタンスが残るので費用が発生する可能性があります。
起動する予定が無いのであれば明示的に削除すると安心です。
docs.aws.amazon.com

完了したプロジェクトのリソースについて

私個人としては、プロジェクトが終了した段階で削除しても良いと考えます。
それは、次の様にしておけば復帰に手間がかからないからです。

  • ソースはgitで管理
  • サーバー構成はCloudFormationで管理。
  • ミドルウェアの構成はansibleで管理
  • wikiに起動方法を記載。

2. rootアカウントで運用しない

rootアカウントとはAWSを契約した時に作成したユーザーの事です。
このユーザーは利用できるサービスに制限が無いため、悪用されてしまうと取り返しがつかない事になります。
そのため、担当者毎(最低でも担当作業毎)にIAMでユーザーを切り出すのが鉄則です。

docs.aws.amazon.com

3. ユーザーのポリシーは必要最低限の設定にする

ユーザーを設定すれば問題ないと言うわけではありません。
例えば、S3にアップロードするパーミッションする場合、下記の様にしていないでしょうか?

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject"
            ],
            "Resource": "*"
        }
    ]
}

この状態では、全てのバケットに対してアップロードできてしまう事になるので、運用のリスクが生じます。 IAMにはパーミッションと呼ばれる利用できる権限を指定する事が可能なので、次の事をする事をお勧めします。

上記設定を一つ一つやると手間ですし、一括管理が面倒です。
その為、

  • ユーザーをひとまとめに管理できる「グループ」
  • サービスをひとまとまりに管理できる「ロール」

といった機能で効率よく管理していくと良いです。

4. rootアカウントのセキュリティはできる限り強固にする

物理的にrootアカウントを使わないとはいえ、IDとPasswordで管理する以上突破される可能性はあります。
rootアカウントのセキュリティは強固にする必要があります。
方法については、IAMを表示すると「セキュリティステータス」と言う情報が見れます。

rootアカウントでログインして、IAMを表示して見てください。
f:id:nakahashi_h:20180103222222p:plain

ここが全てチェックが着いた状態だと、より安全な環境ができます。
ステータスをそれぞれ押すと設定方法が表示されますので、その内容に沿って実施してください。

多要素認証 (MFA) については、スマートフォンに1タイムパスワードアプリを入れて連携させると言う方法もできますので、より個人を特定しないとできない認証にする事ができます。

docs.aws.amazon.com

5. 請求に関するアラームを設定する

もし、不正アクセスしてリソースを追加された場合、確実に請求額が変わります。  

常に請求金額を見れば良いのですが、現実的ではありません。
そのため、アラームを設定して状況を速報で送る様に設定します。  

予定金額の監視

期間と予定金額を設定し、その金額を超えたらアラームを出す様に設定します。
設定方法は下記を参照してください。

docs.aws.amazon.com

無料枠の監視

AWSのサービスによっては無料枠を設定されているものがあります。
1ヶ月の無料枠を超えそうな場合(超えた場合)、メールを送信する様に設定します。
設定方法は下記を参照してください。

docs.aws.amazon.com

6. 公開する情報は念入りにチェックして扱う

いくら用心していても、不注意でソースやwikiに接続情報を記載して公開してしまう可能性はあります。 実際にネットで見た失敗事例の中には、githubwikiに接続情報を載せてしまったばかりに、不正アクセスされて請求金額が跳ね上がった人の話も聞きました。

これの対策方法としては、次の様な方法も良いかもしれません。

  • 開発時に環境情報を別ファイルに分けたり、環境変数に追加してしまう
  • セルフマージでもいいので、プルリクエスト等で二回チェック

ソースは公開しないに越した事はないのですが、もし公開する場合は、個人が特定される情報が無いか?接続に必要なIDが入った状態のソース画像が添付されていないかは今一度確認してください。

7. ユーザーのアクセスを監視する

上記で対策してもアクセスされるときはアクセスされます。
アカウントの行動をログを残す為に、AWSCloudtrailがあります。

AWS CloudTrail ドキュメント


いかがでしたでしょうか?
他の方が公開されている事と重なる部分もありますので、改めて見直す機会にしていただけると幸いです。

ネットの意見には、「AWSは個人には不要」と言う意見もあります。
一度失敗した身として、この意見には賛成です。
料金の面もそうですが、何より、個人で公開する程度のコンテンツにスケーリングやAWSのサービスは必須ではないからです。

しかし、開発と運用の効率を上げるには、AWSの各種サービスはとても魅力的です。
個人でも出来る限り対策して、安全な環境下で運用のノウハウを積めるにしたいですね。