[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-faqs-log-retention-audit-trail-thailand-th":3,"blog-post-log-retention-audit-trail-thailand-th":28},[4,8,12,16,20,24],{"answer":5,"id":6,"question":7},"มาตรา 3 ของพระราชบัญญัติว่าด้วยการกระทำความผิดเกี่ยวกับคอมพิวเตอร์ พ.ศ. 2550 นิยามว่าเป็นข้อมูลเกี่ยวกับการติดต่อสื่อสารของระบบคอมพิวเตอร์ ที่แสดงถึงแหล่งกำเนิด ต้นทาง ปลายทาง เส้นทาง เวลา วันที่ ปริมาณ ระยะเวลา ชนิดของบริการ หรืออื่น ๆ ที่เกี่ยวข้อง ในมุมของทีมระบบ เรามองว่าข้อมูลกลุ่มนี้ใกล้เคียงกับ access log และ connection log มากกว่าเนื้อหาของข้อมูลที่รับส่ง","zwjy8yyzb5i9vya","ข้อมูลจราจรทางคอมพิวเตอร์ตามกฎหมายไทยหมายถึงอะไร",{"answer":9,"id":10,"question":11},"ขึ้นกับลักษณะบริการจริง ประกาศกระทรวงดิจิทัลเพื่อเศรษฐกิจและสังคม พ.ศ. 2564 ภาคผนวก ก ยกตัวอย่างผู้ให้บริการเข้าถึงระบบเครือข่ายคอมพิวเตอร์สำหรับองค์กร เช่น หน่วยงานราชการ บริษัท หรือสถาบันการศึกษา ไว้ด้วย องค์กรที่เปิดเครือข่ายให้พนักงานใช้จึงอาจเข้าข่ายได้ แต่คำตอบสุดท้ายควรมาจากที่ปรึกษากฎหมายขององค์กร และควรบันทึกไว้เป็นลายลักษณ์อักษร","wvf1yf4y9q2idon","องค์กรที่ไม่ได้ขายบริการอินเทอร์เน็ต ถือเป็นผู้ให้บริการตามกฎหมายนี้หรือไม่",{"answer":13,"id":14,"question":15},"Application log บอกว่าระบบทำงานอย่างไร เช่น error หรือเวลาตอบสนอง ใช้แก้ปัญหาแล้วหมดประโยชน์เร็ว ส่วน audit trail บอกว่าใครเปลี่ยนอะไร เมื่อไร จากค่าเดิมเป็นค่าอะไร ใช้เป็นหลักฐาน จึงต้องเก็บนานกว่าและต้องกันไม่ให้ผู้ดูแลระบบหลักแก้ไขได้ เราจึงแยกสองกลุ่มนี้ออกจากกันตั้งแต่ตอนออกแบบ","9nb3bgjo6jqoogz","Audit trail ต่างจาก application log อย่างไร",{"answer":17,"id":18,"question":19},"เมื่อล็อกแล้วยกเลิกไม่ได้ เอกสาร Cloud Logging ของ Google Cloud ระบุว่าการล็อก bucket ย้อนกลับไม่ได้ และลบ bucket ได้เมื่อ log ทุกรายการครบระยะเวลาเก็บแล้วเท่านั้น ฝั่ง Azure เมื่อล็อก time-based retention policy แล้วจะลบ policy ไม่ได้ ขยายระยะเวลาได้แต่ลดไม่ได้ จึงควรทดสอบ retention และตรวจว่าไม่มีข้อมูลที่ไม่ควรเก็บก่อนล็อก","xkqy1k6o205iqka","ล็อก log bucket หรือ immutability policy แล้ว ยกเลิกทีหลังได้ไหม",{"answer":21,"id":22,"question":23},"สำหรับ security log และ audit trail เราแนะนำให้แยกไปไว้ใน project หรือ subscription อื่น ที่คนละกลุ่มถือสิทธิ์ ถ้าบัญชีที่มีสิทธิ์ admin บนระบบหลักลบ log ได้ด้วย log ชุดนั้นจะพิสูจน์อะไรได้น้อยในวันที่ระบบถูกบุกรุก ส่วน operational log ที่ใช้แก้ปัญหาประจำวัน เก็บใกล้ระบบหลักได้","i2tbo6i8l17e886","ควรเก็บ log ไว้ในบัญชีคลาวด์เดียวกับระบบหลักไหม",{"answer":25,"id":26,"question":27},"มาตรา 26 และประกาศปี 2564 ใช้คำว่าไม่น้อยกว่า 90 วัน จึงเป็นขั้นต่ำสำหรับผู้ให้บริการตามนิยาม ไม่ใช่เพดาน แต่การเก็บนานขึ้นมีต้นทุนค่าเก็บ และถ้า log มีข้อมูลส่วนบุคคล ก็เพิ่มปริมาณข้อมูลที่องค์กรต้องดูแล ระยะเวลาที่เกินขั้นต่ำควรมีเหตุผลทางธุรกิจรองรับ และผ่านการทบทวนของ DPO หรือที่ปรึกษากฎหมายด้าน PDPA","miigjhlijnmmh78","เก็บ log ไว้นานกว่าที่กฎหมายกำหนดได้ไหม",{"id":29,"parentId":30,"title":31,"excerpt":32,"content":33,"image":34,"date":35,"isoDate":36,"views":37,"tag":38,"categorySlug":39,"slug":40,"to":41,"readTime":42,"isHighlight":43,"sortOrder":44,"video":45,"video_id":45,"keywords":46},"eeaixj8llywa8zs","4in0ysidwqz16aq","เก็บ log ตาม พ.ร.บ.คอมพิวเตอร์กี่วัน: audit trail ที่องค์กรไทยควรรู้","มาตรา 26 พ.ร.บ.คอมพิวเตอร์ให้ผู้ให้บริการเก็บข้อมูลจราจรไม่น้อยกว่า 90 วัน ใครเข้าข่าย log แบบไหนควรเก็บนานเท่าไร และกันไม่ให้ถูกแก้บน Google Cloud\u002FAzure","\u003Cp>ตอนสร้าง log bucket ใหม่บน Google Cloud มีช่องหนึ่งให้กรอกว่าจะเก็บ log ไว้กี่วัน ถ้าไม่กรอก เอกสารของ Google Cloud ระบุว่าค่าเริ่มต้นคือ 30 วัน และ log ที่พ้นระยะเวลาเก็บแล้วจะกู้คืนไม่ได้ ตัวเลขในช่องนี้จึงกำหนดทั้งค่าใช้จ่ายรายเดือน ความสามารถในการสืบย้อนเหตุการณ์ และภาระด้านข้อมูลส่วนบุคคลไปพร้อมกัน\u003C\u002Fp>\u003Cp>สมมติว่าทีมปล่อยค่าเริ่มต้นไว้ก่อน แล้วตั้งใจจะกลับมาแก้ทีหลัง วันที่ผู้ตรวจสอบภายในขอ audit trail ของสี่เดือนก่อน ทีมจะพบว่าข้อมูลช่วงนั้นไม่มีอยู่แล้ว และไม่มีปุ่มไหนเรียกกลับมาได้\u003C\u002Fp>\u003Cp>บทความนี้เล่าว่าเราคิดเรื่องระยะเวลาเก็บ log อย่างไรเมื่อออกแบบระบบ ตั้งแต่การแยกประเภท log ตามจุดประสงค์ ข้อกำหนดตามกฎหมายไทยที่เราอ่านจากตัวบท การป้องกันไม่ให้ log ถูกแก้ ไปจนถึงต้นทุนและข้อมูลส่วนบุคคลที่ซ่อนอยู่ใน log บทความนี้ไม่ใช่คำแนะนำทางกฎหมาย คำถามว่าองค์กรของคุณมีหน้าที่ตามกฎหมายหรือไม่ ควรตอบโดยที่ปรึกษากฎหมายขององค์กร\u003C\u002Fp>\u003Ch2>log สามแบบ เก็บด้วยเหตุผลคนละข้อ\u003C\u002Fh2>\u003Cp>ข้อผิดพลาดที่เราระวังตั้งแต่ต้นคือการตั้งระยะเวลาเก็บ log เพียงค่าเดียวให้ทุกอย่าง ทั้งที่ log แต่ละประเภทตอบคำถามต่างกัน และมีคนใช้งานต่างกลุ่มกัน\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>\u003Cstrong>Operational log หรือ debug log\u003C\u002Fstrong> ใช้ตอบว่าระบบทำงานผิดพลาดตรงไหน เช่น error, stack trace หรือเวลาตอบสนองของ API ข้อมูลกลุ่มนี้มีปริมาณมากที่สุด และมักหมดประโยชน์เร็วที่สุด เมื่อแก้ปัญหาเสร็จแล้วแทบไม่มีใครย้อนกลับไปดู\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>Security log\u003C\u002Fstrong> ใช้ตอบว่าใครพยายามเข้าถึงอะไร สำเร็จหรือถูกปฏิเสธ เช่น การ log-in, การเปลี่ยนสิทธิ์ และการเชื่อมต่อจากเครือข่ายภายนอก กลุ่มนี้ต้องเก็บนานพอให้สืบย้อนเหตุการณ์ได้ เพราะวันที่พบความผิดปกติกับวันที่เกิดเหตุจริงไม่จำเป็นต้องเป็นวันเดียวกัน\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>Audit trail\u003C\u002Fstrong> ใช้ตอบว่าใครเปลี่ยนอะไร เมื่อไร จากค่าเดิมเป็นค่าอะไร เช่น การอนุมัติรายการ การแก้ข้อมูลหลัก หรือการเปลี่ยนการตั้งค่าระบบ กลุ่มนี้คือหลักฐาน จึงต้องเชื่อถือได้มากกว่าจะค้นหาได้เร็ว\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>เมื่อแยกสามกลุ่มนี้ออกจากกันตั้งแต่ต้นทาง การตั้งระยะเวลาเก็บจะง่ายขึ้นมาก Operational log อาจเก็บสั้น ส่วน audit trail อาจต้องเก็บนานตามนโยบายภายในหรือข้อกำหนดของหน่วยงานกำกับ\u003C\u002Fp>\u003Cp>บทความนี้ไม่ได้พูดถึงการออกแบบ alert จาก log ซึ่งเราเขียนไว้แล้วใน\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fblogs\u002Fmonitoring-alerting-what-to-page-on\">บทความเรื่อง monitoring และ alert\u003C\u002Fa> และไม่ได้ลงรายละเอียด audit log ของ AI Agent ซึ่งอยู่ใน\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fblogs\u002Fai-agent-readiness-before-system-access\">บทความเรื่องด่านก่อนให้ AI Agent เข้าถึงระบบจริง\u003C\u002Fa>\u003C\u002Fp>\u003Ch2>พ.ร.บ.คอมพิวเตอร์ให้เก็บ log กี่วัน และใช้กับใคร\u003C\u002Fh2>\u003Cp>ข้อกำหนดหลักอยู่ในมาตรา 26 ของพระราชบัญญัติว่าด้วยการกระทำความผิดเกี่ยวกับคอมพิวเตอร์ พ.ศ. 2550 ซึ่งวรรคหนึ่งแก้ไขเพิ่มเติมโดยพระราชบัญญัติฉบับที่ 2 พ.ศ. 2560 เราอ่านตัวบทจาก\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.etda.or.th\u002Fgetattachment\u002Fe3c8aef2-00ce-4c91-abea-fef02fc7f07c\u002FComputer-Crimes-Act-BE-2550-and-BE-2560.aspx\">ฉบับที่ สพธอ. (ETDA) เผยแพร่\u003C\u002Fa> ซึ่งรวมการแก้ไขทั้งสองฉบับไว้และอ้างอิงราชกิจจานุเบกษา\u003C\u002Fp>\u003Cp>ตัวบทกำหนดให้ผู้ให้บริการเก็บรักษาข้อมูลจราจรทางคอมพิวเตอร์ไว้ไม่น้อยกว่า 90 วัน นับแต่วันที่ข้อมูลเข้าสู่ระบบคอมพิวเตอร์ ในกรณีจำเป็น พนักงานเจ้าหน้าที่สั่งให้ผู้ให้บริการรายใดเก็บเกิน 90 วันได้ แต่ไม่เกินสองปี เป็นกรณีพิเศษเฉพาะรายและเฉพาะคราว\u003C\u002Fp>\u003Cp>วรรคสองของมาตราเดียวกันกำหนดให้ผู้ให้บริการเก็บข้อมูลผู้ใช้บริการเท่าที่จำเป็นเพื่อระบุตัวผู้ใช้บริการได้ นับตั้งแต่เริ่มใช้บริการ และเก็บต่อไม่น้อยกว่า 90 วันหลังการใช้บริการสิ้นสุดลง วรรคสามระบุว่าวรรคหนึ่งจะใช้กับผู้ให้บริการประเภทใด อย่างไร และเมื่อใด ให้เป็นไปตามที่รัฐมนตรีประกาศในราชกิจจานุเบกษา ส่วนวรรคสุดท้ายระบุว่าผู้ให้บริการที่ไม่ปฏิบัติตามมาตรานี้ต้องระวางโทษปรับไม่เกินห้าแสนบาท\u003C\u002Fp>\u003Cp>คำที่ต้องอ่านให้ละเอียดคือ \"ผู้ให้บริการ\" ซึ่งมาตรา 3 นิยามไว้สองกลุ่ม กลุ่มแรกคือผู้ให้บริการแก่บุคคลอื่นในการเข้าสู่อินเทอร์เน็ตหรือติดต่อถึงกันผ่านระบบคอมพิวเตอร์ ไม่ว่าในนามของตนเองหรือเพื่อประโยชน์ของบุคคลอื่น กลุ่มที่สองคือผู้ให้บริการเก็บรักษาข้อมูลคอมพิวเตอร์เพื่อประโยชน์ของบุคคลอื่น เมื่ออ่านตามนิยามนี้ หน้าที่ตามมาตรา 26 จึงผูกกับบทบาทผู้ให้บริการ ไม่ได้เขียนไว้ให้ใช้กับทุกองค์กรที่มีระบบคอมพิวเตอร์\u003C\u002Fp>\u003Cp>รายละเอียดว่าผู้ให้บริการประเภทใดต้องเก็บอะไร อยู่ใน\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fpub.nstda.or.th\u002Fgov-dx\u002Fwp-content\u002Fuploads\u002F2021\u002F08\u002FT_0009.pdf\">ประกาศกระทรวงดิจิทัลเพื่อเศรษฐกิจและสังคม เรื่อง หลักเกณฑ์การเก็บรักษาข้อมูลจราจรทางคอมพิวเตอร์ของผู้ให้บริการ พ.ศ. 2564\u003C\u002Fa> ซึ่งลงราชกิจจานุเบกษาเมื่อ 13 สิงหาคม 2564 และยกเลิกประกาศฉบับปี 2550 ข้อ 5 ของประกาศแบ่งผู้ให้บริการออกเป็นหลายประเภท และภาคผนวก ก ยกตัวอย่างไว้ เช่น ผู้ให้บริการอินเทอร์เน็ต ผู้ให้บริการ Web Hosting ผู้ให้บริการคลาวด์ที่ให้บริการโดยตรงกับผู้ใช้งาน และผู้ให้บริการดิจิทัลหลายสาขา\u003C\u002Fp>\u003Cp>ตัวอย่างหนึ่งในภาคผนวก ก ที่ทีม IT ขององค์กรควรรู้คือ \"ผู้ให้บริการเข้าถึงระบบเครือข่ายคอมพิวเตอร์สำหรับองค์กร เช่น หน่วยงานราชการ บริษัท หรือสถาบันการศึกษา\" องค์กรที่เปิดเครือข่ายให้พนักงานหรือนักศึกษาใช้อินเทอร์เน็ต จึงอาจอยู่ในขอบเขตนี้ได้ แต่องค์กรของคุณเข้าข่ายประเภทใด หรือไม่เข้าข่ายเลย เป็นคำถามที่ต้องให้ที่ปรึกษากฎหมายตีความจากลักษณะบริการจริง\u003C\u002Fp>\u003Cp>ข้อ 12 ของประกาศกำหนดระยะเวลาสอดคล้องกับตัวบท คือกรณีทั่วไปไม่น้อยกว่า 90 วันนับแต่ข้อมูลเข้าสู่ระบบ และกรณีจำเป็นตามเงื่อนไขที่ระบุ พนักงานเจ้าหน้าที่สั่งให้เก็บต่อได้คราวละไม่เกินหกเดือนต่อเนื่องกัน แต่ต้องไม่เกินสองปี สังเกตว่ากฎหมายกำหนด \"ขั้นต่ำ\" ไว้ ไม่ได้บอกว่าเก็บนานเท่าไรจึงเหมาะกับระบบของคุณ\u003C\u002Fp>\u003Ch2>log ที่ผู้ดูแลระบบแก้ได้ ใช้เป็นหลักฐานได้ยาก\u003C\u002Fh2>\u003Cp>ข้อ 9 ของประกาศฉบับเดียวกันกำหนดวิธีเก็บที่มั่นคงปลอดภัยไว้หลายข้อ ข้อที่ตรงกับงานออกแบบระบบมากที่สุดคือ ต้องเก็บในสื่อหรือระบบที่รักษาความครบถ้วนถูกต้องของข้อมูล และระบุตัวบุคคลที่เข้าถึงได้ รวมถึงต้องไม่ให้ผู้ดูแลระบบแก้ไขข้อมูลที่เก็บไว้ได้ ประกาศยกตัวอย่างวิธีไว้ เช่น Centralized Log Server, Data Archiving หรือ Data Hashing\u003C\u002Fp>\u003Cp>ต่อให้องค์กรของคุณไม่เข้าข่ายผู้ให้บริการ หลักข้อนี้ก็ใช้กับ audit trail ได้ตรง ๆ ถ้าคนที่มีสิทธิ์ admin บนระบบหลักลบหรือแก้ log ได้ด้วยบัญชีเดียวกัน log ชุดนั้นพิสูจน์อะไรได้น้อยมากในวันที่ต้องใช้จริง\u003C\u002Fp>\u003Cp>การแยกสิทธิ์จึงสำคัญกว่าการเลือกเครื่องมือ\u003C\u002Fp>\u003Cp>แนวทางที่เราใช้บ่อยคือส่ง log ออกไปเก็บใน project หรือ subscription แยกจากระบบหลัก ให้คนละกลุ่มถือสิทธิ์ แล้วเปิดคุณสมบัติกันแก้ไขของ cloud provider\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>บน Google Cloud เอกสาร \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fdocs.cloud.google.com\u002Flogging\u002Fdocs\u002Fbuckets\">Cloud Logging buckets\u003C\u002Fa> ระบุว่ากำหนด retention แบบกำหนดเองได้ตั้งแต่ 1 ถึง 3650 วัน และล็อก bucket ได้ การล็อกนี้ย้อนกลับไม่ได้ เมื่อล็อกแล้วจะแก้ไข bucket และ retention policy ไม่ได้ และจะลบ bucket ได้ก็ต่อเมื่อ log ทุกรายการครบระยะเวลาเก็บแล้ว\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>บน Microsoft Azure เอกสาร \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fstorage\u002Fblobs\u002Fimmutable-storage-overview\">Immutable storage for Blob Storage\u003C\u002Fa> อธิบายการเก็บแบบ WORM (Write Once, Read Many) ที่ข้อมูลแก้หรือลบไม่ได้ตลอดช่วงเวลาที่กำหนด เมื่อล็อก time-based retention policy แล้วจะลบ policy ไม่ได้ ขยายระยะเวลาได้แต่ลดไม่ได้\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>ข้อ 11 ของประกาศยังกำหนดให้ตั้งนาฬิกาของอุปกรณ์ให้ตรงกับเวลาอ้างอิงสากล เรื่องนี้ดูเล็ก แต่ audit trail ที่เวลาของแต่ละเครื่องเหลื่อมกันไม่กี่นาที ทำให้เรียงลำดับเหตุการณ์ข้ามระบบไม่ได้ เราจึงตรวจการ sync เวลาเป็นรายการแรก ๆ ก่อนเชื่อมระบบใดเข้ากับ log กลาง\u003C\u002Fp>\u003Ch2>ต้นทุนของการเก็บนาน และการแบ่งชั้นข้อมูล\u003C\u002Fh2>\u003Cp>การเก็บ log นานมีต้นทุนจริง เอกสาร Cloud Logging ระบุว่าตั้งแต่ 1 เมษายน 2566 มีค่าใช้จ่ายด้าน retention สำหรับ log ที่เก็บนานกว่าระยะเวลาเริ่มต้นของ bucket _Default และ bucket ที่ผู้ใช้สร้างเอง ตัวเลขเรตควรเช็คจากหน้า pricing ปัจจุบันของผู้ให้บริการ เพราะเปลี่ยนได้\u003C\u002Fp>\u003Cp>ฝั่ง Azure เอกสาร immutable storage ระบุว่าการเปิด immutability ไม่มีค่าความจุเพิ่ม ข้อมูลคิดราคาเหมือนข้อมูลปกติ และ access tier ทุกระดับของ blob รองรับ immutable storage แนวทางที่เราพิจารณาจึงเป็นการแบ่งชั้นตามอายุของ log เก็บ log ช่วงล่าสุดไว้ในที่ค้นหาได้เร็ว แล้วย้าย log ที่เก่ากว่าไปยัง tier ที่ค่าเก็บต่ำกว่า แต่แลกกับค่าเข้าถึงหรือเวลาเรียกคืนที่สูงกว่า\u003C\u002Fp>\u003Cp>ข้อเสียที่ต้องพูดให้ชัดคือ การล็อก log แบบย้อนกลับไม่ได้ทำให้แก้ความผิดพลาดของตัวเองไม่ได้เช่นกัน ถ้าตั้ง retention ยาวเกินไป หรือเผลอส่งข้อมูลที่ไม่ควรเก็บเข้า bucket ที่ล็อกแล้ว คุณต้องจ่ายค่าเก็บและถือข้อมูลนั้นไว้จนครบกำหนด ถ้าองค์กรของคุณไม่เข้าข่ายผู้ให้บริการ และระบบนั้นมีผู้ใช้ภายในไม่กี่สิบคนโดยไม่มีธุรกรรมที่ต้องพิสูจน์ย้อนหลัง การแยก account พร้อมจำกัดสิทธิ์ลบอาจเพียงพอแล้ว โดยยังไม่ต้องล็อกถาวร\u003C\u002Fp>\u003Ch2>ข้อมูลส่วนบุคคลที่ซ่อนอยู่ใน log\u003C\u002Fh2>\u003Cp>ข้อ 9 (4) ของประกาศกำหนดว่าการเก็บข้อมูลจราจรต้องระบุรายละเอียดผู้ใช้บริการเป็นรายบุคคลได้ ขณะเดียวกัน log ที่ระบุตัวคนได้ก็คือชุดข้อมูลส่วนบุคคลอีกชุดหนึ่งขององค์กร เราจึงออกแบบให้ log เก็บเฉพาะสิ่งที่ต้องใช้ และไม่ให้ข้อมูลอ่อนไหวหลุดเข้าไปโดยไม่ตั้งใจ\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>ไม่ log ค่าในฟอร์มทั้งก้อน เช่น request body ที่มีเลขบัตรประชาชน เบอร์โทร หรือรหัสผ่าน ให้ log เฉพาะรหัสอ้างอิงของรายการ\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>mask ข้อมูลตั้งแต่ตอนเขียน log ไม่รอไปลบทีหลัง เพราะเมื่อข้อมูลเข้า bucket ที่ล็อกแล้ว จะลบออกไม่ได้จนกว่าจะครบกำหนด\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>แยกตารางจับคู่ user ID กับตัวบุคคลไว้ในที่ที่สิทธิ์เข้มกว่า log ทั่วไป คนที่ debug ระบบจะเห็นแค่รหัส ส่วนคนที่ต้องสืบสวนจริงจะขอสิทธิ์ดูการจับคู่ได้ตามขั้นตอน\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>ระยะเวลาเก็บ log ที่มีข้อมูลส่วนบุคคลควรผ่านการทบทวนของ DPO หรือที่ปรึกษากฎหมายด้าน PDPA ขององค์กรด้วย เพราะการเก็บนานกว่าที่จำเป็นก็เป็นความเสี่ยงอีกด้านหนึ่ง\u003C\u002Fp>\u003Ch2>ข้อโต้แย้งที่ได้ยินบ่อย\u003C\u002Fh2>\u003Cp>ข้อโต้แย้งแรกคือ เก็บทุกอย่างไว้ให้นานที่สุดน่าจะปลอดภัยที่สุด ข้อนี้ฟังดูรอบคอบ แต่ log ที่ไม่มีใครกำหนดจุดประสงค์ไว้ มักไม่มีใครค้นเจอในวันที่ต้องใช้ และยังเพิ่มทั้งค่าเก็บกับปริมาณข้อมูลส่วนบุคคลที่องค์กรต้องรับผิดชอบ เราเลือกกำหนดระยะเวลาต่อประเภท log แล้วเขียนเหตุผลของแต่ละค่าไว้ในเอกสาร\u003C\u002Fp>\u003Cp>ข้อโต้แย้งที่สองคือ cloud provider เก็บ log ให้อยู่แล้ว ข้อนี้จริงเพียงบางส่วน เอกสาร Azure เองระบุว่า resource log ที่เก็บข้อมูลการทำงานกับข้อมูล เป็นความรับผิดชอบของผู้ใช้ที่ต้องจัดเก็บให้คงอยู่ตามที่ข้อกำหนดต้องการ ค่าเริ่มต้นของแต่ละ provider จึงเป็นเพียงจุดตั้งต้น ไม่ใช่นโยบายขององค์กร\u003C\u002Fp>\u003Ch2>จะเริ่มตรงไหน\u003C\u002Fh2>\u003Col>\u003Cli>\u003Cp>ทำรายการ log ที่ระบบสร้างขึ้นจริง แล้วจัดเข้าสามกลุ่ม คือ operational, security และ audit trail พร้อมระบุว่าใครเป็นคนใช้ log แต่ละกลุ่ม\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ถามที่ปรึกษากฎหมายว่าองค์กรหรือบริการใดของคุณเข้าข่าย \"ผู้ให้บริการ\" ตามมาตรา 3 และประกาศปี 2564 หรือไม่ แล้วบันทึกคำตอบไว้เป็นลายลักษณ์อักษร\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>กำหนด retention ของแต่ละกลุ่ม โดยใช้ข้อกำหนดทางกฎหมายเป็นขั้นต่ำ และเหตุผลทางธุรกิจเป็นตัวกำหนดส่วนที่เกิน\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ย้าย security log และ audit trail ไปเก็บใน project หรือ subscription แยก ทดสอบ retention ให้แน่ใจก่อน แล้วจึงล็อก\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ตรวจว่า log ไม่มีข้อมูลส่วนบุคคลที่ไม่จำเป็น และนาฬิกาของทุกเครื่อง sync กับเวลาอ้างอิงเดียวกัน\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Fol>\u003Cp>ถ้าอยู่ระหว่างร่าง TOR ระบบใหม่ ให้เขียนข้อกำหนดเรื่อง retention และการกันแก้ไข log ลงไปตั้งแต่รอบแรก แนวคิดเรื่องการเขียนเงื่อนไขแบบนี้อยู่ใน\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fblogs\u002Ftor-conditions-for-a-maintainable-system\">บทความเรื่องการเขียน TOR ให้ได้ระบบที่ดูแลต่อได้\u003C\u002Fa>\u003C\u002Fp>\u003Ch2>สรุป\u003C\u002Fh2>\u003Cp>คำถามว่าต้องเก็บ log นานแค่ไหน ไม่มีตัวเลขเดียวที่ถูกสำหรับทุกระบบ กฎหมายกำหนดขั้นต่ำไว้สำหรับผู้ให้บริการตามนิยาม ส่วนที่เหลือเป็นการตัดสินใจขององค์กรเรื่องหลักฐาน ต้นทุน และข้อมูลส่วนบุคคล ถ้าจะหยิบไปใช้เพียงข้อเดียว ให้แยก audit trail ออกจาก log ทั่วไป แล้วเก็บไว้ในที่ที่ผู้ดูแลระบบหลักแก้ไม่ได้\u003C\u002Fp>\u003Cp>หากต้องการคุยเรื่องการวางโครงสร้าง log บน Google Cloud หรือ Microsoft Azure ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล contact@superdev.tech สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ เรายินดีคุยเพื่อทำความเข้าใจระบบที่คุณมีอยู่ก่อน โดยยังไม่ต้องมีเอกสารครบ ส่วนคำถามด้านการตีความกฎหมาย เราจะแนะนำให้ปรึกษาที่ปรึกษากฎหมายขององค์กรเสมอ ดูข้อมูลเพิ่มเติมเกี่ยวกับเราได้ที่ \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\">superdev.tech\u003C\u002Fa>\u003C\u002Fp>","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fpbc_2128795511\u002Feeaixj8llywa8zs\u002Fcover_cover_a8wvoazfc6.webp","30 กันยายน 2569","2026-09-30 06:20:05.854Z",116,"Enterprise","enterprise","log-retention-audit-trail-thailand","\u002Fblogs\u002Flog-retention-audit-trail-thailand",3,false,0,"",[47,48,49,50,51,52,53],"log retention","audit trail","เก็บ log ตาม พ.ร.บ.คอมพิวเตอร์","เก็บ log 90 วัน","ข้อมูลจราจรทางคอมพิวเตอร์","immutable log","PDPA"]