Skip to content

Cloud Audit Logs Deep Dive

Tại sao Audit Logs là nguồn chi phí bất ngờ nhất

Audit Logs là loại log mà nhiều team nghĩ họ hiểu — nhưng thực ra không hiểu. Sự nhầm lẫn phổ biến nhất: không phải mọi Audit Log đều giống nhau về chi phí và khả năng kiểm soát.

Admin Activity Audit Logs không tốn tiền và không tắt được. Data Access Audit Logs tốn tiền và mặc định tắt — nhưng BigQuery là ngoại lệ: Data Access mặc định bật cho BigQuery. System Event miễn phí và không tắt được. Policy Denied tốn tiền storage nhưng có thể exclude.

Team thường phát hiện chi phí audit log tăng đột biến khi họ: (1) bật Data Access Audit Logs toàn tổ chức để comply với security requirement mà không tính toán volume, hoặc (2) không biết BigQuery Data Access đã bật sẵn và hệ thống analytics đang tạo hàng triệu entries mỗi ngày.


Internal Model: Audit Log trong GCP Control Plane

Audit log không phải một feature tùy chọn bạn có thể bật/tắt toàn bộ. Chúng là một phần của GCP control plane — mọi API call đến GCP đều đi qua audit logging infrastructure.

Cơ chế hoạt động:

Client (user/service account)

       ▼ API call (gọi bất kỳ GCP API)
GCP API Server (IAM verification xảy ra ở đây)

       ├─────────────────────────────────┐
       │                                 │
       ▼                                 ▼
Execute operation           Audit Logging Subsystem
(nếu authorized)            (song song, không blocking)

                            ┌────────────┼────────────┐
                            ▼            ▼            ▼
                    Admin Activity  Data Access   System Event
                    (nếu write op)  (nếu read op  (nếu GCP tự
                                    & DA enabled)  làm action)

Quan trọng: Audit logging xảy ra song song với operation execution — không phải sau đó. Điều này có nghĩa là audit log luôn phản ánh intent, không phải outcome. Nếu một API call bị từ chối bởi IAM, Policy Denied Audit Log vẫn được ghi, dù operation không thực sự xảy ra. Nếu operation thành công, Admin Activity Audit Log được ghi bất kể operation có gây ra lỗi phụ nào không.


Bốn Loại Audit Log

1. Admin Activity Audit Logs

Ghi lại: Mọi API call thay đổi cấu hình hoặc metadata của GCP resources.

Ví dụ:

  • gcloud compute instances create → ghi compute.googleapis.com/instances.insert
  • terraform apply tạo thêm subnet → ghi compute.googleapis.com/subnetworks.insert
  • Thay đổi IAM policy trên project → ghi cloudresourcemanager.googleapis.com/projects.setIamPolicy
  • Scale GKE node pool → ghi container.googleapis.com/nodePools.update

Đặc tính then chốt:

Tính chấtGiá trị
Tắt được khôngKhông — luôn luôn được ghi
Exclude khỏi sink khôngKhông — luôn route vào _Required bucket
Chi phí ingestionMiễn phí
Chi phí storageMiễn phí (trong _Required bucket, 400 ngày)

Admin Activity Logs đặc biệt vì chúng route vào _Required bucket — một bucket bạn không thể modify, không thể thay đổi retention, và không thể delete. Google đảm bảo rằng các admin action luôn có audit trail, độc lập với cấu hình logging của bạn.

Format: Admin Activity Logs dùng protoPayload với @type = "type.googleapis.com/google.cloud.audit.AuditLog". Các fields quan trọng:

json
{
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "serviceName": "compute.googleapis.com",
    "methodName": "v1.compute.instances.insert",
    "authenticationInfo": {
      "principalEmail": "user@company.com"
    },
    "requestMetadata": {
      "callerIp": "203.0.113.1",
      "callerSuppliedUserAgent": "gcloud/438.0.0"
    },
    "resourceName": "projects/my-project/zones/us-central1-a/instances/my-vm",
    "request": { /* request body */ },
    "response": { /* response body */ }
  },
  "logName": "projects/my-project/logs/cloudaudit.googleapis.com%2Factivity"
}

2. Data Access Audit Logs

Ghi lại: Mọi API call đọc configuration/metadata hoặc đọc user data.

Ví dụ:

  • gsutil ls gs://my-bucket → ghi storage buckets.list
  • bq query "SELECT * FROM dataset.table" → ghi BigQuery tables.getData
  • gcloud secrets versions access → ghi Secret Manager versions.access
  • kubectl get pods → ghi GKE API server pods.list

