AWS SCS-C03 학습노트

이 노트 사용법

문제 원문 → 스스로 풀기 → 정답/해설 확인 → 꼭 외울 것 콜아웃만 반복 암기

시험 직전에는 맨 아래 부록. 전체 암기 총정리만 훑기

Q1. MFA 강제 정책 후 CLI 사용 불가
Q2. 리전 제한 SCP
Q3. IAM Identity Center 외부 IdP 연동 순서
Q4. KMS 키 정책과 kms ViaService
Q5. 페더레이션 사용자 S3 버킷 접근 차단
Q6. 보안 모니터링 전략 매칭
Q7. S3 영구 삭제 방지 + 재해 복구
Q8. 침해 사고 대응 KMS 키 삭제
Q9. EC2 + 온프레미스 SSH 대체
Q10. EKS 위협 탐지
Q11. IoT Core 클라이언트 ID 위장 방어
Q12. 구성 변경 추적 + 규정 준수
Q13. CloudHSM 사용자 지정 키 저장소
개념 보충. 질문하며 정리한 것들
부록. 전체 암기 총정리

Q1. MFA 강제 정책 후 CLI 사용 불가

문제

AWS 계정 관리자가 IAM 그룹을 생성하고 각 사용자가 다단계 인증을 사용하도록 요구하는 다음 관리형 정책을 적용했습니다.

 
{
 
    "Version": "2012-10-17",
 
    "Statement": [
 
        {
 
            "Effect": "Allow",
 
            "Action": "ec2:*",
 
            "Resource": "*"
 
        },
 
        {
 
            "Sid": "BlockAnyAccessUnlessSignedInWithMFA",
 
            "Effect": "Deny",
 
            "Action": "ec2:*",
 
            "Resource": "*",
 
            "Condition": {
 
                "BoolIfExists": {
 
                    "aws:MultiFactorAuthPresent": false
 
                }
 
            }
 
        }
 
    ]
 
}

정책을 구현한 후 관리자는 사용자들이 AWS CLI를 사용하여 Amazon EC2 명령을 실행할 수 없다는 보고를 받았습니다. 관리자는 다단계 인증을 유지하면서 이 문제를 해결하기 위해 무엇을 해야 할까요?

A. aws:MultiFactorAuthPresent 값을 true로 변경합니다.

B. 사용자에게 aws sts get-session-token CLI 명령을 실행하고 --serial-number 및 --token-code 매개변수를 전달하도록 안내합니다. 이러한 결과 값을 사용하여 API/CLI 호출을 수행합니다.

C. SAML 2.0을 사용하여 페더레이션된 API/CLI 액세스를 구현한 다음, ID 공급자를 구성하여 다단계 인증을 적용합니다.

D. 역할을 생성하고 역할 신뢰 정책에서 다단계 인증을 적용합니다. 사용자에게 sts assume-role CLI 명령을 실행하고 --serial-number 및 --token-code 매개변수를 전달하도록 안내합니다. 결과 값을 환경 변수에 저장합니다. 정책에서 NotAction에 sts:AssumeRole을 추가합니다.

정답: B

핵심 포인트

1) BoolIfExists가 왜 문제를 일으키는가

| 상황 | 조건 매치 여부 | 결과 |

|---|---|---|

| 키 값이 false | 매치 | Deny |

| 키가 아예 없음 | 매치 (IfExists 때문) | Deny |

2) 왜 CLI에서 키가 없는가

aws:MultiFactorAuthPresent는 STS 임시 자격 증명에만 존재하는 컨텍스트 키입니다.

| 접근 방식 | 키 상태 | 결과 |

|---|---|---|

| 콘솔 MFA 로그인 | true | 허용 |

| CLI + 장기 액세스 키(AKIA...) | 키 자체가 없음 | Deny |

| CLI + get-session-token 임시 자격 증명 | true | 허용 |

→ 사용자들이 MFA를 안 쓴 게 아니라, CLI에서 장기 액세스 키를 써서 MFA 컨텍스트가 전달되지 않는 것

3) 해결 명령

 
aws sts get-session-token \
 
  --serial-number arn:aws:iam::123456789012:mfa/user \
 
  --token-code 123456

반환되는 AccessKeyId / SecretAccessKey / SessionToken 3개를 환경변수나 프로파일에 설정 → 이 세션에는 aws:MultiFactorAuthPresent = true가 붙음

오답 정리

| 선지 | 탈락 이유 |

|---|---|

| A | aws:MultiFactorAuthPresent는 AWS가 채워주는 글로벌 컨텍스트 키. 정책에서 값을 바꾼다는 개념 자체가 없음. true로 바꾸면 MFA 쓴 사람을 막는 정반대 정책 |

| C | SAML 페더레이션은 동작은 하지만 IdP 구축이 필요한 대공사. “최소 변경으로 해결” 요구에 과함 |

| D | ① 같은 Statement에 Action/NotAction 공존 불가(문법 오류) ② Deny 대상이 ec2:*라 sts:AssumeRole은 원래 안 막힘 → 불필요한 조작을 끼워넣은 distractor |

꼭 외울 것

BoolIfExists + false = “MFA 안 썼거나, MFA 정보 자체가 없으면” 차단

(MFA 강제 정책은 거의 항상 IfExists를 씀 — 안 그러면 장기 키 사용자가 그냥 통과)

aws:MultiFactorAuthPresent는 STS 임시 자격 증명에만 존재

같은 계정 내 → get-session-token / 역할 전환 → assume-role

문제에 “역할”이 안 나오면 get-session-token

Q2. 리전 제한 SCP

문제

(정답 선지 C의 정책)

 
{
 
    "Version": "2012-10-17",
 
    "Statement": [
 
        {
 
            "Sid": "DenyNonDefaultRegions",
 
            "Effect": "Deny",
 
            "NotAction": [
 
                "<Desired Global Services>"
 
            ],
 
            "Resource": "*",
 
            "Condition": {
 
                "StringNotEquals": {
 
                    "aws:RequestedRegion": [
 
                        "eu-west-1"
 
                    ]
 
                }
 
            }
 
        }
 
    ]
 
}

정책 해석

<Desired Global Services>에 나열된 것을 제외한 모든 액션에 대해, 요청 리전이 eu-west-1이 아니면 Deny

| 요소 | 역할 |

|---|---|

| NotAction: [글로벌 서비스] | 차단 대상에서 빼둘 액션 (carve-out) |

| StringNotEquals: eu-west-1 | eu-west-1이 아닌 요청일 때 발동 |

| Deny | 둘 다 해당하면 차단 |

핵심 포인트

1) NotAction이 왜 필요한가

IAM, CloudFront, Route 53, WAF(글로벌), Organizations, Support 같은 글로벌 서비스는 aws:RequestedRegion이 us-east-1로 잡힙니다.

→ NotAction 없이 "Action": "*"로 짜면 IAM 사용자 생성도, Route 53 레코드 수정도 못 하는 계정이 됨

 
"NotAction": [
 
  "iam:*", "cloudfront:*", "route53:*",
 
  "organizations:*", "support:*", "waf:*"
 
]

2) 이 패턴의 정체

SCP(Service Control Policy)로 리전을 제한하는 AWS 공식 권장 형태. 데이터 주권(GDPR 등)이나 비용 통제 목적.

3) aws:RequestedRegion 키 부재 문제

이 키는 항상 존재하지는 않는데, StringNotEquals는 키 부재 = 매치로 판정해서 Deny가 발동합니다. NotAction으로 글로벌 서비스를 빼두는 게 이 문제까지 같이 막아줍니다.

꼭 외울 것

리전 제한 문제 판별 기준 2개

Deny + StringNotEquals인가?

(Allow + StringEquals로 짠 선지는 오답 — 다른 Allow 정책으로 우회 가능. Explicit Deny여야 함)

글로벌 서비스 예외(NotAction)가 있는가?

(없으면 계정이 망가지므로 오답)

Q3. IAM Identity Center 외부 IdP 연동 순서

문제

보안 엔지니어가 외부 ID 공급자(IdP)를 사용하여 AWS IAM Identity Center를 구현해야 합니다. 다음 목록에서 이 요구 사항을 충족하는 올바른 단계를 선택하고 순서대로 나열하십시오. 각 단계는 한 번만 선택하거나 전혀 선택하지 않을 수 있습니다.

선택지 (Step 1~3 각각 동일한 목록에서 선택)

Configure the external IdP as the identity source in IAM Identity Center.
Create an IAM role that has a trust policy that specifies the IdP’s API endpoint.
Enable automatic provisioning in IAM Identity Center settings.
Enable automatic provisioning in the external IdP.
Obtain the SAML metadata from IAM Identity Center.
Obtain the SAML metadata from the external IdP.

정답

| 순서 | 단계 | 이유 |

|---|---|---|

| Step 1 | Obtain the SAML metadata from the external IdP | IdP 인증 URL + 공개 서명 인증서를 먼저 확보 |

| Step 2 | Configure the external IdP as the identity source in IAM Identity Center | 받은 메타데이터 등록 → 양방향 신뢰 수립 |

| Step 3 | Enable automatic provisioning in IAM Identity Center settings | SCIM 엔드포인트 URL + 액세스 토큰 발급 |

핵심 포인트

1) SAML 메타데이터 교환은 양방향

| 항목 | 내용 |

|---|---|

| IdP 메타데이터 | 인증 URL, 공개 서명 인증서 |

| SP(=AWS) 메타데이터 | ACS URL(응답 받을 주소), Entity ID |

AWS는 IdP 인증서로 서명을 검증하고, IdP는 AWS 주소를 알아야 Assertion을 보낼 수 있음

2) SAML과 SCIM은 별개의 두 채널


IdP(Okta) ═══ SAML ═══> Identity Center   ← 로그인 순간마다 (인증)

