GuardDuty によって検出されたセキュリティ問題の修復 - Amazon GuardDuty
侵害された EC2 インスタンスの修復侵害された S3 バケットの修復侵害された AWS 認証情報の修復

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

Amazon GuardDuty は、潜在的なセキュリティ問題を示す検出結果を生成します。GuardDuty のこのリリースでは、潜在的なセキュリティ問題は、侵害された EC2 インスタンスまたはご利用の AWS 環境での侵害された認証情報セットを示します。次のセクションでは、これらのシナリオにおいて推奨される修復ステップについて説明します。代替修復シナリオがある場合は、その特定の検出結果タイプのエントリで説明されます。検出結果タイプに関する完全な情報にアクセスするには、[Active findings types table] (アクティブな検出結果タイプテーブル) を選択します。

トピック

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

ご利用の AWS 環境で侵害された EC2 インスタンスを修復するには、次の推奨ステップに従います。

  1. マルウェアに侵害された可能性のあるインスタンスを調査し、検出されたマルウェアを削除します。マルウェアの特定および削除に役立つパートナー製品については、「AWS Marketplace」も参照してください。

  2. EC2 インスタンス上の不正なアクティビティを特定し、停止できない場合は、侵害された EC2 インスタンスを削除し、必要に応じて新しいインスタンスを作成することをお勧めします。EC2 インスタンスを保護するための追加リソースを次に示します。

  3. AWS デベロッパーフォーラムの詳細については、https://forums.aws.amazon.com/index.jspa を参照してください。

  4. プレミアムサポートパッケージの受信者は、テクニカルサポートをリクエストできます。

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

ご利用の AWS 環境で侵害された S3 バケットを修復するには、次の推奨ステップに従います。

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

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

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

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

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

    例えば、次の事項を検討します。

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

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

    • ユーザー名 ANONYMOUS_PRINCIPAL とユーザータイプ AWSAccount のアクセスがあった場合、これは、バケットがパブリックであり、アクセスされたことを示します。このバケットはパブリックであるべきですか? そうでない場合は、S3 リソースを共有する代替ソリューションについて、以下のセキュリティに関するレコメンデーションを確認してください。

    • ユーザータイプ AWSAccount のユーザー名 ANONYMOUS_PRINCIPAL から見た PreflightRequest コールが成功した場合、これはバケットにクロスオリジンリソース共有 (CORS) ポリシーが設定されていることを示します。このバケットには CORS ポリシーが必要ですか? そうでない場合は、バケットが不用意に公開されないようにし、S3 リソースを共有する代替ソリューションについて、以下のセキュリティに関するレコメンデーションを確認してください。CORS の詳細については、「S3 ユーザーガイド​」の「Cross-Origin Resource Sharing (CORS) の使用」を参照してください。

アクセスが許可されている場合は、検出結果を無視できます。S3 データが許可のない当事者によって公開またはアクセスされたと判断した場合は、次の S3 セキュリティに関するレコメンデーションを確認して、許可を強化し、アクセスを制限します。適切な修復ソリューションは、特定の環境のニーズによって異なります。

特定の S3 アクセスニーズに基づくレコメンデーションをいくつか示します。

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

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

    S3 バケットポリシーで仮想プライベートクラウド (VPC) エンドポイントを使用して、特定の VPC エンドポイントへのアクセスを制限することもできます。詳細については、「Example Bucket Policies for VPC Endpoints for Amazon S3」(Amazon S3 の VPC エンドポイント用のバケットポリシーの例) を参照してください。

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

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

  • S3 リソースへのアクセスを他の AWS アカウントに安全に付与するには、アクセスコントロールリスト (ACL) を使用できます。詳細については、「Managing S3 Access with ACLs」(ACL による S3 アクセス管理) を参照してください。

S3 セキュリティオプションの概要については、「S3 セキュリティのベストプラクティス」を参照してください。

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

ご利用の AWS 環境で侵害された認証情報を修復するには、次の推奨ステップに従います。

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

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

    AKIA で始まるキーの場合:

    このタイプのキーは、IAM ユーザーまたは AWS アカウントのルートユーザーに関連付けられているカスタマーマネージドの長期の認証情報です。IAM ユーザーのアクセスキーの管理については、「IAM ユーザーのアクセスキーの管理」を参照してください。

    ASIA で始まるキーの場合:

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

    ロールが使用された場合、[User name] (ユーザー名) フィールドには使用されたロールの名前が表示されます。AWS CloudTrail を使用して CloudTrail のログのエントリの sessionIssuer 要素を確認することにより、キーがどのようにリクエストされたかを特定できます。詳細については、「CloudTrail での IAM と AWS STS に関する情報」を参照してください。

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

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

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

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

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

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

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

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

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