Amazon DOP-C02: 보안, 규정 준수 및 거버넌스 — 학습 가이드

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

다음의 일부입니다: AWS DevOps Engineer Professional DOP-C02 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

개요

AWS에서의 보안, 규정 준수 및 거버넌스는 제공 속도를 늦추지 않으면서 계정과 리전 전반으로 확장되는 결정적 제어에 달려 있습니다. 견고한 설계는 자격 증명 제어(IAM, 권한 경계, 서비스 제어 정책), 다중 계정 거버넌스(AWS Organizations, Control Tower), 지속적인 평가 및 해결(AWS Config), 위협 탐지(Security Hub, GuardDuty, Inspector), 보안 암호 관리, AWS KMS를 사용한 암호화, 네트워크 격리(VPC 보안 그룹, NACL, 엔드포인트, PrivateLink)를 계층화합니다. 목표는 최소 권한과 개발자 자율성을 보존하면서 영향 반경을 최소화하고, 지속적으로 규정 준수를 증명하며, 예방 및 해결을 자동화하는 것입니다.

자격 증명, 정책 및 다중 계정 거버넌스

IAM 역할, 정책, 권한 경계, SCP는 함께 작동하여 유효 권한 집합을 형성합니다. IAM 역할의 자격 증명 기반 정책은 허용된 작업을 정의하고, 역할의 신뢰 정책은 누가 해당 역할을 수임할 수 있는지 정의합니다. 권한 경계는 자격 증명 정책의 내용과 관계없이 보안 주체가 할 수 있는 작업의 상한을 설정합니다. AWS Organizations의 SCP는 멤버 계정의 모든 보안 주체(루트 사용자 포함)에 대한 절대적인 최댓값을 설정합니다. 리소스 기반 정책(S3, KMS, Secrets Manager 등)은 교차 계정 액세스를 허용할 수 있지만, SCP나 권한 경계에 의해 부과된 경계를 초과할 수는 없습니다. 유효 권한은 자격 증명 정책 ∩ 권한 경계 ∩ 세션 정책(있는 경우) ∩ 리소스 정책(해당하는 경우) ∩ SCP의 교집합이며, 명시적 Deny가 우선합니다.

단일 계정에서 안전한 셀프 서비스를 활성화하려면 권한 경계를 사용하십시오. 예를 들어, 개발자 벤딩 파이프라인은 특정 패턴을 제외하고 iam:PassRole을 거부하고, 민감한 키에 대한 kms:Decrypt를 거부하며, EC2 인스턴스 유형을 제한하는 경계를 연결하는 경우에만 역할을 생성할 수 있습니다. 경계는 iam:PutRolePermissionsBoundary 권한을 이미 가진 보안 주체만 연결할 수 있으므로 해당 권한을 엄격하게 보호해야 합니다.

SCP는 조직 전반의 가드레일입니다. 일반적인 가드레일에는 AWS Config 또는 CloudTrail 비활성화 금지, 조직 외부 초대 방지, IAM Identity Center의 위임된 관리자 변경 거부, 리전 제한 등이 포함됩니다. 마찰을 최소화하기 위해 조건을 사용한 명시적 예외 허용 패턴(예: 중앙 관리 역할에 의한 변경 허용)을 선호하십시오. 필요한 서비스 연결 역할(예: GuardDuty, Inspector, Config용)의 생성 및 사용은 항상 허용해야 합니다. 그렇지 않으면 SCP가 의도치 않게 서비스 설정을 차단할 수 있습니다.

AWS Organizations는 환경(예: Sandbox, Dev, Prod), 워크로드 유형, 예외 레인을 분리하기 위한 계층적 OU를 제공합니다. 정책 드리프트를 피하기 위해 상위 OU에서 SCP를 상속받으십시오. 계정 설정을 표준화하기 위해 계정 벤딩을 사용하십시오. CI/CD에 통합하려면 AWS Control Tower의 Account Factory(콘솔) 또는 Account Factory for Terraform(AFT)을 사용합니다. AFT는 GitOps 스타일 워크플로, 드리프트 탐지, 기능 플래그(예: Enterprise Support 프로비저닝)를 추가하고, 일관된 기준 가드레일을 통해 수백 개의 계정으로 확장할 수 있습니다.