IdP(Okta) ═══ SCIM ═══> Identity Center   ← 사용자 변경될 때마다 (명단 동기화)

| | SAML | SCIM |

|---|---|---|

| 언제 | 사용자가 로그인할 때 | 인사 변동이 생길 때 |

| 무엇을 | “이 사람 인증됨” 1회성 통보 | 사용자·그룹 목록 지속 동기화 |

| 경로 | 사용자 브라우저 경유 | IdP → Identity Center API 직접 |

3) 왜 프로비저닝(SCIM)이 필요한가

권한 할당 구조가 이렇기 때문입니다.


[Identity Store의 그룹]  →  [Permission Set]  →  [AWS 계정]

   "보안팀"                "ReadOnly+SecurityAudit"    운영계정

이 매핑을 로그인 전에 미리 만들어야 하는데, 그러려면 “보안팀” 그룹이 Identity Center 안에 실체로 존재해야 함 → SCIM이 그 실체를 만듦

오답 정리

| 선지 | 탈락 이유 |

|---|---|

| Create an IAM role that has a trust policy… | IAM Identity Center를 안 쓰는 직접 SAML 페더레이션 방식. Identity Center는 Permission Set이 역할을 자동 생성/관리. 또한 SAML 신뢰 정책은 API 엔드포인트가 아니라 SAML provider ARN을 참조 |

| Enable automatic provisioning in the external IdP | Identity Center에서 먼저 켜야 SCIM 엔드포인트 URL·토큰이 발급됨. 순서상 Identity Center가 먼저 |

| Obtain the SAML metadata from IAM Identity Center | 실제 연동에선 필요하지만 3단계 안에 다 못 넣음. Step 2에 포함된 것으로 봄 |

꼭 외울 것

메타데이터 받기 → ID 소스 설정 → 프로비저닝(SCIM) 활성화

= 누군지 믿을 준비 → 신뢰 연결 → 사용자 명단 동기화

인증 연동을 끝내기 전엔 프로비저닝을 켤 수 없다

Q4. KMS 키 정책과 kms ViaService

문제

다음 AWS 키 관리 서비스(AWS KMS) 키 정책이 고객 관리 키에 연결되면 어떤 효과가 있습니까?

 
{
 
  "Effect": "Allow",
 
  "Principal": {
 
    "AWS": "arn:aws:iam::111122223333:role/ExampleRole"
 
  },
 
  "Action": [
 
    "kms:Encrypt",
 
    "kms:Decrypt",
 
    "kms:GenerateDataKey*",
 
    "kms:CreateGrant",
 
    "kms:ListGrants"
 
  ],
 
  "Resource": "*",
 
  "Condition": {
 
    "StringEquals": {
 
      "kms:ViaService": [
 
        "workmail.us-west-2.amazonaws.com",
 
        "ses.us-west-2.amazonaws.com"
 
      ]
 
    }
 
  }
 
}

A. Amazon WorkMail 및 Amazon Simple Email Service(Amazon SES)는 111122223333 계정의 ExampleRole 주체에게 KMS 암호화 및 복호화 권한을 위임했습니다.

B. ExampleRole 주체는 ExampleRole과 AWS 간의 이메일 교환을 투명하게 암호화 및 복호화할 수 있습니다.

C. 고객 관리 키는 주체가 ExampleRole이고 요청이 지정된 AWS 리전의 Amazon WorkMail 또는 Amazon Simple Email Service(Amazon SES)에서 온 경우에만 암호화 및 복호화에 사용할 수 있습니다.

D. 키 정책을 통해 Amazon WorkMail 또는 Amazon Simple Email Service(Amazon SES)는 계정의 모든 고객 관리 키에 대해 ExampleRole을 대신하여 암호화 또는 복호화할 수 있습니다.

정답: C

핵심 포인트

1) 정책 요소별 역할

| 요소 | 값 | 질문 |

|---|---|---|

| Principal | ExampleRole | 누가 쓸 수 있나 |

| Action | Encrypt, Decrypt, GenerateDataKey*, CreateGrant, ListGrants | 무엇을 할 수 있나 |

| Resource | * | 이 키 정책이 붙은 그 키 자체 |

| Condition | kms:ViaService | 어떤 경로로 와야 하나 |

2) kms:ViaService의 의미

KMS 요청이 어떤 AWS 서비스를 거쳐서 들어왔는가


✅ ExampleRole → SES → KMS       (ViaService = ses.us-west-2)

❌ ExampleRole → KMS 직접 호출   (ViaService 키 없음 → StringEquals 불일치)

리전까지 하드코딩(us-west-2)돼 있어서 다른 리전의 SES를 거쳐도 안 됨

3) 흔한 오해 교정 — WorkMail/SES는 권한을 받은 게 아님


❌ 잘못된 이해:

   ExampleRole ──(권한 부여)──> WorkMail/SES

  

✅ 실제:

   ExampleRole ──(권한 받음)──> 키 사용 가능

                                단, WorkMail/SES를 경유할 때만

Condition은 절대 “누구에게 권한을 준다”는 뜻이 될 수 없음. 이미 정해진 권한에 필터를 씌우는 자리

4) ViaService는 권한을 깎는 장치

| | Condition 없을 때 | Condition 있을 때 |

|---|---|---|

| CLI로 직접 Decrypt | 가능 | 차단 |

| SES 통해 사용 | 가능 | 가능 |

| Lambda 통해 사용 | 가능 | 차단 |

실무 의미 — ExampleRole이 탈취돼도 공격자가 임의 데이터를 복호화할 수 없고, 정해진 워크플로 안에서만 키가 동작 (blast radius 축소)

오답 정리

| 선지 | 탈락 이유 |

|---|---|

| A | 권한 부여 방향이 반대. 권한을 주는 주체는 키 정책(키 소유자)이지 WorkMail/SES가 아님. 두 서비스는 통과해야 하는 경로일 뿐 |

| B | “ExampleRole과 AWS 간 이메일 교환”이라는 개념 자체가 없음. 키 정책은 키 사용 권한을 정하는 것이지 전송 구간 암호화 기능이 아님 |

| D | "Resource": "*"를 오독. 키 정책은 자기가 붙어 있는 키에만 적용되므로 여기서 *는 “계정의 모든 키”가 아니라 “이 키” |

꼭 외울 것

키 정책 읽는 문장 틀

> [Principal]이 [Action]을 [Resource]에 대해 할 수 있다. 단, [Condition]일 때만.

Condition을 읽을 때 “단, ~일 때만”을 앞에 붙이면 권한 부여로 오해할 일이 없음

리소스 기반 정책의 Resource: "*" = “이 리소스 하나”

(IAM 정책의 *와 의미가 다름 — 최빈출 함정)

kms:ViaService = 직접 호출 차단 + 특정 서비스 경유만 허용

선지에서 “~를 통해서만”, “~에서 온 요청만” 표현을 찾으면 됨

Q5. 페더레이션 사용자 S3 버킷 접근 차단

문제

어떤 회사가 Bob이라는 특정 페더레이션 사용자가 DOC-EXAMPLE-BUCKET이라는 Amazon S3 버킷에 접근하지 못하도록 차단하려고 합니다. 이 요구 사항을 충족하기 위해 버킷 정책을 사용하려고 합니다. 또한 이 버킷 정책은 Bob의 S3 권한에만 적용되어야 하며, Bob이 가진 다른 권한은 그대로 유지되어야 합니다.

이러한 요구 사항을 충족하기 위해 회사는 어떤 정책을 사용해야 할까요?

 
{
 
    "Version": "2012-10-17",
 
    "Statement": {
 
        "Principal": {"AWS": "arn:aws:sts::account-id:federated-user/Bob"},
 
        "Effect": "Allow",
 
        "Action": "s3:*",
 
        "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET"
 
    }
 
}

 
{
 
    "Version": "2012-10-17",
 
    "Statement": {
 
        "Principal": {"AWS": "arn:aws:sts::account-id:federated-user/Bob"},
 
        "Effect": "Deny",
 
        "Action": "s3:*",
 
        "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET"
 
    }
 
}

 
{
 
    "Version": "2012-10-17",
 
    "Statement": {
 
        "Principal": {"AWS": "arn:aws:iam::account-id:user/Bob"},
 
        "Effect": "Deny",
 
        "Action": "s3:*",
 
        "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET"
 
    }
 
}

 
{
 
    "Version": "2012-10-17",
 
    "Statement": {
 
        "Principal": {"AWS": "arn:aws:sts::account-id:assumed-role/Bob/role-session-name"},
 
        "Effect": "Deny",
 
        "Action": "s3:*",
 
        "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET"
 
    }
 
}

정답: B

핵심 포인트

1) 요구사항 3요소 분해

| 요구사항 | 대응 |

|---|---|

| “차단하라” | Explicit Deny |

| “페더레이션 사용자” | sts::...:federated-user/ ARN |

| “다른 권한은 유지” | 버킷 정책(리소스 기반) 으로 이 버킷에서만 차단 |

2) 왜 Allow가 아니라 Deny인가


Explicit Deny  >  Allow  >  Implicit Deny(기본 거부)

버킷 정책에서 Allow를 안 준다고 차단되는 게 아님. Bob이 IAM 정책이나 역할로 이미 S3 권한을 갖고 있으면 그걸로 접근됨 → 확실히 막으려면 Explicit Deny 명시

3) 페더레이션이란

외부에서 인증받은 사용자가 AWS 자체 계정 없이 임시 자격 증명으로 AWS를 쓰는 방식

| | IAM 사용자 | 페더레이션 사용자 |

|---|---|---|

| 계정 실체 | AWS에 영구 존재 | 없음 |

| 자격 증명 | 액세스 키(무기한) | STS 임시 토큰(만료됨) |

