Amazon Inspector と AWS Systems Manager を用いた脆弱性管理と修復の自動化 – Part1

このブログは Automate vulnerability management and remediation in AWS using Amazon Inspector and AWS Systems Manager – Part 1 を翻訳したものです。

AWS は最近、Amazon Elastic Compute Cloud（Amazon EC2）インスタンスと Amazon Elastic Container Registry（Amazon ECR）に保存されているコンテナイメージに継続的な脆弱性スキャンを実行するための新しい Amazon Inspector の提供を開始しました。これらのスキャンは、ソフトウェアの脆弱性と意図しないネットワークの露出を評価します。新しい Amazon Inspector は、Systems Manager (SSM) エージェントを使用して Amazon EC2 インスタンスのソフトウェアアプリケーションインベントリを収集します。次に、Inspector はこのデータをスキャンし、脆弱性管理の重要なステップであるソフトウェアの脆弱性を特定します。

脆弱性の重大度に基づいて Amazon Inspector によって特定された脆弱性を解決するために、定期的なパッチ適用操作を実行する必要があります。AWS Systems Manager Patch Manager を使用すると、SSM エージェントを使用して Systems Manager が管理するノードにパッチを適用するプロセスを自動化できます。パッチが利用可能な状況では、ゼロデイまたはその他の重大な脆弱性がある可能性があります。ただし、通常のパッチ適用スケジュールで修復されるのを待つのは望ましくない場合があります。このような場合、パッチ適用のためにオンデマンドにパッチ適用を行うべきでしょう。
このブログシリーズでは、Systems Manager Automation runbook を使用して、Amazon Inspector のソフトウェアの脆弱性の検出結果をオンデマンドで修復する 2 つの方法を提供します。 Automation Runbook は、自動化の実行時の、マネージドインスタンスやその他の AWS リソースに対する AWS Systems Manager のアクションを定義します。これには、順番に実行される 1 つ以上のステップ、または前のステップに基づいて分岐するステップが含まれます。Inspector によって特定されたソフトウェアパッケージの脆弱性を修復するための速度が重要な場合に、AWS アカウントで両方の方法を準備できます。
このブログシリーズの Part 1 では、複数の EC2 インスタンスに影響を与える特定の脆弱性について Inspector の検出結果を修復する方法を学習します。AWS Security Hub カスタムアクションを使用して、選択した EC2 インスタンスに対するオンデマンドの脆弱性パッチ適用のための Systems Manager Automation runbook をトリガーします。
Part 2 では、Systems Manager Automation runbook を直接呼び出して、リソースタグや検出結果の重大度を使用して EC2 インスタンスのすべての Amazon Inspector の検出結果を修復する方法を学びます。Inspector によって特定されたすべてのソフトウェアの脆弱性にパッチを適用する場合は、Systems Manager Automation runbookの直接呼び出し方法を使用します。このアプローチは、AWS Organization 全体でタグベースのターゲティングを使用して EC2 インスタンスフリートを効果的に管理します。
これらの方法は、AWS Organization が管理する複数のリージョンとアカウントで機能します。手動更新の運用の複雑さを軽減し、ミスを減らし、修復速度を向上させるのに役立ちます。

ソリューションの概要

Security Hub のカスタムアクションを用いて修復を行う

この方法では、カスタムアクションを使用して、Security Hub から選択した Amazon Inspector の検出結果を修復できます。カスタムアクションにより、選択した結果に対して Automation Runbook を有効にできます。次に、Automation Runbook は、Amazon Inspector の検出結果の詳細から影響を受けるパッケージの情報を使用し、Systems Manager Patch Manager を使用して、これらのパッケージのみを最新バージョンに更新します。この方法を使用するには、Security Hub を有効にします。
たとえば、次の図に CVE 2017-8816 の影響を受けるパッケージ curl と libcurl があります。ユーザーがこの結果に対してカスタムアクションを呼び出すと、Systems Manager Patch Manager はターゲットのマネージドインスタンスの両方のパッケージを更新します。Amazon Inspector は、脆弱性にパッチが適用された直後に、影響を受けるパッケージに関連するすべての検出結果を自動的にクローズします。

Figure 1: Finding details in the Amazon Inspector Console

図 1: Amazon Inspector コンソールの検出結果の詳細