AWS Control Tower는 규범적 가드레일이 있는 랜딩 존을 자동화합니다. 예방적 가드레일은 Control Tower가 관리하는 SCP이고, 탐정적 가드레일은 Control Tower가 배포하는 AWS Config 규칙입니다. Control Tower는 SSO 및 권한 집합을 위해 IAM Identity Center를 통합합니다. aws:PrincipalTag 또는 자격 증명 속성을 통해 작업 범위를 지정하려면 ABAC 기반 권한 집합을 속성과 함께 사용하십시오. Customizations for AWS Control Tower(CfCT)로 기준을 확장하여 OU/계정별로 CloudFormation, SCP, Config 팩을 자동으로 배포하십시오. 전역 가드레일을 약화시키지 않으면서 맞춤형 정책이 필요한 워크로드를 호스팅하기 위해 예외 OU를 유지하십시오.

지속적인 규정 준수 및 자동화된 해결

위임된 관리자 계정에서 조직 전체에 AWS Config를 활성화하십시오. 모든 리전의 모든 리소스에 대한 기록을 켜고 조직 애그리게이터를 사용하여 조직 전체의 구성을 집계하십시오. 일반적인 제어(예: ebs-encryption-by-default, restricted-ssh, s3-bucket-level-public-access-prohibited)에는 관리형 규칙을 사용하고, 맞춤형 로직(예: 90일 정책에 대한 KMS 순환 주기 확인 또는 기본 태그 및 값 강제 적용)에는 사용자 지정 Lambda 기반 규칙을 작성하십시오. 규정 준수 팩은 규칙, 파라미터, 해결 조치를 버전 관리되고 배포 가능한 번들로 그룹화하여 OU별로 제공합니다. 일관성과 감사 가능성을 위해 버전 제어 시스템에서 이를 유지하고 StackSets 또는 CfCT를 통해 배포하십시오.

자동화된 해결은 루프를 완성합니다. 각 규칙의 비준수 평가를 기준을 강제하는 SSM Automation 실행서에 매핑하십시오. 예를 들어, 기본 인스턴스 프로파일 연결, 기본값으로 태그 적용, S3 퍼블릭 액세스 차단 토글, 유지 관리를 위한 EC2 인스턴스 재시작 등이 있습니다. 실행서를 일반적으로 유지하기 위해 파라미터화된 문서와 동적 입력(예: Config 결과에서 가져온 값)을 사용하십시오. 고위험 리소스의 경우 해결 조치가 자동으로 실행되도록 구성하고, 민감한 작업의 경우 EventBridge와 ChatOps를 통해 변경 승인 또는 수동 호출을 요구하십시오. 중앙 관리자를 제외하고 레코더를 중지하거나 전송 채널을 삭제하는 것을 거부하는 SCP로 Config 자체를 보호하십시오.

Firewall Manager는 Organizations를 사용하여 계정 전반에 걸쳐 서비스형 정책(Policy-as-a-Service)을 제공함으로써 이 계층을 보완합니다. 중앙 관리자를 위임하고 인터넷 연결 ALB/API Gateway에 대한 WAF 웹 ACL 연결, VPC 보안 그룹 감사 및 정리, 또는 DNS Firewall 규칙 전파를 위한 정책을 작성하십시오. 이는 향후 적용의 초점을 탐지/해결에서 예방으로 전환시킵니다.

위협 탐지, 보안 암호 관리 및 취약점 관리

Security Hub는 여러 계정과 리전에 걸친 탐지 결과를 위한 중앙 집중식 단일 창(central pane of glass) 역할을 합니다. 위임된 관리자(delegated admin)로 활성화하고, 탐지 결과를 집계하며, 관련 표준(AWS Foundational Security Best Practices, CIS, 적용 가능한 경우 PCI DSS)을 활성화하십시오. 탐지 결과는 AWS Security Finding Format(ASFF)으로 수집되어 GuardDuty, Inspector, IAM Access Analyzer, Config, Macie 및 파트너 도구의 입력을 정규화합니다. EventBridge 패턴을 연결하여 중요한 탐지 결과를 해결 자동화(SSM Automation, Lambda) 및 알림(SNS, 채팅)으로 라우팅하십시오.

GuardDuty는 데이터 플레인 로그 파이프라인을 직접 관리할 필요 없이 관리형 위협 탐지 기능을 제공합니다. CloudTrail 관리 및 데이터 이벤트, VPC Flow Logs, Route 53 Resolver DNS 쿼리 로그, EKS 감사 로그를 분석하여 비정상적인 동작, 자격 증명 유출, 암호화폐 채굴, DNS 데이터 유출 등을 탐지합니다. 의심스러운 활동에 대해 S3 및 EC2/EBS 스캔을 위한 악성코드 방지(Malware Protection) 기능을 활성화하십시오. 조직 전체 자동 활성화를 사용하고, 억제 규칙(suppression rules)을 통해 신호가 약한 탐지 결과를 체계적으로 아카이빙하여 조치 가능한 항목에 집중하십시오.

