EKS、ECS、および Fargate のお客様の Apache log4j セキュリティ問題を軽減するためのアドバイス

本投稿は Omar Paul による記事 Advice on mitigating the Apache log4j security issue for EKS, ECS, and Fargate customers を翻訳したものです。

CVE-2021-44228 (以降 CVE-2021-45046) は、Apache Log4j 2 の Java ロギングライブラリバージョン 2.0-beta9 からバージョン 2.15.0 までで見つかったセキュリティ問題を説明しています。この問題は、Java Naming and Directory Interface (JNDI) を使用しており、悪意のある攻撃者は、脆弱なプラットフォーム上でリモートコード実行を行うことができます。この件に関する Amazon Web Services (AWS) のセキュリティ速報では、AWS の各サービスの対応情報をまとめています。

このブログでは、Amazon EC2とAWS Fargateを使用してコンテナ型アプリケーションを実行するAmazon Elastic Container Service (Amazon ECS) とAmazon Elastic Kubernetes Service (Amazon EKS) のお客様が、CVE-2021-44228とCVE-2021-45046（log4j2 issue）を特定して軽減する方法について説明します。

特定と修復

AWS は、お客様がアプリケーションコンテナイメージを調査し、Log4j2 をバージョン 2.16 以降にアップグレードして本脆弱性に早急に対応することを強く推奨します。Amazon Elastic Container Registry（Amazon ECR）は、Amazon Inspector を使用した Enhanced Scanning を提供します。これは、CVE-2021-44228 および CVE-2021-45046を含むコンテナイメージを含む、既知のセキュリティ問題についてコンテナイメージを継続的にスキャンするように設計されています。Inspectorを初めて利用するAWSアカウントを対象にした15日間のトライアルでは、ECRのEnhanced Scanningを利用して、ECRに保存されているコンテナイメージにこの log4j2 issue が含まれてないかを検出することができます。この AWS security services blog post では、log4j2 issue についてより詳しく検出と対応方法について説明しています。

緩和

最近発表された Hotpatch for Apache Log4j を含むAmazon Linuxパッケージを使用することで緩和されます。このパッチがどのように機能するかについては、このブログ記事を参照してください。このパッチは、お客様が Java ベースのアプリケーションで Log4j2 の依存関係を少なくとも Log4j バージョン 2.16 に更新するまでの一時的な緩和策として設計されていることに留意してください。このパッチは、依存関係の更新がすぐにできない場合に、リスクを軽減するのに役立つ可能性があります。Log4j 2 バージョン 2.16 以降を使用するようにアップデート済みのコンテナイメージを使用しているお客様のアプリケーションでは、以下の緩和策を適用しないでください。

Amazon EKS で EC2 をご利用のお客様

AWSのKubernetesチームは、このパッチをノードエージェントとしてパッケージ化し、DaemonSet として任意のKubernetesクラスタにインストールできるプロジェクトをオープンソースで公開しています。このDaemonSet を実行すると、ホスト上だけでなく、Amazon Linux および Amazon Linux 2 上のコンテナで動作している JVM にパッチが適用されます。このツールは、Log4j2 アプリケーションの依存関係を更新することがすぐにできない場合に、リスクを軽減するのに役立つ可能性があります。このノードエージェントを使用するには、GitHub上のプロジェクトをご覧ください。

Amazon ECS で EC2 をご利用のお客様

このパッケージを適用すると、コンテナやネストされたコンテナで実行されているJavaプロセスを含むJavaプロセスを継続的に特定し、ホットフィックスを適用することができるようになります。この新しいパッケージは、Amazon ECSインスタンスにインストールすることで、log4j2の問題を軽減することができます。ECS EC2インスタンスに適用する方法は3つあり、以下に説明します。

AWS Systems Manager を使用した ECS EC2 インスタンスへのインストール

AWS Systems Manager（SSM）と関連付けし、ECSコンテナインスタンスも含むすべてのEC2インスタンスに対して log4j ホットパッチインストールスクリプトを実行することが可能です。SSMはリージョンサービスであるため、以下のすべての手順は、ECSインスタンスがJavaベースのコンテナを実行しているすべてのリージョンで行う必要があります。

