기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 탐지된 GuardDuty 보안 조사 결과 해결
Amazon GuardDuty는 GuardDuty 기본 위협 탐지 및 전용 보호 계획과 관련된 잠재적 보안 조사 결과를 나타내는 [조사 결과](guardduty_findings.md)를 생성합니다. 다음 섹션에서는 이러한 시나리오에 대한 권장 해결 단계를 설명합니다. 대체 해결 시나리오가 있는 경우 각 발견 유형에 대한 설명에 해당 시나리오가 설명되어 있습니다. [활성 결과 유형 표](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 보호 조사 결과 해결](guardduty-remediate-kubernetes.md)
+ [런타임 모니터링 조사 결과 해결](guardduty-remediate-runtime-monitoring.md)
+ [잠재적으로 손상된 데이터베이스 해결](guardduty-remediate-compromised-database-rds.md)
+ [잠재적으로 손상된 Lamda 기능 해결](remediate-lambda-protection-finding-types.md)
# 잠재적으로 손상된 Amazon EC2 인스턴스 문제 해결
GuardDuty가 [잠재적으로 손상된 Amazon EC2 리소스를 나타내는 조사 결과 유형](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html#findings-table)을 생성하면 **리소스**는 **인스턴스**가 됩니다. 잠재적 조사 결과 유형은 [EC2 결과 유형](guardduty_finding-types-ec2.md), [GuardDuty 런타임 모니터링 조사 결과 유형](findings-runtime-monitoring.md) 또는 [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. 잠재적으로 손상된 인스턴스에서 새로 생성된 **격리** 보안 그룹을 제외한 모든 보안 그룹 연결을 제거합니다.
**참고**
기존 추적된 연결은 보안 그룹 변경으로 인해 종료되지 않으며, 향후 트래픽만 새 보안 그룹에 의해 효과적으로 차단됩니다.
의심스러운 기존 연결에서 추가 트래픽을 차단하는 방법에 대한 자세한 내용은 *Incident Response Playbook*의 [네트워크 IoCs를 기반으로 NACLs 적용](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. **기술 지원 요청 제출**
Premium Support 패키지를 구독하는 경우 [기술 지원](https://console.aws.amazon.com/support/home#/case/create?issueType=technical) 요청을 제출할 수 있습니다.
# 잠재적으로 손상된 S3 버킷 해결
GuardDuty가 [GuardDuty S3 보호 조사 결과 유형](guardduty_finding-types-s3.md)를 생성하면 Amazon S3 버킷이 손상되었음을 나타냅니다. 조사 결과를 야기한 동작이 환경에서 예상되는 경우 [억제 규칙](findings_suppression-rule.md) 생성을 고려하세요. 이 동작이 예상되지 않은 경우 다음 권장 단계에 따라 AWS 환경에서 잠재적으로 손상된 Amazon S3 버킷을 해결합니다.
1. **잠재적으로 손상된 S3 리소스를 식별합니다.**
S3에 대한 GuardDuty 검색은 검색 세부 정보에 연결된 S3 버킷, 해당 ARN(Amazon 리소스 이름) 및 소유자를 나열합니다.
1. **의심스러운 활동과 사용된 API 직접 호출의 소스를 식별합니다.**
사용된 API 호출은 결과 세부 정보에 `API`로 나열됩니다. 소스는 IAM 보안 주체(IAM 역할, 사용자 또는 계정)이며 식별 세부 정보는 결과에 나열됩니다. 소스 유형에 따라 원격 IP 주소 또는 소스 도메인 정보가 제공되며 소스가 승인되었는지 여부를 평가하는 데 도움이 될 수 있습니다. 결과에 Amazon EC2 인스턴스의 보안 인증 정보가 포함된 경우 해당 리소스에 대한 세부 정보도 포함됩니다.
1. **직접 호출 소스가 식별된 리소스에 액세스할 권한이 있는지 확인합니다.**
예를 들어 다음을 고려합니다.
+ IAM 사용자가 연루된 경우 해당 사용자의 자격 증명이 잠재적으로 유출되었을 가능성이 있나요? 자세한 내용은 [잠재적으로 손상된 AWS 자격 증명 문제 해결](compromised-creds.md) 단원을 참조하십시오.
+ 이전에 이러한 유형의 API를 간접적으로 호출한 기록이 없는 보안 주체가 API를 간접적으로 호출한 경우 이 소스에 이 작업에 대한 액세스 권한이 필요합니까? 버킷 권한이 추가로 제한될 수 있나요?
+ **사용자 유형**이 `AWSAccount`인 **사용자 이름** `ANONYMOUS_PRINCIPAL`의 액세스가 확인된 경우 이는 버킷이 퍼블릭 상태이고 액세스되었음을 나타냅니다. 이 버킷이 퍼블릭 상태여야 하나요? 그렇지 않은 경우 아래 보안 권장 사항에서 S3 리소스 공유를 위한 대체 솔루션을 검토하세요.
+ **사용자 유형**이 `AWSAccount`인 **사용자 이름** `ANONYMOUS_PRINCIPAL`로부터의 성공적인 `PreflightRequest` 직접 호출을 통해 액세스가 이루어졌다면 이는 버킷에 교차 오리진 리소스 공유(CORS) 정책이 설정되어 있음을 나타냅니다. 이 버킷에 CORS 정책이 있어야 합니까? 그렇지 않은 경우 버킷이 실수로 인해 퍼블릭 상태가 되지 않도록 하고 아래 보안 권장 사항에서 S3 리소스 공유를 위한 대체 솔루션을 검토하세요. CORS에 대한 자세한 내용은 S3 사용 설명서의 [교차 오리진 리소스 공유(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 버킷의 객체에서 민감한 데이터를 검사할 수 있습니다. 자세한 내용은 [Discovering sensitive data with Macie](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 계정에 대해 퍼블릭 액세스 차단 설정을 활성화하여 액세스 세부 수준을 제어할 수 있습니다. 자세한 내용은 *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 버킷 정책에 Virtual Private Cloud(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 사용자 안내서](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html)의 *미리 서명된 URL을 통해 객체 다운로드 및 업로드*를 참조하세요.
+ 서로 다른 소스 간에 S3 객체를 공유해야 하는 사용 사례의 경우 S3 액세스 포인트를 사용하여 프라이빗 네트워크 내에 있는 사용자에게만 액세스를 제한하는 권한 세트를 생성할 수 있습니다. 자세한 내용은 *Amazon S3 사용 설명서*에서 [액세스 포인트로 공유 데이터세트에 대한 액세스 관리](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-points.html)를 참조하세요.
+ 다른 AWS 계정에 S3 리소스에 대한 액세스 권한을 안전하게 부여하려면 액세스 제어 목록(ACL)을 사용할 수 있습니다. 자세한 내용은 *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가 [S3용 맬웨어 보호 결과 유형](gdu-malware-protection-s3-finding-types.md)를 생성하면 Amazon S3 버킷에 새로 업로드된 객체에 맬웨어가 포함되어 있음을 나타냅니다. 리소스 유형은 **S3Object**입니다.
생성된 조사 결과를 잠재적으로 수정하려면 다음 권장 단계를 따르세요.
1. 조사 결과와 연관된 **S3ObjectDetails**를 확인하여 잠재적으로 악성일 수 있는 S3 객체를 식별합니다.
1. 영향을 받는 S3 객체를 격리합니다. 연결된 Amazon S3 버킷에 대해 S3용 맬웨어 방지를 활성화할 때 태그 지정을 활성화한 경우 GuardDuty가 이 객체에 **악성** 태그를 할당했어야 합니다. 태그 기반 액세스 제어(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 설명서를](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-snapshot-attribute.html) 참조하세요.
1. **문제 해결 조치 수행**
+ 삭제를 진행하기 전에 모든 종속성을 식별하고 필요한 경우 적절한 백업이 있는지 확인합니다.
# 잠재적으로 손상된 EC2 AMI 문제 해결
GuardDuty가 Execution:EC2/MaliciousFile\$1AMI 결과 유형을 생성하면 Amazon Machine Image(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가를 생성하면 자격 AWS 증명이 손상되었음을 [IAM 결과 유형](guardduty_finding-types-iam.md)나타냅니다. 잠재적으로 손상된 **리소스** 유형은 **AccessKey**입니다.
AWS 환경에서 잠재적으로 손상된 자격 증명을 해결하려면 다음 단계를 수행합니다.
1. **잠재적으로 손상된 IAM 엔터티와 사용된 API 호출을 식별합니다.**
사용된 API 호출은 결과 세부 정보에 `API`로 나열됩니다. IAM 엔터티(IAM 역할 또는 사용자)와 해당 식별 정보는 검색 세부정보의 **리소스** 섹션에 나열됩니다. 관련된 IAM 엔터티의 유형은 **User Type(사용자 유형)** 필드에 의해 결정될 수 있으며 IAM 엔터티의 이름은 **User name(사용자 이름)** 필드에 표시됩니다. 결과에 관여한 IAM 엔터티의 유형은 사용된 **Access key ID(Access 키 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 참조하세요.
역할을 사용한 경우 **사용자 이름** 필드에는 사용된 역할의 이름이 표시됩니다. CloudTrail 로그 항목의 `sessionIssuer` 요소를 검사 AWS CloudTrail 하여에서 키가 요청된 방식을 확인할 수 있습니다. 자세한 내용은 [ CloudTrail의 IAM 및 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 계정가 손상되었기 때문일 수 있습니다. 자격 증명이 손상되었다고 의심되는 경우 [내 정보가 손상되었을 AWS 계정 수](https://repost.aws/knowledge-center/potential-account-compromise) 있음을 검토하여이 문제를 해결하세요.
# 잠재적으로 손상된 독립형 컨테이너 문제 해결
GuardDuty가 [잠재적으로 손상된 컨테이너를 나타내는 조사 결과 유형](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 콘솔을 엽니다.
+ **조사 결과** 페이지에서 해당 조사 결과를 선택하여 조사 결과 패널을 확인합니다.
+ 결과 패널의 **영향을 받는 리소스** 섹션에서 컨테이너의 **ID**와 **이름**을 볼 수 있습니다.
이 컨테이너를 다른 컨테이너 워크로드로부터 격리합니다.
1. **컨테이너 일시 중지**
컨테이너의 모든 프로세스를 일시 중단합니다.
컨테이너 동결에 대한 자세한 내용은 [컨테이너 일시 중지](https://docs.docker.com/engine/api/v1.35/#tag/Container/operation/ContainerPause)를 참조하세요.
**컨테이너를 중지합니다**.
위 단계에 실패하고 컨테이너가 일시 중지되지 않으면 컨테이너 실행을 중지하세요. [스냅샷 보존](malware-protection-customizations.md#mp-snapshots-retention) 기능을 활성화한 경우 GuardDuty는 맬웨어가 포함된 EBS 볼륨의 스냅샷을 보관합니다.
컨테이너를 중지하는 방법에 대한 자세한 내용은 [컨테이너 중지](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 보호 조사 결과 해결
Amazon GuardDuty는 계정에 대해 EKS 보호가 활성화된 경우 잠재적인 Kubernetes 보안 문제를 나타내는 [조사 결과](guardduty_findings.md)를 생성합니다. 자세한 내용은 [EKS 보호](kubernetes-protection.md) 단원을 참조하십시오. 다음 섹션에서는 이러한 시나리오에 대한 권장 해결 단계를 설명합니다. 특정 문제 해결 조치는 해당 결과 유형의 항목에 설명되어 있습니다. [활성 결과 유형 표](guardduty_finding-types-active.md)에서 선택하여 결과 유형에 대한 전체 정보에 액세스할 수 있습니다.
EKS 보호 발견 유형 중 하나가 예상대로 생성된 경우 향후 경고를 방지하기 위해 [GuardDuty의 억제 규칙](findings_suppression-rule.md)를 추가하는 것을 고려할 수 있습니다.
다양한 유형의 공격과 구성 문제가 GuardDuty EKS 보호 조사 결과를 트리거할 수 있습니다. 이 설명서는 클러스터에 대한 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 사용자 세부 정보** 섹션 또는 결과 JSON의 `resource.kubernetesDetails.kubernetesUserDetails`에서 사용자를 식별할 수 있습니다. 이러한 사용자 세부 정보에는 `user name`, `uid` 및 사용자가 속한 Kubernetes 그룹이 포함됩니다.
사용자가 IAM 엔터티를 사용하여 워크로드에 액세스하는 경우 `Access Key details` 섹션을 사용하여 IAM 역할 또는 사용자의 세부 정보를 식별할 수 있습니다. 다음 사용자 유형 및 해결 지침을 참조하세요.
**참고**
Amazon Detective를 사용하여 결과에서 식별된 IAM 역할 또는 사용자를 추가로 조사할 수 있습니다. GuardDuty 콘솔에서 결과 세부 정보를 보는 동안 **Detective에서 조사**를 선택합니다. 그런 다음 나열된 항목에서 AWS 사용자 또는 역할을 선택하여 Detective에서 조사합니다.
**기본 제공 Kubernetes 관리자** - Amazon EKS에서 클러스터를 생성한 IAM ID에 할당한 기본 사용자입니다. 이 사용자 유형은 사용자 이름 `kubernetes-admin`으로 식별됩니다.
**기본 제공 Kubernetes 관리자의 액세스 권한 철회:**
+ `Access Key details` 섹션에서 `userType`을 찾습니다.
+ `userType`이 **역할**이고 역할이 EC2 인스턴스 역할에 속하는 경우:
+ 해당 인스턴스를 식별한 다음 [잠재적으로 손상된 Amazon EC2 인스턴스 문제 해결](compromised-ec2.md)의 지침을 따릅니다.
+ `userType`이 **사용자**이거나 사용자가 맡은 **역할**인 경우:
1. 해당 사용자의 [액세스 키를 교체](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)합니다.
1. 사용자가 액세스할 수 있었던 모든 보안 암호를 교체합니다.
1. 자세한 내용은 [내 정보가 손상되었을 AWS 계정 수 있음을](https://repost.aws/knowledge-center/potential-account-compromise) 검토하세요.
**OIDC 인증 사용자** - OIDC 공급자를 통해 액세스 권한이 부여된 사용자입니다. 일반적으로 OIDC 사용자는 이메일 주소를 사용자 이름으로 사용합니다. `aws eks list-identity-provider-configs --cluster-name your-cluster-name ` 명령으로 클러스터가 OIDC를 사용하는지 확인할 수 있습니다.
**OIDC 인증 사용자의 액세스 철회:**
1. OIDC 공급자에서 해당 사용자의 보안 인증 정보를 교체합니다.
1. 사용자가 액세스할 수 있었던 모든 보안 암호를 교체합니다.
**AWS-Auth ConfigMap 정의 사용자** AWS- 인증 ConfigMap을 통해 액세스 권한이 부여된 IAM 사용자입니다. 자세한 내용은 **Amazon EKS 사용 설명서**의 [클러스터의 사용자 또는 IAM 역할 관리](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. **mapRoles** 또는 **mapUsers** 섹션의 역할 또는 사용자 항목이 GuardDuty 결과의 Kubernetets 사용자 세부 정보 섹션에 보고된 것과 같은 사용자 이름인지 식별합니다. 다음 예시에서는 관리자가 결과에서 식별되었습니다.
```
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`이 **사용자**이거나 사용자가 맡은 **역할**인 경우:
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 서비스 계정입니다.
**서비스 계정** - 서비스 계정은 포드의 ID를 제공하고 `system:serviceaccount:namespace:service_account_name` 형식의 사용자 이름으로 식별할 수 있습니다.
**서비스 계정에 대한 액세스 권한 철회:**
1. 서비스 계정 보안 인증 정보를 교체합니다.
1. 다음 섹션의 포드 손상 안내를 검토합니다.
## 잠재적으로 손상된 Kubernetes 포드 해결
GuardDuty가 `resource.kubernetesDetails.kubernetesWorkloadDetails` 섹션 내에서 파드 또는 워크로드 리소스에 대한 세부 정보를 지정하면 해당 파드 또는 워크로드 리소스가 잠재적으로 손상되었을 가능성이 있습니다. GuardDuty 결과는 단일 포드가 손상되었거나 상위 수준 리소스를 통해 여러 포드가 손상되었음을 나타낼 수 있습니다. 손상된 포드를 식별하는 방법에 대한 지침은 다음 보안 침해 시나리오를 참조하세요.
**단일 포드 손상**
`resource.kubernetesDetails.kubernetesWorkloadDetails` 섹션 내 `type` 필드가 **포드**인 경우 결과에서 단일 포드가 식별됩니다. 이름 필드는 포드의 `name`이고 `namespace` 필드는 네임스페이스입니다.
포드를 실행 중인 워커 노드를 식별하는 방법에 대한 정보는 *Amazon EKS 모범 사례 가이드*의 [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) 섹션을 참조하세요.
**워크로드 리소스를 통해 포드가 손상됨**
`resource.kubernetesDetails.kubernetesWorkloadDetails` 섹션 내 `type` 필드에서 **워크로드 리소스**(예: `Deployment`)가 식별되면 해당 워크로드 리소스 내의 모든 포드가 손상되었을 수 있습니다.
워크로드 리소스의 모든 포드와 해당 포드가 실행 중인 노드를 식별하는 방법에 대한 정보는 *Amazon EKS 모범 사례 설명서*의 [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` 섹션에서 Service Account가 식별되면 식별된 서비스 계정을 사용하는 포드가 손상되었을 수 있습니다. 형식이 `system:serviceaccount:namespace:service_account_name`인 경우 결과에 보고된 사용자 이름은 서비스 계정입니다.
서비스 계정을 사용하여 모든 포드를 식별하고 해당 포드가 실행 중인 노드에 대한 정보는 *Amazon EKS 모범 사례 가이드*의 [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 모범 사례 가이드*의 [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 모범 사례 가이드*의 [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) 섹션을 참조하세요.
작업자 노드에 포드가 다른 AWS 리소스에 액세스할 수 있는 IAM 역할이 할당된 경우 해당 역할을 인스턴스에서 제거하여 공격으로 인한 추가 손상을 방지합니다. 마찬가지로 포드에 IAM 역할이 할당된 경우 다른 워크로드에 영향을 미치지 않으면서 역할에서 IAM 정책을 안전하게 제거할 수 있는지 평가합니다.
## 잠재적으로 손상된 컨테이너 이미지 수정
GuardDuty 결과에서 포드 손상이 나타나면 포드를 시작하는 데 사용된 이미지가 잠재적으로 악의적이거나 손상된 것일 수 있습니다. GuardDuty 결과의 `resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image` 필드에 컨테이너 이미지가 있습니다. 맬웨어를 스캔하여 이미지가 악성인지 확인할 수 있습니다.
**잠재적으로 손상된 컨테이너 이미지를 수정합니다**
1. 이미지 사용을 즉시 중지하고 이미지 리포지토리에서 이미지를 제거합니다.
1. 손상 가능성이 있는 이미지를 사용하여 모든 포드를 식별합니다.
자세한 내용은 *Amazon EKS 모범 사례 가이드*의 [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 모범 사례 가이드*의 [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 결과는 결과에서 식별된 사용자가 노드 ID를 나타내거나 결과가 권한 있는 컨테이너의 사용을 나타내는 경우 노드 손상을 나타낼 수 있습니다.
**사용자 이름** 필드에 `system:node:node name` 형식이 있는 경우 사용자 ID는 워커 노드입니다. 예를 들어 `system:node:ip-192-168-3-201.ec2.internal`입니다. 이는 공격자가 노드에 대한 액세스 권한을 얻었고 노드의 보안 인증 정보를 사용하여 Kubernetes API 엔드포인트와 통신하고 있음을 나타냅니다.
결과에 나열된 하나 이상의 컨테이너에 `resource.kubernetesDetails.kubernetesWorkloadDetails.containers.securityContext.privileged` 결과 필드가 `True`로 설정된 경우 결과에서 권한이 있는 컨테이너의 사용을 나타냅니다.
**잠재적으로 손상된 노드를 해결하려면:**
1. 포렌식 분석을 위해 포드를 격리하고, 자격 증명을 교체하고, 데이터를 수집하세요.
자세한 내용은 *Amazon EKS 모범 사례 가이드*의 [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. 잠재적으로 손상된 노드를 종료합니다.
# 런타임 모니터링 조사 결과 해결
계정에 대해 런타임 모니터링을 활성화하면 Amazon GuardDuty에서 AWS 환경의 잠재적 보안 문제를 [GuardDuty 런타임 모니터링 조사 결과 유형](findings-runtime-monitoring.md) 나타내는를 생성할 수 있습니다. 잠재적인 보안 문제는 환경의 손상된 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 런타임 모니터링 검색은 검색의 세부 정보 패널 또는 검색 JSON의 `resource.ecsClusterDetails` 섹션에서 ECS 클러스터 세부 정보를 제공합니다.
1. **영향을 받는 ECS 작업 식별**
GuardDuty 런타임 모니터링 조사 결과는 조사 결과의 세부 정보 패널 또는 조사 결과 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. 손상된 이미지를 사용하는 모든 작업을 중지합니다. 손상된 이미지 사용을 중지하도록 작업 정의를 업데이트합니다.
# 잠재적으로 손상된 데이터베이스 해결
GuardDuty는 [RDS 보호](rds-protection.md) 활성화 후 [지원되는 데이터베이스](rds-protection.md#rds-pro-supported-db)에서 발생할 수 있는 의심스럽고 비정상적인 로그인 동작을 나타내는 [RDS 보호 결과 유형](findings-rds-protection.md)을 생성합니다. 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 결과의 결과 패널 아래에 있는 **작업자** 섹션에서는 **IP 주소** 및 **ASN 조직**(퍼블릭 연결인 경우)이 제공됩니다.
Autonomous System(AS)은 명확하게 정의된 단일 라우팅 정책을 유지하는 하나 이상의 네트워크 운영자가 실행하는 하나 이상의 IP 접두사 그룹입니다(네트워크에서 액세스할 수 있는 IP 주소 목록). 네트워크 운영자가 네트워크 내 라우팅을 제어하고 다른 인터넷 서비스 제공업체(ISP)와 라우팅 정보를 교환하려면 Autonomous System Number(ASN)가 필요합니다.
1. **이 동작이 예상치 않은 것인지 확인합니다.**
다음과 같이 이 활동이 데이터베이스에 대한 추가 무단 액세스 권한을 얻으려는 시도를 나타내는지 검사합니다.
+ 내부 소스인 경우 애플리케이션이 잘못 구성되어 있고 연결을 반복해서 시도하고 있지 않은지 검사합니다.
+ 외부 작업자인 경우 해당 데이터베이스가 공개되어 있거나 잘못 구성되어 있어 잠재적인 악성 공격자가 일반적인 사용자 이름을 무차별 대입할 수 있는지 확인합니다.
1. **예상치 않은 동작이 발생한 경우 이 단계를 시작합니다.**
1. **데이터베이스 액세스 제한**
의심되는 계정 및 이 로그인 활동의 출처에 대한 데이터베이스 액세스를 제한합니다. 자세한 내용은 [손상되었을 수 있는 보안 인증 정보 문제 해결](#gd-rds-database-compromised-credentials) 및 [네트워크 액세스 제한](#gd-rds-database-restrict-network-access) 섹션을 참조하세요.
1. **근본 원인 분석을 수행하고 이러한 활동의 원인이 될 수 있었던 단계를 파악합니다.**
활동으로 인해 네트워킹 정책이 수정되어 안전하지 않은 상태가 발생할 경우 알림을 받도록 설정합니다. 자세한 내용은AWS Network Firewall 개발자 안내서**의 [Firewall policies in AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-policies.html)을 참조하세요.
## 손상되었을 수 있는 보안 인증 정보 문제 해결
GuardDuty 결과는 결과에서 식별된 사용자가 예상치 못한 데이터베이스 작업을 수행했을 때 영향을 받는 데이터베이스의 사용자 보안 인증 정보가 손상되었음을 나타낼 수 있습니다. 콘솔의 결과 패널에 있는 **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 사용 설명서**의 [Security best practices for Amazon Relational Database Service](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_BestPractices.Security.html)를 참조하세요.
## 네트워크 액세스 제한
GuardDuty 결과가 애플리케이션 또는 Virtual Private Cloud(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 개발자 안내서**의 [Firewalls in AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewalls.html)을 참조하세요.
# 잠재적으로 손상된 Lamda 기능 해결
GuardDuty가 [Lambda 보호 결과 유형](lambda-protection-finding-types.md)를 생성하면 Lambda 함수가 손상될 수 있습니다. GuardDuty가 이 결과를 생성하도록 만든 활동이 예상되었다면 [억제 규칙](findings_suppression-rule.md) 사용을 고려할 수 있습니다. 손상된 Lambda 함수 문제를 해결하려면 다음 단계를 완료하는 것이 좋습니다.
**Lambda 보호 결과 해결**
1. **잠재적으로 손상된 람다 함수 버전을 식별합니다**.
Lambda 보호에 대한 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. **잠재적으로 손상된 람다 기능 수정**.
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 결과를 완화하세요.