Cloud logging คือการเก็บบันทึกกิจกรรมในระบบคลาวด์ เช่น ใครล็อกอิน ใครเปลี่ยนสิทธิ์ และใครเปิดหรือลบข้อมูล ส่วน detection (การตรวจจับ) คือการนำบันทึกเหล่านั้นมาหาพฤติกรรมน่าสงสัยและแจ้งเตือน ถ้าไม่ได้เก็บ log ที่ถูกต้องไว้ก่อน ก็ตรวจจับไม่ได้ และสืบสวนย้อนหลังไม่ได้ด้วย บทความนี้อธิบายว่าควรเก็บ log ประเภทใด ผู้ให้บริการคลาวด์รายใหญ่บันทึกอะไรให้เองและเก็บนานแค่ไหน และต้องตั้งค่าอย่างไรให้ log ใช้ตรวจจับได้จริง
log ในคลาวด์มีกี่ชั้น
ก่อนเลือกว่าจะเก็บอะไร ต้องรู้ก่อนว่าการทำงานในคลาวด์มีสองแบบ แบบแรกคือ control plane (ส่วนจัดการ) หมายถึงการสร้าง แก้ไข หรือลบทรัพยากร (resource คือสิ่งที่สร้างในคลาวด์) เช่น สร้างเครื่องเสมือนหรือแก้สิทธิ์ผู้ใช้ แบบที่สองคือ data plane (ส่วนใช้ข้อมูล) หมายถึงการทำงานกับข้อมูลที่อยู่ในทรัพยากร เช่น อ่านไฟล์ในที่เก็บข้อมูล หรือดึงรหัสลับจากตู้เก็บกุญแจ (key vault) log ของ control plane มีปริมาณน้อยแต่มีค่าสูง ส่วน log ของ data plane มีปริมาณมาก จึงมักไม่เปิดไว้ให้อัตโนมัติ
- ตัวตน: การล็อกอิน การยืนยันตัวตนหลายปัจจัย (MFA) และการเปลี่ยนแปลงบัญชีกับสิทธิ์ ดูเพิ่มที่ ITDR: การตรวจจับและตอบสนองภัยคุกคามด้านตัวตน
- การจัดการ (control plane): ใครสั่งคำสั่งจัดการอะไรบนบัญชีคลาวด์ เมื่อไร และจากที่ไหน
- ข้อมูล (data plane): การอ่าน เขียน หรือลบข้อมูลในที่เก็บข้อมูลหรือฐานข้อมูล เปิดเฉพาะส่วนที่สำคัญ
- ระบบและเครือข่าย: log ของเครื่อง แอป และการเชื่อมต่อเครือข่ายภายในคลาวด์
ผู้ให้บริการแต่ละรายบันทึกอะไรให้เอง และเก็บนานแค่ไหน
ข้อมูลต่อไปนี้ตรวจจากเอกสารของผู้ให้บริการแต่ละราย เมื่อ 27 ตุลาคม 2026 ค่าเริ่มต้นเปลี่ยนได้ จึงควรตรวจเอกสารล่าสุดก่อนนำไปใช้วางแผน:
- AWS CloudTrail (บริการบันทึกกิจกรรมของ AWS): ทุกบัญชีเปิดดู Event history ได้เองโดยค่าเริ่มต้น ย้อนหลังได้ 90 วัน และมีเฉพาะ management event (กิจกรรมฝั่งจัดการ) ในแต่ละภูมิภาค (Region) ถ้าต้องการเก็บนานกว่า 90 วัน ต้องสร้าง trail (การตั้งค่าให้เก็บ log ต่อเนื่อง) หรือ CloudTrail Lake event data store (ที่เก็บ log ที่ตั้งขึ้นเอง) ส่วน data event (กิจกรรมฝั่งข้อมูล) ไม่ถูกบันทึกโดยค่าเริ่มต้น และมีค่าใช้จ่ายเพิ่ม
- Azure Activity Log (บันทึกกิจกรรมของ Azure): บันทึกการดำเนินการฝั่งจัดการของทรัพยากร เก็บไว้ 90 วันแล้วลบ ถ้าต้องการเก็บนานกว่านั้น ต้องตั้ง diagnostic setting (การตั้งค่าให้ส่ง log ไปเก็บที่อื่น) ส่วน log ฝั่งข้อมูลอยู่ใน resource logs ซึ่งต้องตั้งค่าเอง
- Google Cloud Audit Logs (บันทึกตรวจสอบของ Google Cloud): Admin Activity (กิจกรรมฝั่งจัดการ) ถูกบันทึกเสมอและปิดไม่ได้ ส่วน Data Access (การเข้าถึงข้อมูล) ปิดอยู่โดยค่าเริ่มต้น ยกเว้น BigQuery (บริการวิเคราะห์ข้อมูลของ Google) ถ้าเป็นบริการอื่นต้องเปิดเอง ที่เก็บ log ชื่อ _Required เก็บ 400 วันและปรับไม่ได้ ส่วนที่เก็บชื่อ _Default เก็บ 30 วัน
- Microsoft Entra ID (บริการระบบตัวตนของ Microsoft): log การล็อกอินและ log การตรวจสอบเก็บไว้ 7 วันในรุ่น Free และ 30 วันในรุ่น P1 และ P2 log เหล่านี้แยกจาก Microsoft 365 Unified Audit Log ซึ่งจัดการผ่าน Microsoft Purview
สรุปคือ ค่าเริ่มต้นเหมาะกับการดูย้อนหลังระยะสั้นเท่านั้น ถ้าพบเหตุการณ์หลังพ้นระยะเวลาเก็บ ก็จะไม่มี log ให้ย้อนดู ระยะเวลาเก็บที่เหมาะสมเป็นการตัดสินใจขององค์กร ขึ้นกับความเสี่ยงและกฎระเบียบที่เกี่ยวข้อง แหล่งที่เราตรวจไม่ได้ระบุตัวเลขกลางที่ใช้ได้ทุกกรณี
ควรเก็บอะไรก่อน
NSA และ CISA ร่วมกับหน่วยงานต่างประเทศ เผยแพร่เอกสารชุดเรื่อง SIEM (ระบบรวบรวมและวิเคราะห์ log จากหลายแหล่ง) และ SOAR (ระบบสั่งงานตอบสนองเหตุการณ์อัตโนมัติ) เมื่อ 27 พฤษภาคม 2025 ชุดนี้มีสามฉบับ ฉบับหนึ่งชื่อ Priority Logs for SIEM Ingestion: Practitioner Guidance ว่าด้วยการเลือกว่าควรส่ง log ชนิดใดเข้า SIEM ก่อน เราอ่านเนื้อหาในไฟล์ PDF โดยตรงไม่ได้ จึงสรุปได้เพียงตามคำอธิบายของ CISA และหน้าสรุปของหน่วยงานพันธมิตร ซึ่งบอกว่าเอกสารจัดกลุ่ม log ตามประเภทแหล่ง รวมถึงผู้ให้บริการคลาวด์รายใหญ่ และแนะนำให้ปรับให้เหมาะกับองค์กร โดยค่อย ๆ เพิ่มแหล่ง log ทีละส่วน ไม่ใช่เปิดทั้งหมดพร้อมกัน
ลำดับด้านล่างเป็นข้อเสนอของเราเอง เลือกจากเหตุการณ์ที่มีค่าสูงและปริมาณน้อยก่อน ไม่ได้ยกมาจากเอกสารข้างต้น
- การล็อกอินและการเปลี่ยนวิธียืนยันตัวตน: ล็อกอินสำเร็จและล้มเหลว รวมถึงการเพิ่มหรือลบ MFA
- การใช้บัญชีผู้ดูแลสูงสุด: บัญชี root ของ AWS หรือบทบาท Global Administrator ของ Microsoft บัญชีเหล่านี้ควรใช้น้อยมาก จึงต้องมีเหตุผลทุกครั้งที่ใช้
- การเปลี่ยนสิทธิ์และกุญแจ: การสร้าง access key (รหัสที่โปรแกรมใช้เรียกคลาวด์) การให้สิทธิ์ผู้ดูแลระบบ และการสร้างหรือแก้บัญชีเครื่อง (บัญชีที่โปรแกรมใช้ ไม่ใช่คน)
- การแตะต้องระบบบันทึก log เอง: การปิดหรือลบ trail, diagnostic setting หรือ sink (ปลายทางที่ส่ง log ออกไป)
- การเปิดช่องทางเข้าถึง: การเปิดที่เก็บไฟล์ให้เป็นสาธารณะ หรือเปิดกฎไฟร์วอลล์ของเครื่องในคลาวด์ให้ทั้งอินเทอร์เน็ตเข้าได้
- การเข้าถึงข้อมูลสำคัญ: เปิด log ฝั่งข้อมูลเฉพาะที่เก็บข้อมูลสำคัญ เพราะมีค่าใช้จ่ายเพิ่มและมีปริมาณมาก
เปลี่ยน log ให้เป็นการตรวจจับด้วย MITRE ATT&CK
MITRE ATT&CK (ฐานความรู้เรื่องเทคนิคที่ผู้โจมตีใช้) มี Cloud Matrix ซึ่งครอบคลุมสี่แพลตฟอร์ม ได้แก่ Office Suite, Identity Provider, SaaS และ IaaS (บริการเช่าเครื่องและเครือข่าย) วิธีใช้คือเลือกก่อนว่าจะเขียนกฎตรวจจับเรื่องใด แล้วย้อนไปดูว่าต้องมี log อะไรจึงตรวจได้ ถ้าไม่มี log ที่ต้องใช้ กฎนั้นก็ทำงานไม่ได้ แอป SaaS ที่องค์กรใช้ก็ต้องส่ง log ของตัวเองเข้ามาด้วย ดู SaaS Security และ SSPM: ดูแลแอป SaaS อย่างไร
- บัญชีคลาวด์ถูกใช้ผิดปกติ: ล็อกอินสำเร็จหลังล้มเหลวหลายครั้ง หรือล็อกอินจากที่ที่ไม่เคยพบมาก่อน ตรงกับเทคนิค Valid Accounts: Cloud Accounts
- เพิ่มช่องทางให้อยู่ในระบบต่อ: การเพิ่มกุญแจหรือบทบาทใหม่ให้บัญชี ตรงกับเทคนิคย่อยของ Account Manipulation เช่น Additional Cloud Credentials และ Additional Cloud Roles
- ปิดการป้องกันหรือการบันทึก: การปิด log หรือเครื่องมือป้องกัน ตรงกับกลยุทธ์ (tactic) ชื่อ Defense Impairment ใน ATT&CK เวอร์ชัน v20 ที่เราเปิดดู
- สั่งงานเครื่องผ่านระบบจัดการของคลาวด์: ตรงกับเทคนิค Cloud Administration Command ซึ่งดูได้จาก log ฝั่ง control plane
- ขนข้อมูลออก: การอ่านหรือคัดลอกข้อมูลปริมาณมากจากที่เก็บข้อมูล ตรวจได้ก็ต่อเมื่อเปิด log ฝั่งข้อมูลไว้เท่านั้น
ตั้งค่าทีละขั้น
ขั้นตอนนี้เป็นแนวปฏิบัติที่เราเรียบเรียงเองจากเอกสารของผู้ให้บริการและแนวคิดข้างต้น ไม่ได้มาจากมาตรฐานฉบับใดฉบับเดียว
- เปิดการบันทึกให้ครบทุกบัญชีและทุกภูมิภาค: สร้าง trail หรือ event data store ใน AWS ตั้ง diagnostic setting ใน Azure และเปิด Data Access audit logs ใน Google Cloud เฉพาะบริการสำคัญ
- ส่ง log ไปเก็บในบัญชีแยก: ใช้บัญชีหรือโปรเจกต์ที่ใช้เก็บ log โดยเฉพาะ และให้ผู้ดูแลระบบทั่วไปลบ log ไม่ได้ เพราะผู้โจมตีมักพยายามลบร่องรอย
- กำหนดระยะเวลาเก็บข้อมูล: ตั้งตามความเสี่ยงและกฎระเบียบ และตรวจว่าระยะที่ตั้งยาวพอกับความต้องการ เพราะค่าเริ่มต้นของผู้ให้บริการอาจสั้นกว่า
- ป้องกันความถูกต้องของ log: เปิด log file validation ของ CloudTrail ซึ่งช่วยตรวจได้ว่าไฟล์ log ถูกแก้ไขหรือลบหรือไม่ ส่วน Cloud Audit Logs ของ Google Cloud ระบุว่าแก้ไขรายการที่บันทึกแล้วไม่ได้
- ส่งเข้า SIEM แล้วทดสอบกฎ: จำลองเหตุการณ์ในบัญชีทดสอบ เช่น สร้าง access key ใหม่ แล้วดูว่ากฎแจ้งเตือนจริงหรือไม่
เมื่อรวม log ไว้ที่เดียวกันแล้ว ถ้าต้องเลือกเครื่องมือวิเคราะห์ ดู SIEM, SOAR และ XDR: ต่างกันอย่างไร
ข้อผิดพลาดที่พบบ่อย
- พึ่งค่าเริ่มต้นของผู้ให้บริการ: หลายบริการเก็บแค่ 7 ถึง 90 วัน และไม่มี log ฝั่งข้อมูล
- เปิด log ทุกอย่างโดยไม่เลือก: ค่าใช้จ่ายสูง และทีมถูกท่วมด้วยการแจ้งเตือนที่ไม่มีใครอ่าน
- เก็บ log ไว้ในบัญชีเดียวกับระบบที่ถูกโจมตี: ผู้โจมตีที่ได้สิทธิ์ผู้ดูแลระบบจะลบ log ได้
- ไม่ตรวจว่า log ยังส่งเข้ามาอยู่: การส่ง log หยุดไปโดยไม่มีใครรู้ ทั้งที่ทุกคนเชื่อว่ายังตรวจจับได้อยู่
- ไม่ทดสอบกฎตรวจจับ: มีกฎอยู่แต่ไม่เคยแจ้งเตือนเลย เพราะไม่ได้เปิด log ที่กฎต้องใช้
ข้อผิดพลาด
- พึ่งแต่ค่าเริ่มต้น
- เก็บ log ไว้ในบัญชีเดียวกับระบบ
- ไม่เคยทดสอบกฎตรวจจับ
แนวปฏิบัติ
- ตั้งระยะเวลาเก็บเอง
- เก็บสำเนาในบัญชีแยก
- จำลองเหตุการณ์แล้วดูว่าแจ้งเตือน
ขั้นแรกที่ทำได้ทันที
- ตรวจว่าเปิดการบันทึกฝั่งจัดการไว้ครบทุกบัญชี: ดูว่ามี trail หรือ diagnostic setting ครอบคลุมทุกบัญชีหรือไม่
- ดูระยะเวลาเก็บข้อมูลที่ใช้อยู่: เทียบกับค่าเริ่มต้นที่ระบุไว้ข้างต้น ว่าสั้นเกินไปหรือไม่
- เลือก 3 กฎแรกที่จะสร้าง: เช่น การใช้บัญชีผู้ดูแลสูงสุด การปิดการบันทึก และการสร้าง access key ใหม่
- คัดลอก log ไปเก็บในบัญชีแยก: เริ่มจาก log ฝั่งจัดการและ log การล็อกอิน
หากต้องการทราบว่าการเฝ้าระวังและการตรวจจับขององค์กรอยู่ในระดับใด ลองใช้ แบบประเมินตนเอง
แหล่งอ้างอิงและข้อมูลเพิ่มเติม
- CISA: Guidance for SIEM and SOAR Implementation: หน้ารวมเอกสารสามฉบับ รวมถึง Priority Logs for SIEM Ingestion
- MITRE ATT&CK: Cloud Matrix: เทคนิคของผู้โจมตีบน Office Suite, Identity Provider, SaaS และ IaaS
- MITRE ATT&CK T1078.004: Valid Accounts: Cloud Accounts: ตัวอย่างเทคนิคที่เริ่มจาก log การล็อกอิน
- AWS CloudTrail: How CloudTrail works: Event history, trail และ event data store
- AWS CloudTrail: Logging data events: data event ไม่เปิดโดยค่าเริ่มต้นและมีค่าใช้จ่ายเพิ่ม
- Azure Monitor: Activity log: ระยะเวลาเก็บ 90 วัน และ diagnostic setting
- Google Cloud: Cloud Audit Logs overview: ชนิดของ audit log และค่าเริ่มต้น
- Google Cloud: Logging quotas and limits: ระยะเวลาเก็บของที่เก็บ _Required และ _Default
- Microsoft Entra: Data retention: ระยะเวลาเก็บ log การล็อกอินและการตรวจสอบ