翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 検出された GuardDuty セキュリティ検出結果の修復
Amazon GuardDuty は、GuardDuty の基本的な脅威検出と専用の保護プランに関連付けられたセキュリティを脅かす可能性がある事例を[検出結果](guardduty_findings.md)として生成します。次のセクションでは、これらのシナリオにおいて推奨される修復ステップについて説明します。代替修復シナリオがある場合は、その説明が検出結果タイプごとに提示されます。検出結果タイプに関する完全な情報にアクセスするには、[[Active findings types table]](guardduty_finding-types-active.md) (アクティブな検出結果タイプテーブル) を選択します。
**Topics**
+ [侵害された可能性のある Amazon EC2 インスタンスの修復](compromised-ec2.md)
+ [侵害された可能性のある S3 バケットの修復](compromised-s3.md)
+ [悪意のある可能性がある S3 オブジェクトの修復](compromised-s3object-malware-protection-gdu.md)
+ [侵害された可能性のある EBS スナップショットの修復](compromised-snapshot.md)
+ [侵害された可能性のある EC2 AMI の修復](compromised-ami.md)
+ [侵害された可能性のある EC2 復旧ポイントの修復](compromised-ec2-recoverypoint.md)
+ [侵害された可能性のある S3 復旧ポイントの修復](compromised-s3-recoverypoint.md)
+ [侵害された可能性のある ECS クラスターの修復](compromised-ecs.md)
+ [侵害された可能性のある AWS 認証情報の修正](compromised-creds.md)
+ [侵害された可能性のあるスタンドアロンコンテナの修復](remediate-compromised-standalone-container.md)
+ [EKS Protection の検出結果の修復](guardduty-remediate-kubernetes.md)
+ [Runtime Monitoring 検出結果の修正](guardduty-remediate-runtime-monitoring.md)
+ [侵害された可能性のあるデータベースの修復](guardduty-remediate-compromised-database-rds.md)
+ [侵害された可能性のある Lambda 関数の修復](remediate-lambda-protection-finding-types.md)
# 侵害された可能性のある Amazon EC2 インスタンスの修復
[Amazon EC2 リソースの侵害を示唆する検出結果タイプ](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html#findings-table)が生成された場合、**[リソース]** が **[インスタンス]** になります。生成されうる検出結果タイプには [EC2 の検出結果タイプ](guardduty_finding-types-ec2.md)、[GuardDuty Runtime Monitoring の検出結果タイプ](findings-runtime-monitoring.md)、[Malware Protection for EC2 の検出結果のタイプ](findings-malware-protection.md) があります。検出結果の原因となった動作が環境の想定内である場合は、[抑制ルール](findings_suppression-rule.md)の使用を検討してください。
侵害された可能性のある Amazon EC2 インスタンスを修復するには、次の手順を実行します。
1. **侵害された可能性がある Amazon EC2 インスタンスを識別する**
マルウェアに侵害された可能性のあるインスタンスを調査し、検出されたマルウェアを削除します。[GuardDuty でのオンデマンドマルウェアスキャン](on-demand-malware-scan.md) を使用して、侵害された可能性のある EC2 インスタンス内のマルウェアを特定したり、[AWS Marketplace](https://aws.amazon.com/marketplace) でマルウェアを特定して削除するのに役立つパートナー製品があるかどうかを確認したりできます。
1. **侵害された可能性がある Amazon EC2 インスタンスを分離する**
可能であれば、次の手順を使用して侵害された可能性のあるインスタンスを分離します。
1. 専用の**分離**セキュリティグループを作成します。分離セキュリティグループでは、特定の IP アドレスからのインバウンドアクセスとアウトバウンドアクセスのみを許可します。`0.0.0.0/0 (0-65535)` に対するトラフィックを許可するインバウンドルールもアウトバウンドルールも存在しないことを確認してください。
1. このインスタンスに**分離**セキュリティグループを関連付けます。
1. 新規に作成した**分離**セキュリティグループを除くすべてのセキュリティグループの関連付けを侵害された可能性のあるインスタンスから削除します。
**注記**
セキュリティグループが変更されても、既に追跡済みの接続が終了することはありません。今後発生するトラフィックのみが新しいセキュリティグループによって効果的にブロックされます。
疑わしい既存の接続からのトラフィックを今後ブロックする方法については、「*インシデント対応プレイブック*」の「[Enforce NACLs based on network IoCs to prevent further traffic](https://github.com/aws-samples/aws-customer-playbook-framework/blob/main/docs/Ransom_Response_EC2_Linux.md#enforce-nacls-based-on-network-iocs-to-prevent-further-traffic)」を参照してください。
1. **疑わしいアクティビティのソースを特定する**
マルウェアが検出された場合は、アカウント内の検出結果のタイプに基づいて、EC2 インスタンスでの不正なアクティビティの可能性を特定して停止します。これには、開いているポートを閉じる、アクセスポリシーを変更する、脆弱性を修正するためにアプリケーションをアップグレードするなどのアクションが必要になる場合があります。
侵害された可能性のある EC2 インスタンスでの不正なアクティビティを識別して停止できない場合は、侵害された EC2 インスタンスを削除し、必要に応じて新しいインスタンスを作成することをお勧めします。EC2 インスタンスを保護するための追加リソースを次に示します。
+ 「[Amazon EC2 のベストプラクティス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-best-practices.html)」の「セキュリティ」と「ネットワーク」のセクション。
+ [Linux インスタンス用の Amazon EC2 セキュリティグループ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html)。
+ [Amazon EC2 でのセキュリティ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security.html)
+ [EC2 インスタンスのセキュリティを確保するためのヒント (Linux)](https://aws.amazon.com/articles/tips-for-securing-your-ec2-instance/)
+ [AWS セキュリティのベストプラクティス](https://aws.amazon.com//architecture/security-identity-compliance/)
+ [AWS セキュリティインシデント対応テクニカルガイド](https://docs.aws.amazon.com/security-ir/latest/userguide/security-incident-response-guide.html)。
1. **参照 AWS re:Post**
不明な点については、「[AWS re:Post](https://repost.aws/)」を参照してください。
1. **テクニカルサポートリクエストを送信する**
プレミアムサポートパッケージのサブスクライバーは、[テクニカルサポート](https://console.aws.amazon.com/support/home#/case/create?issueType=technical)をリクエストできます。
# 侵害された可能性のある S3 バケットの修復
GuardDuty で [GuardDuty S3 Protection の検出結果タイプ](guardduty_finding-types-s3.md)が生成された場合は、Amazon S3 バケットが既に侵害されています。検出結果の原因となった動作が環境の想内である場合は、[抑制ルール](findings_suppression-rule.md)の作成を検討してください。この動作が予期されなかった場合は、以下の推奨手順に従って、 AWS 環境内の侵害された可能性のある Amazon S3 バケットを修復します。
1. **侵害された可能性のある S3 リソースを識別します。**
S3 の GuardDuty 検索では、関連付けられた S3 バケット、その Amazon リソースネーム (ARN)、およびその所有者が検出結果の詳細に表示されます。
1. **疑わしいアクティビティのソースと使用された API コールを特定します。**
使用された API コールは、検出結果の詳細に `API` として表示されます。ソースは IAM プリンシパル (IAM ロール、ユーザーまたはアカウント) で、識別情報が検出結果に表示されます。ソースタイプに応じて、リモート IP アドレスまたはソースドメイン情報が利用可能になり、ソースが承認されたかどうかを評価するのに役立ちます。Amazon EC2 インスタンスから関連する認証情報が検出結果にあれば、そのリソースの詳細も含まれます。
1. **コールソースが、識別されたリソースへのアクセスを許可されたかどうかを確認します。**
例えば、次の事項を検討します。
+ IAM ユーザーが関与していた場合は、認証情報が侵害された可能性があるかどうかを確認します。詳細については、「[侵害された可能性のある AWS 認証情報の修正](compromised-creds.md)」を参照してください。
+ API が、このタイプの API を呼び出した履歴がないプリンシパルから呼び出された場合、このソースはこのオペレーションのアクセス権を必要としますか? バケットの許可をさらに制限することはできますか?
+ **ユーザー名** `ANONYMOUS_PRINCIPAL` と**ユーザータイプ** `AWSAccount` のアクセスがあった場合、これは、バケットがパブリックであり、アクセスされたことを示します。このバケットはパブリックであるべきですか? そうでない場合は、S3 リソースを共有する代替ソリューションについて、以下のセキュリティに関するレコメンデーションを確認してください。
+ アクセスが**ユーザー名** `ANONYMOUS_PRINCIPAL` と **ユーザータイプ** `AWSAccount`からの 成功した `PreflightRequest` コールを介して行われた場合、バケットにクロスオリジンリソース共有 (CORS) ポリシーが設定されていることを示します。このバケットには CORS ポリシーが必要ですか? そうでない場合は、バケットが不用意に公開されないようにし、S3 リソースを共有する代替ソリューションについて、以下のセキュリティに関するレコメンデーションを確認してください。CORS の詳細については、「S3 ユーザーガイド」の「[Cross-Origin Resource Sharing (CORS) の使用](https://docs.aws.amazon.com/AmazonS3/latest/userguide/cors.html)」を参照してください。
1. **S3 バケットに機密データが含まれているかどうか判断します。**
[Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html) を使用して、S3 バケットに個人を特定できる情報 (PII)、財務データ、認証情報などの機密データが含まれているかどうかを判断します。Macie アカウントで機密データの自動検出が有効になっている場合は、S3 バケットの詳細を確認して S3 バケットのコンテンツをよりよく理解してください。Macie アカウントでこの機能が無効になっている場合、評価を早めるために有効にすることをおすすめします。または、機密データ検出ジョブを作成して実行し、S3 バケットのオブジェクトに機密データがないかを検査することもできます。詳細については、「[機密ログデータをマスキングで保護する](https://docs.aws.amazon.com/macie/latest/user/data-classification.html)」を参照してください。
アクセスが許可されている場合は、検出結果を無視できます。[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) コンソールでは、個々の結果を表示しないように完全に抑制するルールを設定できます。詳細については、「[GuardDuty の抑制ルール](findings_suppression-rule.md)」を参照してください。
S3 データが許可のない当事者によって公開またはアクセスされたと判断した場合は、次の S3 セキュリティに関するレコメンデーションを確認して、許可を強化し、アクセスを制限します。適切な修復ソリューションは、特定の環境のニーズによって異なります。
## 特定の S3 バケットへのアクセスニーズに基づく推奨事項
**次に、特定の Amazon S3 バケットへのアクセスニーズに基づく推奨事項を示します。**
+ S3 データへのパブリックアクセスを一元的に制限するには、S3 ブロックパブリックアクセスを使用してください。ブロックパブリックアクセス設定は、アクセスポイント、バケット、 AWS アカウントに対して 4 つの異なる設定で有効にして、アクセスの詳細度を制御できます。詳細については、「*Amazon S3 ユーザーガイド*」の「[パブリックアクセスブロック設定](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html#access-control-block-public-access-options)」を参照してください。
+ AWS アクセスポリシーを使用して、IAM ユーザーがリソースにアクセスする方法やバケットにアクセスする方法を制御できます。詳細は、「*Amazon S3 ユーザーガイド*」の「[バケットポリシーとユーザーポリシーの使用](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security_iam_service-with-iam.html)」を参照してください。
S3 バケットポリシーで仮想プライベートクラウド (VPC) エンドポイントを使用して、特定の VPC エンドポイントへのアクセスを制限することもできます。詳細については、「*Amazon S3 ユーザーガイド*」の「[バケットポリシーを使用した VPC エンドポイントからのアクセスコントロール](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies-vpc-endpoint.html)」を参照してください
+ アカウント外の信頼できるエンティティへの S3 オブジェクトへのアクセスを一時的に許可するには、S3 を使用して署名済み URL を作成します。このアクセスは、アカウントの認証情報を使用して作成され、使用される認証情報に応じて 6 時間から 7 日間使用できます。詳細については、「*Amazon S3 ユーザーガイド*」の「[署名付き URL を使用したオブジェクトのダウンロードおよびアップロード](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html)」を参照してください。
+ 異なるソース間で S3 オブジェクトを共有する必要があるユースケースでは、S3 アクセスポイントを使用して、プライベートネットワーク内のオブジェクトのみへのアクセスを制限する許可セットを作成できます。詳細については、「*Amazon S3 ユーザーガイド*」の「[アクセスポイントを使用した共有データセットへのアクセス管理](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-points.html)」を参照してください。
+ 他のアカウントに S3 リソースへのアクセスを安全に許可 AWS するには、*Amazon S3ユーザーガイド*」の「アクセスコントロールリスト (ACL[) の概要](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html)」を参照してください。
S3 のセキュリティオプションの詳細については、「*Amazon S3 ユーザーガイド*」の「[Amazon S3 のセキュリティのベストプラクティス](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html)」を参照してください。
# 悪意のある可能性がある S3 オブジェクトの修復
GuardDuty で [Malware Protection for S3 の検出結果タイプ](gdu-malware-protection-s3-finding-types.md)が生成された場合は、Amazon S3 バケットに新規にアップロードされたオブジェクトにマルウェアが含まれています。リソースタイプは **S3Object** です。
次の推奨手順を使用すると、生成された検出結果を修復できる可能性があります。
1. 検出結果に関連付けられている **S3ObjectDetails** をチェックして、悪意のある可能性がある S3 オブジェクトを識別します。
1. こうして識別した S3 オブジェクトを分離します。関連付けられた Amazon S3 バケットに対して Malware Protection for S3 を有効にした時点で既にタグ付けを有効にしていた場合は、このオブジェクトに**悪意のある**タグが割り当てられているはずです。タグベースのアクセスコントロール (TBAC) を使用して、この S3 オブジェクトへのアクセスを制限します。詳細については、「[タグベースのアクセスコントロール (TBAC) の使用](tag-based-access-s3-malware-protection.md)」を参照してください。
あるいは、今後このオブジェクトを必要としない場合は、削除することも分離された S3 バケットに移動することもできます。S3 オブジェクトを削除する際の考慮事項については、「*Amazon S3 ユーザーガイド*」の「[オブジェクトの削除](https://docs.aws.amazon.com/AmazonS3/latest/userguide/DeletingObjects.html)」を参照してください。
# 侵害された可能性のある EBS スナップショットの修復
GuardDuty が Execution:EC2/MaliciousFile\$1Snapshot 検出結果タイプを生成すると、マルウェアが Amazon EBS スナップショットで検出されたことを示します。侵害された可能性のあるスナップショットを修正するには、次の手順を実行します。
1. **侵害された可能性のあるスナップショットを特定する**
1. 侵害された可能性のあるスナップショットを特定します。EBS スナップショットの GuardDuty 検出結果は、影響を受けるスナップショット ID、その Amazon リソースネーム (ARN)、および関連するマルウェアスキャンの詳細を検出結果の詳細に一覧表示します。
1. 次のコマンドを使用して、復旧ポイントの詳細を確認します。
```
aws backup describe-recovery-point —backup-vault-name 021345abcdef6789 —recovery-point-arn "arn:aws:ec2:us-east-1::snapshot/snap-abcdef01234567890"
```
1. **侵害されたスナップショットへのアクセスを制限する**
バックアップボールトアクセスポリシーを確認して変更し、リカバリポイントのアクセスを制限し、このスナップショットを使用する可能性のある自動復元ジョブを停止します。
1. 現在の共有アクセス許可を確認します。
```
aws ec2 describe-snapshot-attribute --snapshot-id snap-abcdef01234567890 --attribute createVolumePermission
```
1. 特定のアカウントアクセスを削除します。
```
aws ec2 modify-snapshot-attribute --snapshot-id snap-abcdef01234567890 --attribute createVolumePermission --operation-type remove --user-ids 111122223333
```
1. その他の CLI オプションについては、[modify-snapshot-attribute CLI documentation](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-snapshot-attribute.html)」を参照してください。
1. **修復アクションを実行する**
+ 削除に進む前に、すべての依存関係を特定し、必要に応じて適切なバックアップがあることを確認してください。
# 侵害された可能性のある EC2 AMI の修復
GuardDuty が Execution:EC2/MaliciousFile\$1AMI 検出結果タイプを生成すると、マルウェアが Amazon マシンイメージ (AMI) で検出されたことを示します。侵害された可能性のある AMI を修復するには、次の手順を実行します。
1. **侵害された可能性のある AMI を特定する**
1. AMIs の GuardDuty 検出結果は、影響を受ける AMI ID、その Amazon リソースネーム (ARN)、および関連するマルウェアスキャンの詳細を検出結果の詳細に一覧表示します。
1. AMI ソースイメージを確認します。
```
aws ec2 describe-images --image-ids ami-021345abcdef6789
```
1. **侵害されたリソースへのアクセスを制限する**
1. バックアップボールトアクセスポリシーを確認して変更し、復旧ポイントへのアクセスを制限し、この復旧ポイントを使用する可能性のある自動復元ジョブを停止します。
1. ソース AMI アクセス許可からアクセス許可を削除する
最初に既存のアクセス許可を表示します。
```
aws ec2 describe-image-attribute --image-id ami-abcdef01234567890 --attribute launchPermission
```
次に、個々のアクセス許可を削除します。
```
aws ec2 modify-image-attribute --image-id ami-abcdef01234567890 --launch-permission '{"Remove":[{"UserId":"111122223333"}]}'
```
その他の CLI オプションについては、[「特定のアカウントと AMI を共有する - Amazon Elastic Compute Cloud](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html#unsharing-an-ami)」を参照してください。
1. ソースが EC2 インスタンスの場合: [侵害された可能性のある Amazon EC2 インスタンスの修正](https://docs.aws.amazon.com/guardduty/latest/ug/compromised-ec2.html)を参照してください。
1. **修復アクションを実行する**
+ 削除に進む前に、すべての依存関係を特定し、必要に応じて適切なバックアップがあることを確認してください。
# 侵害された可能性のある EC2 復旧ポイントの修復
GuardDuty が Execution:EC2/MaliciousFile\$1RecoveryPoint 検出結果タイプを生成すると、EC2 Recovery Point Backup リソースでマルウェアが検出されたことを示します。侵害された可能性のある復旧ポイントを修復するには、次の手順を実行します。
1. **侵害された可能性のある EC2 復旧ポイントを特定する**
1. EC2 Recovery Point の GuardDuty の検出結果は、Amazon リソースネーム (ARN) と関連するマルウェアスキャンの詳細を検出結果の詳細に一覧表示します。
```
aws backup describe-recovery-point --backup-vault-name 021345abcdef6789 --recovery-point-arn "arn:aws:backup:us-east-1:111122223333:recovery-point:a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
```
1. 復旧の詳細を確認して、ソースイメージを検索します。
```
aws backup get-recovery-point-restore-metadata --backup-vault-name 021345abcdef6789 --recovery-point-arn "arn:aws:backup:us-east-1:111122223333:recovery-point:a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
```
1. **侵害されたリソースへのアクセスを制限する**
+ バックアップボールトアクセスポリシーを確認して変更し、復旧ポイントへのアクセスを制限し、この復旧ポイントを使用する可能性のある自動復元ジョブを停止します。環境がリソースタグ付けを使用している場合は、復旧ポイントに適切にタグ付けして調査中であることを示すとともに、必要に応じてスケジュールされたバックアップの一時停止を検討してください。
例:
*aws backup tag-resource --resource-arn arn:aws:backup:us-east-1:111122223333:recovery-point:a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 --tags Investigation=Malware,DoNotDelete=True*
1. **修復アクションを実行する**
+ 削除に進む前に、すべての依存関係を特定し、必要に応じて適切なバックアップがあることを確認してください。
# 侵害された可能性のある S3 復旧ポイントの修復
GuardDuty が Execution:S3/MaliciousFile\$1RecoveryPoint 検出結果タイプを生成すると、マルウェアが S3 Recovery Point Backup リソースで検出されたことを示します。侵害された可能性のある復旧ポイントを修復するには、次の手順を実行します。
1. **侵害された可能性のある S3 復旧ポイントを特定する**
1. S3 リカバリポイントの GuardDuty 検出結果には、影響を受けるリカバリポイント ARN、バックアップボールト名、および関連するマルウェアスキャンの詳細が検出結果の詳細に一覧表示されます。
1. 復旧ポイントの詳細を確認します。
```
aws backup describe-recovery-point --backup-vault-name 021345abcdef6789 --recovery-point-arn arn:aws:backup:us-east-1:123456789012:recovery-point:abcdef01234567890
```
1. **侵害されたリソースへのアクセスを制限する**
+ バックアップボールトアクセスポリシーを確認して変更し、復旧ポイントへのアクセスを制限し、この復旧ポイントを使用する可能性のある自動復元ジョブを停止します。環境がリソースタグ付けを使用している場合は、復旧ポイントに適切にタグ付けして調査中であることを示すとともに、必要に応じてスケジュールされたバックアップの一時停止を検討してください。
例:
```
aws backup tag-resource —resource-arn arn:aws:backup:us-east-1:111122223333:recovery-point:abcdef01234567890 —tags Investigation=Malware,DoNotDelete=True
```
詳細については、[「tag-resource CLI コマンドリファレンス](https://docs.aws.amazon.com/cli/latest/reference/backup/tag-resource.html)」を参照してください。
1. **修復アクションを実行する**
+ 削除に進む前に、すべての依存関係を特定し、必要に応じて適切なバックアップがあることを確認してください。
# 侵害された可能性のある ECS クラスターの修復
侵害された可能性のある ECS クラスターの検出結果は、Amazon ECS 環境内で疑わしいアクティビティまたは悪意のあるアクティビティが検出されたことを示します。これには、コンテナワークロードを危険にさらす不正アクセス、マルウェアの実行、またはその他の悪意のある動作が含まれます。
侵害された可能性のある Amazon ECS クラスターを修復するには、次の手順に従います。
1. **侵害された可能性のある ECS クラスターと検出された脅威を特定する (検出結果)**
影響を受ける ECS クラスターの詳細は、GuardDuty の検出結果の詳細パネルに表示されます。
1. **脅威/マルウェアの原因を評価する**
コンテナイメージにマルウェアがないか確認します。マルウェアが検出された場合は、使用されているコンテナイメージを確認します。を使用して[https://docs.aws.amazon.com//AmazonECS/latest/APIReference/API_ListTasks.html](https://docs.aws.amazon.com//AmazonECS/latest/APIReference/API_ListTasks.html)、侵害された可能性のある同じイメージを使用する他のすべての実行中のタスクを識別します。
1. **影響を受けるタスクを分離する**
影響を受けるタスクへのすべてのネットワークトラフィック (着信と発信の両方) をブロックして、脅威を停止します。このネットワーク分離は、侵害されたタスクへのすべての接続を切断することで、進行中の攻撃を防ぐのに役立ちます。
**注**: この検出結果が環境内の予想/正当なアクティビティによってトリガーされたと判断した場合は、同様の検出結果が表示されないように抑制ルールを設定できます。詳細については、「[GuardDuty の抑制ルール](findings_suppression-rule.md)」を参照してください。
# 侵害された可能性のある AWS 認証情報の修正
GuardDuty が を生成すると[IAM の検出結果タイプ](guardduty_finding-types-iam.md)、 AWS 認証情報が侵害されたことを示します。侵害された可能性のある **[リソース]** のタイプは **[AccessKey]** です。
AWS 環境内の侵害された可能性のある認証情報を修正するには、次の手順を実行します。
1. **侵害された可能性のある IAM エンティティと使用された API コールを識別します。**
使用された API コールは、検出結果の詳細に `API` として表示されます。IAM エンティティ (IAM ロールまたはユーザー) とその識別情報は、検出結果の詳細の **[リソース]** セクションに表示されます。関連する IAM エンティティのタイプは、**[User Type]** (ユーザータイプ) フィールドで特定できます。IAM エンティティの名前は、**[User name]** (ユーザー名) フィールドに表示されます。検出結果に関連する IAM エンティティのタイプは、使用された **[Access key ID]** (アクセスキー ID) でも特定できます。
`AKIA` で始まるキーの場合:
このタイプのキーは、IAM ユーザーまたは AWS アカウントのルートユーザーに関連付けられているカスタマーマネージドの長期の認証情報です。IAM ユーザーのアクセスキーの管理については、「[IAM ユーザーのアクセスキーの管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)」を参照してください。
`ASIA` で始まるキーの場合:
このタイプのキーは、 AWS Security Token Serviceによって生成される短期の一時的な認証情報です。これらのキーは短時間のみ存在し、 AWS マネジメントコンソールで表示または管理することはできません。IAM ロールは常に AWS STS 認証情報を使用しますが、IAM ユーザー用に生成することもできます。詳細については、[「IAM: 一時的なセキュリティ認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html#sts-introduction) AWS STS 」を参照してください。
ロールが使用された場合、**[User name]** (ユーザー名) フィールドには使用されたロールの名前が表示されます。CloudTrail ログエントリの `sessionIssuer`要素を調べる AWS CloudTrail ことで、 でキーがどのようにリクエストされたかを判断できます。詳細については、[「IAM」およびCloudTrail AWS STS の情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html#iam-info-in-cloudtrail)」を参照してください。
1. **IAM エンティティの許可を確認します。**
[IAM コンソール] を開きます。使用されたエンティティのタイプに応じて **[ユーザー]** タブまたは **[ロール]** タブを選択し、検索フィールドに識別した名前を入力して影響を受けるエンティティを見つけます。**[Permission]** (許可) タブと **[Access Advisor]** (アクセスアドバイザー) タブを使用して、そのエンティティの有効な許可を確認します。
1. **IAM エンティティの認証情報が正当に使用されたかどうかを確認します。**
アクティビティが意図的なものであったかどうかを確認するには、認証情報のユーザーに問い合わせます。
例えば、ユーザーが次のことを行ったかどうかを確認します。
+ GuardDuty の検出結果に表示された API オペレーションの呼び出し
+ GuardDuty の検出結果に表示された時刻における API オペレーションの呼び出し
+ GuardDuty の検出結果に表示された IP アドレスからの API オペレーションの呼び出し
このアクティビティが AWS 認証情報の正当な使用である場合は、GuardDuty の検出結果を無視できます。[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) コンソールでは、個々の結果を表示しないように完全に抑制するルールを設定できます。詳細については、「[GuardDuty の抑制ルール](findings_suppression-rule.md)」を参照してください。
正当に使用されたことが確認できない場合、このアクティビティはその特定のアクセスキー、IAM ユーザーのサインイン認証情報、または AWS アカウント全体に対する侵害の結果である可能性があります。認証情報が侵害された疑いがある場合は、[「My AWS アカウント may be compromised](https://repost.aws/knowledge-center/potential-account-compromise) to remediate this issue」の情報を確認してください。
# 侵害された可能性のあるスタンドアロンコンテナの修復
[コンテナの侵害を示唆する検出結果タイプ](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html#findings-table)が生成された場合、**[リソース]** のタイプが **[コンテナ]** になります。検出結果の原因となった動作が環境の想定内である場合は、[抑制ルール](findings_suppression-rule.md)の使用を検討してください。
AWS 環境内の侵害された可能性のある認証情報を修正するには、次の手順を実行します。
1. **侵害された可能性があるコンテナを分離する**
次の手順に従うと、悪意のある可能性があるコンテナワークロードを識別できます。
+ [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) で GuardDuty コンソールを開きます。
+ **[検出結果]** ページで、対応する検出結果を選択して検出結果パネルを表示します。
+ 検出結果パネルの **[Resource affected]** (影響を受けるリソース) セクションで、コンテナの **[ID]** と **[Name]** (名前) を表示できます。
このコンテナを他のコンテナワークロードから分離します。
1. **コンテナを一時停止する**
コンテナ内のすべてのプロセスを一時停止します。
コンテナをフリーズする方法については、「[Pause a container](https://docs.docker.com/engine/api/v1.35/#tag/Container/operation/ContainerPause)」を参照してください。
**コンテナを停止する**。
上記のステップが失敗し、コンテナが一時停止しない場合は、コンテナの実行を停止します。[スナップショットの保持](malware-protection-customizations.md#mp-snapshots-retention) 機能を有効にした場合、GuardDuty はマルウェアを含む EBS ボリュームのスナップショットを保持します。
コンテナを停止する方法については、「[Stop a container](https://docs.docker.com/engine/api/v1.35/#tag/Container)」を参照してください。
1. **マルウェアの有無の評価**
マルウェアがコンテナのイメージに存在したかどうかを評価します。
アクセスが許可されている場合は、検出結果を無視できます。[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) コンソールでは、個々の結果を表示しないように完全に抑制するルールを設定できます。GuardDuty コンソールでは、個々の結果が表示されないように完全に抑制するルールを設定できます。詳細については、「[GuardDuty の抑制ルール](findings_suppression-rule.md)」を参照してください。
# EKS Protection の検出結果の修復
Amazon GuardDuty は、アカウント用に EKS Protection が有効になっている場合に、Kubernetes のセキュリティ問題の可能性を示す[検出結果](guardduty_findings.md)を生成します。詳細については、「[EKS Protection](kubernetes-protection.md)」を参照してください。次のセクションでは、これらのシナリオにおいて推奨される修復ステップについて説明します。特定の修復アクションは、その特定の検出結果タイプのエントリで説明されています。検出結果タイプに関する完全な情報にアクセスするには、[[Active findings types table]](guardduty_finding-types-active.md) (アクティブな検出結果タイプテーブル) を選択します。
EKS Protection の検出結果タイプのいずれかが予想どおりに生成された場合は、今後アラートが発生しないように [GuardDuty の抑制ルール](findings_suppression-rule.md)を追加することを検討してください。
さまざまなタイプの攻撃と設定の問題によって、GuardDuty EKS Protection の検出結果がトリガーされる可能性があります。このガイドは、適切な修復ガイダンスを概説するものであり、クラスターに対する GuardDuty の検出結果の根本原因を特定するのに役立ちます。GuardDuty の Kubernetes の検出結果につながる主な根本原因は次のとおりです。
+ [潜在的な設定の問題](#compromised-kubernetes-config)
+ [侵害された可能性のある Kubernetes ユーザーの修復](#compromised-kubernetes-user)
+ [侵害された可能性のある Kubernetes ポッドの修復](#compromised-kubernetes-pod)
+ [侵害された可能性のある Kubernetes ノードの修復](#compromised-kubernetes-node)
+ [侵害された可能性のあるコンテナイメージの修復](#compromised-kubernetes-image)
**注記**
Kubernetes バージョン 1.14 より前では、`system:unauthenticated` グループは、デフォルトで `system:discovery` と `system:basic-user` **ClusterRoles** に関連付けられていました。これは、匿名ユーザーからの意図しないアクセスを許可する場合があります。クラスターの更新では、これらの許可は取り消されません。つまり、クラスターをバージョン 1.14 以降に更新した場合でも、これらの許可は引き続き有効である可能性があります。これらの許可の関連付けを `system:unauthenticated` グループから解除することをお勧めします。
これらのアクセス許可の削除の詳細については、「**Amazon EKS ユーザーガイド**」の「[ベストプラクティスによる Amazon EKS クラスターの保護](https://docs.aws.amazon.com/eks/latest/userguide/security-best-practices.html)」を参照してください。
## 潜在的な設定の問題
検出結果で設定の問題が示されている場合、その特定の問題の解決に関するガイダンスについては、その検出結果の修復セクションを参照してください。詳細については、設定上の問題を示す次の検出結果タイプを参照してください。
+ [Policy:Kubernetes/AnonymousAccessGranted](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-anonymousaccessgranted)
+ [Policy:Kubernetes/ExposedDashboard](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-exposeddashboard)
+ [Policy:Kubernetes/AdminAccessToDefaultServiceAccount](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-adminaccesstodefaultserviceaccount)
+ [Policy:Kubernetes/KubeflowDashboardExposed](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-kubeflowdashboardexposed)
+ **SuccessfulAnonymousAccess** で終わる検出結果。
## 侵害された可能性のある Kubernetes ユーザーの修復
GuardDuty の検出結果は、検出結果で特定されたユーザーが想定されていない API アクションを実行したときに、侵害された Kubernetes ユーザーを示している場合があります。ユーザーは、コンソールの検出結果の詳細の **[Kubernetes user details]** (Kubernetes ユーザー詳細) セクション、または検出結果の JSON の `resource.kubernetesDetails.kubernetesUserDetails` で識別できます。これらのユーザーの詳細には、`user name`、`uid`、およびユーザーが属する Kubernetes グループが含まれます。
ユーザーが IAM エンティティを使用してワークロードにアクセスしていた場合は、この `Access Key details` セクションを使用して、IAM ロールまたはユーザーの詳細を識別できます。次のユーザータイプとその修復ガイダンスを参照してください。
**注記**
Amazon Detective を使用して、検出結果で特定された IAM ロールまたはユーザーをさらに調査できます。GuardDuty コンソールで検出結果の詳細を表示しているときに、**[Detective で調査]** を選択します。次に、リストされた項目から AWS ユーザーまたはロールを選択して、Detective で調査します。
**組み込みの Kubernetes 管理者** – クラスターを作成した IAM アイデンティティに Amazon EKS によって割り当てられたデフォルトのユーザー。このユーザータイプは、ユーザー名 `kubernetes-admin` で識別されます。
**組み込みの Kubernetes 管理者のアクセスを取り消すには:**
+ `Access Key details` セクションから `userType` を識別します。
+ `userType` が **[Role]** (ロール) であり、ロールが EC2 インスタンスロールに属している場合:
+ そのインスタンスを特定し、「[侵害された可能性のある Amazon EC2 インスタンスの修復](compromised-ec2.md)」の手順に従います。
+ `userType` が **[User]** (ユーザー) の場合、またはユーザーが引き受けた **[Role]** (ロール) の場合:
1. そのユーザーの[アクセスキーをローテーション](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)します。
1. ユーザーがアクセス権を有していたシークレットをローテーションします。
1. 詳細については、[「My AWS アカウント may be compromised](https://repost.aws/knowledge-center/potential-account-compromise)」の情報を確認してください。
**OIDC 認証済みユーザー** – OIDC プロバイダーを通じてアクセス権を付与されたユーザー。通常、OIDC ユーザーは、ユーザー名としてメールアドレスを持っています。次のコマンドを使用して、クラスターが OIDC を使用しているかどうかを確認できます: `aws eks list-identity-provider-configs --cluster-name your-cluster-name `。
**OIDC 認証済みユーザーのアクセスを取り消すには:**
1. OIDC プロバイダーでそのユーザーの認証情報をローテーションします。
1. ユーザーがアクセス権を有していたシークレットをローテーションします。
**AWS-Auth ConfigMap 定義ユーザー** – AWS認証 ConfigMap を通じてアクセス権が付与された IAM ユーザー。詳細については、「**Amazon EKS ユーザーガイド**」の「[Managing users or IAM roles for your cluster](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html)」を参照してください。次のコマンドを使用して、許可を確認できます: `kubectl edit configmaps aws-auth --namespace kube-system`。
** AWS ConfigMap ユーザーのアクセスを取り消すには:**
1. 次のコマンドを使用して、ConfigMap を開きます。
```
kubectl edit configmaps aws-auth --namespace kube-system
```
1. GuardDuty の検出結果の [Kubernetes user details] (Kubernetes ユーザー詳細) セクションで報告されたものと同じユーザー名で、**mapRoles** または **mapUsers** セクションの下のロールまたはユーザーエントリを特定します。次の例を参照してください。ここでは、管理者ユーザーが検出結果で特定されています。
```
apiVersion: v1
data:
mapRoles: |
- rolearn: arn:aws:iam::444455556666:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
user name: system:node:EC2_PrivateDNSName
groups:
- system:bootstrappers
- system:nodes
mapUsers: |
- userarn: arn:aws:iam::123456789012:user/admin
username: admin
groups:
- system:masters
- userarn: arn:aws:iam::111122223333:user/ops-user
username: ops-user
groups:
- system:masters
```
1. そのユーザーを ConfigMap から削除します。管理者ユーザーが削除された次の例を参照してください。
```
apiVersion: v1
data:
mapRoles: |
- rolearn: arn:aws:iam::111122223333:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
mapUsers: |
- userarn: arn:aws:iam::111122223333:user/ops-user
username: ops-user
groups:
- system:masters
```
1. `userType` が **[User]** (ユーザー) の場合、またはユーザーが引き受けた **[Role]** (ロール) の場合:
1. そのユーザーの[アクセスキーをローテーション](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)します。
1. ユーザーがアクセス権を有していたシークレットをローテーションします。
1. 詳細については、[AWS 「アカウントが侵害されている可能性がある](https://aws.amazon.com//premiumsupport/knowledge-center/potential-account-compromise/)」の情報を確認してください。
検出結果に `resource.accessKeyDetails` セクションがない場合、ユーザーは Kubernetes サービスアカウントです。
**サービスアカウント** – サービスアカウントはポッドのアイデンティティを提供し、次の形式のユーザー名で識別できます: `system:serviceaccount:namespace:service_account_name`。
**サービスアカウントへのアクセス権を取り消すには:**
1. サービスアカウントの認証情報をローテーションします。
1. 次のセクションでポッドの侵害に関するガイダンスを確認します。
## 侵害された可能性のある Kubernetes ポッドの修復
GuardDuty が `resource.kubernetesDetails.kubernetesWorkloadDetails` セクション内のポッドまたはワークロードリソースの詳細を指定する場合、そのポッドまたはワークロードリソースが侵害されている可能性があります。GuardDuty の検出結果は、単一のポッドが侵害されたか、または上位レベルのリソースを介して複数のポッドが侵害されたことを示している場合があります。侵害されたポッドを特定する方法のガイダンスについては、次の侵害シナリオを参照してください。
**単一のポッドの侵害**
`resource.kubernetesDetails.kubernetesWorkloadDetails` セクション内の `type` フィールドが **[Pod]** (ポッド) である場合、検出結果は単一のポッドを特定します。名前フィールドはポッドの `name` であり、`namespace` フィールドはその名前空間です。
ポッドを実行しているワーカーノードの特定の詳細については、「*Amazon EKS Best Practices Guide*」の「[Identify the offending pods and worker node](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pod_and_worker_node)」を参照してください。
**ワークロードリソースを通じて侵害されたポッド**
`type` セクション内の `resource.kubernetesDetails.kubernetesWorkloadDetails` フィールドが、`Deployment` などの **[Workload Resource]** (ワークロードリソース) を識別している場合、そのワークロードリソース内のすべてのポッドが侵害されている可能性があります。
ワークロードリソースのすべてのポッドとそれらが実行されているノードの特定の詳細については、「*Amazon EKS Best Practices Guide*」の「[Identify the offending pods and worker nodes using workload name](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pods_and_worker_nodes_using_workload_name)」を参照してください。
**サービスアカウントを通じて侵害されたポッド**
GuardDuty の検出結果が `resource.kubernetesDetails.kubernetesUserDetails` セクションでサービスアカウントを識別した場合、識別されたサービスアカウントを使用しているポッドが侵害されている可能性があります。検出結果によって報告されたユーザー名は、次の形式の場合はサービスアカウントです: `system:serviceaccount:namespace:service_account_name`。
サービスアカウントを使用しているすべてのポッドとそれらが実行されているノードの特定の詳細については、「*Amazon EKS Best Practices Guide*」の「[Identify the offending pods and worker nodes using service account name](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pods_and_worker_nodes_using_service_account_name)」を参照してください。
侵害されたポッドとそれらが実行されているノードをすべて特定したら、「*Amazon EKS Best Practices Guide*」の「[Isolate the pod by creating a network policy that denies all ingress and egress traffic to the pod](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_isolate_the_pod_by_creating_a_network_policy_that_denies_all_ingress_and_egress_traffic_to_the_pod)」を参照してください。
**侵害されている可能性のあるポッドを修復するには:**
1. ポッドを侵害した脆弱性を特定します。
1. その脆弱性の修復を実装し、新しい代替ポッドを起動します。
1. 脆弱なポッドを削除します。
詳細については、「*Amazon EKS Best Practices Guide*」の「[Redeploy compromised pod or workload resource](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_redeploy_compromised_pod_or_workload_resource)」を参照してください。
ワーカーノードに Pod が他の AWS リソースにアクセスできるようにする IAM ロールが割り当てられている場合は、攻撃によるさらなる損害を防ぐために、それらのロールをインスタンスから削除します。同様に、ポッドに IAM ロールが割り当てられている場合は、他のワークロードに影響を与えることなく、ロールから IAM ポリシーを安全に削除できるかどうかを評価します。
## 侵害された可能性のあるコンテナイメージの修復
GuardDuty の検出結果でポッドの侵害が示されている場合、ポッドの起動に使用されたイメージが潜在的に悪意があるものであるか、または侵害されている可能性があります。GuardDuty の検出結果では、`resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image` フィールド内のコンテナイメージが識別されます。マルウェアがないかを調べるためにスキャンして、イメージが悪意のあるものであるかどうかを判断できます。
**侵害されたコンテナイメージを修復するには:**
1. 直ちにイメージの使用を停止し、イメージリポジトリから削除します。
1. 侵害された可能性のあるイメージを使用しているすべてのポッドを特定します。
詳細については、「*Amazon EKS Best Practices Guide*」の「[Identify pods with vulnerable or compromised images and worker nodes](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_pods_with_vulnerable_or_compromised_images_and_worker_nodes)」 を参照してください。
1. 侵害された可能性のあるポッドを分離し、認証情報をローテーションして、分析のためにデータを収集します。詳細については、*「Amazon EKS Best Practices Guide*」の「[Isolate the pod by creating a network policy that denies all ingress and egress traffic to the pod](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_isolate_the_pod_by_creating_a_network_policy_that_denies_all_ingress_and_egress_traffic_to_the_pod)」を参照してください。
1. 侵害された可能性のあるイメージを使用しているすべてのポッドを削除します。
## 侵害された可能性のある Kubernetes ノードの修復
GuardDuty の検出結果は、検出結果で識別されたユーザーがノードアイデンティティを表す場合、または検出結果が特権コンテナの使用を示している場合、ノードの侵害を示している場合があります。
**[username]** (ユーザーネーム) フィールドの形式が次の場合、ユーザーアイデンティティはワーカーノードです: `system:node:node name`。例えば、`system:node:ip-192-168-3-201.ec2.internal`。これは、攻撃者がノードへのアクセスを取得し、ノードの認証情報を使用して Kubernetes API エンドポイントと通信していることを示すものです。
検出結果では、検出結果にリストされている 1 つ以上のコンテナの `resource.kubernetesDetails.kubernetesWorkloadDetails.containers.securityContext.privileged` 検出結果フィールドが `True` に設定されている場合に、特権コンテナの使用を示します。
**侵害されている可能性のあるノードを修復するには:**
1. ポッドを分離し、認証情報をローテーションして、フォレンジック分析のためにデータを収集します。
詳細については、*「Amazon EKS Best Practices Guide*」の「[Isolate the pod by creating a network policy that denies all ingress and egress traffic to the pod](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_isolate_the_pod_by_creating_a_network_policy_that_denies_all_ingress_and_egress_traffic_to_the_pod)」を参照してください。
1. 侵害されている可能性のあるノードで実行されているすべてのポッドが使用するサービスアカウントを特定します。許可を確認し、必要に応じてサービスアカウントをローテーションします。
1. 侵害されている可能性のあるノードを終了します。
# Runtime Monitoring 検出結果の修正
アカウントの Runtime Monitoring を有効にすると、Amazon GuardDuty [GuardDuty Runtime Monitoring の検出結果タイプ](findings-runtime-monitoring.md)が AWS 環境内の潜在的なセキュリティ問題を示す を生成することがあります。潜在的なセキュリティ上の問題は、侵害された Amazon EC2 インスタンス、コンテナワークロード、Amazon EKS クラスター、または AWS 環境内の侵害された認証情報のセットのいずれかを示しています。セキュリティエージェントは、複数のリソースタイプからのランタイムイベントを監視します。危険にさらされている可能性のあるリソースを特定するには、GuardDuty コンソールで生成された検出結果の詳細で **[リソースタイプ]** を確認してください。次のセクションでは、リソースのタイプごとに推奨される修復手順について説明します。
------
#### [ Instance ]
検出結果の **[リソースタイプ]** が **[インスタンス]** の場合は、EC2 インスタンスまたは EKS ノードのいずれかが侵害されている可能性があることを示しています。
+ 侵害された EKS ノードを修復するには、「[侵害された可能性のある Kubernetes ノードの修復](guardduty-remediate-kubernetes.md#compromised-kubernetes-node)」を参照してください。
+ 侵害された EC2 インスタンスを修正するには、「[侵害された可能性のある Amazon EC2 インスタンスの修復](compromised-ec2.md)」を参照してください。
------
#### [ EKSCluster ]
検出結果の詳細の **[リソースタイプ]** が **[EKSCluster]** の場合は、EKS クラスター内のポッドまたはコンテナが危険にさらされている可能性があることを示しています。
+ 侵害されたポッドを修復するには、「[侵害された可能性のある Kubernetes ポッドの修復](guardduty-remediate-kubernetes.md#compromised-kubernetes-pod)」を参照ください。
+ 侵害されたコンテナイメージを修復するには、「[侵害された可能性のあるコンテナイメージの修復](guardduty-remediate-kubernetes.md#compromised-kubernetes-image)」を参照してください。
------
#### [ ECSCluster ]
検出結果の詳細の **[リソースタイプ]** が **[ECSCluster]** の場合は、ECS タスク内の ECS タスクまたはコンテナが危険にさらされている可能性があることを示しています。
1. **影響を受ける ECS クラスターを特定します**
GuardDuty Runtime Monitoring の検出結果では、検出結果の詳細パネルまたは検出結果 JSON の `resource.ecsClusterDetails` セクションに ECS クラスターの詳細が表示されます。
1. **影響を受ける ECS タスクを特定**
GuardDuty Runtime Monitoring の検出結果では、検出結果の詳細パネルまたは検出結果 JSON の `resource.ecsClusterDetails.taskDetails` セクションに ECS タスクの詳細が表示されます。
1. **影響を受けるタスクを分離**
タスクへの送受信トラフィックをすべて拒否して、影響を受けたタスクを分離します。すべてのトラフィックを拒否するルールは、タスクへのすべての接続を切断することによって、すでに進行中の攻撃を阻止するのに役立ちます。
1. **侵害されたタスクを修復**
1. タスクを侵害した脆弱性を特定します。
1. その脆弱性の修復を実装し、新しい代替タスクを起動します。
1. 脆弱なタスクを停止します。
------
#### [ Container ]
検出結果の詳細の **[リソースタイプ]** が **[コンテナ]** の場合は、スタンドアロンコンテナが危険にさらされている可能性があることを示しています。
+ 修正するには、「[侵害された可能性のあるスタンドアロンコンテナの修復](remediate-compromised-standalone-container.md)」を参照してください。
+ 同じコンテナイメージを使用して複数のコンテナにわたって検出結果が生成される場合は、「[侵害された可能性のあるコンテナイメージの修復](guardduty-remediate-kubernetes.md#compromised-kubernetes-image)」を参照してください。
+ コンテナが基盤となる EC2 ホストにアクセスした場合、関連するインスタンスの認証情報が侵害されている可能性があります。詳細については、「[侵害された可能性のある AWS 認証情報の修正](compromised-creds.md)」を参照してください。
+ 潜在的に悪意のある攻撃者が基盤となる EKS ノードまたは EC2 インスタンスにアクセスした場合は、*[EKSCluster]* タブと *[インスタンス]* タブで推奨される修復方法を参照してください。
------
## 侵害されたコンテナイメージの修復
GuardDuty の検出結果でタスクの侵害が示されている場合、タスクの起動に使用されたイメージが悪意があるものであるか、または侵害されている可能性があります。GuardDuty の検出結果では、`resource.ecsClusterDetails.taskDetails.containers.image` フィールド内のコンテナイメージが識別されます。マルウェアの有無を調べるためにスキャンして、イメージが悪意のあるものであるかどうかを判断できます。
**侵害されたコンテナイメージを修復**
1. 直ちにイメージの使用を停止し、イメージリポジトリから削除します。
1. このイメージを使用しているタスクをすべて特定します。
1. 侵害されたイメージを使用しているすべてのタスクを停止します。侵害されたイメージの使用を停止するよう、タスクの定義を更新します。
# 侵害された可能性のあるデータベースの修復
[RDS Protection](rds-protection.md) を有効にすると、GuardDuty によって [RDS Protection の検出結果タイプ](findings-rds-protection.md) が生成され、[サポートされているデータベース](rds-protection.md#rds-pro-supported-db) での異常かつ疑わしいログイン動作が示されます。GuardDuty は RDS ログインアクティビティを使用して、ログイン試行の異常なパターンを特定することで脅威の分析とプロファイリングを行います。
**注記**
検出結果タイプに関する完全な情報にアクセスするには、[GuardDuty のアクティブな検出結果タイプ](guardduty_finding-types-active.md#findings-table) から選択します。
AWS 環境内の侵害された可能性のある Amazon Aurora データベースを修正するには、以下の推奨ステップに従います。
**Topics**
+ [ログインイベントの成功により、侵害された可能性のあるデータベースの修復](#gd-compromised-db-successful-attempt)
+ [ログインイベントの失敗により、侵害された可能性のあるデータベースの修正](#gd-compromised-db-failed-attempt)
+ [漏えいした可能性のある認証情報の修正](#gd-rds-database-compromised-credentials)
+ [ネットワークアクセスを制限する](#gd-rds-database-restrict-network-access)
## ログインイベントの成功により、侵害された可能性のあるデータベースの修復
以下の推奨手順は、ログインイベントの成功に関連して異常な動作をする、侵害された可能性のある Aurora データベースを修復する際に役に立ちます。
1. **影響を受けたデータベースとユーザーを特定します。**
生成された GuardDuty の検出結果には、影響を受けたデータベースの名前と対応するユーザーの詳細が表示されます。詳細については、「[検出結果の詳細](guardduty_findings-summary.md)」を参照してください。
1. **この動作が予期されるものであるか、または予期されないものであるかを確認します。**
以下のリストは、GuardDuty から検出結果が生成されるシナリオを示しています。
+ 長い時間が経過した後にデータベースにログインするユーザー。
+ データベースにときどきログインするユーザー (四半期ごとにログインする財務アナリストなど)。
+ ログイン試行に成功し、データベースを侵害した可能性がある疑わしい攻撃者。
1. **予期しない動作が発生した場合は、このステップを開始してください。**
1. **データベースアクセスを制限する**
疑わしいアカウントおよびこのログインアクティビティのソースによるデータベースへのアクセスを制限します。詳細については、「[漏えいした可能性のある認証情報の修正](#gd-rds-database-compromised-credentials)」および「[ネットワークアクセスを制限する](#gd-rds-database-restrict-network-access)」を参照してください。
1. **影響を評価し、アクセスされた情報を特定します。**
+ 可能であれば、監査ログを確認して、アクセスされた可能性のある情報を特定します。詳細については、「*Amazon Aurora ユーザーガイド*」の「[Amazon Aurora DB クラスターでの、イベント、ログ、およびストリーミングのモニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_Monitor_Logs_Events.html)」を参照してください。
+ 機密情報または保護された情報にアクセスされたか、または変更が加えられたかどうかを確認します。
## ログインイベントの失敗により、侵害された可能性のあるデータベースの修正
以下の推奨手順は、ログインイベントの失敗に関連して異常な動作をする、侵害された可能性がある Aurora データベースを修復する際に役に立ちます。
1. **影響を受けたデータベースとユーザーを特定します。**
生成された GuardDuty の検出結果には、影響を受けたデータベースの名前と対応するユーザーの詳細が表示されます。詳細については、「[検出結果の詳細](guardduty_findings-summary.md)」を参照してください。
1. **ログインに失敗したソースを特定します。**
GuardDuty の検出結果パネルの **[Actor]** (アクター) セクションに、**[IP address]** (IP アドレス) と **[ASN organization]** (ASN 組織) (パブリック接続の場合) が表示されます。
自律システム (AS) は、1 つ以上のネットワークオペレーターによって実行される 1 つ以上の IP プレフィックス (ネットワーク上でアクセス可能な IP アドレスのリスト) のグループで、明確に定義された単一のルーティングポリシーを維持します。ネットワークオペレーターには、ネットワーク内のルーティングを制御したり、他のインターネットサービスプロバイダー (ISP) とルーティング情報を交換したりするための AS 番号 (ASN) が必要です。
1. **この動作が予期しないものであることを確認します。**
このアクティビティが、データベースへのさらなる不正アクセスを試みているものかどうかを次のように検証します。
+ ソースが内部にある場合は、アプリケーションが誤って設定されていないかどうかを調べて、接続が繰り返し試行されていないかを確認します。
+ これが外部の攻撃者である場合は、該当するデータベースが一般公開されているかどうか、または設定が誤っていないかどうか調べ、悪意のある攻撃者が一般的なユーザー名に対してブルートフォース攻撃を仕掛けられるようになっていないかを確認します。
1. **予期しない動作が発生した場合は、このステップを開始してください。**
1. **データベースアクセスを制限する**
疑わしいアカウントおよびこのログインアクティビティのソースによるデータベースへのアクセスを制限します。詳細については、「[漏えいした可能性のある認証情報の修正](#gd-rds-database-compromised-credentials)」および「[ネットワークアクセスを制限する](#gd-rds-database-restrict-network-access)」を参照してください。
1. **根本原因を分析し、このアクティビティを引き起こした可能性のあるステップを特定します。**
アクティビティによってネットワークポリシーが変更され、安全でない状態になったときに通知を受けるようにアラートを設定します。詳細については、「*AWS Network Firewall デベロッパーガイド*」の「[AWS Network Firewallにおけるファイアウォールポリシー](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-policies.html)」を参照してください。
## 漏えいした可能性のある認証情報の修正
GuardDuty の検出結果には、検出結果で特定されたユーザーが予期しないデータベース操作を実行したときに、影響を受けたデータベースのユーザー認証情報が漏えいしたことが示される場合もあります。ユーザーを特定するには、コンソールの検出結果パネル内の **[RDS DB user details]** (RDS DB ユーザー詳細) セクション、または検出結果 JSON の `resource.rdsDbUserDetails` を確認します。これらのユーザーの詳細には、ユーザー名、使用したアプリケーション、アクセスしたデータベース、SSL バージョン、認証方法が含まれます。
+ 検出結果に関係する特定のユーザーのアクセス権限を取り消したり、パスワードを変更したりするには、「*Amazon Aurora ユーザーガイド*」の「[Amazon Aurora MySQL でのセキュリティ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Security.html)」または「[Amazon Aurora PostgreSQL でのセキュリティ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Security.html)」を参照してください。
+ を使用して AWS Secrets Manager 、Amazon Relational Database Service (RDS) データベースのシークレットを安全に保存し、自動的にローテーションします。詳細については、「*AWS Secrets Manager ユーザーガイド*」の「[AWS Secrets Manager のチュートリアル](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials.html)」を参照してください。
+ IAM データベース認証を使用すると、パスワードなしでデータベースユーザーのアクセスを管理できます。詳細については、「Amazon Aurora ユーザーガイド」の「[IAM データベース認証](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.html)」を参照してください。
詳細については、「[Amazon RDS ユーザーガイド](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_BestPractices.Security.html)」の「*Amazon RDS のセキュリティのベストプラクティス*」を参照してください。
## ネットワークアクセスを制限する
GuardDuty の検出結果には、データベースがアプリケーションや仮想プライベートクラウド (VPC) の外部からのアクセスが可能であることが示されている場合があります。検出結果に示されているリモート IP アドレスが予期しない接続元である場合は、セキュリティグループを監査してください。データベースにアタッチされたセキュリティグループのリストは、[https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/) コンソールの **[セキュリティグループ]**、または検出結果 JSON の `resource.rdsDbInstanceDetails.dbSecurityGroups` で確認できます。セキュリティグループの設定については、「[Amazon RDS ユーザーガイド](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.RDSSecurityGroups.html)」の「*セキュリティグループによるアクセス制御*」を参照してください。
ファイアウォールを使用している場合は、ネットワークアクセスコントロールリスト (NACL) を再設定して、データベースへのネットワークアクセスを制限します。詳細については、「*AWS Network Firewall デベロッパーガイド*」の「[AWS Network Firewallのファイアウォール](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewalls.html)」を参照してください。
# 侵害された可能性のある Lambda 関数の修復
GuardDuty が [Lambda Protection の検出結果タイプ](lambda-protection-finding-types.md)を生成するときに、Lambda 関数が侵害される可能性があります。この検出結果の原因となったアクティビティが想定内である場合は、[抑制ルール](findings_suppression-rule.md)の使用を検討してみてください。侵害された Lambda 関数を修正するには、以下の手順を実行することをお勧めします。
**Lambda Protection の検出結果を修正するには**
1. **侵害された可能性のある Lambda 関数のバージョンを確認します**。
Lambda Protection の GuardDuty の検出結果では、検出結果の詳細に記載されている Lambda 関数に関連する名前、Amazon リソースネーム (ARN)、関数バージョン、リビジョン ID がわかります。
1. **疑わしいアクティビティのソースを識別します**。
1. 検出結果に含まれる Lambda 関数のバージョンに関連するコードを確認してください。
1. インポートされたライブラリと、検出結果に関係する Lambda 関数バージョンのレイヤーを確認します。
1. [Amazon Inspector で AWS Lambda 関数のスキャン](https://docs.aws.amazon.com/inspector/latest/user/scanning-lambda.html)を有効にしている場合は、[検出結果に関連する Lambda 関数に関連付けられた Amazon Inspector ](https://docs.aws.amazon.com/inspector/latest/user/findings-understanding-locating-analyzing.html) の検出結果を確認します。
1. AWS CloudTrail ログを確認して、関数の更新の原因となったプリンシパルを特定し、アクティビティが承認または予期されたことを確認します。
1. **侵害された可能性のある Lambda 関数を修復します**。
1. 検出結果に関係する Lambda 関数の実行トリガーを無効にします。詳細については、「[DeleteFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/dg/API_DeleteFunctionEventInvokeConfig.html)」を参照してください。
1. Lambda コードを確認し、ライブラリのインポートと [Lambda 関数レイヤー](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html)を更新して、潜在的に疑わしいライブラリとレイヤーを削除します。
1. 検出結果に関係した Lambda 関数に関連する Amazon Inspector の検出結果を軽減します。