เก็บ log ตาม พ.ร.บ.คอมพิวเตอร์กี่วัน: audit trail ที่องค์กรไทยควรรู้

ตอนสร้าง log bucket ใหม่บน Google Cloud มีช่องหนึ่งให้กรอกว่าจะเก็บ log ไว้กี่วัน ถ้าไม่กรอก เอกสารของ Google Cloud ระบุว่าค่าเริ่มต้นคือ 30 วัน และ log ที่พ้นระยะเวลาเก็บแล้วจะกู้คืนไม่ได้ ตัวเลขในช่องนี้จึงกำหนดทั้งค่าใช้จ่ายรายเดือน ความสามารถในการสืบย้อนเหตุการณ์ และภาระด้านข้อมูลส่วนบุคคลไปพร้อมกัน

สมมติว่าทีมปล่อยค่าเริ่มต้นไว้ก่อน แล้วตั้งใจจะกลับมาแก้ทีหลัง วันที่ผู้ตรวจสอบภายในขอ audit trail ของสี่เดือนก่อน ทีมจะพบว่าข้อมูลช่วงนั้นไม่มีอยู่แล้ว และไม่มีปุ่มไหนเรียกกลับมาได้

บทความนี้เล่าว่าเราคิดเรื่องระยะเวลาเก็บ log อย่างไรเมื่อออกแบบระบบ ตั้งแต่การแยกประเภท log ตามจุดประสงค์ ข้อกำหนดตามกฎหมายไทยที่เราอ่านจากตัวบท การป้องกันไม่ให้ log ถูกแก้ ไปจนถึงต้นทุนและข้อมูลส่วนบุคคลที่ซ่อนอยู่ใน log บทความนี้ไม่ใช่คำแนะนำทางกฎหมาย คำถามว่าองค์กรของคุณมีหน้าที่ตามกฎหมายหรือไม่ ควรตอบโดยที่ปรึกษากฎหมายขององค์กร

log สามแบบ เก็บด้วยเหตุผลคนละข้อ

ข้อผิดพลาดที่เราระวังตั้งแต่ต้นคือการตั้งระยะเวลาเก็บ log เพียงค่าเดียวให้ทุกอย่าง ทั้งที่ log แต่ละประเภทตอบคำถามต่างกัน และมีคนใช้งานต่างกลุ่มกัน

• Operational log หรือ debug log ใช้ตอบว่าระบบทำงานผิดพลาดตรงไหน เช่น error, stack trace หรือเวลาตอบสนองของ API ข้อมูลกลุ่มนี้มีปริมาณมากที่สุด และมักหมดประโยชน์เร็วที่สุด เมื่อแก้ปัญหาเสร็จแล้วแทบไม่มีใครย้อนกลับไปดู

• Security log ใช้ตอบว่าใครพยายามเข้าถึงอะไร สำเร็จหรือถูกปฏิเสธ เช่น การ log-in, การเปลี่ยนสิทธิ์ และการเชื่อมต่อจากเครือข่ายภายนอก กลุ่มนี้ต้องเก็บนานพอให้สืบย้อนเหตุการณ์ได้ เพราะวันที่พบความผิดปกติกับวันที่เกิดเหตุจริงไม่จำเป็นต้องเป็นวันเดียวกัน

• Audit trail ใช้ตอบว่าใครเปลี่ยนอะไร เมื่อไร จากค่าเดิมเป็นค่าอะไร เช่น การอนุมัติรายการ การแก้ข้อมูลหลัก หรือการเปลี่ยนการตั้งค่าระบบ กลุ่มนี้คือหลักฐาน จึงต้องเชื่อถือได้มากกว่าจะค้นหาได้เร็ว

เมื่อแยกสามกลุ่มนี้ออกจากกันตั้งแต่ต้นทาง การตั้งระยะเวลาเก็บจะง่ายขึ้นมาก Operational log อาจเก็บสั้น ส่วน audit trail อาจต้องเก็บนานตามนโยบายภายในหรือข้อกำหนดของหน่วยงานกำกับ

บทความนี้ไม่ได้พูดถึงการออกแบบ alert จาก log ซึ่งเราเขียนไว้แล้วในบทความเรื่อง monitoring และ alert และไม่ได้ลงรายละเอียด audit log ของ AI Agent ซึ่งอยู่ในบทความเรื่องด่านก่อนให้ AI Agent เข้าถึงระบบจริง

