GuardDuty によって検出されたセキュリティ問題の修復 - Amazon GuardDuty

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

GuardDuty によって検出されたセキュリティ問題の修復

Amazon GuardDuty はの結果これは、潜在的なセキュリティ問題を示します。このリリースの GuardDuty におけるセキュリティ問題は、AWS 環境の侵害された EC2 インスタンスまたは侵害された認証情報セットを示します。以下のセクションでは、これらのシナリオにおける推奨修正手順について説明します。代替の修復シナリオがある場合は、その特定の検索タイプのエントリに説明されます。検索タイプに関する完全な情報にアクセスするには、[アクティブな結果タイプ] テーブル

侵害された EC2 インスタンスの修正

AWS 環境の侵害された EC2 インスタンスを修正するには、以下の推奨手順に従います。

侵害された S3 バケットの修復

AWS 環境の侵害された S3 バケットを修正するには、以下の推奨手順に従います。

  1. 影響を受ける S3 リソースを特定します。

    S3 の GuardDuty 検索では、検索の詳細に S3 バケット、バケットの Amazon リソース番号(ARN)、およびバケット所有者が一覧表示されます。

  2. 疑わしいアクティビティの原因と使用された API コールを特定します。

    使用された API コールは、検索の詳細に API として表示されます。ソースは IAM プリンシパル(IAM ユーザー、ロール、またはアカウント)で、識別詳細が結果にリストされます。ソースタイプに応じて、リモート IP またはソースドメイン情報が利用可能になり、ソースが認可されたかどうかを評価するのに役立ちます。EC2 インスタンスからの認証情報が見つかった場合は、そのリソースの詳細も含まれます。

  3. コールソースが、識別されたリソースへのアクセスを許可されたかどうかを判断します。

    たとえば、以下の点を考慮します。

    • IAM ユーザーが関与していた場合、そのユーザーの認証情報が侵害されている可能性がありますか? 次の「侵害された AWS 認証情報の修正」セクションを参照してください。

    • このタイプの API を呼び出す以前の履歴がないプリンシパルから API が呼び出された場合、このソースはこのオペレーションのアクセス権限を必要としますか? バケットのアクセス許可をさらに制限できますか?

    • アクセスがユーザー名 ANONYMOUS_PRINCIPALuser typeAWSAccountこれは、バケットがパブリックであり、アクセスされたことを示します。このバケットは公開する必要がありますか? そうでない場合は、S3 リソースを共有するための代替ソリューションについて、以下のセキュリティ推奨事項を確認してください。

アクセスが許可された場合は、結果は無視できます。S3 データが許可されていないパーティによって公開またはアクセスされていると判断した場合は、次の S3 セキュリティ推奨事項を確認して、アクセス許可を強化し、アクセスを制限してください。適切な修正ソリューションは、お客様の特定の環境のニーズによって異なります。

以下に、特定の S3 アクセスのニーズに基づく推奨事項を示します。

  • S3 データへのパブリックアクセスを制限するための一元的な方法では、S3 ブロックパブリックアクセスを使用します。ブロックパブリックアクセス設定は、アクセスポイント、バケット、AWS アカウントの 4 つの異なる設定を有効にして、アクセスの粒度を制御できます。詳細については、「」を参照してください。S3 パブリックアクセスブロック設定

  • AWS アクセスポリシーを使用して、IAM ユーザーがリソースにアクセスする方法、またはバケットにアクセスする方法を制御できます。詳細については、「」を参照してください。バケットポリシーとユーザーポリシーの使用

    S3 バケットポリシー付きの Virtual Private Cloud (VPC) エンドポイントを使用して、特定の VPC エンドポイントへのアクセスを制限することもできます。詳細については、「」を参照してください。Amazon S3 の VPC エンドポイントのバケットポリシーの例

  • アカウント外の信頼されたエンティティへの S3 オブジェクトへのアクセスを一時的に許可するには、S3 を使用して署名済み URL を作成します。このアクセスは、アカウントの認証情報を使用して作成され、使用される認証情報に応じて 6 時間から 7 日間続くことがあります。詳細については、「」を参照してください。S3 による署名付き URL の生成

  • 異なるソース間で S3 オブジェクトを共有する必要があるユースケースでは、S3 アクセスポイントを使用して、プライベートネットワーク内のアクセス権のみに制限するアクセス権セットを作成できます。詳細については、「」を参照してください。Amazon S3 アクセスポイントを使用したデータアクセスの管理

  • 他の AWS アカウントに S3 リソースへのアクセスを安全に付与するには、アクセスコントロールリスト(ACL)を使用します。詳細については、ACL による S3 アクセス管理

S3 セキュリティオプションの完全な概要については、S3 セキュリティのベストプラクティス

侵害された AWS 認証情報の修正

AWS 環境の侵害された認証情報を修正するには、以下の推奨手順に従います。

  1. 影響を受ける IAM エンティティと使用された API コールを特定します。

    使用された API コールは、検索の詳細に API として表示されます。IAM エンティティ (IAM ユーザーまたは IAM ロール) とその識別情報は、結果の詳細の [リソース] セクションに表示されます。関連する IAM エンティティのタイプは、[ユーザータイプ] フィールドで特定できます。IAM エンティティの名前は、[ユーザー名] フィールドに表示されます。結果に関連する IAM エンティティのタイプは、使用されたアクセスキー ID でも特定できます。

    AKIA で始まるキーの場合:

    このタイプのキーは、IAM ユーザーまたは AWS アカウントのルートユーザーに関連付けられているお客様が管理する長期の認証情報です。IAM ユーザーのアクセスキーの管理については、IAM ユーザーのアクセスキーの管理

    ASIA で始まるキーの場合:

    このタイプのキーは、AWS Security Token Service によって生成される短期の一時的な認証情報です。これらのキーは短時間しか存在せず、AWS マネジメントコンソールで表示または管理することはできません。IAM ロールは常に AWS STS 認証情報を使用しますが、これらは IAM ユーザーに対して生成することもできます。AWS STS の詳細については、IAM: 一時的な認証情報

    ロールが使用された場合、[User name]フィールドには、使用されるロールの名前が示されます。AWS CloudTrail でキーがどのようにリクエストされたかを判断するには、sessionIssuer要素を CloudTrail ログエントリに追加する必要があります。詳細については、CloudTrail での IAM および AWS STS 情報

  2. IAM エンティティのアクセス許可を確認します。

    IAM コンソールを開き、使用されたエンティティのタイプに応じて [ユーザー] タブまたは [ロール] タブを選択し、検索フィールドに特定した名前を入力して影響を受けるエンティティを見つけます。[アクセス許可] タブと [アクセスアドバイザー] タブを使用して、そのエンティティの有効なアクセス許可を確認します。

  3. IAM エンティティの認証情報が正当に使用されたかどうかを確認します。

    アクティビティが意図的なものであったかどうかを確認するには、認証情報のユーザーに問い合わせます。

    たとえば、ユーザーが以下のことを行ったかどうかを確認します。

    • GuardDuty の結果に表示された API オペレーションの呼び出し

    • GuardDuty の結果に表示された時刻における API オペレーションの呼び出し

    • GuardDuty の結果に表示された IP アドレスからの API オペレーションの呼び出し

アクティビティが AWS 認証情報の正当な使用を示していることを確認した場合、GuardDuty の結果は無視できます。確認できない場合、このアクティビティは、その特定のアクセスキー、IAM ユーザーの ID とパスワード、または AWS アカウント全体に対する侵害の結果である可能性があります。認証情報が侵害された疑いがある場合は、AWS アカウントが侵害されている可能性があります記事を参照して、問題を修復してください。