Compliance Monitoring: Audit Logs สำหรับ Security Standards

Categories

การทำ Compliance Monitoring คือการติดตามและเก็บหลักฐานการกระทำบนระบบเพื่อยืนยันว่าองค์กรปฏิบัติตามมาตรฐานด้าน security เช่น PCI DSS, HIPAA, ISO 27001, SOC 2 หรือ GDPR — หัวใจสำคัญคือ Audit Log ที่บันทึกทุก event ที่เกี่ยวข้องกับการเข้าถึงและเปลี่ยนแปลงข้อมูล เพื่อพิสูจน์ได้ว่าใครทำอะไร เมื่อไหร่ ที่ไหน

บทความนี้จะอธิบายว่า audit log ที่ดีต้องมีอะไรบ้าง, วิธีเก็บให้ถูกต้องตามมาตรฐาน, วิธี centralize log จากหลายระบบ, การทำ retention, tamper-evident storage และการตั้ง alert สำหรับเหตุการณ์ที่น่าสงสัย เพื่อผ่านการ audit และตรวจจับการบุกรุกได้ทันท่วงที

Audit Log คืออะไร และต่างจาก Application Log อย่างไร

Audit Log คือ log ที่บันทึก event สำคัญเพื่อการตรวจสอบย้อนหลัง — ใคร (Who) ทำอะไร (What) เมื่อไหร่ (When) ที่ไหน (Where) ผลลัพธ์คืออะไร (Result) ต่างจาก application log ทั่วไปตรงที่ audit log ต้อง tamper-evident และเก็บไว้ยาวนานตามกฎหมาย ไม่สามารถลบได้ง่าย ๆ

ส่วนประกอบที่ต้องมีใน Audit Event

  • Timestamp — UTC + timezone อย่างแม่นยำ (ใช้ NTP)
  • Actor — user ID, service account, หรือ API key ที่ทำ action
  • Source — IP address, device fingerprint, user agent
  • Action — create, read, update, delete, login, permission change
  • Target — resource หรือ record ที่ถูกเปลี่ยนแปลง
  • Result — success, failure, error code
  • Context — correlation ID, session ID, request ID
  • Before/After — ค่าเดิมและค่าใหม่ (สำหรับ data change)
{
  "timestamp": "2026-04-18T03:24:15.123Z",
  "actor": {
    "user_id": "u_12345",
    "email": "[email protected]",
    "roles": ["admin"],
    "auth_method": "SAML_SSO"
  },
  "source": {
    "ip": "203.0.113.42",
    "user_agent": "Mozilla/5.0 ...",
    "country": "TH"
  },
  "action": "user.permission.granted",
  "target": {
    "resource_type": "user",
    "resource_id": "u_67890",
    "changes": {
      "roles_before": ["user"],
      "roles_after": ["user", "admin"]
    }
  },
  "result": "success",
  "request_id": "req_abc123",
  "session_id": "sess_def456"
}

มาตรฐาน Security ที่ต้องการ Audit Log

มาตรฐานขอบเขตRetentionข้อกำหนดสำคัญ
PCI DSS 4.0Payment card data1 ปี (online) + 1 ปีReq. 10: Log และ monitor access
HIPAAHealth information (US)6 ปี§164.312(b): Audit controls
ISO 27001Information security mgmtตามนโยบาย (>= 1 ปี)A.12.4: Logging and monitoring
SOC 2Service org controls1 ปี+CC7.2: Anomaly monitoring
GDPREU personal dataตามที่กำหนดใน policyArt. 32: Integrity & confidentiality
SOXFinancial reporting (US)7 ปีSection 404: Internal controls

