AWS 환경에서의 보안 아키텍처, 데이터 보호, 규정 준수 역량을 검증하는 전문 보안 자격증.
Amazon GuardDuty, Amazon Detective, AWS Security Hub, Amazon EventBridge, 사고 대응 자동화, AWS Systems Manager Incident Manager
AWS CloudTrail, Amazon CloudWatch Logs, VPC Flow Logs, AWS Config, Amazon Athena 로그 분석, Amazon OpenSearch Service
Amazon VPC 보안, AWS WAF, AWS Shield, AWS Network Firewall, AWS PrivateLink, 엣지 보안·CloudFront
AWS IAM 정책, AWS IAM Identity Center, Amazon Cognito, AWS Organizations SCP, 페더레이션·SAML, 권한 경계
AWS KMS, AWS CloudHSM, AWS Certificate Manager, Amazon Macie, S3 암호화·버킷 정책, AWS Secrets Manager
AWS Organizations, AWS Control Tower, AWS Audit Manager, AWS Trusted Advisor, 규정 준수 프레임워크, AWS Artifact
무료 샘플 세트의 실전형 문제를 바로 풀어보세요. 모든 정답에 상세 해설이 제공됩니다.
글로벌 금융 서비스 기업의 보안팀은 AWS Organizations 환경에서 중앙 데이터 계정의 S3 버킷에 여러 워크로드 계정의 애플리케이션이 접근할 수 있도록 구성하려 합니다.
워크로드 계정의 IAM 역할에는 S3 접근 권한이 부여되어 있으나, 실제 접근 시 권한 오류가 발생하고 있습니다. 보안팀은 최소 권한 원칙을 유지하면서 운영 오버헤드를 최소화하는 방식으로 이 문제를 해결하려 합니다.
이 상황에서 교차 계정 S3 접근을 올바르게 허용하기 위해 반드시 추가로 구성해야 하는 것은 무엇입니까?
정답: A. S3 bucket policy, 교차 계정 Principal 허용
교차 계정 S3 접근 시 AWS는 요청자 측 IAM 정책과 리소스 측 S3 버킷 정책 모두에서 허용이 있어야 접근을 승인합니다. 워크로드 계정의 IAM 역할에 S3 권한이 있더라도, 중앙 계정의 S3 버킷 정책에 워크로드 계정 Principal에 대한 명시적 허용이 없으면 권한 오류가 발생합니다. S3 버킷 정책에 교차 계정 Principal(워크로드 계정 IAM 역할 ARN 또는 계정 ID)을 허용하는 구성이 반드시 필요합니다.
S3 버킷 정책은 리소스 기반 정책으로, 다른 계정의 Principal이 버킷에 접근하려면 해당 버킷 정책에 명시적으로 허용 설정이 있어야 합니다. Organizations 환경에서는 개별 버킷 정책에 계정 ID 또는 IAM 역할 ARN을 Principal로 지정하여 최소 권한 원칙을 지킬 수 있습니다.
시험에서 교차 계정 S3 오류는 항상 버킷 정책 누락이 원인입니다. S3 ACL은 구형 방식으로 최소 권한 관리가 어려우며, SCP는 허용이 아닌 제한 용도이고, IAM 정책만으로는 교차 계정 S3 접근이 불가합니다.
글로벌 에너지 기업의 보안팀은 수백 명의 개발자가 속한 IAM 그룹 전체에 대해 특정 리전 외의 AWS 리소스 생성 및 수정을 즉시 차단해야 하는 보안 요구사항이 생겼습니다. 단, IAM, CloudFront, Route 53과 같이 글로벌 서비스로 분류되는 서비스에 대한 접근은 계속 허용되어야 합니다.
개별 사용자 정책을 변경하지 않고 그룹 전체에 일괄 적용하면서 글로벌 서비스 예외를 함께 처리할 수 있는 가장 적절한 IAM 정책 구성 방식은 무엇입니까?
정답: B. IAM 그룹 정책, aws:RequestedRegion Deny, 글로벌 서비스 NotAction 제외
이 시나리오에서 핵심 조건은 두 가지입니다. IAM 그룹 전체에 일괄 적용해야 하고, 글로벌 서비스(IAM, CloudFront, Route 53)는 예외 처리해야 합니다. IAM 그룹에 연결된 인라인 또는 관리형 정책에서 aws:RequestedRegion 조건과 함께 NotAction을 사용하면 글로벌 서비스를 제외한 특정 리전 외 요청을 일괄 차단할 수 있습니다. 개별 사용자 정책을 변경하지 않고도 그룹 수준에서 즉시 효과를 낼 수 있는 가장 직접적인 방식입니다.
IAM 그룹 정책에서 Deny 구문에 NotAction을 사용하면 나열된 글로벌 서비스 액션만 제외하고 나머지 모든 액션에 대해 리전 조건 Deny가 적용됩니다. aws:RequestedRegion 조건 키는 요청이 향하는 AWS 리전을 기반으로 필터링하며, 글로벌 서비스는 특정 리전을 대상으로 하지 않으므로 NotAction으로 명시적 제외가 필요합니다.
시험에서 SCP와 IAM 그룹 정책을 혼동하기 쉽습니다. SCP는 AWS Organizations 계층에 적용되며 IAM 그룹에 직접 연결할 수 없고, Permission Boundary는 최대 허용 범위를 정의할 뿐 그룹 일괄 차단에는 적합하지 않습니다.
글로벌 소프트웨어 기업의 보안팀은 개발팀이 CI/CD 파이프라인용 IAM 역할과 사용자를 직접 생성할 수 있도록 허용하되, 개발팀이 생성하는 IAM principal이 보안팀이 정의한 최대 권한 범위를 초과하지 못하도록 중앙에서 통제해야 합니다. 개발팀이 관리자 권한에 준하는 역할을 스스로 생성하여 파이프라인에 부여하는 권한 상승 위험을 방지하면서도, 개발팀의 자율성은 유지해야 합니다.
보안팀이 중앙에서 최대 권한 가드레일을 관리하면서 개발팀의 IAM principal 생성을 허용하는 가장 적절한 접근 제어 방식은 무엇입니까?
정답: B. IAM permissions boundary, 개발팀 역할 생성 조건 부여
한 소프트웨어 기업의 보안팀이 개발팀의 IAM 생성 자율성을 보장하면서도 최대 권한 상한선을 중앙에서 제어해야 하는 상황입니다. IAM permissions boundary는 IAM principal이 가질 수 있는 최대 권한의 상한선을 정의하는 정책으로, 개발팀이 아무리 강력한 권한을 포함한 역할을 생성해도 boundary를 초과하는 권한은 실제로 적용되지 않습니다. 보안팀이 boundary 정책을 중앙에서 관리하고 개발팀이 역할 생성 시 이 boundary를 필수 연결하도록 조건을 설정하면, 권한 상승 없이 개발팀의 자율성을 허용할 수 있습니다.
IAM permissions boundary는 identity-based policy와 함께 적용되며, 두 정책의 교집합만이 실제 유효한 권한이 됩니다. 즉, 개발팀이 AdministratorAccess 수준의 policy를 역할에 부여해도 boundary에 포함되지 않은 권한은 자동 차단됩니다. 이는 SCP와 달리 계정 전체가 아닌 특정 IAM principal 단위로 세밀하게 적용되는 것이 핵심 특징입니다.
시험에서 SCP와 permissions boundary를 혼동하기 쉽습니다. SCP는 AWS Organizations 수준에서 계정 전체에 적용되고, permissions boundary는 개별 IAM principal 단위에 적용됩니다. 특정 개발팀의 IAM 생성 범위를 제한하는 시나리오이면 permissions boundary, 조직 전체 계정의 서비스 사용을 제한하면 SCP를 선택하세요.
글로벌 컨설팅 기업의 보안팀은 특정 계약 기간 동안만 외부 협력사의 IAM 사용자가 지정된 S3 버킷에 객체를 업로드할 수 있도록 접근을 제한해야 합니다. 계약 기간이 종료되면 자동으로 접근이 차단되어야 하며, 운영팀이 수동으로 정책을 수정하는 작업 없이 이를 구현하길 원합니다.
IAM identity-based policy에서 시간 조건을 활용하여 특정 기간에만 S3 PutObject를 허용하는 가장 적절한 접근 방식은 무엇입니까?
정답: C. IAM policy, aws:CurrentTime 조건 Allow
이 시나리오에서 가장 중요한 조건은 IAM identity-based policy에서 시간 조건을 활용한 자동 접근 차단입니다. IAM Allow 정책에 aws:CurrentTime 조건(DateGreaterThan/DateLessThan)을 추가하면 지정한 기간에만 S3 PutObject가 허용되고, 기간 종료 후에는 조건이 충족되지 않아 암묵적 Deny가 적용됩니다. 이 방식은 별도 운영 작업 없이 자동 차단을 구현하는 가장 간결한 방법입니다.
aws:CurrentTime 조건은 IAM 글로벌 조건 컨텍스트 키로, ISO 8601 형식의 날짜·시간을 비교합니다. DateGreaterThan으로 시작 시점, DateLessThan으로 종료 시점을 지정하면 그 사이의 요청만 통과합니다. 이 조건은 Allow 문에 적용하면 조건 불충족 시 해당 정책이 적용되지 않아 다른 Allow가 없는 한 접근이 거부됩니다.
시험에서 자동 기간 기반 접근 제어가 나오면 aws:CurrentTime 조건 Allow를 선택하세요. Deny 문에 조건을 걸면 로직이 역전되어 관리가 복잡해지고, STS 세션 만료는 짧은 세션(최대 12시간)에 적합해 장기 계약 제어에 부적합합니다.
글로벌 미디어 기업의 개발팀은 SSE-KMS로 암호화된 S3 버킷에 소용량 파일 업로드는 정상적으로 성공하지만, 대용량 파일 업로드 시에만 권한 오류가 발생하는 문제를 겪고 있습니다. Lambda 함수의 실행 역할에는 kms:GenerateDataKey 권한이 부여되어 있습니다.
이 오류의 원인과 대용량 파일의 멀티파트 업로드 과정에서 추가로 필요한 KMS 권한은 무엇입니까?
정답: A. kms:Decrypt 권한 누락
멀티파트 업로드에서 소용량 파일과 대용량 파일의 차이는 KMS 권한 요구사항에 있습니다. 소용량 파일의 단일 PUT 업로드는 kms:GenerateDataKey만으로 데이터 키를 생성하여 암호화할 수 있지만, 멀티파트 업로드의 CompleteMultipartUpload 단계에서 S3는 각 파트의 암호화된 데이터 키를 복호화하기 위해 kms:Decrypt 권한이 필요합니다. Lambda 실행 역할에 kms:Decrypt가 없기 때문에 대용량 파일 업로드가 실패하는 것입니다.
SSE-KMS 멀티파트 업로드는 세 단계로 구성됩니다. 먼저 CreateMultipartUpload에서 데이터 키를 생성하고, 각 파트를 UploadPart로 전송한 후, CompleteMultipartUpload에서 모든 파트를 하나의 객체로 합칩니다. 이 마지막 단계에서 S3는 각 파트의 암호화 키 정보를 복호화하여 최종 객체의 DEK(Data Encryption Key)를 재생성해야 하며, 이때 kms:Decrypt가 필요합니다.
시험에서 SSE-KMS 관련 권한 오류가 나오면 단일 PUT vs 멀티파트 업로드를 구분하세요. 단일 업로드이면 kms:GenerateDataKey, 멀티파트라면 kms:GenerateDataKey와 kms:Decrypt 모두 필요합니다.
AWS Certified Security - Specialty (SCS-C03) 시험은 총 65문항으로 구성되어 있으며, 시험 시간은 170분입니다.
SCS-C03 시험의 합격 점수는 1000점 만점 중 750점 이상입니다.
SCS-C03 샘플 세트 20문항은 해설까지 포함해 무료로 풀 수 있습니다. 340문항 이상의 전체 문제 세트는 CloudMasterIT 구독으로 이용할 수 있습니다.
SCS-C03 자격증은 취득 후 3년간 유효하며, 이후 재인증이 필요합니다.