พ.ร.บ.คอมพิวเตอร์ให้เก็บ log กี่วัน และใช้กับใคร

ข้อกำหนดหลักอยู่ในมาตรา 26 ของพระราชบัญญัติว่าด้วยการกระทำความผิดเกี่ยวกับคอมพิวเตอร์ พ.ศ. 2550 ซึ่งวรรคหนึ่งแก้ไขเพิ่มเติมโดยพระราชบัญญัติฉบับที่ 2 พ.ศ. 2560 เราอ่านตัวบทจากฉบับที่ สพธอ. (ETDA) เผยแพร่ ซึ่งรวมการแก้ไขทั้งสองฉบับไว้และอ้างอิงราชกิจจานุเบกษา

ตัวบทกำหนดให้ผู้ให้บริการเก็บรักษาข้อมูลจราจรทางคอมพิวเตอร์ไว้ไม่น้อยกว่า 90 วัน นับแต่วันที่ข้อมูลเข้าสู่ระบบคอมพิวเตอร์ ในกรณีจำเป็น พนักงานเจ้าหน้าที่สั่งให้ผู้ให้บริการรายใดเก็บเกิน 90 วันได้ แต่ไม่เกินสองปี เป็นกรณีพิเศษเฉพาะรายและเฉพาะคราว

วรรคสองของมาตราเดียวกันกำหนดให้ผู้ให้บริการเก็บข้อมูลผู้ใช้บริการเท่าที่จำเป็นเพื่อระบุตัวผู้ใช้บริการได้ นับตั้งแต่เริ่มใช้บริการ และเก็บต่อไม่น้อยกว่า 90 วันหลังการใช้บริการสิ้นสุดลง วรรคสามระบุว่าวรรคหนึ่งจะใช้กับผู้ให้บริการประเภทใด อย่างไร และเมื่อใด ให้เป็นไปตามที่รัฐมนตรีประกาศในราชกิจจานุเบกษา ส่วนวรรคสุดท้ายระบุว่าผู้ให้บริการที่ไม่ปฏิบัติตามมาตรานี้ต้องระวางโทษปรับไม่เกินห้าแสนบาท

คำที่ต้องอ่านให้ละเอียดคือ "ผู้ให้บริการ" ซึ่งมาตรา 3 นิยามไว้สองกลุ่ม กลุ่มแรกคือผู้ให้บริการแก่บุคคลอื่นในการเข้าสู่อินเทอร์เน็ตหรือติดต่อถึงกันผ่านระบบคอมพิวเตอร์ ไม่ว่าในนามของตนเองหรือเพื่อประโยชน์ของบุคคลอื่น กลุ่มที่สองคือผู้ให้บริการเก็บรักษาข้อมูลคอมพิวเตอร์เพื่อประโยชน์ของบุคคลอื่น เมื่ออ่านตามนิยามนี้ หน้าที่ตามมาตรา 26 จึงผูกกับบทบาทผู้ให้บริการ ไม่ได้เขียนไว้ให้ใช้กับทุกองค์กรที่มีระบบคอมพิวเตอร์

รายละเอียดว่าผู้ให้บริการประเภทใดต้องเก็บอะไร อยู่ในประกาศกระทรวงดิจิทัลเพื่อเศรษฐกิจและสังคม เรื่อง หลักเกณฑ์การเก็บรักษาข้อมูลจราจรทางคอมพิวเตอร์ของผู้ให้บริการ พ.ศ. 2564 ซึ่งลงราชกิจจานุเบกษาเมื่อ 13 สิงหาคม 2564 และยกเลิกประกาศฉบับปี 2550 ข้อ 5 ของประกาศแบ่งผู้ให้บริการออกเป็นหลายประเภท และภาคผนวก ก ยกตัวอย่างไว้ เช่น ผู้ให้บริการอินเทอร์เน็ต ผู้ให้บริการ Web Hosting ผู้ให้บริการคลาวด์ที่ให้บริการโดยตรงกับผู้ใช้งาน และผู้ให้บริการดิจิทัลหลายสาขา