หลักการพื้นฐานที่ทุกมาตรฐานต้องการ

  • Completeness — log ทุก event ที่เกี่ยวข้องกับการเข้าถึงและเปลี่ยน data
  • Integrity — log ต้องไม่ถูกแก้ไขหรือลบ (tamper-evident)
  • Time Synchronization — clock ของทุก server ต้อง sync ผ่าน NTP
  • Separation of Duties — ผู้ดูแล log ≠ ผู้ที่ถูก log
  • Retention — เก็บตามระยะเวลาที่มาตรฐานกำหนด
  • Access Control — จำกัดสิทธิ์การเข้าถึง log
  • Review — มีกระบวนการ review log อย่างสม่ำเสมอ

Authentication และ Authorization

  • Login success/failure (พร้อม IP, MFA method)
  • Logout และ session expiry
  • Password change, reset, lockout
  • MFA enable/disable, device registration
  • Permission grant/revoke, role change
  • Impersonation / Sudo

Data Access และ Modification

  • Read ข้อมูล sensitive (PII, PHI, payment card)
  • Create, Update, Delete records
  • Export / Download ข้อมูลจำนวนมาก
  • Database schema change
  • File upload/download (เฉพาะ sensitive)

Administrative Actions

  • Create/delete user, group, service account
  • Change security policy (firewall, ACL)
  • Key rotation, secret access
  • Configuration change
  • Backup, restore
  • Log system tamper attempt

สถาปัตยกรรมการเก็บ Audit Log

Audit log ต้องเก็บแยกจาก application log และจัดเก็บใน storage ที่ write-once (immutable) โดยมีการ centralize log จากทุก source เข้าสู่ระบบเดียว แล้ว forward ต่อไปยัง storage ที่ tamper-evident

Pattern ที่ใช้บ่อย

  • Application → Log Agent → Kafka → SIEM + Cold Storage — agent อ่าน log ส่งไป Kafka สำหรับ streaming, SIEM สำหรับ real-time alert, cold storage (S3/GCS) สำหรับ retention
  • Application → Syslog → Log Forwarder → Central — ใช้ rsyslog/syslog-ng สำหรับ infrastructure log
  • Application → AWS CloudTrail / GCP Cloud Audit Logs — ใช้ native cloud audit service
  • Application → Loki/Elastic → S3 Object Lock — ใช้ object lock ป้องกันการลบ

S3 Object Lock สำหรับ Immutable Storage

S3 Object Lock ใช้บังคับ retention และป้องกันการลบหรือแก้ไข object โดยมี 2 mode — Compliance mode (root user ก็ลบไม่ได้) และ Governance mode (มี privilege พิเศษลบได้) สำหรับ audit log ที่ต้องผ่านมาตรฐาน ควรใช้ Compliance mode

# สร้าง bucket พร้อม Object Lock
aws s3api create-bucket \
  --bucket audit-logs-compliance \
  --object-lock-enabled-for-bucket \
  --region us-east-1

# ตั้ง default retention 7 ปี แบบ Compliance mode
aws s3api put-object-lock-configuration \
  --bucket audit-logs-compliance \
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {
      "DefaultRetention": {
        "Mode": "COMPLIANCE",
        "Years": 7
      }
    }
  }'

# Upload พร้อม retention
aws s3api put-object \
  --bucket audit-logs-compliance \
  --key 2026/04/audit-log-2026-04-18.json.gz \
  --body audit-log.json.gz \
  --object-lock-mode COMPLIANCE \
  --object-lock-retain-until-date "2033-04-18T00:00:00Z"

AWS CloudTrail

CloudTrail บันทึกทุก API call ที่เกิดขึ้นใน AWS account ทั้งจาก Console, CLI, SDK มี 3 ประเภท — Management events (API ที่จัดการ resource), Data events (S3, Lambda การเข้าถึง data), Insight events (ตรวจจับ anomaly) ควร enable ทั้ง 3 ประเภทและ log ลง S3 พร้อม Object Lock

aws cloudtrail create-trail \
  --name org-audit-trail \
  --s3-bucket-name audit-logs-compliance \
  --is-multi-region-trail \
  --is-organization-trail \
  --enable-log-file-validation

