หลักการ#

กันบาดเจ็บก่อนเข้าโรงพยาบาล ดีกว่ารักษาในห้อง ER

ข้อมูลที่ผิดเข้าระบบไปแล้ว — แก้ยากกว่าและ trail หาย ป้องกันที่ด่านแรกคือต้นทุนต่ำที่สุด

Input controls มี 4 หมวดหลัก:

1. Source document / authorization — ทุก transaction ต้องมี authorization ก่อนเข้าระบบ — มี source document ที่ระบุได้ว่าใครอนุมัติ
2. Batch controls — ถ้าข้อมูลเข้าเป็น batch (กลุ่ม) → มีกลไกตรวจว่าทุก record ใน batch ถูกประมวลผลครบ
3. Edit / validation controls — ระบบตรวจรูปแบบของข้อมูลก่อนรับเข้า reject ที่ผิดรูป
4. Data conversion controls — ถ้าข้อมูลมาจากระบบอื่น ตรวจ integrity ระหว่างการ convert

Batch Controls — 4 แบบที่ทำงานคนละหน้าที่#

ลองนึกถึงการรับเช็ค 100 ใบเข้าธนาคาร — มี 4 มิติของ “ครบไหม”:

กับดัก ⚠️: Hash total = ตัวเลขทางธุรกิจ

ผิดครับ — Hash total ตั้งใจเป็นตัวเลขที่ ไม่มีความหมายในตัวเอง — รวมยอด account number, รวม customer ID, รวม invoice number การที่มันไม่มีความหมายธุรกิจคือ feature ไม่ใช่ bug — ใครที่พยายาม manipulate ตัวเลขจะไม่รู้ว่า hash total ที่คาดหวังคือเท่าไหร่

กับดัก: ใช้ batch control ประเภทเดียวพอ

ผิด — แต่ละประเภทตรวจคนละมิติ:

• Monetary total ผ่าน + item count ตก = มีคนเปลี่ยนยอดเช็คใบเดียวให้ใหญ่ขึ้น และลบเช็คใบอื่นออก
• Item count ผ่าน + monetary total ตก = มีคนเปลี่ยนยอดของเช็คบางใบ
• ทั้งคู่ผ่าน + hash total ตก = มีคนเปลี่ยน account number ของเช็คใบใดใบหนึ่ง

ระบบที่ใช้ หลายประเภทร่วมกัน จับ fraud ได้ละเอียดกว่า

Edit Controls — ระบบ reject ข้อมูลผิดรูป#

ลองนึกถึงฟอร์มขอสินเชื่อออนไลน์ของธนาคาร — ระบบจะไม่ยอมให้กดส่งถ้า:

• เลขประจำตัว 13 หลักของไทยรวม checksum ไม่ถูก (check digit verification)
• รายได้ระบุติดลบหรือเกินขอบเขตที่กำหนด (limit / range check)
• ID นี้ยื่นขอสินเชื่อในรอบ 30 วันแล้ว (duplicate check)
• กรอกอีเมลผิดรูปแบบ (validity check ต่อ format)
• เลือก “ผู้กู้ร่วม” แต่ไม่กรอกข้อมูลผู้กู้ร่วม (completeness check)
• รายได้ 100,000 แต่อายุ 18 ปีและเป็นนักศึกษา (reasonableness check)
• ระบุจังหวัด “เชียงใหม่” แต่รหัสไปรษณีย์ขึ้นต้นด้วย “10” (logical relationship check)

มี edit controls หลายแบบที่ผม distill จากที่อ่าน — แต่ละแบบตรวจคนละสิ่ง:

• Sequence check — ลำดับเลขเอกสารต่อเนื่องไหม ขาดหายไหม
• Limit check — ค่าเกินขอบเขตที่ตั้งไหม
• Range check — ค่าอยู่ในช่วงที่ valid ไหม (เช่น เดือน 1-12)
• Validity check — ค่าตรงกับ list ของค่าที่อนุญาตไหม (เช่น country code)
• Reasonableness check — ค่าสมเหตุสมผลในบริบทไหม
• Table lookup — ค่ามีใน reference table ไหม
• Existence check — field ที่บังคับมีค่าไหม
• Key verification — keying ผิดไหม (key 2 ครั้งแล้วเทียบ)
• Check digit — ตัวเลขเช็ค checksum ตรงไหม
• Completeness check — record ครบทุก field ที่ต้องมีไหม
• Duplicate check — เป็น record ที่มีอยู่แล้วไหม
• Logical relationship check — ความสัมพันธ์ระหว่าง field สมเหตุสมผลไหม

