ข้อมูลคนไทย 66 ล้านคนหลุด

ทางเทคนิค — เกิดขึ้นได้อย่างไร?

ข้อมูลรั่วไหลขนาดใหญ่ไม่ได้เกิดจากสาเหตุเดียว แต่มักเป็นการรวมกันของหลายจุดอ่อนในระบบ จากการวิเคราะห์เหตุการณ์ที่ผ่านมา สาเหตุหลักๆ ที่พบในระบบ IT ภาครัฐไทยมีดังนี้:

1. API ไม่มีระบบยืนยันตัวตน (Broken Authentication)

หลายระบบเปิด API endpoint ให้เรียกข้อมูลได้โดยไม่ต้อง login หรือใช้แค่ API Key ง่ายๆ ที่ไม่มีการหมุนเวียน แฮกเกอร์สามารถเขียน script ดูดข้อมูลทีละ record ได้ตลอด 24 ชั่วโมง โดยระบบไม่มี rate limiting หรือการแจ้งเตือนว่ามีการเรียกข้อมูลจำนวนผิดปกติ

2. SQL Injection ที่ยังไม่ถูกแก้ไข

SQL Injection เป็นช่องโหว่ที่ถูกค้นพบมากว่า 25 ปี แต่ยังพบได้ทั่วไปในเว็บแอปพลิเคชันภาครัฐ เมื่อระบบไม่ใช้ Parameterized Query แฮกเกอร์สามารถแทรกคำสั่ง SQL ผ่านช่องกรอกข้อมูลหรือ URL แล้วดึงฐานข้อมูลทั้งหมดออกมาได้ในครั้งเดียว

3. ฐานข้อมูลเปิดสาธารณะ (Misconfigured Database)

ฐานข้อมูลหลายแห่ง (เช่น MongoDB, Elasticsearch) ถูกตั้งค่าให้เข้าถึงได้จาก internet โดยไม่ต้องใส่รหัสผ่าน สาเหตุมักมาจากการ deploy แบบ default config โดยไม่ได้เปลี่ยนค่า binding address หรือไม่ได้ตั้ง firewall ให้ถูกต้อง มีเครื่องมืออย่าง Shodan หรือ Censys ที่ scan หาฐานข้อมูลเปิดทั่วโลกได้ตลอดเวลา

4. Insider Threat — ภัยจากคนใน

ในหลายกรณี ข้อมูลไม่ได้ถูกแฮกจากภายนอก แต่ถูก "ยกออก" โดยคนในองค์กรที่มีสิทธิ์เข้าถึง อาจเป็นเจ้าหน้าที่ IT พนักงานสัญญาจ้าง หรือบริษัท outsource ที่ได้รับสิทธิ์ admin เต็มรูปแบบโดยไม่มีการ audit

5. ไม่มี Data Processing Agreement (DPA) กับผู้พัฒนา

กรณี PDPC ปรับเงิน 15 ล้านบาทในปี 2567 ชี้ชัดว่าหน่วยงานรัฐว่าจ้างบริษัทภายนอกพัฒนาเว็บแอปพลิเคชัน แต่ ไม่มีสัญญาคุ้มครองข้อมูล (DPA) ไม่มีการตรวจสอบ มาตรฐานความปลอดภัย ของผู้พัฒนา ไม่มีการทำ security audit ก่อนเปิดใช้งาน และใช้รหัสผ่านที่อ่อนแอ

6. ข้อมูลไม่ได้เข้ารหัส (No Encryption at Rest)

แม้แฮกเกอร์จะเจาะเข้าระบบได้ ถ้าข้อมูลถูกเข้ารหัสอย่างถูกต้อง (AES-256 หรือ similar) ข้อมูลที่ได้ไปก็จะเป็นแค่ข้อมูลที่อ่านไม่ออก แต่ระบบภาครัฐส่วนใหญ่เก็บข้อมูลส่วนบุคคลเป็น plain text — เลขบัตรประชาชน ชื่อ-ที่อยู่ เบอร์โทร ไม่มีการเข้ารหัสใดๆ

ตรวจสอบตัวเอง — ข้อมูลของเราหลุดไหม?

เมื่อเกิดเหตุการณ์ข้อมูลรั่วไหลขนาดใหญ่ สิ่งแรกที่ต้องทำคือตรวจสอบว่าข้อมูลของเราได้รับผลกระทบหรือไม่:

สำหรับบุคคลทั่วไป