# Enable data events สำหรับ S3
aws cloudtrail put-event-selectors \
  --trail-name org-audit-trail \
  --event-selectors '[{
    "ReadWriteType": "All",
    "IncludeManagementEvents": true,
    "DataResources": [{
      "Type": "AWS::S3::Object",
      "Values": ["arn:aws:s3:::sensitive-bucket/"]
    }]
  }]'

# Start logging
aws cloudtrail start-logging --name org-audit-trail

CloudTrail Lake สำหรับ Query

CloudTrail Lake เป็น managed data lake สำหรับเก็บและ query audit event ด้วย SQL — เหมาะกับการ investigation เหตุการณ์และทำ compliance report

-- หา failed login attempt ใน 30 วันที่ผ่านมา
SELECT eventTime, userIdentity.userName, sourceIPAddress, errorMessage
FROM event_data_store
WHERE eventName = 'ConsoleLogin'
  AND errorMessage IS NOT NULL
  AND eventTime > timestamp '2026-03-18 00:00:00.000'
ORDER BY eventTime DESC
LIMIT 100;

GCP Cloud Audit Logs

GCP มี Cloud Audit Logs แยก 4 ประเภท — Admin Activity (enable by default), Data Access (ต้องเปิดเอง), System Event, Policy Denied ควรเปิด Data Access log สำหรับ resource ที่มี data sensitive แล้ว export ไปยัง Cloud Storage หรือ BigQuery

# Export audit log ไป Cloud Storage
gcloud logging sinks create audit-log-sink \
  storage.googleapis.com/audit-logs-bucket \
  --log-filter='logName:"cloudaudit.googleapis.com"' \
  --project=prod-project

# Enable Data Access log
# (ใช้ IAM policy file data_access.yaml)
gcloud projects set-iam-policy prod-project data_access.yaml

Kubernetes Audit Log

Kubernetes API server สามารถเปิด audit log ได้ เพื่อบันทึกทุก API call ที่เข้ามา โดยมี 4 level — None, Metadata, Request, RequestResponse สำหรับ compliance แนะนำ Metadata สำหรับ resource ทั่วไป และ RequestResponse สำหรับ resource sensitive เช่น Secret

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
# Log Secret และ ConfigMap แบบละเอียด
- level: RequestResponse
  resources:
  - group: ""
    resources: ["secrets", "configmaps"]

# Log authentication ทุกครั้ง
- level: Metadata
  verbs: ["create", "update", "patch", "delete"]
  omitStages: ["RequestReceived"]

# Don't log routine requests
- level: None
  users: ["system:kube-proxy"]
  verbs: ["watch"]

Tamper Evidence

การทำให้ log ไม่สามารถถูกแก้ไขได้โดยไม่มีหลักฐานใช้เทคนิคหลายอย่าง เช่น hash chain, signed log, WORM storage — วิธีที่ง่ายและได้ผลคือการคำนวณ hash ของ log แต่ละ chunk แล้วเก็บ hash ไว้ในระบบแยก หากใครแก้ log, hash จะไม่ตรง

# ตัวอย่าง: hash chain สำหรับ log file
import hashlib, json

previous_hash = "0" * 64  # genesis
for entry in audit_events:
    entry_bytes = json.dumps(entry, sort_keys=True).encode()
    hasher = hashlib.sha256()
    hasher.update(previous_hash.encode())
    hasher.update(entry_bytes)
    current_hash = hasher.hexdigest()
    entry["prev_hash"] = previous_hash
    entry["hash"] = current_hash
    previous_hash = current_hash

# การ verify: คำนวณ hash ใหม่ทุก entry ถ้าไม่ตรง = ถูกแก้

AWS CloudTrail Log File Validation

CloudTrail มี feature Log File Validation ที่สร้าง digest file (SHA-256 hash ของทุก log file ในชั่วโมงนั้น) แล้ว sign ด้วย RSA — สามารถใช้ AWS CLI verify ได้ว่ามีการแก้ไขไฟล์ใดหรือไม่

