ความปลอดภัยของข้อมูลในระบบ ERP

1. อัปเดต 2569 — สามกฎเกณฑ์ที่บังคับใช้ในเดือนกันยายนเดือนเดียว

สิ่งที่เปลี่ยนไปจากปีก่อนไม่ใช่ตัวภัยคุกคาม แต่คือ "ภาระการพิสูจน์" ที่ตกมาที่องค์กร เดิมกฎหมายเขียนกว้างๆ ว่าต้องมีมาตรการที่เหมาะสม ปี 2569 เริ่มมีประกาศที่ระบุกรอบเวลาและรายละเอียดชัดเจนขึ้น ซึ่งหมายความว่าเวลาถูกตรวจสอบ องค์กรต้องมีหลักฐานให้ดู ไม่ใช่แค่ยืนยันด้วยปากเปล่า

รายละเอียดของสองมาตรฐาน สกมช. อ่านได้ที่บทความ สกมช. ออกมาตรฐาน Cloud Security และ Website Security บังคับใช้ ก.ย. 2569 และประกาศ PDPA ฉบับใหม่อยู่ในบทความ สิทธิขอสำเนาข้อมูลส่วนบุคคล PDPA 2569 — องค์กรต้องตอบภายใน 30 วัน

2. ภัยคุกคามข้อมูลในระบบ ERP ที่ผู้บริหารต้องรู้

ก่อนวางแผนป้องกัน ต้องเข้าใจก่อนว่าภัยที่ระบบ ERP เผชิญมีหลายรูปแบบ และไม่ได้มาจากภายนอกทั้งหมด สิ่งที่ผู้บริหารควรจำคือ ทางเข้าของการโจมตีเกือบทุกแบบผ่าน "คน" หรือ "สิทธิ์" ก่อนถึงตัวระบบ

Ransomware — มัลแวร์เรียกค่าไถ่

Ransomware เข้ารหัสข้อมูลทั้งหมดแล้วเรียกค่าไถ่เพื่อแลกกับกุญแจถอดรหัส สิ่งที่ทำให้ ERP เป็นเป้าคือมันหยุดธุรกิจได้ทันที — ออกใบกำกับไม่ได้ ตัดสต็อกไม่ได้ จ่ายเงินเดือนไม่ได้ จุดที่หลายองค์กรพลาดคือมีไฟล์สำรองแต่ไฟล์สำรองอยู่บนเครื่องเดียวกันหรือแชร์โฟลเดอร์เดียวกัน จึงถูกเข้ารหัสไปด้วย การสำรองข้อมูลที่ช่วยได้จริงต้องแยกที่เก็บและต้องเคยทดสอบกู้คืนแล้ว ดูแนวทางที่บทความ แผนกู้คืนระบบจากภัยพิบัติ (Disaster Recovery)

Phishing — อีเมลหลอกลวง

Phishing ยังเป็นทางเข้าที่ใช้บ่อยที่สุด เพราะถูกที่สุดสำหรับผู้โจมตี ส่งอีเมลปลอมในนามผู้บริหารหรือซัพพลายเออร์ หลอกให้พนักงานกรอกรหัสผ่านในหน้าเลียนแบบ เมื่อได้รหัสผ่านก็เข้าระบบได้เหมือนเป็นพนักงานคนนั้น ทางแก้ที่ได้ผลที่สุดไม่ใช่การสอนให้ "สังเกตอีเมลให้ดี" เพียงอย่างเดียว แต่คือทำให้รหัสผ่านที่รั่วใช้ไม่ได้ ด้วย การยืนยันตัวตนสองชั้น (2FA) ที่บังคับใช้ทุกบัญชี

Insider Threats — ภัยคุกคามจากภายใน