SSMでインスタンスに提供します。その際はこのドキュメントに従ってください。
ハイレベル
- SSMエージェントがインスタンスにインストールされていることを確認します。Amazon Linux 2ベースのECS-optimized AMIを使用する場合、SSM Agentが含まれているので、このステップはスキップできます。
- AmazonSSMManagedInstanceCore IAMポリシーが、EC2インスタンスプロファイルに使用されるIAMロールに含まれていることを確認します。
- これらのEC2インスタンスは、AWS Systems Managerのコンソールで、Instances & Nodes > Managed Instancesに表示されます。
- このテンプレートでAWS CloudFormationスタックを作成します。

AWSTemplateFormatVersion: "2010-09-09"
Resources:
  InstallLog4JHotPatchAgentAssociation:
    Type: AWS::SSM::Association
    Properties:
      AssociationName: "InstallLog4JHotPatch"
      Name:
        Ref: InstallLog4JHotPatchDocument
      MaxConcurrency: "1"
      Targets:
        - Key: "InstanceIds"
          Values:
            - "*"
  InstallLog4JHotPatchDocument:
    Type: AWS::SSM::Document
    Properties:
      Content:
        mainSteps:
          - "action": "aws:runShellScript"
            "name": "InstallLog4JHotPatch"
            "inputs":
              "runCommand":
              - "yum install -y log4j-cve-2021-44228-hotpatch"
        parameters: {}
        schemaVersion: "2.0"
      DocumentType: "Command"

EC2インスタンスにlog4j ホットパッチをインストールするSSMドキュメントが作成され、AWSアカウントから起動した新規を含むすべてのEC2インスタンスに対してSSMドキュメントを実行するSSM の関連付けが作成されます。これにより、オートスケールでクラスタに追加されたすべての新規インスタンスに、このパッチが自動的に適用されるようになります。
AWS Systems ManagerコンソールのInstances & Nodes > State Managerにアクセスし、InstallLog4jHotPatch の関連付けがSuccessの状態であることを確認します。

EC2 ユーザーデータを使用した ECS EC2 インスタンスへのインストール

User Dataは、EC2がインスタンスを起動する際に実行する短いシェルスクリプトで、詳しくはこちらのドキュメントをご覧ください。このコマンドをECS EC2インスタンスのUser Dataに追加します。

#!/bin/bash
yum install -y log4j-cve-2021-44228-hotpatch

ECS EC2インスタンスへの手動インストール

緊急対応のオプションとして、お客様はECS EC2インスタンスにSSH接続し、パッチを手動でインストールすることができます。

$ sudo yum install -y log4j-cve-2021-44228-hotpatch

AWS Fargate のお客様

AWS Batch、Amazon ECS、Amazon EKSでFargateをご利用のお客様は、AWSサポートにご連絡いただき、log4j Javaホットパッチの適用を希望される旨をお申し出ください。このオプトインはアカウントとリージョンごとに行われるため、リクエストにはすべてのアカウントIDとホットパッチを適用すべきすべてのリージョンを含める必要があります。地域ごとにホットパッチが適用されると、Fargateタスク/Podを新規に起動した際にホットパッチが適用されます。すでに実行されているタスク/ポッドは、置き換える必要があります。

余談ですが、同意なしにお客様のアプリケーションに影響を与える可能性を避けるため、また、お客様が本番環境で使用するアカウントにオプトインする前に、非本番環境でこれを試すことができるように、このメカニズムをオプトインすることにしました。

AWS Batch のお客様

EC2およびFargate Batchジョブのエフェメラルな性質を考えると、コンテナイメージを更新してlog4j2のセキュリティ問題を修正することは、AWS Batchのお客様に推奨される解決策です。これは、30分未満の短時間のジョブは、ジョブキューからの継続的なジョブ送信とスケーリングされたEC2インスタンスへのジョブプレイスメントの性質と組み合わせると、ホットパッチのアプリケーションロジックによって見逃されてしまうからです。

バッチ起動のEC2インスタンスを使用している場合、一時的な緩和策として、お客様は、上記の「EC2 を使用している Amazon ECS のお客様」のセクションのオプション1または2を使用してパッチを適用することができます。

オプション1：SSM経由のパッチは、Batchで起動した既存および新規のEC2インスタンスで動作します。
オプション2：ユーザーデータを使用する方法は、新しいEC2インスタンスで動作し、AWS Batchの LaunchTemplate サポートを通じて適用することができます。以下に例を示します。

==MYBOUNDARY==
Content-Type: text/cloud-config; charset="us-ascii"

packages:
- log4j-cve-2021-44228-hotpatch
==MYBOUNDARY==--

