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

ทีมเอเจนซีและฟรีแลนซ์ที่ดูแลเว็บไซต์ให้ลูกค้าหลายรายมักไม่มีปัญหาเรื่องกระบวนการรับมือ data breach จนกว่าจะเจอเหตุการณ์จริง ปัญหาที่เกิดซ้ำในเคสจริงคือ เมื่อปลั๊กอิน WordPress หรือระบบ e-commerce ของลูกค้าโดนเจาะและฐานข้อมูลลูกค้าปลายทางหลุดออกไป ทีมงานถึงจะพบว่าไม่มีใครรู้ชัดว่าต้องเก็บหลักฐานอะไรก่อน ใครในทีมต้องรับผิดชอบแจ้งลูกค้าภายในกี่ชั่วโมง และสัญญาที่เซ็นไว้เขียนขอบเขตความรับผิดเรื่องข้อมูลไว้อย่างไร

บทความนี้เป็นแนวทาง audit กระบวนการ data breach สำหรับเอเจนซีและฟรีแลนซ์ทำเว็บไซต์โดยเฉพาะ ครอบคลุมขอบเขตที่ควรตรวจ ขั้นตอนตรวจทีละขั้น ตัวอย่าง evidence ที่ควรเก็บ และข้อผิดพลาดที่พบบ่อยเมื่อทีมขนาดเล็กพยายามวางระบบนี้ด้วยตัวเอง

ขอบเขตของการ Audit Data Breach สำหรับเอเจนซีและฟรีแลนซ์

การ audit data breach ของเอเจนซีต่างจากธุรกิจที่มีข้อมูลของตัวเองอย่างเดียว เพราะเอเจนซีมักถือกุญแจเข้าถึงระบบของลูกค้าหลายรายพร้อมกัน ขอบเขตที่ควรตรวจครอบคลุมอย่างน้อยสี่ส่วน ส่วนแรกคือบัญชีผู้ดูแลระบบทั้งหมดที่ทีมงานหรืออดีตพนักงานยังถืออยู่ ทั้งบัญชี WordPress, hosting panel, FTP และฐานข้อมูล ส่วนที่สองคือรายชื่อ subprocessor หรือผู้ให้บริการภายนอกที่เข้าถึงข้อมูลลูกค้าของลูกค้า เช่น ผู้ให้บริการ hosting ปลั๊กอินฟอร์มติดต่อ หรือระบบอีเมลมาร์เก็ตติ้ง ส่วนที่สามคือแผนผังการไหลของข้อมูลส่วนบุคคลในแต่ละเว็บไซต์ที่ดูแล ว่าข้อมูลไหนเก็บที่ไหน ถูกส่งต่อให้ใครบ้าง และส่วนสุดท้ายคือข้อสัญญาที่เซ็นกับลูกค้าแต่ละราย โดยเฉพาะข้อที่ระบุระยะเวลาการแจ้งเหตุและขอบเขตความรับผิดชอบเมื่อเกิดเหตุ

ทำไมขอบเขตนี้จึงต่างจากธุรกิจทั่วไป

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

ในทางปฏิบัติ พอร์ตงานของเอเจนซีมักผสมกันหลายแพลตฟอร์ม บางเว็บไซต์สร้างด้วย WordPress และ Elementor บางเว็บไซต์เป็นร้านค้าบน Shopify หรือเชื่อมต่อกับ LINE OA เพื่อรับออเดอร์ แต่ละแพลตฟอร์มมีจุดอ่อนต่างกัน เช่น ปลั๊กอินฟอร์มสมัครสมาชิกบน WordPress ที่ไม่เคยอัปเดต หรือ API key ของ LINE Messaging ที่ฝังไว้ในโค้ดโดยไม่ได้เข้ารหัส การ audit จึงต้องแยกตรวจตามแพลตฟอร์ม ไม่ใช้ checklist เดียวกันทุกเว็บไซต์แบบเหมารวม เพราะความเสี่ยงของแต่ละระบบไม่เหมือนกัน