| 인증 주체 | AWS | 외부 IdP 또는 자체 인증 시스템 |

4) 왜 버킷 정책이어야 하는가

Bob의 IAM 정책에 Deny를 넣으면 적용 범위가 넓어져 “다른 권한 유지” 조건 위반. 버킷 정책은 이 버킷 하나에서만 Bob을 차단하므로 Bob의 EC2 권한이나 다른 버킷 접근은 그대로

5) s3:*와 Resource의 관계 (헷갈리기 쉬움)

s3:* = 액션의 범위 (모든 S3 API)
버킷 vs 객체를 나누는 건 Resource 쪽

| Resource 표기 | 적용 대상 |

|---|---|

| arn:aws:s3:::BUCKET | 버킷 레벨 (ListBucket, GetBucketPolicy) |

| arn:aws:s3:::BUCKET/* | 객체 레벨 (GetObject, PutObject) |

※ 이 문제는 4개 선지가 모두 버킷 ARN만 써서 변별 요소가 아님. 실무에선 둘 다 명시해야 완전 차단

오답 정리

| 선지 | 탈락 이유 |

|---|---|

| A | ARN 형식은 맞지만 Allow라서 요구사항과 정반대 |

| C | iam::...:user/Bob은 IAM 사용자 ARN. Bob은 IAM 사용자가 아니므로 이 정책은 아무에게도 적용 안 됨 |

| D | assumed-role/Bob/role-session-name은 AssumeRole 방식이고, Bob이 역할 이름 자리에 들어간 잘못된 구조 |

꼭 외울 것 — 주체 ARN 형식 (최빈출)

| 진입 경로 | STS API | ARN 형식 |

|---|---|---|

| IAM 사용자 | — | arn:aws:iam::acct:user/Bob |

| 자체 인증 브로커 | GetFederationToken | arn:aws:sts::acct:federated-user/Bob |

| SAML IdP / Identity Center | AssumeRoleWithSAML | arn:aws:sts::acct:assumed-role/Role/Session |

| Cognito, Google, Facebook | AssumeRoleWithWebIdentity | arn:aws:sts::acct:assumed-role/Role/Session |

| 교차 계정 역할 | AssumeRole | arn:aws:sts::acct:assumed-role/Role/Session |

역산 판별

federated-user/이름 → GetFederationToken (자체 브로커, IdP 없음)

assumed-role/역할/세션 → AssumeRole 계열 전부 (SAML, Identity Center, Cognito, 교차계정)

지문에 “SAML”·“Identity Center” 등장 → 정답 ARN은 assumed-role

Q6. 보안 모니터링 전략 매칭

문제

한 회사가 AWS에서 운영 중인 민감한 워크로드에 대한 보안 모니터링 전략을 설계하고 있습니다. 보안 팀은 모니터링 전략이 필요한 여러 시나리오를 파악했습니다.

다음 목록에서 각 모니터링 시나리오에 맞는 모니터링 전략을 선택하십시오. 각 전략은 한 번만 선택할 수 있습니다.

시나리오

A. 멀웨어 탐지 결과가 확인되면 Amazon EC2 인스턴스를 자동으로 격리합니다.
B. 여러 AWS 탐지 서비스의 보안 탐지 결과를 상호 연관시켜 다단계 공격을 식별합니다.
C. 권한 있는 사용자가 비정상적으로 많은 양의 리소스 삭제 작업을 수행할 때 이를 감지합니다.
D. 특정 IP 주소에서 1시간 동안 50회 이상의 인증 실패 시도가 발생하는 패턴을 식별합니다.
E. 특히 정상 근무 시간 외에 외부 IP 주소로의 대용량 데이터 전송과 같은 네트워크 트래픽 패턴을 모니터링합니다.

전략

특정 시간대의 트래픽 양과 대상 패턴을 분석하기 위해 Amazon CloudWatch Logs Insights 쿼리를 사용하여 VPC Flow 로그를 구성합니다.
애플리케이션 로그에 Amazon CloudWatch 메트릭 필터를 생성하여 각 소스 IP 주소별 인증 실패율을 시간 단위로 집계하여 추적합니다.
API 호출률을 분석하여 기준선을 설정하고 비정상적인 API 활동 패턴을 감지하기 위해 AWS CloudTrail Insights를 활성화합니다.
통합된 사고 대응을 위해 Amazon EventBridge 규칙을 사용하여 AWS Security Hub 사용자 지정 인사이트를 구현하고, 자동화된 AWS Lambda 함수를 호출합니다.
(Amazon Detective 활성화 — 다단계 공격 상관분석용)

정답 매칭

| 전략 | 시나리오 | 근거 |

|---|---|---|

| 1. VPC Flow Logs + Logs Insights | E | 네트워크 트래픽 = L3/L4 메타데이터 (소스/대상 IP, 포트, 바이트, 시각) |

| 2. CloudWatch 메트릭 필터 | D | 고정 임계값(50회/1시간) 카운팅 |

| 3. CloudTrail Insights | C | “비정상적으로” = 기준선 자동 학습 필요 + 삭제는 관리 평면 API |

| 4. Security Hub + EventBridge + Lambda | A | 탐지에서 끝나지 않고 조치 실행 체인 존재 |

| 5. Detective | B | 다단계 공격의 연결고리를 그래프로 추적 |

핵심 포인트

1) E → Flow Logs 쿼리 예시

 
fields @timestamp, srcAddr, dstAddr, bytes
 
| filter dstAddr not like /^10\./
 
| stats sum(bytes) as total by srcAddr, dstAddr, bin(1h)
 
| sort total desc

2) A vs B 구분 — 자동화 컴포넌트 유무

| | A (자동 격리) | B (상관분석) |

|---|---|---|

| 필요한 것 | 탐지 → 조치 실행 | findings 집계·연관 |

| Lambda 필요? | 필요 (SG 교체, 스냅샷) | 불필요 |

| EventBridge 필요? | 필요 (트리거) | 불필요 |

A의 실제 흐름:


GuardDuty Malware Protection findings 생성

→ Security Hub로 집계

→ EventBridge 규칙이 severity/type 매칭

→ Lambda 실행: 격리 SG로 교체 + EBS 스냅샷 + 태깅

꼭 외울 것 — 3단계 공략법

1단계 — 데이터 소스 확정

| 키워드 | 서비스 |

|---|---|

| IP, 포트, 전송량, 대역폭 | VPC Flow Logs |

| API 호출, 누가 무엇을 했나 | CloudTrail |

| 애플리케이션 로그, 로그인 실패 | CloudWatch Logs |

| 멀웨어, 이상 행위, 위협 인텔 | GuardDuty |

| 여러 서비스 findings 통합 | Security Hub |

| 공격 경로 추적, 다단계 상관분석 | Detective |

2단계 — 고정 임계값 vs 기준선 학습

숫자 명시(“50회”) → 메트릭 필터 + 알람

“비정상적”, “평소와 다른” → Insights / GuardDuty / Detective

3단계 — 탐지만인가, 조치까지인가

“식별합니다”, “모니터링합니다” → 탐지 서비스만

“자동으로 격리/차단/대응” → EventBridge + Lambda(또는 SSM Automation) 필수

Q7. S3 영구 삭제 방지 + 재해 복구

문제

회사는 중요 데이터가 영구적으로 삭제되지 않도록 보호하는 솔루션이 필요합니다. 데이터는 Amazon S3 버킷에 저장되어 있습니다.

재해 복구 요구 사항을 충족하기 위해 기본 AWS 리전의 S3 객체를 보조 리전으로 복제해야 합니다. 또한 관리자 권한이 있는 사용자가 보조 리전의 데이터를 영구적으로 삭제할 수 없도록 해야 합니다.

이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

A. AWS Backup을 구성하여 리전 간 S3 백업을 수행합니다. 보조 리전에서 백업 볼트를 선택합니다. 보조 리전의 백업에 대해 거버넌스 모드에서 AWS Backup 볼트 잠금을 활성화합니다.

B. 기본 리전에서 규정 준수 모드로 S3 객체 잠금을 구현합니다. S3 복제를 구성하여 객체를 보조 리전의 S3 버킷으로 복제합니다.

C. S3 복제를 구성하여 객체를 보조 리전의 S3 버킷으로 복제합니다. 보조 리전의 S3 버킷에 s3:ReplicateDelete 작업을 거부하는 S3 버킷 정책을 생성합니다.

D. S3 복제를 구성하여 객체를 보조 리전의 S3 버킷으로 복제합니다. S3 객체 버전 관리를 구성합니다.

정답: B

핵심 포인트

1) 요구사항 분리

| 요구사항 | 해결 수단 |

|---|---|

| 재해 복구 → 보조 리전 복제 | S3 Replication (CRR) |

| 관리자도 영구 삭제 불가 | Object Lock — Compliance 모드 |

2) Governance vs Compliance (승부처)

| 모드 | 누가 해제/삭제 가능한가 |

|---|---|

| Governance(거버넌스) | s3:BypassGovernanceRetention 권한자가 우회 가능 |

| Compliance(규정 준수) | 아무도 불가. 루트 계정도, AWS도 불가. 보존 기간 만료까지 삭제·단축 모두 차단 |

문제가 “관리자 권한이 있는 사용자가 영구적으로 삭제할 수 없어야”라고 못 박았으니 Compliance만 정답

이것이 WORM(Write Once Read Many) 개념 — 금융권 SEC 17a-4, 국내 전자금융감독규정처럼 감사 증적 위변조 방지가 필요할 때 사용

3) 왜 기본 리전에만 걸어도 되는가

S3 Replication이 Object Lock 보존 설정까지 함께 복제하기 때문


[기본 리전]                    [보조 리전]

객체 + Compliance 잠금  ──복제──>  객체 + Compliance 잠금

                                   (보존 기간 그대로 승계)

전제 조건: 양쪽 버킷 모두 버전 관리 활성화 + Object Lock 활성화

오답 정리

| 선지 | 탈락 이유 |

|---|---|

| A | Vault Lock 자체는 유효하나 거버넌스 모드라 관리자가 잠금을 풀 수 있음 → 요구사항 미충족. 모드 단어 하나만 바꿔놓은 전형적 함정 |

| C | s3:ReplicateDelete는 복제 프로세스가 삭제 마커를 전파하는 것만 통제. 보조 리전에서 관리자가 직접 DeleteObjectVersion 호출하는 건 전혀 못 막음 |

| D | 버전 관리는 실수로 인한 삭제 복구용. 관리자가 DeleteObjectVersion으로 특정 버전을 지정 삭제하면 영구 삭제됨 |

꼭 외울 것

영구 삭제 방지 계층 서열

버전 관리 → 실수 복구용. 버전 지정 삭제는 못 막음

MFA Delete → 버전 삭제에 MFA 요구. 루트만 설정 가능

Object Lock 거버넌스 → 특정 권한자(BypassGovernanceRetention) 우회 가능

Object Lock 규정준수 → 누구도 불가 (루트·AWS 포함)

지문 표현 → 정답 매핑

| 지문 표현 | 정답 |

|---|---|

| “실수로 삭제된 경우 복구” | 버전 관리 |

| “권한 있는 사용자는 예외적으로 삭제 가능” | Governance |

| “관리자도 / 루트도 / 어떤 경우에도 삭제 불가” | Compliance |

| “규정 준수, 감사 요건, WORM” | Compliance |

Q8. 침해 사고 대응 KMS 키 삭제

문제

보안 엔지니어가 AWS 계정에 영향을 미치는 사고에 대응하고 있습니다. 계정 ID는 1234156789012입니다. 공격자는 여러 AWS 리전에 분산된 워크로드를 생성했습니다.

보안 엔지니어는 공격을 차단했습니다. 영향을 받은 모든 리전에서 모든 컴퓨팅 및 스토리지 리소스를 제거했습니다. 그러나 공격자는 AWS KMS 키도 생성했습니다. KMS 키에 대한 키 정책은 IAM 주체에 kms:* 권한을 명시적으로 허용합니다.

해당 키는 전날 삭제되도록 예약되었지만 여전히 활성화되어 사용 가능합니다. 키의 ARN은 arn:aws:kms:us-east-2:123456789012:key/mrk-0bb0212cd9864fdea0dcamzo26efb5670입니다.

보안 엔지니어는 가능한 한 빨리 이 키를 삭제해야 합니다.

이 요구 사항을 충족하는 솔루션은 무엇입니까?

A. 계정 루트 사용자 자격 증명을 사용하여 계정에 로그인합니다. KMS 키 삭제 요청을 7일 대기 기간으로 다시 제출합니다.

B. KMS 키가 존재하는 다른 리전을 확인하고 7일 후에 키 삭제를 예약합니다.

C. IAM 주체를 업데이트하여 KMS 키 ARN에 kms:* 권한을 허용합니다. KMS 키 삭제 요청을 7일 대기 기간으로 다시 제출합니다.

D. KMS 키를 비활성화합니다. KMS 키 삭제 요청을 30일 후에 다시 제출합니다.

정답: B

핵심 포인트

1) 지문의 핵심 단서 2개

| 단서 | 함의 |

|---|---|

| “여러 리전에 분산된 워크로드” | 다른 리전에도 KMS 키가 있을 가능성 → 확인 필요 |

| “어제 삭제 예약됐지만 여전히 활성” | 문제가 아니라 정상 동작 (PendingDeletion 상태) |

2) KMS 삭제 대기 기간은 정상 동작

| 항목 | 값 |

|---|---|

| 대기 기간 | 7~30일 (기본 30일) |

| 대기 중 상태 | PendingDeletion — 사용 불가 |

| 취소 가능 여부 | 대기 기간 내 CancelKeyDeletion으로 복구 가능 |

왜 즉시 삭제가 안 되나 — 키를 지우면 그 키로 암호화된 모든 데이터가 영구히 복구 불가해지므로 AWS가 강제로 유예 기간을 둠

→ 지문의 “활성화되어 사용 가능”은 콘솔 목록에 보인다는 뜻. 실제로는 이미 처리 진행 중이고 엔지니어가 할 일은 남은 리전 정리

3) 남겨진 키의 위험

공격자가 나중에 데이터를 복호화하거나 백도어로 재진입하는 경로가 될 수 있음. 침해 대응에서 가장 흔한 실수가 눈에 보이는 리전만 정리하고 끝내는 것

오답 정리

| 선지 | 탈락 이유 |

|---|---|

| A | ① 키 정책이 이미 kms:* 허용 중이라 루트 불필요 (최소 권한 위반) ② 이미 PendingDeletion이면 삭제 요청 재제출 불가 (CancelKeyDeletion 후 재예약해야 함) |

| C | 지문이 이미 권한 허용을 명시 → 불필요한 조작 distractor |

| D | ① 비활성화는 삭제가 아님 (Disabled는 언제든 재활성화 가능) ② 30일은 최대치라 “가능한 한 빨리”와 배치 |

꼭 외울 것

1. KMS 키 삭제 3종 구분

| 작업 | 결과 | 되돌리기 |

|---|---|---|

| DisableKey | 사용만 중지, 키는 존재 | EnableKey로 즉시 |

| ScheduleKeyDeletion | 7~30일 후 영구 삭제 | 대기 중 CancelKeyDeletion |

| 대기 기간 만료 | 영구 삭제, 복구 불가 | 불가능 |

2. 사고 대응 문제에서 “여러 리전” 언급 시 → 리전 확인 선지가 정답 후보

3. “루트 자격 증명 사용”은 거의 항상 오답

루트가 정답인 경우: 계정 해지, 결제 정보 변경, 루트 액세스 키 삭제, S3 MFA Delete 설정, 잘못 설정된 키 정책 복구

Q9. EC2 + 온프레미스 SSH 대체

문제

한 회사가 여러 Amazon EC2 인스턴스와 온프레미스 서버에 배포된 타사 애플리케이션을 설치했습니다. 이 회사의 IT 팀은 소프트웨어 유지 관리 작업을 수행하기 위해 SSH를 사용하여 각 머신에 연결해야 하는 경우가 있습니다. 이러한 작업 시간 외에는 머신이 네트워크의 나머지 부분과 완전히 격리되어야 합니다. 회사는 SSH 키를 관리하고 싶지 않으며, SSH 연결이 있는 시간만큼만 비용을 지불하기를 원합니다.

다음과 같은 요구 사항을 충족하는 솔루션은 무엇입니까?

A. 포트 포워딩을 사용하여 머신에 연결할 수 있는 배스천 호스트를 생성합니다.

B. 임시 연결을 허용하도록 AWS Systems Manager Session Manager를 설정합니다.

C. AWS CloudShell을 사용하여 서버리스 연결을 생성합니다.

D. 각 머신에 대해 프라이빗 연결을 위한 VPC 엔드포인트 인터페이스를 설정합니다.

정답: B

핵심 포인트

1) 요구사항 4개 대응표

| 요구사항 | Session Manager의 해결 |

|---|---|

| EC2 + 온프레미스 | 하이브리드 활성화 (mi- 관리형 인스턴스) |

| 작업 시간 외 완전 격리 | 인바운드 포트 0개 |

| SSH 키 관리 불필요 | IAM 기반 인증 |

| 연결 시간만큼만 과금 | 상시 인프라 없음, 서비스 자체 추가 요금 없음 |

2) 동작 구조 — 양쪽이 밖으로 나와서 만남


        ┌─────────────────────┐

        │  SSM 서비스 (AWS)    │  ← 중립 지대(만남의 장소)

        └─────────────────────┘

           ▲               ▲

    아웃바운드 443     아웃바운드 443

           │               │

      [타겟 서버]      [관리자]


❌ 기존 SSH:  관리자 → 인바운드 22번 → 서버

✅ Session Manager:  서버의 SSM Agent → 아웃바운드 443 → SSM 서비스

                     관리자 → SSM 서비스 → (기존 연결 재사용)

세션 수립 절차

SSM Agent가 부팅 시 SSM 엔드포인트로 아웃바운드 연결 수립 (long polling)
관리자가 StartSession API 호출 (IAM 권한 검증)
SSM이 기존 연결로 “세션 시작” 신호 전달
Agent가 로컬에서 셸 프로세스 생성 (기본 ssm-user)
입력/출력이 WebSocket 터널로 양방향 스트리밍

→ 명령 실행은 타겟 서버 안에서 일어남. 중간 지점은 입출력을 나르는 터널일 뿐

3) 배스천과의 결정적 차이

| | 배스천 | Session Manager |

|---|---|---|

| 중간 지점 소유 | 내가 만든 EC2 | AWS 관리 서비스 |

| 인바운드 포트 | 필요 | 불필요 |

| 인증 | SSH 키 × 2회 (관리자→배스천, 배스천→타겟) | IAM 1회 |

| 유휴 비용 | 발생 | 없음 |

| 명령어 감사 | 별도 구성 필요 | 기본 제공 |

※ 배스천은 SSH를 없애는 게 아니라 한 곳으로 모으는 구조. ProxyJump나 Agent Forwarding으로 편해질 뿐 키가 사라지지 않고, Agent Forwarding은 배스천 침해 시 관리자 키 도용 위험까지 추가

4) 감사 증적

CloudTrail(누가 언제 접속) + S3/CloudWatch Logs(입력한 명령어 전체) → ISMS-P 서버 접근통제·로그 항목 대응에 유리

오답 정리

| 선지 | 탈락 이유 |

|---|---|

| A | ① EC2 24시간 가동 → 유휴 과금 ② 배스천에 SSH 인바운드 개방 필요 ③ SSH 키 계속 관리 → 요구사항 4개 중 3개 위반 |

| C | CloudShell은 브라우저에서 AWS CLI를 돌리는 셸. AWS API 호출용이지 서버 접속 도구가 아님. 온프레미스는 더더욱 불가 |

| D | VPC 엔드포인트는 “AWS 서비스로 가는 사설 경로” 를 만드는 부품. 셸을 제공하지 않음. AZ당 시간 과금이라 비용 요구사항과도 충돌. 온프레미스 커버 불가 |

D가 정답의 일부가 되는 경우

프라이빗 서브넷 + NAT 게이트웨이 없이 Session Manager를 쓰려면 인터페이스 엔드포인트 3종이 필요:

ssm / ssmmessages / ec2messages

꼭 외울 것

“SSH 키 관리 없이 / 포트 개방 없이 / 배스천 없이” → Session Manager 반사적으로

배스천 호스트 선지는 대부분 오답 (AWS는 배스천을 레거시로 취급 — 관리 부담·상시 비용·공격 표면)

온프레미스가 지문에 등장하면 Systems Manager 계열 의심

(Patch Manager, Run Command, Session Manager, Inventory 모두 하이브리드 활성화로 온프레미스 관리)

Q10. EKS 위협 탐지

문제

한 회사가 Amazon Elastic Kubernetes Service(Amazon EKS)에서 여러 애플리케이션을 운영하고 있습니다. 이 회사는 운영 체제, 네트워킹 및 파일 이벤트 외에도 Amazon EKS 감사 로그를 모니터링하여 Kubernetes 보안 위협을 감지하는 솔루션이 필요합니다. 또한, 식별된 위협에 대해 보안 팀과 연결된 메일링 리스트로 이메일 알림을 전송해야 합니다.

이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

A. AWS Security Hub를 배포하고 EKS 제어 기능을 포함하는 보안 표준을 활성화합니다. Amazon SNS 토픽을 생성하고 보안 팀의 메일링 리스트를 구독자로 설정합니다. Amazon EventBridge 규칙을 사용하여 관련 Security Hub 이벤트를 SNS 토픽으로 전송합니다.

B. Amazon Inspector 컨테이너 이미지 스캔을 활성화합니다. Amazon Detective를 구성하여 EKS 보안 로그를 분석합니다. EKS 감사 로그용 Amazon CloudWatch 로그 그룹을 생성합니다. AWS Lambda 함수를 사용하여 로그를 처리하고 보안 팀에 이메일 알림을 전송합니다.

C. Amazon GuardDuty를 활성화합니다. GuardDuty에서 Amazon EKS에 대한 EKS 보호 및 런타임 모니터링을 활성화합니다. Amazon SNS 토픽을 생성하고 보안 팀의 메일링 리스트를 구독자로 설정합니다. Amazon EventBridge 규칙을 사용하여 관련 GuardDuty 이벤트를 SNS 토픽으로 전송합니다.

D. 모든 EKS 노드에 AWS Systems Manager Agent(SSM Agent)를 설치합니다. Amazon CloudWatch Logs를 구성하여 EKS 감사 로그를 수집합니다. Amazon SNS 토픽을 생성하고 보안 팀의 메일링 리스트를 구독자로 설정합니다. 감사 로그가 생성될 때 SNS 토픽에 메시지를 게시하도록 CloudWatch 알람을 구성합니다.

정답: C

핵심 포인트

1) 요구사항이 두 갈래

| 요구사항 | 필요 기능 |

|---|---|

| OS, 네트워킹, 파일 이벤트 | 런타임 모니터링 (호스트 레벨) |

| EKS 감사 로그 | 컨트롤 플레인 감사 로그 분석 |

2) GuardDuty의 EKS 2계층 — 이 문제의 출제 의도

| 기능 | 데이터 소스 | 탐지 대상 |

|---|---|---|

| EKS Protection | EKS 감사 로그 | 익명 사용자 API 접근, 권한 상승, 컨테이너 이스케이프 시도 |

| Runtime Monitoring | eBPF 기반 에이전트 | 프로세스 실행, 파일 접근, 네트워크 연결 |

지문 요구사항이 이 두 개에 1:1 대응 → C가 “EKS 보호 및 런타임 모니터링” 둘 다 명시한 게 결정적

3) 로그 수집 ≠ 위협 탐지


로그 수집 → 저장 → [??] → 위협 판단

                    ↑

            여기에 탐지 로직이 필요

GuardDuty는 AWS 위협 인텔리전스 + ML + 공격 패턴 시그니처를 내장해 판단까지 해줌

탐지 예시:

system:anonymous로 Kubernetes API 호출 → 인증 우회
컨테이너에서 호스트 파일시스템 마운트 → 컨테이너 이스케이프
암호화폐 채굴 도메인으로 아웃바운드 연결
/etc/shadow 읽기 시도

4) 알림 체인 (표준 패턴)


GuardDuty finding 생성

  → EventBridge 규칙 매칭 (source: aws.guardduty)

  → SNS 토픽

  → 메일링 리스트 이메일

오답 정리

| 선지 | 탈락 이유 |

|---|---|

| A | ① Security Hub는 스스로 탐지하지 않음 (하위 서비스 findings 집계) — GuardDuty 없이는 EKS 런타임 이벤트가 들어올 곳이 없음 ② 보안 표준은 설정 상태 점검용이지 실시간 파일·프로세스 이벤트를 안 봄 |

| B | Inspector(배포 전 CVE 스캔) + Detective(사후 조사, 탐지 안 함) + CloudWatch/Lambda(수집·전달만) → 위협을 판단하는 주체가 없음 |

| D | ① 감사 로그만 수집 → “OS/네트워킹/파일 이벤트” 전혀 미커버 ② “감사 로그 생성 시 알림” = 정상 활동에도 알림 폭탄 ③ SSM Agent는 노드 관리용이지 런타임 보안 도구가 아님 |

꼭 외울 것

1. 컨테이너/EKS 보안 서비스 역할 구분

| 서비스 | 시점 | 역할 |

|---|---|---|

| Inspector | 배포 전 | 이미지 취약점(CVE) 스캔 |

| GuardDuty | 런타임 | 위협 탐지 (감사 로그 + 호스트 이벤트) |

| Security Hub | 상시 | findings 집계, 규정 준수 점검 |

| Detective | 사후 | 근본 원인 조사, 공격 경로 추적 |

2. “운영 체제 / 프로세스 / 파일 / 네트워크 이벤트” → GuardDuty Runtime Monitoring

(EKS, ECS Fargate, EC2 모두 지원)

3. 요구사항이 두 갈래면 양쪽을 다 명시한 선지를 찾는다

Q11. IoT Core 클라이언트 ID 위장 방어

문제

한 회사가 사용자에게 모바일 앱을 다운로드할 수 있도록 제공합니다. 이 앱은 MQTT 기반이며 사용자가 AWS IoT Core에 연결하여 특정 클라이언트 관련 토픽을 구독합니다.

최근 이 회사는 악의적인 공격자들이 정상적인 모바일 기기에 트로이 목마를 심으려 시도하였다는 것을 발견했습니다. 이 트로이 목마는 정식 애플리케이션으로 위장하고 특수 문자가 삽입된 클라이언트 ID를 사용하여 클라이언트 권한 범위를 벗어난 토픽에 접근합니다.

이 위협을 방지하기 위해 회사는 어떤 조치를 취해야 할까요? (두 가지 선택)

A. 애플리케이션에서 IoT 사물 이름을 클라이언트 ID로 사용하여 디바이스를 AWS IoT Core에 연결합니다.

B. 애플리케이션에 클라이언트 ID 검사 기능을 추가합니다. 특수 문자가 감지되면 서버 연결을 끊습니다.

C. 주체를 client/${iot:Connection.Thing.ThingName}으로 설정하고 AWSIoTWirelessDataAccess를 허용하는 AWS IoT Core 정책을 적용합니다.

D. 리소스를 client/${iot:ClientId}로 설정하고 iot:Connect를 허용하는 AWS IoT Core 정책을 디바이스에 적용합니다.

E. 리소스를 client/${iot:Connection.Thing.ThingName}으로 설정하고 iot:Connect를 허용하는 AWS IoT Core 정책을 디바이스에 적용합니다.

정답: A, E

핵심 포인트

1) 공격 원리

MQTT에서 클라이언트 ID는 연결할 때 클라이언트가 스스로 신고하는 값. 서버가 부여하는 게 아니므로 트로이 목마 앱이 임의 조작 가능


정상: clientId = "device-001"    → client/device-001 토픽만

공격: clientId = "device-*"      → 와일드카드로 범위 확장 시도

      clientId = "device-001/#"  → 하위 토픽 전체 접근 시도

MQTT 와일드카드(+, #)나 경로 구분자가 정책 변수에 그대로 치환되면서 의도보다 넓은 리소스에 매칭됨

2) 정책 변수 신뢰도 — 이 문제의 전부

| 변수 | 값의 출처 | 검증 여부 |

|---|---|---|

| ${iot:ClientId} | 클라이언트가 CONNECT 패킷에 넣은 값 | ❌ 검증 없음 |

| ${iot:Connection.Thing.ThingName} | IoT 레지스트리의 사물(Thing) 이름 | ✅ 인증서-사물 연결 검증 |

iot:ClientId는 사용자 입력을 그대로 권한 판단에 쓰는 것과 같음 (웹 취약점으로 치면 클라이언트가 보낸 user_id를 신뢰하는 셈)

Thing 정책 변수의 검증 절차

연결에 쓴 X.509 인증서가 어떤 사물에 attach되어 있는지 레지스트리 조회
그 사물의 이름을 변수에 치환
클라이언트 ID와 사물 이름이 일치하는지 확인

→ 공격자가 특수 문자를 넣어도 레지스트리에 그런 사물이 없으니 연결 자체가 실패

3) 올바른 정책

 
{
 
  "Effect": "Allow",
 
  "Action": "iot:Connect",
 
  "Resource": "arn:aws:iot:region:acct:client/${iot:Connection.Thing.ThingName}"
 
}

4) A와 E가 세트인 이유

E = 정책 리소스를 검증되는 변수로 교체 (일치를 강제)
A = Thing 정책 변수 동작 전제인 “클라이언트 ID = 사물 이름”을 맞춤 (일치시키기)

E만 적용하고 앱이 여전히 임의 클라이언트 ID를 쓰면 정상 기기도 불일치로 연결 실패

오답 정리

| 선지 | 탈락 이유 |

|---|---|

| B | 클라이언트 측 검증. 공격자가 이미 앱을 변조해 트로이 목마를 배포한 상황인데 그 앱 안에 검사 로직을 넣는 건 무의미. 검증은 항상 신뢰 경계 안쪽(서버) 에서 |

| C | ① Principal이 아니라 Resource (IoT 정책은 인증서에 붙는 구조라 Principal을 따로 안 씀) ② AWSIoTWirelessDataAccess는 LoRaWAN/Sidewalk용 — MQTT와 무관. 필요한 액션은 iot:Connect |

| D | 형식은 맞지만 변수가 검증되지 않음. 공격자가 clientId = "evil-*"로 연결하면 정책 리소스도 client/evil-*로 치환 → 자기가 보낸 값끼리 비교하니 항상 일치 → 제약이 전혀 안 걸림 |

꼭 외울 것

1. IoT Core 변수 신뢰도 서열

검증됨: iot:Connection.Thing.ThingName

iot:Connection.Thing.Attributes[속성명]

iot:Certificate.Subject.CommonName

비검증: iot:ClientId ← 클라이언트가 보낸 값 그대로

지문에 “스푸핑, 위장, 권한 범위 이탈” → iot:ClientId 쓰는 선지는 오답

2. Thing 정책 변수 사용 전제 조건 3가지

① 사물이 IoT 레지스트리에 등록

② 인증서가 그 사물에 연결(attach)

③ 클라이언트 ID = 사물 이름

3. 클라이언트 측 검증 선지는 항상 오답

(“앱에서 검사”, “SDK에서 필터링”, “디바이스에서 확인” = 공격자 통제 영역)

Q12. 구성 변경 추적 + 규정 준수

문제

보안 엔지니어가 특정 AWS 리소스의 구성 변경 사항을 평가하여 해당 리소스가 규정 준수 표준을 충족하는지 확인하려고 합니다. 그러나 보안 엔지니어는 해당 리소스에 여러 구성 변경이 빠르게 연속적으로 발생하는 상황을 우려하고 있습니다. 보안 엔지니어는 이러한 변경 사항들의 누적 영향을 파악하기 위해 해당 리소스의 최신 구성만 기록되기를 원합니다.

이 요구 사항을 가장 운영 효율적인 방식으로 충족하는 솔루션은 무엇입니까?

A. AWS CloudTrail을 사용하여 API 호출을 필터링하여 변경 사항을 모니터링하고 구성 변경을 감지합니다. 여러 호출의 누적 영향을 파악하기 위해 가장 최근의 API 호출을 사용합니다.

B. AWS Config를 사용하여 구성 변경을 감지하고, 여러 구성 변경이 발생한 경우 최신 구성을 기록합니다.

C. Amazon CloudWatch를 사용하여 API 호출을 필터링하여 변경 사항을 모니터링하고 구성 변경을 감지합니다. 여러 호출의 누적 영향을 파악하기 위해 가장 최근의 API 호출을 사용합니다.

D. AWS Cloud Map을 사용하여 구성 변경을 감지합니다. 슬라이딩 타임 윈도우를 사용하여 AWS Cloud Map에서 구성 변경 보고서를 생성하고 최신 상태를 추적합니다.

정답: B

핵심 포인트

1) 지문 키워드 → 방향

| 지문 표현 | 함의 |

|---|---|

| 구성 변경 평가 | 리소스 설정 상태 추적 |

| 규정 준수 표준 충족 | 규칙 기반 자동 평가 |

| 변경이 연속적으로 빠르게 발생 | 중간 상태 처리 방식 |

| 최신 구성만 기록 | 최종 상태 기준 판단 |

| 가장 운영 효율적 | 직접 구현보다 관리형 서비스 |

2) Config가 하는 일


[t1] SG: 22번 포트 0.0.0.0/0 개방

[t2] SG: 3389번 추가

[t3] SG: 22번 제거

     ↓

Config: 각 시점의 "전체 구성"을 Configuration Item으로 저장

        + 최신 상태를 Config Rules로 평가 → 준수/미준수 판정

변경이 짧은 시간에 몰릴 때 매 순간을 다 기록하지 않고 안정화된 시점의 최종 구성을 하나의 Configuration Item으로 남김 → 지문 요구와 정확히 일치

3) CloudTrail과의 결정적 차이 (핵심)

| | CloudTrail | Config |

|---|---|---|

| 기록 단위 | 개별 API 호출 | 리소스 구성 상태 |

| 답하는 질문 | 누가 언제 무엇을 호출했나 | 지금 이 리소스가 어떤 상태인가 |

| 누적 결과 | 직접 재구성해야 함 | 자동으로 최종 상태 제공 |

| 규정 준수 평가 | 없음 | Config Rules 내장 |

"최근 API 호출 = 최신 구성"은 성립하지 않음

t1: AuthorizeSecurityGroupIngress (22번 추가)

t2: AuthorizeSecurityGroupIngress (3389번 추가)

t3: RevokeSecurityGroupIngress (22번 제거)

→ 가장 최근 API는 “22번 제거”

→ 하지만 현재 구성은 “3389번이 열려 있음”

전체 이력을 순서대로 재생(replay)해야 현재 상태를 알 수 있고, 그걸 직접 구현하는 건 “운영 효율적”과 정반대

4) 실무 연결 — ISMS-P

Config Rules 관리형 규칙: s3-bucket-public-read-prohibited, encrypted-volumes, iam-password-policy 등

Conformance Pack으로 PCI DSS, HIPAA, CIS 벤치마크 일괄 적용 가능

→ “암호화 적용 여부”, “접근통제 설정 상태” 같은 심사 항목을 자동 상시 점검 + 증적 확보

오답 정리

| 선지 | 탈락 이유 |

|---|---|

| A | 최근 API ≠ 최신 구성. 규정 준수 평가 기능도 없어 Lambda로 판정 로직 직접 구현 필요 → 운영 효율 위반 |

| C | CloudWatch는 메트릭·로그 서비스. API 호출을 보려면 CloudTrail 로그를 CloudWatch Logs로 보내야 하므로 A와 같은 문제를 그대로 안음 |

| D | Cloud Map은 서비스 디스커버리 도구 (마이크로서비스가 서로의 엔드포인트를 찾는 DNS 기반 레지스트리). 구성 변경·규정 준수와 무관. “Config”와 이름만 비슷한 함정 |

꼭 외울 것

1. 로그·모니터링 4대장 반사적 구분

| 질문 | 서비스 |

|---|---|

| 누가 무엇을 했나 | CloudTrail |

| 지금 어떤 상태인가 / 규정을 지키나 | Config |

| 성능·수치가 임계값을 넘었나 | CloudWatch |

| IP·포트·전송량은 | VPC Flow Logs |

2. “규정 준수(compliance)” 단어가 나오면 Config를 먼저

3. 자동 조치까지 요구하면 Config Rules + SSM Automation(Remediation)

Q13. CloudHSM 사용자 지정 키 저장소

문제

보안 엔지니어가 회사의 암호화 작업에 사용되는 키를 생성하고 제어하는 솔루션을 구현하려고 합니다. 보안 엔지니어는 AWS CloudHSM 클러스터 기반의 사용자 지정 키 저장소에 키 자료를 생성하고 사용하는 대칭 키를 생성해야 합니다.

보안 엔지니어는 애플리케이션 내에서 로컬로 사용하기 위해 대칭 및 비대칭 데이터 키를 사용합니다. 또한 키 사용에 대한 감사도 수행해야 합니다.

보안 엔지니어는 이러한 요구 사항을 어떻게 충족할 수 있습니까?

A. 키 생성에는 AWS Key Management Service(AWS KMS)와 CloudHSM 클러스터의 사용자 지정 키 저장소를 사용합니다. 감사에는 Amazon Athena를 사용합니다.

B. 키 생성에는 Amazon S3와 CloudHSM 클러스터의 사용자 지정 키 저장소를 사용합니다. 감사에는 AWS CloudTrail을 사용합니다.

C. 키 생성에는 AWS Key Management Service(AWS KMS)와 CloudHSM 클러스터의 사용자 지정 키 저장소를 사용합니다. 감사에는 Amazon GuardDuty를 사용합니다.

D. 키를 생성하려면 AWS Key Management Service(AWS KMS)와 CloudHSM 클러스터의 사용자 지정 키 저장소를 사용하십시오. 감사를 위해서는 AWS CloudTrail을 사용하십시오.

정답: D

핵심 포인트

1) 2축 채점 — 이 유형의 풀이법

| 선지 | 키 생성 | 감사 |

|---|---|---|

| A | KMS + Custom Key Store ✅ | Athena ❌ |

| B | S3 ❌ | CloudTrail ✅ |

| C | KMS + Custom Key Store ✅ | GuardDuty ❌ |

| D | ✅ | ✅ |

문장을 통으로 읽으면 C와 D가 구분 안 가지만, 축별로 O/X를 매기면 1초 만에 갈림

2) Custom Key Store 구조


[일반 KMS]         KMS 관리 HSM (AWS 소유·운영, 멀티테넌트)

[Custom Key Store] KMS API  →  내 CloudHSM 클러스터 (단독 점유)

                   ↑ 인터페이스는 KMS 그대로 (S3/EBS/RDS 통합 유지)

                   ↑ 키 자료는 내 HSM에 격리 저장

왜 쓰나 — 지문의 “키를 생성하고 제어”가 답. FIPS 140-2 Level 3 단독 HSM에 키를 두면서도 KMS 통합 서비스를 그대로 사용. 금융·공공의 키 주권 요구 대응

3) 봉투 암호화(Envelope Encryption)

지문의 “대칭 키를 로컬에서 사용해 데이터 키를 암복호화”가 이것


1. GenerateDataKey 호출

2. KMS가 [평문 데이터 키 + 암호화된 데이터 키] 반환

3. 앱이 평문 키로 로컬에서 데이터 암호화 → 즉시 메모리 폐기

4. 암호화된 데이터 키는 데이터 옆에 저장

→ 마스터 키는 HSM 밖으로 절대 나오지 않고, 대용량 데이터는 로컬에서 빠르게 처리

4) “감사” = CloudTrail

KMS의 모든 API 호출(Encrypt, Decrypt, GenerateDataKey, CreateGrant 등)이 CloudTrail 이벤트로 기록 → 호출 주체·시각·소스 IP·대상 키 ARN

오답 정리

| 선지 | 탈락 이유 |

|---|---|

| A | Athena는 S3 데이터를 SQL로 쿼리하는 도구. 감사 데이터를 생성하지 않음. CloudTrail 로그가 S3에 쌓인 뒤 분석하는 후속 도구 (CloudTrail 없으면 쿼리할 대상 자체가 없음) |

| B | S3는 객체 스토리지. 키 생성 기능 없음. 키를 파일로 S3에 넣는 발상은 “키를 제어·격리”와 정반대 |

| C | GuardDuty는 위협 탐지 서비스. 이상 행위를 판단해 findings를 만들 뿐, 정상 활동을 포함한 전체 감사 기록을 남기지 않음 |

꼭 외울 것

1. “감사(audit)” = CloudTrail 반사적으로

| 지문 표현 | 서비스 |

|---|---|

| 감사, 사용 기록, 누가 무엇을 | CloudTrail |

| 위협 탐지, 이상 행위 | GuardDuty |

| 로그를 SQL로 분석 | Athena (CloudTrail 이후 단계) |

| 구성 상태, 규정 준수 | Config |

2. KMS 키 저장소 4종

| 방식 | 키 자료 위치 | 언제 |

|---|---|---|

| KMS 기본 | AWS 관리 HSM (공유) | 일반 |

| Custom Key Store (CloudHSM) | 내 CloudHSM 클러스터 | 단독 HSM·FIPS L3 |

| Custom Key Store (External) | 외부 키 관리자 | 온프레미스 HSM 유지 |

| Import Key Material (BYOK) | 내가 생성해 반입 | 키 생성 주권만 필요 |

3. 선지가 2축으로 갈리면 축별로 따로 채점

개념 보충. 질문하며 정리한 것들

1) NotAction의 진짜 의미

“이 액션을 하지 않는다”가 아니라 “이 액션을 제외한 나머지 전부”

 
"Effect": "Deny",
 
"NotAction": "sts:AssumeRole"

→ “sts:AssumeRole만 빼고 나머지 전부 Deny” (AssumeRole을 살려두는 carve-out)

실무 패턴 — MFA 강제 시 필수 예외

 
{
 
  "Sid": "DenyAllExceptListedIfNoMFA",
 
  "Effect": "Deny",
 
  "NotAction": [
 
    "iam:CreateVirtualMFADevice",
 
    "iam:EnableMFADevice",
 
    "iam:ChangePassword",
 
    "sts:GetSessionToken"
 
  ],
 
  "Resource": "*",
 
  "Condition": {
 
    "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" }
 
  }
 
}

MFA 없으면 다 막되 MFA를 등록하러 갈 수 있는 최소 액션은 열어둬야 함

→ 안 그러면 신규 사용자가 MFA를 켤 방법이 없는 닭-달걀 문제

| 조합 | 의미 |

|---|---|

| Action | 나열한 것”에 대해” |

| NotAction | 나열한 것”을 제외한 나머지에 대해” |

| Deny + NotAction | 예외만 남기고 전부 차단 (화이트리스트) |

| Allow + NotAction | 예외만 빼고 전부 허용 (위험, 잘 안 씀) |

주의: 한 Statement 안에 Action과 NotAction은 공존 불가

2) StringNotEquals 해석법

“값이 나열된 것들과 하나도 같지 않으면 조건 매치” — 조건 자체가 부정형이라 Effect와 곱해 두 번 뒤집어 읽음

| 조합 | 읽는 법 |

|---|---|

| Allow + StringNotEquals | 값이 다를 때만 허용 |

| Deny + StringNotEquals | 값이 다르면 차단 = 나열된 값만 통과 ← 실무 표준 |

가장 흔한 실전 패턴

 
{
 
  "Effect": "Deny",
 
  "Action": "s3:*",
 
  "Resource": "*",
 
  "Condition": {
 
    "StringNotEquals": { "aws:PrincipalOrgID": "o-abc123" }
 
  }
 
}

“우리 조직 소속이 아니면 전부 차단” → 결과적으로 화이트리스트

StringEquals + Allow로 짜면 다른 Allow 정책이 뚫고 들어올 수 있지만, Deny + StringNotEquals는 Explicit Deny라 무엇도 못 뚫음

함정 1 — 키가 없으면 매치 → Deny 발동

Dept 태그가 없는 사용자도 Deny에 걸림. 통과시키려면 StringNotEqualsIfExists

함정 2 — 다중 값은 AND

 
"StringNotEquals": { "s3:x-amz-acl": ["public-read", "public-read-write"] }

→ “public-read도 아니고 AND public-read-write도 아니면” 매치

(긍정 연산자 StringEquals가 OR인 것과 반대)

3) IfExists의 유일한 규칙

“키가 없으면 조건을 통과(true 취급)시킨다”

| | 키 없을 때 |

|---|---|

| Bool + false | 매치 안 됨 |

| BoolIfExists + false | 매치됨 (Deny 발동) |

| StringEquals | 매치 안 됨 |

| StringNotEquals | 매치됨 (Deny 발동) |

| StringNotEqualsIfExists | 매치 안 됨 |

방향이 반대로 보이는 이유 — IfExists가 방향을 바꾸는 게 아니라 원래 연산자의 부재 시 동작이 서로 반대이기 때문

4) ARN 구조와 계정 ID


arn:aws:iam::111122223333:role/ExampleRole

 │   │   │  ││      │      │  │      │

 │   │   │  ││      │      │  └──────┴─ 리소스 타입/이름

 │   │   │  ││      │      └─────────── 계정 ID (12자리 숫자)

 │   │   │  │└──────┴────────────────── 리전 (IAM은 글로벌 → 비움, :: 연속)

 │   │   └──────────────────────────── 서비스

 │   └──────────────────────────────── 파티션 (aws / aws-cn / aws-us-gov)

 └──────────────────────────────────── 고정 접두사

111122223333은 AWS 계정 번호(12자리), IAM 이름이 아님. AWS 공식 문서의 예제용 더미 번호
::가 연달아 나오면 리전 자리가 비었다는 신호 (IAM은 글로벌). S3도 arn:aws:s3:::my-bucket처럼 콜론 3개
교차 계정 판별 — 키 ARN의 계정과 Principal ARN의 계정이 다르면 키 정책 + 상대 계정 IAM 정책 양쪽 다 허용해야 통과

5) 페더레이션 — 넓은 의미 vs 좁은 의미


넓은 의미: "AWS 밖에서 인증받고 임시 자격증명으로 들어온다" → 아래 전부

좁은 의미: sts:GetFederationToken으로 발급받은 세션 → federated-user ARN

Identity Center + SAML + SCIM 경로는 넓은 의미로는 페더레이션이지만 ARN은 assumed-role

GetFederationToken 시나리오 (= federated-user)


1. Bob이 사내 웹앱에 사번/비번으로 로그인

2. 웹앱(IAM 사용자 권한 보유)이 Bob을 확인

3. 웹앱이 sts:GetFederationToken 호출 (Name="Bob")

4. STS가 임시 자격증명 반환

5. Bob이 그걸로 S3 접근  → ARN: sts::acct:federated-user/Bob

Name 파라미터가 그대로 ARN에 박힘 → 사람 이름이 직접 들어감

(반면 assumed-role은 역할 이름 + 세션 이름 2단 구조)

SCIM은 ARN 형식과 무관 — SCIM은 Identity Center 내부 디렉터리에 명단을 채우는 것이고, ARN은 STS가 어떤 API로 세션을 발급했는지에 따라 결정됨

6) 외부 IdP를 쓰는 이유 (실무 근거)

| 이유 | 설명 |

|---|---|

| 퇴사자 유령 계정 제거 | IAM 사용자는 AD 비활성화해도 살아있음. IdP 연동 시 AD 정지 = AWS 접근 차단 |

| 장기 자격 증명 제거 | IAM 액세스 키는 무기한. 페더레이션은 STS 임시 자격 증명 |

| MFA·조건부 접근 일원화 | IdP에서 MFA 강제하면 AWS 정책 별도 작성 불필요 |

| 감사 대응 | ISMS-P 계정 관리 항목: “인사시스템 연동, 퇴사 시 즉시 권한 회수” 증적 |

부록. 전체 암기 총정리

시험 직전 이것만

아래는 문제 유형별 반사적으로 떠올려야 하는 판별 기준

A. IAM 정책 문법

A-1. 조건 연산자 3단계 치환법

Not 계열 발견 → “~가 아니면” 으로 읽기
Effect와 합치기 → Deny + “~가 아니면” = “~만 허용”
키가 없는 케이스 대입 → IfExists 유무 확인

A-2. 키 부재 시 동작 ⚠️ 최빈출


BoolIfExists + false   → 키 없으면 매치 → Deny 발동

StringNotEquals        → 키 없으면 매치 → Deny 발동

StringNotEqualsIfExists→ 키 없으면 매치 안 됨

StringEquals           → 키 없으면 매치 안 됨

A-3. 다중 값 논리

StringEquals: [A, B] → OR
StringNotEquals: [A, B] → AND

A-4. 평가 순서


Explicit Deny  >  Allow  >  Implicit Deny(기본 거부)

→ 확실히 막으려면 Allow를 안 주는 게 아니라 Deny 명시

A-5. 리소스 기반 정책의 `Resource: "*"`

“부착된 그 리소스 하나” (IAM 정책의 *와 다름)

A-6. NotAction

“제외한 나머지 전부”. Action과 공존 불가

B. 주체 ARN 형식 ⚠️ 최빈출

| 경로 | ARN |

|---|---|

| IAM 사용자 | iam::acct:user/Bob |

| GetFederationToken | sts::acct:**federated-user**/Bob |

