สารบัญ
ใน ตอน 32 ผมพูดถึง 4 theme ของ Domain 4 และ theme ที่ 2 คือ — control gap มักอยู่ที่รอยต่อ
ตอนนี้ผมขอลงไปดูรอยต่อ 2 แบบที่ Section 4.4 และ 4.5 จัดไว้:
- รอยต่อทางการ — System Interfaces: ระบบ A ส่งข้อมูลไประบบ B ที่ IT รู้จัก
- รอยต่อใต้ดิน — Shadow IT / EUC: ระบบที่ IT ไม่รู้ว่ามี (แต่บริษัทใช้งานจริง)
ทั้งคู่มี logic เดียว — ความเสี่ยงเกิดที่ข้อมูลเดินทาง ไม่ใช่ตอนข้อมูลนิ่ง
ส่วนที่ 1 — System Interfaces: ระบบที่คุยกัน แต่ไม่มีคนยืนกลาง
ภาพในหัว: สายพานในโรงงานที่ไม่มี QC ที่จุดส่งต่อ
ลองนึกถึงโรงงานประกอบรถยนต์ — ชิ้นส่วนเดินทางบนสายพานยาวต่อกันหลายช่วง ช่วงแรกเชื่อมงานปั๊มกับงานเชื่อม, ช่วงที่สองเชื่อมงานเชื่อมกับงานพ่นสี, ช่วงที่สามเชื่อมงานพ่นสีกับงานประกอบ
ในแต่ละสถานี — มี QC ทำงานอย่างเข้ม ทุกชิ้นถูกตรวจ
แต่ที่รอยต่อระหว่างสายพาน — ไม่มีใครยืน ไม่มีใครเช็คว่าชิ้นส่วนที่ออกจากสายพาน A เข้าสายพาน B ครบมั้ย ขนาดถูกต้องมั้ย หรือถูกขย้ำตอนเปลี่ยนสายพาน
System interface ก็เหมือนกัน — ระบบ A กับระบบ B ทั้งคู่มี internal control แน่นหนา แต่ระหว่างที่ข้อมูลเดินทาง จากระบบหนึ่งไปอีกระบบหนึ่ง — ใครคุม?
3 ประเภทของ interface ที่ต้องแยก
| ประเภท | ลักษณะ | ความเสี่ยงหลัก |
|---|---|---|
| System-to-System | ระบบส่งข้อมูลระหว่างกันแบบอัตโนมัติ | mapping ผิด → ข้อมูล corrupt ทั้ง batch |
| Partner-to-Partner | องค์กรเรากับ partner / vendor ภายนอก | ขยายขอบเขตความเสี่ยงไปยังองค์กรที่เราคุมไม่ได้ |
| Person-to-Person | คนส่งไฟล์ให้กัน (email, shared drive) | ไม่มี audit trail, ไม่มี integrity check |
ที่ผมเจอจริงในงาน consulting
กรณีที่ 1 — โรงพยาบาลเอกชน: ระบบลงทะเบียนผู้ป่วยส่งข้อมูลไประบบ billing ผ่าน system-to-system interface
วันหนึ่ง developer คนหนึ่งแก้ field mapping ของระบบลงทะเบียน — โดยไม่ผ่าน change management
ผลลัพธ์: ชื่อผู้ป่วยถูก truncate ก่อนส่งเข้า billing → ใบ invoice ออกไปโดยที่ชื่อผิด → ลูกค้าหลายเคสปฏิเสธจ่าย เพราะชื่อบนใบเสร็จไม่ตรงกับที่ลงทะเบียน
control gap: ไม่มี field-level validation ที่ interface และไม่มี change management สำหรับ interface config
กรณีที่ 2 — ผู้ผลิตชิ้นส่วน: partner-to-partner interface ส่งคำสั่งซื้อรายวันไปยัง supplier tier 2
วันหนึ่ง encoding ของไฟล์ที่ส่งเปลี่ยน (แค่ encoding — ไม่ใช่ logic) supplier system รับไฟล์ได้โดยไม่ error แต่อ่านได้แค่ 10% ของข้อมูล
3 วันต่อมา line ผลิตขาดชิ้นส่วน — ไม่มีใครรู้ว่าทำไม
control gap: ไม่มี reconciliation ที่ interface — ฝั่งรับไม่เคยตอบกลับว่ารับครบกี่ record
Reconciliation = control ที่ exam ออกบ่อย
reconciliation control คือคำตอบของคำถาม: “ที่รับมา = ที่ส่งไป จริงมั้ย?”
ทำได้ 3 ทาง:
- Record count — นับจำนวน record ที่ส่ง vs ที่รับ ต้องตรงกัน
- Hash checksum — เช็คค่า hash ของไฟล์ ก่อนส่ง vs หลังรับ
- Acknowledgment — ฝั่งรับยืนยันกลับ ว่ารับ batch ID นี้ครบ
control นี้ดู “เพิ่มงาน” — แต่จริงๆ แล้วมันคือสิ่งเดียวที่ทำให้ interface ไม่ใช่แค่ “ส่งแล้วลืม”
MFT — เครื่องมือที่จัดการ person-to-person ให้กลับมาควบคุมได้
Person-to-person transfer (อีเมลแนบไฟล์, share drive, SFTP แบบไม่มีใคร audit) คือรอยต่อที่ควบคุมยากที่สุด
MFT (Managed File Transfer) = ระบบที่บังคับให้การส่งไฟล์ทุกครั้งมี:
- การยืนยันตัวตนของผู้ส่ง/ผู้รับ
- encryption ระหว่างส่ง
- log ทั้ง action — ใครส่งอะไรให้ใคร เมื่อไหร่
- integrity check
- non-repudiation (ปฏิเสธไม่ได้ว่าไม่ได้ส่ง)
ในมุม auditor — ถ้าองค์กรยัง rely บน email สำหรับส่งข้อมูล sensitive อยู่ → flag เป็น finding
Trap pattern ของข้อสอบเรื่อง interface
| หลุมพราง | คำตอบที่ถูก |
|---|---|
| ”เรามี firewall ก็ปลอดภัยที่ interface แล้ว” | firewall คุม network perimeter ไม่ได้ตรวจ data integrity ที่ interface |
| ”automation = ลดความเสี่ยง” | automation ที่ interface = systemic error ตัว mapping ผิดแค่ครั้งเดียว corrupt ทุก record |
| ”trust ระบบเราเอง ไม่ต้อง reconcile” | trust ≠ control ทุก critical interface ต้องมี reconciliation |
| ”non-repudiation = ต้องใช้ digital signature” | digital signature ทำได้ แต่ logged transfer + timestamped ack ก็ใช้ได้ |
ส่วนที่ 2 — Shadow IT / EUC: รอยต่อใต้ดินที่ IT ไม่รู้ว่ามี
ภาพในหัว: ครัวฝ่าย ที่ไม่ผ่านครัวกลาง
ลองนึกถึงโรงแรมใหญ่ที่มี main kitchen ที่ดูแลโดยเชฟใหญ่และทีม — มีมาตรฐานทุกขั้นตอน, มีตู้แช่แยก, มี HACCP
แต่ฝ่ายจัดเลี้ยงรู้สึกว่าครัวกลางช้าเกินไป เวลามี request ด่วนตอน 2 ทุ่ม
ฝ่ายจัดเลี้ยงเลยตั้งครัวเล็กของตัวเอง ใน room ข้างๆ — อุปกรณ์ไม่ครบ, ไม่มีตู้แช่แยก, ไม่มี HACCP, ไม่มีคนตรวจ
แต่มันทำงานได้ — เร็ว ทันใจ ลูกค้าได้ของ
จนกระทั่ง — มีลูกค้ากลุ่มหนึ่งติดเชื้อ salmonella
นี่คือ Shadow IT ในรูปแบบ analogy — เกิดเพราะระบบทางการช้าเกินไป แก้ปัญหาเฉพาะหน้าได้ แต่อยู่นอก governance ทั้งหมด
EUC vs Shadow IT — แยกให้ชัด
| ศัพท์ | ความหมาย | ตัวอย่าง |
|---|---|---|
| EUC (End-User Computing) | non-IT staff สร้างเครื่องมือเอง ภายในเครื่องตัวเอง | Excel macro คำนวณโบนัส, Access database ของฝ่าย HR |
| Shadow IT | พนักงานเอา cloud tool / SaaS เข้ามาใช้โดย IT ไม่รู้ | สมัคร Dropbox ฟรี ส่งไฟล์ลูกค้า, ใช้ Notion ของส่วนตัวจัดการ project บริษัท |
ทั้งคู่มีรากเดียว: business ต้องการความเร็ว/ความยืดหยุ่นที่ official IT ให้ไม่ได้
ตัวอย่างที่เห็นบ่อย
EUC ที่ Chonburi: ฝ่าย HR ของโรงงานสร้าง Excel ตามค่า OT พนักงาน เพราะ HRMS ทางการดึง report ช้า
3 ปีผ่านไป — Excel มี 50,000 row, มี macro ซับซ้อน, ผู้สร้างคนเดียวที่เข้าใจ
วันที่ผู้สร้างลาออก — ไม่มีใคร maintain ได้
ปีถัดมา auditor เจอว่า formula error คำนวณ OT ผิดมา 6 เดือน → บริษัทต้องชดเชย/เรียกคืน OT หลายล้านบาท
control gap:
- ไม่มี version control / change management ของ Excel
- ไม่มี backup / disaster recovery
- ไม่มี documentation
- ไม่มี second person ตรวจ formula
Shadow IT ที่กรุงเทพ: หัวหน้าฝ่ายของโรงพยาบาลเอกชน สมัคร Google Drive ฟรี เพื่อ share consultation note กับแพทย์ผู้เชี่ยวชาญที่โรงพยาบาลอื่น
ผลลัพธ์: ชื่อ-ID-การวินิจฉัย-ยา ของผู้ป่วยอยู่บน server ของ Google นอกประเทศ นอก data governance ของโรงพยาบาล
ทีม PDPA compliance ทำ audit เจอ → critical finding ทันที
ทำไม “ห้าม” ไม่ใช่คำตอบ
ปฏิกิริยาแรกของหลาย IT/CISO — “ออก policy ห้าม Shadow IT”
ผมว่านั่นแก้ไม่ได้ เพราะมัน treat symptom ไม่ใช่ root cause
Shadow IT ขึ้นเมื่อ — official IT ตอบสนองความต้องการ business ไม่ได้
ถ้า ban อย่างเดียว → Shadow IT ลงใต้ดินลึกขึ้น → IT มองเห็นน้อยลงไปอีก → ความเสี่ยงสูงขึ้นไม่ใช่ลด
วิธีที่ work กว่า:
- Discovery — ใช้ tool หา cloud app ที่กำลังใช้ในองค์กร (CASB)
- Triage — แต่ละ tool ที่เจอ = ban / sanction / replace
- Sanction the safe ones — tool ที่ปลอดภัย + business ต้องการ → bring under official governance
- Provide alternative — สำหรับ tool ที่ ban ต้องมี official tool แทน
Trap pattern ที่ exam ออก
| หลุมพราง | คำตอบที่ถูก |
|---|---|
| ”Shadow IT = ปัญหาเสมอ ต้องห้าม” | บางส่วนของ Shadow IT แก้ปัญหาที่ official IT ตอบไม่ได้ — sanction ดีกว่า ban |
| ”EUC = แค่ Excel” | EUC รวม Access, low-code platform, RPA bot ที่ business สร้างเอง, cloud subscription |
| ”Excel เล็กๆ ไม่ critical” | criticality วัดจาก impact ไม่ใช่ size — Excel เดียวที่ CEO ใช้ตัดสินใจ = critical |
| ”ฟรี = ไม่มีต้นทุน” | ฟรี SaaS = องค์กรจ่ายด้วย “data” ที่ vendor เอาไปใช้ |
มุมผู้บริหาร
คำถามที่ผมว่าผู้บริหารควรถามก่อนโกรธพนักงาน: “ทำไมพนักงานต้องหา workaround?”
ถ้าคำตอบคือ — official tool ช้า, ใช้ยาก, ไม่ตอบ business need — นั่นคือสัญญาณว่า IT governance ของบริษัทตอบไม่ทันธุรกิจ
Shadow IT ในมุมหนึ่ง = vote of no-confidence ใน IT department
แก้ที่ root: ทำให้ official IT ตอบสนองดีขึ้น → ความต้องการสร้าง shadow tool จะลดลงเอง
ปิดบท: 2 รอยต่อ 1 หลักการ
ที่ผมเล่ามา 2 เรื่องนี้ — interfaces (รอยต่อทางการ) และ Shadow IT (รอยต่อใต้ดิน) — ดูเหมือนต่างกันมาก แต่จริงๆ มีหลักการเดียว:
ความเสี่ยงในระบบ IT ไม่ได้อยู่ในระบบ — มันอยู่ที่ระหว่างระบบ
ระบบ A ดี ระบบ B ดี — ไม่รับประกันว่า A→B ดี ระบบ official ดี — ไม่รับประกันว่าทุก data flow อยู่ในระบบ official
auditor ที่ตามรอยปัญหาเก่ง — เริ่มที่รอยต่อก่อนเสมอ
ตอนถัดไปจะลงเรื่องที่เกิดขึ้นเมื่อระบบเริ่มมีปัญหาจริง — Capacity Management, Incident Management, และ Problem Management ที่ exam ชอบหลอกว่า incident กับ problem คือเรื่องเดียวกัน (มันไม่ใช่)
อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 4: Section 4.4 System Interfaces + Section 4.5 End-User Computing and Shadow IT
