侵害された可能性のある S3 バケットの修復 - Amazon GuardDuty

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

侵害された可能性のある S3 バケットの修復

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

  1. 侵害された可能性のある S3 リソースを特定します。

    S3 GuardDuty の結果には、関連する S3 バケット、その Amazon リソースネーム (ARN)、およびその所有者が結果の詳細に表示されます。

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

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

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

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

    • IAM ユーザーが関係していた場合、そのユーザーの認証情報が侵害された可能性がありますか? 詳細については、「侵害された可能性のある AWS 認証情報の修復」を参照してください。

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

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

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

  4. S3 バケットに機密データが含まれているかどうか判断します。

    Amazon Macie を使用して、S3 バケットに個人を特定できる情報 (PII)、財務データ、認証情報などの機密データが含まれているかどうかを判断します。Macie アカウントで機密データの自動検出が有効になっている場合は、S3 バケットの詳細を確認して S3 バケットのコンテンツをよりよく理解してください。Macie アカウントでこの機能が無効になっている場合、評価を早めるために有効にすることをおすすめします。または、機密データ検出ジョブを作成して実行し、S3 バケットのオブジェクトに機密データがないかを検査することもできます。詳細については、「機密ログデータをマスキングで保護する」を参照してください。

アクセスが許可されている場合は、検出結果を無視できます。https://console.aws.amazon.com/guardduty/ コンソールでは、個々の結果を表示しないように完全に抑制するルールを設定できます。詳細については、「抑制ルール」を参照してください。

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

特定の S3 バケットアクセスニーズに基づく推奨事項

次のリストは、特定の Amazon 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 Access Points を使用したデータアクセスの管理」を参照してください。

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

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