วิธี Audit Data Breach ของเว็บไซต์ธุรกิจทั่วไปและ SME พร้อม Evidence ที่ควรเก็บ

ทีมไอทีของธุรกิจ SME แห่งหนึ่งถูกถามในที่ประชุมว่า "ถ้าเกิด Data Breach ขึ้นพรุ่งนี้ เรามีหลักฐานอะไรบ้างที่จะบอกได้ว่าเกิดอะไรขึ้น" คำตอบที่ได้คือความเงียบ เพราะไม่เคยมีใคร Audit ระบบเก็บข้อมูลอย่างเป็นระบบมาก่อน มีแต่ความรู้สึกว่า "น่าจะโอเค"

การ Audit Data Breach ที่ใช้งานได้จริงต้องมากกว่าความรู้สึก ต้องมี Evidence ที่จับต้องได้ประกอบทุกข้อสรุป บทความนี้วางขั้นตอน Audit แบบที่เว็บไซต์ SME ทำได้เอง พร้อมตัวอย่าง Evidence ที่ควรเก็บในแต่ละจุด

ขั้นตอนที่ 1: ไล่ Data Flow ตั้งแต่จุดเก็บถึงจุดจัดเก็บ

เริ่มจากไล่เส้นทางข้อมูลจริงของเว็บไซต์ ตั้งแต่ฟอร์มที่ผู้ใช้กรอก ไปจนถึงระบบที่เก็บข้อมูลนั้นไว้ถาวร ระหว่างทางอาจผ่านหลายจุด เช่น ปลั๊กอินฟอร์ม ระบบอีเมลแจ้งเตือน ฐานข้อมูลหลัก และบริการภายนอกที่เชื่อมต่อผ่าน API หรือ Webhook

จุดในเส้นทางข้อมูล	คำถามที่ต้องตอบระหว่าง Audit	Evidence ที่ควรเก็บ
ฟอร์มหน้าเว็บไซต์	เก็บข้อมูลอะไรบ้าง มีการยืนยันตัวตนหรือไม่	ภาพหน้าจอฟอร์มพร้อมรายการฟิลด์
ปลั๊กอิน/บริการภายนอก	ข้อมูลถูกส่งไปที่ใด มีสัญญาประมวลผลข้อมูลหรือไม่	รายชื่อ Vendor และเอกสารเงื่อนไขการใช้งาน
ฐานข้อมูลหลัก	ใครมีสิทธิ์เข้าถึงได้บ้าง	รายการบัญชีผู้ดูแลระบบและระดับสิทธิ์
Backup/Export	เก็บไว้ที่ใด เข้ารหัสหรือไม่	นโยบายการสำรองข้อมูลและตำแหน่งจัดเก็บ

ขั้นตอนที่ 2: ตรวจ Timing ของ Tracking Script เทียบกับ Consent

หนึ่งใน Finding ที่พบบ่อยที่สุดในการ Audit เว็บไซต์ SME คือ Tracking Script ที่ทำงานก่อนผู้ใช้กดยินยอมผ่าน Cookie Consent Banner ผู้ตรวจควรทดสอบด้วยการโหลดหน้าเว็บไซต์แบบ Session ใหม่ ไม่กด Accept แล้วเปิด Developer Tools ดู Network Request ว่ามี Pixel หรือ Analytics ยิงออกไปก่อนหรือไม่

Evidence ที่เก็บได้จากขั้นตอนนี้

• ภาพหน้าจอ Network Request ก่อนกด Accept
• รายชื่อ Script ที่พบพร้อม Provider และ Category
• ผลทดสอบซ้ำหลังกด Reject All ว่า Script หยุดทำงานจริงหรือไม่

ขั้นตอนที่ 3: ตรวจสิทธิ์การเข้าถึงและร่องรอยการใช้งาน