พนักงานที่ไม่พอใจ อดีตพนักงานที่ยังไม่ถูกปิดสิทธิ์ หรือแม้แต่คนที่ทำผิดพลาดโดยไม่ตั้งใจ ล้วนเป็นความเสี่ยง กรณีที่พบบ่อยที่สุดไม่ใช่การเจตนาขายข้อมูล แต่เป็น "สิทธิ์ค้างท่อ" — คนย้ายแผนกไปแล้วแต่สิทธิ์เดิมยังอยู่ สะสมไปเรื่อยจนบางบัญชีเข้าถึงได้เกือบทุกอย่าง วิธีคุมคือทบทวนสิทธิ์เป็นรอบ และให้ระบบเก็บ audit log ที่ตอบได้ว่าใครเปิดดูอะไรเมื่อไร

ข้อมูลรั่วไหล (Data Breach) และไฟล์ที่หลุดออกนอกระบบ

การรั่วไหลไม่ได้เกิดจากการถูกเจาะเสมอไป ที่พบบ่อยกว่าคือข้อมูลถูก export ออกเป็นไฟล์แล้วเดินทางต่อเองผ่านแชตและอีเมล ซึ่งเป็นความเสี่ยงเดียวกับที่อธิบายไว้ในบทความ ความเสี่ยงของการใช้ Excel เก็บข้อมูลสำคัญขององค์กร ผลกระทบไม่ใช่แค่ตัวเงิน แต่รวมถึงความน่าเชื่อถือ การถูกฟ้องร้อง และค่าปรับตาม PDPA

3. ความเสี่ยงใหม่ปี 2569 — เมื่อ AI ต่อเข้าระบบ ERP

หัวข้อนี้ยังไม่มีในบทความฉบับปี 2568 แต่ปีนี้เป็นคำถามที่ผู้บริหารถามบ่อยที่สุด เมื่อองค์กรเริ่มให้ผู้ช่วย AI ช่วยสรุปรายงานหรือค้นข้อมูลจาก ERP สิ่งที่เปลี่ยนคือมี "ผู้ใช้" รายใหม่ที่ทำงานเร็วมากและไม่ได้อ่านนโยบายบริษัท

ความเสี่ยงหลักคือ Prompt Injection — การฝังคำสั่งไว้ในข้อมูลที่ AI จะอ่าน เช่น ในไฟล์แนบใบเสนอราคาที่คู่ค้าส่งมา เพื่อหลอกให้ AI ทำสิ่งที่เจ้าของระบบไม่ได้สั่ง รายละเอียดกลไกและแนวป้องกันอยู่ในบทความ Prompt Injection คืออะไร: ช่องโหว่อันดับ 1 ของ AI Agent

หลักที่ใช้ได้กับทุกองค์กรมีสามข้อ:

• AI ต้องไม่มีสิทธิ์เกินคนที่เรียกใช้ — ผูกการเข้าถึงเข้ากับสิทธิ์ของผู้ใช้จริง ไม่ใช่ให้ AI ใช้บัญชี admin กลางบัญชีเดียว
• แยกงานอ่านกับงานเขียนออกจากกัน — เริ่มจากให้อ่านและสรุปเท่านั้น การสร้างหรือแก้เอกสารในระบบต้องมีคนกดอนุมัติ
• ทุกคำสั่งต้องอยู่ใน audit log — ตอบได้ว่า AI ดึงข้อมูลอะไรออกไป ตามคำขอของใคร เมื่อไร

เรื่องนี้ต่อเนื่องกับการเลือกใช้ AI ในองค์กรอย่างปลอดภัย ซึ่งเราแยกไว้ในบทความ เทรนด์ความปลอดภัยไซเบอร์ 2569

4. PDPA กับระบบ ERP — สิ่งที่เปลี่ยนในปี 2569

พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) บังคับใช้เต็มรูปแบบตั้งแต่ 1 มิถุนายน 2565 และระบบ ERP คือที่เก็บข้อมูลส่วนบุคคลก้อนใหญ่ที่สุดขององค์กร ทั้งข้อมูลพนักงาน ลูกค้า และคู่ค้า สิ่งที่เพิ่มเข้ามาในปี 2569 คือประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลเรื่องหลักเกณฑ์การเข้าถึงและขอรับสำเนาข้อมูลส่วนบุคคล ซึ่งลงราชกิจจานุเบกษาวันที่ 16 กรกฎาคม 2569 และมีผลบังคับใช้ 14 กันยายน 2569

ภาพรวมการวางระบบ ERP ให้สอดคล้อง PDPA อ่านต่อได้ที่ PDPA กับ ERP — จัดการข้อมูลส่วนบุคคลให้ถูกกฎหมาย และสำหรับหน่วยงานรัฐมีกรอบเพิ่มเติมที่ ขมธอ.1-2557 มาตรฐานความปลอดภัยสารสนเทศภาครัฐ

5. มาตรการรักษาความปลอดภัยใน Saeree ERP

Saeree ERP ออกแบบโดยวางความปลอดภัยไว้ในโครงสร้างตั้งแต่ต้น ไม่ใช่เพิ่มทีหลัง ตารางด้านล่างแยกให้ชัดว่าอะไรเป็นความสามารถของระบบ และอะไรเป็นสิ่งที่ต้องตั้งค่าตามนโยบายของแต่ละองค์กรตอนวางระบบ เพราะสองอย่างนี้ต่างกันและมักถูกพูดรวมกันจนเข้าใจผิด

สำหรับองค์กรที่ต้องยืนยันตัวตนระดับบุคคลด้วยหลักฐานของรัฐ Saeree ERP รองรับการยืนยันตัวตนผ่าน ThaiD เพิ่มเติมจาก 2FA ปกติ และถ้าต้องการเช็กสถานะ SSL ของระบบตัวเองก่อนถึงวันบังคับใช้ WSS ทำได้เองตามขั้นตอนในบทความ ตรวจ SSL เว็บไซต์ด้วยตัวเอง

ความปลอดภัยที่ตรวจสอบไม่ได้ ไม่ต่างจากไม่มีความปลอดภัย — ถ้าตอบไม่ได้ว่าใครเปิดดูข้อมูลอะไรเมื่อไร ก็ยังไม่มีหลักฐานให้ผู้ตรวจสอบดู

- ไพฑูรย์ บุตรี, ผู้เชี่ยวชาญด้านระบบเน็ตเวิร์คและความปลอดภัยเซิร์ฟเวอร์ บริษัท แกรนด์ลีนุกซ์ โซลูชั่น จำกัด

6. On-premise หรือคลาวด์ — ใครรับผิดชอบส่วนไหน

Cloud Security Standard ที่บังคับใช้ 10 กันยายน 2569 ตั้งคำถามสองข้อที่หลายองค์กรตอบไม่ได้ทันที คือ "ข้อมูลของเราอยู่ที่ไหน" และ "ใครรับผิดชอบส่วนไหน" ความเข้าใจผิดที่พบบ่อยที่สุดคือคิดว่าใช้คลาวด์แล้วผู้ให้บริการดูแลความปลอดภัยให้ทั้งหมด ซึ่งไม่จริง — การตั้งค่าผิดที่อยู่ในความรับผิดชอบของผู้ใช้เองเป็นสาเหตุข้อมูลรั่วบนคลาวด์ที่พบบ่อยที่สุด

ถ้ายังตัดสินใจไม่ได้ว่าจะวางระบบแบบไหน เปรียบเทียบข้อดีข้อเสียแบบละเอียดไว้ที่ On-Premise หรือ Cloud — เลือกแบบไหนให้เหมาะกับองค์กร

7. การสำรองข้อมูลและกู้คืน (Backup & Disaster Recovery)

ไม่มีระบบใดป้องกันได้ 100% ดังนั้นคำถามที่ผู้บริหารควรถามไม่ใช่ "เรามีสำรองข้อมูลไหม" แต่คือ "ครั้งล่าสุดที่เราทดสอบกู้คืนจริงคือเมื่อไร และใช้เวลากี่ชั่วโมง" องค์กรที่ตอบคำถามนี้ไม่ได้ ถือว่ายังไม่มีแผนสำรองข้อมูลที่ใช้งานได้