Data Access có ba sub-types:

  • ADMIN_READ: Đọc cấu hình/metadata của resource (ví dụ: xem IAM policy, liệt kê buckets)
  • DATA_READ: Đọc user data (ví dụ: đọc object từ GCS, query BigQuery)
  • DATA_WRITE: Ghi user data (ví dụ: upload object vào GCS)

Đặc tính then chốt:

Tính chấtGiá trị
Mặc địnhTắt cho hầu hết services
Ngoại lệBigQuery DATA_READ và DATA_WRITE bật mặc định
Chi phí ingestion$0.50/GB sau 50 GB free
Chi phí storage$0.01/GB/tháng sau 30 ngày
Bật được theo serviceCó — cấu hình per-service
Exclude khỏi sinkCó — có thể route ra ngoài _Required

Tại sao BigQuery là ngoại lệ: BigQuery được Google mặc định bật Data Access Audit Logs vì đây là service phân tích dữ liệu — các tổ chức thường cần audit trail cho mọi query để comply với regulation. Trong một hệ thống analytics active, mỗi query BigQuery tạo ra ít nhất 2-3 audit log entries. 1,000 queries/ngày = 2,000-3,000 entries = có thể vài GB/ngày tùy query complexity và metadata size.

Bật Data Access Audit Logs có chọn lọc:

bash
# Bật Data Access cho Secret Manager (chỉ DATA_READ)
gcloud projects get-iam-policy my-project > policy.yaml

# Thêm vào policy.yaml:
# auditConfigs:
# - auditLogConfigs:
#   - logType: DATA_READ
#   service: secretmanager.googleapis.com

gcloud projects set-iam-policy my-project policy.yaml

Hoặc qua Terraform:

hcl
resource "google_project_iam_audit_config" "project" {
  project = "my-project"
  service = "secretmanager.googleapis.com"
  audit_log_config {
    log_type = "DATA_READ"
  }
}

Tính toán volume trước khi bật: Trước khi enable Data Access Audit Logs toàn tổ chức, hãy estimate volume:

  1. Bật trong môi trường staging trong 24 giờ
  2. Query metric logging.googleapis.com/billing/bytes_ingested theo log type
  3. Extrapolate lên production workload
  4. Tính toán monthly cost

Điều không nên làm: bật Data Access ở org-level theo yêu cầu của compliance team mà không estimate trước, rồi nhận hóa đơn tăng đột ngột cuối tháng.

3. System Event Audit Logs

Ghi lại: Hành động của Google Cloud infrastructure tự thực hiện mà không có user action trực tiếp.

Ví dụ:

  • GKE Cluster Autoscaler thêm node vào node pool
  • Preemptible/Spot VM bị Google thu hồi
  • Live migration của VM sang host mới
  • GKE Auto-upgrade cluster
  • Cloud SQL automatic failover

Đặc tính then chốt:

Tính chấtGiá trị
Tắt được khôngKhông
Chi phí ingestionMiễn phí
Chi phí storageMiễn phí (trong _Required bucket)

System Event Logs đặc biệt quan trọng cho debugging vì chúng giải thích những thứ xảy ra không phải do user action. Khi bạn thấy traffic spike lạ hoặc connection drop và không tìm thấy deploy nào liên quan trong Admin Activity, System Event Log thường là nơi tìm lời giải thích.

Ví dụ thực tế: Một Spot VM bị preempted tạo System Event Log trước khi VM shutdown, giúp phân biệt giữa "VM bị preempted" và "VM bị terminate do application crash". Không có entry này, team sẽ mất thời gian tìm root cause sai hướng.

4. Policy Denied Audit Logs

Ghi lại: Các request bị từ chối bởi security policy — IAM deny, VPC Service Controls violation, org policy violation.

Ví dụ:

  • User không có permission cố gắng delete bucket → PERMISSION_DENIED
  • Service account cố truy cập resource ngoài VPC Service Controls perimeter
  • Tạo resource vi phạm org policy (ví dụ: tạo VM ở region bị restrict)

Đặc tính then chốt:

Tính chấtGiá trị
Mặc địnhBật — tự động được ghi
Chi phí ingestion$0.50/GB
Chi phí storage$0.01/GB/tháng
Exclude được không — có thể exclude khỏi sink

Policy Denied Logs quan trọng cho security monitoring nhưng cũng có thể noisy trong môi trường có nhiều misconfigured service accounts. Nếu một service account không có permission A nhưng vẫn cố gọi API đó mỗi phút (ví dụ: một agent health check sai config), bạn sẽ có hàng nghìn Policy Denied entries mỗi ngày.

