はじめに
みなさんは妄想はお好きですか？私は好きです。
今日は一人で脳内 AWS Game Day をやっていました。
AWS Game Day Japan 2015 は来るのか？
来たら一体どんなチームが勝つのか？
そんなことを妄想しながらお送りしたいと思います。
Game Day とは？
チームが敵味方に分かれ、一方は知恵を絞って AWS 上に構築されたシステムを破壊し、もう一方は全力でそれを修復するというもの。AWS の PowerUser アカウントが乗っ取られた体で、各チームでアカウントを交換し全力で相手方のシステムを破壊します。破壊された後は、いち早く元の構成に戻します。
ルールは参加したことないのでよくわかってませんが、過去の開催状況を見る限り以下のようになります。
（過去参加した方、詳しいルールをご存知の方、補足していただけるとありがたいです。）
-
アカウント自体への攻撃禁止
- PowerUser アカウントの権限変更やパスワードの変更、アカウントのクローズ処理等は行わない
-
インスタンスへの ssh 禁止
- これはやらないというよりキーペアの秘密鍵がないので出来ない。ただしAMI化して新しいインスタンスにし直せば、中にログインしてインスタンス内の設定ファイルというを壊せるかも。（過去に、その手を使った方もいらっしゃった模様。）
攻撃手法の分類
自分で思いついた限り、大きく分類して以下のような攻撃手法がありそうです。
これで各パターン×サービスの数x機能の数の組み合わせぐらいはあるのではないかと思われます。
- AWS リソース削除系
- AWS リソース置き換え、その発見を遅らせるダミーリソース追加系
- サービス設定変更系
- ファイル（設定ファイルなど）置き換え系
一番簡単で誰でも出来るのは 1 のリソース削除です。根こそぎ削除してもいいですが、恐らく防御側はそこから簡単に復旧してしまうでしょう。
2は例えばインスタンスを違う AMI であげておくなど。3 は VPC のルーティング設定をいじっておくなどの例が思いつきました。
4はインスタンスの中の設定ファイルや鍵になるスクリプトを入れ替えたり、壊したりになります。
下に行くほど巧妙な感じになり、発見も難しくなるのではないでしょうか。
そこで、攻撃手法ごとに有効そうな事前対策を考えてみました。
有効そうな事前対策
- CloudTrail の有効化
- かつ、他のアカウントの Bucket にログを保存するとか？
- AWS リソース削除系への対策
- 基本 AMI などは共有機能で他のアカウントなどに持たせてバックアップとしておく
- 構成は CloudFormation で出来る部分を確認しておいて、出来る限り自動的に戻す
- S3 上のファイルなら Versioning ON にして二回アップ、最新世代を削除しておき、何もファイルがないように見せかける（某イケメンがいけない画像を隠すのに使っている方法を応用）
- AWS リソース置き換え、ダミー追加系
- CloudTrail ログで何をされたか確認
- 場合によっては丸ごとCloudFormationで作り直したほうが早いかも？
- サービス設定変更系
- CloudTrail ログで何をされたか確認
- 場合によっては丸ごとCloudFormationで作り直したほうが早いかも？
- ファイル置き換え系
- CloudTrailにログが残らないのでこのあたりは変更点を探して直そうとすると苦労する
- 見つけだすことよりも復旧に注力して、正しいファイルを含むAMIなどを使ってインスタンスごと直したほうが早いかもしれません
- 事前に変えられると致命的なスクリプトや設定ファイルなどの場所をデフォルトから変えて見つかりにくくする、とかもありでしょうか？
まとめ
実際に Game Day 参加したことないので妄想レベルですが、結局一人でやっていると自分の手を越える神の一手を考えだすのは難しそうです。あと何かいろんなものを勘違いしているかもしれません。
免責
こちらは個人の意見で、所属する企業や団体は関係ありません。
いけない画像を S3 Versioning で隠している某イケメンもフィクションです。