• สำรองอัตโนมัติตามรอบ — ตั้งความถี่ตามความสำคัญของข้อมูล ไม่ต้องรอคนกด และเข้ารหัสไฟล์สำรองก่อนจัดเก็บ
• แยกที่เก็บออกจากระบบหลัก — ถ้าไฟล์สำรองอยู่บนเครื่องเดียวกับ ERP มันจะถูกเข้ารหัสไปพร้อมกันเมื่อโดน Ransomware
• กำหนด RPO/RTO ให้เป็นตัวเลข — ยอมเสียข้อมูลย้อนหลังได้กี่ชั่วโมง (RPO) และต้องกลับมาให้บริการภายในกี่ชั่วโมง (RTO) สองตัวเลขนี้เป็นการตัดสินใจของผู้บริหาร ไม่ใช่ของฝ่ายไอที
• ซ้อมกู้คืนอย่างน้อยปีละครั้ง — จับเวลาจริง แล้วเทียบกับ RTO ที่ประกาศไว้

8. เช็กลิสต์สำหรับผู้บริหาร — เริ่มจากอะไรก่อน

งานด้านความปลอดภัยทำครั้งเดียวไม่จบ แต่ก็ไม่จำเป็นต้องทำทุกอย่างพร้อมกัน ตารางนี้จัดลำดับตามผลที่ได้ต่อความพยายามที่ลง — สามข้อแรกทีมไอทีส่วนใหญ่ทำได้เองภายในไม่กี่สัปดาห์

สรุป

ปี 2569 เปลี่ยนความปลอดภัยของข้อมูลใน ERP จาก "เรื่องที่ควรทำ" ให้เป็น "เรื่องที่ต้องพิสูจน์ได้" — PDPA กำหนดกรอบเวลา 30 วันสำหรับคำขอสำเนาข้อมูล และมาตรฐานของ สกมช. ทั้งด้านคลาวด์และเว็บไซต์เริ่มบังคับใช้ในเดือนกันยายนเดียวกัน องค์กรที่ตอบได้ว่าข้อมูลอยู่ที่ไหน ใครเข้าถึงได้ และกู้คืนได้ในกี่ชั่วโมง จะผ่านทั้งสามเรื่องไปพร้อมกัน

Saeree ERP วางรากฐานให้ตอบคำถามเหล่านั้นได้ ด้วยสิทธิ์ตามบทบาทที่ปิดบังข้อมูลอ่อนไหวได้ audit log ที่ตรวจย้อนหลังได้ การรองรับ SSL เกรด A+ และ 2FA และทางเลือกติดตั้งแบบ On-premise สำหรับองค์กรที่ต้องระบุที่ตั้งข้อมูลให้ชัดเจน ส่วนความถี่การสำรองข้อมูล ผังสิทธิ์ และรอบการทบทวน เป็นสิ่งที่กำหนดร่วมกันตอนวางระบบตามนโยบายของแต่ละองค์กร

หากต้องการประเมินว่าระบบปัจจุบันของคุณตอบเจ็ดข้อในเช็กลิสต์ได้กี่ข้อ สามารถติดต่อทีมงานของเราเพื่อขอคำปรึกษาด้านความปลอดภัยของข้อมูลในระบบ ERP

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

• สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส.)
• พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 — ราชกิจจานุเบกษา
• ประกาศหลักเกณฑ์การเข้าถึงและการขอรับสำเนาข้อมูลส่วนบุคคล พ.ศ. 2569 — ราชกิจจานุเบกษา เล่ม 143 ตอนพิเศษ 175 ง (16 ก.ค. 2569)
• Cloud Security Thailand — สำนักงานคณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติ (สกมช.)