ตัวอย่างหนึ่งในภาคผนวก ก ที่ทีม IT ขององค์กรควรรู้คือ "ผู้ให้บริการเข้าถึงระบบเครือข่ายคอมพิวเตอร์สำหรับองค์กร เช่น หน่วยงานราชการ บริษัท หรือสถาบันการศึกษา" องค์กรที่เปิดเครือข่ายให้พนักงานหรือนักศึกษาใช้อินเทอร์เน็ต จึงอาจอยู่ในขอบเขตนี้ได้ แต่องค์กรของคุณเข้าข่ายประเภทใด หรือไม่เข้าข่ายเลย เป็นคำถามที่ต้องให้ที่ปรึกษากฎหมายตีความจากลักษณะบริการจริง

ข้อ 12 ของประกาศกำหนดระยะเวลาสอดคล้องกับตัวบท คือกรณีทั่วไปไม่น้อยกว่า 90 วันนับแต่ข้อมูลเข้าสู่ระบบ และกรณีจำเป็นตามเงื่อนไขที่ระบุ พนักงานเจ้าหน้าที่สั่งให้เก็บต่อได้คราวละไม่เกินหกเดือนต่อเนื่องกัน แต่ต้องไม่เกินสองปี สังเกตว่ากฎหมายกำหนด "ขั้นต่ำ" ไว้ ไม่ได้บอกว่าเก็บนานเท่าไรจึงเหมาะกับระบบของคุณ

log ที่ผู้ดูแลระบบแก้ได้ ใช้เป็นหลักฐานได้ยาก

ข้อ 9 ของประกาศฉบับเดียวกันกำหนดวิธีเก็บที่มั่นคงปลอดภัยไว้หลายข้อ ข้อที่ตรงกับงานออกแบบระบบมากที่สุดคือ ต้องเก็บในสื่อหรือระบบที่รักษาความครบถ้วนถูกต้องของข้อมูล และระบุตัวบุคคลที่เข้าถึงได้ รวมถึงต้องไม่ให้ผู้ดูแลระบบแก้ไขข้อมูลที่เก็บไว้ได้ ประกาศยกตัวอย่างวิธีไว้ เช่น Centralized Log Server, Data Archiving หรือ Data Hashing

ต่อให้องค์กรของคุณไม่เข้าข่ายผู้ให้บริการ หลักข้อนี้ก็ใช้กับ audit trail ได้ตรง ๆ ถ้าคนที่มีสิทธิ์ admin บนระบบหลักลบหรือแก้ log ได้ด้วยบัญชีเดียวกัน log ชุดนั้นพิสูจน์อะไรได้น้อยมากในวันที่ต้องใช้จริง

การแยกสิทธิ์จึงสำคัญกว่าการเลือกเครื่องมือ

แนวทางที่เราใช้บ่อยคือส่ง log ออกไปเก็บใน project หรือ subscription แยกจากระบบหลัก ให้คนละกลุ่มถือสิทธิ์ แล้วเปิดคุณสมบัติกันแก้ไขของ cloud provider

• บน Google Cloud เอกสาร Cloud Logging buckets ระบุว่ากำหนด retention แบบกำหนดเองได้ตั้งแต่ 1 ถึง 3650 วัน และล็อก bucket ได้ การล็อกนี้ย้อนกลับไม่ได้ เมื่อล็อกแล้วจะแก้ไข bucket และ retention policy ไม่ได้ และจะลบ bucket ได้ก็ต่อเมื่อ log ทุกรายการครบระยะเวลาเก็บแล้ว

• บน Microsoft Azure เอกสาร Immutable storage for Blob Storage อธิบายการเก็บแบบ WORM (Write Once, Read Many) ที่ข้อมูลแก้หรือลบไม่ได้ตลอดช่วงเวลาที่กำหนด เมื่อล็อก time-based retention policy แล้วจะลบ policy ไม่ได้ ขยายระยะเวลาได้แต่ลดไม่ได้

ข้อ 11 ของประกาศยังกำหนดให้ตั้งนาฬิกาของอุปกรณ์ให้ตรงกับเวลาอ้างอิงสากล เรื่องนี้ดูเล็ก แต่ audit trail ที่เวลาของแต่ละเครื่องเหลื่อมกันไม่กี่นาที ทำให้เรียงลำดับเหตุการณ์ข้ามระบบไม่ได้ เราจึงตรวจการ sync เวลาเป็นรายการแรก ๆ ก่อนเชื่อมระบบใดเข้ากับ log กลาง

