CTO室SREの侘美です。最近はM5Stackを嗜んでおります。
ここ半年ほど、MedPeerグループ全体のAWSのセキュリティ改善に力を入れてきました。 その中で、AWS Well-Architectedのセキュリティのベストプラクティスにも記載があるゲームデーを実施したところ、とても学びが多かったので本記事にまとめました。
ゲームデーとは?
Well-Architectedには以下のように記載されています。
ゲームデーを実施する
ゲームデーを実施する: さまざまな脅威について、インシデント対応イベントのシミュレーション (ゲームデー) を実施します。このゲームデーには、主要なスタッフや管理者を参加させてください。
教訓から学ぶ: ゲームデーの実行から得られた教訓は、プロセスを改善するためのフィードバックに含まれている必要があります。
出典: https://wa.aws.amazon.com/wat.question.SEC_10.ja.html
実施したゲームデーの概要
今回行ったゲームデーの概要は以下の通りです。
- 擬似的に社内のいずれかのサービスでAWS上のインフラに関するセキュリティインシデントを発生させる。
- どのサービスで発生するかは発生するまで不明とする。
- セキュリティインシデント対応計画に則りSREチームで対応する。
- ステージング環境を本番環境とみなしてゲームデーを行う。
今回は初回ということもあり、ゲームデーへの参加はSREのみとし、 私がインシデントを擬似的に発生させ、他のSREメンバー5名で対応にあたるシナリオとしました。
ゲームデーのシナリオ
より実際のセキュリティインシデントを再現するため、次のようなシナリオを事前に作成しました。 SREチームのメンバーへはゲームデー終了後に公開しました。
シナリオ全体の図
インシデント
IAMアクセスキーの流出。
ある開発者がバグ調査のためにIAMユーザーを作成し、IAM認証情報を作成した。
Slack上の社外のゲストユーザーが参加しているチャンネルでAWSのアクセスキーIDとシークレットアクセスキーを投稿してしまった。*1
認証情報には、S3やECRやSystem Managerパラメータストアの権限が含まれていた。
インシデントの検知
CTOのTwitterのDMに以下のメッセージがあった体とする。*2
XXX社のYYYです。 御社の<サービス名>というサイトのユーザーのリストと思われる情報がWebに公開されていました。 現在は公開されていないようです。 名前とメールアドレスが載っているので、個人情報流出的に大丈夫ですか?? サイト: https://example.com/path/to/user-list 掲載されている情報(抜粋) 1,テスト太郎,taro.test@example.com 2,テスト次郎,jiro.test@example.com
掲載されている情報は、流出したS3上のCSVファイルの一部となっている。
攻撃者が取得した情報
攻撃者はSlackに投稿されたIAM認証情報を利用して、以下の操作を行った。 (実際に事前に認証情報を利用してこの操作を行う)
- S3バケットからユーザー情報が記載されたCSVファイルをダウンロード
- ECRへログインし、サービスで利用しているECS用のRuby on Railsアプリケーションのイメージを取得
本シナリオを利用したゲームデーで確認したい点
- 初動でIAM認証情報を無効化できるか
- 以下を調査し適切に報告へ含めることができるか
- 流出したIAM認証情報
- 流出した情報
- ECR上のイメージ流出による影響
- 流出した経路
- セキュリティインシデント対応計画の内容は適切か
ゲームデー当日
当日は2時間と時間を区切ってインシデント対応にあたることにしました。
私はシナリオ作成者なので調査は見ているだけで参加しなかったのですが、インシデント検知→作業を分担して各種ログを調査→IAM認証情報特定→他の操作調査とスムーズに対応が進んでいました。
具体的な調査としては、CloudTrail、ALB、ECS、S3アクセスログなどを調査し、流出したIAM認証情報の特定やその認証情報で実行された操作等を特定していきました。
必要なログが取得されて無いといったことは発生しませんでした。
特に初動で流出したデータ内容から、RDS、S3バケット、管理画面などが流出経路である可能性があると判断し、分担して対応にあたった場面は想定以上にスムーズに実行できていたと思います。
最終的な報告では、流出経路を含めほとんど特定でき、その上で流出した情報からサービスの緊急停止を検討すべきか等の議論も行われており、十分対応できた結果となりました。
学び
ゲームデー終了後にSREチームで振り返りを行ったところ、多くの学びや改善点が見つかりました。
すべては記載しきれないので、一部を掲載させていただきます。
- AWSやGoogle等が説いているインシデント対応のゲームデーの重要さについて、真の意味で理解できた。
- S3アクセスログ、CloudTrail、Athenaなどを利用して調査を行ったが、習熟度が人それぞれだったため、得意不得意が出た。
- ログを1箇所に集約し、Athenaを事前に設定しておくことで解消できそう。
- CloudTrailでのS3オブジェクトレベルのアクセスログ記録が有効になっていないため、S3側で設定しているアクセスログも調査する必要があった。
- コストとの兼ね合いもあるが、一箇所で検索できると調査がスムーズになる。
- IAMユーザーの総数が少ないと流出したIAM認証情報の特定は速い。
- IAMユーザーの棚卸しはやはり大事。
- (一部のエンジニアにIAMのフル権限を与えているので)IAMユーザー作成検知の仕組みが欲しい。
- ゲームデー後にCloudTrailのログを利用して通知する仕組みを実装した。
- 初動の分担等、陣頭指揮は重要。
- ECRログイン後のアクセスキーが変化するという仕様に気づかず、ECRからイメージをダウンロードしたログを特定できなかった。
- Ruby on Railsで扱う秘匿情報の管理方法について見直す必要がある。
- 報告がSlackで散発的に行われたので、最後に報告をまとめる際に苦労した。
- テンプレートが用意されており、共同編集可能な環境にまとめていくのが良さそう。
- 次は各サービスのRailsエンジニア等と協力して調査する部分もシミュレートすべき。
AWSのソリューションアーキテクトの方からのアドバイス
AWSのソリューションアーキテクトの方に今回実施したゲームデーの内容を共有したところ、以下のようなコメントをいただきました。
(SAさんに気軽に相談できる環境は本当にありがたい!)
- 目的・手段が噛み合っているシナリオで良い
- CloudTrailから影響を絞っていく対応も良かった
- セキュリティ系インシデントであれば、エンジニア系職種以外の他職種・他チームも巻き込んでシミュレートすると、より実際の対応に近づく
- セキュリティ系以外には可用性の障害を発生させるシナリオもよくある
次回
上記を踏まえて次回は以下の点を事前に準備・検討した上で再度ゲームデーを夏頃に開催する予定です。
- 報告書のテンプレートの準備
- ログ検索の整備
- SRE以外のエンジニア、非エンジニア職も巻き込んむ
まとめ
セキュリティインシデントのゲームデーを実施することで、実際にやってみないと見えてこない課題などがいくつも見つかりました。
サービスを運用している会社では是非実施することをおすすめします!
メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております!
■募集ポジションはこちら
https://medpeer.co.jp/recruit/entry/
■開発環境はこちら
https://medpeer.co.jp/recruit/workplace/development.html