มุม IS auditor: ไม่ใช่แค่ถามว่า “มี edit check ไหม” แต่ทดสอบจริง — ส่ง test transaction ที่ผิดรูปเข้าไป ดูว่าระบบ reject หรือไม่ และ reject ถูกประเภทไหม

หลักการ#

ข้อมูลผ่านด่าน input แล้ว — เข้าระบบมา ตอนนี้ control ต้องตอบคำถาม:

“ระหว่างที่ระบบประมวลผล — ข้อมูลถูกเปลี่ยนแปลงโดยไม่ได้รับอนุญาตไหม”

Processing controls มีหลายประเภท:

Run-to-Run Totals#

ระหว่าง process — ระบบเก็บ total ก่อน-หลังของแต่ละ step → เปรียบเทียบ → ถ้าไม่ตรง = มีปัญหา

ลองนึกถึงระบบเงินเดือน:

• เริ่มต้น: 1,000 พนักงาน, total gross = 50,000,000 บาท
• หลังคำนวณภาษี: 1,000 พนักงาน, total tax = 7,500,000, total net = 42,500,000
• หลังโอนเข้าบัญชี: 1,000 transactions, total transferred = 42,500,000

ถ้าจำนวนพนักงานหลัง process ใดๆ ไม่ใช่ 1,000 — มี integrity break ที่ไหนสักจุด

Exception Reports#

ระบบบันทึก transaction ที่ “ผิดปกติ” ไว้ใน exception report — ใหก้คนตรวจสอบทีหลัง

กับดัก: Exception report = control ที่เพียงพอ

ไม่ใช่ — exception report เป็น detective control ตรวจหลังเหตุ ต้องคู่กับ:

• กระบวนการ review exception report เป็นระยะ
• ผู้รับผิดชอบที่ชัดเจน
• Timeline สำหรับแก้ไข
• Escalation เมื่อแก้ไม่ทัน

ถ้า exception report ออกทุกวัน แต่ไม่มีใครเปิด — control นี้ = 0

Reasonableness Verification#

นอกจาก validate ตอน input — ระหว่าง process ก็ verify ได้ว่าผลลัพธ์ “สมเหตุสมผล” ไหม

เช่น ระบบคำนวณยอด commission เกิน 200% ของยอดขาย — flag ให้ supervisor approve ก่อน post

Manual Recalculation#

สำหรับ transaction ใหญ่ๆ — ใช้คนคำนวณซ้ำเปรียบเทียบกับระบบ ไม่ใช่เพราะไม่เชื่อระบบ แต่เพื่อ catch programming bug + manipulation

มุมที่ผู้บริหารต้องเข้าใจ: processing controls ที่ดีไม่ได้ทำงานเงียบๆ — ต้องมีคนอ่าน, คนตอบสนอง, คนรับผิดชอบ ระบบ alert 1,000 ครั้ง/วันที่ไม่มีใครดู = control ที่อยู่บนกระดาษเท่านั้น

Before/After Image#

บันทึก snapshot ของ record ก่อนแก้ และ หลังแก้ — เพื่อ:

• Rollback transaction ที่ผิดพลาด
• Audit trail — รู้ว่าใครเปลี่ยนอะไรเป็นอะไร
• Forensic — สืบสวนเมื่อมีปัญหา

ลองนึกถึงร้านซ่อมรถที่ดี — ถ่ายรูปก่อนซ่อมและหลังซ่อม ถ้ามีข้อพิพาท = มีหลักฐาน

Transaction Logs#

บันทึก transaction ทุกตัวที่เข้าระบบ — ใคร, เมื่อไหร่, ทำอะไร, จาก IP ไหน, ผลเป็นอย่างไร

สำคัญสุด: transaction log ต้องบันทึก การเปลี่ยน system control parameters ด้วย — ไม่ใช่แค่ business transaction การที่ admin เปลี่ยน threshold ของ control = ต้อง log

Internal / External Labels#

ในระบบที่มี media (เช่น tape backup) — มี:

• Internal label — metadata ที่ระบบอ่านเพื่อ verify ว่ามี media ที่ถูก
• External label — ป้ายที่คนอ่าน เพื่อระบุ media เมื่อจะใช้

