Amazon SCS-C02: 거버넌스, 구성 및 자동화 — 학습 가이드
다음의 일부입니다: AWS Security Specialty SCS-C02 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.
서비스 제어 정책 및 조직 수준 가드레일
서비스 제어 정책(Service Control Policies, SCP)은 AWS Organization 내 모든 보안 주체(principal)가 수행할 수 있는 작업의 가장 바깥쪽 경계를 형성합니다. SCP는 IAM 정책이 아닙니다. SCP는 아무것도 부여하지 않으며, 단지 OU나 전체 조직에 속한 계정에서 사용할 수 있는 최대 권한을 정의할 뿐입니다. IAM 정책, 리소스 정책 또는 권한 경계(permissions boundary)의 Allow는 SCP가 해당 작업을 거부하면 완전히 효력을 잃습니다. 이러한 비대칭성 때문에 SCP는 리전 제한, 금지된 서비스 사용, 중앙 관리형 IAM 역할 보호, 리소스 생성 시 암호화 강제 등 조직 전체의 가드레일을 설정하는 데 가장 적합한 도구입니다.
암호화되지 않은 DynamoDB 테이블과 S3 버킷 생성을 거부하는 표준적인 SCP는 다음과 같습니다.
Version: "2012-10-17"
Statement:
- Sid: DenyUnencryptedS3
Effect: Deny
Action: s3:CreateBucket
Resource: "*"
Condition:
StringNotEquals:
s3:x-amz-server-side-encryption-aws-kms-key-id: !Ref CmkArn
- Sid: DenyUnencryptedDdb
Effect: Deny
Action: dynamodb:CreateTable
Resource: "*"
Condition:
"Null":
dynamodb:SSESpecificationEnabled: "true"
흔히 저지르는 실수는 각 계정에 연결된 IAM 정책을 통해 ‘조직 내 누구도 us-east-2를 사용할 수 없음’이나 ‘아무도 CloudTrail을 비활성화할 수 없음’과 같은 규칙을 강제하려는 것입니다. 권한 경계와 자격 증명 정책을 잘 맞춰놓아도, 로컬 관리자는 스스로에게 빠져나갈 구멍을 부여할 수 있습니다. 루트나 OU에 적용된 SCP만이 신뢰할 수 있습니다. 왜냐하면 SCP는 (제한할 수 없는 몇 가지 예외 작업을 제외하고) 멤버 계정의 루트 사용자까지도 제약하기 때문입니다.
또한 SCP는 비상 접근(break-glass) 및 위임된 관리자 역할을 보호해야 합니다. 예를 들어 OrganizationAccountAccessRole이나 SecurityAudit과 같은 역할을 대상으로 하는 모든 작업에 대해, 호출자의 aws:PrincipalArn이 승인된 목록과 일치하지 않는 한 명시적인 Deny를 추가해야 합니다.
AWS Config, 규정 준수 팩, 그리고 다중 계정 적용
AWS Config는 지속적인 평가 계층을 제공하여, (예방하는) SCP를 (편차를 관찰하고 보고하는) 탐지 기능으로 보완합니다. 규정 준수 팩(conformance pack)은 s3-bucket-server-side-encryption-enabled와 같은 관리형 규칙과 Lambda 또는 Guard 기반의 사용자 지정 규칙을 모두 포함하는 Config 규칙의 묶음으로, 선택적 해결 조치(remediation action)와 함께 배포 가능한 단일 YAML 아티팩트로 패키징됩니다.
표준 기준(baseline)을 조직 전체에 배포하기 위해 두 가지 메커니즘이 결합됩니다.
관리 계정에서 배포하는 CloudFormation StackSets: 서비스 관리형 권한(service-managed permissions)과
AutoDeployment: Enabled설정을 사용합니다. 이렇게 하면 조직에 새로 가입하는 모든 계정에 Config 레코더와 전송 채널(delivery channel)을 활성화하는 스택이 자동으로 배포됩니다. 이는 부트스트랩 문제를 해결합니다. 즉, Config가 활성화되지 않은 계정은 규정 준수 팩으로 평가할 수 없습니다.위임된 관리자 계정에서 배포하는 규정 준수 팩:
PutOrganizationConformancePack을 사용하여 위임된 관리자 계정(예:security-01)에서 규정 준수 팩을 배포합니다. 이를 통해 각 계정을 수동으로 건드리지 않고도 현재와 미래의 모든 계정에 일관된 규칙 세트를 전파할 수 있습니다.
위임된 관리자 + 집계기(aggregator) 패턴은 중요합니다. 이 패턴을 통해 보안팀은 모든 계정의 규정 준수 상태를 한곳에서 볼 수 있으면서도, 애플리케이션팀은 로컬에서 자체 규칙을 추가할 수 있습니다. 관리 계정에서 직접 동일한 규칙을 배포하는 것도 가능하지만, 이는 최소 권한 원칙을 위반하고 직무 분리(separation-of-duties) 감사를 방해합니다.
CloudFormation Guard, StackSets, 그리고 Service Catalog
예방은 개발 수명 주기의 왼쪽(shift left)으로 이동해야 합니다. CloudFormation Guard (cfn-guard)는 CloudFormation 템플릿(또는 모든 JSON/YAML)을 파싱하고 배포 전에 선언적 규칙에 따라 평가하는 코드형 정책(policy-as-code) 엔진입니다. Guard 규칙은 다음과 같습니다.
rule s3_encrypted {
Resources.*[ Type == "AWS::S3::Bucket" ] {
Properties.BucketEncryption exists
Properties.BucketEncryption.ServerSideEncryptionConfiguration[*] {
ServerSideEncryptionByDefault.SSEAlgorithm == "aws:kms"
}
}
}
이를 CI/CD 단계에 연결하면(일반적으로 cfn-guard validate -r rules.guard -d template.yaml을 실행하는 Docker 컨테이너 단계로 구현), 규정을 준수하지 않는 리소스가 생성되기 전에 파이프라인이 실패합니다. 위반 시 파이프라인은 보안팀이 구독하는 SNS 주제로 알림을 게시하여, 보안팀이 수동 승인 병목 지점이 되지 않으면서도 가시성을 확보할 수 있게 합니다. StackSets나 CloudFormation 변경 세트(change-set) 검토에만 의존하여 보안팀에 알리는 것은 함정입니다. 두 서비스 모두 리소스별 규정 준수 결과를 내보내지 않으며, 스택이 생성된 시점에는 이미 리소스가 계정에 존재하기 때문입니다.
Service Catalog는 마지막 단계(last mile)에서 Guard를 보완합니다. 개발자가 임의의 CloudFormation을 작성하도록 허용하는 대신, 플랫폼팀은 검증된 제품(VPC 기준, RDS 패턴, EKS 클러스터 등)을 Service Catalog 포트폴리오로 게시하여 AWS RAM을 통해 여러 계정에 공유합니다. 개발자는 제한된 파라미터로 제품을 시작하고, 시작 제약 조건(launch constraint) IAM 역할이 개발자 본인에게는 없는 높은 권한으로 리소스를 프로비저닝합니다. 이를 통해 기반 템플릿이 이미 Guard 검사를 통과한, 감사 가능하고 셀프서비스가 가능한 배포 모델을 제공할 수 있습니다.
StackSets 자체도 올바른 연결(plumbing)이 필요합니다. 조직 관리 계정에서 배포할 때는 SERVICE_MANAGED 권한 모델을 사용하고, Organizations에서 CloudFormation에 대한 신뢰할 수 있는 액세스를 활성화하며, 실행 역할을 신중하게 구성해야 합니다. (자체 관리형 모드에서의) AdministrationRoleARN/ExecutionRoleName 쌍 또는 (서비스 관리형 모드에서의) 서비스 연결 역할(service-linked roles)은 실제로 리소스를 생성하는 CloudFormation 서비스 역할에 iam:PassRole을 허용해야 합니다. CloudFormation 서비스 역할을 연결하는 것을 잊고 배포하는 사용자의 자격 증명에 의존하면 iam:PassRole에 대한 간헐적인 AccessDenied 오류가 발생하며, 이는 StackSet 작업 실패의 일반적인 원인입니다. 올바른 패턴은 스택당 하나의 전용 서비스 역할을 사용하고, 해당 역할에는 선언된 리소스 유형을 생성하는 데 필요한 권한만 부여하는 것입니다.
자동화된 해결 파이프라인
Config가 규정 미준수를 감지하면, 안전하게 자가 치유가 가능한 모든 항목에 대해 해결 조치가 자동으로 이루어져야 합니다. 이벤트 흐름은 다음과 같습니다:
Config가 기본 이벤트 버스로
Compliance Change이벤트를 게시합니다.EventBridge 규칙이 특정 규칙에 대한
NON_COMPLIANT결과를 필터링하고, Systems Manager Automation 문서(S3 암호화 활성화와 같은 간단하고 멱등성 있는 수정용), Lambda 함수(API 수준 수정용), 또는 Step Functions 상태 머신(승인, 재시도, 또는 교차 서비스 오케스트레이션이 필요한 다단계 워크플로우용)을 대상으로 지정합니다.
예를 들어, s3-bucket-public-read-prohibited 규칙이 트리거되면 SSM Automation 런북 AWS-DisableS3BucketPublicReadWrite가 이를 해결합니다. 더 복잡한 흐름의 경우(예: KMS 키 정책이 변경되어 소유 팀에 알리면서 일치시켜야 하는 경우) Step Functions가 조정을 담당합니다. 현재 정책을 읽고, 골든 버전과 비교(diff)하고, kms:PutKeyPolicy를 호출한 다음, SNS에 게시합니다. 해결 로직을 단일 Lambda 함수가 아닌 Step Functions에 저장하면 각 단계에 대한 가시성을 확보하고 깔끔한 재시도 시맨틱을 구현할 수 있습니다.
IAM Access Analyzer 및 정책 검증
IAM Access Analyzer는 두 가지 별개의 질문에 답합니다. 첫째, 외부 액세스 분석기는 신뢰 영역(계정 또는 조직) 외부의 보안 주체에게 액세스 권한을 부여하는 정책을 가진 리소스(S3, KMS, IAM 역할, Lambda, SQS, Secrets Manager)를 식별합니다. 결과가 중앙에서 집계되도록 위임된 관리자 계정에서 조직 수준으로 분석기를 활성화하십시오.
둘째, Access Analyzer 정책 검증 및 정책 생성은 정책 작성 중에 실행됩니다. aws accessanalyzer validate-policy는 보안 경고, 오류 및 제안(예: 민감한 작업과 결합된 지나치게 광범위한 Resource: "*" 플래그 지정)을 반환합니다. CloudFormation에 포함된 IAM 정책이 배포 전에 확인되도록 이 기능을 cfn-guard와 동일한 CI/CD 단계에 통합하십시오. 또한 Access Analyzer는 CloudTrail 기록에서 최소 권한 정책을 생성하여 와일드카드 정책을 역할이 실제로 사용한 정확한 작업으로 대체할 수 있습니다. 이는 호출 서비스가 kms:ViaService 조건을 통해 S3, DynamoDB, Lambda 또는 EKS일 때만 kms:Decrypt를 허용하는 범위 지정 KMS 키 정책과 함께 “데이터 액세스에 대한 최소 권한 적용"에 대한 기계적인 해답입니다.
실전 문제: 사용 사례 시나리오
시나리오: Meridian Financial은 프로덕션, 스테이징, 샌드박스 및 중앙 보안 계정을 포함하는 다중 계정 AWS Organization을 운영합니다. 이들은 샌드박스에서 CloudFormation 템플릿과 개발자 주도 템플릿을 혼합하여 워크로드를 배포합니다. 소유권은 여러 팀에 걸쳐 연합되어 있으며, 데이터 암호화 및 최소 권한 액세스에 대한 내부 거버넌스를 충족해야 합니다.
과제: 샌드박스의 개발자들이 실수로 퍼블릭 S3 버킷과 과도하게 허용적인 IAM 정책을 생성하여 다른 계정으로 전파되었으며, 보안 팀은 Organization 전반에 걸쳐 일관되고 자동화된 강제 적용 및 템플릿 검증 기능이 부족합니다.
권장 접근 방식:
- Organization 루트에서 퍼블릭 S3를 거부하고, 버킷 암호화를 강제하며, 권한 있는 IAM 작업을 제한하는 조직 수준의 서비스 제어 정책(SCP)을 생성하여 예방적 가드레일을 제공합니다.
- 중앙 보안 계정에서 CloudFormation StackSets를 사용하여 모든 계정과 리전에 AWS Config 애그리게이터 및 규정 준수 팩을 배포하여 S3 퍼블릭 액세스, IAM 정책 연결 패턴 및 암호화 규정 준수를 지속적으로 평가합니다.
- CloudFormation Guard(cfn-guard) 규칙을 CI/CD 파이프라인(CodePipeline/CodeBuild)에 통합하고, 승인된 인프라에 대해 Service Catalog 제품을 요구하여 템플릿이 검증되고 규정을 준수하는 스택만 프로비저닝되도록 합니다.
- 우선순위가 높은 결과(퍼블릭 S3 자동 차단, 과도하게 광범위한 IAM 정책 해결)에 대해 SSM Automation 문서 또는 Lambda 런북을 사용하여 AWS Config 자동 해결을 활성화하고, EventBridge를 통해 추가 워크플로우를 트리거합니다.
- IAM Access Analyzer 및 정책 검증을 중앙에서 실행하고, 결과를 Security Hub로 수집하며, 발견된 교차 계정 또는 과도하게 허용적인 정책에 대한 티켓 생성 또는 해결 플레이북을 자동화합니다.
근거: 이 접근 방식은 예방적인 조직 전체 가드레일(SCP), 지속적인 탐지(Config/규정 준수 팩), 시프트-레프트(shift-left) 템플릿 검증(cfn-guard/Service Catalog), 그리고 IAM Access Analyzer를 사용한 자동화된 해결을 결합하여 최소 권한을 강제하고 AWS 모범 사례에 따라 일관된 다중 계정 거버넌스를 달성합니다.
AWS Config: 조직 규칙, 집계기 및 위임된 관리자
AWS Config는 AWS에서의 탐정적 규정 준수(detective compliance)의 기반입니다. 리소스 구성을 지속적으로 기록하고 AWS 관리형 규칙(예: restricted-ssh, vpc-flow-logs-enabled, encrypted-volumes) 또는 사용자 지정 규칙(Lambda 또는 Guard 기반)에 따라 평가합니다. 엔터프라이즈 규모에서는 규칙 자체보다 세 가지 아키텍처 결정, 즉 규칙 배포 방식, 결과 집계 방식, 도구 소유자가 더 중요합니다.
AWS Organizations 하의 다중 계정, 다중 리전 배포의 경우, 올바른 패턴은 aws organizations register-delegated-administrator --service-principal=config-multiaccountsetup.amazonaws.com을 통해 위임된 관리자 계정(일반적으로 관리 계정이 아닌 보안 또는 감사 계정)을 지정하는 것입니다. 해당 계정에서 PutOrganizationConfigRule 또는 PutOrganizationConformancePack을 사용하여 모든 멤버 계정과 리전에 규칙을 배포합니다. 위임된 관리를 건너뛰면 각 계정에서 수동으로 Config를 활성화하거나 관리 계정에서 모든 것을 실행해야 합니다. 후자는 직무 분리를 위반하고 전자는 소수의 계정을 넘어서면 확장성이 떨어집니다.
조직 규칙은 단일 규칙 정의를 푸시하고, **집계기(aggregator)**는 그 결과 평가를 수집합니다. 모든 계정과 리전을 포괄하는 OrganizationAggregationSource를 사용하여 위임된 관리자 계정에 집계기를 생성합니다. 그러면 집계기 대시보드는 계정 간 역할을 복잡하게 전환할 필요 없이 “200개 계정 중 Flow Logs가 없는 VPC는 무엇인가?“와 같은 질문에 답할 수 있습니다. 집계기는 읽기 전용으로, 규정 준수 상태를 보여주지만 직접 수정하지는 않는다는 점에 유의하십시오.
기준선 적용을 위한 규정 준수 팩
규정 준수 팩(conformance pack)은 Config 규칙과 그에 대한 수정 조치를 단일 YAML 템플릿으로 묶은 것입니다. AWS는 PCI DSS, HIPAA, NIST 800-53, CIS와 같은 프레임워크에 매핑된 팩을 제공합니다. 위임된 관리자에서 조직 규정 준수 팩을 배포하면 특정 OU를 대상으로 할 수 있습니다. 예를 들어, Sandbox OU보다 Prod OU에 더 엄격한 팩을 적용할 수 있습니다. 이는 단일 API 호출로 규칙 세트와 그 수정 연결(remediation wiring)이 모든 곳에 한 번에 전파되기 때문에 수백 개의 계정에 걸쳐 일관된 기준선을 적용하는 가장 효율적인 방법입니다.
Resources:
EncryptedVolumesRule:
Type: AWS::Config::ConfigRule
Properties:
ConfigRuleName: encrypted-volumes
Source:
Owner: AWS
SourceIdentifier: ENCRYPTED_VOLUMES
EncryptedVolumesRemediation:
Type: AWS::Config::RemediationConfiguration
Properties:
ConfigRuleName: encrypted-volumes
TargetType: SSM_DOCUMENT
TargetId: AWSConfigRemediation-EncryptS3BucketVolume
Automatic: true
MaximumAutomaticAttempts: 3
RetryAttemptSeconds: 60
자동 수정 패턴
대표적인 두 가지 수정 경로가 있으며, 어느 것을 선택할지는 지연 시간 및 복잡성 요구 사항에 따라 달라집니다.
Config 네이티브 수정 경로는 AWS::Config::RemediationConfiguration을 사용하여 규칙이 NON_COMPLIANT를 보고할 때마다 SSM Automation 실행서(runbook)를 호출합니다. AWS는 AWS-EnableVPCFlowLogs, AWSConfigRemediation-RemoveUnrestrictedSourceIngressRules, AWSConfigRemediation-EncryptSNSTopic과 같은 사전 빌드된 실행서를 제공합니다. 이 경로는 선언적이며, 규정 준수 팩과 깔끔하게 통합되고, 몇 분 정도의 지연이 허용되는 경우에 이상적입니다.
EventBridge 기반 경로는 지연 시간이 중요하거나 사용자 지정 오케스트레이션이 필요할 때 사용됩니다. Config는 모든 상태 전환 시 Config Rules Compliance Change 이벤트를 발생시킵니다. EventBridge 규칙은 detail.newEvaluationResult.complianceType = NON_COMPLIANT를 필터링하여 Lambda 함수(또는 Step Function, 또는 SSM 실행서)를 직접 대상으로 지정합니다. EventBridge는 평가 후 몇 초 내에 실행되므로 1분 미만의 수정 시간(remediation window)이 가능해집니다.
{
"source": ["aws.config"],
"detail-type": ["Config Rules Compliance Change"],
"detail": {
"configRuleName": ["restricted-ssh"],
"newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] }
}
}
그러면 Lambda 핸들러는 문제가 되는 SG에 대해 RevokeSecurityGroupIngress를 호출합니다. 어떤 경로를 선택하든, 자동화는 대상 리소스를 수정할 수 있는 최소한의 권한을 가진 IAM 역할을 수임(assume)해야 합니다. 자주 발생하는 실패 모드는 수정 실행서가 AccessDenied 오류를 발생시켜 Config 규칙의 규정 준수 상태가 NON_COMPLIANT와 COMPLIANT 사이를 무한정 오가는 경우입니다. Config는 호출을 기록하지만 조용히 계속 진행합니다. 항상 SSM Automation 실행 기록을 검사하고 실행서 역할에 필요한 특정 변경 권한(mutating permissions)(예: ec2:CreateFlowLogs, flow-log 전달 역할을 위한 iam:PassRole, logs:CreateLogGroup)을 부여하십시오.
Systems Manager Automation 및 Patch Manager
SSM Automation 실행서는 명령형(imperative) 수정을 위한 핵심 도구입니다. 이는 API 호출, 승인, 분기 등의 단계를 설명하는 버전 관리되는 YAML/JSON 문서이며, 지정한 IAM 역할에 의해 실행됩니다. Config에 의해 트리거되는 수정 외에도, 액세스 키 순환, 연결되지 않은 EBS 볼륨 태깅, 30일 후 중지된 인스턴스 종료 등 예약된 정리 작업(hygiene tasks)을 실행합니다.
Patch Manager는 SSM의 하위 시스템으로, 운영 체제가 패치 기준선(patch baseline)(승인된 패치, 분류, 심각도 필터의 집합)을 준수하도록 유지합니다. 인스턴스는 Patch Group 태그를 통해 **패치 그룹(patch groups)**으로 그룹화되며, **유지 관리 기간(maintenance window)**은 이들을 대상으로 AWS-RunPatchBaseline 문서를 예약 실행합니다. 규정 준수 상태는 다시 Config 및 Security Hub로 전달되어 OS 수준의 상태와 조직의 보고 사이의 순환 고리를 완성합니다.
Service Catalog, CloudFormation StackSets, 예방적 가드레일
탐지 및 수정은 사후 대응적입니다. 규정 미준수를 방지하려면 예방적 통제를 사용해야 합니다:
Service Catalog는 선별되고 파라미터화된 CloudFormation 템플릿을 제품으로 게시합니다. 개발자는 기본 서비스에 대한 IAM 권한 없이도 승인된 패턴(강화된 VPC, 암호화된 RDS 클러스터 등)을 시작할 수 있어 플랫폼 팀과 소비자 간의 직무 분리를 강제합니다.
CloudFormation StackSets는 여러 계정과 리전에 걸쳐 동일한 스택을 배포합니다. 서비스 관리형 권한과 OU 타기팅을 사용하면 단일 작업으로 조직 내 모든 계정(자동 배포를 통해 새로 생성된 계정 포함)에 Config 레코더, IAM 역할 또는 GuardDuty 탐지기를 배포할 수 있습니다.
**Service Control Policies (SCPs)**는 조직 경계에서 API 호출을 완전히 거부할 수 있는 유일한 메커니즘입니다. Config와 SSM은 암호화가 누락된
RunInstances호출을 막을 수 없으며, 사후에 탐지하고 수정할 수만 있습니다. Config 규칙만으로 “공개 S3 버킷 절대 금지"와 같은 강력한 금지 조치를 시행하려고 하면 리소스 생성과 수정 사이에 시간적 공백이 생깁니다. 이 공백을 메우려면 Config 탐지 규칙과s3:PutBucketPublicAccessBlock거부 같은 SCP를 함께 사용해야 합니다.
재해 복구: 백업, 템플릿, 소스 제어
RPO/RTO 목표를 충족하려면 데이터와 인프라 정의를 모두 복구할 수 있어야 합니다. AWS Backup은 EBS, RDS, DynamoDB, EFS, FSx에 걸친 백업 정책을 중앙에서 관리합니다. 조직 백업 정책은 멤버 계정 전반에 걸쳐 계획을 강제하고, 리전 간 및 계정 간 복사본은 리전 손실 및 계정 침해로부터 보호합니다. RPO는 백업 주기에 따라 설정되며, RTO는 복원 메커니즘에 따라 달라집니다(DynamoDB PITR 복원은 몇 분, 리전 간 RDS 스냅샷 복원은 한 시간이 걸릴 수 있음).
인프라 복구는 단일 진실 공급원으로서 CodeCommit(또는 다른 Git 제공자)에 저장된 CloudFormation 템플릿에 의존합니다. 버전 관리되는 템플릿에서 StackSet을 다시 배포하면 복구 리전에 VPC, IAM, 애플리케이션 스택을 몇 분 안에 재구축할 수 있습니다. 템플릿을 리포지토리 없이 콘솔에만 보관하면 재현 가능한 아티팩트가 없으므로 RTO를 예측할 수 없게 됩니다.
함정 분석
세 가지 오해는 지속적으로 오답을 유도합니다. 첫째, Config를 예방적 통제로 취급하는 것입니다. Config는 CloudTrail이 변경 사항을 기록한 후에 평가하므로, 진정한 금지 조치에는 SCP가 필요합니다. 둘째, 적절한 범위의 IAM 역할 없이 수정을 연결하는 것입니다. SSM 문서가 존재하고 Config 규칙이 트리거되더라도 권한 오류로 인해 런북이 조용히 실패합니다. 셋째, 위임된 관리자를 등록하는 대신 관리 계정에서 조직 전체 서비스를 실행하는 것입니다. 이는 계정별 수동 활성화를 강제하고 조직 전체 수집기가 올바르게 작동하는 것을 방해합니다.
실전 문제: 사용 사례 시나리오
시나리오: Meridian Financial은 AWS Organizations 아래에 별도의 프로덕션, 개발, 보안 계정을 두고 멀티 어카운트 AWS 환경을 운영하고 있습니다. 보안팀은 여러 리전에 걸쳐 있는 수백 개의 EC2 인스턴스, S3 버킷, Lambda 함수를 관리하면서 내부 통제 및 규제 기관에 대한 지속적인 규정 준수를 입증해야 합니다.
과제: 최근 감사에서 패치가 적용되지 않은 EC2 인스턴스, 공개 S3 버킷, 계정 간 일관되지 않은 기준 적용이 발견되었습니다. 수정 작업은 수동으로 느리게 진행되며 예방적 통제가 균일하게 적용되지 않고 있습니다.
권장 접근 방식:
- 보안 계정을 AWS Config 위임된 관리자로 지정하고 CloudFormation StackSets를 통해 AWS Config 수집기를 배포하여 모든 계정 및 리전에서 구성 및 규정 준수 데이터를 수집합니다.
- 보안 계정에서 (StackSets를 사용하여) 조직 수준의 AWS Config 적합성 팩을 배포하여 기준 통제(S3 퍼블릭 액세스, 암호화, 태깅)를 코드화함으로써 동일한 규칙이 일관되게 적용되도록 합니다.
- 고위험 규칙에 AWS Config 자동 수정 조치를 연결하여 (수정 런북으로 등록된) AWS Systems Manager Automation 문서를 호출함으로써 위반 사항이 발생하면 SSM Automation 또는 Run Command 수정이 자동으로 트리거되도록 합니다.
- AWS Systems Manager Patch Manager를 SSM 패치 기준 및 State Manager와 함께 사용하여 패치 그룹을 정의하고 계정 전반의 OS 패치를 자동화합니다. 패치 준수 결과를 Config 수집기로 전송합니다.
- 승인된 CloudFormation 템플릿을 AWS Service Catalog에 게시하고 CloudFormation StackSets를 사용하여 규정을 준수하는 스택을 배포하거나 업데이트합니다. AWS Organizations Service Control Policies로 예방적 가드레일을 적용하여 허용되지 않는 리소스 생성(예: 공개 S3 버킷 생성 비활성화)을 차단합니다.
- Amazon EventBridge(CloudWatch Events) 및 SNS를 구성하여 규정 미준수 시 보안팀에 알리고 복잡한 인시던트에 대해 추가적인 SSM Automation 워크플로를 트리거합니다.
근거: Config 수집기 및 적합성 팩으로 탐지를 중앙화하고, SSM을 통해 수정을 자동화하며, Service Catalog/StackSets 및 SCP를 통해 예방적 가드레일을 적용함으로써 보안, 규정 준수, 최소 권한에 대한 AWS 모범 사례에 따라 일관되고 감사 가능한 통제와 신속한 수정을 제공합니다.
← 엣지 및 애플리케이션 보안 · 모든 도메인 · 취약점 →
이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
시험 합격하기 →