[Sigma Rule] 제21화: GCP Cloud Audit Log Sigma 룰

이번 글에서는 GCP Cloud Audit Log를 기반으로 Sigma 룰을 작성하는 방법을 실전 관점에서 정리해드리겠습니다. 

Sigma는 벤더 중립적인 탐지 규칙 포맷이라서, GCP 감사 로그처럼 구조화된 클라우드 로그와 궁합이 좋습니다. 

Panther와 SigmaHQ 문서에서도 Sigma는 YAML 기반으로 탐지 로직을 기술하고, 백엔드를 통해 SIEM별 쿼리로 변환되는 표준이라고 설명합니다.

 

◎ 왜 GCP Audit Log인가

• GCP Cloud Audit Logs는 관리자 활동, 데이터 액세스, 시스템 이벤트, 정책 거부를 기록하며, 누가 언제 어디서 무엇을 했는지 추적하는 데 핵심이 됩니다. 
• 특히 공격자는 IAM 정책을 바꾸거나, 서비스 계정을 악용하거나, 방화벽과 로깅 설정을 바꾸는 식으로 움직이기 때문에, 감사 로그가 있으면 초반 행위를 빠르게 잡아낼 수 있습니다.
• SigmaHQ의 logsource 문서도 이런 식으로 product와 service를 조합해 특정 로그 소스를 좁히는 방식을 권장합니다.

 

◎ 먼저 봐야 할 이벤트

 - GCP에서는 처음부터 모든 로그를 다 보려 하기보다, 관리 평면 이벤트부터 잡는 편이 좋습니다. 

 - 실무에서 우선순위가 높은 항목은 다음과 같습니다.

• IAM 정책 변경입니다.
• 서비스 계정 키 생성입니다.
• 방화벽 규칙 수정/삭제입니다.
• Cloud Logging 비활성화 또는 변경입니다.
• 데이터 액세스 권한 변화입니다.

 - Panther의 Sigma 예시도 GCP 방화벽 생성·삭제·수정 이벤트를 탐지하는 규칙을 보여주며, gcp.audit.method_name 기반으로 매칭하는 구조를 사용합니다.

 

◎ 기본 규칙 구조

• GCP Audit Log용 Sigma는 보통 아래 형태로 시작하면 됩니다.

title: Google Cloud Firewall Modified or Deleted id: fe513c69-734c-4d4a-8548-ac5f609be82b status: test description: Detects when a firewall rule is modified or deleted in GCP. logsource:   product: gcp   service: gcp.audit detection:   selection:     gcp.audit.method_name:       - v*.Compute.Firewalls.Delete       - v*.Compute.Firewalls.Patch       - v*.Compute.Firewalls.Update       - v*.Compute.Firewalls.Insert   condition: selection level: medium

• 이 규칙은 방화벽 변경 행위 자체를 잡는 가장 기본적인 패턴입니다.
• 실제 운영에서는 이 규칙에 프로젝트 ID, 사용자 이메일, 호출 IP를 함께 넣어야 오탐 줄이기가 훨씬 쉬워집니다.

 

◎ 실전 탐지 포인트

• 가장 먼저 추천드리는 탐지 포인트는 IAM 정책 변경입니다. 
• GCP에서는 서비스 계정 가장이 공격의 핵심이기 때문에, SetIamPolicy 계열 이벤트와 serviceAccountTokenCreator, serviceAccountUser 같은 역할 추가를 같이 보는 것이 좋습니다.
• A13e의 GCP Audit Log 룰 라이브러리도 이런 식으로 서비스 계정 권한 상승을 별도 탐지 항목으로 다루고 있습니다.
• 예를 들면 다음과 같이 작성할 수 있습니다.

title: GCP Service Account Token Creator Privilege Granted id: gcp-sa-tokencreator-granted status: experimental logsource:   product: gcp   service: gcp.audit detection:   selection:     protoPayload.serviceName: iahttp://m.googleapis.com     protoPayload.methodName:       - google.iam.admin.v1.SetIAMPolicy       - SetIamPolicy   selection_role:     protoPayload.serviceData.policyDelta.bindingDeltas.role|contains:       - roles/iam.serviceAccountTokenCreator       - roles/iam.serviceAccountUser     protoPayload.serviceData.policyDelta.bindingDeltas.action: ADD   condition: selection and selection_role level: high

• 이 규칙은 서비스 계정 가장을 위한 핵심 권한 추가를 탐지하는 데 유용합니다.

 

 

◎ 서비스 계정과 방화벽

• GCP에서는 서비스 계정 키 생성이 매우 중요합니다. 
• 공격자가 키를 만들면 장기적으로 재사용 가능한 자격 증명을 확보하게 되므로, CreateServiceAccountKey 계열 이벤트는 반드시 보셔야 합니다.
• 방화벽 쪽에서는 Compute.Firewalls.Delete, Patch, Update 같은 메서드를 기준으로 보면 되고, 필요하면 포트·대상 범위까지 좁혀서 외부 노출 행위를 잡을 수 있습니다.

title: GCP Firewall Rule Modified logsource:   product: gcp   service: gcp.audit detection:   selection:     gcp.audit.method_name:       - v*.Compute.Firewalls.Delete       - v*.Compute.Firewalls.Patch       - v*.Compute.Firewalls.Update   condition: selection level: medium

 

◎ 로그 비활성화와 은폐

• 공격자는 흔히 감사 로그 자체를 약화시키려고 합니다. 
• GCP에서는 감사 로그를 직접 끄는 것이 어렵더라도, 로그 라우팅, 싱크, 권한, 보관 정책을 바꾸는 방식으로 탐지를 회피할 수 있습니다.
• 그래서 Disable, Delete, Update 계열의 관리 작업과 함께, 로깅 설정 변경 이벤트를 따로 묶어 보는 것이 중요합니다.
• 이 부분은 AWS CloudTrail의 StopLogging과 같은 사고 모델로 이해하시면 편합니다.

 

◎ 오탐 줄이는 방법

• GCP Audit Log는 자동화 시스템이 많이 호출하기 때문에, 오탐 튜닝이 정말 중요합니다.
• Terraform, Deployment Manager, CI/CD principal을 화이트리스트로 두십시오.
• 프로젝트별로 예상되는 서비스 계정 메일을 필터링하십시오.
• 정기 배포 시간대와 관리 작업 시간을 구분하십시오.
• A13e 라이브러리도 실전 배포 전에 automation principal과 IP allowlist를 튜닝하라고 안내합니다.
• 이 부분을 빼면 초기 운영에서 알람 피로도가 매우 높아집니다.

 

◎ 운영 순서

 - 실무에서는 아래 순서로 가시면 가장 안정적입니다.

• Audit Logs 수집 활성화부터 확인합니다.
• IAM 정책 변경, 서비스 계정 키 생성, 방화벽 수정 세 가지를 먼저 탐지합니다.
• Sigma로 작성한 뒤 SIEM dialect로 변환합니다.
• CI/CD에서 테스트용 GCP 로그로 검증합니다.
• 오탐 필터를 추가하고 운영에 투입합니다.

 

◎ 마무리

• GCP Cloud Audit Log는 단순한 감사 기록이 아니라, 공격자가 클라우드에서 무엇을 바꾸고 어떻게 은폐하는지 보여주는 핵심 증거입니다. 
• Sigma로 이 로그를 표준화하면, GCP 전용 탐지를 만들면서도 다른 클라우드와 같은 문법으로 운영할 수 있습니다.
• 특히 IAM 정책 변경, 서비스 계정 권한 상승, 방화벽 수정, 로깅 무력화는 반드시 우선순위로 잡는 것이 좋습니다.