기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 보안 조사 결과 분류 및 문제 해결에 대한 예제
이 섹션에서는 보안, 클라우드 및 애플리케이션 팀을 위한 분류 프로세스 예제를 검토합니다. 여기에서는 각 팀이 공통적으로 다루는 조사 결과 유형에 대해 설명하고 대응 방법의 예제를 제공합니다. 상위 수준의 문제 해결 지침도 포함되어 있습니다.
**Topics**
+ [보안 팀 예제: Security Hub CSPM 자동화 규칙 생성](security-team-example.md)
+ [클라우드 팀 예제: VPC 구성 변경](cloud-team-example.md)
+ [애플리케이션 팀 예제: AWS Config 규칙 생성](application-team-example.md)
# 보안 팀 예제: Security Hub CSPM 자동화 규칙 생성
보안 팀은 Amazon GuardDuty 조사 결과를 포함하여 위협 감지와 관련된 조사 결과를 받습니다. AWS 리소스 유형별로 분류된 GuardDuty 결과 유형의 전체 목록은 GuardDuty 설명서의 [결과 유형을](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html) 참조하세요. 보안 팀은 이러한 모든 조사 결과 유형에 익숙해야 합니다.
이 예제에서 보안 팀은 학습 목적으로만 AWS 계정 사용되고 중요하거나 민감한 데이터를 포함하지 않는의 보안 조사 결과에 대한 관련 위험 수준을 수락하고 있습니다. 이 계정의 이름은 `sandbox`이고 계정 ID는 `123456789012`입니다. 보안 팀은이 계정의 모든 GuardDuty 조사 결과를 억제하는 AWS Security Hub CSPM 자동화 규칙을 생성할 수 있습니다. 템플릿에서 여러 가지 일반적인 사용 사례를 다루는 규칙을 생성하거나 사용자 지정 규칙을 생성할 수 있습니다. Security Hub CSPM에서는 기준 결과를 미리 보고 규칙이 의도한 결과를 반환하는지 확인하는 것이 좋습니다.
**참고**
이 예제에서는 자동화 규칙의 기능을 강조합니다. 계정에 대한 모든 GuardDuty 조사 결과를 억제하지 않는 것이 좋습니다. 컨텍스트가 중요하므로 각 조직은 데이터 유형, 분류 및 완화 제어를 기반으로 억제할 조사 결과를 선택해야 합니다.
다음은 이 자동화 규칙을 생성하는 데 사용된 파라미터입니다.
+ **규칙:**
+ **규칙 이름**: `Suppress findings from Sandbox account`
+ **규칙 설명**: `Date: 06/25/23 Authored by: John Doe Reason: Suppress GuardDuty findings from the sandbox account`
+ **기준:**
+ `AwsAccountId` = `123456789012`
+ `ProductName` = `GuardDuty`
+ `WorkflowStatus` = `NEW`
+ `RecordState` = `ACTIVE`
+ **자동화된 작업:**
+ `Workflow.status`은(는) `SUPPRESSED`
자세한 내용은 Security Hub CSPM 설명서의 [자동화 규칙을](https://docs.aws.amazon.com/securityhub/latest/userguide/automation-rules.html) 참조하세요. 보안 팀은 감지된 위협에 대한 조사 결과를 조사하고 해결할 수 있는 다양한 옵션을 제공합니다. 광범위한 지침은 [AWS 보안 인시던트 대응 지침](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)을 참조하세요. 이 지침을 검토하여 강력한 인시던트 대응 프로세스를 수립했는지 확인하는 것이 좋습니다.
# 클라우드 팀 예제: VPC 구성 변경
클라우드 팀은 사용 사례에 적합하지 않을 수 있는 AWS 기본 설정 변경과 같은 일반적인 추세가 있는 보안 조사 결과를 분류하고 수정할 책임이 있습니다. 이러한 결과는 VPC 구성과 같은 많은 AWS 계정 또는 리소스에 영향을 미치는 경향이 있거나 전체 환경에 적용해야 하는 제한을 포함합니다. 대부분의 경우 클라우드 팀은 정책 추가 또는 업데이트와 같은 일회성 수동 변경을 수행합니다.
조직에서 환경을 AWS 사용한 후 개발 중인 안티 패턴 세트를 찾을 수 있습니다. *안티 패턴*은 솔루션이 다른 솔루션보다 비생산적이거나 비효율적이거나 덜 효과적이어서 반복되는 문제에 자주 사용되는 솔루션입니다. 이러한 안티 패턴의 대안으로 조직은 AWS Organizations 서비스 제어 정책(SCPs) 또는 IAM Identity Center 권한 세트와 같이 보다 효과적인 환경 전반의 제한을 사용할 수 있습니다. SCP 및 권한 세트는 사용자가 퍼블릭 Amazon Simple Storage Service(Amazon S3) 버킷을 구성하지 못하도록 하는 등 리소스 유형에 대한 추가 제한 사항을 제공할 수 있습니다. 가능한 모든 보안 구성을 제한하고 싶을 수 있지만 SCP 및 권한 세트에는 정책 크기 제한이 있습니다. 선제적 제어 및 감지 제어에 균형 잡힌 접근 방식을 사용하는 것이 좋습니다.
다음은 클라우드 팀이 담당할 수 있는 AWS Security Hub CSPM [기본 보안 모범 사례(FSBP)](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html) 표준의 몇 가지 제어입니다.
+ [[EC2.2] VPC 기본 보안 그룹은 인바운드 및 아웃바운드 트래픽을 허용해서는 안 됩니다.](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-2)
+ [[EC2.6] 모든 VPC에서 VPCs 흐름 로깅을 활성화해야 합니다.](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-6)
+ [[EC2.23] Amazon EC2 Transit Gateway는 VPC 연결 요청을 자동으로 수락해서는 안 됩니다.](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-23)
+ [[CloudTrail.1] CloudTrail은 읽기 및 쓰기 관리 이벤트를 포함하는 다중 리전 추적을 하나 이상 활성화하고 구성해야 합니다.](https://docs.aws.amazon.com/securityhub/latest/userguide/cloudtrail-controls.html#cloudtrail-1)
+ [[Config.1]를 활성화해야 AWS Config 합니다.](https://docs.aws.amazon.com/securityhub/latest/userguide/config-controls.html#config-1)
이 예제에서 클라우드 팀은 FSBP 제어 EC2.2에 대한 조사 결과를 처리하고 있습니다. 이 제어에 대한 [설명서](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-2)에서는 기본 인바운드 및 아웃바운드 규칙을 통해 광범위한 액세스를 허용하므로 기본 보안 그룹을 사용하지 않는 것이 좋습니다. 기본 보안 그룹은 삭제할 수 없으므로 기본 보안 그룹 규칙 설정을 변경하여 인바운드 및 아웃바운드 트래픽을 제한하는 것이 좋습니다. 이 문제를 효율적으로 해결하려면 클라우드 팀이 설정된 메커니즘을 사용하여 모든 VPC에 대한 보안 그룹 규칙을 수정해야 합니다. 각 VPC에 이 기본 보안 그룹이 있기 때문입니다. 대부분의 경우 클라우드 팀은 [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) 사용자 지정 또는 코드형 인프라(IaC) 도구(예: [https://www.terraform.io/](https://www.terraform.io/) 또는 [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html))를 사용하여 VPC 구성을 관리합니다.
# 애플리케이션 팀 예제: AWS Config 규칙 생성
다음은 애플리케이션 또는 개발 팀이 담당할 수 있는 Security Hub CSPM [기본 보안 모범 사례(FSBP)](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html) 보안 표준의 몇 가지 제어입니다.
+ [[CloudFront.1] CloudFront 배포에는 기본 루트 객체가 구성되어 있어야 합니다.](https://docs.aws.amazon.com/securityhub/latest/userguide/cloudfront-controls.html#cloudfront-1)
+ [[EC2.19] 보안 그룹은 위험이 높은 포트에 대한 무제한 액세스를 허용해서는 안 됩니다.](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-19)
+ [[CodeBuild.1] CodeBuild GitHub 또는 Bitbucket 소스 리포지토리 URLs은 OAuth를 사용해야 합니다.](https://docs.aws.amazon.com/securityhub/latest/userguide/codebuild-controls.html#codebuild-1)
+ [[ECS.4] ECS 컨테이너는 권한이 없는 상태로 실행되어야 합니다.](https://docs.aws.amazon.com/securityhub/latest/userguide/ecs-controls.html#ecs-4)
+ [[ELB.1] 모든 HTTP 요청을 HTTPS로 리디렉션하도록 Application Load Balancer를 구성해야 합니다.](https://docs.aws.amazon.com/securityhub/latest/userguide/elb-controls.html#elb-1)
이 예제에서 애플리케이션 팀은 FSBP 제어 EC2.19에 대한 조사 결과를 처리하고 있습니다. 이 제어는 보안 그룹에 대한 무제한 수신 트래픽이 가장 위험이 높은 지정된 포트에 액세스할 수 있는지 여부를 확인합니다. 보안 그룹의 규칙 중 하나라도 해당 포트에 대해 `0.0.0.0/0` 또는 `::/0`의 수신 트래픽을 허용하는 경우 이 제어는 실패합니다. 이 제어에 대한 [설명서](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-19)에서는 이 트래픽을 허용하는 규칙을 삭제할 것을 권장합니다.
이는 개별 보안 그룹 규칙을 해결하는 것 외에도 새로운 AWS Config [규칙](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)이 발생해야 하는 조사 결과의 좋은 예입니다. [선제적 평가 모드](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config-rules.html#aws-config-rules-evaluation-modes)를 사용하면 향후 위험한 보안 그룹 규칙의 배포를 방지할 수 있습니다. 선제적 모드는 리소스가 배포되기 전에 리소스를 평가하므로 잘못 구성된 리소스 및 관련 보안 조사 결과를 방지할 수 있습니다. 새 서비스 또는 새 기능을 구현할 때 애플리케이션 팀은 지속적 통합 및 지속적 전송(CI/CD) 파이프라인의 일부로 선제적 예방 모드에서 규칙을 실행하여 규정을 준수하지 않는 리소스를 식별할 수 있습니다. 다음 이미지는 사전 AWS Config 예방적 규칙을 사용하여 AWS CloudFormation 템플릿에 정의된 인프라가 규정을 준수하는지 확인하는 방법을 보여줍니다.
![\[AWS CloudFormation 템플릿의 규정 준수를 확인하는 사전 예방 AWS Config 규칙\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/vulnerability-management/images/cloudformation-config-proactive-workflow.png)
이 예제에서는 또 다른 중요한 효율성을 얻을 수 있습니다. 애플리케이션 팀이 선제적 AWS Config 규칙을 생성하면 다른 애플리케이션 팀이 사용할 수 있도록 공통 코드 리포지토리에서 공유할 수 있습니다.
Security Hub CSPM 제어와 연결된 각 결과에는 결과에 대한 세부 정보와 문제 해결 지침 링크가 포함되어 있습니다. 클라우드 팀은 일회성 수동 수정이 필요한 조사 결과를 발견할 수 있지만 적절한 경우 개발 프로세스에서 가능한 한 빨리 문제를 식별하는 선제적 검사를 빌드하는 것이 좋습니다.