EC2 インスタンスの露出の修正

AWS Security Hub は、Amazon Elastic Compute Cloud (EC2) インスタンスの公開結果を生成できます。

Security Hub コンソールでは、公開結果に関連する EC2 インスタンスとその識別情報が、検出結果の詳細のリソースセクションに一覧表示されます。プログラムでは、Security Hub API の GetFindingsV2オペレーションを使用してリソースの詳細を取得できます。

露出検出結果に関連するリソースを特定したら、不要なリソースを削除できます。不要なリソースを削除すると、露出プロファイルと AWS コストを削減できます。リソースが不可欠な場合は、以下の推奨される修復手順に従ってリスクを軽減します。修復トピックは、特性のタイプに基づいて分割されます。

1 つの公開結果には、複数の修復トピックで特定された問題が含まれます。逆に、1 つの修復トピックだけに対処することで、露出の検出結果に対処し、その重要度レベルを下げることができます。リスク修復へのアプローチは、組織の要件とワークロードによって異なります。

注記

このトピックで提供される修復ガイダンスでは、他の AWS リソースで追加の相談が必要になる場合があります。

目次

• EC2 インスタンスの設定ミス特性

  • EC2 インスタンスは、バージョン 1 を使用して IMDS へのアクセスを許可します

  • Amazon EC2 インスタンスに関連付けられた IAM ロールには管理アクセスポリシーがあります

  • Amazon EC2 インスタンスに関連付けられた IAM ロールにはサービス管理者ポリシーがあります

  • Amazon EC2 インスタンスに、SSH または RDP アクセスを許可するセキュリティグループまたはネットワーク ACL がある

  • Amazon EC2 インスタンスにオープンセキュリティグループがある

  • Amazon EC2 インスタンスにパブリック IP アドレスがある

• EC2 インスタンスの到達可能性特性

  • EC2 インスタンスにはインターネット経由でアクセスできます。

  • Amazon EC2 インスタンスは Amazon VPC 内で到達可能

• EC2 インスタンスの脆弱性特性

  • EC2 インスタンスには、悪用の可能性が高いネットワークで悪用可能なソフトウェアの脆弱性があります

  • Amazon EC2 インスタンスにソフトウェアの脆弱性がある

EC2 インスタンスの設定ミス特性

EC2 インスタンスの設定ミスの特徴と推奨される修復手順は次のとおりです。

EC2 インスタンスは、バージョン 1 を使用して IMDS へのアクセスを許可します

インスタンスメタデータは、実行中のインスタンスを設定または管理するためにアプリケーションが使用できる Amazon EC2 インスタンスに関するデータです。インスタンスメタデータサービス (IMDS) は、インスタンス上のコードによって、インスタンスメタデータに安全にアクセスするために使用されるインスタンス上のコンポーネントです。IMDS が適切に保護されていない場合、一時的な認証情報やその他の機密設定データにアクセスできるため、潜在的な攻撃ベクトルになる可能性があります。IMDSv2 は、セッション指向認証による悪用に対する保護を強化し、メタデータリクエストにセッショントークンを必要とし、セッション期間を制限します。標準のセキュリティ原則に従って、 では、IMDSv2 を使用し、IMDSv1 を無効にするように Amazon EC2 インスタンスを設定する AWS ことをお勧めします。 IMDSv2 IMDSv1

アプリケーションの互換性をテストする

IMDSv2 を実装する前に、インスタンスをテストして IMDSv2 との互換性を確認します。一部のアプリケーションまたはスクリプトでは、コア機能に IMDSv1 が必要で、追加の設定が必要になる場合があります。アプリケーションの互換性をテストするためのツールと推奨パスの詳細については、「Amazon Elastic Compute Cloud ユーザーガイド」の「インスタンスメタデータサービスバージョン 2 の使用への移行」を参照してください。

IMDSv2 を使用するようにインスタンスを更新する

