[Multi-cloud] 멀티클라우드 보안 로그와 IAM 위임 구조 이해하기 - AWS, Azure, GCP를 아우르는 SIEM 설계

1. 왜 멀티클라우드 보안 로그를 이해해야 하는가

멀티클라우드 SIEM 환경을 설계할 때 가장 먼저 부딪히는 문제는 로그는 비스해 보이지만, 실제로는 전혀 다르다는 점이다.

 

AWS, Azure, GCP 모두 관리 행위에 대한 감사 로그를 제공하지만, 로그가 기록되는 단위, IAM 권한이 위임되는 방식, 권한 변경과 사용이 표현되는 구조가 서로 다르다.

 

이 차이를 이해하지 못한 채 로그를 단순 통합하면 탐지는 부정확해지고, 운영 비용만 증가한다.

---

2. 멀티클라우드 보안 로그의 공통점과 한계

공통점

• 모두 관리 행위(Administrative Action)을 기록
• 누가(Who), 언제(When), 무엇을(What) 했는지 남김
• IAM, 리소스 설정 변경, 정책 수정이 핵심 대상

세 CSP 모두 보안 이벤트 로그를 "누가, 어떤 권한으로, 어떤 행위를 했는가"를 정의한다.
문제는 이걸 '어디에서', '어떤 단위로', '어떤 시점에' 기록하느냐가 다른 것이다.

 

한계

• "행위"를 표현하는 방식이 서로 다름
• IAM 모델 차이로 동일한 탐지를 그대로 적용할 수 없음

---

3. AWS CloudTrail - "누가 어떤 API를 호출했는가"

3-1. AWS에서 보안 이벤트가 발생하는 실제 흐름

예시 상황 : 

IAM 사용자가 관리자 권한을 얻어
S3 버킷을 퍼블릭으로 변경했다.

 

실제 내부 흐름

1. 사용자가 AssumeRole을 호출
2. AWS STS가 임시 자격 증명 발급
3. 해당 Role 권한으로 아래 API 호출 발생
   • PutBucketAcl
   • PutBucketPolicy

---

3-2. CloudTrail 기록 형식

CloudTrail은 행위의 결과가 아니라 행위 자체(API 호출)를 기록한다.

# STS AssumeRole (권한 위임)
eventSource: sts.amazonaws.com
eventName: AssumeRole
userIdentity:
  type: IAMUser
  userName: attacker

# S3 PutBucket (실제 위험 행위)
eventSource: s3.amazonaws.com
eventName: PutBucketPolicy
userIdentity:
  type: AssumedRole
  sessionContext:
    sessionIssuer: AdminRole

eventName, eventSource, userIdentity가 핵심

---

3-3. AWS 로그의 핵심 특징

• 이벤트는 단일 API 호출 ("어떤 API가 호출됐는가")
• 권한 위임(AssumeRole)과 행위가 분리된 이벤트로 기록됨

 

IAM 위임 구조 (AssumeRole)

• 사용자 → Role → 정책(Policy)
• AssumeRole 시점과 이후 API 호출이 분리되어 기록됨

---

3-4. 탐지 관점

AWS에서는 보안 탐지를 아래와 같이 수행한다.

• 위험한 API 목록
• 특정 Role 사용 패턴
• AssuemRole 이후 짧은 시간 내 고위험 API 연쇄 호출

그래서 AWS는 행위 기반 탐지에 적합하다.

---

4. Azure Activity Log - "리소스 상태가 어떻게 바뀌었는가"

4-1. Azure에서 보안 이벤트가 발생하는 실제 흐름

예시 상황 : 

사용자가 관리자 권한을 얻어
Storage Account 접근 정책을 변경했다.

 

실제 내부 흐름

1. 사용자가 로그인
2. 특정 리소스 범위(Subscription / Resource Group)에 Role Assignment가 적용됨
3. 이후 리소스 설정이 변경됨

Azure는 "API 호출"보다 "리소스 상태 변화"를 더 중요하게 본다.

---

4-2. Activity Log 기록 형식

# 권한 부여 이벤트
operationName: Microsoft.Authorization/roleAssignments/write
caller: user@company.com
resourceId: /subscriptions/xxx/resourceGroups/rg1

# 리소스 설정 변경 이벤트
operationName: Microsoft.Storage/storageAccounts/write
resourceId: /subscriptions/.../storageAccounts/myStorage

operationName, caller, resourceId 중심

---

4-3. Azure 로그의 핵심 특징

• 이벤트 = 리소스에 대한 상태 변경
• "어떤 API가 호출됐는지"는 직접적으로 중요하지 않음
• 하나의 사용자 행동이 여러 로그로 분산될 수 있음

 

IAM 위임 구조 (RBAC)

• 사용자 / 서비스 주체(Principal)
• 권한은 "주체 + 역할 + 리소스 범위"의 조합

---

4-4. 탐지 관점

Azure에서는 보안 탐지를 아래와 같이 수행한다.

• 어떤 리소스에 어떤 역할이 부여/변경되었는가 ("이 리소스의 권한이나 상태가 왜 바뀌었는가")
• 그 이후 어떤 설정 변경이 발생했는가