สิทธิ์การเข้าถึงฐานข้อมูลและระบบหลังบ้านคือจุดที่ Automated Scan ภายนอกมองไม่เห็น เพราะสแกนภายนอกตรวจได้เฉพาะสิ่งที่เปิดเผยต่อสาธารณะ ผู้ Audit ต้องขอรายการบัญชีผู้ใช้จากทีมพัฒนาหรือผู้ดูแลระบบโดยตรง แล้วตรวจว่าบัญชีที่มีสิทธิ์สูงสุดตรงกับผู้ที่ยังทำงานอยู่จริงหรือไม่

• รายชื่อบัญชีที่มีสิทธิ์ Admin หรือเข้าถึงฐานข้อมูลได้โดยตรง
• วันที่ตั้งบัญชีและวันที่ใช้งานล่าสุด
• บันทึกว่าบัญชีของพนักงานที่ลาออกถูกปิดเมื่อใด

ขั้นตอนที่ 4: ตรวจ Vendor และ Cross-domain

เว็บไซต์ SME ส่วนใหญ่พึ่งพา Vendor ภายนอกหลายราย ตั้งแต่ระบบชำระเงิน ระบบแชท ไปจนถึงระบบอีเมลการตลาด การ Audit ต้องตรวจว่าข้อมูลถูกส่งข้าม Domain หรือส่งให้ Vendor รายใดบ้าง และ Vendor แต่ละรายมีเอกสารรับรองการประมวลผลข้อมูล (Data Processing Terms) หรือไม่ ถ้าไม่มีเอกสารดังกล่าว ควรบันทึกไว้เป็น Finding ที่ต้องติดตามกับ Vendor โดยตรง ไม่ใช่ข้อสรุปว่า Vendor ทำผิด

ขั้นตอนที่ 5: สรุปเป็น Finding ที่มี Evidence กำกับ

ทุก Finding ที่ได้จากการ Audit ควรเขียนตามโครงสร้างเดียวกัน เพื่อให้ทีมอื่นอ่านแล้วดำเนินการต่อได้ทันทีโดยไม่ต้องถามซ้ำ

Finding → Evidence → Why It Matters → Priority → Recommended Fix → Owner → Verification → Limitation

ตัวอย่างเช่น หากพบว่า Pixel การตลาดยิงก่อน Consent Finding ควรเขียนว่า "พบ Pixel ของผู้ให้บริการโฆษณายิง Request ก่อนผู้ใช้กด Accept (Evidence: ภาพ Network Log วันที่ตรวจ) ความเสี่ยงคือข้อมูลพฤติกรรมถูกส่งออกก่อนได้รับความยินยอม (Why It Matters) ควรแก้ไขโดยย้าย Script ไปอยู่หลัง Consent Trigger (Fix) มอบหมายให้ทีมพัฒนาเป็นผู้แก้ (Owner) และทดสอบซ้ำหลังแก้ไข (Verification)"

ใครควรมีส่วนร่วมในการ Audit

การ Audit Data Breach ที่ครอบคลุมจริงต้องอาศัยข้อมูลจากมากกว่าหนึ่งทีม เพราะแต่ละทีมเห็นเส้นทางข้อมูลคนละส่วน หากให้คนเดียวทำทั้งหมด ผลลัพธ์มักตกหล่นจุดที่ตัวเองไม่คุ้นเคย

บทบาท	ข้อมูลที่ควรให้
เจ้าของกิจการ/ผู้จัดการ	ภาพรวมกระบวนการทางธุรกิจที่เกี่ยวข้องกับข้อมูลลูกค้า และผู้รับผิดชอบแต่ละขั้นตอน
ทีมการตลาด	รายชื่อ Tracking Script, Pixel และเครื่องมือการตลาดที่ติดตั้งไว้บนเว็บไซต์
ทีมพัฒนา/ผู้ดูแลเว็บไซต์	สิทธิ์การเข้าถึงระบบ โครงสร้างฐานข้อมูล และนโยบายการสำรองข้อมูล
ทีมขาย/บริการลูกค้า	วิธีการรับส่งข้อมูลลูกค้านอกเว็บไซต์ เช่น ไฟล์ Excel หรือแชท

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