เตรียมอะไรก่อนเริ่ม Audit

ก่อนเริ่ม audit ทีมควรรวบรวมเอกสารพื้นฐานสามชุด ชุดแรกคือบัญชีรายชื่อเว็บไซต์ทั้งหมดที่ดูแลอยู่ พร้อมระบุว่าเว็บไซต์ใดเก็บข้อมูลส่วนบุคคลประเภทใดบ้าง เช่น ชื่อ ที่อยู่ เบอร์โทร หรือข้อมูลการชำระเงิน ชุดที่สองคือ log การเข้าถึงระบบย้อนหลังอย่างน้อยหกเดือน หากระบบ hosting หรือ CMS ที่ใช้ไม่ได้เก็บ log ไว้นานพอ ควรตั้งค่าเพิ่มก่อนที่ audit จะเดินหน้าได้จริง ชุดที่สามคือรายชื่อผู้ติดต่อฉุกเฉินของลูกค้าแต่ละราย เพราะเมื่อเกิดเหตุจริง เวลาที่เสียไปกับการหาว่าจะติดต่อใครที่ฝั่งลูกค้าคือเวลาที่ทำให้พลาดกรอบ 72 ชั่วโมงในการแจ้ง PDPC บ่อยที่สุด

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

ขั้นตอน Audit Data Breach ทีละขั้น

1. ตรวจสอบสิทธิ์การเข้าถึงทั้งหมด ไล่รายชื่อผู้ใช้ในทุกระบบที่แตะข้อมูลลูกค้า ปิดบัญชีของอดีตพนักงานหรือฟรีแลนซ์ที่เลิกทำงานร่วมกันแล้ว และตรวจว่ารหัสผ่านที่ใช้ร่วมกันในทีม (shared credentials) ยังปลอดภัยอยู่หรือไม่
2. ตรวจสอบว่ามีระบบ log หรือ monitoring หรือไม่ เว็บไซต์ลูกค้าจำนวนมากไม่มี security log เลย ถ้าไม่มี ให้บันทึกไว้เป็นช่องว่างที่ต้องแก้ก่อนอื่น เพราะไม่มี log แปลว่าเมื่อเกิดเหตุจะไม่มีหลักฐานยืนยันว่าเกิดอะไรขึ้นบ้าง
3. ทดสอบว่าทีมงานรู้ขั้นตอนแจ้งเหตุหรือไม่ ลองจำลองสถานการณ์ (mock drill) ถามทีมว่าถ้าเจอเหตุตอนนี้จะโทรหาใครก่อน ใช้แบบฟอร์มไหนบันทึก และต้องแจ้งลูกค้าภายในกี่ชั่วโมงตามสัญญา
4. ตรวจสอบสัญญาลูกค้าแต่ละรายเรื่องระยะเวลาการแจ้งเหตุ สัญญาบางฉบับกำหนดให้แจ้งลูกค้าภายใน 24 ชั่วโมง บางฉบับไม่ได้ระบุเลย ความไม่สอดคล้องกันนี้คือความเสี่ยงที่ audit ต้องจับให้เจอ
5. ตรวจสอบ subprocessor ว่ามีข้อตกลงประมวลผลข้อมูลหรือไม่ ผู้ให้บริการภายนอกที่เอเจนซีเลือกใช้เอง เช่น ปลั๊กอินฟอร์ม หรือระบบส่งอีเมล ต้องมีข้อตกลงระบุหน้าที่เมื่อเกิดเหตุ ไม่ใช่แค่เงื่อนไขการใช้งานทั่วไป
6. ตรวจสอบว่ามีแบบฟอร์มบันทึกเหตุการณ์พร้อมใช้หรือไม่ incident log template ที่พร้อมกรอกทันทีช่วยลดเวลาที่เสียไปกับการคิดว่าจะบันทึกอะไรตอนเกิดเหตุจริง
7. สรุปช่องว่างที่พบและจัดลำดับความสำคัญในการแก้ไข แยกเป็นสิ่งที่ต้องแก้ทันที เช่น ปิดบัญชีที่ไม่ใช้แล้ว กับสิ่งที่วางแผนแก้ในไตรมาสถัดไป เช่น เพิ่ม log ให้ครบทุกเว็บไซต์

Evidence ที่ควรเก็บระหว่างและหลังเหตุการณ์

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

การแจ้งเหตุ PDPC ภายใน 72 ชั่วโมง กับบทบาทของเอเจนซี

ประเด็นที่เอเจนซีสับสนบ่อยคือบทบาทของตัวเองในฐานะผู้ประมวลผลข้อมูล (data processor) ไม่ใช่ผู้ควบคุมข้อมูล (data controller) ตามกฎหมาย หน้าที่แจ้งเหตุต่อสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลภายใน 72 ชั่วโมงเป็นหน้าที่หลักของผู้ควบคุมข้อมูลคือลูกค้าของเอเจนซี แต่ในทางปฏิบัติ เอเจนซีคือฝ่ายที่รู้เหตุการณ์ก่อนเสมอ เพราะเป็นผู้ดูแลระบบ ดังนั้นสิ่งที่ audit ต้องตรวจคือมีขั้นตอนแจ้งลูกค้าเร็วพอหรือไม่ เพื่อให้ลูกค้ามีเวลาเหลือพอที่จะประเมินและแจ้ง PDPC ทันกรอบเวลา หากสัญญาระบุให้เอเจนซีแจ้งลูกค้าภายใน 24 ชั่วโมงหลังพบเหตุ แต่กระบวนการภายในใช้เวลาถึงสามวันกว่าจะยืนยันว่าเกิดอะไรขึ้น นั่นคือช่องว่างที่ทำให้ลูกค้าพลาดกรอบ 72 ชั่วโมงได้ทันที

การประเมินผลหลังเหตุการณ์ (Post-Incident Review)

หลังปิดเคสแล้ว การ audit ที่ดีต้องรวมขั้นตอนทบทวนไว้เสมอ ไม่ใช่แค่แก้ช่องโหว่แล้วจบ ทีมควรกลับมาดูสามเรื่อง เรื่องแรกคือสาเหตุที่แท้จริง (root cause) ไม่ใช่แค่อาการที่เห็น เช่น ถ้าปลั๊กอินเก่าคือช่องทางเข้า ต้องถามต่อว่าทำไมปลั๊กอินนั้นไม่ถูกอัปเดตมานาน เรื่องที่สองคือปรับปรุงข้อสัญญากับลูกค้ารายที่เกิดเหตุและรายอื่นให้สอดคล้องกัน เรื่องที่สามคืออัปเดต checklist audit เองให้ครอบคลุมช่องโหว่ที่เพิ่งเจอ เพื่อไม่ให้เว็บไซต์อื่นในความดูแลเจอปัญหาเดียวกันซ้ำ

การมอบหมายบทบาทหน้าที่เมื่อเกิดเหตุ (ใครทำอะไร)