• ตรวจสอบผ่านเว็บไซต์ Have I Been Pwned (haveibeenpwned.com) — ใส่อีเมลเพื่อตรวจสอบว่าข้อมูลของเราเคยหลุดจากเหตุการณ์ไหนบ้าง
• ตรวจสอบแอปประกันสังคม (SSO Plus) — เข้าแอป SSO Plus ตรวจสอบว่าข้อมูลที่อยู่ เบอร์โทร อีเมลถูกต้องหรือไม่
• เปลี่ยนรหัสผ่านทันที — โดยเฉพาะระบบที่ใช้เลขบัตรประชาชนเป็น username ต้องเปลี่ยนรหัสผ่านทั้งหมด
• เปิด Two-Factor Authentication (2FA) — เปิดใช้ การยืนยันตัวตนสองชั้น ในทุกบริการที่รองรับ
• ระวังการหลอกลวง — หลังข้อมูลหลุด มักมีมิจฉาชีพโทรมาอ้างเป็นธนาคาร ประกันสังคม หรือหน่วยงานรัฐ โดยรู้ข้อมูลของเราจริง ทำให้น่าเชื่อถือมากขึ้น

สำหรับผู้ดูแลระบบ IT / องค์กร

• ตรวจสอบ Access Log — ดูว่ามีการเข้าถึงฐานข้อมูลในปริมาณผิดปกติหรือไม่ เช่น query ที่ดึงข้อมูลเป็นแสน record ในเวลาสั้นๆ
• สแกนช่องโหว่ — ใช้เครื่องมืออย่าง OWASP ZAP, Nessus หรือ Burp Suite สแกนหา SQL Injection, XSS และช่องโหว่อื่นๆ
• ตรวจสอบ Dark Web — ใช้บริการ Dark Web Monitoring (เช่น SpyCloud, Have I Been Pwned for Domain) ตรวจสอบว่าข้อมูลองค์กรถูกนำไปขายหรือไม่
• ทบทวนสิทธิ์การเข้าถึง — ตรวจสอบว่าใครมีสิทธิ์เข้าถึงข้อมูลอะไรบ้าง ลบสิทธิ์ที่ไม่จำเป็นออก

ทำไมระบบภาครัฐหลุดบ่อย?

คำถามที่หลายคนสงสัยคือ ทำไมระบบ IT ภาครัฐไทยถึงเกิดเหตุการณ์ข้อมูลรั่วไหลซ้ำแล้วซ้ำเล่า สาเหตุเชิงโครงสร้างที่แท้จริงมีหลายประการ:

• งบ IT ส่วนใหญ่ทุ่มไปกับ "สร้าง" ไม่ใช่ "ดูแล" — หน่วยงานภาครัฐมักมีงบสำหรับพัฒนาระบบใหม่ แต่ไม่มีงบสำหรับ security audit, penetration test หรือการ monitor ระบบหลังเปิดใช้งาน
• Outsource แล้วไม่ตรวจ — ว่าจ้างบริษัทภายนอกพัฒนาระบบ แต่ไม่มี code review, security testing หรือแม้แต่ DPA ก่อนส่งมอบงาน
• ไม่มี Security Team ประจำ — หลายหน่วยงานไม่มีทีม cybersecurity ประจำ ใช้เจ้าหน้าที่ IT ทั่วไปดูแลทุกอย่าง ตั้งแต่ซ่อมคอมไปจนถึงดูแลฐานข้อมูล
• ระบบเก่าที่ไม่ได้อัพเดท — หลายระบบพัฒนามานานกว่า 10 ปี ใช้ framework เก่าที่มีช่องโหว่ที่รู้อยู่แล้ว แต่ไม่มีงบหรือคนมาอัพเดท
• ไม่มีกฎหมายบังคับจริงจัง — แม้จะมี พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล (PDPA) แต่บทลงโทษยังเบา และการบังคับใช้ยังไม่ทั่วถึง เทียบกับ GDPR ของยุโรปที่ปรับสูงสุด 4% ของรายได้ทั้งบริษัท

ป้องกันอย่างไร — Checklist สำหรับระบบ IT ภาครัฐ

จากบทเรียนที่ผ่านมา นี่คือ checklist ที่ระบบ IT ภาครัฐ (และเอกชน) ควรมีเป็นอย่างน้อย:

บทเรียนสำหรับระบบ ERP ภาครัฐ

