Y_Yamashitaのブログ

勉強したことのアウトプット・メモ中心。たまに日記とか。

「AKIBA.AWS ONLINE #04 - こんなときどうする⁉︎ トラブル・インシデント対応 編-」参加メモ

AWS

はじめに

本日、以下のオンライン勉強会に参加した。

dev.classmethod.jp

各セッションで個人的に印象に残った内容・勉強になった内容等を抜粋して、メモとして記載する。

当日のセッション内容

AWSのセキュリティインシデント通知

なぜAWSから通知がくるのか？

  • 責任共有モデルでユーザーの責任範囲となっている箇所のインシデントについて、なぜAWSから通知がくるのか？
    • AWSリソースが外部に攻撃をしかけている、アクセスキーが流出しているなど、AWSが看過出来ない状況であるため。

Your AWS Access Key is Exposed

  • アクセスキーが外部に公開されていることを検出したという通知
  • EC2がマイニングに使われ、数千万円レベルの利用費が発生する場合も
  • 事業継続に影響を与えるレベルの損害が発生することもある

  • やること
    • アクセスキーの削除、無効を最優先（無効で終わらせずに、最終的には必ず削除する）
    • AWSへ対応着手したことを連絡する（連絡しないとアカウント停止される恐れも）
    • アクセスキーに付与されていた権限を確認
    • 全IAMユーザーとrootユーザーのパスワード・アクセスキーをローテーション
    • CloudTrailで対象のキーのアクティビティを確認（全リージョンで確認する）
    • 不正なリソースの削除（IAMユーザーが作られているケースも）
    • 請求のチェック（反映には１日かかる場合も）
    • AWSへの対応完了連絡（英語）

  • 知っておくこと
    • AWSに漏洩した理由を聞いてもわからない。AWSの責任範囲ではない。
    • たまにAWSが権限をはく奪するポリシーを適用し被害を止めることがあるが、必ずではない。過信しない。
    • rootユーザーのアクセスキーは使用しない。
    • S3のオブジェクトレベルのログは有効にしておく。何が漏れたかログでチェックできる。
    • 攻撃者は本番環境か検証環境かは気にしない。検証環境だからセキュリティ対策は適当でいいや、は通用しない。

AWS Abuse Report

  • 自分のAWSアカウントのリソースが外部に攻撃をしている。（加害者になっている）
  • リスク
    • EC2が乗っ取られている場合、EC2内のデータも抜き取られる。
    • ロール権限によっては他のリソース（S3やRDSなど）にも被害が波及する。
    • 攻撃の被害者から訴訟される可能性も。
    • 対処やAWSへの返信をしない場合、24時間以内にアカウントを停止される恐れも。

  • やること
    • AWSへ着手したことの報告（英語）
    • 攻撃を止める。発生はほぼEC2
    • EC2のIAMロール権限の確認
    • CloudTrailで不審なアクティビティがないか確認
    • AWSへ対応完了の連絡（英語）※攻撃が停止されていること＋適切な再発防止策が実施されていることを求められる。

  • 知っておくこと
    • Abuseについてはサポートケースに質問しても回答不可。対応チームが異なる。
    • 対応チームは持っている情報くれるが、原因調査は行わない（責任共有モデル）
    • 削除したEC2をバックアップから復元して再発した場合はもう一度通知がやってくる。
    • スパムがフィッシングメールだと判明すると、AWSの温度感が上がる。AWSからの通知を見逃さないこと。

Amazon SES Review

  • 存在しないアドレスにメールを送ってバウンスしている場合や、苦情率が増加した時に通知を受ける。
  • SESの認証情報が奪取されてスパム送信している場合がある。
  • リスク
    • 著名なドメインを運用中の場合、そのドメインでスパムが送信されることにより被害が拡大したり、ブランドの損失につながったりする。
    • フィッシングメールの場合、非常に高い緊急度での対応がAWSから求められる。
    • 24時間以内にSESが停止されることも。

  • SESが不正利用された場合の対処については、以下のブログに詳細にまとめられている

dev.classmethod.jp

通知が来た時に焦らないために

  • インシデントは起きるものとして準備しておく。
  • AWSの通知に頼らない検知・調査方法を確立する。
  • 監査ログが取れているかチェックする。
  • ビジネスリスクとして認識し、組織的に対応できるようにしておく。
    • エンジニアリングレイヤーだけで取り組まず、ビジネスレイヤーを巻き込む。
  • 自力で対応が難しい場合は調査会社を選定しておく。
  • 対応訓練を行う。
    • 公式ドキュメントに対応手順の記載がある。
    • 定期的に訓練することには高い効果がある。

AWSアカウントのセキュリティインシデント調査どうする？Amazon Detectiveを利用した調査の勘所

登壇者ブログ

このセッションの内容については、すでに登壇者の方がご自身でブログにまとめているので、詳細についてはそちらを参照。

dev.classmethod.jp

AWSのセキュリティとは

  • Well-Architectedフレームワークの中にセキュリティの柱がある。
  • セキュリティの柱は７つの設計原則と６つのベストプラクティスがあり、その中に10個の質問がある。
  • Well-Architectedフレームワークの質問を使い、「自分の組織はどうか？」を議論すると、幅広い内容について検討できる。
  • AWSに閉じた話ではなく、ワークロード・ビジネス・会社全体に活用できる考え方。

Amazon GuardDuty

  • AWS上のインシデント検知するサービス。以下は一例。
  • GuardDutyによるインシデント検知
    • CloudTrail/VPC FlowLog/Athena等を利用してログ調査する。
    • S3に保存されたログはAthenaを使って分析するのがセオリー。