Amazon Inspector는 EC2(SSM agent를 통해)의 패키지 CVE, 배포 전 ECR 컨테이너 이미지의 취약점, Lambda 함수의 코드 패키지 CVE를 지속적으로 평가합니다. Inspector를 사용하려면 EC2 인스턴스에 SSM Agent가 설치되어 있어야 하고, 인스턴스 프로파일이 SSM 권한을 허용해야 하며, SSM/KMS 엔드포인트로의 이그레스(인터넷이 제한된 경우 VPC 엔드포인트를 통해)가 가능해야 합니다. Inspector가 Security Hub로 탐지 결과를 전송하고 Systems Manager Patch Manager 또는 런북 기반 해결을 통해 패치 워크플로를 트리거하도록 구성하십시오. 태그를 사용하여 스캔 대상 리소스의 범위를 지정하고 샌드박스 워크로드와 규제 대상 워크로드를 분리하십시오.

Secrets Manager는 강력한 감사 기능을 통해 보안 암호의 저장, 교체, 계정 간 액세스를 중앙에서 관리합니다. 교체가 필요한 자격 증명의 경우 파라미터 스토어보다 Secrets Manager를 사용하는 것이 좋습니다. RDS/Aurora의 경우 내장된 교체 기능을, 외부 시스템의 경우 Lambda 기반 교체 기능을 활용하십시오. 스테이징 레이블(AWSCURRENT, AWSPREVIOUS)을 사용하면 무중단 교체가 가능합니다. 교체용 Lambda는 필요한 엔드포인트(Secrets Manager, RDS, KMS)가 있는 VPC에서 실행하고 이그레스를 제한하십시오. 계정 간 사용을 위해서는 다른 계정의 보안 주체(principal)에게 GetSecretValue 권한을 부여하는 리소스 기반 정책을 연결하십시오. 보안 암호의 CMK에 대한 KMS 키 정책이 소비자 측 보안 주체에게 복호화 권한 및 필요한 경우 권한 부여 생성(create grants) 권한을 허용하는지 확인해야 합니다. 재해 복구 또는 로컬리티 제어를 위해 여러 리전에 걸쳐 보안 암호를 복제하고 교체 주기를 조정하십시오.

데이터 보호 및 네트워크 보안

명시적인 키 정책을 사용하여 KMS 암호화를 설계합니다. IAM 정책뿐만 아니라 키 정책이 최종적으로 CMK에 대한 암호화 작업을 수행할 보안 주체를 승인합니다. 최소 권한, 역할 기반 키 정책 모델을 채택하십시오. 중앙 KMS 관리자 역할에 관리를 위임하고, 워크로드 역할에는 사용 권한을 좁게 부여하며, 의도치 않은 권한 상승을 피하기 위해 와일드카드 kms:*를 허용하지 마십시오. 조건 키(kms:EncryptionContext:*)를 사용하여 예상된 컨텍스트에 복호화를 바인딩합니다. 다중 리전 키를 사용하면 데이터가 리전 간에 복제되는 액티브-액티브 암호화를 구현할 수 있습니다.

Grant는 키 정책을 편집하지 않고 일시적이거나 범위가 엄격하게 제한된 키 사용을 위임하는 데 적합한 도구이며, 일부 서비스 흐름(예: 암호화된 시작 템플릿을 사용하는 EC2 Auto Scaling, 교차 계정 AMI 사용)에 필요합니다. 다른 계정이 Grant를 생성하도록 허용하려면 키 정책이 해당 계정의 보안 주체에게 kms:CreateGrant를 허용해야 합니다. 권한을 받는 수여자(grantee)는 동일한 호출 경로에서 즉시 사용할 수 있도록 권한 부여 토큰(grant token)을 제공해야 합니다. 교차 계정 암호화 AMI의 경우, AMI를 복사하고 CMK로 암호화한 후 AMI를 공유하고, 대상 계정이 CMK에 대한 Grant를 생성하도록 허용하며, 대상 서비스 연결 역할이 Grant를 받도록 해야 합니다.