ต้นทุนของการเก็บนาน และการแบ่งชั้นข้อมูล

การเก็บ log นานมีต้นทุนจริง เอกสาร Cloud Logging ระบุว่าตั้งแต่ 1 เมษายน 2566 มีค่าใช้จ่ายด้าน retention สำหรับ log ที่เก็บนานกว่าระยะเวลาเริ่มต้นของ bucket _Default และ bucket ที่ผู้ใช้สร้างเอง ตัวเลขเรตควรเช็คจากหน้า pricing ปัจจุบันของผู้ให้บริการ เพราะเปลี่ยนได้

ฝั่ง Azure เอกสาร immutable storage ระบุว่าการเปิด immutability ไม่มีค่าความจุเพิ่ม ข้อมูลคิดราคาเหมือนข้อมูลปกติ และ access tier ทุกระดับของ blob รองรับ immutable storage แนวทางที่เราพิจารณาจึงเป็นการแบ่งชั้นตามอายุของ log เก็บ log ช่วงล่าสุดไว้ในที่ค้นหาได้เร็ว แล้วย้าย log ที่เก่ากว่าไปยัง tier ที่ค่าเก็บต่ำกว่า แต่แลกกับค่าเข้าถึงหรือเวลาเรียกคืนที่สูงกว่า

ข้อเสียที่ต้องพูดให้ชัดคือ การล็อก log แบบย้อนกลับไม่ได้ทำให้แก้ความผิดพลาดของตัวเองไม่ได้เช่นกัน ถ้าตั้ง retention ยาวเกินไป หรือเผลอส่งข้อมูลที่ไม่ควรเก็บเข้า bucket ที่ล็อกแล้ว คุณต้องจ่ายค่าเก็บและถือข้อมูลนั้นไว้จนครบกำหนด ถ้าองค์กรของคุณไม่เข้าข่ายผู้ให้บริการ และระบบนั้นมีผู้ใช้ภายในไม่กี่สิบคนโดยไม่มีธุรกรรมที่ต้องพิสูจน์ย้อนหลัง การแยก account พร้อมจำกัดสิทธิ์ลบอาจเพียงพอแล้ว โดยยังไม่ต้องล็อกถาวร

ข้อมูลส่วนบุคคลที่ซ่อนอยู่ใน log

ข้อ 9 (4) ของประกาศกำหนดว่าการเก็บข้อมูลจราจรต้องระบุรายละเอียดผู้ใช้บริการเป็นรายบุคคลได้ ขณะเดียวกัน log ที่ระบุตัวคนได้ก็คือชุดข้อมูลส่วนบุคคลอีกชุดหนึ่งขององค์กร เราจึงออกแบบให้ log เก็บเฉพาะสิ่งที่ต้องใช้ และไม่ให้ข้อมูลอ่อนไหวหลุดเข้าไปโดยไม่ตั้งใจ

• ไม่ log ค่าในฟอร์มทั้งก้อน เช่น request body ที่มีเลขบัตรประชาชน เบอร์โทร หรือรหัสผ่าน ให้ log เฉพาะรหัสอ้างอิงของรายการ

• mask ข้อมูลตั้งแต่ตอนเขียน log ไม่รอไปลบทีหลัง เพราะเมื่อข้อมูลเข้า bucket ที่ล็อกแล้ว จะลบออกไม่ได้จนกว่าจะครบกำหนด

• แยกตารางจับคู่ user ID กับตัวบุคคลไว้ในที่ที่สิทธิ์เข้มกว่า log ทั่วไป คนที่ debug ระบบจะเห็นแค่รหัส ส่วนคนที่ต้องสืบสวนจริงจะขอสิทธิ์ดูการจับคู่ได้ตามขั้นตอน

ระยะเวลาเก็บ log ที่มีข้อมูลส่วนบุคคลควรผ่านการทบทวนของ DPO หรือที่ปรึกษากฎหมายด้าน PDPA ขององค์กรด้วย เพราะการเก็บนานกว่าที่จำเป็นก็เป็นความเสี่ยงอีกด้านหนึ่ง