ป้องกันการใช้ wrong media (เช่น overwrite backup ของเดือนผิด)

Parity Checking#

ตรวจ integrity ของข้อมูลในการ transmission — ตรวจ bit-level error

กับดัก: Parity = security control

ผิดครับ — parity เป็น transmission integrity control ตรวจว่าข้อมูลขนส่งถึงปลายทางครบถ้วนหรือไม่ ไม่ได้ป้องกัน unauthorized access เลย

ถ้าเอกสารส่งทางไปรษณีย์มา — parity check = ตรวจว่ากระดาษที่ได้รับครบทุกแผ่น มันไม่ได้ตรวจว่า คนที่ส่งคือคนที่ควรส่งหรือเปล่า

หลักการ#

ข้อมูลออกจากระบบ — ไปไหน ใครเห็น เก็บอย่างไร

Output controls ครอบคลุม:

Report Distribution#

ใครได้รับ report อะไร — ระบุชัดเจน

ระบบที่ดี:

• มี distribution list ที่ approve โดยเจ้าของข้อมูล
• Sensitive report ส่งผ่าน secure channel (encrypted email, secure portal) ไม่ใช่ email ปกติ
• มี access control บน print queue — ป้องกันคนอื่นแอบดู report ที่ค้างใน printer

Balancing / Reconciling#

Output ของระบบหนึ่ง = input ของอีกระบบ → ต้อง reconcile ให้ตรง

เช่น ระบบ payroll output ยอดรวม = ระบบ accounting input ยอดเงินเดือน — ต้องเท่ากัน ถ้าไม่เท่า = มีปัญหาที่ต้องสืบ

Output Retention#

นานแค่ไหนเก็บ output, นานแค่ไหนทำลาย — ตามกฎหมาย + business need

ผูกกับ Domain 5: sensitive output retention ต้องมี encryption + access controls — เดี๋ยว Domain 5 จะลง data protection ลึกกว่านี้

Receipt Verification#

ผู้รับ acknowledge ว่าได้รับ output แล้ว — โดยเฉพาะสำหรับ output ที่ critical (เช่น report ส่งให้ regulator)

กับดัก: Output controls = report formatting

ผิดครับ — output controls ครอบคลุมตั้งแต่ generation → distribution → access → retention → destruction การจัดรูปแบบสวยๆ ไม่ใช่ control

ปัญหาใหญ่ที่ application controls ไม่ครอบคลุม#

ผมสะท้อนเรื่องนี้มาตั้งแต่ตอน 23 — ขอย้ำอีกครั้งเพราะเป็นเรื่องที่สำคัญที่สุดของบทนี้

กับดัก ⚠️ ใหญ่สุดของบทนี้: Application controls ครอบคลุม เส้นทางผ่าน application เท่านั้น

ถ้า DBA (Database Administrator) เข้า database ตรง — application controls ทุกตัว ถูก bypass

ลองนึกถึงร้านอาหาร:

• Application control = “ลูกค้าต้องสั่งอาหารผ่าน waiter เท่านั้น” — waiter ตรวจ menu, ตรวจ allergy, ส่งให้ chef
• DBA bypass = chef เปิดประตูครัวไปคุยกับลูกค้าเอง รับ order, ปรุง, ส่ง — ไม่ผ่าน waiter

ทุก control ที่ออกแบบให้ “ผ่าน waiter” หายไปเหมือน control ไม่เคยมี

มุม IS Auditor#

ตรวจทั้ง 2 layer:

Application layer:

• Edit controls ทำงานไหม
• Batch totals balance ไหม
• Output distribution ผ่าน controlled list ไหม

Database layer:

• ใครมี direct database access (DBA, system administrator)
• DBA access ถูก log ไหม
• DBA log ถูก review โดยคนนอกทีม DBA ไหม (SoD!)
• มี emergency change procedure สำหรับ DBA action ที่ต้อง bypass application ไหม

มุมที่ผู้บริหารต้องเข้าใจ: องค์กรที่บอกว่า “ระบบเรามี edit check ครบแล้ว ข้อมูลต้องถูกต้อง” — ขาดมิติของ database access ถ้า DBA ไม่ผ่าน SoD → control assurance ใกล้ศูนย์

เรื่อง IAM + privileged access ลึกๆ — เดี๋ยว Domain 5 จะลง access control ลึกขึ้น