봉투 암호화(Envelope encryption)는 기본 패턴입니다. KMS로 데이터 키를 생성하고, 평문 데이터 키로 데이터를 로컬에서 암호화한 다음, 암호문과 암호화된 데이터 키만 저장합니다. 읽기 시에는 KMS Decrypt를 호출하여 평문 데이터 키를 메모리로 복구합니다. 이 방식은 대용량 페이로드에 대한 KMS 호출을 최소화하고 평문 키 노출을 제한합니다. 지원되는 경우, 운영 단순성을 위해 서비스 관리형 SSE-KMS(S3, EBS, RDS)를 사용하되, 교차 계정 생산자/소비자를 위해 키 정책을 계속 정렬해야 합니다.

VPC 보안은 최소 권한의 보안 그룹에서 시작됩니다. 보안 그룹은 상태 저장(stateful) 방식이며, 반환 트래픽은 암묵적으로 허용됩니다. 깨지기 쉬운 IP 허용 목록을 피하고 인프라 코드의 의도를 유지하기 위해 CIDR 기반 규칙보다 보안 그룹 참조를 선호하십시오. 기본 아웃바운드 허용은 위험합니다. 필요한 대상으로 이그레스(egress)를 명시적으로 제한하고 AWS 서비스 액세스에는 VPC 엔드포인트를 사용하십시오. NACL은 상태 비저장(stateless) 방식이며 먼저 평가됩니다. 추가적인 경계를 구현하거나 규제 요구 사항을 충족해야 할 때만 임시 포트에 대한 명시적 반환 규칙을 포함한 서브넷 수준의 대략적인 제어로 유지하고, 그 외의 경우에는 관리 용이성을 위해 보안 그룹을 선호하십시오.

VPC 엔드포인트를 사용하여 인터넷 의존성을 제거하십시오. 게이트웨이 엔드포인트(S3, DynamoDB)는 AWS 네트워크를 통해 비공개로 라우팅됩니다. 엔드포인트 정책을 연결하여 액세스 가능한 버킷이나 테이블을 제한하십시오. 인터페이스 엔드포인트(AWS PrivateLink)는 AWS 서비스(Secrets Manager, KMS, SSM, ECR, CloudWatch)를 프라이빗 IP를 통해 노출합니다. 올바른 보안 그룹이 있는 서브넷에 배포하고 프라이빗 DNS를 활성화하여 표준 서비스 이름이 프라이빗 주소로 확인되도록 하십시오. 여러 계정/VPC에 걸친 생산자-소비자 마이크로서비스의 경우, NLB 기반 엔드포인트 서비스를 게시하고 소비자가 PrivateLink를 통해 여기에 인터페이스 엔드포인트를 생성하도록 하여 피어링이나 Transit Gateway를 피하고 트래픽이 공용 인터넷을 통하지 않도록 하십시오. 이러한 제어를 NAT/IGW가 없는 서브넷 및 인터넷 액세스가 필요한 경우 중앙 집중식 이그레스(egress) 검사와 결합하십시오.

실제 문제 시나리오

Expedia Group은 여러 리전에 걸쳐 수백 개의 AWS 계정으로 확장하고 있으며, 엄격한 보안 기준을 적용해야 합니다. 워크로드의 인터넷 이그레스(egress) 금지, 잘못된 구성의 자동화된 해결, 중앙 집중식 위협 탐지, 보안 암호 순환, 표준화된 골든 이미지를 위한 암호화된 AMI의 통제된 교차 계정 공유 등이 포함됩니다.

AWS Organizations와 AWS Control Tower로 다중 계정 거버넌스 구축

조치: Sandbox, Dev, Prod, Security용 OU를 생성합니다. Control Tower를 배포하여 랜딩 존을 구축하고, 필수 가드레일을 활성화하며, IAM Identity Center를 통합합니다. Account Factory for Terraform(AFT)을 사용하여 GitOps를 통해 계정을 제공합니다.
이유: Control Tower는 즉시 사용 가능하고 지속적으로 적용되는 가드레일(SCP 및 Config 규칙)을 제공합니다. AFT는 대규모 계정 프로비저닝을 표준화하고 기준선을 버전 관리 시스템에 코드로 정의합니다.

예외가 있는 전역 가드레일을 적용하기 위한 SCP 작성

조치: CloudTrail 및 AWS Config 비활성화를 거부하고, 리전을 제한하며, 퍼블릭 S3 ACL을 방지하는 SCP를 연결합니다. Security OU의 보안 관리자 역할에 대한 조건 기반 예외를 포함합니다. 필요한 서비스 연결 역할의 생성/사용을 허용합니다.
이유: SCP는 루트를 포함한 모든 보안 주체의 권한 상한을 설정하여 드리프트(drift)를 방지하는 동시에 중앙 운영을 위한 통제된 예외를 허용합니다.