그래서 Azure는 상태 변화 기반 탐지가 핵심이다.

---

5. GCP Audit Log - "이 요청이 왜 허용/거부되었는가"

5-1. GCP에서 보안 이벤트가 발생하는 실제 흐름

예시 상황 : 

사용자가 프로젝트의 IAM 정책을 수정해
자신에게 관리자 권한을 부여했다.

 

실제 내부 흐름

1. 요청 발생
2. IAM Policy 평가
3. 허용 / 거부 결정
4. 그 결과를 로그로 남김

GCP는 "판단 결과" 자체가 로그의 핵심이다.

---

5-2. Audit Log 기록 형식

Audit Log는 이 권한이 왜 허용되었는지가 명확하다.

authenticationInfo:
  principalEmail: user@company.com

authorizationInfo:
  permission: resourcemanager.projects.setIamPolicy
  granted: true

authenticationInfo, authorizationInfo 구조

---

5-3. GCP 로그의 핵심 특징

• 이벤트 = 요청 + 정책 평가 결과 ("이 요청이 왜 허용되었는가")
• "누가 무엇을 시도했고, 왜 허용됐는지(정책 평가)"가 한 이벤트에 포함됨
• 하나의 사용자 행동이 여러 로그로 분산될 수 있음

 

IAM 위임 구조 (Policy Binding)

• 리소스에 정책을 바인딩하는 구조
• "누가 어떤 역할을 갖는다"를 정책 집합으로 선언함
• 요청 시 정책 평가 결과가 로그에 포함됨

---

5-4. 탐지 관점

GCP에서는 아래 이벤트를 정책 평가 결과 기준으로 탐지한다.

• 정책 변경 / 우회
• 과도한 권한 허용
• 정상적이지 않은 권한(permission) 사용

그래서 GCP는 정책 판단 기반 탐지에 강하다.

---

6. CSP 별 IAM 위임 구조 비교 요약

구분	AWS	Azure	GCP
기록 단위	API 호출	리소스 상태 변화	정책 평가 결과
권한 부착 위치	주체 (사용자/역할)	리소스 범위	리소스 정책
권한 위임	AssumeRole	Role Assignment (RBAC)	Policy Binding
로그 분리	위임 / 행위 분리	행위가 다단계	판단 결과 포함
탐지 강점	행위 기반	상태 변화 기반	정책 판단 기반

 

---

7. 멀티클라우드 SIEM 설계 시사점

왜 멀티클라우드 SIEM에서 그대로 합치면 안 되는가

만약 이렇게 생각한다면 실패한다.

"CloudTrail 룰을 Azure에도 적용하자"
"API 이름만 바꾸면 되지 않을까?"

 

AWS는 행위(API)를, Azure는 결과(상태 변화)를, GCP는 판단(정책 평가)를 기록하기 때문이다.

---

그래서 SIEM에서는 어떻게 해야 하는가

위 차이로 인해 SIEM에서 멀티클라우드의 로그 형식을 그대로 통합하는 방식은 실패하기 쉽다.

따라서 멀티클라우드 SIEM에서는 로그가 아니라 '행위'를 기준으로 설계해야 한다.

 

행위 예 : 

• 정책 변경 (Policy Modification)
• 비정상 권한 사용 (Permission Misuse)
• 권한 추가 / 권한 범위 확장 (Privilege Escalation)
• 허용되지 않은 리소스 노출 (Unauthorized Resource Exposure)

 

이처럼 공통 행위 모델을 먼저 정의하고, 각 CSP 로그를 해당 행위로 매핑하는 방식이 현실적이다.

• AWS → API 연쇄
• Azure → Role + Resource 변경
• GCP → Policy Binding + Permission 허용

---

마무리

멀티클라우드 보안 로그의 차이는 단순한 형식 문제가 아니다.

"어디에서 보안을 판단하느냐"라는 CSP 철학의 차이다.

 

이걸 이해하면 멀티클라우드 SIEM 설계는 기술 문제가 아니라 모델링 문제가 된다.

 

멀티클라우드 보안의 핵심은 모든 클라우드를 동일하게 보는 것이 아니라,

다르다는 사실을 인정하고 그 위에 공통된 보안 언어를 만드는 것이다.

 

이것이 멀티클라우드 SIEM 설계의 출발점이다.

---

8. 다음 단계 : 멀티클라우드를 아우르는 SIEM으로

이 글은 멀티클라우드 SIEM 프로젝트의 출발점이다.

 

다음 단계에서는 아래와 같은 확장을 고려한다.

• 공통 IAM 행위 모델 정의
• CSP 별 로그 필드 매핑 전략
• 공통 탐지 룰 설계 방식
• SIEM / SOAR에서의 단계적 자동화 기준

---

참고 출처

 - https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html

 - https://learn.microsoft.com/en-us/azure/azure-monitor/platform/activity-log?tabs=log-analytics

 - https://docs.cloud.google.com/logging/docs/audit

 - https://www.reddit.com/r/cybersecurity/comments/18r8d1q/siem_for_multicloud_aws_and_azure_which_to_use/?tl=ko

 

Powered By. ChatGPT