แอปทางรัฐ แจ้งเตือนซ้ำ คือเหตุที่ผู้ลงทะเบียนเยียวยาน้ำท่วมได้รับข้อความจากแอปทางรัฐซ้ำหลายครั้ง สำนักงานพัฒนารัฐบาลดิจิทัล (DGA) ชี้ว่าต้นเหตุคือคิวส่งข้อความค้าง ไม่ใช่การถูกแฮก บทความนี้เหมาะกับฝ่าย PDPA ฝ่ายไอที และธุรกิจที่ส่ง SMS หรือ LINE หาลูกค้าจำนวนมาก อ่านแล้วจะรู้ว่าเหตุแบบนี้ต้องประเมินอย่างไรตาม PDPA
ลองนึกภาพว่าแม่ค้าออนไลน์ส่งแจ้งเตือนโปรโมชันถึงลูกค้าหลายหมื่นคน แล้วระบบค้าง ข้อความเดิมวนส่งซ้ำไม่หยุด เรื่องแบบนี้เกิดกับระบบรัฐสัปดาห์นี้ ต่อจากข่าวลงทะเบียนเยียวยาน้ำท่วมที่เราเขียนไว้ใน รัฐเปิดลงทะเบียนเยียวยาน้ำท่วม 9,000 บาทผ่านแอปทางรัฐ 65 จังหวัดและกรุงเทพฯ องค์กรควรเตือนพนักงานเรื่องลิงก์ปลอมและข้อมูลส่วนบุคคลอย่างไร
สรุปสั้น: DGA ระบุว่าข้อความเยียวยาน้ำท่วมถูกส่งซ้ำเพราะคิวระบบแจ้งเตือนคับคั่ง และ DGA กับ ปภ. ยืนยันว่าระบบไม่ถูกแฮก ไม่มีข้อมูลรั่ว แต่ “ไม่ถูกแฮก” ไม่ได้ตอบแทนการประเมินเหตุตาม PDPA ซึ่งผู้ควบคุมข้อมูลต้องทำเอง องค์กรที่ส่งข้อความหาลูกค้าจำนวนมากควรมีเพดานการส่ง ปุ่มหยุดฉุกเฉิน และขั้นตอนประเมินเหตุที่เขียนไว้ล่วงหน้า
แอปทางรัฐ แจ้งเตือนซ้ำเพราะอะไร และมีข้อมูลรั่วหรือไม่
แอปทางรัฐ แจ้งเตือนซ้ำเพราะคิวระบบแจ้งเตือนคับคั่งเมื่อส่งข้อความถึงผู้ใช้หลายแสนรายพร้อมกัน ตามคำชี้แจงของ DGA และเจ้าหน้าที่ยืนยันว่าไม่มีข้อมูลรั่ว ข้อความส่งออกจากระบบรัฐถึงผู้รับเดิมเท่านั้น
DGA อธิบายว่าแม้สั่งหยุดส่งแล้ว ข้อความที่ค้างอยู่ในคิวก็ถูกส่งซ้ำโดยอัตโนมัติจนคิวหมด ทั้ง DGA และ ปภ. ยืนยันว่า “ระบบไม่ถูกแฮก ไม่มีข้อมูลรั่ว” DGA ยังปิดระบบลงทะเบียนวันที่ 3 ต.ค. เวลา 21:00–24:00 เพื่อปรับปรุง ต้นทางข่าวไม่ได้อ้างอิง PDPA และไม่มีตัวเลขว่ามีผู้ได้รับข้อความซ้ำกี่ราย
| ประเด็น | ข้อเท็จจริงตามข่าว |
|---|---|
| ผู้ลงทะเบียนเยียวยาทั่วประเทศ | 851,547 ราย (ณ 4 ต.ค. เวลา 08:30) |
| ในกรุงเทพฯ | 371,775 ราย (ตามรายงานไทยโพสต์) |
| สาเหตุที่ DGA ชี้ | คิวแจ้งเตือนคับคั่ง ข้อความที่ค้างถูกส่งซ้ำเองหลังหยุดส่ง |
| คำยืนยันของ DGA และ ปภ. | ไม่ถูกแฮก ไม่มีข้อมูลรั่ว |
| ปิดระบบลงทะเบียน | 3 ต.ค. เวลา 21:00–24:00 |
แอปทางรัฐ แจ้งเตือนซ้ำ กระทบองค์กรและคนทั่วไปอย่างไร
แอปทางรัฐ แจ้งเตือนซ้ำเป็นเหตุด้านความพร้อมใช้งานและความถูกต้องของระบบ ไม่ใช่เหตุข้อมูลรั่ว แต่ผู้ควบคุมข้อมูลยังต้องมีขั้นตอนประเมินเหตุเสมอ ส่วนนี้เป็นการวิเคราะห์ของผู้เขียน แยกตามกลุ่มที่ได้รับผลกระทบ
“ระบบไม่ถูกแฮก” เท่ากับ “ไม่ใช่เหตุละเมิดข้อมูลส่วนบุคคล” ใช่หรือไม่
ไม่เท่ากัน เพราะคำว่า “ไม่ถูกแฮก” ตอบแค่ว่าไม่มีคนนอกบุกเข้าระบบ แต่การประเมินว่าเป็นเหตุละเมิดข้อมูลส่วนบุคคลหรือไม่เป็นหน้าที่ของผู้ควบคุมข้อมูลตาม PDPA ระบบรัฐนี้ประมวลผลข้อมูลผู้ประสบภัยหลายแสนคน จึงควรมีบันทึกการประเมินที่ตอบได้ว่าเหตุเข้าข่ายหรือไม่
ต้องเขียนเหตุผลลงเอกสารเสมอ แม้สุดท้ายประเมินว่าไม่ต้องแจ้ง สคส. ตามมาตรา 37(4) ซึ่งกำหนดกรอบ 72 ชั่วโมงนับจากทราบเหตุ ผู้เขียนยังไม่ยืนยันว่าประกาศ สคส. นับเหตุด้านความพร้อมใช้งานเป็นการละเมิดหรือไม่ จึงควรเปิดประกาศฉบับล่าสุดตรวจก่อน
ธุรกิจที่ส่ง SMS หรือ LINE หาลูกค้าจำนวนมากเสี่ยงอะไร
ธุรกิจที่ส่งแจ้งเตือนจำนวนมากเสี่ยงเจอคิวค้างแบบเดียวกัน และข้อความซ้ำหรือผิดผู้รับสร้างความตื่นตระหนก ตัวอย่างสมมติ: ร้านค้าออนไลน์ส่งข้อความยืนยันคำสั่งซื้อถึงลูกค้า 50,000 คนพร้อมกัน ระบบค้างแล้วส่งซ้ำ 3 รอบ ลูกค้าจะคิดว่าถูกตัดเงินซ้ำ แล้วโทรเข้าคอลเซ็นเตอร์พร้อมกัน
สัญญากับผู้ให้บริการส่งข้อความจึงควรถามให้ชัดว่า ใครคุมเพดานการส่ง ใครกดหยุดได้ และหยุดแล้วคิวที่ค้างถูกล้างหรือไม่
คนทั่วไปควรระวังอะไรเมื่อได้รับข้อความซ้ำ
คนทั่วไปควรระวังมิจฉาชีพที่ฉวยโอกาสจากความสับสน เพราะข้อความซ้ำหรือผิดผู้รับเปิดช่องให้ข้อความปลอมแทรกเข้ามาได้ง่าย ผู้ที่รอเงินเยียวยามีแนวโน้มกดลิงก์เร็วกว่าปกติ
หลักง่าย ๆ คือ ตรวจสถานะผ่านแอปหรือช่องทางทางการที่เคยใช้ลงทะเบียน และไม่กดลิงก์จากข้อความแปลก ๆ
ถ้าไม่ทำอะไรเลย จะเสี่ยงอะไร
ถ้าไม่เตรียมรับมือแอปทางรัฐ แจ้งเตือนซ้ำแบบเดียวกัน องค์กรจะเจอเหตุคิวค้างโดยไม่มีปุ่มหยุดและไม่มีขั้นตอนประเมิน ทำให้ตอบลูกค้าและหน่วยงานกำกับช้า ความเสี่ยงแรกคือข้อความซ้ำทำลูกค้าตื่นตระหนกและเสียความเชื่อมั่น ความเสี่ยงที่สองคือมิจฉาชีพใช้จังหวะสับสนส่งข้อความปลอมแทรก ความเสี่ยงที่สามคือไม่มีบันทึกการประเมิน จึงอธิบาย สคส. ไม่ได้ว่าทำไมจึงไม่แจ้งเหตุ
องค์กรที่ส่งแจ้งเตือนถึงลูกค้าจำนวนมากควรทำอะไรตอนนี้
องค์กรควรเริ่มจากระบบส่งข้อความของตัวเอง เพราะแก้ได้ทันทีโดยไม่ต้องรอประกาศใหม่ ใช้กรณีแอปทางรัฐ แจ้งเตือนซ้ำเป็นกรณีศึกษาในเวิร์กชอปรับมือเหตุได้เลย เพราะแสดงชัดว่าเหตุแบบไหนต้องแจ้งตามมาตรา 37(4) และแบบไหนไม่ต้อง
- 1. ตั้งเพดานการส่ง (rate limit) กำหนดจำนวนข้อความต่อนาทีที่ระบบส่งได้ และทดสอบด้วยรายชื่อจำนวนมากก่อนใช้งานจริง
- 2. ทำปุ่มหยุดฉุกเฉินที่ล้างคิวได้จริง ทดสอบว่ากดหยุดแล้วข้อความที่ค้างไม่ถูกส่งซ้ำ ไม่ใช่หยุดแค่รอบใหม่
- 3. เตรียมแผนสื่อสารและแม่แบบข้อความแก้ไข ระบุว่าใครอนุมัติ ส่งทางช่องไหน และเตือนลูกค้าให้ตรวจสถานะผ่านช่องทางทางการเท่านั้น
- 4. เขียนขั้นตอนประเมินเหตุตามมาตรา 37(4) กำหนดว่าใครประเมินภายในกี่ชั่วโมง ใช้เกณฑ์อะไรตัดสินว่าต้องแจ้ง สคส. และบันทึกเหตุผลทุกครั้ง แม้ผลคือไม่ต้องแจ้ง
ถ้าองค์กรต้องการคนช่วยเขียนขั้นตอนประเมินเหตุและแผนแจ้งเหตุ ดูรายละเอียดได้ที่ บริการ AI Governance และ PDPA ของ Kooru และติดตามประเด็นต่อได้ที่ หมวด PDPA & Privacy
มุมมองผู้เชี่ยวชาญ
สิ่งที่ผมอยากให้องค์กรอ่านจากข่าวนี้ไม่ใช่เรื่องแอปรัฐ แต่คือคำว่า “ไม่ถูกแฮก” ที่ฟังแล้วโล่งใจเกินเหตุ จุดที่องค์กรมักพลาดคือเอาคำนี้ไปแทนการประเมิน ทั้งที่ PDPA ให้ผู้ควบคุมข้อมูลเป็นคนตอบเอง คำว่า “ไม่ถูกแฮก” ตอบแค่ว่าใครไม่ได้เข้า แต่ไม่ได้ตอบว่าองค์กรต้องทำอะไรต่อ ผมจึงอยากให้ทุกองค์กรมีแบบฟอร์มประเมินเหตุหนึ่งหน้า เขียนเหตุผลทุกครั้ง แม้ผลคือไม่ต้องแจ้ง
— Phuwara Krobtaku —
LL.M. (IP & IT) | M.S. (IT) | Thai Barrister & Attorney-at-Law
คำถามที่พบบ่อยเกี่ยวกับแอปทางรัฐ แจ้งเตือนซ้ำ
แอปทางรัฐ แจ้งเตือนซ้ำเพราะระบบถูกแฮกหรือเปล่า
ไม่ใช่ตามคำชี้แจงของ DGA ซึ่งระบุว่าต้นเหตุคือคิวระบบแจ้งเตือนคับคั่ง ทั้ง DGA และ ปภ. ยืนยันว่าระบบไม่ถูกแฮกและไม่มีข้อมูลรั่ว ข้อมูลนี้มาจากคำแถลงของหน่วยงานเอง
ข้อมูลผู้ลงทะเบียนเยียวยาน้ำท่วมรั่วไหลไหม
DGA และ ปภ. ยืนยันว่าไม่มีข้อมูลรั่ว และข้อความส่งออกจากระบบรัฐถึงผู้รับเดิมเท่านั้น ต้นทางข่าวไม่ได้ระบุว่ามีการตรวจสอบจากหน่วยงานภายนอก และไม่มีตัวเลขผู้ได้รับข้อความซ้ำ
เหตุแบบนี้ต้องแจ้ง สคส. ภายใน 72 ชั่วโมงไหม
ต้องดูว่าเหตุเข้านิยามการละเมิดข้อมูลส่วนบุคคลหรือไม่ และมีความเสี่ยงต่อสิทธิของเจ้าของข้อมูลหรือเปล่า มาตรา 37(4) กำหนดให้แจ้งภายใน 72 ชั่วโมงนับจากทราบเหตุ ต้นทางไม่ได้บอกว่าหน่วยงานรัฐประเมินอย่างไร ผู้เขียนจึงไม่สรุปแทน
ได้รับข้อความซ้ำควรทำอย่างไร
ตรวจสถานะผ่านแอปหรือช่องทางทางการที่เคยใช้ลงทะเบียน และไม่กดลิงก์จากข้อความแปลก ๆ มิจฉาชีพมักฉวยจังหวะที่คนสับสนกับข้อความซ้ำเพื่อส่งข้อความปลอมแทรกเข้ามา
แหล่งอ้างอิง
- กรุงเทพธุรกิจ — (อ่านต้นฉบับ) — อ่านข่าวที่กรุงเทพธุรกิจ
- ไทยโพสต์ — (อ่านต้นฉบับ) — อ่านข่าวที่ไทยโพสต์
บทความนี้เป็นการสรุปข่าวและให้ข้อมูลทั่วไป ไม่ใช่คำแนะนำทางกฎหมาย หากต้องการคำปรึกษาเฉพาะกรณีของธุรกิจคุณ ควรปรึกษาผู้เชี่ยวชาญ