ข้อโต้แย้งที่ได้ยินบ่อย

ข้อโต้แย้งแรกคือ เก็บทุกอย่างไว้ให้นานที่สุดน่าจะปลอดภัยที่สุด ข้อนี้ฟังดูรอบคอบ แต่ log ที่ไม่มีใครกำหนดจุดประสงค์ไว้ มักไม่มีใครค้นเจอในวันที่ต้องใช้ และยังเพิ่มทั้งค่าเก็บกับปริมาณข้อมูลส่วนบุคคลที่องค์กรต้องรับผิดชอบ เราเลือกกำหนดระยะเวลาต่อประเภท log แล้วเขียนเหตุผลของแต่ละค่าไว้ในเอกสาร

ข้อโต้แย้งที่สองคือ cloud provider เก็บ log ให้อยู่แล้ว ข้อนี้จริงเพียงบางส่วน เอกสาร Azure เองระบุว่า resource log ที่เก็บข้อมูลการทำงานกับข้อมูล เป็นความรับผิดชอบของผู้ใช้ที่ต้องจัดเก็บให้คงอยู่ตามที่ข้อกำหนดต้องการ ค่าเริ่มต้นของแต่ละ provider จึงเป็นเพียงจุดตั้งต้น ไม่ใช่นโยบายขององค์กร

จะเริ่มตรงไหน

1. ทำรายการ log ที่ระบบสร้างขึ้นจริง แล้วจัดเข้าสามกลุ่ม คือ operational, security และ audit trail พร้อมระบุว่าใครเป็นคนใช้ log แต่ละกลุ่ม

2. ถามที่ปรึกษากฎหมายว่าองค์กรหรือบริการใดของคุณเข้าข่าย "ผู้ให้บริการ" ตามมาตรา 3 และประกาศปี 2564 หรือไม่ แล้วบันทึกคำตอบไว้เป็นลายลักษณ์อักษร

3. กำหนด retention ของแต่ละกลุ่ม โดยใช้ข้อกำหนดทางกฎหมายเป็นขั้นต่ำ และเหตุผลทางธุรกิจเป็นตัวกำหนดส่วนที่เกิน

4. ย้าย security log และ audit trail ไปเก็บใน project หรือ subscription แยก ทดสอบ retention ให้แน่ใจก่อน แล้วจึงล็อก

5. ตรวจว่า log ไม่มีข้อมูลส่วนบุคคลที่ไม่จำเป็น และนาฬิกาของทุกเครื่อง sync กับเวลาอ้างอิงเดียวกัน

ถ้าอยู่ระหว่างร่าง TOR ระบบใหม่ ให้เขียนข้อกำหนดเรื่อง retention และการกันแก้ไข log ลงไปตั้งแต่รอบแรก แนวคิดเรื่องการเขียนเงื่อนไขแบบนี้อยู่ในบทความเรื่องการเขียน TOR ให้ได้ระบบที่ดูแลต่อได้

สรุป

คำถามว่าต้องเก็บ log นานแค่ไหน ไม่มีตัวเลขเดียวที่ถูกสำหรับทุกระบบ กฎหมายกำหนดขั้นต่ำไว้สำหรับผู้ให้บริการตามนิยาม ส่วนที่เหลือเป็นการตัดสินใจขององค์กรเรื่องหลักฐาน ต้นทุน และข้อมูลส่วนบุคคล ถ้าจะหยิบไปใช้เพียงข้อเดียว ให้แยก audit trail ออกจาก log ทั่วไป แล้วเก็บไว้ในที่ที่ผู้ดูแลระบบหลักแก้ไม่ได้

หากต้องการคุยเรื่องการวางโครงสร้าง log บน Google Cloud หรือ Microsoft Azure ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ เรายินดีคุยเพื่อทำความเข้าใจระบบที่คุณมีอยู่ก่อน โดยยังไม่ต้องมีเอกสารครบ ส่วนคำถามด้านการตีความกฎหมาย เราจะแนะนำให้ปรึกษาที่ปรึกษากฎหมายขององค์กรเสมอ ดูข้อมูลเพิ่มเติมเกี่ยวกับเราได้ที่ superdev.tech