การจัดลำดับความสำคัญของ Finding ที่พบระหว่าง Audit

เมื่อ Audit เสร็จแล้วมักพบ Finding จำนวนมาก การไล่แก้ทีละข้อตามลำดับที่พบไม่ใช่วิธีที่มีประสิทธิภาพ ควรจัดลำดับตามความเสี่ยงจริงก่อน โดยให้น้ำหนักกับประเด็นที่กระทบข้อมูลอ่อนไหวหรือ Tracking ที่ทำงานก่อน Consent เป็นอันดับต้น ๆ ก่อนไปแก้ประเด็นที่เป็นเพียงความเรียบร้อยของเอกสาร

• ลำดับแรก: ข้อมูลอ่อนไหวหรือความเสี่ยงทางกฎหมายที่ชัดเจน เช่น ฐานข้อมูลเปิดสาธารณะโดยไม่ตั้งใจ
• ลำดับถัดมา: Tracking Script ที่ทำงานก่อน Consent
• ลำดับรองลงมา: สิทธิ์การเข้าถึงที่ไม่ได้ปิดตามรอบพนักงานลาออก
• ลำดับท้ายสุด: ความไม่สอดคล้องของเอกสาร Policy กับสิ่งที่ตรวจพบจริง

คะแนนหรือผลสแกนต่ำในโมดูลใดโมดูลหนึ่งไม่ได้แปลว่าต้องเป็นงานแรกเสมอไป Finding ที่กระทบข้อมูลอ่อนไหวหรือความเสี่ยงทางกฎหมายควรมาก่อนเสมอ แม้จะไม่ใช่จุดที่ทำให้คะแนนรวมต่ำที่สุดก็ตาม

เครื่องมือที่ช่วยให้ Audit ทำได้เร็วขึ้น

trusty มีโมดูล PDPA Readiness Scan และ Website Trust Scan ที่ช่วยตรวจ Policy, Banner, ทางเลือก Reject และ Tracking Script บางส่วนได้อัตโนมัติ ซึ่งช่วยลดเวลาช่วงต้นของการ Audit ได้มาก แต่ผลสแกนเป็นเพียงจุดเริ่มต้น ทีมยังต้องไปเก็บ Evidence ส่วนที่สแกนภายนอกมองไม่เห็นด้วยตัวเอง เช่น สิทธิ์การเข้าถึงหลังบ้านหรือสัญญากับ Vendor

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

ข้อจำกัดของการ Audit ด้วยทีมภายใน

การ Audit ตามขั้นตอนนี้ช่วยให้เห็นความเสี่ยงพื้นฐานที่ตรวจสอบได้จากภายนอกและจากข้อมูลที่ทีมงานให้มา แต่ไม่เท่ากับ Security Audit เชิงลึกหรือความเห็นทางกฎหมาย ธุรกิจที่มีข้อมูลอ่อนไหว เช่น ข้อมูลสุขภาพหรือข้อมูลทางการเงินจำนวนมาก ควรให้ผู้เชี่ยวชาญด้าน Security และฝ่ายกฎหมายตรวจเพิ่มเติมในจุดที่ทีมภายในไม่มีความเชี่ยวชาญเฉพาะทาง

การเก็บรายงาน Audit ให้ตรวจสอบย้อนหลังได้

รายงาน Audit ที่เขียนเสร็จแล้วเก็บไว้เฉยๆ มีประโยชน์น้อยกว่าที่ควร รายงานนี้ควรถูกจัดเก็บในรูปแบบที่ทีมสามารถเปิดดูย้อนหลังได้ทุกเมื่อ และเทียบกับรอบ Audit ก่อนหน้าได้ว่า Finding เดิมถูกแก้ไขแล้วหรือยังเกิดซ้ำ

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

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

ความแตกต่างระหว่าง Audit ภายในกับการตรวจโดยผู้เชี่ยวชาญภายนอก

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

คำถามที่พบบ่อย