ระบบ ERP เป็นหัวใจหลักขององค์กร เก็บข้อมูลทุกอย่างตั้งแต่ข้อมูลพนักงาน (HR) งบการเงิน (GL) ไปจนถึงข้อมูลคู่ค้าและลูกค้า (AP/AR) ถ้าระบบ ERP ถูกเจาะ ผลกระทบจะรุนแรงกว่าระบบอื่นหลายเท่า

สิ่งที่ระบบ ERP ที่ดีต้องมี ตั้งแต่ขั้นออกแบบ (Security by Design):

• Role-Based Access Control (RBAC) — แต่ละคนเห็นแค่ข้อมูลที่ตัวเองต้องใช้งาน เจ้าหน้าที่พัสดุไม่ควรเห็นข้อมูลเงินเดือน
• Audit Trail ทุกการกระทำ — ใครทำอะไร เมื่อไหร่ แก้ข้อมูลอะไร ต้องตรวจสอบย้อนหลังได้ทั้งหมด
• Encryption ทั้ง at Rest และ in Transit — ข้อมูลในฐานข้อมูลและข้อมูลที่ส่งระหว่าง client-server ต้องเข้ารหัส
• Two-Factor Authentication — ไม่ใช่แค่รหัสผ่าน ต้องยืนยันตัวตนสองชั้นสำหรับการเข้าถึงข้อมูลสำคัญ
• ไม่พึ่ง Third-party Cloud ที่ไม่มี DPA — เลือกระบบที่ deploy ในเซิร์ฟเวอร์ขององค์กรเอง หรือ cloud ที่มี compliance ชัดเจน

งบบำรุงรักษาและดูแลระบบ — ควรเท่าไหร่?

สาเหตุหลักที่ระบบ IT ภาครัฐถูกเจาะซ้ำแล้วซ้ำเล่า คือ งบจัดซื้อระบบมีทุกปี แต่งบบำรุงรักษาไม่มีหรือมีน้อยมาก หลายหน่วยงานลงทุนหลักสิบล้านบาทสร้างระบบ แต่พอส่งมอบงานเสร็จก็ไม่มีงบดูแลต่อ เหมือนซื้อรถใหม่แล้วไม่เคยเปลี่ยนน้ำมันเครื่อง

งบบำรุงรักษาระบบ IT ควรตั้งเท่าไหร่?

มาตรฐานสากล (Gartner, NIST) แนะนำว่างบบำรุงรักษาควรอยู่ที่ 15-20% ของมูลค่าระบบต่อปี สำหรับหน่วยงานภาครัฐไทย สามารถแบ่งได้ดังนี้:

รายการ	สัดส่วนงบ	ตัวอย่าง (ระบบ 10 ล้าน)	ทำอะไร
Software Maintenance	5-8%	500,000-800,000/ปี	อัพเดท patch, แก้ bug, ปรับปรุงระบบตามกฎหมายใหม่
Security Operations	3-5%	300,000-500,000/ปี	Penetration Test, Vulnerability Scan, Security Audit, Monitoring
Infrastructure	3-4%	300,000-400,000/ปี	ค่า server, backup, SSL certificate, domain, cloud hosting
Training & Awareness	1-2%	100,000-200,000/ปี	อบรม Security Awareness ให้เจ้าหน้าที่, ซ้อม Incident Response
Incident Response Reserve	2-3%	200,000-300,000/ปี	งบสำรองกรณีเกิดเหตุฉุกเฉิน, จ้าง forensic, แจ้ง PDPC
รวม	15-20%	1.5-2.0 ล้าน/ปี	สำหรับระบบมูลค่า 10 ล้านบาท

งบบำรุงรักษาต้องทำอะไรบ้าง — แยกตามรอบ

ทุกวัน (Daily Operations)

• ตรวจสอบ Backup สำเร็จหรือไม่ — ทั้ง database backup และ file backup
• ตรวจสอบ Server uptime, CPU, Memory, Disk usage
• ตรวจสอบ Security Log — มี login ผิดปกติหรือไม่
• ตรวจสอบ SSL certificate ยังไม่หมดอายุ

ทุกสัปดาห์ (Weekly)

• อัพเดท OS security patches
• ตรวจสอบ Firewall rules — มี port เปิดโดยไม่จำเป็นหรือไม่
• ตรวจสอบ Disk space — ลบ log เก่า, temp files
• ทดสอบ Restore backup — backup ที่ไม่เคยทดสอบ restore ไม่ใช่ backup

