

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# AMS Accelerate でのパッチ管理を理解する
<a name="acc-patching"></a>

**重要**  
Accelerate Patch レポートは、 AWS Glue リソースベースのポリシーを定期的にデプロイします。パッチシステムへの AMS 更新は、既存の AWS Glue リソースベースのポリシーを上書きすることに注意してください。

**重要**  
マネージドノードの代替パッチリポジトリを指定できます。AMS がリクエストされたパッチ設定を実装している間は、選択したリポジトリのセキュリティを選択して検証する責任があります。また、サプライチェーンのリスクなど、これらのリポジトリを使用することによるリスクを受け入れる必要があります。  
パッチ管理プロセスのセキュリティに関するベストプラクティスを次に示します。  
信頼できる検証済みのリポジトリソースのみを使用する
可能な場合は、デフォルトで標準 OS ベンダーリポジトリに設定されます。
カスタムリポジトリ設定を定期的に監査する

AMS Accelerate パッチシステムである Patch Add-On を使用して、セキュリティ関連の更新やその他のタイプの更新でインスタンスにパッチを適用できます。Accelerate Patch アドオンは、AMS インスタンスにタグベースのパッチを適用する機能です。( AWS Systems Manager SSM) 機能を利用すると、インスタンスにタグを付け、設定したベースラインとウィンドウを使用してそれらのインスタンスにパッチを適用できます。AMS Accelerate Patch アドオンはオンボーディングオプションです。 Accelerate アカウントのオンボーディング中に取得しなかった場合は、クラウドサービスデリバリーマネージャー (CSDM) に連絡して取得してください。

AMS Accelerate パッチ管理では、Systems Manager のパッチベースライン機能を使用して、インスタンスに適用されるパッチの定義を制御します。パッチベースラインには、すべてのセキュリティパッチなど、事前承認されたパッチのリストが含まれます。インスタンスのコンプライアンスは、インスタンスに関連付けられたパッチベースラインに対して測定されます。AMS Accelerate は、デフォルトで、インスタンスを最新の状態に保つために使用可能なすべてのパッチをインストールします。

**注記**  
AMS Accelerate はオペレーティングシステム (OS) パッチのみを適用します。たとえば、Windows の場合、Windows 更新プログラムのみが適用され、Microsoft 更新プログラムは適用されません。

レポートの詳細については、「」を参照してください[AMS ホスト管理レポート](ams-host-man.md)。

AMS Accelerate は、運用上の優秀性の実現に役立つさまざまな運用サービスを提供します AWS。チームが 24 時間 365 日体制のヘルプデスク、プロアクティブモニタリング、セキュリティ、パッチ適用、ログ記録、バックアップなどの主要な運用機能 AWS クラウド を使用して、AMS が の全体的な運用上の優秀性を達成するのにどのように役立つかをすばやく理解するには、[「AMS リファレンスアーキテクチャ図](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/AWS-managed-services-for-operational-excellence-ra.pdf)」を参照してください。