เริ่มต้น Audit Data Breach ของเว็บไซต์ SME ควรทำอะไรก่อน

ควรเริ่มจากการไล่ Data Flow ของเว็บไซต์ตั้งแต่จุดที่เก็บข้อมูลไปจนถึงจุดจัดเก็บถาวร เพื่อรู้ว่าข้อมูลผ่านระบบใดบ้างก่อนไปตรวจจุดอื่น

Evidence แบบไหนที่ควรเก็บระหว่างการ Audit

ควรเก็บภาพหน้าจอการตั้งค่า Consent รายการสิทธิ์เข้าถึงระบบ บันทึก Network Request ของ Tracking Script และเอกสารเงื่อนไขการใช้งานจาก Vendor ที่เชื่อมต่อกับเว็บไซต์

การ Audit ด้วยทีมภายในเทียบเท่า Security Audit เชิงลึกหรือไม่

ไม่เทียบเท่า การ Audit ตามขั้นตอนนี้ช่วยเห็นความเสี่ยงพื้นฐาน แต่ธุรกิจที่มีข้อมูลอ่อนไหวควรให้ผู้เชี่ยวชาญด้าน Security และฝ่ายกฎหมายตรวจเพิ่มเติม

ควร Audit Data Breach บ่อยแค่ไหน

ควร Audit ทุกครั้งที่มีการเปลี่ยนแปลงระบบสำคัญ เช่น เปลี่ยน Vendor เพิ่มฟีเจอร์ใหม่ หรืออย่างน้อยทุก 6 เดือนตามรอบทบทวนที่กำหนดไว้

เช็กลิสต์ปฏิบัติ

• ไล่ Data Flow ของเว็บไซต์ตั้งแต่จุดเก็บถึงจุดจัดเก็บถาวร และวาดเป็นแผนภาพอย่างง่าย
• ทดสอบ Tracking Script ด้วย Session ใหม่ก่อนและหลังกด Accept/Reject
• ขอรายชื่อบัญชีที่มีสิทธิ์ Admin จากทีมพัฒนา และตรวจว่าตรงกับพนักงานที่ยังทำงานอยู่
• รวบรวมเอกสารเงื่อนไขการใช้งานจาก Vendor ภายนอกที่เชื่อมต่อกับเว็บไซต์
• เขียน Finding ทุกข้อตามโครงสร้าง Evidence, Priority, Fix, Owner, Verification
• บันทึกวันที่ Audit และกำหนดรอบ Audit ครั้งถัดไป

ข้อผิดพลาดที่พบบ่อย

• สรุป Finding โดยไม่มี Evidence แนบ ทำให้ทีมอื่นตรวจสอบซ้ำไม่ได้
• Audit เฉพาะสิ่งที่มองเห็นจากหน้าเว็บไซต์ โดยไม่ขอข้อมูลสิทธิ์เข้าถึงจากทีมพัฒนา
• ทดสอบ Tracking Script เพียงครั้งเดียวโดยไม่ทดสอบซ้ำหลัง Reject All
• ไม่บันทึกวันที่ Audit ทำให้ไม่รู้ว่าผลตรวจล่าสุดยังใช้ได้อยู่หรือไม่

สรุป

การ Audit Data Breach ที่ใช้งานได้จริงต้องมี Evidence กำกับทุกข้อสรุป ไม่ใช่ความรู้สึกว่าเว็บไซต์น่าจะปลอดภัย ทีมงาน SME ควรไล่ Data Flow ตรวจ Timing ของ Tracking Script ตรวจสิทธิ์เข้าถึง และตรวจ Vendor อย่างเป็นระบบ แล้วสรุปเป็น Finding ที่ตรวจสอบซ้ำได้ ดูภาพรวมทั้งหมวดได้ที่ คู่มือ Data Breach สำหรับ SME และเช็กลิสต์ก่อนเปิดใช้งานที่ เช็กลิสต์ Data Breach สำหรับ SME

แหล่งข้อมูลอ้างอิง

• สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC)