ASOS ข้อมูลรั่ว คือกรณีที่ร้านแฟชั่นออนไลน์ ASOS แก้คำแถลงที่ออกเมื่อ 8 ตุลาคม 2569 หลัง BBC ติดต่อ จากเดิมที่บอกว่าเป็น “ข้อมูลติดต่อพื้นฐาน” มาเป็นชื่อ ที่อยู่ เบอร์โทร อีเมล เลขลูกค้า วันเกิด และประวัติค้นหา บทความอัปเดตนี้เหมาะกับร้านออนไลน์ ฝ่ายไอที และ DPO ที่ต้องเขียนคำแถลงแจ้งเหตุ
ลองนึกภาพร้านออนไลน์ไทยที่ประกาศว่าข้อมูลรั่วแค่ “ชื่อกับเบอร์โทร” แล้ววันรุ่งขึ้นต้องแก้ว่ารั่วทั้งวันเกิดและสิ่งที่ลูกค้าเคยค้นหา (ตัวอย่างสมมติ) ลูกค้าจะเชื่อประกาศฉบับต่อไปได้น้อยลง เรื่องนี้เป็นอัปเดตจาก แจ้งเตือน “ASOS HACKED” เข้าแอปลูกค้าผ่านระบบของบุคคลที่สาม ร้านออนไลน์ไทยต้องเตรียมสัญญาและแผนรับมืออย่างไร ซึ่งเล่าเหตุการณ์ป๊อปอัปแจ้งเตือนครั้งแรก
สรุปสั้น: ตามรายงานของ Silicon UK ที่อ้าง BBC ASOS ยอมรับว่าข้อมูลที่ได้รับผลกระทบกว้างกว่าคำแถลงแรก ผู้โจมตีอ้างว่าได้ข้อมูลลูกค้าอาจหลายล้านราย แต่ ASOS ยังไม่ยืนยันจำนวน ร้านออนไลน์ไทยควรใช้ MFA ที่ต้านฟิชชิง จำกัดสิทธิ์เครื่องมือการตลาด และเตรียมแม่แบบแจ้งเหตุที่ระบุประเภทข้อมูลตามจริงก่อนเกิดเหตุ
ASOS ข้อมูลรั่ว คืออะไร และมีอะไรใหม่จากบทความก่อนหน้า
ASOS ข้อมูลรั่ว มีข้อเท็จจริงใหม่สองเรื่อง คือประเภทข้อมูลที่ ASOS ยอมรับกว้างขึ้น และวิธีที่ผู้โจมตีเข้าระบบ ตามรายงานของ Silicon UK ที่อ้าง BBC ส่วนจำนวนลูกค้าเป็นข้ออ้างของผู้โจมตี ไม่ใช่ตัวเลขที่ ASOS ยืนยัน
| ประเด็น | ข้อเท็จจริงตามรายงาน |
|---|---|
| คำแถลง | ASOS แก้คำแถลงที่ออกเมื่อ 8 ตุลาคม 2569 หลัง BBC ติดต่อ |
| ข้อมูลที่ ASOS ยอมรับ | ชื่อ ที่อยู่ เบอร์โทร อีเมล เลขลูกค้า วันเกิด ประวัติค้นหา |
| จำนวนผู้ได้รับผลกระทบ | ผู้โจมตีอ้างว่าอาจหลายล้านราย ASOS ยังไม่ยืนยัน |
| วิธีเข้าระบบ | หลอกพนักงานให้ให้รหัส แล้วเข้าแพลตฟอร์มบุคคลที่สามที่ ASOS ใช้ |
| ป๊อปอัป | ถึงอุปกรณ์ลูกค้าทั่วโลกเช้า 6 ตุลาคม 2569 |
กลุ่มผู้โจมตีอ้างว่าเข้าผ่าน Snowflake ผ่านแพลตฟอร์มการตลาดที่เชื่อมกับ Snowflake ข้อนี้เป็นข้ออ้างของกลุ่มผู้โจมตี ไม่ใช่ข้อสรุปที่ผู้เขียนตรวจสอบเอง ส่วน ASOS ระบุว่าไม่พบการรั่วของรหัสผ่านและบัตร ตามรายงานทุติยภูมิ
ASOS ข้อมูลรั่ว กระทบร้านออนไลน์ไทยอย่างไร
ASOS ข้อมูลรั่ว กระทบร้านออนไลน์ไทยที่ใช้คลังข้อมูลและเครื่องมือการตลาดภายนอก เพราะเจอเส้นทางเดียวกันได้ ASOS ส่งสินค้าไทยและมีแอปให้บริการในเอเชีย ผู้ใช้ไทยอาจถูกกระทบ แต่ยังไม่มีการยืนยัน ส่วนนี้เป็นการวิเคราะห์ของผู้เขียน
คำแถลงเบื้องต้นที่ประเมินความเสียหายต่ำเกินไป เสี่ยงอะไรตาม PDPA
คำแถลงที่ประเมินต่ำแล้วต้องแก้ภายหลังเสียความน่าเชื่อถือ และเสี่ยงต่อหน้าที่แจ้งเหตุตาม PDPA มาตรา 37(4) ซึ่งให้แจ้ง สคส. ภายใน 72 ชั่วโมงนับแต่ทราบเหตุ โดยต้องระบุประเภทข้อมูลตามจริง ขั้นตอนใน 72 ชั่วโมงแรกอธิบายไว้ใน ข้อมูลรั่ว ต้องทำอะไรบ้างใน 72 ชั่วโมงแรก
ทำไมประวัติค้นหาและวันเกิดจึงต้องนับเป็นข้อมูลเสี่ยง ไม่ใช่แค่ข้อมูลติดต่อ
ประวัติค้นหาและวันเกิดบอกพฤติกรรมและตัวตนมากกว่าชื่อกับเบอร์โทร จึงใช้ทำฟิชชิงเจาะจงเป้าหมายได้ดี ข้อมูลพฤติกรรมจึงต้องนับในการประเมินความรุนแรงตั้งแต่แรก ไม่ใช่ประเมินแค่ข้อมูลติดต่อแล้วค่อยเพิ่มภายหลัง
พนักงานที่เข้าคลังข้อมูลและเครื่องมือการตลาดควรมีสิทธิ์แค่ไหน
พนักงานควรมีสิทธิ์เท่าที่งานต้องใช้ เพราะช่องทางที่ผู้โจมตีใช้คือหลอกพนักงานแล้วเข้าระบบของบุคคลที่สาม กลยุทธ์ใกล้เคียงกันปรากฏใน ThaiCERT เตือน ShinyHunters โจมตี Oracle PeopleSoft ด้วยการโทรหลอก Help Desk เพื่อขโมยข้อมูล HR และเงินเดือน องค์กรไทยต้องยืนยันตัวตนผู้โทรอย่างไร ส่วนตัวอย่างการตอบ PDPA ภายใน 72 ชั่วโมงของธุรกิจไทย ดู H.I.S. ไทยถูกเจาะ ข้อมูลพาสปอร์ตสูงสุด 627 คนอาจรั่ว ธุรกิจท่องเที่ยวไทยจะตอบ PDPA 72 ชั่วโมงได้อย่างไร
สัญญากับผู้ให้บริการแพลตฟอร์มภายนอกควรเขียนอะไรเพิ่ม
สัญญากับผู้ให้บริการภายนอกควรกำหนดหน้าที่แจ้งเหตุ ภายในกี่ชั่วโมง ต้องระบุประเภทข้อมูลอะไร และใครเป็นผู้ติดต่อ ผู้ควบคุมข้อมูลที่ส่งข้อมูลให้คนนอกทำแทนต้องมีข้อตกลงประมวลผลข้อมูลกำกับ แนวทางของญี่ปุ่นสรุปไว้ใน ญี่ปุ่นข้อมูลรั่วต่อเนื่อง skyticket 14.6 ล้าน คาราโอเกะ 8.7 ล้าน Lawson 2.16 ล้าน รัฐเรียกประชุมฉุกเฉิน สัญญา DPA ของธุรกิจไทยต้องมีข้อไหน
ถ้าไม่ทำอะไรเลย ร้านออนไลน์ไทยจะเสี่ยงอะไรจากกรณี ASOS ข้อมูลรั่ว
ถ้าไม่ทำอะไร ร้านออนไลน์เสี่ยงให้ผู้โจมตีหลอกพนักงานแล้วเข้าคลังข้อมูลได้เช่นเดียวกัน และเสี่ยงที่แม่แบบแจ้งเหตุมีแต่ข้อมูลติดต่อ ทำให้คำแถลงแรกประเมินต่ำ
ผลที่ตามมาคือต้องแก้ประกาศภายหลัง ลูกค้าเชื่อน้อยลง และผู้ถูกกระทบไม่รู้ว่าต้องระวังฟิชชิงที่ใช้วันเกิดหรือประวัติค้นหา
ร้านออนไลน์ที่ใช้คลังข้อมูลและเครื่องมือการตลาดควรทำอะไรตอนนี้
ร้านออนไลน์ที่ใช้คลังข้อมูลและเครื่องมือการตลาดควรทำ 4 เรื่องนี้ เพื่อไม่ให้เจอเหตุแบบ ASOS ข้อมูลรั่ว
- 1. ใช้ MFA ที่ต้านฟิชชิงกับบัญชีพนักงานที่เข้าคลังข้อมูล ใช้กุญแจความปลอดภัยหรือพาสคีย์ แทนรหัสครั้งเดียวทาง SMS
- 2. จำกัดสิทธิ์และเก็บ log เครื่องมือ marketing และ analytics ให้สิทธิ์เท่าที่งานต้องใช้ และตรวจว่าใครเข้าอะไรเมื่อไร
- 3. ซ้อมรับมือการหลอกพนักงาน ทดสอบโทรหรือส่งข้อความหลอกพนักงานแบบ social engineering แล้วดูว่าใครยืนยันตัวตนผู้ติดต่อก่อนให้รหัสหรือไม่
- 4. ร่างแม่แบบแจ้งเหตุที่ระบุประเภทข้อมูลครบ รวมข้อมูลพฤติกรรมอย่างประวัติค้นหา ไม่ใช่แค่ข้อมูลติดต่อ และเตรียมถ้อยคำที่ไม่ประเมินต่ำ
ถ้าต้องการคนช่วยวางแผนรับมือและเอกสาร ดูได้ที่ บริการ AI Governance และ PDPA ของ Kooru
มุมมองผู้เชี่ยวชาญ
ข้อสังเกตเชิงวิชาชีพของผมคือ ความเสียหายครั้งที่สองมักมาจากคำแถลงครั้งแรก คำว่า “ข้อมูลติดต่อพื้นฐาน” ที่ต้องแก้ทีหลังหนักกว่าการบอกความจริงที่ยังไม่ครบตั้งแต่ต้น จุดที่องค์กรมักพลาดคือแม่แบบแจ้งเหตุที่เขียนไว้ล่วงหน้าบอกแค่ชื่อกับเบอร์โทร ควรเขียนให้ครอบคลุมข้อมูลพฤติกรรม และเขียนตรง ๆ ว่ากำลังตรวจสอบอะไรอยู่
— Phuwara Krobtaku —
LL.M. (IP & IT) | M.S. (IT) | Thai Barrister & Attorney-at-Law
คำถามที่พบบ่อยเกี่ยวกับ ASOS ข้อมูลรั่ว
ASOS ข้อมูลรั่ว มีข้อมูลอะไรบ้างตามที่ ASOS ยอมรับ
ตามรายงาน ASOS ยอมรับว่ามีชื่อ ที่อยู่ เบอร์โทร อีเมล เลขลูกค้า วันเกิด และประวัติค้นหา หลังแก้คำแถลงจากที่เคยบอกว่าเป็นข้อมูลติดต่อพื้นฐาน
ผู้ใช้ไทยของ ASOS ถูกกระทบหรือไม่
ยังไม่มีการยืนยัน ASOS ส่งสินค้าไทยและมีแอปให้บริการในเอเชีย ผู้ใช้ไทยจึงอาจได้รับผลกระทบ แต่ไม่มีรายงานที่ยืนยันจำนวนหรือประเทศของผู้ถูกกระทบ
ผู้โจมตีเข้าระบบของ ASOS ได้อย่างไร
ตามรายงาน ผู้โจมตีปลอมตัวเป็นผู้ติดต่อที่ไว้ใจได้ หลอกพนักงานให้ให้รหัสเข้าระบบ แล้วเข้าแพลตฟอร์มของบุคคลที่สามที่ ASOS ใช้ กลุ่มผู้โจมตีอ้างว่าเป็น Snowflake ผ่านแพลตฟอร์มการตลาดที่เชื่อมกับ Snowflake
ร้านออนไลน์ไทยต้องแจ้ง สคส. ภายในกี่ชั่วโมงเมื่อข้อมูลรั่ว
ต้องแจ้ง สคส. ภายใน 72 ชั่วโมงนับแต่ทราบเหตุ ตามมาตรา 37(4) ของ PDPA ถ้าเหตุนั้นมีความเสี่ยงต่อสิทธิของเจ้าของข้อมูล และถ้าความเสี่ยงสูงต้องแจ้งเจ้าของข้อมูลด้วย โดยควรระบุประเภทข้อมูลที่รั่วตามจริง
อ่านต่อ: ความรู้ที่เกี่ยวกับเรื่องนี้
- จดหมายแจ้งเจ้าของข้อมูลเมื่อข้อมูลรั่ว ต้องมีอะไรบ้าง — ใช้เป็นกรอบเขียนจดหมายแจ้งลูกค้าที่ระบุประเภทข้อมูลที่รั่วตามจริง ไม่ประเมินต่ำ (aipdpa.com)
- สัญญาประมวลผลข้อมูลส่วนบุคคล (ผู้ควบคุม–ผู้ประมวลผล) ต้องมีอะไรบ้าง — ใช้ตรวจสัญญากับผู้ให้บริการคลังข้อมูลและแพลตฟอร์มการตลาดที่รับข้อมูลลูกค้าไปประมวลผล (ok.aipdpa.com)
แหล่งอ้างอิง
- Silicon UK (อ้างรายงานของ BBC) — (อ่านต้นฉบับ) — อ่านข่าวที่ Silicon UK
บทความนี้เป็นการสรุปข่าวและให้ข้อมูลทั่วไป ไม่ใช่คำแนะนำทางกฎหมาย หากต้องการคำปรึกษาเฉพาะกรณีของธุรกิจคุณ ควรปรึกษาผู้เชี่ยวชาญ