# Verify digest
aws cloudtrail validate-logs \
  --trail-arn arn:aws:cloudtrail:us-east-1:123456789012:trail/org-audit-trail \
  --start-time 2026-04-17T00:00:00Z \
  --end-time 2026-04-18T00:00:00Z

Alert สำหรับเหตุการณ์ที่น่าสงสัย

การเก็บ log อย่างเดียวไม่พอ ต้องมี alert เมื่อเกิด event ที่ผิดปกติ ทั้งใน real-time และ batch — ส่วนใหญ่ตั้ง alert ใน SIEM (Security Information and Event Management) ที่จะครอบคลุมในบทความถัดไป

Alert ที่ควรตั้ง

  • Failed login ซ้ำ — >5 ครั้งใน 5 นาทีจาก source เดียวกัน (brute force)
  • Login จากพื้นที่ผิดปกติ — ประเทศที่ไม่เคย login มาก่อน
  • Privileged action — user ธรรมดา run admin command
  • Root login — root account ควร alert ทุกครั้ง
  • Mass export — download ข้อมูลเกิน threshold ใน 1 ชั่วโมง
  • Log tampering — Object Lock violation, digest verification failed
  • MFA bypass — login success โดยไม่ผ่าน MFA
  • After-hours activity — admin activity นอกเวลาทำงาน

Compliance Report

การ audit จะถาม evidence — ต้องมีรายงานที่พิสูจน์ได้ว่าระบบ log ทำงานครบถ้วนตามนโยบาย ควรสร้าง dashboard และ report อัตโนมัติเพื่อลดภาระการเตรียม evidence ตอนเข้า audit

  • Log Coverage Report — แสดงว่าทุก system มี log flow ปกติ
  • Retention Compliance — แสดงว่า log ถูกเก็บตามระยะเวลา
  • Access Review — ใครเข้าถึง audit log และทำอะไร
  • Incident Report — สรุป security incident พร้อม evidence
  • User Activity Review — พฤติกรรมผู้ใช้ที่มี privilege สูง

Best Practices

  • แยก audit log ออกจาก application log — storage ต่างกัน, retention ต่างกัน
  • ห้าม log ข้อมูล sensitive — PII, password, token ต้อง mask ก่อน log
  • Time sync — ทุก server ต้อง sync clock ผ่าน NTP
  • Immutable storage — ใช้ Object Lock หรือ WORM storage
  • Centralize — ทุก log ส่งเข้าระบบกลาง 1 จุด
  • Test restoration — ทดสอบดึง log ย้อนหลังอย่างน้อยปีละครั้ง
  • Document retention policy — เขียนไว้ว่า log แต่ละประเภทเก็บนานแค่ไหน
  • Periodic access review — review ผู้ที่เข้าถึง audit log ทุกไตรมาส
  • Automate compliance report — ลดงาน manual ช่วง audit

สรุป

Audit Log เป็นรากฐานของ Compliance — ไม่ใช่แค่การเก็บข้อความ แต่เป็นการสร้างระบบที่พิสูจน์ได้ว่าใครทำอะไร เมื่อไหร่ โดยที่ไม่สามารถถูกแก้ไขได้ การออกแบบระบบต้องคิดตั้งแต่การ instrument event, centralize log, ใช้ immutable storage, ตั้ง alert และสร้าง report อัตโนมัติ เพื่อให้ผ่านการ audit และตอบสนองต่อ incident ได้เร็ว

มาตรฐานแต่ละตัว (PCI DSS, HIPAA, ISO 27001, SOC 2, GDPR, SOX) มี requirement ต่างกัน แต่หลักการคล้ายกัน — completeness, integrity, retention, access control ใช้เครื่องมือ native เช่น AWS CloudTrail, GCP Cloud Audit Logs, Kubernetes Audit Policy ร่วมกับ immutable storage (S3 Object Lock) และ SIEM จะทำให้ตอบโจทย์มาตรฐานได้อย่างมีประสิทธิภาพ