SOA-C03 11/16 — 신원·다중 계정·지속적 준수
정보보안기사 응시 후 학습을 위해 미리 작성한 본문이다. 작성·보존은 대화 전달이나 학습 완료를 뜻하지 않는다.
1. 접근 실패를 요청의 좌표로 표현한다
권한 문제의 출발점은 “정책이 있나”보다 어떤 identity가 어떤 session으로 어떤 resource에 어떤 action을 어떤 조건에서 시도했나다.
인증된 principal·session
+ action·resource
+ account·Region·network·MFA·tag 등 context
→ 적용 정책 평가
→ allow 또는 deny
→ 실제 API 결과·CloudTrail 확인로그인 성공은 인증 사실이다. 로그인 후 S3 객체를 읽거나 role을 넘겨 자동화를 실행할 수 있는지는 별도 권한 평가다.
2. Password·MFA·role·federation의 역할
| 구성 | 목적 | 경계 |
|---|---|---|
| IAM password policy | IAM user password의 길이·복잡도 등 관리 | root·외부 IdP password 정책을 대신하지 않음 |
| MFA | 인증에 추가 증거 요구 | 모든 API 권한을 자동 허용하지 않음 |
| IAM role | trust를 만족한 주체가 임시 자격 증명으로 역할 사용 | 누가 맡는가와 무엇을 하는가를 분리 |
| Federation | 외부 identity를 AWS session으로 연결 | 외부 로그인·AWS 역할 권한 각각 확인 |
| IAM Identity Center | workforce의 account·application 접근 관리 | 사용자·group·할당과 account 권한 연결 |
Password policy, MFA, IAM roles
Identity Center는 기존 IdP 또는 관리하는 사용자·group을 연결하고 account access·permission set 등을 통해 접근을 제공한다. 사용자가 portal에 보인다는 사실과 특정 account에서 필요한 role·권한이 provision됐다는 사실을 대조한다. Identity Center
3. Policy는 역할이 서로 다르다
| 정책 | 판단 질문 |
|---|---|
| Identity policy | 이 user·role에 어떤 작업을 허용했는가 |
| Resource policy | 이 resource가 어떤 principal의 접근을 허용하는가 |
| Trust policy | 누가 이 role을 맡을 수 있는가 |
| Permissions boundary | identity policy가 부여할 수 있는 권한의 상한은 무엇인가 |
| Session policy | 이번 session의 권한을 더 제한했는가 |
| SCP | member account principal이 사용할 수 있는 조직 차원의 상한은 무엇인가 |
기본 거부에서 출발하고 적용되는 명시적 Deny는 Allow보다 우선한다. 같은 account의 identity·resource policy, role session 직접 지정, cross-account 요청은 평가 경로가 다르므로 “모든 정책을 무조건 AND”로 외우지 않는다. Principal 형식과 실제 적용 정책을 보고 공식 평가 로직에 대조한다. IAM 평가 로직
Condition은 정책 문장에 붙은 실제 요청 조건이다. ARN·prefix·source endpoint·tag·MFA context가 예상과 다르면 action 이름이 허용 목록에 있어도 적용되지 않을 수 있다. S3 bucket ARN과 object ARN처럼 action별 resource 형식도 맞아야 한다.
4. Organizations·OU·SCP로 account 경계를 관리한다
Organizations는 account를 묶고 OU에 정책을 적용하는 구조다. SCP는 권한을 직접 부여하지 않고 member account의 user·role이 사용할 수 있는 범위를 제한한다. Member account의 AdministratorAccess도 적용 SCP를 넘지 못한다.
SCP는 management account의 user·role이나 service-linked role에 동일하게 적용되지 않는다. Member account의 root에는 적용될 수 있다. Account가 다른 OU로 이동하면 상위 정책 경로가 달라지므로 전후 허용 범위를 확인한다. SCP
Region 제한 정책은 글로벌 서비스와 서비스별 호출 경로를 고려해야 한다. 일부 API를 막는 것과 데이터가 특정 Region 밖으로 절대 이동하지 않게 하는 것은 동일한 보장이 아니다. 운영 요구를 실제 서비스·data flow·정책 조건에 연결한다.
Organizations의 declarative policy는 서비스의 원하는 기본 구성을 조직 범위에서 유지하는 도구다. API 호출 권한의 상한인 SCP와 역할이 다르다. 예를 들어 VPC Block Public Access 구성을 OU에 일관되게 적용하는 요구를 검토할 수 있다. SCP로 변경 API를 제한해도 이미 존재하는 network 구성이 자동 수정되는 것은 아니다. 반대로 SCP가 기존 account에는 적용되지 않는다고 해석해서도 안 된다. 현재·미래 account의 정책 상속과 실제 서비스 설정을 함께 확인한다. Declarative policies
5. CloudTrail·Access Analyzer·Simulator가 보여 주는 증거
| 도구 | 주는 근거 | 한계 |
|---|---|---|
| CloudTrail | 실제 API identity·시각·action·error·요청 맥락 | 기록 설정·event 범위 밖은 보이지 않음 |
| Access Analyzer policy validation | 문법·권한 관련 경고·개선 항목 | 실환경 API 성공을 직접 시험하지 않음 |
| Access Analyzer access findings | 분석 범위 안의 외부·내부·미사용 접근 등 | finding은 해당 분석 종류와 범위로 해석 |
| IAM policy simulator | 입력한 action·resource·context의 정책 평가 | 미지원 정책·cross-account 등 제한 확인 |
| Trusted Advisor | 제공되는 보안 check의 점검 결과 | 모든 위협·구성을 전수 검증한 것이 아님 |
Policy validation, Access Analyzer, Policy simulator, Trusted Advisor
권한 오류를 해결할 때는 실제 실패 요청에서 시작한다. 시뮬레이터에서 allowed여도 실제 session·resource policy·endpoint·KMS context가 달랐다면 실행은 실패할 수 있다. 변경 후에는 허용해야 할 최소 작업과 계속 거부해야 할 작업을 각각 확인한다.
Trusted Advisor finding은 해당 resource와 check 조건을 읽고 원인을 수정한 뒤 재검사한다. Check 가용성과 상세 결과는 현재 지원 범위에 따르며, 경고 숨김을 remediation으로 기록하지 않는다.
6. Config conformance pack은 지속 평가의 묶음이다
Conformance pack은 Config rule과 remediation action을 함께 배포·관리하는 단위다. 조직과 여러 account에 같은 평가 묶음을 배치할 수 있다. Conformance packs
운영에서는 다음 층을 구분한다.
- Recorder가 해당 resource type·Region을 기록하는가.
- Rule이 평가할 설정과 필요한 parameter가 맞는가.
- 결과의 timestamp와 resource scope가 현재 요구에 맞는가.
- Remediation이 실행되었다면 권한·입력·결과는 무엇인가.
- 재평가와 실제 설정이 원하는 상태를 확인하는가.
Noncompliant는 정의한 rule을 만족하지 않았다는 뜻이다. 이 결과만으로 침해가 발생했다고 단정하지 않는다. Compliant 역시 평가한 조건 안의 상태이며 모든 보안 요구의 충족을 대신하지 않는다.
7. 완성된 운영 적용 — 다른 account의 bucket 접근 실패
가정: role은 맡았지만 특정 object 읽기가 거부된다.
- 실제 caller identity와 assumed-role session을 확인한다.
- 대상 bucket·key·version·account를 확인한다.
- Role의 S3 action·object ARN과 bucket policy의 principal·condition을 대조한다.
- 적용 SCP·boundary·session policy의 제한을 확인한다.
- Endpoint policy·KMS 암호화가 있으면 그 접근 경계를 확인한다.
- CloudTrail의 실패 action과 오류를 기준으로 필요한 최소 변경을 정한다.
- 동일 session 조건에서 필요한 읽기를 검증하고 불필요한 쓰기·다른 prefix 접근은 계속 거부되는지 확인한다.
이 사례는 진단 순서를 설명하며 실제 사용자 account를 조사·변경한 결과가 아니다.
8. 연결 요약
인증 → role session → 권한 평가 → 실제 API 결과 → 지속 평가를 연결한다. 시험에서는 IAM 기능·감사 도구·조직 정책·Config를 요구와 연결하고, 실제 운영에서는 요청 맥락과 분석 도구의 범위를 함께 검증한다. 범위: Domain 4 Task 4.1.
계획과 연결
-
ID:
11-identity-multi-account-and-continuous-compliance -
의존:
01-operational-signals-and-evidence -
결정 축: 신원·권한·권한 상한·조직 경계·구성 준수를 서로 다른 제어면에 배치하고 접근 실패의 평가 경로를 추적한다.
-
범위: IAM password policy·MFA·roles·federation·resource policies·conditions, CloudTrail, IAM Access Analyzer, policy simulator, Organizations, SCPs, IAM Identity Center, Trusted Advisor, AWS Config conformance packs.
-
시험 매핑: Domain 4, Task 4.1.