Security Hub 委任管理者アカウントは、マルチアカウント、マルチリージョンのシナリオで、Automation Runbook をトリガーし、メンバーアカウントの Amazon EC2 インスタンスをターゲットにすることができます。このブログポストでは、影響を受けるパッケージを更新して再起動を実行するか、再起動をすぐに実行せず延期する 2 つのカスタムアクションを提供します。更新をインストールした後に Amazon EC2 インスタンスを再起動して、更新をすぐに利用することができます。さらに、再起動なしオプションを選択することで、再起動をメンテナンスウィンドウまで遅らせることができます。
このカスタムアクションでは、Amazon Inspector の検出結果を特定の CVE で検索することをお勧めします。Security Hub の [タイトル] フィルターを使用し、マッチタイプを [次で始まる] としてフィルターし、次の図の矢印を使用して CVE を入力できます。さらにリソースタイプフィルタを使用して AwsEc2Instance と入力することで、Amazon EC2 インスタンスに関連付けられた結果のみを表示します。これらのフィルタを選択すると、Security Hub は CVE の影響を受けるすべての Amazon EC2 インスタンスを表示します。次に、Amazon EC2 インスタンスに関連付けられたこのフィルタで表示されるすべての結果を選択し、カスタムアクションを実行できます。
次の図は、異なる Amazon EC2 インスタンスに関連付けられた複数の検出結果に対してカスタムアクションを実行できることを示しています。ただし、同じ Amazon EC2 インスタンスに対して多数の Amazon Inspector の調査結果を選択すべきではありません。同じ Amazon EC2 インスタンスに対する複数の Amazon Inspector の検出結果を解決するには、このブログシリーズの Part 2 を参照してください。

Figure 2; Selecting multiple Amazon Inspector findings for remediation in Security Hub

図2: Security Hub で修復のために複数の Amazon Inspector の検出結果を選択する

アーキテクチャの概要

自動化ワークフローにより、このブログポストで提供されている resolveInspectorFindingsRunbook カスタム Automation Runbook が有効になります。Security Hub カスタムアクションは、ソリューションの概要セクションで説明されているように、この Runbook を開始します。次の図のプロセスを確認してみましょう。

Figure 3: Automation process in multiple accounts

図 3: 複数アカウントにおける Automation のプロセス

Security Hub のカスタムアクションを使う場合は Security Hub 内での Amazon Inspector 検出結果を選択し、カスタムアクションを呼び出します。そうするとイベントが Amazon Inspector の検出結果の詳細とともに　Amazon Event Bridge に送信されます。ResolveInspectorFindings　EventBridge ルールはこのイベントパターンに一致します。
resolveInspectorFindings EventBridge ルールは、Amazon EC2 インスタンス ID と Amazon Inspector の検索 ID を Automation Runbook にパラメーターとして解析します。再起動オプションは、使用されているカスタムアクションに基づいて選択されます。
resolveInspectorFindingsRunbook は、マルチアカウントおよびマルチリージョンの startAutomationExecution API 呼び出しを作成し、Amazon EC2 インスタンスのターゲットアカウントとリージョンでパッチワークフローを開始します。
Python スクリプトは、図1に示されているように、Amazon Inspector の検出のために影響を受けるパッケージを収集します。次に、スクリプトは、収集された影響を受けるパッケージから InstallOverrideList を作成します。委任された管理者アカウントは、Amazon Simple Storage Service (Amazon S3) バケットにリストを保存します。このブログポストで提供されている AWS CloudFormation テンプレートは、このバケットを作成します。
AWS-RunPatchBaseline ドキュメントの Run Command タスクは、ステップ 4 で作成したインストールオーバーライドリストを使用して Amazon EC2 インスタンスで実行されます。再起動オプションは、選択した Security Hub カスタムアクションに基づいて渡されます。既存のパッチ適用オペレーションがターゲットの Amazon EC2 インスタンスで実行されている場合、Automation Runbook は続行されません。更新が利用可能な場合、AWS-RunPatchBaseline インストールオペレーションは、InstallOverrideList で特定された影響を受けるパッケージを、利用可能な最新バージョンに更新します。
更新が完了すると、Automation Runbook は、AWS-GatherSoftwareInventory ドキュメントを使用してソフトウェアインベントリを収集するために、Amazon EC2 インスタンスに適用されているステートマネージャの関連付けをSystems Manager に照会します。
AWS-GatherSoftwareInventory の関連付けは、インベントリを更新するために Amazon EC2 インスタンスにすぐに適用を開始します。
Amazon EC2 インスタンスは、更新されたインベントリ情報を AWS Systems Manager に送信します。

Amazon Inspector は、新しいパッチが正常にインストールされると、修復された結果のステータスを CLOSED に設定します。Security Hub の対応する検出結果のレコードの状態は ARCHIVED に設定されます。