| AssumeRole 계열 전부 | sts::acct:**assumed-role**/Role/Session |

지문에 SAML·Identity Center → assumed-role

지문에 페더레이션 사용자만 + 선지에 federated-user → GetFederationToken

C. 서비스 역할 구분 ⚠️ 최빈출

C-1. 로그·모니터링 4대장

| 질문 | 서비스 |

|---|---|

| 누가 무엇을 했나 | CloudTrail |

| 지금 어떤 상태 / 규정 준수 | Config |

| 수치가 임계값을 넘었나 | CloudWatch |

| IP·포트·전송량 | VPC Flow Logs |

C-2. 보안 서비스 계층

| 서비스 | 시점 | 역할 |

|---|---|---|

| Inspector | 배포 전 | 취약점(CVE) 스캔 |

| GuardDuty | 런타임 | 위협 탐지 |

| Security Hub | 상시 | findings 집계, 규정 준수 |

| Detective | 사후 | 근본 원인 조사 |

| Macie | 상시 | S3 민감 데이터 탐지 |

자주 틀리는 지점

Security Hub는 스스로 탐지 안 함

Detective는 탐지가 아니라 조사

Athena는 감사 데이터를 생성 안 함 (CloudTrail 이후 분석 도구)

GuardDuty는 탐지지 감사가 아님

C-3. 탐지 방식 판별

| 지문 표현 | 방식 |

|---|---|

| “1시간에 50회 이상” (숫자) | CloudWatch 메트릭 필터 |

| “비정상적으로”, “평소와 다른” | CloudTrail Insights / GuardDuty |

| “자동으로 격리/차단/대응” | EventBridge + Lambda 필수 |

| “여러 탐지 서비스 상호 연관” | Security Hub 집계 / Detective 추적 |

C-4. GuardDuty 보호 기능

| 기능 | 데이터 소스 |

|---|---|

| EKS Protection | EKS 감사 로그 |

| Runtime Monitoring | eBPF → OS/프로세스/파일/네트워크 |

| Malware Protection | EBS 볼륨 스캔 |

| S3 / RDS Protection | 데이터 이벤트 / 로그인 활동 |

D. KMS

D-1. 키 삭제 3종

| 작업 | 결과 | 되돌리기 |

|---|---|---|

| DisableKey | 사용 중지, 키 존재 | 즉시 |

| ScheduleKeyDeletion | 7~30일 후 삭제 (기본 30일) | 대기 중 CancelKeyDeletion |

| 대기 만료 | 영구 삭제 | 불가 |

PendingDeletion 상태면 재제출 불가
비활성화 ≠ 삭제

D-2. 키 저장소 4종

KMS 기본 / Custom Key Store(CloudHSM) / Custom Key Store(External) / BYOK(Import)

D-3. `kms:ViaService`

“지정 서비스 경유만 허용” = 직접 호출 차단. 권한을 깎는 장치

D-4. 봉투 암호화

GenerateDataKey → [평문 키 + 암호화된 키] → 로컬 암호화 후 평문 키 폐기

마스터 키는 HSM 밖으로 안 나감

E. S3 데이터 보호

E-1. 영구 삭제 방지 계층


버전 관리          → 실수 복구용

MFA Delete         → 버전 삭제에 MFA

Object Lock 거버넌스 → 특정 권한자 우회 가능

Object Lock 규정준수 → 누구도 불가 (루트·AWS 포함)

E-2. 신호어 매핑

| 지문 | 정답 |

|---|---|

| “실수로 삭제 복구” | 버전 관리 |

| “권한자는 예외 삭제 가능” | Governance |

| “관리자도 삭제 불가” | Compliance |

| “규정 준수, WORM” | Compliance |

E-3. 복제 조합

Replication이 Object Lock 설정까지 복제
전제: 양쪽 버전 관리 + Object Lock 활성화
s3:ReplicateDelete는 삭제 마커 전파만 통제