ทีมเอเจนซีขนาดเล็กมักเจอปัญหาว่าเมื่อเกิดเหตุจริง ทุกคนวิ่งเข้ามาช่วยพร้อมกันแต่ไม่มีใครตัดสินใจได้ เพราะไม่เคยกำหนดไว้ล่วงหน้าว่าใครมีอำนาจสั่งปิดระบบ ใครติดต่อลูกค้า และใครเป็นคนบันทึกหลักฐาน การ audit ที่ดีจึงควรตรวจสอบว่ามีการมอบหมายบทบาทชัดเจนแบบ RACI อย่างน้อยสี่บทบาท บทบาทแรกคือผู้รับผิดชอบหลัก (Responsible) ที่ลงมือแก้ไขทางเทคนิค เช่น ปิดช่องโหว่ เปลี่ยนรหัสผ่าน หรือ rollback ระบบ บทบาทที่สองคือผู้อนุมัติ (Accountable) ซึ่งมักเป็นเจ้าของเอเจนซีหรือหัวหน้าทีม ที่ตัดสินใจเรื่องใหญ่ เช่น จะแจ้งลูกค้าตอนไหน จะจ้างผู้เชี่ยวชาญภายนอกเข้ามาสอบสวนหรือไม่ บทบาทที่สามคือผู้ประสานงานลูกค้า (Consulted) ที่สื่อสารกับลูกค้าโดยตรง ต้องเป็นคนที่รู้เนื้อหาสัญญาและใช้ภาษาที่ไม่สร้างความตื่นตระหนกเกินจริง และบทบาทสุดท้ายคือผู้บันทึกเหตุการณ์ (Informed) ที่คอยจดไทม์ไลน์ทุกการตัดสินใจตั้งแต่วินาทีแรกที่พบเหตุ

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

ข้อผิดพลาดที่พบบ่อยเมื่อ Audit Data Breach ของเอเจนซี

• เก็บบัญชีผู้ดูแลระบบไว้ในไฟล์ spreadsheet ที่ไม่มีใครอัปเดต ทำให้ audit ใช้ข้อมูลเก่าโดยไม่รู้ตัว
• ตรวจแค่เว็บไซต์ลูกค้ารายใหญ่ แล้วมองข้ามเว็บไซต์เล็กที่ทีมดูแลแบบผ่านๆ ทั้งที่ความเสี่ยงมักเริ่มจากจุดที่ถูกมองข้าม
• ไม่แยกแยะระหว่างบทบาทผู้ประมวลผลข้อมูลกับผู้ควบคุมข้อมูล ทำให้เข้าใจผิดว่าตัวเองไม่มีหน้าที่ต้องแจ้งอะไรเลย
• ไม่มีแบบฟอร์มบันทึกเหตุการณ์ที่ใช้ร่วมกันทั้งทีม ต่างคนต่างจดคนละแบบ ทำให้ข้อมูลไม่ครบเมื่อต้องรวบรวม evidence
• ทำ audit ครั้งเดียวแล้วไม่ทบทวนซ้ำ ทั้งที่ทีมงานเปลี่ยน ปลั๊กอินเปลี่ยน และลูกค้าใหม่เข้ามาตลอดเวลา

สรุป

การ audit data breach ของเอเจนซีและฟรีแลนซ์ไม่ใช่การเขียนเอกสารเก็บไว้เฉยๆ แต่เป็นการตรวจสอบสิทธิ์การเข้าถึง subprocessor แผนผังข้อมูล และข้อสัญญาให้ครบ พร้อมวางระบบเก็บ evidence ไว้ล่วงหน้า กระบวนการนี้ช่วยลดความเสี่ยงที่ทีมจะพลาดกรอบเวลาแจ้งเหตุ และช่วยให้ทบทวนปรับปรุงได้จริงหลังเกิดเหตุการณ์ ดูขั้นตอนปฏิบัติแบบละเอียดเพิ่มเติมได้ที่ คู่มือ How-to วางระบบ Data Breach สำหรับเอเจนซี และภาพรวมของหมวดสิทธิ เหตุการณ์ และความเสี่ยงทั้งหมดได้ที่ หน้าเสาหลัก Rights, Incidents & Risk

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

ข้อมูลอ้างอิงหลักของบทความนี้มาจากสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) ที่ pdpc.or.th ทีมควรตรวจสอบประกาศและแนวปฏิบัติล่าสุดจากแหล่งทางการก่อนนำไปปรับใช้ในสัญญาหรือกระบวนการภายในของแต่ละเอเจนซี