要件

必須要件は以下の二つです。

Systems Manager が Amazon EC2 インスタンスを管理している必要があります。
Security Hub を有効化する必要があります。

ウォークスルー

このウォークスルーはいくつかのステップにて構成されます。

Amazon Inspector の検出結果を解決するための Security Hub カスタムアクションを作成する
Automation runbook のための CloudFormation テンプレートをデプロイする
StackSets を利用してマルチアカウントやマルチリージョンのための実行ロールを作成する
EC2 インスタンスの IAM ロールに InstallOverrideList の S3 バケットに対するアクセス権限を付与して更新する
Security Hub カスタムアクションを使用して脆弱性を修復する

Step 1: Amazon Inspector の検出結果を解決するための Security Hub カスタムアクションを作成する

Security Hub の委任された管理者アカウントとリージョンで、Security Hub コンソールへ移動します。左側のナビゲーションペインから設定を選択して、カスタムアクションのタブへ移動します。
カスタムアクションを作成する を選択します。
EC2 インスタンスを再起動せずに Amazon Inspector の結果を修復するには、次の手順を実行します。
1. 1. アクション名 に Rem-Inspector-NoRBT と入力します。
  2. 説明には、インスタンスを再起動せずに Amazon Inspector の検出結果を修復する、のように記載しておきます。
  3. カスタムアクション ID には InspectorRemNoRBT と入力します。
図 4: インスタンスの再起動なしに検出結果を修復する Security Hub のカスタムアクションを作成する
Inspector の結果を修復して EC2 インスタンスを再起動するための 2 つ目のカスタムアクションを作成するには、次の手順を実行します。
1. アクション名 に Rem-Inspector-RBT と入力します。
2. 説明には Amazon Inspector の検出結果を修復してEC2インスタンスを再起動する、のように記載しておきます。
3. カスタムアクション ID には InspectorRemRBT　と入力します。
カスタムアクションの ARN をそれぞれコピーしておきます。これは次のステップで利用します。

Figure 5: Security Hub custom action ARNs

図 5: Security Hub のカスタムアクション ARN

Step 2: Automation Runbook のための CloudFormation テンプレートのデプロイ

このブログポストで提供される AWS CloudFormation テンプレートは、Amazon Inspector が AWS アカウントの解決策を見つけられるようにするために必要なリソースをデプロイします。これらのリソースは、Security Hub 委任管理者アカウントに展開する必要があります。CloudFormation は、Security Hub クロスリージョン集約を使用する場合、集約リージョンにのみデプロイする必要があります。

以下の GitHub ページを開き、 ResolveInspectorFindingsCFN.yaml ファイルをダウンロードしてください。

https://github.com/aws-samples/automate-vulnerability-management-and-remediation/blob/main/templates/resolveInspectorFindingsCFN.yaml

Security Hub の委任管理者アカウントとリージョンの AWS CloudFormation コンソールに移動します。resolveInspectorfindingscfn.yaml テンプレートファイルを使用してスタックを作成します。
スタックの詳細を指定 のページは以下のステップを実行します。
1. 1. スタック名 には分かりやすい名前を入力します。
  2. RemediateInspectorFindingCustomActionNoRBTArn には前のステップでコピーした EC2 インスタンスを再起動せずに Inspector の検出結果を修復する Security Hub のカスタムアクション ARN を入力します。
  3. RemediateInspectorFindingCustomActionRBTArn には前のステップでコピーしたInspector の検出結果を修復後、EC2 インスタンスを再起動する Security Hub のカスタムアクションARN を入力します。
  4. もし委任管理者や管理アカウントでこのテンプレートをデプロイする場合は、OrganizationId に Organization ID をセットしておきます。Organization ID は、AWS Organization のコンソールから以下の図に示されている箇所で見つけることができます。もしスタンドアロンのアカウントでこのテンプレートを展開する場合は、このフィールドは空白のままにしておいてください。
図 6: Organization のコンソール
1. 次へを選択します。
図 7: スタックの詳細ページ
スタックオプション のページではオプションでタグをつけることができます。次へを選択します。
設定したパラメータを見直しします。その後、「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」を選択して、スタックの作成 をクリックしてスタックの設定を完了させます。
ページがリフレッシュされた後、スタックの状態が CREATE_IN_PROGRESS になるはずです。このステータスが CREATE_COMPLETE に変わったら、次のセクションに進めます。CloudFotmation のリソースタブから作成された様々なリソースを確認できます。
下の図に示すように、CloudFormation コンソールの出力タブから AutomationRunbookName と InstallOverrideListS3BucketName をコピーします。この値は以降のステップで使います。

