Sourcenext ข้อมูลรั่ว คือเหตุที่ผู้จำหน่ายซอฟต์แวร์ญี่ปุ่นประกาศเมื่อ 15 ตุลาคม 2569 (ค.ศ. 2026) ว่าข้อมูลสมาชิกอาจรั่ว 22,519,960 รายการ รวมอีเมลและรหัสผ่าน ต่อมา Burger King Japan เปิดเผยอีก 11.18 ล้านรายการ บทความนี้เหมาะกับธุรกิจไทยที่มีฐานสมาชิกหรือแอป อ่านแล้วจะรู้ว่าต้องทบทวนการเก็บข้อมูลและ API ตรงไหน
ลองนึกภาพร้านอาหารไทยที่มีแอปสะสมแต้ม ลูกค้าสมัครไว้ตั้งแต่ปีแรก แล้วไม่เคยเปิดอีกเลย แต่ชื่อ เบอร์โทร วันเกิด และประวัติสั่งซื้อยังนอนอยู่ในระบบ เรื่องแบบนี้คือจุดร่วมของข่าวญี่ปุ่นรอบนี้ และเกิดขึ้นต่อจากเหตุข้อมูลรั่วหลายบริษัทที่เว็บนี้รายงานไว้แล้ว
สรุปสั้น: Sourcenext ประกาศเมื่อ 15 ตุลาคม 2569 ว่าข้อมูลสมาชิกอาจรั่ว 22,519,960 รายการ และ Burger King Japan เปิดเผยเมื่อ 16 ตุลาคม 2569 ว่าข้อมูลสมาชิกแอป 11.18 ล้านรายการถูกเข้าถึง ทั้งสองกรณียังไม่เปิดเผยต้นเหตุครบถ้วน ธุรกิจไทยควรเก็บข้อมูลเท่าที่จำเป็น ลบบัญชีที่ไม่ใช้งาน ทดสอบสิทธิ์ API และไม่เก็บรหัสผ่านในรูปที่กู้คืนได้
Sourcenext ข้อมูลรั่ว คืออะไร เกิดอะไรขึ้นกับสมาชิก
Sourcenext ข้อมูลรั่ว คือกรณีที่บริษัทประกาศว่าข้อมูลสมาชิกอาจรั่วออกไป 22,519,960 รายการ ของผู้ลงทะเบียนก่อน 13:36 น. เวลาญี่ปุ่น วันที่ 13 ตุลาคม 2569 บริษัทใช้หน่วยนับภาษาญี่ปุ่นที่ไม่ระบุว่าเป็นจำนวนคนหรือจำนวนบัญชี จึงอย่าอ่านตัวเลขนี้ว่าเป็น 22.5 ล้านคน
ข้อมูลที่อาจรั่ว ได้แก่ อีเมล รหัสผ่าน ชื่อ ที่อยู่ เบอร์โทร และวันเกิด โดยแต่ละรายไม่เหมือนกัน บริษัทระบุว่าระบบนี้ไม่มีข้อมูลบัตรเครดิต ตามรายงานของสื่อ ผู้โจมตีอาจเข้าถึงกุญแจเข้ารหัสด้วย ซึ่งหมายความว่ารหัสผ่านอาจถูกอ่านได้ แต่เทคนิคนี้ยังไม่ได้รับการยืนยัน
Burger King Japan (ประมาณ 350 สาขา) เปิดเผยเมื่อ 16 ตุลาคม 2569 ว่าเซิร์ฟเวอร์ข้อมูลสมาชิกแอป 11.18 ล้านรายการถูกเข้าถึงระหว่าง 2-7 ตุลาคม 2569 ข้อมูลที่เกี่ยวข้องคือชื่อ วันเกิด เพศ อีเมล เบอร์โทร และประวัติสั่งซื้อ ไม่มีเลขบัตรเครดิต บริษัทรายงานต่อคณะกรรมาธิการคุ้มครองข้อมูลส่วนบุคคลญี่ปุ่น (PPC) แล้ว ข้อมูลถูกนำไปเผยแพร่ออนไลน์ในภายหลัง ส่วนต้นเหตุยังไม่เปิดเผย
| ประเด็น | ข้อเท็จจริงตามรายงาน |
|---|---|
| Sourcenext | ประกาศ 15 ต.ค. 2569 · อาจรั่ว 22,519,960 รายการ · มีรหัสผ่าน ไม่มีบัตรเครดิต |
| Burger King Japan | เปิดเผย 16 ต.ค. 2569 · 11.18 ล้านรายการ · เข้าถึง 2-7 ต.ค. 2569 |
| PPC ญี่ปุ่น | MLex รายงาน 15 ต.ค. ว่าเรียกร้องให้เสริมความปลอดภัยพื้นฐานและลบข้อมูลที่ไม่ต้องใช้ |
| ภาพรวมญี่ปุ่น | Macnica บันทึก 119 เหตุข้อมูลรั่วหรือถูกขโมยในปี 2569 ตามที่ BleepingComputer อ้าง |
ข้อมูลอีกชิ้นมาจาก MLex ที่รายงานว่า PPC เรียกร้องให้บริษัทเสริมมาตรการความปลอดภัยพื้นฐาน รวมถึงลบข้อมูลส่วนบุคคลที่ไม่ต้องใช้แล้ว หลังเหตุของบริษัทย่อยคาร์แชริ่งของ Park24 ที่ภาพเอกสารยืนยันตัวตนราว 1.6 ล้านบัญชีหลุด ตัวเลขนี้มาจาก MLex และยังไม่ได้ตรวจกับต้นทางหลัก ผู้เขียนจึงอ้างไว้ในฐานะรายงานของสื่อเท่านั้น
เหตุก่อนหน้าในญี่ปุ่น เช่น ร้านอาหารและเว็บจองตั๋วหลายราย สรุปไว้ใน ญี่ปุ่นข้อมูลรั่วต่อเนื่อง skyticket 14.6 ล้าน คาราโอเกะ 8.7 ล้าน Lawson 2.16 ล้าน รัฐเรียกประชุมฉุกเฉิน สัญญา DPA ของธุรกิจไทยต้องมีข้อไหน บทความนี้เล่าเฉพาะสิ่งที่เพิ่มเข้ามา
Sourcenext ข้อมูลรั่ว กระทบธุรกิจไทยอย่างไร
Sourcenext ข้อมูลรั่ว ยังไม่มีรายงานผู้เสียหายชาวไทย แต่ปัญหาที่ญี่ปุ่นเผชิญคือ เก็บมากเกิน เก็บนานเกิน และเปิด API กว้างเกิน ซึ่งเป็นนิสัยที่พบได้ในโปรแกรมสมาชิกของธุรกิจไทยเช่นกัน ส่วนนี้เป็นการวิเคราะห์ของผู้เขียน ไม่ใช่ข้อเท็จจริงในข่าว
ธุรกิจไทยที่มีโปรแกรมสมาชิกหรือแอปได้รับผลอย่างไร
ธุรกิจที่มีฐานสมาชิกใหญ่ เช่น ร้านอาหารเครือข่าย ร้านค้าปลีก โรงเรียนกวดวิชา หรือแอปสะสมแต้ม เสี่ยงเหตุแบบเดียวกัน เพราะฐานข้อมูลสมาชิกมักโตเรื่อย ๆ โดยไม่มีใครลบ พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 37(1) กำหนดให้ผู้ควบคุมข้อมูลต้องมีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม และข้อมูลที่ไม่มีอยู่ในระบบ ย่อมรั่วไม่ได้
เก็บรหัสผ่านแบบกู้คืนได้ มีปัญหาอะไรเมื่อระบบถูกเจาะ
เก็บรหัสผ่านแบบกู้คืนได้ มีปัญหาตรงที่ผู้โจมตีที่ได้ทั้งฐานข้อมูลและกุญแจ จะอ่านรหัสผ่านได้ทั้งหมด รายงานสื่อที่ว่าอาจเข้าถึงกุญแจเข้ารหัสได้ชี้ว่า การเข้ารหัสแบบกู้คืนได้ไม่ช่วย เมื่อกุญแจอยู่ในระบบเดียวกัน ผู้ใช้จำนวนมากใช้รหัสเดิมกับหลายเว็บ จึงเสี่ยงถูกนำไปลองเข้าบัญชีอื่นต่อ
API ภายในที่ตั้งสิทธิ์หละหลวม เกี่ยวกับข้อมูลรั่วอย่างไร
API ภายในที่ดึงข้อมูลสมาชิกได้ ต้องจำกัดว่าใครขอข้อมูลอะไรได้เท่าไร ถ้าตั้งสิทธิ์กว้างเกินไป ผู้โจมตีที่ได้โทเคนเพียงตัวเดียวอาจดึงข้อมูลทั้งฐานได้ กรณี Burger King Japan ยังไม่เปิดต้นเหตุ จึงไม่ควรสรุปว่าเกิดจาก API แต่ API เป็นจุดที่ควรทดสอบก่อนเสมอ
ถ้าเกิดเหตุกับองค์กรไทย ต้องแจ้งใครและเมื่อไร
องค์กรไทยต้องแจ้งเหตุละเมิดต่อสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส.) ภายใน 72 ชั่วโมงนับแต่ทราบเหตุ ตามมาตรา 37(4) หากเหตุมีความเสี่ยงต่อสิทธิเสรีภาพของบุคคล ก็ต้องแจ้งเจ้าของข้อมูลพร้อมแนวทางเยียวยา ตัวอย่างบริบทไทยดูได้ใน H.I.S. ไทยถูกเจาะ ข้อมูลพาสปอร์ตสูงสุด 627 คนอาจรั่ว ธุรกิจท่องเที่ยวไทยจะตอบ PDPA 72 ชั่วโมงได้อย่างไร
สัญญาณจากภาครัฐไทยก็ไปทางเดียวกัน เลขาธิการ สคส. ให้สัมภาษณ์ถึงแนวทาง Data Trust ที่มีมาตรการส่งเสริมการเก็บข้อมูลเท่าที่จำเป็น โดยระบุว่าการเก็บเกินเป็นสาเหตุสำคัญของข้อมูลรั่ว เรื่องนี้เป็นการให้สัมภาษณ์เชิงนโยบาย ไม่ใช่ประกาศทางการ
ถ้าไม่ทำอะไรเลย ธุรกิจเสี่ยงอะไร
ถ้าไม่ทำอะไร ธุรกิจเสี่ยงสามเรื่อง เรื่องแรก ข้อมูลของสมาชิกที่เลิกใช้บริการไปแล้วยังรั่วได้ ทั้งที่ธุรกิจไม่ได้ประโยชน์จากข้อมูลนั้นแล้ว เรื่องที่สอง เมื่อเกิดเหตุ ต้องแจ้ง สคส. ภายใน 72 ชั่วโมง แต่ถ้าไม่รู้ว่าเก็บข้อมูลอะไรไว้ที่ไหน ก็ประเมินความเสี่ยงไม่ทัน
เรื่องที่สาม คือความเชื่อมั่นของลูกค้า กรณี Burger King Japan ข้อมูลถูกเผยแพร่ออนไลน์ภายหลัง ทำให้ผู้ใช้ต้องระวังอีเมลหลอกลวงต่อไปอีกนาน
ธุรกิจที่มีฐานสมาชิกควรทำอะไรตอนนี้
ธุรกิจที่มีฐานสมาชิกควรทำ 4 เรื่องภายใน 30 วัน เพื่อไม่ให้เหตุแบบ Sourcenext ข้อมูลรั่วเกิดกับระบบของตัวเอง
- 1. ทบทวนระยะเก็บข้อมูลสมาชิก กำหนดว่าเก็บข้อมูลแต่ละประเภทนานเท่าไร และเขียนเหตุผลที่ต้องเก็บ
- 2. ลบหรือทำให้ไม่ระบุตัวตนกับบัญชีที่ไม่ใช้งาน ตั้งเกณฑ์ เช่น ไม่เข้าใช้นานเกินกำหนด แล้วลบพร้อมจดบันทึกการลบ
- 3. ทดสอบสิทธิ์ API ที่ดึงข้อมูลสมาชิก ตรวจว่าโทเคนหนึ่งตัวดึงข้อมูลได้กี่รายการ และมีการจำกัดอัตราการขอข้อมูลหรือไม่
- 4. เลิกเก็บรหัสผ่านในรูปที่กู้คืนได้ ใช้การแฮชแบบมีค่าสุ่ม และแยกกุญแจออกจากระบบที่เก็บฐานข้อมูล
ถ้าต้องการคนช่วยทำตารางทบทวนการเก็บรักษาข้อมูลและตรวจ PDPA ดูได้ที่ บริการ AI Governance และ PDPA ของ Kooru กรณีผู้รับจ้างดูแลข้อมูล ดูบทเรียนเพิ่มใน Yakiniku King ข้อมูลรั่วกว่า 10.7 ล้านรายการ ข้อมูลไดวะอาจรั่วที่ผู้รับจ้าง ธุรกิจไทยต้องตรวจผู้รับจ้างอย่างไร
มุมมองผู้เชี่ยวชาญ
ข้อสังเกตเชิงวิชาชีพของผมคือ ข่าวญี่ปุ่นชุดนี้ไม่ได้สอนเรื่องแฮกเกอร์เก่งแค่ไหน แต่สอนเรื่องนิสัยการเก็บข้อมูลของบริษัท ข้อมูลที่คุณไม่ได้ใช้แล้วแต่ยังเก็บอยู่ คือหนี้ที่รอวันถูกทวง จุดที่องค์กรมักพลาดคือเก็บทุกอย่างไว้ก่อนเพราะกลัวต้องใช้ทีหลัง ควรเริ่มจากถามว่าข้อมูลชิ้นนี้ยังมีเหตุผลทางธุรกิจให้เก็บอยู่ไหม ถ้าตอบไม่ได้ก็ควรลบ
— Phuwara Krobtaku —
LL.M. (IP & IT) | M.S. (IT) | Thai Barrister & Attorney-at-Law
อ่านเพิ่มเติม: เหตุข้อมูลรั่วล่าสุดของบริษัทญี่ปุ่นที่แจ้ง PPC อ่านต่อที่ Capcom ยืนยัน CAPCOM ID รั่ว 11.7 ล้านบัญชี แจ้ง PPC ญี่ปุ่นใน 2 วัน ธุรกิจเกมและแอปสมาชิกไทยต้องเทียบแผนแจ้งเหตุ 72 ชั่วโมง
คำถามที่พบบ่อยเกี่ยวกับ Sourcenext ข้อมูลรั่ว
Sourcenext ข้อมูลรั่ว 22.5 ล้านรายการ คือ 22.5 ล้านคนหรือไม่
ไม่จำเป็น Sourcenext ใช้หน่วยนับภาษาญี่ปุ่นที่ไม่ระบุว่าเป็นคนหรือบัญชี จึงควรอ่านว่าเป็น 22,519,960 รายการ ที่อาจรั่วตามประกาศของบริษัทเมื่อ 15 ตุลาคม 2569
ข้อมูลที่อาจรั่วจาก Sourcenext มีอะไรบ้าง
ข้อมูลที่อาจรั่วคืออีเมล รหัสผ่าน ชื่อ ที่อยู่ เบอร์โทร และวันเกิด โดยแต่ละรายไม่เหมือนกัน บริษัทระบุว่าระบบนี้ไม่มีข้อมูลบัตรเครดิต
Burger King Japan ข้อมูลรั่วเพราะอะไร
ต้นเหตุยังไม่เปิดเผย บริษัทระบุว่าเซิร์ฟเวอร์ข้อมูลสมาชิกแอป 11.18 ล้านรายการถูกเข้าถึงระหว่าง 2-7 ตุลาคม 2569 และรายงานต่อ PPC แล้ว ข้อมูลถูกนำไปเผยแพร่ออนไลน์ในภายหลัง
ธุรกิจไทยต้องทำอะไรตาม PDPA เพื่อลดความเสี่ยงแบบเดียวกัน
ต้องมีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสมตามมาตรา 37(1) และแจ้งเหตุละเมิดต่อ สคส. ภายใน 72 ชั่วโมงตามมาตรา 37(4) ในทางปฏิบัติควรเริ่มจากลดข้อมูลที่เก็บ ลบบัญชีที่ไม่ใช้งาน และทดสอบสิทธิ์ API
อ่านต่อ: ความรู้ที่เกี่ยวกับเรื่องนี้
- จดหมายแจ้งเจ้าของข้อมูลเมื่อข้อมูลรั่ว ต้องมีอะไรบ้าง — อธิบายว่าจดหมายแจ้งเจ้าของข้อมูลต้องมีเนื้อหาอะไรเมื่อเหตุมีความเสี่ยงสูง ตามมาตรา 37(4) (aipdpa.com)
แหล่งอ้างอิง
- BleepingComputer — (อ่านต้นฉบับ) — Burger King Japan data breach exposes 11 million customer records
- SmartScope (อ้างประกาศ Sourcenext) — (อ่านต้นฉบับ) — อ่านรายงานที่ SmartScope
- MLex — (อ่านต้นฉบับ) — อ่านรายงานที่ MLex
- Sourcenext — ประกาศของบริษัท — อ่านประกาศที่ Sourcenext
บทความนี้เป็นการสรุปข่าวและให้ข้อมูลทั่วไป ไม่ใช่คำแนะนำทางกฎหมาย หากต้องการคำปรึกษาเฉพาะกรณีของธุรกิจคุณ ควรปรึกษาผู้เชี่ยวชาญ
