기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# AWS 환경의 보안 조사 결과 분류 및 해결
보안 조사 결과를 분류하려면 조사 결과를 적절한 이해관계자에게 전달하고, 조사 결과를 평가하며, 우선순위를 지정한 다음 문제를 해결하는 과정이 포함됩니다. 이 섹션에서는 이러한 각 단계를 자세히 검토하고 확장성 및 효율성에 대한 권장 사항을 제공합니다. 분류 및 문제 해결 프로세스를 설명하는 데 도움이 되는 예제도 포함되어 있습니다.
**Topics**
+ [보안 조사 결과의 소유권 정의](define-ownership-of-security-findings.md)
+ [보안 조사 결과 평가 및 우선순위 지정](assess-and-prioritize-security-findings.md)
+ [보안 조사 결과 문제 해결](remediate-security-findings.md)
+ [보안 조사 결과 분류 및 문제 해결에 대한 예제](triage-remediation-examples.md)
# 보안 조사 결과의 소유권 정의
보안 조사 결과를 분류하기 위해 소유권 모델을 정의하는 것은 어려울 수 있지만 반드시 이 작업을 수행할 필요는 없습니다. 보안 환경은 지속적으로 변화하며 실무자는 이러한 변화에 유연하게 적응해야 합니다. 보안 조사 결과에 대한 소유권 모델을 개발할 때 유연한 접근 방식을 채택합니다. 초기 모델을 사용하면 팀이 즉시 조치를 취할 수 있습니다. 기본 소유권 로직부터 시작하여 시간이 지남에 따라 해당 로직을 구체화하는 것이 좋습니다. 완벽한 소유권 기준의 정의가 지연되면 보안 조사 결과 수가 계속 증가합니다.
조사 결과를 적절한 팀과 리소스에 쉽게 할당하려면 팀이 일상적인 작업을 관리하는 데 사용하는 AWS Security Hub CSPM 기존 시스템과 통합하는 것이 좋습니다. 예를 들어 Security Hub CSPM을 보안 정보 및 이벤트 관리(SIEM) 시스템 또는 제품 백로그 및 티켓팅 시스템과 통합할 수 있습니다. 자세한 내용은 이 안내서의 [보안 조사 결과 할당 준비](prepare-finding-assignments.md) 섹션을 참조하세요.
다음은 시작점으로 사용할 수 있는 소유권 모델에 대한 예제입니다.
+ **보안 팀은 잠재적으로 활성 위협을 검토하고 보안 조사 결과를 평가하고 우선순위를 정하는 데 도움을 줍니다**. 보안 팀은 컨텍스트를 적절하게 평가할 수 있는 전문 지식과 도구를 갖추고 있습니다. 취약성을 평가하고 우선순위를 지정하며 위협 감지 이벤트를 조사하는 데 도움이 되는 추가 보안 관련 데이터를 이해합니다. 조사 결과 심각도 또는 추가 조정이 필요한 경우 이 가이드의 [보안 조사 결과 평가 및 우선순위 지정](assess-and-prioritize-security-findings.md) 섹션을 참조하세요. 예제는 이 가이드의 [보안 팀 예제](security-team-example.md) 섹션을 참조하세요.
![\[보안 팀은 SIEM 시스템을 통해 Security Hub CSPM의 결과를 검토합니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/vulnerability-management/images/security-team-remediation.png)
+ **클라우드 팀과 애플리케이션 팀 간에 보안 조사 결과 분산** - [보안 소유권 분산](distribute-ownership.md) 섹션에서 설명한 대로 리소스를 구성할 수 있는 액세스 권한이 있는 팀이 보안 구성을 담당합니다. 애플리케이션 팀은 자신이 빌드하고 구성하는 리소스와 관련된 보안 조사 결과를 책임지고, 클라우드 팀은 광범위한 구성과 관련된 보안 조사 결과를 책임집니다. 대부분의 경우 애플리케이션 팀은 광범위한 구성 AWS 서비스,의 AWS Control Tower[서비스 제어 정책](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)(SCPs), AWS Organizations네트워킹 관련 VPC 구성 및 [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/)를 변경할 수 없습니다.
애플리케이션을 전용 계정으로 분리하는 다중 계정 환경의 경우 일반적으로 계정의 보안 관련 조사 결과를 애플리케이션의 백로그 또는 티켓팅 시스템에 통합할 수 있습니다. 해당 시스템에서 클라우드 팀 또는 애플리케이션 팀이 조사 결과를 해결할 수 있습니다. 예제는 이 가이드의 [클라우드 팀 예제](cloud-team-example.md) 또는 [애플리케이션 팀 예제](application-team-example.md) 섹션을 참조하세요.
![\[): 애플리케이션 또는 클라우드 팀은 백로그를 통해 Security Hub CSPM의 보안 조사 결과를 수정합니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/vulnerability-management/images/application-team-remediation.png)
+ **해결되지 않은 나머지 조사 결과를 클라우드 팀에 할당** - 남은 조사 결과는 클라우드 팀이 해결할 수 있는 기본 설정 또는 광범위한 구성과 관련이 있을 수 있습니다. 이 팀은 결과를 해결하기 위해 가장 많은 과거의 지식과 액세스 권한을 가지고 있을 것입니다. 전반적으로 이는 일반적으로 전체 조사 결과의 훨씬 더 작은 하위 세트입니다.
# 보안 조사 결과 평가 및 우선순위 지정
효과적인 취약성 관리 프로그램의 중요한 구성 요소는 보안 조사 결과를 평가하고 우선순위를 지정하는 기능입니다. 여기에서 컨텍스트, 조직 기록 및 조정 감지 시스템이 제공됩니다. 보안 조사 결과의 우선순위를 지정하면 대응 수준에 적합한 속도를 설정하는 데 도움이 됩니다.
Amazon Inspector AWS Security Hub CSPM및 Amazon GuardDuty의 경우 결과에 심각도 레이블 또는 점수가 포함됩니다. Foundational Security Best Practices(FSBP) 표준, Amazon Inspector 및 GuardDuty와 관련된 조사 결과를 포함하여 Security Hub CSPM의 모든 중요하고 심각도가 높은 조사 결과에 대한 조사의 우선순위를 지정하는 것이 좋습니다. 조사 결과 심각도 레이블은 다음과 같이 결정됩니다.
+ [Amazon Inspector 점수](https://docs.aws.amazon.com/inspector/latest/user/findings-understanding-score.html)는 각 조사 결과에 대한 고도로 컨텍스트화된 점수입니다. 공통 취약성 평가 시스템(CVSS) 기본 점수 정보와 네트워크 도달 가능성 결과 및 악용 데이터를 상호 연관시켜 계산됩니다. 이 점수를 사용하면 조사 결과의 우선순위를 지정하여 가장 중요한 조사 결과와 취약한 리소스에 집중할 수 있습니다. 점수 외에도 Amazon Inspector는 [일반적인 취약성 및 노출(CVE)](https://www.cve.org/)에 대한 향상된 취약성 인텔리전스도 제공합니다. 여기에서는 Amazon을 비롯하여 Recorded Future, 사이버 보안 및 인프라 보안국(CISA) 등의 업계 표준 보안 인텔리전스 소스에서 제공하는 CVE에 대해 사용 가능한 인텔리전스를 요약합니다. 예를 들어 Amazon Inspector는 취약성을 악용하는 데 사용되는 알려진 맬웨어 키트의 이름을 제공할 수 있습니다. 자세한 내용은 [Vulnerability Intelligence](https://docs.aws.amazon.com/inspector/latest/user/findings-understanding-score.html#vulnerability-intel)를 참조하세요.
+ 각 GuardDuty 조사 결과에는 사용자 환경에 조사 결과의 잠재적 위험을 반영하는 [관련 심각도 수준 및 값](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_findings.html#guardduty_findings-severity)이 있습니다. 이 수준과 값은 AWS 보안 엔지니어가 결정합니다. 예를 들어 `High` 심각도 수준은 리소스가 손상되어 승인되지 않은 목적을 위해 적극적으로 사용되고 있음을 나타냅니다. `High` 심각도 GuardDuty 조사 결과를 우선적으로 처리하고 즉시 해결하여 무단 사용을 방지하는 것이 좋습니다.
+ [Security Hub CSPM 제어 결과의 심각도](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-control-details.html#control-findings-severity)는 악용의 어려움과 손상 가능성에 따라 결정됩니다. 난이도는 취약점을 이용해 위협 시나리오를 수행하는 데 필요한 정교함이나 복잡성의 정도에 따라 결정됩니다. 손상 가능성은 위협 시나리오로 인해 AWS 서비스 또는 리소스가 중단되거나 침해될 가능성을 나타냅니다.
조사 결과를 조정하기 위해 해당 서비스 콘솔에서 직접 또는 서비스의 API를 사용하여 특정 조사 결과를 억제하거나 아카이브할 수 있습니다. 또한 [자동화 규칙을](https://docs.aws.amazon.com/securityhub/latest/userguide/automation-rules.html) 사용하여 Security Hub CSPM에서 조사 결과를 변경할 수 있습니다. GuardDuty 및 Amazon Inspector 조사 결과는 Security Hub CSPM으로 자동 전송됩니다. 자동화 규칙을 사용하여 사용자가 정의한 기준에 따라 거의 실시간으로 조사 결과를 자동으로 업데이트(예: 심각도 변경)하거나 억제할 수 있습니다. 자동화 규칙을 생성할 때 생성 또는 수정 날짜, 생성한 사람, 규칙이 필요한 이유와 같은 컨텍스트를 규칙 설명에 추가하는 것이 좋습니다. 이 정보는 나중에 참조하는 데 유용한 경우가 많습니다.
# 보안 조사 결과 문제 해결
결과를 평가하고 우선순위를 지정한 후 다음 작업은 조사 결과와 관련된 문제를 해결하는 것입니다. 조사 결과 관련 문제를 해결하기 위해 취할 수 있는 다양한 조치가 있습니다. 소프트웨어 취약성의 경우 운영 체제를 업데이트하거나 패치를 적용할 수 있습니다. 클라우드 구성 조사 결과의 경우 리소스 구성을 업데이트할 수 있습니다. 일반적으로 문제 해결을 위해 수행하는 작업은 다음 성과 중 하나로 그룹화할 수 있습니다.
+ **수동 수정 **- 암호화를 활성화하도록 AWS 리소스의 속성을 수정하는 등 취약성에 대한 수정 사항을** **수동으로 제공합니다. 조사 결과가 Security Hub CSPM의 관리형 검사 중 하나에서 나온 경우 조사 결과에는 조사 결과를 수동으로 해결하기 위한 지침에 대한 링크가 포함됩니다.
+ **재사용 가능한 아티팩트** - 코드형 인프라(IaC)를 업데이트하여 취약성을 수정하고 다른 사용자가 유사한 솔루션의 이점을 누릴 수 있음을 알고 있습니다. 업데이트된 IaC와 해결 방법에 대한 간략한 요약을 내부 공유 코드 리포지토리에 업로드하는 방법을 고려합니다.
+ **자동 문제 해결** -** **취약성은 사용자가 생성한 메커니즘을 통해 자동으로 해결됩니다.
+ **파이프라인 제어** - 지속적 통합 및 지속적 전송(CI/CD) 파이프라인 내에 취약성이 있는 경우 배포를 방지하는 제어를 적용합니다.
+ **허용된 위험** - 조치를 취하거나 보완 제어를 구현하지 않으며 취약성이 야기하는 위험을 허용합니다. 위험 레지스트리와 같은 전용 위치에서 허용된 위험을 추적합니다.
+ **거짓 긍정** - 조사 결과가 취약성을 올바르게 식별하지 못했다고 판단했기 때문에 아무런 조치도 취하지 않습니다.
취약성을 해결하는 데 사용할 수 있는 다양한 작업과 도구의 전체 목록은 이 가이드의 범위를 벗어납니다. 그러나 다음과 같이 주목할 만한 대규모 취약성을 해결하는 데 도움이 되는 몇 가지 서비스와 도구가 있습니다.
+ 의 기능인 [Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html)는 보안 관련 업데이트 및 기타 유형의 업데이트로 관리형 노드에 패치를 적용하는 프로세스를 AWS Systems Manager자동화합니다. 패치 관리자를 사용하면 운영 체제와 애플리케이션 모두에 패치를 적용할 수 있습니다.
+ [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-chapter.html)를 사용하면의 계정 및 애플리케이션에서 방화벽 규칙을 중앙에서 구성하고 관리할 수 있습니다 AWS Organizations. 새 애플리케이션이 생성되면 Firewall Manager는 공통 보안 규칙 세트를 적용하여 새 애플리케이션과 리소스를 쉽게 규정 준수 상태로 만들 수 있습니다.
+ [의 자동 보안 대응 AWS](https://aws.amazon.com/solutions/implementations/automated-security-response-on-aws/)은 Security Hub CSPM과 함께 작동하며 보안 위협에 대한 업계 규정 준수 표준 및 모범 사례를 기반으로 사전 정의된 대응 및 문제 해결 조치를 제공하는 AWS 솔루션입니다.
# 보안 조사 결과 분류 및 문제 해결에 대한 예제
이 섹션에서는 보안, 클라우드 및 애플리케이션 팀을 위한 분류 프로세스 예제를 검토합니다. 여기에서는 각 팀이 공통적으로 다루는 조사 결과 유형에 대해 설명하고 대응 방법의 예제를 제공합니다. 상위 수준의 문제 해결 지침도 포함되어 있습니다.
**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 제어와 연결된 각 결과에는 결과에 대한 세부 정보와 문제 해결 지침 링크가 포함되어 있습니다. 클라우드 팀은 일회성 수동 수정이 필요한 조사 결과를 발견할 수 있지만 적절한 경우 개발 프로세스에서 가능한 한 빨리 문제를 식별하는 선제적 검사를 빌드하는 것이 좋습니다.