**Topics**
+ [パッチ適用に関する推奨事項](#acc-patching-recos)
+ [AMS でパッチメンテナンスウィンドウを作成する](acc-p-maint-window.md)
+ [フックを使用したパッチ](acc-p-hooks.md)
+ [AMS Accelerate パッチベースライン](acc-patch-baseline.md)
+ [AMS Accelerate のオンデマンドパッチ適用用の IAM ロールの作成](acc-p-user-access.md)
+ [AMS Accelerate のパッチ通知とパッチ障害を理解する](acc-patch-mon-remediate.md)

## パッチ適用に関する推奨事項
<a name="acc-patching-recos"></a>

アプリケーションやインフラストラクチャの運用に携わっている方なら、アプリケーションチームからの多様な要件に対応できる柔軟性と拡張性を備えたオペレーティングシステム (OS) パッチソリューションの重要性を理解していることでしょう。一般的な組織では、不変インスタンスを含むアーキテクチャを使用するアプリケーションチームもあれば、可変インスタンスにアプリケーションをデプロイするアプリケーションチームもあります。

パッチ適用に関する AWS 規範ガイダンスの詳細については、[「 を使用したハイブリッドクラウドのミュータブルインスタンスの自動パッチ適用 AWS Systems Manager](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/welcome.html)」を参照してください。

**注記**  
Accelerate Patch アドオンは、AMS インスタンスにタグベースのパッチを適用する機能です。( AWS Systems Manager SSM) 機能を利用すると、インスタンスにタグを付け、設定したベースラインとウィンドウを使用してそれらのインスタンスにパッチを適用できます。AMS Accelerate Patch アドオンはオンボーディングオプションです。 Accelerate アカウントのオンボーディング中に取得しなかった場合は、クラウドサービスデリバリーマネージャー (CSDM) に連絡して取得してください。

### パッチ責任に関する推奨事項
<a name="patch-recos-responsibilities"></a>

永続インスタンスのパッチ適用プロセスには、次のチームとアクションが必要です。
+ **アプリケーション (DevOps) チームは**、アプリケーション環境、OS タイプ、またはその他の基準に基づいてサーバーのパッチグループを定義します。また、各パッチグループ固有のメンテナンスウィンドウも定義します。この情報は、インスタンスにアタッチされたタグに保存する必要があります。推奨されるタグ名は「パッチグループ」と「メンテナンスウィンドウ」です。各パッチサイクル中、アプリケーションチームはパッチ適用の準備、パッチ適用後のアプリケーションのテスト、パッチ適用中のアプリケーションと OS の問題のトラブルシューティングを行います。
+ **セキュリティオペレーションチームは**、アプリケーションチームが使用するさまざまな OS タイプのパッチベースラインを定義し、Systems Manager Patch Manager を通じてパッチを利用できるようにします。
+ **自動パッチソリューションは**定期的に実行され、ユーザー定義のパッチグループとメンテナンスウィンドウに基づいて、パッチベースラインで定義されたパッチをデプロイします。
+ **ガバナンスチームとコンプライアンスチームは**、パッチ適用ガイドラインと例外プロセスとメカニズムを定義します。

詳細については、[「ミュータブル EC2 インスタンスのパッチソリューション設計](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/design-standard.html)」を参照してください。

### アプリケーションチーム向けガイダンス
<a name="patch-recos-app-teams"></a>
+ メンテナンスウィンドウの作成と管理を確認し、理解してください。詳細については、[AWS Systems Manager 「メンテナンスウィンドウ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html)」と[「パッチ適用用の SSM メンテナンスウィンドウの作成](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-patching.html#acc-p-maint-window)」を参照してください。メンテナンスウィンドウの一般的な構造と使用方法を理解すると、メンテナンスウィンドウを作成しているユーザーでない場合に提供する情報を理解するのに役立ちます。
+ 高可用性 (HA) セットアップの場合、アベイラビリティーゾーンと環境 (Dev/Test/Prod) ごとに 1 つのメンテナンスウィンドウを計画します。これにより、パッチ適用中の可用性が維持されます。
+ 推奨されるメンテナンスウィンドウ期間は 4 時間で、カットオフは 1 時間、さらにインスタンス 50 個あたり 1 時間です。
+ 開発バージョンとテストバージョンに、本番稼働用パッチ適用の前に潜在的な問題を特定できるように、各バージョンの間に十分な時間をかけてパッチを適用します。
+ SSM オートメーションを使用してパッチ適用前後の一般的なタスクを自動化し、メンテナンスウィンドウタスクとして実行します。パッチ後のタスクでは、カットオフに達するとタスクは起動しないため、十分な時間が割り当てられていることを確認する必要があります。
+ パッチベースラインとその機能、特に、開発/テストで適用されたパッチのみが後日本番環境で適用されるようにするために使用できるパッチ重要度タイプの自動承認の遅延について知識を深めてください。詳細については、[「パッチベースラインについて](https://docs.aws.amazon.com/systems-manager/latest/userguide/about-patch-baselines.html)」を参照してください。

### セキュリティ運用チーム向けのガイダンス
<a name="patch-recos-sec-ops-teams"></a>
+ パッチベースラインを確認し、理解します。パッチの承認は自動化された方法で処理され、さまざまなルールオプションがあります。詳細については、[「パッチベースラインについて](https://docs.aws.amazon.com/systems-manager/latest/userguide/about-patch-baselines.html)」を参照してください。
+ Dev/Test/Prod へのパッチ適用に関するニーズをアプリケーションチームと話し合い、 これらのニーズに合わせて複数のベースラインを作成します。

### ガバナンスチームとコンプライアンスチームのガイダンス
<a name="patch-recos-gov-comp-teams"></a>
+ パッチ適用は「オプトアウト」関数である必要があります。パッチが適用されないように、デフォルトのメンテナンスウィンドウと自動タグ付けが存在する必要があります。AMS Resource Tagger はこれに役立ちます。このオプションについては、クラウドアーキテクト (CA) またはクラウドサービスデリバリーマネージャー (CSDM) と話し合い、実装に関するガイダンスを得てください。
+ パッチ適用の免除をリクエストするには、免除を正当化するドキュメントが必要です。最高情報セキュリティ責任者 (CISO) またはその他の承認担当者は、リクエストを承認または拒否する必要があります。
+ パッチコンプライアンスは、Patch Manager コンソール、Security Hub、または脆弱性スキャナーを介して定期的に確認する必要があります。

### 高可用性 Windows アプリケーションの設計例
<a name="patch-ex-design-ha-win-app"></a>

 ![\[Patch Tuesday schedule showing development, test, and production environments with baseline approval timelines.\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/accelerate-guide/images/acc-maint-window.png) 

**概要：**
+ AZ ごとに 1 つのメンテナンスウィンドウ。
+ 環境ごとに 1 セットのメンテナンスウィンドウ。
+ 環境ごとに 1 つのパッチベースライン:
  + 開発: 0 日後にすべての重要度と分類を承認します。
  + テスト: 0 日後に重要なセキュリティ更新 パッチを承認し、7 日後に他のすべての重要度と分類を承認します。
  + 製品: 0 日後に重要なセキュリティ更新パッチ を承認し、14 日後に他のすべての重要度と分類を承認します。

**CloudFormation スクリプト:**

これらのスクリプトは、上記のベースライン承認設定を使用して、2 つのアベイラビリティーゾーン Windows HA EC2 アプリケーションのメンテナンスウィンドウ、ベースライン、パッチ適用タスクを構築するように設定されています。
+ Windows 開発 CFN スタックの例：  [HA-Patching-Dev-Stack.json](samples/HA-Patching-Dev-Stack.zip)
+ Windows テスト CFN スタックの例：  [HA-Patching-Test-Stack.json](samples/HA-Patching-Test-Stack.zip)
+ Windows Prod CFN スタックの例：  [HA-Patching-Prod-Stack.json](samples/HA-Patching-Prod-Stack.zip)

### パッチレコメンデーションFAQs
<a name="patch-recos-faq"></a>

Q: 「0」日間のエクスプロイトに対して予定外のパッチ適用を処理するにはどうすればよいですか?

A: SSM は、インスタンスの OS の現在のデフォルトベースラインを使用する **Patch Now** 機能をサポートしています。AMS は、0 日後にすべてのパッチを承認するパッチベースラインのデフォルトセットをデプロイします。ただし、**Patch Now** 機能を使用する場合、このコマンドは AWS-RunPatchBaseline SSM ドキュメントを実行するため、パッチ前のスナップショットは作成されません。パッチを適用する前に、手動バックアップを取ることをお勧めします。

Q: AMS は Auto Scaling Group (ASGs) のインスタンスのパッチ適用をサポートしていますか?

A: いいえ。現時点では、ASG パッチ適用は Accelerate のお客様ではサポートされていません。

Q: メンテナンスウィンドウに留意すべき制限はありますか?

A: はい、注意すべき制限がいくつかあります。
+ アカウントあたりのメンテナンスウィンドウ: 50
+ メンテナンスウィンドウあたりのタスク数: 20
+ メンテナンスウィンドウあたりの同時オートメーションの最大数: 20
+ 同時メンテナンスウィンドウの最大数: 5

デフォルトの SSM 制限の完全なリストについては、 [AWS Systems Manager 「 エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/ssm.html)」を参照してください。