AWS公式資料で挑むSCS認定(19)-こんな時どうする(分野1:インシデント対応)

[前回] AWS公式資料で挑むSCS認定(18)-模擬テスト

はじめに

「最強の敵は自分自身だ」
こうなりたいと願っても、意志や覚悟が足りず、ついさぼり出したい自分が。。。

各種AWSサービスの視点から勉強してきましたが、試験対策としては不十分でした。
模擬テストからは、以下のように
「あなたはセキュリティ担当者です、不審なアクセスが報告されました、どうしますか」
シチュエーションに対し、最適なソリューションを選ぶといった形がほとんど。

そうだ、「こんな時どうする」集をまとめてみよう

有効な試験対策になるかも。
なんか楽しくなりそう。

ネタはぶれず、AWS公式資料の「ユーザガイド」と「よくある質問」などからピックアップします。
下記出題対象の分野別、「こんな時どうする」を作ってみます。

• 分野1: インシデント対応
• 分野2: ログとモニタリング(監視)
• 分野3: インフラストラクチャのセキュリティ
• 分野4: アイデンティティ(ID)及びアクセス管理
• 分野5: データ保護

「分野1: インシデント対応」基本知識のおさらい

インシデントとは

• 認証情報漏洩(キーの紛失)
• データ整合性侵害(機密情報改竄)
• アクセス制限欠損(機密情報窃取)

インシデントの検知方法

• ログとモニタリング
  • これが基本か
• AWS請求の記録
  • 設定金額を超えアラートが送られたら
• 脅威インテリジェンス
  • 攻撃手段のナレッジを取得し、脅威分析を自動化、ML化
• AWSサポートからの通知
  • あなたのアカウントに不審なログイン試行がありました
• パブリックレスポンス
  • ユーザからの報告

インシデント対応に使用されるサービスとツール

• AWS Trusted Advisor
• AWS Cloud Formation
• AWS Service Catalog
• VPC フローログ
• AWS Config
• Amazon API Gateway
• AWS CloudTrail
• Amazon CloudWatch

「分野1: インシデント対応」の「こんな時どうする」

• IAMアクセスキーが誤って公開された

  • 公開されたIAMアクセスキーを無効にする
  • IAMアクセスキーがどのユーザに関連付けされたか確認
  • IAM拒否ポリシーをユーザにアタッチ
  • 残っているセッションをすべて取り消す
  • アクセスキーに関連付けされたポリシーの範囲を確認
  • AWS CloudTrail, AWS Configでリソースや設定が変更されていないか確認
  • 他のIAMアクセスキーや認証情報に問題ないか確認

• EC2インスタンスアクセス用のSSHキーが盗まれた

  • SSHキーが使用されていないか確認
  • SSHキーを使用しているEC2インスタンスへのポート22をブロック
  • SSHキーを使用しているEC2インスタンスのauthorized_keysファイルを変更

• EC2インスタンスから不審なトラフィックが検知されたので分離しインシデント調査したい

  • EC2インスタンスをAuto Scalingグループから分離
  • フォレンジック用にセキュリティグループ(SG)を作成
  • EBS スナップショットを用いてSGへボリュームコピー
  • フォレンジックSGにて問題EC2インスタンスを調査

• 複数パブリックサブネットに含まれる特定EC2インスタンスを簡単に自動分離させたい

  • セキュリティグループを変更するLambda関数を作成、インバウンドトラフィックをブロック

• EC2インスタンスから既知のC&Cサーバーへ不審なリクエストがないか確認したい

  • GuardDutyの結果タイプ(Finding)から確認
    • C&CサーバーのIPをクエリしている場合「Backdoor:EC2/C&CActivity.B」が通知
    • C&Cサーバーのドメイン名をクエリしている場合「Backdoor:EC2/C&CActivity.B!DNS」が通知
  • ※ C&Cサーバーとは、ボットネットのメンバーに悪意あるコマンドを発行させるコンピュータ

• CloudFrontディストリビューションへ不審なリクエスト発生、その送信元IPアドレス、元のリクエスト、リファラー、プロトコルを特定したい

  • CloudFrontのアクセスログに記録されたユーザーリクエスト情報から特定
    • 前提条件: ログ保存するS3バケットのACLに対し変更が必要
      • awslogsdelivery アカウントを追加し、FULL_CONTROL のアクセス許可を付与
      • awslogsdelivery アカウントにより、アクセスログがバケットに書き込まれる
  • ※ S3バケットのアクセスログからは、送信元IPアドレスを確認できない(リファラーは確認できる)
  • ※ CloudTrailからは、元のリクエストを確認できない(APIコールは確認できる)

おわりに

試験対策として「こんな時どうする」をまとめ始めました。
本質をしっかり理解しながら、追記して行こうと思います。
お楽しみに。

[次回] AWS公式資料で挑むSCS認定(20)-こんな時どうする(分野2:ログと監視)