자동화된 해결 기능이 있는 Config 규정 준수 팩 배포

조치: Security 위임된 관리자 계정에서 조직 전체에 AWS Config를 활성화하고 애그리게이터를 생성합니다. 기본 EBS 암호화, 제한된 SSH, 기본값이 있는 필수 태그, 퍼블릭 진입점에 필수 WAF를 강제하는 규정 준수 팩을 배포합니다. 각 규칙을 자동 수정을 위한 SSM Automation 문서에 매핑합니다(예: 기본 인스턴스 프로파일 연결, 누락된 태그를 weekly로 설정).
이유: 규정 준수 팩은 자동 해결 기능이 있는 일관되고 감사 가능한 정책형 코드(policy-as-code)를 제공하여 티켓 처리 부담 없이 환경을 규정 준수 상태로 유지합니다.

Security Hub, GuardDuty, Inspector로 탐지 중앙화

조치: 위임된 관리자를 통해 조직 전체에 GuardDuty와 Inspector를 활성화합니다. Security Hub 표준(AWS FSBP 및 CIS)을 활성화하고 결과를 집계합니다. 심각도가 높은 결과를 SSM Automation 런북과 온콜(on-call)용 SNS 주제로 라우팅하는 EventBridge 규칙을 생성합니다.
이유: 관리형 탐지 및 취약점 평가는 최소한의 운영 오버헤드로 지속적인 커버리지를 제공하며, Security Hub는 신호를 통합하여 더 빠른 분류 및 대응을 가능하게 합니다.

권한 경계와 ABAC로 IAM 최소 권한 적용

조치: AFT로 프로비저닝된 계정에서 개발자가 생성한 역할에 권한 경계를 연결하도록 요구합니다. 이 경계는 선별된 역할 외에는 iam:PassRole을 거부하고 영향력이 큰 API를 제한합니다. IAM Identity Center 권한 세트와 ABAC를 사용하여 팀 태그별로 작업 범위를 지정합니다.
이유: 권한 경계는 권한 상승을 방지하면서 안전한 셀프 서비스를 가능하게 합니다. ABAC는 정책 확산을 줄이고 ID 속성과 일관성을 유지합니다.

VPC 엔드포인트와 PrivateLink로 네트워크 경로 강화

조치: 애플리케이션 서브넷에서 IGW/NAT를 제거합니다. KMS, Secrets Manager, SSM, ECR, CloudWatch용 인터페이스 엔드포인트와 제한적인 엔드포인트 정책이 있는 S3/DynamoDB용 게이트웨이 엔드포인트를 생성합니다. 교차 계정 소비를 위해 PrivateLink 기반 NLB를 통해 내부 플랫폼 서비스를 게시합니다.
이유: 프라이빗 연결은 인터넷 노출을 제거하고 잠긴 환경에서도 서비스에 계속 연결할 수 있도록 보장합니다.

교차 계정 AMI를 위한 Grant를 포함한 KMS 키 전략 구현

조치: 역할 범위의 키 정책을 사용하여 환경별로 CMK를 생성합니다. 이미지 빌드 계정에서 골든 AMI를 암호화하고 공유합니다. 대상 계정이 Grant를 생성할 수 있도록 CMK 정책을 업데이트한 다음, 해당 대상 계정의 서비스 연결 역할에 Grant를 생성합니다.
이유: Grant는 모든 소비자에 대해 키 정책을 편집하지 않고도 범위가 지정되고 감사 가능한 위임을 제공하여, Auto Scaling이 여러 계정에서 암호화된 AMI로 인스턴스를 시작할 수 있게 합니다.

보안 암호 순환 및 교차 계정 액세스 표준화

조치: 데이터베이스 및 API 자격 증명을 Secrets Manager에 저장합니다. 비-RDS 대상을 위해 Lambda 순환을 구현하고 RDS에 대해서는 내장된 순환 기능을 활성화합니다. 공유 플랫폼 보안 암호의 경우, 다른 계정의 소비자 역할에 GetSecretValue를 부여하는 리소스 기반 정책을 연결하고 CMK 정책이 복호화를 허용하는지 확인합니다. 순환 Lambda를 필요한 엔드포인트가 있는 VPC에 배치합니다.
이유: 자동화된 순환은 자격 증명 위험을 줄입니다. KMS와 연계된 리소스 정책은 최소 권한과 감사 추적을 유지하면서 안전한 교차 계정 소비

← 모니터링 · 모든 도메인 · 컨테이너 및 서버리스 운영 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →