ข้อควรตระหนัก กับหน้าที่ที่ต้องแยกกันในระบบ IT มาลองดูกันครับ!
IT AuditKnowledge CenterRisk Alert
ข้อควรตระหนัก: หน้าที่ที่ต้องแยกกันในระบบ IT
Segregation of Duties (SoD) — บทเรียนที่แพงที่สุดในโลกการเงิน
เมื่อ “คนคนเดียว” มีอำนาจมากเกินไปในระบบ IT — ความเสียหายที่ตามมาอาจไม่ใช่แค่เรื่อง Bug แต่คือหายนะระดับองค์กร บทความนี้จะพาคุณเจาะลึก 4 จุดวิกฤตที่ต้องแยกหน้าที่ พร้อมกรณีศึกษาจริงที่พิสูจน์ว่า SoD ไม่ใช่แค่ทฤษฎี
Segregation of Duties (SoD) หรือการแบ่งแยกหน้าที่ คือหลักการควบคุมภายในที่สำคัญที่สุดข้อหนึ่งในงาน IT Audit ซึ่งมีแนวคิดเรียบง่ายว่า “คนคนเดียวไม่ควรมีอำนาจครบวงจรในกระบวนการเดียวกัน” เพราะทุกครั้งที่ SoD ล้มเหลว นั่นคือประตูเปิดให้เกิดทั้งความผิดพลาดโดยไม่ตั้งใจ และการทุจริตโดยตั้งใจ
⚡
4 หน้าที่วิกฤตที่ต้องแยกกันในระบบ IT
จุดเสี่ยงที่ IT Auditor ต้องตรวจสอบเป็นอันดับแรก
| 1การพัฒนาโปรแกรม vs การทดสอบDev vs. Test | |
|
🎯 ทำไมต้องแยก
เพื่อให้เกิด Objectivity อย่างแท้จริง คนเขียนโปรแกรมมักมี “Blind Spots” มองข้ามข้อผิดพลาดของตัวเอง เหมือนนักเขียนที่ Proofread งานตัวเอง ย่อมพลาดคำผิดที่คนอื่นเห็นได้ง่าย ทีม Test ที่เป็นอิสระจึงจำเป็นต้องมีอยู่เสมอ
|
⚠️ ความเสี่ยงหากไม่แยก
Bug หลุดเข้าสู่ระบบงานจริง (Production) โดยไม่ถูกตรวจจับ หรือในกรณีร้ายแรง นักพัฒนาอาจแอบฝัง “Backdoor” ไว้เพื่อเข้ามาแก้ไขข้อมูลในภายหลัง โดยที่ไม่มีใครรู้ตัว
|
| 2การเปลี่ยนแปลงโปรแกรม vs การอนุมัติChange vs. Approval | |
|
🎯 ทำไมต้องแยก
นี่คือหัวใจของ Change Management เพื่อให้มั่นใจว่าทุกการแก้ไขบน Production ผ่านการพิจารณาผลกระทบจากบุคคลที่สามก่อนเสมอ ไม่มีใครควรตรวจงานตัวเองแล้วกดอนุมัติได้
|
⚠️ ความเสี่ยงหากไม่แยก
คนขอแก้และคนอนุมัติเป็นคนเดียวกัน — เปิดทางให้แอบแก้ Code เพื่อเอื้อประโยชน์ตัวเอง เช่น เปลี่ยนสูตรคำนวณ Commission แล้วกดอนุมัติเองทันที ฝ่ายบริหารไม่รู้เรื่องเลย
|
| 3การจัดการสิทธิ์ผู้ใช้ vs การตรวจสอบ LogAccess Provisioning vs. Log Review | |
|
🎯 ทำไมต้องแยก
เพื่อป้องกัน “ทำผิดแล้วลบหลักฐาน” — Log ที่ดีจะไร้ประโยชน์ทันที หากคนที่ดูแล Log เป็นคนเดียวกับที่ให้สิทธิ์เข้าถึงระบบ
|
⚠️ ความเสี่ยงหากไม่แยก
Admin ที่ให้สิทธิ์ (User Provisioning) อาจแอบให้สิทธิ์พิเศษแก่ตัวเองเพื่อ ขโมยข้อมูล แล้วเข้าไปลบ Log ทิ้งเพื่อทำลายหลักฐานการกระทำนั้นโดยสมบูรณ์
|
| 4การสำรองข้อมูล vs การกู้คืนข้อมูลBackup vs. Recovery Verification | |
|
🎯 ทำไมต้องแยก
เพื่อ Verify อย่างเป็นอิสระ ว่า Backup ที่ทำไปนั้น “ใช้งานได้จริง” ไม่ใช่แค่ไฟล์ที่กู้คืนไม่ได้ — Backup ที่ไม่ได้ Test คือ “ภาพลวงตา” ของความปลอดภัย
|
⚠️ ความเสี่ยงหากไม่แยก
หลายบริษัทสำรองข้อมูลทุกวัน แต่พอเกิดวิกฤตกลับ Restore ไม่ได้ เพราะไม่เคยมีทีม Recovery Checker อิสระมาทดสอบจริง นั่นคือ BCP ที่ไม่มีประสิทธิภาพ
|
|
💡 มุมมอง Professional: The Maker-Checker Principle
กรณีองค์กรขนาดเล็กที่ไม่สามารถแยกคนได้จริง (Limited Resources) — ในฐานะ Auditor เราจะแนะนำให้ใช้ Compensating Control แทน เช่น ให้ผู้บริหารระดับสูง Review Exception Report รายการเปลี่ยนแปลงทั้งหมดอย่างใกล้ชิดและสม่ำเสมอ พร้อมทั้งบันทึกหลักฐานการ Review ไว้ทุกครั้ง
⚠️ Compensating Control ไม่ได้ “แก้” ปัญหา SoD — แต่เป็นมาตรการชดเชยชั่วคราวที่ยอมรับได้ พร้อมแผนแก้ไขในระยะยาว
|
!
กรณีศึกษาจริง: เมื่อ SoD ล้มเหลว ราคาที่ต้องจ่ายคือเท่าไร?
บทเรียนราคาแพงจากองค์กรชั้นนำระดับโลก
|
🔴 Case Study 1 — Dev vs. TestKnight Capital Group (2012)บริษัทหลักทรัพย์ชั้นนำของสหรัฐอเมริกา
⚡ ความเสียหาย
$440M
~15,000 ล้านบาท
ภายใน 45 นาที
|
||
|
📋 เหตุการณ์
ในการติดตั้งซอฟต์แวร์เทรดหุ้นตัวใหม่ พนักงานดันส่ง Code เก่าที่ยกเลิกแล้ว ขึ้น Production พร้อมกัน ส่งผลให้ระบบ Automated Trading ทำงานผิดพลาดแบบรัวๆ
|
💥 จุดที่ SoD มีข้อบกพร่อง
นักพัฒนา (Maker) เขียน Code และนำขึ้น Production ด้วยตัวเอง โดยไม่มีทีม Test อิสระ (Checker) ที่เข้มงวดพอ และขาด Independent Code Review
|
📉 ผลลัพธ์
ระบบซื้อหุ้นในราคาสูง-ขายในราคาต่ำอย่างต่อเนื่อง บริษัทขาดทุนจนเกือบล้มละลาย ภายใน 45 นาที และต้องขายกิจการในที่สุด
|
|
🔴 Case Study 2 — Change vs. ApprovalJérôme Kerviel — Société Généraleธนาคารชั้นนำแห่งฝรั่งเศส — มหากาพย์การทุจริตที่สั่นสะเทือนโลกการเงิน
⚡ ความเสียหาย
€4.9B
~200,000 ล้านบาท
|
||
|
📋 เหตุการณ์
เทรดเดอร์ Jérôme Kerviel แอบทำรายการเทรดปลอมมูลค่ามหาศาล โดยปิดระบบแจ้งเตือนเพื่อป้องกันไม่ให้ฝ่ายบริหารรู้ตัว
|
💥 จุดที่ SoD มีข้อบกพร่อง
เขาเคยทำงานใน IT/Back Office ทำให้มีทั้ง Access และความรู้ ในการแก้ระบบ เขาจึงสามารถ “แก้ Code + อนุมัติรายการ” ได้ด้วยตัวเองคนเดียว
|
📉 ผลลัพธ์
เขาเป็นทั้ง Maker และ Checker ในคนเดียว ธนาคารไม่รู้ตัวเลยจนกว่าความเสียหายจะแตะระดับ แสนล้านบาท และกลายเป็นบทเรียนระดับโลก
|
|
🔴 Case Study 3 — Backup vs. RecoveryGitLab Database Incident (2017)แพลตฟอร์ม DevOps ชั้นนำที่ใช้งานโดยนักพัฒนาทั่วโลก
⚡ ความเสียหาย
300 GB
ข้อมูลหายถาวร
+ ระบบล่มหลายชั่วโมง
|
||
|
📋 เหตุการณ์
System Admin เผลอใช้คำสั่งลบ Database ผิดตัวบนเครื่อง Production ขณะพยายามแก้ปัญหาระบบที่ช้าลง
|
💥 จุดที่ SoD มีข้อบกพร่อง
ทีม Backup (Maker) สำรองข้อมูลตาม Script ไปเรื่อยๆ แต่ ไม่มีทีม Recovery Checker อิสระ ที่ทดสอบว่า Restore ได้จริงหรือไม่
|
📉 ผลลัพธ์
Script Backup พังมานานแล้ว แต่ไม่มีใครรู้ เพราะคนทำกับคนตรวจเป็นคนเดียวกัน จนทำให้ข้อมูลมหาศาลสูญหายตลอดกาล
|
|
🎯 บทสรุปสำหรับ IT Auditor
ทุกกรณีศึกษาข้างต้นมีจุดร่วมเดียวกัน — “คนคนเดียวถูกให้อำนาจมากเกินไปในกระบวนการเดียว” และไม่มีกลไกตรวจสอบที่เป็นอิสระ SoD จึงไม่ใช่แค่ทฤษฎีในหนังสือ แต่คือเครื่องมือป้องกันภัยที่พิสูจน์แล้วว่าได้ผลในโลกจริง
ในการ Audit ครั้งถัดไป ให้ตั้งคำถาม 4 ข้อนี้: ใครทำ? ใครตรวจ? ทั้งสองคนเป็นคนเดียวกันหรือไม่? และมีหลักฐานการตรวจสอบหรือเปล่า? คำตอบที่ได้จะบอกถึงระดับความเสี่ยงขององค์กรได้ทันทีครับ
|
|
🔍 Audit Checklist — 4 คำถามที่ต้องถามในทุก IT Audit
|
| IT AuditSegregation of DutiesSoDITGCChange ManagementAccess ControlMaker-CheckerBCPCase StudyInternal Audit |