Figure 8: CloudFormation outputs tab

図 8: CloudFormation の出力タブ

Step 3: StackSet でマルチアカウント、マルチリージョンでの自動化を行うために実行ロールを作成する

メンバーアカウントの Amazon EC2 インスタンスをターゲットとする委任された管理者アカウントから、この自動化（前のステップでデプロイしました）をトリガーするための自動化実行クロスアカウントロールを作成する必要があります。

この自動化を 1 つのアカウントでのみ使用する場合は、ステップ 1 で使用したのと同じ AWS アカウントでこのロールを作成する必要があります。

以下は複数アカウントでロールを作成する方法です。単一のアカウントでデプロイされる場合は、SteckSet を利用せずに、左のナビゲーションペインのスタックからデプロイをしてください。(※単一アカウントの場合のデプロイ方法が分かりにくいので付け加えました。)

次の GitHub ページを開き、AutomationExecutionRole.yml ファイルをダウンロードします。

https://github.com/aws-samples/automate-vulnerability-management-and-remediation/blob/main/templates/automationExecutionRole.yaml

Organization の管理アカウントや CloudFormation の委任管理者で AWS CloudFormation コンソールへ移動します。
ナビゲーションペインから StackSets を選択します。
StackSets ページの上部にある StackSet の作成を選択します。
前提条件 – テンプレートの準備 では テンプレートの準備完了 を選択します。
テンプレートの指定 では テンプレートファイルのアップロードを選択し、automationExecutionRole.yml を選択して次へをクリックします。
StackSet の詳細を指定 のページでは以下のステップを実行します。
1. Stackset 名 と StackSet の説明を設定します。
2. AutomationRunPatchBaselineRunbook にはステップ 2 の手順 6 でコピーした Runbook 名を入力します。
3. DelegatedAdministratorAccoundID では Security Hub の委任管理者のアカウント ID を選択します。もし、一つのアカウントでデプロイしている場合は、そのアカウント ID を入力します。
4. InstallOverrideListBucket ではステップ 2 の手順 6 でコピーした S3 のバケット名を入力します。
図 9: CloudFormation StackSet の詳細
StackSet オプションの設定 のページでは、オプションで required-tags を追加することもできます。次へを選択します。
デプロイオプションの設定ページで、目的のリージョンを選択します。IAM リソースを作成しているので、1 つのリージョンを指定します。次へを選択します。
設定した情報を確認します。「AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。」 を選択して、次に送信を選択することで、スタックの設定が完了します。
ページを更新すると、StackSet のステータスは [実行中] になります。ステータスが [Succeeded] に変わったら、次のセクションに進みます。個々のスタックインスタンスの結果は、CloudFormation StackSet コンソールの [スタックインスタンス] タブで確認できます。

Step 4: EC2 IAM インスタンスロールに install override list S3 バケットのアクセス権限を付与する

ターゲットアカウントの EC2 インスタンスには、Security Hub の委任管理者アカウントの S3 バケットにある IAM アクセス許可が必要です。ステップ 1 の CloudFormation テンプレートによってこの S3 バケットは作成されます。次のセクションでは、EC2 のプロファイル定義に必要な必要な IAM ポリシーの例を示します。このポリシーは、Systems Manager がリソースを管理するための IAM ポリシーに加えて必要です。

サンプルポリシーのリソースセクションにあるバケットの名前を、前の手順 2、ポイント 6 でコピーしたインストール上書きリストのバケット名で更新する必要があります。このアクセス許可ポリシーは、自動化を使用して Amazon Inspector の検出結果を修復できるようにしたいインスタンスのすべての EC2 インスタンスロールに追加する必要があります。

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": "s3:GetObject",
        "Resource": "arn:aws:s3:::NameOfInstallOverrideListBucketHere/*"
    }]
}

Step 5: Security Hub のカスタムアクションを使って脆弱性を修復する

それでは、Security Hub のカスタムアクションを使用して、Amazon EC2 インスタンスに関連づけられた Amazon Inspector の検出結果を修復する手順を見てみましょう。