ทุกเดือน (Monthly)

• Vulnerability Scan ด้วย automated tools
• ตรวจสอบ User accounts — ลบ account ที่ลาออกหรือหมดสัญญา
• ตรวจสอบ Access privileges — ใครมีสิทธิ์เกินจำเป็นหรือไม่
• อัพเดท Application patches (ERP, middleware, libraries)
• ตรวจสอบ Database performance — query ที่ช้าผิดปกติ

ทุกไตรมาส (Quarterly)

• Security Assessment / Mini Penetration Test
• ทบทวน Disaster Recovery Plan
• อบรม Security Awareness ให้เจ้าหน้าที่
• ทบทวน DPA กับ vendor ภายนอก

ทุกปี (Annual)

• Full Penetration Test โดยผู้เชี่ยวชาญภายนอก
• Security Audit ตามมาตรฐาน (ISO 27001, NIST CSF)
• ซ้อม Incident Response — จำลองเหตุการณ์ data breach
• ทบทวนนโยบาย PDPA Compliance
• อัพเกรด Hardware ที่หมดอายุ warranty

รายงานต่อเดือนที่ต้องส่งผู้บริหาร

ผู้ดูแลระบบ IT (หรือบริษัทที่รับจ้างดูแล) ควรจัดทำ Monthly Security & Operations Report เสนอผู้บริหารทุกเดือน โดยควรมีเนื้อหาอย่างน้อยดังนี้:

รายงานนี้ไม่จำเป็นต้องยาว — 2-3 หน้า A4 ก็เพียงพอ สิ่งสำคัญคือต้องทำ สม่ำเสมอทุกเดือน และผู้บริหารต้อง อ่านจริง ถามจริง สั่งการจริง ไม่ใช่แค่รับไว้แล้วเก็บ รายงานที่ไม่มีใครอ่านก็ไม่ต่างจากไม่มีรายงาน

จะเห็นว่า ค่าดูแลป้องกัน 1.5-2 ล้านบาทต่อปี ถูกกว่า ค่าเสียหายจากการถูกเจาะครั้งเดียว 5.5-27 ล้านบาท อย่างมาก ยังไม่นับความเสียหายต่อความเชื่อมั่นของประชาชนที่ประเมินค่าไม่ได้ การตั้งงบบำรุงรักษาจึงไม่ใช่ "ค่าใช้จ่าย" แต่เป็น "ค่าประกันภัย" ที่คุ้มค่าที่สุด

สรุป

เหตุการณ์ข้อมูลรั่วไหล 66 ล้านคน ไม่ใช่เรื่องน่าแปลกใจสำหรับผู้เชี่ยวชาญด้าน cybersecurity เพราะปัญหาเชิงโครงสร้างมีมานาน — ระบบเก่า ไม่มีการ audit ไม่เข้ารหัส ไม่มี DPA สิ่งที่แต่ละฝ่ายควรทำตอนนี้คือ:

• บุคคลทั่วไป: เปลี่ยนรหัสผ่าน เปิด 2FA ระวังมิจฉาชีพ
• ผู้ดูแลระบบ: สแกนช่องโหว่ ตรวจ access log ทบทวนสิทธิ์การเข้าถึง
• ผู้บริหาร: จัดงบ security audit เลือกระบบที่มี Security by Design ทำ DPA กับ vendor ทุกราย

ข้อมูลส่วนบุคคลของคนไทย 66 ล้านคน ขายในตลาดมืดราคาแค่ 1,650 บาท — ถูกกว่าค่ากาแฟ 1 ปี คำถามคือ ระบบ IT ภาครัฐจะยังใช้มาตรฐานเดิมอีกนานแค่ไหน?

- ทีมงาน Saeree ERP

แหล่งอ้างอิง

• ข้อมูลคนไทย 66 ล้าน หลุดว่อนตลาดมืด — TheThaiger
• แอปประกันสังคมอัปเดตใหม่ทำพิษ ข้อมูลที่อยู่มั่ว — เดลินิวส์
• 9Near แฮกข้อมูลคนไทย 55 ล้านคน — PPTVHD36
• ข้อมูลผู้สูงอายุรั่วไหลเกือบ 20 ล้านชุด — Thai PBS
• Five data breach incidents in Thailand 2024: PDPC fines — Lexology
• 70% ประชากรไทย ข้อมูลรั่วไหล — PDPACore