はじめに
こんにちは、ソリューションアーキテクトの佐藤です。
突然ですが、みなさんは普段どのようなパッチ運用を行なっていますか ?
スケジューリングで定期的に実行している、あるいはリスクが高い脆弱性が検出された場合に絞って実施している、などの方法で各々のセキュリティポリシーに準拠する形で実施されていると思います。
この記事では、Amazon Inspector、AWS Systems Manager をはじめとしたサービスを用いて、脆弱性をもつパッケージをオンデマンドでパッチ適用させるソリューションを実際にデプロイして扱っていきます。このソリューションにより、重大な脆弱性が発見された場合、修正パッチが公開された段階ですぐに・数クリックで適用することが可能になります。
それでは、簡単に EC2 インスタンスやコンテナイメージの脆弱性を検知してくれる Amazon Inspector について紹介した後に、今回のソリューションをデプロイしていきたいと思います。
ご注意
本記事で紹介する AWS サービスを起動する際には、料金がかかります。builders.flash メールメンバー特典の、クラウドレシピ向けクレジットコードプレゼントの入手をお勧めします。
builders.flash メールメンバー登録
Amazon Inspector とは ?
まず、脆弱性対応においては、利用中の AWS 環境内でどのような脆弱性が存在しているかを把握しておく必要があります。
特に、重大な脆弱性が発見された場合は、どの EC2 インスタンスやコンテナイメージに該当する脆弱性が存在しているかといった、リソースを特定しておくことは大切です。
このような脆弱性の「検知」の部分を支援してくれるのが Amazon Inspector です。Amazon Inspector は、 2021 年の AWS re:Invent でアップデートされた、EC2 インスタンスや ECR のコンテナイメージに対してソフトウェアパッケージの脆弱性やネットワークの露出を検知してくれるサービスです。
※余談ですが、アップデート前の Amazon Inspector は Inspector Agent という専用のエージェントをインストールすることで、EC2 インスタンスの脆弱性を検知できるようなサービスでしたが、こちらは Inspector Classic と名前が変更されました。
Amazon Inspector は Systems Manager (SSM) エージェントでソフトウェアのインベントリ情報を取得してソフトウェアの脆弱性についてスキャンを行います。SSM エージェントは、AWS の提供する多くの AMI ではデフォルトでインストールされている ため、それらのAMIを使っている場合は、インストール作業等必要なしに、すぐに、そして数クリックで脆弱性を検出することが可能です。
図のようにダッシュボードとして Inspector が有効になっているリソースの割合や、重大度が最も高い脆弱性の件数など、全体の状況を把握することも可能です。
また、検出結果は AWS Security Hub へ統合することも可能です。以上が Amazon Inspector の主な機能です。
ソリューションの概要
では早速、今回デプロイするソリューションを見てみましょう。以下のアーキテクチャで構成されています。
各工程の解説
少し複雑なので、各工程を追って何を行なっているのか解説します。箇条書きの番号が、アーキテクチャ図の矢印に記載の番号と対応しています。
Amazon Inspector の検出結果を AWS Security Hub に統合します。
Security Hub で修復したい Inspector からの検出結果を指定し、カスタムアクション で Amazon EventBridge に送信します。
EventBridge では EC2 のインスタンス ID と、Amazon Inspector の検出結果の ID をパラメータとして、Systems Manager Automation を実行します。
AWS Systems Manager Automation 内の Python スクリプトによって、指定した検出結果の原因となるパッケージを収集して、パッチ適用させたいパッケージの情報が記載された Patch Install Override List を Amazon S3 へ保管します。
AWS-RunPatchBaseline の Run Command では、ステップ 4 で作成した Patch Install Override List を使用して、検出結果のソフトウェアパッケージに対して実行しパッチを適用させます。
更新が完了すると、Automation Runbook は インベントリの情報を更新する AWS-GatherSoftwareInventory ドキュメントを実行するために、EC2 インスタンスに紐づけられたステートマネージャの関連づけを Systems Manager State Manager から取得します。
AWS-GatherSoftwareInventory ドキュメントを実行して、インベントリ情報を更新します。
EC2 インスタンスは、更新されたインベントリの情報を AWS Systems Manager に送信します。
また、このソリューションにおけるユーザーが操作する箇所は、Security Hub のコンソールで修復したい検出結果を指定してカスタムアクションの実行ボタンをクリックするのみであり、工数が少なく、オペレーションのミスが発生しにくい点も特徴です。
また、本記事では単一アカウントでのデプロイ方法を紹介しますが、マルチアカウントの構成の場合もサポートされていますので、ご興味があれば実施いただければ幸いです。マルチアカウントの場合の構築方法が紹介されたブログは こちら です。
ソリューションのデプロイ
前提
Amazon EC2 インスタンスが Systems Manager によって管理されているマネージドインスタンスであること
Security Hub を有効化していること
ソリューションのデプロイ
前提
Amazon EC2 インスタンスが Systems Manager によって管理されているマネージドインスタンスであること
Security Hub を有効化していること
Step 1 : Amazon Inspector を有効化する
まずは Amazon Inspector を有効化しましょう ! 有効化は数クリックで簡単にできます。
今回デプロイしたいリージョンを選択して、Amazon Inspector のコンソールへと移動します。
「使用を開始する」をクリックします。
その後、Inspector を有効化のページで「Inspector を有効化」をクリックします。
これで有効化作業は完了です !
しばらくすると、各リソースに対する検出結果が現れるはずです。
Step 2 : Amazon Inspector の検出結果を EventBridge に送信するための Security Hub カスタムアクションを作成する
まずは、Security Hub でカスタムアクションを作成しましょう。
Security Hub のコンソールを開き、左のナビゲーションから「設定」を選択して、「カスタムアクション」のタブへ移動します。
「カスタムアクションを作成する」をクリックします。
3. 今回はパッチ適用後に再起動しない場合と再起動する場合について、それぞれカスタムアクションを作成します。
再起動しない場合のカスタムアクションを作成する
a. アクション名には Rem-Inspector-NoRBT と入力します。
b. 説明には、「インスタンスを再起動せずに Amazon Inspector の検出結果を修復します。」と記載しておきます。
c. カスタムアクション ID には、InspectorRemNoRBT と入力します。
d. 「カスタムアクションを作成する」をクリックします。
再起動する場合のカスタムアクションを作成する
a. アクション名には Rem-Inspector-RBT と入力します。
b. 説明には、「Amazon Inspector の検出結果を修復してEC2インスタンスを再起動します。」と記載しておきます。
c. カスタムアクション ID には、InspectorRemRBT と入力します。
d. 「カスタムアクションを作成する」をクリックします。
4. カスタムアクションの ARN をそれぞれコピーしておきます。
Step 3 : Automation Runbook のための CloudFormation テンプレートのデプロイ
ここからの構築は CloudFormation テンプレートを用いて行います。aws-samples のこちら のリンクを開いて、ResolveInspectorFindingsCFN.yaml をダウンロードしてください。
AWS CloudFormation コンソールに移動します。「スタックの作成」をクリックします。
スタックの作成ページでは、「テンプレートの指定」の欄でテンプレートファイルのアップロードを選択し、ResolveInspectorFindingsCFN.yaml をアップロードして「次へ」を選択します。
3. スタックの詳細を指定ページでは、以下のステップを実行します。
a. 「スタック名」 には分かりやすい名前を入力します。私は RemInspectorFindings-Template と入力しました。
b. 次にパタメータの欄の、「RemediateInspectorFindingCustomActionNoRBTArn」には再起動しない方のカスタムアクションの ARN を入力します。
c.「RemediateInspectorFindingCustomActionRBTArn」には再起動する方のカスタムアクションの ARN を入力します。
d. OrganizationId は空白のままで大丈夫です。
4. スタックオプションの設定ではタグなどの設定を行えますが、今回はスキップして「次へ」を選択します。
5. 最後に、設定したパラメータを見直しします。確認したのち、 「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」 を選択して、「スタックの作成」をクリックしてスタックの設定を完了させます。
6. ページがリフレッシュされた後、スタックの状態が CREATE_COMPLETE に変わったら、出力タブから、「AutomationRunbookName」と「InstallOverrideListS3BucketName」の値をコピーしておきます。
Step 4 : Automation の実行ロールを作成する
次に、Automation を実行するためのロールを作成します。こちらも aws-samples に CloudFormation テンプレートがあるので、それを使ってデプロイしていきます。
こちら の GitHub ページを開き、AutomationExecutionRole.yaml ファイルをダウンロードします。
CloudFormation のコンソールから「スタックの作成」をクリックします。
スタックの作成ページでは、テンプレートの指定の欄でテンプレートファイルのアップロードを選択し、automationExectionRole.yaml をアップロードして「次へ」を選択します。
スタックの詳細を指定ページでは、以下のステップを実行します。
「スタック名」には分かりやすい名前を入力します。私は CreateExectionRole-Template と入力しました。
「AutomationRunPatchBaselineRunbook」にはステップ 3 の手順 6 でコピーした Runbook 名を入力します。
「DelegatedAdministratorAccoundID」 では現在ご利用のアカウント ID を入力します。
「InstallOverrideListBucket」では ステップ 3 の手順 6 でコピーした S3 のバケット名を入力します。
スタックオプションの設定ではタグなどの設定を行えますが、今回はスキップして「次へ」を選択します。
最後に、設定したパラメータを見直しします。確認したのち、 「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」 を選択して、「スタックの作成」をクリックしてスタックの設定を完了させます。
ページがリフレッシュされた後、スタックの状態が CREATE_COMPLETE に変わるのを待ちます。
Step 5 : EC2 IAM インスタンスロールに S3 バケットのアクセス権限を付与する
どのソフトウェアパッケージにパッチを当てるかを知るために、EC2 は パッケージ情報が記載されたファイルが保存されている S3 バケットへのアクセス許可が必要です。このステップでは必要なアクセス権限が記載された IAM ポリシーを EC2 インスタンスに付与します。このポリシーは Systems Manager がリソースを管理するための IAM ポリシーに加えて必要です。
こちら の手順に従って、EC2 にアタッチされている IAM ロールに対して IAM ポリシーをアタッチします。
ポリシーの内容は以下の NameOfInstallOverrideListBucketHere の文字列を、Step 3 の手順 6 でコピーした S3 バケットに変更してください。
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::NameOfInstallOverrideListBucketHere/*"
}]
}Step 6 : Security Hub のカスタムアクションを使って脆弱性を修復する
これで準備が整いました。それでは、Security Hub のカスタムアクションを使って、EC2 に関連づけられた Amazon Inspector の検出結果を修復してみましょう！
Security Hub のコンソールで、左のナビゲーションから検出結果を選択します。そうすると、各検出結果がリストされている画面に遷移します。
次に、フィルタの追加で「タイトル」フィルタを使用して、マッチタイプに「次で始まる」としてフィルタリングして「CVE」と入力します。この操作により、CVE にまつわる検出結果に絞って表示させることができます。
Inspector は EC2 インスタンスと ECR のコンテナイメージをスキャンしますが、今回は EC2 インスタンスのため、検出結果を EC2 インスタンスからのものに絞ります。さらにフィルタを追加して、「リソースタイプ」フィルタで 「AwsEc2Instance」と入力します。この二つのフィルタを適用すると、Security Hub は EC2 インスタンスのソフトウェアパッケージの脆弱性を表示します。
修復する検出結果を選択し、カスタムアクションを実行します。
パッチをインストールした後に、Amazon EC2 インスタンスを再起動する場合は 「Rem-Inspector-RBT」を、再起動したくない場合は、「Rem-Inspector-NoRBT」を選択します。カスタムアクションを選択すると、EventBridge に送信したことを示す通知が表示されます。
6. アーキテクチャ図に示した通り、EventBridge から Automation を実行して指定した脆弱性のソフトウェアパッケージのパッチが適用されます。
Automation の実行状況は Systems Manager のコンソールの左のナビゲーションから自動化を選択すると確認できます。興味があれば、Automation 内でそういう実装がなされているか確認してみてください。
しばらく時間が経過すると Inspector の検出結果も反映されるので確認してみましょう。
7. Inspector の左のナビゲーションから、「全ての検出結果」をクリックします。
デフォルトでは存在している Active な脆弱性が表示されますが、今回は修復された検出結果を確認したいので「Closed」に変更してください。そうすると、指定した Security Hub のカスタムアクションで指定した CVE のソフトウェアパッケージに関連する検出結果が修復されていることが確認できます !
まとめ
今回、aws-samples 内の CloudFormation テンプレートを活用して、指定した Amazon Inspector の検出結果を修復するようなソリューションを構築しました。これにより、オンデマンドに EC2 インスタンスで検出されたソフトウェアパッケージの脆弱性にパッチを適用できます。
多くの環境では定期的にパッチを適用されているかと思います。しかしながら、重大な脆弱性が検出された場合、スケジューリング実行のみでは、修正パッチが公開されたとしても、パッチ適用のタイミングを待つ必要があり、修正が遅れてしまう可能性があります。今回のソリューションではオンデマンドでパッチを適用できるため、迅速に修正することができます。ぜひ参考にしていただけると幸いです。
筆者プロフィール
佐藤 航大
アマゾン ウェブ サービス ジャパン 合同会社
ソリューションアーキテクト
西日本のお客様を中心にクラウド活用に関する技術的な支援を行うアーキテクト。
暗号技術が好きで、最近は耐量子暗号 (PQC) に興味をもっています。
休日は近所の喫茶店で本を読んだり、ぼんやり考え事をしています。