IMDSv2 を使用するように既存のインスタンスを変更します。詳細については、「Amazon Elastic Compute Cloud ユーザーガイド」の「既存のインスタンスのインスタンスメタデータオプションを変更する」を参照してください。

Auto Scaling グループのインスタンスに更新を適用する

インスタンスが Auto Scaling グループの一部である場合は、起動テンプレートまたは起動設定を新しい設定で更新し、インスタンスの更新を実行します。

Amazon EC2 インスタンスに関連付けられた IAM ロールには管理アクセスポリシーがあります

管理アクセスポリシーは、Amazon EC2 インスタンスに AWS のサービス および リソースへの広範なアクセス許可を提供します。これらのポリシーには通常、インスタンス機能に必要のないアクセス許可が含まれます。Amazon EC2 インスタンスで (インスタンスプロファイルにアタッチされたロールが必要とする最小限のアクセス許可のセットではなく) IAM アイデンティティに管理アクセスポリシーを提供することで、Amazon EC2 インスタンスが侵害された場合に攻撃の範囲を広げることができます。インスタンスが侵害された場合、攻撃者はこれらの過剰なアクセス許可を利用して、環境を横切って移動したり、データにアクセスしたり、リソースを操作したりする可能性があります。標準のセキュリティ原則に従って、最小権限を付与することをお勧めします。つまり、タスクの実行に必要なアクセス許可のみを付与します。

管理ポリシーの確認と識別

IAM ダッシュボードで、ロール名を持つロールを見つけます。IAM ロールにアタッチされているアクセス許可ポリシーを確認します。ポリシーが AWS マネージドポリシーの場合は、 AdministratorAccessまたは を探しますIAMFullAccess。それ以外の場合は、ポリシードキュメントで、"Effect": "Allow", "Action": "*"、、および を含むステートメントを探します"Resource": "*"。

最小特権アクセスの実装

管理ポリシーを、インスタンスが機能するために必要な特定のアクセス許可のみを付与するポリシーに置き換えます。IAM ロールのセキュリティのベストプラクティスの詳細については、AWS Identity and Access Management 「 ユーザーガイド」の「セキュリティのベストプラクティス」の「最小特権のアクセス許可を適用する」を参照してください。不要なアクセス許可を特定するには、IAM Access Analyzer を使用して、アクセス履歴に基づいてポリシーを変更する方法を理解します。詳細については、「 AWS Identity and Access Management ユーザーガイド」の「外部アクセスと未使用のアクセスの検出結果」を参照してください。または、新しい IAM ロールを作成して、既存のロールを使用して他のアプリケーションに影響を与えないようにすることもできます。このシナリオでは、新しい IAM ロールを作成し、新しい IAM ロールをインスタンスに関連付けます。インスタンスの IAM ロールを置き換える手順については、「Amazon Elastic Compute Cloud ユーザーガイド」の「インスタンスに IAM ロールをアタッチする」を参照してください。

安全な設定に関する考慮事項

インスタンスにサービスレベルの管理権限が必要な場合は、リスクを軽減するためにこれらの追加のセキュリティコントロールを実装することを検討してください。

• 安全な設定に関する考慮事項

  • 多要素認証 (MFA) – MFA は、追加の形式の認証を要求することで、セキュリティレイヤーを追加します。これにより、認証情報が侵害された場合でも、不正アクセスを防ぐことができます。詳細については、AWS Identity and Access Management 「 ユーザーガイド」の「多要素認証 (MFA) を要求する」を参照してください。

  • IAM 条件 – 条件要素を設定すると、ソース IP や MFA の経過時間などの要因に基づいて、管理アクセス許可をいつ、どのように使用できるかを制限できます。詳細については、「 AWS Identity and Access Management ユーザーガイド」の「IAM ポリシーの条件を使用してアクセスをさらに制限する」を参照してください。

  • アクセス許可の境界 — アクセス許可の境界は、ロールが持つことができる最大アクセス許可を確立し、管理アクセスを持つロールのガードレールを提供します。詳細については、「 ユーザーガイド」の「アクセス許可の境界を使用してアカウント内のアクセス許可管理を委任する」を参照してください。 AWS Identity and Access Management