1. Security Hub の委任管理者アカウントでステップ 1 を展開したリージョンの Security Hubコンソールに移動し、検出結果ページに移動します。
  1. Security Hub のタイトルフィルタを使用して、マッチタイプに次で始まるとしてフィルタリングして修復する CVE を入力します。
  2. リソースタイプフィルタで AwsEc2Instance を入力して、Amazon EC2 インスタンスに関連付けられた検出結果のみを表示します。
  3. これらのフィルタを適用すると、Security Hub は CVE の影響を受ける全ての Amazon EC2 インスタンスを表示します。
  4. 修復する検出結果を選択し、カスタムアクションを実行します。
  5. パッチをインストールした後に、Amazon EC2 インスタンスを再起動する場合は Rem-Inspector-RBT　を、再起動したくない場合は、Rem-Inspector-NoRBT を選択します。
  図 10: Security Hub の検出結果のページとカスタムアクション
2. カスタムアクションを選択すると、EventBridge がイベントを受信したことを確認する通知バナーが表示されます。
3. 次の図に示すように、Systems Manager Automation コンソールの [実行] タブで選択した結果ごとに、Automation Runbook の進行状況を監視できます。

Figure 11: Systems Manager Automation execution status

図 11: Systems Manager Automation 実行ステータス

1. パッケージにパッチを適用すると、Amazon Inspector の検出結果は Closed ステータスに更新されます。クローズした Amazon Inspector の調査結果は、Amazon Inspector コンソールの All Findings ページで確認できます。次の図に示すように、ドロップダウンから close を選択します。

Figure 12: Amazon Inspector console for closed finding.

図 13: Archived に設定された Security Hub の検出結果

このように Amazon EC2 インスタンスの vim パッケージ関連および依存関係関連の調査結果は修復され、クローズされます。

次の図に示すように、対応する Security Hub の検索レコードの状態は ARCHIVED に設定されます。

Figure 13: Security Hub finding record state set to Archived

Figure 13: Security Hub finding record state set to Archived.

注記

この方法では、Amazon EC2 インスタンスに関連する Amazon Inspector パッケージの脆弱性の検出結果のみが修復されます。 Amazon Inspector のネットワーク到達可能性の検出結果または Amazon ECR のコンテナイメージに関連するパッケージの脆弱性の検出結果は修復されません。
カスタムアクションを使用して、Amazon EC2 インスタンスごとに一度に 1 つの Amazon Inspector の結果を修復できます。ただし、影響を受けるパッケージが、同じ EC2 インスタンスに対して異なる CVE で複数の検出結果をもたらしたとします。その場合、影響を受けたパッケージに対するパッチ適用操作が成功すると、すべての検出結果が修復されます。Inspector の検出結果を大規模に修復したい場合は、このブログシリーズの Part 2 を参照してください。
異なる Amazon EC2 インスタンスに関連付けられている複数の Amazon Inspector の検出結果に対して、カスタムアクションを同時にトリガーできます。セキュリティハブの特定の CVE で Amazon Inspector の結果をフィルタリングし、脆弱性のあるすべての Amazon EC2 インスタンスでカスタムアクションを実行することをお勧めします (図 2 を参照)。
Automation Runbook は、影響を受けるパッケージの最新バージョンをインストールし、パッケージマネージャーリポジトリから入手できます。
これらの方法を使用して Linux カーネルの更新をインストールするとします。その場合、Linux は古いカーネルを削除しないため、関連する Inspector の検出結果は修復されない可能性があります。インストールされている最新のカーネルバージョンは、Systems Manager インベントリを使用して確認できます。

まとめ

このブログでは、どのように新しくなった Amazon Inspector が EC2 インスタンスの脆弱性の検出を支援できるのかを説明しました。オンデマンドでパッチを行う手法がゼロデイ攻撃や重大度が致命的な脆弱性の修復を行うために必要である理由を再認識しました。最後に、特定の CVE に関連する EC2 インスタンスのパッケージ脆弱性に対する Inspector の検出結果を Security Hub のカスタムアクションを使って自動で修復する方法を示しました。この自動化は、手作業による更新の複雑さや、エラーを削減し、修復スピードを向上させることに役立ちます。

また、AWS Organization 全体で複数の EC2 インスタンスが抱える同じ脆弱性の修復を二つの Security Hub カスタムアクション Rem-Inspector-RBT と Rem-Inspector-NoRBT を使って実現できます。

Part 2 では、リソースタグや Inspector の検出結果の重大度に基づいて Organization 全体の EC2 インスタンスに対する検出結果を修復するために、Automation コンソールから直接 Systems Manager Automation runbook を利用する方法を示します。

翻訳はソリューションアーキテクトの佐藤航大が担当しました。原文はこちらです。

Amazon Web Services ブログ