Fargateジョブを持つAWS Batchのお客様で、ホットパッチによる緩和をご希望の方は、上記のAWS Fargateのアドバイスをご参照ください。

AWS Elastic Beanstalk のお客様

AWS Elastic Beanstalkは、Amazon Linux 1およびAmazon Linux 2のTomcatプラットフォームにおいて、Amazon LinuxのデフォルトパッケージリポジトリからLog4j2をインストールしています。 Amazon Linux 1およびAmazon Linux 2のリポジトリで利用できるLog4j2のバージョンは、log4j2の問題の影響を受けません。もしアプリケーションでlog4jを使用するために設定を変更した場合、またはlog4jの新しいバージョンをインストールした場合は、アプリケーションのコードを更新して、log4j2のバージョン2.16以上にアップグレードすることをお勧めします。

Elastic Beanstalkは、最新のAmazon Linuxデフォルトパッケージリポジトリを使用する新しいプラットフォームのバージョンをリリースしており、新しいプラットフォームのリリースには log4j hotpatched JDK が含まれています。アプリケーションの依存関係にあるlog4jをカスタマイズしてインストールしているお客様には、CVE-2021-44228またはCVE-2021-45046を軽減するために、最新のBeanstalkプラットフォームバージョンにアップグレードすることが推奨されます。お客様は、この緩和策が利用可能になったときに自動的に取得するために、マネージドプラットフォームアップデートを使用することができます。

AWS App Runner のお客様

App Runner で Java を使用しているお客様は、log4j のバージョンを更新してコンテナイメージを再構築し、App Runner サービスを再デプロイしてください。

EC2 または AWS Fargate を使用し、Windowsベースのコンテナを実行しているAmazon ECSのお客様

以下の緩和オプションの中から、お客様のニーズに合ったものをお選びください。

影響を受けるバージョンの Log4j2 を使用しているすべてのコンテナについて、既存のタスク定義を更新してください。
- コンソール経由でタスク内の影響を受ける各コンテナに対して LOG4J_FORMAT_MSG_NO_LOOKUPS=true を設定します。
- AWS コマンドラインまたは SDK を使用して、タスク内の該当コンテナの environment セクションを以下のように更新してください。

"environment" : [ 
    { 
        "name" : "LOG4J_FORMAT_MSG_NO_LOOKUPS", "value" : "true" 
    }
]

タスク定義の更新が難しい場合、以下の2つの方法で既存のDockerfileを更新することができます。
- アプリケーションを起動する前に、コンテナ内に ENV コマンドの設定を追加してください。

FROM openjdk:##-jdk
... 
ENV LOG4J_FORMAT_MSG_NO_LOOKUPS=true 
...

- または、アプリケーション起動時に log4j2.formatMsgNoLookups JVM startup オプションを追加してください。

FROM openjdk:##-jdk
... 
ENTRYPOINT ["java", "-Dlog4j2.formatMsgNoLookups=true", "...", "{EntryClass}"]

Bottlerocket のお客様

AWSがサポートするBottlerocketイメージは、log4j2の問題の影響を受けません。最小限のOSであるため、OSの一部としてApache Log4j2が含まれていません。しかし、Bottlerocketのお客様は、コンテナ内でロギングライブラリを使用している可能性があります。これらのJavaベースのコンテナへの影響を軽減するために、Bottlerocket 1.5.0では、コンテナ内のJavaプロセスにホットパッチを当てる機能（Hotdog）が追加されました。
ホットパッチは、ユーザーデータに以下の設定を含めることで、新規インスタンス起動時に有効にすることができます。

[settings.oci-hooks] <br />log4j-hotpatch-enabled = true

最新バージョンのBottlerocketを実行している既存のホストでは、APIクライアントを使用してホットパッチを有効にすることができます。

$ apiclient set oci-hooks.log4j-hotpatch-enabled=true

この機能は、BottlerocketのEKS、ECS、VMWareの各バリエーションで利用可能です。この機能を使用するには、ノードを最新のBottlerocketリリース(1.5.0)にアップグレードしてください。詳細については、GitHubのアナウンスを参照してください。

Vaishnavi Venkatesan、Sharanya Devaraj、Rashid Aga、Mike Stefaniakの各氏の寄稿によるものです。

翻訳はソリューションアーキテクトの竹本が担当しました。

Amazon Web Services ブログ