自動スケーリンググループのインスタンスに更新を適用する

AWS 自動スケーリンググループの Amazon EC2 インスタンスの場合、新しいインスタンスプロファイルを使用して起動テンプレートまたは起動設定を更新し、インスタンスの更新を実行します。起動テンプレートの更新の詳細については、「Amazon Elastic Compute Cloud ユーザーガイド」の「起動テンプレートの変更 (起動テンプレートのバージョンの管理）」を参照してください。詳細については、「インスタンスの更新を使用して Auto Scaling グループのインスタンスを更新する」を参照してください。Auto Scaling グループで IAM ロールを使用する方法の詳細については、Amazon EC2 Auto Scaling ユーザーガイド」の「Amazon EC2 インスタンスで実行されるアプリケーションの IAM ロールAuto Scaling Amazon EC2」を参照してください。

Amazon EC2 インスタンスに関連付けられた IAM ロールにはサービス管理者ポリシーがあります

サービスアクセスポリシーは、Amazon EC2 インスタンスに AWS サービスとリソースへの広範なアクセス許可を提供します。これらのポリシーには通常、インスタンス機能に必要のないアクセス許可が含まれます。インスタンスプロファイルにアタッチされたロールが必要とする最小限のアクセス許可セットではなく、IAM ID に Amazon EC2 インスタンスの管理アクセスポリシーを提供することで、インスタンスが侵害された場合に攻撃の範囲を広げることができます。標準のセキュリティ原則に従って、最小権限を付与することをお勧めします。つまり、タスクの実行に必要なアクセス許可のみを付与します。

管理ポリシーの確認と識別

IAM ダッシュボードで、ロール名を持つロールを見つけます。IAM ロールにアタッチされているアクセス許可ポリシーを確認します。ポリシーが AWS マネージドポリシーの場合は、 AdministratorAccessまたは を探しますIAMFullAccess。それ以外の場合は、ポリシードキュメントで、"Effect": "Allow", "Action": "*"、、および を含むステートメントを探します"Resource": "*"。

最小特権アクセスの実装

サービス管理者ポリシーを、インスタンスが機能するために必要な特定のアクセス許可のみを付与するポリシーに置き換えます。IAM ロールのセキュリティのベストプラクティスの詳細については、AWS Identity and Access Management 「 ユーザーガイド」の「セキュリティのベストプラクティス」の「最小特権のアクセス許可を適用する」を参照してください。不要なアクセス許可を特定するには、IAM Access Analyzer を使用して、アクセス履歴に基づいてポリシーを変更する方法を理解します。詳細については、「 AWS Identity and Access Management ユーザーガイド」の「外部アクセスと未使用のアクセスの検出結果」を参照してください。または、新しい IAM ロールを作成して、既存のロールを使用している他のアプリケーションに影響を与えないようにすることもできます。このシナリオでは、新しい IAM ロールを作成し、新しい IAM ロールをインスタンスに関連付けます。インスタンスの IAM ロールの置き換えについては、「Amazon Elastic Compute Cloud ユーザーガイド」の「インスタンスに IAM ロールをアタッチする」を参照してください。

安全な設定に関する考慮事項

インスタンスにサービスレベルの管理権限が必要な場合は、リスクを軽減するためにこれらの追加のセキュリティコントロールを実装することを検討してください。

安全な設定に関する考慮事項

インスタンスにサービスレベルの管理権限が必要な場合は、リスクを軽減するためにこれらの追加のセキュリティコントロールを実装することを検討してください。

• 多要素認証 (MFA) – MFA は、追加の形式の認証を要求することで、セキュリティレイヤーを追加します。これにより、認証情報が侵害された場合でも、不正アクセスを防ぐことができます。詳細については、「 AWS Identity and Access Management ユーザーガイド」の「多要素認証 (MFA) を要求する」を参照してください。

• IAM 条件 – 条件要素を設定すると、ソース IP や MFA の経過時間などの要因に基づいて、管理アクセス許可をいつ、どのように使用できるかを制限できます。詳細については、「 AWS Identity and Access Management ユーザーガイド」の「IAM ポリシーの条件を使用してアクセスをさらに制限する」を参照してください。

• アクセス許可の境界 – アクセス許可の境界は、ロールが持つことができる最大アクセス許可を確立し、管理アクセスを持つロールのガードレールを提供します。詳細については、「 ユーザーガイド」の「アクセス許可の境界を使用してアカウント内のアクセス許可管理を委任する」を参照してください。 AWS Identity and Access Management

Auto Scaling グループのインスタンスに更新を適用する

AWS 自動スケーリンググループの Amazon EC2 インスタンスの場合、新しいインスタンスプロファイルを使用して起動テンプレートまたは起動設定を更新し、インスタンスの更新を実行します。起動テンプレートの更新については、「Amazon Elastic Compute Cloud ユーザーガイド」の「起動テンプレートの変更 (起動テンプレートのバージョンの管理）」を参照してください。詳細については、「インスタンスの更新を使用して Auto Scaling グループのインスタンスを更新する」を参照してください。Auto Scaling グループで IAM ロールを使用する方法の詳細については、Amazon EC2 Auto Scaling ユーザーガイド」の「Amazon EC2 インスタンスで実行されるアプリケーションの IAM ロールAuto Scaling Amazon EC2」を参照してください。

Amazon EC2 インスタンスに、SSH または RDP アクセスを許可するセキュリティグループまたはネットワーク ACL がある

SSH や RDP などのリモートアクセスプロトコルを使用すると、ユーザーは外部の場所から Amazon EC2 インスタンスに接続および管理できます。セキュリティグループがインターネットからのこれらのプロトコルへの無制限アクセスを許可すると、インスタンスへのインターネットアクセスを許可することで、Amazon EC2 インスタンスのアタックサーフェスが増加します。標準のセキュリティ原則に従って、 では、リモートアクセスを信頼できる特定の IP アドレスまたは範囲に制限 AWS することをお勧めします。

1. セキュリティグループルールを変更する

   Amazon EC2 インスタンスへのアクセスを特定の信頼された IP アドレスに制限します。SSH および RDP アクセスを特定の信頼できる IP アドレスに制限するか、CIDR 表記を使用して IP 範囲 (198.168.1.0/24 など) を指定します。セキュリティグループルールを変更するには、「Amazon Elastic Compute Cloud ユーザーガイド」の「セキュリティグループルールの設定」を参照してください。

Amazon EC2 インスタンスにオープンセキュリティグループがある

セキュリティグループはAmazon EC2 インスタンスの仮想ファイアウォールとして機能し、インバウンドトラフィックとアウトバウンドトラフィックを制御します。任意の IP アドレスからの無制限のアクセスを許可するオープンセキュリティグループは、インスタンスを不正アクセスにさらす可能性があります。標準のセキュリティ原則に従って、 はセキュリティグループアクセスを特定の IP アドレスとポートに制限 AWS することをお勧めします。

セキュリティグループのルールを確認し、現在の設定を評価する

などの幅広い IP 範囲からオープンおよびアクセス可能なポートを評価します(0.0.0.0/0 or ::/0)。セキュリティグループの詳細を表示する手順については、「Porting Assistant for .NET API Reference」の「DescribeSecurityGroups」を参照してください。

セキュリティグループルールを変更する

セキュリティグループのルールを変更して、特定の信頼された IP アドレスまたは範囲へのアクセスを制限します。セキュリティグループルールを更新するときは、必要なソース IP 範囲ごとにルールを作成するか、特定のポートへのアクセスを制限することで、異なるネットワークセグメントのアクセス要件を分離することを検討してください。セキュリティグループルールを変更するには、Amazon EC2 ユーザーガイド」の「セキュリティグループルールの設定」を参照してください。

Amazon EC2 インスタンスにパブリック IP アドレスがある

パブリック IP アドレスを持つ Amazon EC2 インスタンスは、インターネットからパブリックにアクセスできます。外部顧客にサービスを提供するインスタンスにはパブリック IP アドレスが必要になる場合がありますが、これは不正なプリンシパルを攻撃することで潜在的なものとして使用できます。は、標準のセキュリティ原則に従って、可能な場合はリソースの公開を制限することを AWS 推奨しています。

インスタンスをプライベートサブネットに移動する

インスタンスが直接インターネットアクセスを必要としない場合は、VPC 内のプライベートサブネットに移動することを検討してください。これにより、パブリック IP アドレスが削除され、VPC 内の他のリソースと通信できるようになります。詳細については、 AWS ナレッジセンターのAmazon EC2 インスタンスを別のサブネット、アベイラビリティーゾーン、または VPC に移動するにはどうすればよいですか？」を参照してください。

パブリック IP アドレスなしで起動するようにインスタンスを設定する

インスタンスがパブリック IP アドレスを必要としないパブリックサブネットで起動された場合、パブリック IP アドレスの自動割り当てを防ぐために起動設定を変更できます。これは、サブネットレベルまたは個々のインスタンスを起動するときに無効にできます。詳細については、Amazon Virtual Private Cloud ユーザーガイド」の「サブネットの IP アドレス属性の変更」および「Amazon Elastic Compute Cloud ユーザーガイド」の「Amazon EC2instance IP アドレス指定」を参照してください。

代替アクセス方法

代替アクセス方法には、次のオプションを検討してください。

• アウトバウンドインターネット接続に NAT ゲートウェイを使用する –

  インターネットへのアクセス (更新のダウンロードなど) を必要とするプライベートサブネット内のインスタンスの場合、パブリック IP アドレスを割り当てる代わりに NAT ゲートウェイを使用することを検討してください。NAT Gateway を使用すると、プライベートサブネットのインスタンスは、インターネットからのインバウンド接続を防止しながら、インターネットへのアウトバウンド接続を開始できます。詳細については、「Amazon Virtual Private Cloud ユーザーガイド」の「NAT ゲートウェイ」を参照してください。 Amazon Virtual Private Cloud

• Elastic Load Balancing を使用する – ウェブアプリケーションを実行しているインスタンスの場合は、Elastic Load Balancer (LB) の使用を検討してください。LBs は、LB がパブリックサブネットで実行され、インターネットトラフィックを処理する間に、インスタンスがプライベートサブネットで実行されるように設定できます。詳細については、ELB ユーザーガイドのElastic Load Balancing AWSとは」を参照してください。LB の維持戦略を選択する方法については、「規範ガイダンス」の「ロードバランサーサブネット」を参照してください。 AWS

EC2 インスタンスの到達可能性特性

EC2 インスタンスの到達可能性特性と推奨される修復手順は次のとおりです。

EC2 インスタンスにはインターネット経由でアクセスできます。

インターネットゲートウェイ (Application Load Balancer または Classic Load Balancer の背後にあるインスタンスを含む）、VPC ピアリング接続、または VPN 仮想ゲートウェイを介してインターネットから到達可能なポートを持つ Amazon EC2 インスタンスは、インスタンスをインターネットに公開することがあります。標準のセキュリティ原則に従い、インバウンドトラフィックを必要なソースとポートのみに制限して、最小特権のネットワークアクセスコントロールを実装することをお勧めします。

セキュリティグループルールの変更または削除

リソースタブで、Amazon EC2 セキュリティグループのリソースを開きます。インスタンスが機能するためにインターネットアクセスが必要かどうかを確認します。無制限のアクセスを許可するインバウンドセキュリティグループルールを変更または削除します (0.0.0.0/0 または ::/0）。特定の IP 範囲またはセキュリティグループに基づいて、より制限の厳しいルールを実装します。制限されたパブリックアクセスが必要な場合は、インスタンスの 関数に必要な特定のポートとプロトコルへのアクセスを制限します。セキュリティグループルールを管理する手順については、Amazon EC2 ユーザーガイド」の「セキュリティグループルールの設定」を参照してください。

ネットワーク ACLs を更新する

インスタンスのサブネットに関連付けられたネットワークアクセスコントロールリスト (ACLs) を確認して変更します。ACL 設定がセキュリティグループの変更と一致しており、意図せずにパブリックアクセスを許可していないことを確認します。ネットワーク ACLs「Amazon VPC ユーザーガイド」の「ネットワーク ACLs」を参照してください。

代替アクセス方法

代替アクセス方法には、次のオプションを検討してください。

• アウトバウンドインターネット接続に NAT Gateway を使用する – インターネットへのアクセスを必要とする (更新をダウンロードするなど) プライベートサブネット内のインスタンスの場合、パブリック IP アドレスを割り当てる代わりに NAT Gateway を使用することを検討してください。NAT Gateway を使用すると、プライベートサブネットのインスタンスはインターネットからのインバウンド接続を防止しながら、インターネットへのアウトバウンド接続を開始できます。

• Systems Manager Session Manager を使用する – Session Manager は、インバウンドポート、SSH キーの管理、踏み台ホストの維持を必要とせずに、Amazon EC2 インスタンスへの安全なシェルアクセスを提供します。

• WAF と Elastic Load Balancing または Application Load Balancer を使用する – ウェブアプリケーションを実行しているインスタンスの場合は、LB を AWS ウェブアプリケーションファイアウォール (WAF) と組み合わせて使用することを検討してください。LBs は、LB がパブリックサブネットで実行され、インターネットトラフィックを処理する間に、インスタンスがプライベートサブネットで実行されるように設定できます。WAF をロードバランサーに追加すると、ウェブエクスプロイトやボットに対する保護を強化できます。

Amazon EC2 インスタンスは Amazon VPC 内で到達可能

Amazon Virtual Private Cloud (Amazon VPC) を使用すると、定義された仮想ネットワークで AWS リソースを起動できます。インスタンス間の無制限のアクセスを許可する Amazon VPC ネットワーク設定は、インスタンスが侵害された場合に攻撃の範囲を広げる可能性があります。セキュリティのベストプラクティスに従って、 はサブネットおよびセキュリティグループレベルでのネットワークセグメンテーションと最小特権のアクセスコントロールの実装 AWS を推奨します。

Amazon VPC ネットワーク接続パターンを確認する

公開結果で、ARN のセキュリティグループ ID を特定します。相互に通信する必要があるインスタンスとポートを特定します。Amazon VPC フローログを使用して Amazon VPC 内の既存のトラフィックパターンを分析し、使用されているポートを特定できます。

セキュリティグループルールを変更する

セキュリティグループのルールを変更して、特定の信頼された IP アドレスまたは範囲へのアクセスを制限します。たとえば、VPC CIDR 範囲全体 (10.0.0.0/16 など) からのすべてのトラフィックを許可する代わりに、特定のセキュリティグループまたは IP 範囲へのアクセスを制限します。セキュリティグループルールを更新するときは、必要なソース IP 範囲ごとにルールを作成するか、特定のポートへのアクセスを制限することで、異なるネットワークセグメントのアクセス要件を分離することを検討してください。セキュリティグループルールを変更するには、「Amazon EC2Userユーザーガイド」の「セキュリティグループルールの設定」を参照してください。

セキュリティ要件または機能に基づいて Amazon VPC リソースをサブネットに整理することを検討してください。たとえば、ウェブサーバーとデータベースサーバーを別々のサブネットに配置します。詳細については、「Amazon Virtual Private Cloud ユーザーガイド」の「VPC のサブネット」を参照してください。 Amazon Virtual Private Cloud

サブネットレベルの保護用にネットワーク ACLs を設定する

ネットワークアクセスコントロールリスト (NACLsは、サブネットレベルで追加のセキュリティレイヤーを提供します。セキュリティグループとは異なり、NACLs はステートレスであり、インバウンドルールとアウトバウンドルールの両方を明示的に定義する必要があります。詳細については、Amazon Virtual Private Cloud ユーザーガイド」の「ネットワークアクセスコントロールリストを使用してサブネットトラフィックを制御する」を参照してください。

その他の考慮事項

Amazon VPC へのアクセスを制限するときは、次の点を考慮してください。

• 制限付きルーティングによる Transit Gateway または Amazon VPC ピアリング – アーキテクチャで通信する必要がある複数の VPCs を使用している場合は、 AWS Transit Gateway と Amazon VPC ピアリングを使用して Amazon VPCs 間の接続を提供しながら、どのサブネットが相互に通信できるかを制御できるようにすることを検討してください。詳細については、「Amazon VPC Transit Gateway と VPC ピアリング接続の使用を開始する」を参照してください。 https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html

• サービスエンドポイントとプライベートリンク – Amazon VPC エンドポイントを使用して、トラフィックを AWS ネットワーク内に保持し、インターネット経由ではなく AWS リソースと通信できます。これにより、同じサービスにアクセスするインスタンス間の直接接続の必要性が軽減されます。VPC エンドポイントの詳細については、「Amazon Virtual Private Cloud ユーザーガイド」の「Amazon VPC エンドポイントとは」を参照してください。 Amazon Virtual Private Cloud 他の Amazon VPCs、 の使用を検討してください AWS PrivateLink。

EC2 インスタンスの脆弱性特性

EC2 インスタンスの脆弱性特性と推奨される修復手順は次のとおりです。

EC2 インスタンスには、悪用の可能性が高いネットワークで悪用可能なソフトウェアの脆弱性があります

EC2 インスタンスにインストールされているソフトウェアパッケージは、共通脆弱性識別子 (CVEs) に公開できます。重要な CVEs AWS 、環境に重大なセキュリティリスクをもたらします。認可されていないプリンシパルは、これらのパッチが適用されていない脆弱性を悪用して、データの機密性、完全性、可用性を侵害したり、他のシステムにアクセスしたりする可能性があります。エクスプロイトコードはすでに公開されており、攻撃者や自動スキャンツールによってアクティブに使用されている可能性があるため、エクスプロイトの可能性の高い重大な脆弱性は即時のセキュリティ脅威を表します。インスタンスを保護するために、これらの脆弱性にパッチを適用することをお勧めします。

影響を受けるインスタンスを更新する

特性の脆弱性タブの「リファレンス」セクションを確認します。ベンダーのドキュメントには、特定の修復ガイダンスが含まれている場合があります。これらの一般的なガイドラインを使用して、適切な修復に従ってください。

Systems Manager Patch Manager を使用して、オペレーティングシステムとアプリケーションの両方にパッチを適用します。Patch Manager は、オペレーティングシステムとソフトウェアパッチを自動的に大規模なインスタンスグループに選択してデプロイするのに役立ちます。Patch Manager を設定していない場合は、影響を受ける各インスタンスのオペレーティングシステムを手動で更新します。

ベンダーの推奨手順に従って、影響を受けるアプリケーションを最新の安全なバージョンに更新します。複数のインスタンスでアプリケーションの更新を管理するには、Systems Manager ステートマネージャーを使用してソフトウェアを一貫した状態に保つことを検討してください。更新が利用できない場合は、パッチがリリースされるか、アプリケーションへのネットワークアクセスの制限や脆弱な機能の無効化などのその他の緩和策が行われるまで、脆弱なアプリケーションを削除または無効化することを検討してください。

Amazon Inspector の検出結果に記載されている特定の修復アドバイスに従ってください。これには、セキュリティグループルールの変更、インスタンス設定の変更、アプリケーション設定の調整が含まれる場合があります。

インスタンスが Auto Scaling グループの一部であるかどうかを確認します。AMI 置換パッチ適用は、Auto Scaling グループに新しい Amazon EC2 インスタンスをデプロイするように設定された AMI ID を更新することで、イミュータブルなインフラストラクチャで行われます。カスタム/ゴールデン AMI を使用している場合は、新しい AMI でインスタンスを作成し、インスタンスをカスタマイズして新しいゴールデン AMI を作成します。詳細については、「AMI の更新パッチ適用 (Auto Scaling グループのパッチ適用された AMIs を使用）」を参照してください。

今後の考慮事項

今後の発生を防ぐには、脆弱性管理プログラムの実装を検討してください。Amazon Inspector は、インスタンスで CVEs を自動的にスキャンするように設定できます。Amazon Inspector は、自動修復のために Security Hub と統合することもできます。Systems Manager メンテナンスウィンドウを使用して定期的なパッチ適用スケジュールを実装し、インスタンスの中断を最小限に抑えることを検討してください。

Amazon EC2 インスタンスにソフトウェアの脆弱性がある

Amazon EC2instancesにインストールされているソフトウェアパッケージは、共通脆弱性識別子 (CVEs) に公開される可能性があります。重要でない CVEsは、重要な CVEs と比較して重要度や悪用可能性が低いセキュリティの弱点を表します。これらの脆弱性は差し迫ったリスクが少なくなりますが、攻撃者はパッチが適用されていないこれらの脆弱性を悪用してデータの機密性、完全性、可用性を侵害したり、他のシステムにアクセスしたりできます。セキュリティのベストプラクティスに従って、 は、インスタンスを攻撃から保護するために、これらの脆弱性にパッチを適用 AWSすることをお勧めします。

影響を受けるインスタンスを更新する

AWS Systems Manager Patch Manager を使用して、オペレーティングシステムにパッチを適用します。Patch Manager は、オペレーティングシステムとソフトウェアパッチを自動的に選択して大規模なインスタンスグループにデプロイするのに役立ちます。Patch Manager を設定していない場合は、影響を受ける各インスタンスのオペレーティングシステムを手動で更新します。

ベンダーの推奨手順に従って、影響を受けるアプリケーションを最新の安全なバージョンに更新します。複数のインスタンスでアプリケーションの更新を管理するには、 AWS Systems Manager ステートマネージャーを使用してソフトウェアを一貫した状態に保つことを検討してください。更新が利用できない場合は、パッチがリリースされるか、アプリケーションへのネットワークアクセスの制限や脆弱な機能の無効化などのその他の緩和策が行われるまで、脆弱なアプリケーションを削除または無効化することを検討してください。

Amazon Inspector の検出結果に記載されている特定の修復アドバイスに従ってください。これには、セキュリティグループルールの変更、インスタンス設定の変更、アプリケーション設定の調整が含まれる場合があります。

インスタンスが Auto Scaling グループの一部であるかどうかを確認します。AMI 置換パッチ適用は、Auto Scaling グループに新しい Amazon EC2 インスタンスをデプロイするように設定された AMI ID を更新することで、イミュータブルなインフラストラクチャで行われます。カスタム/ゴールデン AMI を使用している場合は、新しい AMI でインスタンスを作成し、インスタンスをカスタマイズして新しいゴールデン AMI を作成します。詳細については、「AMI の更新パッチ適用 (Auto Scaling グループのパッチ適用された AMIs を使用）」を参照してください。

今後の考慮事項

今後の発生を防ぐには、脆弱性管理プログラムの実装を検討してください。Amazon Inspector は、インスタンスで CVEs を自動的にスキャンするように設定できます。Amazon Inspector は、自動修復のために Security Hub と統合することもできます。Systems Manager メンテナンスウィンドウを使用して定期的なパッチ適用スケジュールを実装し、インスタンスの中断を最小限に抑えることを検討してください。