E-4. Resource ARN

BUCKET = 버킷 레벨 / BUCKET/* = 객체 레벨 (실무는 둘 다)

F. 접근 통제 / 운영

F-1. Session Manager

“SSH 키 없이 / 포트 개방 없이 / 배스천 없이” → 반사적으로

인바운드 0개 (에이전트가 아웃바운드 443으로 먼저 연결)
IAM 인증, 온프레미스 지원(하이브리드 활성화)
감사: CloudTrail + S3/CloudWatch Logs(명령어 전문)
프라이빗 + NAT 없이 → 엔드포인트 3종 ssm/ssmmessages/ec2messages

F-2. 배스천 호스트 선지는 대부분 오답

(상시 비용 + 인바운드 개방 + SSH 키 2회 → 레거시)

F-3. 온프레미스 등장 시

Systems Manager 계열 의심 (Patch Manager, Run Command, Session Manager, Inventory)

F-4. 루트 자격 증명

“루트로 로그인” 선지는 거의 항상 오답

예외: 계정 해지, 결제 정보 변경, 루트 액세스 키 삭제, S3 MFA Delete 설정, 잘못된 키 정책 복구

G. IoT Core

G-1. 정책 변수 신뢰도


검증됨:  iot:Connection.Thing.ThingName

         iot:Connection.Thing.Attributes[속성]

         iot:Certificate.Subject.CommonName

비검증:  iot:ClientId  ← 클라이언트가 보낸 값

G-2. Thing 정책 변수 전제 3가지

① 레지스트리 등록 ② 인증서 attach ③ 클라이언트 ID = 사물 이름

H. 범용 판별 원칙 ⭐

어떤 문제든 먼저 적용

클라이언트 측 검증 선지는 항상 오답 (앱/SDK/디바이스 = 공격자 통제 영역)

지문이 이미 허용한 권한을 또 주는 선지는 오답 (불필요한 조작 distractor)

선지가 2축으로 갈리면 축별로 O/X 채점 (문장 통독 금지)

요구사항 개수만큼 선지에 기능이 있는지 확인 (2갈래면 둘 다 명시한 선지)

“여러 리전” 언급 시 리전 확인 선지가 정답 후보

“가장 운영 효율적” = 관리형 서비스 (직접 구현·Lambda 조합은 후순위)

모드·기간 단어 하나만 바꾼 함정 주의 (거버넌스↔규정준수, 7일↔30일, Allow↔Deny, Action↔NotAction)

“차단하라” = Explicit Deny (Allow 미부여로는 부족)

wyzz.log

Explorer

AWS-DAY1

AWS SCS-C03 학습노트

목차

Q1. MFA 강제 정책 후 CLI 사용 불가

문제

정답: B

핵심 포인트

오답 정리

Q2. 리전 제한 SCP

문제

정책 해석

핵심 포인트

Q3. IAM Identity Center 외부 IdP 연동 순서

문제

정답

핵심 포인트

오답 정리

Q4. KMS 키 정책과 kms ViaService

문제

정답: C

핵심 포인트

오답 정리

Q5. 페더레이션 사용자 S3 버킷 접근 차단

문제

정답: B

핵심 포인트

오답 정리

Q6. 보안 모니터링 전략 매칭

문제

정답 매칭

핵심 포인트

Q7. S3 영구 삭제 방지 + 재해 복구

문제

정답: B

핵심 포인트

오답 정리

Q8. 침해 사고 대응 KMS 키 삭제

문제

정답: B

핵심 포인트

오답 정리

Q9. EC2 + 온프레미스 SSH 대체

문제

정답: B

핵심 포인트

오답 정리

Q10. EKS 위협 탐지

문제

정답: C

핵심 포인트

오답 정리

Q11. IoT Core 클라이언트 ID 위장 방어

문제

정답: A, E

핵심 포인트

오답 정리

Q12. 구성 변경 추적 + 규정 준수

문제

정답: B

핵심 포인트

오답 정리

Q13. CloudHSM 사용자 지정 키 저장소

문제

정답: D

핵심 포인트

오답 정리

개념 보충. 질문하며 정리한 것들

1) NotAction의 진짜 의미

2) StringNotEquals 해석법

3) IfExists의 유일한 규칙

4) ARN 구조와 계정 ID

5) 페더레이션 — 넓은 의미 vs 좁은 의미

6) 외부 IdP를 쓰는 이유 (실무 근거)

부록. 전체 암기 총정리

A. IAM 정책 문법

A-1. 조건 연산자 3단계 치환법

A-2. 키 부재 시 동작 ⚠️ 최빈출

A-3. 다중 값 논리

A-5. 리소스 기반 정책의 `Resource: "*"`

D-3. `kms:ViaService`