Yakiniku King คือเครือร้านปิ้งย่างในญี่ปุ่นที่บริษัท Monogatari ประกาศเมื่อ 5 ต.ค. 2569 ว่าแอปทางการถูกเข้าถึงโดยไม่ได้รับอนุญาต ทำให้ข้อมูลสมาชิก 10,788,963 รายการรั่ว ทั้งชื่อ อีเมล และเบอร์โทรศัพท์ บทความนี้เหมาะกับร้านอาหาร ค้าปลีก และโบรกเกอร์ไทยที่มีแอปสมาชิกหรือจ้างผู้รับจ้างถือข้อมูลลูกค้า อ่านแล้วจะรู้ว่าต้องตรวจผู้รับจ้างอย่างไร
ลองนึกภาพเครือร้านอาหารไทยที่มีแอปสะสมแต้ม ฝ่าย IT ยืนยันว่าระบบของบริษัทปลอดภัย แต่ข้อความที่ลูกค้าส่งมาถามเรื่องบัญชีทั้งหมดไปกองอยู่ที่เซิร์ฟเวอร์ของบริษัทรับตอบคำถามลูกค้า (ตัวอย่างสมมติ) กรณีไดวะซีเคียวริตีส์ของญี่ปุ่นเป็นสถานการณ์แนวนี้ เพราะไดวะแจ้งเมื่อ 5 ต.ค. 2569 ว่าเซิร์ฟเวอร์ของผู้รับจ้างถูกเจาะ ขณะที่ระบบของไดวะเองไม่ถูกเจาะ
สรุปสั้น: Monogatari ประกาศเมื่อ 5 ต.ค. 2569 ว่าข้อมูลสมาชิก Yakiniku King รั่ว 10,788,963 รายการ ส่วนไดวะซีเคียวริตีส์แจ้งว่าข้อมูลลูกค้าราว 110,000 รายอาจรั่วจากเซิร์ฟเวอร์ของผู้รับจ้าง NHK รายงานว่าบริษัทความปลอดภัยรายหนึ่งมองว่า AI อาจถูกใช้โจมตี แต่ยังไม่ยืนยัน องค์กรไทยควรตรวจว่าผู้รับจ้างถือข้อมูลอะไร และกำหนดเวลาแจ้งเหตุในสัญญา
Yakiniku King และไดวะข้อมูลรั่วอย่างไร และ NHK รายงานอะไรเพิ่ม
Yakiniku King ข้อมูลรั่วจากแอปสมาชิกของบริษัท Monogatari ซึ่งประกาศเมื่อ 5 ต.ค. 2569 ว่าแอปทางการถูกเข้าถึงโดยไม่ได้รับอนุญาต ข้อมูลที่รั่วคือชื่อ อีเมล และเบอร์โทรศัพท์ของสมาชิก รวม 10,788,963 รายการ
ไดวะซีเคียวริตีส์ประกาศในวันเดียวกันว่าเซิร์ฟเวอร์ของ Scala Communications ผู้รับจ้างบริหารงานสอบถามลูกค้า ถูกเจาะตั้งแต่ 20:33 น. ของ 2 ต.ค. ถึง 08:01 น. ของ 3 ต.ค. ข้อมูลลูกค้าราว 110,000 ราย (ชื่อ อีเมล เลขบัญชี) อาจรั่ว รวมประมาณ 220,000 รายการ ไดวะแจ้งว่าระบบของตนเองไม่ถูกเจาะ
| เหตุ | ประกาศ | ข้อมูลที่ระบุ | ขนาด |
|---|---|---|---|
| Yakiniku King (Monogatari) | 5 ต.ค. 2569 | ชื่อ อีเมล เบอร์โทรศัพท์ | 10,788,963 รายการ |
| ไดวะซีเคียวริตีส์ (ผ่าน Scala Communications) | 5 ต.ค. 2569 | ชื่อ อีเมล เลขบัญชี | ลูกค้าราว 110,000 ราย รวมราว 220,000 รายการ |
| บริษัทอาหารทะเลรายหนึ่ง (NHK รวบรวม) | ช่วงเดียวกัน | ไม่ระบุ | ราว 175,000 คน |
| Daiichi Life (NHK รวบรวม) | ช่วงเดียวกัน | ข้อมูลพนักงาน | ราว 120,000 คน |
NHK รายงานเมื่อ 6 ต.ค. 2569 ว่าบริษัทความปลอดภัยรายหนึ่งพบความเสียหายเพิ่มขึ้นตั้งแต่ ก.ค. 2569 จึงมองว่ามีโอกาสสูงที่ AI ถูกใช้ในการโจมตี NHK ไม่ได้ระบุชื่อบริษัทนั้นและไม่ได้ให้ตัวเลขการเพิ่มขึ้น ข้อสรุปเรื่อง AI จึงยังไม่ยืนยัน และเหตุเหล่านี้เกิดในช่วงใกล้กัน ไม่ได้แปลว่าเกี่ยวข้องกัน
บทเรียนจาก Yakiniku King และไดวะกระทบองค์กรไทยอย่างไร
บทเรียนจาก Yakiniku King และไดวะกระทบองค์กรไทยที่ให้ผู้รับจ้างถือข้อมูลลูกค้า เพราะผู้ควบคุมข้อมูลยังต้องรับผิดชอบแม้ข้อมูลรั่วที่เซิร์ฟเวอร์ของผู้รับจ้าง ข่าวต้นทางเป็นเหตุในญี่ปุ่นและไม่ได้ระบุว่ากระทบข้อมูลในไทย แต่บริษัทญี่ปุ่นจำนวนมากมีบริษัทลูกและผู้รับจ้างในไทย ส่วนที่เหลือเป็นการวิเคราะห์ของผู้เขียน
ถ้าผู้รับจ้างถูกเจาะ องค์กรต้องรับผิดชอบอย่างไรตาม PDPA
ผู้ควบคุมข้อมูลยังเป็นฝ่ายรับผิดชอบต่อเจ้าของข้อมูล แม้การเจาะเกิดที่ผู้รับจ้าง กรณีไดวะแสดงภาพนี้ชัด เพราะระบบของไดวะเองไม่ถูกเจาะ แต่ข้อมูลลูกค้าของไดวะอาจรั่วที่ผู้รับจ้าง หลักของ PDPA ให้ผู้ควบคุมต้องมีข้อตกลงกับผู้ประมวลผลข้อมูล และให้ผู้ประมวลผลแจ้งเหตุแก่ผู้ควบคุมตามมาตรา 40
เมื่อผู้ควบคุมรู้เหตุแล้ว ยังมีหน้าที่แจ้ง สคส. ภายใน 72 ชั่วโมงตามมาตรา 37(4) ตามเงื่อนไขของกฎหมาย สัญญาจึงควรระบุว่าผู้รับจ้างต้องแจ้งภายในกี่ชั่วโมง เพราะองค์กรเริ่มประเมินเหตุไม่ได้จนกว่าจะรู้ว่าเกิดเหตุ ตัวอย่างเรื่องการแจ้งเหตุอ่านต่อได้ใน Simba Telecom สิงคโปร์ข้อมูลลูกค้ารั่ว 23,549 ราย บทเรียนเรื่องแจ้งเหตุที่ธุรกิจไทยต้องรู้
ร้านอาหาร ค้าปลีก และโบรกเกอร์ไทยควรดูอะไรในผู้รับจ้าง
ควรดู 2 เรื่อง คือผู้รับจ้างเก็บข้อมูลอะไรไว้ และสัญญากำหนดเวลาแจ้งเหตุไว้กี่ชั่วโมง เรื่องนี้ใช้กับธุรกิจที่มีแอปสมาชิก หรือจ้าง call center และระบบตอบคำถามจากภายนอก
ผู้รับจ้างอาจถือข้อมูลมากกว่าที่องค์กรนึกไว้ ในกรณีไดวะ ผู้รับจ้างงานสอบถามลูกค้าถือทั้งชื่อ อีเมล และเลขบัญชี องค์กรจึงควรขอรายการข้อมูลจริงที่ผู้รับจ้างเก็บอยู่ ไม่ใช่ดูแค่ขอบเขตงานในสัญญา แนวทางบริหารผู้รับจ้างอ่านต่อได้ใน 44 รัฐสหรัฐฯ ปรับ Labcorp $2.3M เพราะ vendor ทำข้อมูลรั่ว บทเรียน Vendor Governance ที่ธุรกิจไทยใช้ได้ทันที
ถ้า AI ถูกใช้โจมตีจริง ต้องตรวจผู้รับจ้างถี่ขึ้นไหม
ควรตรวจถี่กว่าปีละครั้ง และไม่ต้องรอให้ยืนยันเรื่อง AI ก่อน นี่เป็นมุมวิเคราะห์ของผู้เขียน ถ้าการโจมตีเร็วขึ้นจริง จุดอ่อนที่สุดคือผู้รับจ้างรายเล็กที่ถือข้อมูลของลูกค้ารายใหญ่ ตรวจปีละครั้งอาจช้าเกินไป
ถ้าองค์กรไทยไม่ตรวจผู้รับจ้างเลย จะเสี่ยงอะไร
ถ้าไม่ตรวจผู้รับจ้าง องค์กรเสี่ยงต้องตอบลูกค้าและ สคส. ทั้งที่ข้อมูลรั่วจากเซิร์ฟเวอร์ที่ตัวเองไม่เคยเห็น
- ไม่รู้ว่าข้อมูลอะไรรั่ว ถ้าไม่เคยขอรายการข้อมูลที่ผู้รับจ้างเก็บ จะแจ้งลูกค้าได้ไม่ครบ
- รู้เหตุช้า สัญญาที่ไม่มีกรอบเวลาแจ้งเหตุ ทำให้องค์กรตั้งหลักไม่ทัน
- เสียความเชื่อมั่น ลูกค้าจะโทษแบรนด์ที่เขาให้ข้อมูล ไม่ใช่ผู้รับจ้างที่เขาไม่เคยได้ยินชื่อ
องค์กรที่มีแอปสมาชิกหรือจ้างผู้รับจ้างควรทำอะไร
องค์กรควรเริ่มจากรู้ก่อนว่าข้อมูลลูกค้าอยู่ที่ไหนบ้าง แล้วค่อยแก้สัญญาและรอบการตรวจ 5 ข้อนี้ทำได้ด้วยทีมเล็กและเริ่มได้ทันที
- 1. ทำรายการผู้รับจ้างที่ถือข้อมูลลูกค้า รวม call center ระบบตอบคำถาม และผู้พัฒนาแอป พร้อมระบุว่าแต่ละรายถือข้อมูลอะไร
- 2. ขอรายการข้อมูลที่ผู้รับจ้างเก็บจริง อย่าดูแค่ขอบเขตงานในสัญญา และให้ลบข้อมูลที่ไม่จำเป็นออก
- 3. ทำสัญญาประมวลผลข้อมูลให้ชัด ระบุกรอบเวลาแจ้งเหตุเป็นชั่วโมง หน้าที่ตามมาตรา 40 และการลบข้อมูลเมื่อจบงาน
- 4. ตรวจผู้รับจ้างให้ถี่กว่าปีละครั้ง ใช้แบบตรวจแบบย่อ ถามเรื่องการป้องกัน การเข้าถึงข้อมูล และแผนรับเหตุ
- 5. ซ้อมแผนรับเหตุที่เกิดที่ผู้รับจ้าง กำหนดว่าใครแจ้งลูกค้า ใครประเมินการแจ้ง สคส. ภายใน 72 ชั่วโมงตามมาตรา 37(4)
ถ้าต้องการคนช่วยร่างสัญญาประมวลผลข้อมูลและแบบตรวจผู้รับจ้าง ดูรายละเอียดได้ที่ บริการ AI Governance และ PDPA ของ Kooru ติดตามเรื่องข้อมูลส่วนบุคคลต่อได้ที่ หมวด PDPA & Privacy
มุมมองผู้เชี่ยวชาญ
ผมมองว่าข่าวญี่ปุ่นชุดนี้ไม่ควรอ่านเป็นเรื่อง AI ก่อน เพราะเรื่อง AI ยังไม่ยืนยัน สิ่งที่ไดวะแถลงชัดคือระบบของไดวะไม่ถูกเจาะ แต่ข้อมูลลูกค้าอาจรั่วอยู่ดี ข้อมูลลูกค้าของคุณปลอดภัยเท่ากับผู้รับจ้างที่อ่อนแอที่สุดของคุณ จุดที่องค์กรมักพลาดคือตรวจระบบตัวเองละเอียด แต่ไม่เคยขอรายการข้อมูลที่ผู้รับจ้างเก็บ
— Phuwara Krobtaku —
LL.M. (IP & IT) | M.S. (IT) | Thai Barrister & Attorney-at-Law
คำถามที่พบบ่อยเกี่ยวกับ Yakiniku King
Yakiniku King ข้อมูลรั่วกี่รายการ
บริษัท Monogatari ประกาศเมื่อ 5 ต.ค. 2569 ว่าข้อมูลสมาชิกรั่ว 10,788,963 รายการ เป็นชื่อ อีเมล และเบอร์โทรศัพท์ จากแอปทางการที่ถูกเข้าถึงโดยไม่ได้รับอนุญาต
ไดวะซีเคียวริตีส์ถูกเจาะโดยตรงหรือไม่
ไดวะแจ้งว่าระบบของตนเองไม่ถูกเจาะ แต่เซิร์ฟเวอร์ของ Scala Communications ผู้รับจ้างบริหารงานสอบถามลูกค้าถูกเจาะ ข้อมูลลูกค้าราว 110,000 รายอาจรั่ว
เหตุข้อมูลรั่วในญี่ปุ่นเกิดจาก AI ใช่ไหม
ยังไม่ยืนยัน NHK รายงานว่าบริษัทความปลอดภัยรายหนึ่งมองว่ามีโอกาสสูงที่ AI ถูกใช้โจมตี แต่ไม่ได้ระบุชื่อบริษัทและไม่ได้ให้ตัวเลขการเพิ่มขึ้น
ผู้รับจ้างทำข้อมูลรั่ว องค์กรตาม PDPA ต้องรับผิดชอบไหม
ต้อง ผู้ควบคุมข้อมูลยังรับผิดชอบต่อเจ้าของข้อมูลและต้องมีข้อตกลงกับผู้ประมวลผลข้อมูล ผู้ประมวลผลต้องแจ้งเหตุให้ผู้ควบคุมทราบตามมาตรา 40 ส่วนผู้ควบคุมต้องแจ้ง สคส. ภายใน 72 ชั่วโมงตามมาตรา 37(4) ตามเงื่อนไขของกฎหมาย
แหล่งอ้างอิง
- NHK — (อ่านต้นฉบับ) — อ่านข่าวที่ NHK
- Impress Watch — (อ่านต้นฉบับ) — อ่านข่าวที่ Impress Watch
- Nissyoku — ข้อมูลประกอบ (ไม่มีลิงก์ต้นฉบับ)
บทความนี้เป็นการสรุปข่าวและให้ข้อมูลทั่วไป ไม่ใช่คำแนะนำทางกฎหมาย หากต้องการคำปรึกษาเฉพาะกรณีของธุรกิจคุณ ควรปรึกษาผู้เชี่ยวชาญ
Comments are closed.