Chiến lược với Policy Denied Logs:

  • Giữ nguyên để security team có visibility → nhưng cần alert để không bị "alert fatigue"
  • Exclude các patterns lành (known misconfigs đã được track và fix) bằng exclusion filter
  • Route vào Security Command Center thay vì chỉ dựa vào Logs Explorer

Audit Log Exemptions — Ai Không Bị Log

Theo Cloud Audit Logs documentation, một số trường hợp không tạo Data Access Audit Log ngay cả khi enabled:

  1. Publicly accessible resources: Nếu bucket GCS được public (allUsers có READ), các access vào bucket đó không tạo Data Access log (để bảo vệ privacy của end users)
  2. Unauthenticated access: Tương tự — không log để không expose identity tracking của anonymous users
  3. Google internal operations: Một số Google system operations không tạo audit log để tránh noise

Cấu Hình và Kiểm Soát

Cấu hình ở cấp độ nào?

Audit Log configuration có thể set ở ba cấp độ, theo IAM inheritance:

Organization (org policy áp dụng cho tất cả)

    ├── Folder A
    │       └── Project 1 (inherit từ folder, có thể override)
    │       └── Project 2
    └── Folder B
            └── Project 3

Khi bạn bật Data Access Audit Logs ở organization level, nó áp dụng cho tất cả projects trong org, trừ khi một project override với cấu hình riêng. Đây là lý do bạn phải cẩn thận khi bật ở org level.

Override behavior

Tham chiếu trực tiếp từ Audit Logs documentation: "If a resource has an audit configuration and an ancestor resource also has an audit configuration, the two configurations are combined. Individual audit log types from ancestor resources are merged with the child resource. Any exemptions at the child resource level take precedence over exemptions at the ancestor level."

Điều này có nghĩa:

  • Nếu org bật DATA_READ cho BigQuery
  • Và project A disable DATA_READ cho BigQuery
  • Thì project A không ghi BigQuery DATA_READ audit logs

Nhưng nếu org enable DATA_READ với exemption cho service-account-1@project.iam.gserviceaccount.com:

  • Tất cả principals trừ service-account-1 đều bị log
  • Project con không thể "unescape" exemption này một cách độc lập

Tại Sao Data Access Audit Logs Là Nguồn Cost Surprise

Hãy xem một ví dụ cụ thể để hiểu magnitude của vấn đề.

Hệ thống BigQuery analytics với 50 data scientists:

  • Mỗi người chạy trung bình 20 queries/ngày
  • 50 × 20 = 1,000 queries/ngày
  • Mỗi query tạo: 1 tables.getData audit log + metadata logs
  • Mỗi audit log entry: ~3-5 KB (protobuf serialized với request/response metadata)
  • 1,000 × 4 KB = 4 MB/ngày = 120 MB/tháng

Nghe có vẻ nhỏ. Nhưng thêm:

  • Scheduled queries (Looker reports, dashboards): +500 queries/ngày
  • Data pipeline reads (Dataflow, dbt): +2,000 operations/ngày
  • BigQuery Data Transfer Service jobs: +200 operations/ngày

Tổng: ~3,700 operations/ngày × 4 KB = ~14.8 MB/ngày = ~444 MB/tháng

Nhân lên với số teams, số projects, và tính thêm ADMIN_READ logs từ BigQuery metadata lookups — con số thực tế của một tổ chức lớn có thể là hàng chục GB/tháng chỉ từ BigQuery Data Access.


Tích Hợp Với Security Command Center

Audit Logs là data source chính cho Security Command Center (SCC). SCC tự động analyze Admin Activity và Policy Denied Audit Logs để detect:

  • Anomalous admin activity (unusual resource access patterns)
  • Privilege escalation attempts
  • Service account key creation spikes
  • Cross-project lateral movement

Nếu tổ chức đã có SCC, đây là lý do thêm để giữ nguyên Audit Logs routing vào _Required bucket — SCC cần chúng để function properly.


Retention Và Forensics

Một điểm quan trọng thường bị bỏ qua: _Required bucket có retention 400 ngày. Đây là intentional — để đảm bảo audit trail đủ dài cho forensics và compliance investigations.

Khi có incident hoặc data breach investigation, Admin Activity và System Event logs trong 400 ngày gần nhất luôn có sẵn mà không cần tốn tiền lưu trữ thêm. Tuy nhiên, Data Access Audit Logs không vào _Required bucket — chúng vào _Default (retention 30 ngày mặc định). Nếu bạn cần Data Access logs cho forensics dài hạn, phải:

  1. Cấu hình custom bucket với retention dài hơn
  2. Route Data Access logs vào đó qua custom sink
  3. Hoặc export sang BigQuery/Cloud Storage cho long-term storage

References