Amazon Detective

  • ログ調査を簡単にしてくれるツール。
  • 有効にすればログを自動で取り込んでくれる。
  • エンティティ間を自動で関連づけしてくれる。
  • GuardDutyのFindingsから「Detectiveで調査する」というボタンを押して使用する。
  • リンクを辿ることができる（例えばEC2インスタンスのログから、作成者・インスタンスID・ロールなどへ飛ぶことができる）
  • API実行履歴や通信記録を確認できる。
    • 実行したIPアドレス毎にAPI呼び出しが分類されている。
    • 正規利用者と不正利用者が混在している場合などに整理しやすい。
    • どのあたりからAPIが利用されているか地図上で表示してくれる。

コインマイニングへの対応

  • GuardDuty Findingsで「CryptoCurrencyCurrency:EC2/BitcoinTool.B」が出たら、ほぼ100％マイニングされていると思って間違いない。
  • IAMが乗っ取られたかEC2が乗っ取られている。どちらかによって対応範囲が異なる。
  • EC2をいつ誰が作ったのか確認する。ユーザーに見覚えがあるか。見覚えがあれば本人に確認する。
  • 攻撃者が作った場合は更に元を辿る。どこからクレデンシャルが漏れたのか。
  • IAMユーザーのアクセスキーか、EC2等のIAMロールの一時クレデンシャルか。
  • ユーザーの他の作業を確認。「RunInstances」「CreateSecurityGroup」「CreateKeyPair」があれば注意。
  • コインマイニングのために新規に作られたEC2は削除する。
  • 既存のEC2の場合、AMIをバックアップして、隔離された環境で後で解析する。
  • コインマイニングの場合、すべてのインスタンスタイプで作成できる限界までEC2を作成される。※インスタンスタイプ毎に作成数に上限がある。

S3データアクセス

  • GuardDuty Findings「PenTest:S3/KaliLinux」など。
  • もともと公開しているものじゃないバケット、データにアクセスが来ていたらヤバい。
  • 公開しているバケット、データなのかについて、Detectiveで調査することはできない。
  • Detectiveは全てのFindingTypeに対応しているわけではないため。対応しているタイプは以下を参照。

サポートされている検索結果タイプ - Amazon Detective

  • S3データイベントはCloudTrail上ではデフォルトでは取れない。管理イベントのみ。
  • 重要なデータを保存する場合はデータイベントを収集する設定を追加する。
  • S3にログを保管するなら、不正アクセスされてもログを消されない工夫が必要。
    • 別のAWSアカウントにログを集約する。
    • S3オブジェクトロックを使用する。
    • SCPを使用して、組織全体でアクセス制限をかける。

その他

  • EC2についてロケーション単位でのアクセス制限をしたい場合は、ALBをかませてWAFを利用する。
  • ロケーションでのアクセス制限はあくまで補助的な対策と考える。
  • 組織のセキュリティ意識を高めるには、マイニングを実際にやられた人のブログを読ませるのが良いかも。

アラート対応で疲弊しているチームが今できること

登壇者ブログ

こちらのセッションについても、すでに登壇者の方がブログにまとめていたので、詳細はそちらを参照。

dev.classmethod.jp

AWS Systems Manager(SSM)

  • EC2インスタンスなどの操作を自動化(RunBook)
  • 2021年5月にアップデートあり
  • インシデントマネージャー
    • インシデント管理機能と進化した自動化フロー
    • CloudWatchアラームをトリガーにしてSSM AutomationのRunBookを実行
    • さらにインシデントの管理ページを作成できる（事象サマリ、時系列、振り返り）
    • 一定時間解決しない場合に電話を発信したり、状況をSlackに上げたりできる。
    • CloudWatchアラームのアクション設定画面から連携可能。
    • 「あるアラームが出たらプロセスを再起動する」といったオペレーションを自動化できる。
    • アラートが発生した時にtopコマンドを打つように自動化して、後でどのプロセスが暴れていたのか検知したりすることも可能。

CloudWatch Anomaly Detection（異常検出）

  • 学習結果を閾値に反映する。
  • 従来型のアラートと並行して運用。
  • 最初は予測のバンド狭く（敏感に）設定→徐々に鈍感にしていく
  • 傾向がある程度読めるメトリクス向き（月末に多い・土日に少ない・バッチ処理する夜間に多い、など）
  • 突発的なイベントには対応しづらい（セールや新商品の発表など）

CloudWatchダッシュボード

  • 傾向が知りたいならダッシュボードを利用する。
  • 「なんか不安だから」と低い閾値でアラームを出すのをやめる。
  • 朝に５分眺める習慣から。
  • 他のアカウントのリソースを持ってくるのはちょっと大変。
  • ダッシュボードはいきなり完璧なものを作るのは難しい。まずはたたき台を作り、そこから練り上げていく。ダッシュボードは育てるもの。

CloudWatch Syncetics

  • 合成監視サービス。
  • URLを監視して、ユーザーの体験のメトリクスをとる。
    • レスポンスタイム、レスポンスコード、レスポンスなしの数。
    • 4XX、5XXエラーが返ってくるか。
    • WEBサービスの死活監視にも使える。

おわりに

今回の勉強会は非常にためになった。個人環境だと本格的な運用の経験を積むのがなかなか難しいので、実際の現場でのリアルな運用話が聞けて良かった。

また、個人アカウントでも不正アクセスから大きな損害を発生させてしまうのは、リソースを簡単にデプロイできるクラウド環境ならではの怖さだな、と感じた。 Well-Architectedフレームワークを見て自分の利用環境も見直してみようと思う。