Nikkei ข้อมูลรั่ว คือเหตุที่ผู้บุกรุกใช้รหัสผ่านที่ถูกขโมยเข้าระบบ development ของ Nikkei สื่อธุรกิจรายใหญ่ของญี่ปุ่น แล้วเข้าถึงข้อมูล 1.83 ล้านระเบียน นับเป็นเหตุครั้งที่ 3 ต่อจากเหตุในเดือนกรกฎาคมและกันยายน บทความนี้เหมาะกับฝ่ายไอที ทีมพัฒนาซอฟต์แวร์ และ DPO อ่านแล้วจะรู้ว่าระบบทดสอบเป็นช่องรั่วได้อย่างไร
ลองนึกภาพบริษัทประกันไทยที่ทีมพัฒนาก๊อปฐานข้อมูลลูกค้าจริงไปไว้ในเซิร์ฟเวอร์ทดสอบ เพื่อให้ทดสอบระบบใหม่ได้สมจริง เซิร์ฟเวอร์นั้นไม่มี MFA และไม่มีใครเฝ้าดู แค่รหัสผ่านของนักพัฒนาคนเดียวหลุด ข้อมูลลูกค้าทั้งฐานก็เปิดให้คนนอก (ตัวอย่างสมมติ)
สรุปสั้น: Nikkei รายงานว่าผู้บุกรุกใช้ credential ที่ถูกขโมยเข้าระบบ development เมื่อ 7 ตุลาคม 2569 และเข้าถึง 1.83 ล้านระเบียน ระบุตัวตนได้ 150,000 ราย เป็นเหตุครั้งที่ 3 ขององค์กร องค์กรไทยควรเลิกใช้ข้อมูลจริงในระบบทดสอบ บังคับ MFA และหมุน credential เพราะ PDPA มาตรา 37(1) ใช้กับทุกระบบที่มีข้อมูลส่วนบุคคล
Nikkei ข้อมูลรั่ว เกิดอะไรขึ้น ข้อมูลอะไรหลุด
Nikkei ข้อมูลรั่วครั้งนี้เริ่มจากผู้บุกรุกใช้ credential ที่ถูกขโมยเข้าระบบ development เมื่อ 7 ตุลาคม 2569 (ค.ศ. 2026) ตามรายงานของ BleepingComputer และ SecurityWeek ผู้บุกรุกเข้าถึง 1.83 ล้านระเบียน ในจำนวนนี้ระบุตัวตนได้ 150,000 ราย เป็นอีเมล 120,000 รายการ และไม่มีข้อมูลบัตร
Nikkei แจ้งคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลของญี่ปุ่น (PPC) เมื่อ 11 ตุลาคม เหตุนี้เป็นครั้งที่ 3 ต่อจากเหตุเดือนกรกฎาคมที่เกี่ยวกับ Google Workspace และเหตุเดือนกันยายนที่เกี่ยวกับ Microsoft 365
| ประเด็น | ข้อเท็จจริงตามรายงาน |
|---|---|
| ทางเข้า | credential ที่ถูกขโมย เข้าระบบ development |
| วันที่เข้าระบบ / แจ้ง PPC | 7 ต.ค. / 11 ต.ค. 2569 |
| ระเบียนที่ถูกเข้าถึง | 1.83 ล้านระเบียน ระบุตัวตนได้ 150,000 ราย |
| อีเมล / ข้อมูลบัตร | อีเมล 120,000 รายการ / ไม่มีข้อมูลบัตร |
| เหตุก่อนหน้า | ก.ค. (Google Workspace) และ ก.ย. (Microsoft 365) |
Nikkei ข้อมูลรั่ว กระทบองค์กรไทยอย่างไร
Nikkei ข้อมูลรั่ว กระทบองค์กรไทยในฐานะคำเตือน เพราะการก๊อปข้อมูลลูกค้าจริงไปไว้ในระบบทดสอบเป็นวิธีทำงานที่พบได้ในทีมพัฒนาซอฟต์แวร์จำนวนมาก ส่วนนี้เป็นการวิเคราะห์ของผู้เขียน
ทำไมระบบทดสอบจึงเป็นช่องรั่วที่องค์กรไทยมองข้าม
ระบบทดสอบมักถูกมองว่า “ไม่ใช่ของจริง” จึงได้มาตรการป้องกันน้อยกว่า ไม่มี MFA ไม่มีการเฝ้าดู และเปิดสิทธิ์ให้คนจำนวนมาก แต่ถ้าในระบบมีข้อมูลลูกค้าจริง ความเสียหายเมื่อรั่วเท่ากับระบบจริงทุกประการ กรณี Nikkei แสดงว่ารหัสผ่านที่หลุดเพียงชุดเดียวเปิดทางไปสู่ 1.83 ล้านระเบียนได้
บริษัทซอฟต์แวร์และ outsource ที่ทดสอบระบบให้ลูกค้าเสี่ยงอะไร
บริษัทที่รับพัฒนาระบบให้ลูกค้ามักได้รับข้อมูลจริงมาทดสอบ ถ้าข้อมูลรั่วจากเครื่องของผู้รับจ้าง ลูกค้าในฐานะผู้ควบคุมข้อมูลยังต้องรับผิดชอบการแจ้งเหตุ คำถามว่าใครต้องแจ้งใครเมื่อผู้รับจ้างทำข้อมูลรั่ว อธิบายไว้ใน ผู้รับจ้างทำข้อมูลรั่ว ใครต้องแจ้งใคร ภายในกี่ชั่วโมง
ข้อมูลรั่วซ้ำหลายครั้ง ทำให้ความเสี่ยงทางกฎหมายหนักขึ้นไหม
ผู้เขียนมองว่าหนักขึ้น เพราะเหตุซ้ำเป็นหลักฐานว่ามาตรการที่มีอยู่ยังไม่เหมาะสม เมื่อองค์กรอ้างว่าได้ทำมาตรการรักษาความปลอดภัยแล้ว เหตุครั้งที่ 2 และ 3 จะทำให้ข้ออ้างนั้นอ่อนลง และอาจถูกนำมาพิจารณาในการกำหนดโทษ
อีเมลที่หลุด 120,000 รายการ กระทบคนทั่วไปอย่างไร
อีเมลที่หลุดเป็นวัตถุดิบของอีเมลหลอกลวง ผู้ที่ได้รับผลกระทบอาจได้รับอีเมลที่อ้างชื่อ Nikkei หรือบริการที่เกี่ยวข้อง คนไทยที่สมัครบริการของสื่อต่างประเทศควรระวังลิงก์ที่ขอรหัสผ่าน ปัญหารหัสผ่านถูกใช้ซ้ำเคยเกิดในภาคธนาคารใน เกาหลีใต้สั่งสอบแฮกแบงก์ 6 แห่ง Shinhan รั่ว 25,000 ราย เหตุ credential stuffing
เทียบกับกฎหมายไทย: Nikkei ข้อมูลรั่ว ต่างจาก PDPA อย่างไร
กฎหมายญี่ปุ่นและไทยวางหน้าที่คล้ายกัน คือรักษาความปลอดภัยและแจ้งหน่วยงานกำกับ แต่ PDPA ของไทยกำหนดกรอบเวลาแจ้งเหตุไว้ชัดที่ 72 ชั่วโมง
| ประเด็น | กรณี Nikkei | กฎหมายไทย |
|---|---|---|
| มาตรการความปลอดภัย | credential ถูกขโมยเข้าระบบ dev | PDPA มาตรา 37(1) มาตรการรักษาความมั่นคงปลอดภัย |
| แจ้งหน่วยงานกำกับ | เข้าระบบ 7 ต.ค. แจ้ง PPC 11 ต.ค. | PDPA มาตรา 37(4) แจ้ง สคส. ภายใน 72 ชม. นับแต่ทราบเหตุ |
| เข้าระบบโดยมิชอบ | ใช้รหัสผ่านที่ขโมยมา | พ.ร.บ.คอมพิวเตอร์ มาตรา 5 เข้าถึงระบบโดยมิชอบ |
| เหตุซ้ำ | ครั้งที่ 3 ต่อจาก ก.ค. และ ก.ย. | ใช้ประกอบการพิจารณาว่ามาตรการเหมาะสมหรือไม่ |
ช่องว่างของไทยคือ PDPA ไม่ได้แยกระบบทดสอบออกจากระบบจริง ทุกระบบที่มีข้อมูลส่วนบุคคลต้องมีมาตรการตามมาตรา 37(1) แต่หลายองค์กรเขียนนโยบายความปลอดภัยครอบคลุมเฉพาะระบบจริง ทำให้ระบบทดสอบหลุดจากการตรวจ
ถ้าไม่ทำอะไรเลย องค์กรไทยเสี่ยงอะไร
ถ้าไม่ทำอะไร องค์กรเสี่ยงให้ระบบทดสอบกลายเป็นประตูหลังของข้อมูลลูกค้าทั้งฐาน และเมื่อเกิดเหตุ จะอธิบายต่อ สคส. ยากว่าทำไมข้อมูลจริงไปอยู่ในระบบที่ป้องกันน้อยกว่า
ถ้าเกิดเหตุซ้ำ ความเสียหายด้านชื่อเสียงจะทบกัน ลูกค้าจะไม่ถามแค่ว่า “รั่วอะไร” แต่จะถามว่า “ทำไมรั่วอีก”
ทีมไอทีและ DPO ไทยควรทำอะไรตอนนี้
ทีมไอทีและ DPO ควรทำ 5 เรื่องต่อไปนี้ เพื่อไม่ให้เหตุแบบ Nikkei ข้อมูลรั่วเกิดจากระบบทดสอบของตัวเอง
- 1. ห้ามใช้ข้อมูลจริงในระบบ dev และ test ใช้ข้อมูลสังเคราะห์หรือข้อมูลที่ปิดบังตัวตนแล้วแทน
- 2. บังคับ MFA ทุกบัญชีที่เข้าระบบ dev รวมถึงบัญชีของผู้รับจ้างภายนอก
- 3. หมุน credential ตามรอบและทันทีเมื่อสงสัย ยกเลิกบัญชีที่ไม่ได้ใช้และกุญแจที่ฝังในโค้ด
- 4. ใส่ระบบทดสอบในนโยบายความปลอดภัยและ RoPA ให้ระบบทดสอบถูกตรวจเหมือนระบบจริง
- 5. ซ้อมแผนแจ้งเหตุ 72 ชั่วโมง ทดสอบว่าทีมรู้ว่าต้องแจ้ง สคส. เมื่อไรและอย่างไร
ก่อนเริ่ม ลองใช้ เครื่องมือสแกนความเสี่ยงเว็บไซต์ของ Kooru เพื่อดูจุดเปิดเผยบนเว็บไซต์ แนวทาง MFA ในบริบทไทยดูเพิ่มได้ใน MFA และ PDPA สัญญาณเตือนองค์กรไทย จากข้อมูลรั่วถึงแฟ้มกระดาษ
มุมมองผู้เชี่ยวชาญ
เหตุของ Nikkei บอกว่าคนร้ายไม่จำเป็นต้องเจาะประตูหน้า ถ้าประตูหลังเปิดอยู่ ระบบทดสอบที่มีข้อมูลลูกค้าจริงไม่ใช่ระบบทดสอบ มันคือระบบจริงที่ไม่มียาม จุดที่องค์กรมักพลาดคือคิดว่ามาตรการความปลอดภัยใช้กับระบบที่ลูกค้าเห็นเท่านั้น ควรเช็กว่าข้อมูลจริงถูกก๊อปไปอยู่ในเซิร์ฟเวอร์ไหนบ้าง
— Phuwara Krobtaku —
LL.M. (IP & IT) | M.S. (IT) | Thai Barrister & Attorney-at-Law
ประวัติผู้เขียน · นโยบายบรรณาธิการ
คำถามที่พบบ่อยเกี่ยวกับ Nikkei ข้อมูลรั่ว
Nikkei ข้อมูลรั่วกี่รายการ มีข้อมูลบัตรหรือไม่
ผู้บุกรุกเข้าถึง 1.83 ล้านระเบียน ระบุตัวตนได้ 150,000 ราย เป็นอีเมล 120,000 รายการ และไม่มีข้อมูลบัตร
ผู้บุกรุกเข้าระบบ Nikkei ได้อย่างไร
ผู้บุกรุกใช้ credential ที่ถูกขโมยเข้าระบบ development เมื่อ 7 ตุลาคม 2569 แล้ว Nikkei แจ้ง PPC ญี่ปุ่นเมื่อ 11 ตุลาคม
ใช้ข้อมูลลูกค้าจริงในระบบทดสอบผิด PDPA หรือไม่
PDPA ไม่ได้ห้ามตรง ๆ แต่ระบบทดสอบที่มีข้อมูลจริงต้องมีมาตรการรักษาความปลอดภัยตามมาตรา 37(1) เหมือนระบบจริง และการใช้ข้อมูลต้องอยู่ในวัตถุประสงค์ที่แจ้งไว้ตามมาตรา 21 ทางที่ปลอดภัยกว่าคือใช้ข้อมูลสังเคราะห์
องค์กรไทยต้องแจ้ง สคส. ภายในกี่ชั่วโมงถ้าระบบทดสอบรั่ว
ต้องแจ้งภายใน 72 ชั่วโมงนับแต่ทราบเหตุตาม PDPA มาตรา 37(4) ถ้าเหตุมีความเสี่ยงต่อสิทธิและเสรีภาพของเจ้าของข้อมูล ไม่ว่าข้อมูลจะรั่วจากระบบจริงหรือระบบทดสอบ
อ่านต่อ: ความรู้ที่เกี่ยวกับเรื่องนี้
- ซ้อมรับมือข้อมูลรั่วทั้งบริษัท ครึ่งวันก็พอ — วิธีจัดซ้อมแผนแจ้งเหตุให้ทีมพร้อมก่อนเกิดเหตุจริง (aipdpa.com)
แหล่งอ้างอิง
- BleepingComputer — (อ่านต้นฉบับ) — อ่านข่าวที่ BleepingComputer
- SecurityWeek — (brief ไม่ได้ให้ลิงก์)
บทความนี้เป็นการสรุปข่าวและให้ข้อมูลทั่วไป ไม่ใช่คำแนะนำทางกฎหมาย หากต้องการคำปรึกษาเฉพาะกรณีของธุรกิจคุณ ควรปรึกษาผู้เชี่ยวชาญ
