ญี่ปุ่นข้อมูลรั่ว ในช่วง 8–9 ตุลาคม 2569 (ค.ศ. 2026) คือชุดเหตุที่ประกาศเพิ่มจาก skyticket คาราโอเกะ BIG ECHO Bookoff Lawson ID และ JR East รวมหลายสิบล้านรายการ และหลายเคสเกิดที่ผู้รับจ้างหรือคลาวด์ ไม่ใช่ระบบหลักของแบรนด์ บทความนี้เหมาะกับธุรกิจค้าปลีก ท่องเที่ยว และองค์กรที่จ้างคนอื่นดูแลข้อมูล อ่านแล้วจะรู้ว่าสัญญา DPA ต้องมี 4 ข้ออะไร
ลองนึกภาพเครือร้านอาหารไทยที่จ้างบริษัทภายนอกดูแลแอปสะสมแต้ม (ตัวอย่างสมมติ) วันหนึ่งเครื่องของพนักงานผู้รับจ้างติดมัลแวร์ ข้อมูลลูกค้าหลายแสนคนเสี่ยงหลุด แต่แบรนด์รู้ช้าเพราะสัญญาไม่ได้เขียนว่าผู้รับจ้างต้องแจ้งภายในกี่ชั่วโมง ญี่ปุ่นเจอภาพนี้ซ้ำหลายบริษัทในสัปดาห์เดียว
สรุปสั้น: ญี่ปุ่นมีเหตุข้อมูลรั่วประกาศเพิ่มช่วง 8–9 ตุลาคม 2569 ใหญ่สุดคือ skyticket ราว 14.64 ล้านรายการ ส่วนคาราโอเกะ BIG ECHO สูงสุดราว 8.72 ล้านรายการยังอยู่ในสถานะอาจรั่ว เคสสำคัญเกิดที่ผู้รับจ้างประมวลผลและคลาวด์ IDCF ที่โดนแรนซัมแวร์ ธุรกิจไทยควรทบทวนสัญญา DPA ให้มีกรอบแจ้งเหตุ สิทธิตรวจสอบ และแผนกู้คืนข้อมูล
ญี่ปุ่นข้อมูลรั่วรอบนี้มีบริษัทไหนบ้าง และรั่วเท่าไร
ญี่ปุ่นข้อมูลรั่วรอบนี้มี 5 เหตุหลักที่ Impress Watch รวบรวมจากประกาศช่วง 8–9 ตุลาคม 2569 ใหญ่สุดคือ Adventure ผู้ให้บริการ skyticket ราว 14.64 ล้านรายการ รอบนี้เป็นความต่อเนื่องจากเหตุที่สรุปไว้ใน Yakiniku King ข้อมูลรั่วกว่า 10.7 ล้านรายการ ข้อมูลไดวะอาจรั่วที่ผู้รับจ้าง ธุรกิจไทยต้องตรวจผู้รับจ้างอย่างไร
| บริษัท | จำนวนตามรายงาน | สถานะ |
|---|---|---|
| Adventure (skyticket) | ราว 14.64 ล้านรายการ | ประกาศเหตุรั่ว |
| Daiichi Kosho (คาราโอเกะ BIG ECHO) | สูงสุดราว 8.72 ล้านรายการ | อาจรั่ว บริษัทยังไม่ยืนยันว่าหลุดจริง |
| Bookoff | สูงสุดราว 6.43 ล้านรายการ | ประกาศเหตุ |
| Lawson ID | ราว 2.16 ล้านรายการ | ถูกเข้าถึง 12–14 ก.ย. ตรวจพบ 7 ต.ค. |
| JR East | ราว 2.06 ล้านรายการ | ประกาศเหตุ |
ตัวเลขในตารางเป็นจำนวนรายการ ไม่ใช่จำนวนคนเสมอไป และบางรายเป็นตัวเลขสูงสุดที่อาจกระทบ แหล่งข่าวไม่ได้ระบุว่าข้อมูลคนไทยได้รับผลกระทบหรือไม่ ประเด็นนี้จึงยังไม่ยืนยัน
ทำไมเหตุข้อมูลรั่วในญี่ปุ่นหลายเคสเกิดที่ผู้รับจ้าง
เพราะข้อมูลลูกค้าของแบรนด์ใหญ่จำนวนมากถูกส่งต่อให้ผู้รับจ้างประมวลผลหรือคลาวด์ภายนอก จุดที่อ่อนที่สุดในห่วงโซ่จึงมักไม่ใช่ระบบของแบรนด์เอง เคส Daiichi Kosho เกิดที่ Nippon Columbia Group ผู้รับจ้างประมวลผล เมื่อเครื่องพนักงาน 1 เครื่องติดมัลแวร์
ข้อมูลที่เสี่ยงในเคสนี้คือลูกค้าราว 8.63 ล้านรายและพนักงานราว 93,000 ราย ได้แก่ ชื่อ เพศ วันเกิด อีเมล และเบอร์โทร บริษัทบอกว่ายังไม่ยืนยันว่าข้อมูลหลุดออกไปจริง
คลาวด์ IDCF ถูกแรนซัมแวร์ตั้งแต่ราว 03:00 น. วันที่ 7 ตุลาคม 2569 กระทบบริษัทและท้องถิ่น 495 ราย ข้อมูลลูกค้าบางส่วนกู้คืนได้ยาก สำนักงานไซเบอร์แห่งชาติของญี่ปุ่นจึงเรียกประชุมฉุกเฉินทุกกระทรวงวันที่ 8 ตุลาคม และออกมาตรการรับมือวันที่ 9 ตุลาคม 2569
ญี่ปุ่นข้อมูลรั่วกระทบธุรกิจไทยอย่างไร
ญี่ปุ่นข้อมูลรั่วกระทบธุรกิจไทยในฐานะบทเรียนเรื่องผู้รับจ้าง เพราะค้าปลีก ท่องเที่ยว และคลาวด์ไทยใช้โครงสร้างเดียวกัน คือจ้างคนอื่นดูแลข้อมูลลูกค้า ไทยมี Lawson 108 และคนไทยใช้บริการญี่ปุ่นจำนวนมาก แต่ยังไม่มีรายงานว่าข้อมูลคนไทยถูกกระทบ ส่วนนี้เป็นการวิเคราะห์ของผู้เขียน
ผู้รับจ้างประมวลผลข้อมูลมีหน้าที่อะไรตาม PDPA
ผู้ประมวลผลข้อมูลมีหน้าที่ตามมาตรา 40 ของ พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 ส่วนผู้ควบคุมข้อมูลยังต้องจัดมาตรการรักษาความมั่นคงปลอดภัยตามมาตรา 37(1) และแจ้งเหตุต่อ สคส. ภายใน 72 ชั่วโมงตามมาตรา 37(4) แม้เหตุจะเกิดที่ผู้รับจ้างก็ตาม
ถ้าผู้รับจ้างไม่แจ้งเรา เราก็แจ้ง สคส. ไม่ทัน สัญญา DPA จึงต้องเขียนให้ผู้รับจ้างแจ้งเราเร็วกว่ากรอบ 72 ชั่วโมงพอสมควร ตัวอย่างการตอบกรอบเวลานี้อยู่ใน H.I.S. ไทยถูกเจาะ ข้อมูลพาสปอร์ตสูงสุด 627 คนอาจรั่ว ธุรกิจท่องเที่ยวไทยจะตอบ PDPA 72 ชั่วโมงได้อย่างไร
ตรวจพบช้าอย่างเคส Lawson มีผลกับการแจ้งเหตุอย่างไร
มีผลมาก ระบบ Lawson ID ถูกเข้าถึงช่วง 12–14 กันยายน แต่ตรวจพบ 7 ตุลาคม ช้ากว่าการเจาะเกือบ 3 สัปดาห์ Lawson รายงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลญี่ปุ่น (PPC) แล้ว ส่วนระบบจองผ่านแอปหลุดเลขบัตรเครดิตบางส่วน 26 ราย
กรอบ 72 ชั่วโมงตาม PDPA เริ่มนับเมื่อทราบเหตุ แต่ยิ่งตรวจพบช้า ความเสียหายก็ยิ่งลาม และองค์กรจะถูกถามว่าทำไมระบบเฝ้าระวังจับไม่ได้
ถ้าคลาวด์ล่มทั้งระบบอย่าง IDCF ธุรกิจไทยต้องเตรียมอะไร
ต้องมีแผนกู้คืนข้อมูลที่ไม่ฝากไว้กับผู้ให้บริการรายเดียว เคส IDCF แสดงว่าข้อมูลบางส่วนกู้คืนได้ยากเมื่อแรนซัมแวร์โจมตีคลาวด์ องค์กรที่ไม่มีสำเนาแยกจะหยุดให้บริการลูกค้าทันที
มาตรฐานคลาวด์ฝั่งไทยสรุปไว้ใน มาตรฐานไซเบอร์ระบบคลาวด์ของ สกมช. พ้นระยะผ่อนผัน บังคับใช้แล้วตั้งแต่ 10 ก.ย. 2569 ผู้ขาย SaaS และ MSP ที่ทำงานกับหน่วยงานรัฐหรือ CII ต้องเตรียมอะไร
ถ้าสัญญา DPA ไม่มีข้อแจ้งเหตุและกู้คืน จะเสี่ยงอะไร
ถ้าสัญญา DPA ไม่มีข้อแจ้งเหตุและกู้คืน ธุรกิจเสี่ยงรู้เหตุช้า แจ้ง สคส. ไม่ทัน 72 ชั่วโมง และไม่มีสิทธิเรียกข้อมูลจากผู้รับจ้างมาประเมินความเสียหาย ภาระตาม PDPA ยังอยู่กับผู้ควบคุมข้อมูล แม้ต้นเหตุจะอยู่ที่ผู้รับจ้าง
ผู้เขียนวิเคราะห์ว่าความเสี่ยงจากห่วงโซ่ผู้ให้บริการกำลังเป็นประเด็นหลักของ PDPA เพราะเหตุรั่วในญี่ปุ่นรอบนี้จำนวนมากมาจากผู้รับจ้างหรือคลาวด์ ไม่ได้มาจากระบบหลักของแบรนด์
ธุรกิจไทยควรเขียนอะไรในสัญญา DPA
ธุรกิจไทยควรเขียน 4 ข้อในสัญญา DPA คือ กรอบเวลาแจ้งเหตุ สิทธิตรวจสอบ แผนกู้คืนข้อมูล และการคุมผู้รับจ้างช่วง ทั้งสี่ข้อช่วยให้ผู้ควบคุมข้อมูลทำหน้าที่ตาม PDPA ได้จริงเมื่อเกิดเหตุแบบญี่ปุ่นข้อมูลรั่ว
- 1. กำหนดกรอบแจ้งเหตุเป็นชั่วโมง ให้ผู้รับจ้างแจ้งเราภายในจำนวนชั่วโมงที่สั้นกว่ากรอบ 72 ชั่วโมงของมาตรา 37(4) พร้อมรายการข้อมูลที่ต้องส่งมา
- 2. เขียนสิทธิตรวจสอบ ให้เราขอดูมาตรการความปลอดภัย บันทึกการเข้าถึง และผลตรวจของผู้รับจ้างได้ รวมถึงหลังเกิดเหตุ
- 3. ระบุแผนกู้คืนข้อมูล กำหนดการสำรองข้อมูลแยกจากผู้ให้บริการหลัก ระยะเวลากู้คืน และการทดสอบกู้คืนเป็นรอบ
- 4. คุมผู้รับจ้างช่วงและเครื่องพนักงาน ให้ผู้รับจ้างแจ้งก่อนส่งงานต่อ และมีมาตรการป้องกันมัลแวร์บนเครื่องที่แตะข้อมูลลูกค้า
ถ้าต้องการคนช่วยร่างหรือตรวจสัญญา DPA ดูรายละเอียดได้ที่ บริการ AI Governance และ PDPA ของ Kooru
มุมมองผู้เชี่ยวชาญ
ข้อสังเกตเชิงวิชาชีพของผมคือ ตัวเลขหลายสิบล้านรายการในญี่ปุ่นไม่ได้บอกว่าแบรนด์ไหนอ่อน แต่บอกว่าข้อมูลของแบรนด์ถูกเก็บในที่ที่แบรนด์มองไม่เห็น คุณจ้างคนอื่นดูแลข้อมูลได้ แต่จ้างคนอื่นรับผิดแทนตาม PDPA ไม่ได้ จุดที่องค์กรมักพลาดคือเซ็นสัญญาจ้างที่เขียนแต่ราคาและระดับบริการ ควรเช็กว่ามีข้อแจ้งเหตุเป็นชั่วโมง สิทธิตรวจสอบ และแผนกู้คืนครบหรือไม่
— Phuwara Krobtaku —
LL.M. (IP & IT) | M.S. (IT) | Thai Barrister & Attorney-at-Law
อ่านเพิ่มเติม: อีกกรณีที่ข้อมูลรั่วผ่านผู้ให้บริการภายนอก อ่านต่อที่ 302.ai ตัวกลาง AI เปิดคลาวด์ทิ้ง 22.72TB แชต 144,000 ชุดหลุด SME ไทยที่ต่อแชตบอตผ่าน AI ราคาถูกต้องเช็กสัญญา PDPA
คำถามที่พบบ่อยเกี่ยวกับญี่ปุ่นข้อมูลรั่ว
ญี่ปุ่นข้อมูลรั่วรอบ 8–9 ตุลาคม 2569 ใหญ่สุดคือเคสไหน
ใหญ่สุดคือ Adventure ผู้ให้บริการ skyticket ราว 14.64 ล้านรายการ ตามด้วย Daiichi Kosho สูงสุดราว 8.72 ล้านรายการ Bookoff สูงสุดราว 6.43 ล้าน Lawson ID ราว 2.16 ล้าน และ JR East ราว 2.06 ล้านรายการ
ข้อมูลลูกค้าคาราโอเกะ BIG ECHO รั่วจริงหรือไม่
ยังไม่ยืนยัน Daiichi Kosho บอกว่าเครื่องพนักงานของผู้รับจ้างประมวลผลติดมัลแวร์ และข้อมูลลูกค้าราว 8.63 ล้านรายกับพนักงานราว 93,000 รายมีความเสี่ยง แต่ยังไม่ยืนยันว่าข้อมูลหลุดออกไปจริง
ข้อมูลคนไทยได้รับผลกระทบจากเหตุในญี่ปุ่นหรือไม่
แหล่งข่าวไม่ได้ระบุว่าข้อมูลคนไทยได้รับผลกระทบ จึงยังไม่ยืนยัน คนไทยที่ใช้บริการจองตั๋วหรือสมาชิกของบริษัทเหล่านี้ควรติดตามประกาศของแต่ละบริษัท และระวังอีเมลหรือข้อความหลอกที่อ้างเหตุรั่ว
ถ้าผู้รับจ้างทำข้อมูลรั่ว ใครต้องแจ้ง สคส.
ผู้ควบคุมข้อมูลต้องแจ้ง สคส. ภายใน 72 ชั่วโมงนับแต่ทราบเหตุตามมาตรา 37(4) ส่วนผู้รับจ้างในฐานะผู้ประมวลผลมีหน้าที่ตามมาตรา 40 สัญญา DPA จึงควรบังคับให้ผู้รับจ้างแจ้งผู้ควบคุมข้อมูลโดยเร็ว
แหล่งอ้างอิง
- Impress Watch — (อ่านต้นฉบับ) — อ่านข่าวที่ Impress Watch
- BleepingComputer — (อ่านต้นฉบับ) — อ่านข่าวที่ BleepingComputer
บทความนี้เป็นการสรุปข่าวและให้ข้อมูลทั่วไป ไม่ใช่คำแนะนำทางกฎหมาย หากต้องการคำปรึกษาเฉพาะกรณีของธุรกิจคุณ ควรปรึกษาผู้เชี่ยวชาญ
