สารบัญ
ใน ตอน 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 |
Case study ที่เห็นซ้ำในวงการ
กรณีที่ 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) = ระบบที่บังคับให้การส่งไฟล์ทุกครั้งมี audit trail + control ครบ
ในมุม CISA exam — CRM ไล่ความสามารถที่ MFT system ที่ดีควรมีไว้ 12 ข้อ ขอจัดเป็นตารางให้เห็นภาพรวมง่ายๆ ครับ:
| # | Capability | สิ่งที่มันทำ |
|---|---|---|
| 1 | Multiple protocols support | รองรับหลาย protocol (SFTP, FTPS, HTTPS, AS2) ไม่ผูกขาดอันเดียว |
| 2 | Inventory / categorize data files | รู้ว่ามีไฟล์อะไรอยู่ จัดกลุ่มตามประเภท/ความสำคัญ |
| 3 | Investigation register | บันทึก case ที่ต้องสอบสวน เช่น transfer ที่ผิดปกติ |
| 4 | Automate regular transfers | ตั้งเวลาส่งอัตโนมัติ ลดงาน manual + ลดความผิดพลาดของคน |
| 5 | Analyze / track / report attributes | วิเคราะห์ + ติดตาม attribute ของไฟล์ เช่น ขนาด ปลายทาง ความถี่ |
| 6 | Regulatory compliance | บังคับตามกฎ เช่น PDPA, GDPR, SOX (เก็บ log ตามที่กฎหมายกำหนด) |
| 7 | Integrate with corporate directories | ผูกกับ Active Directory / LDAP เพื่อใช้ identity เดียวกับระบบอื่น |
| 8 | Integrate with back-office | คุยกับ ERP / accounting / business application ได้ |
| 9 | Authenticate / authorize users | ยืนยันตัวตน + ตรวจสิทธิ์ก่อนปล่อยให้ส่ง/รับ |
| 10 | Encryption in transit + at rest | เข้ารหัสทั้งตอนเดินทาง + ตอนพักอยู่ในระบบ |
| 11 | Log / report | บันทึกทุก action + ทำ report ให้ auditor ตามดูได้ |
| 12 | Reconciliation | กระทบยอด — ส่งกี่ไฟล์ รับกี่ไฟล์ ตรงกันมั้ย |
ในมุม auditor ถ้าองค์กรยังพึ่ง email สำหรับส่งข้อมูล sensitive อยู่ → flag เป็น finding ทันที และถ้าใช้ MFT แล้วแต่ขาด 3 ข้อท้าย (encryption, log, reconciliation) ก็ถือว่า MFT ทำหน้าที่ไม่ครบ
EDI — รอยต่อระดับ B2B ที่ยังเป็นกระดูกสันหลังของ supply chain
หลายคนพออ่านถึงตรงนี้จะคิดว่า “ก็ใช้ API ส่งกันสิ ทำไมต้องมี standard เก่าๆ อะไรนักหนา”
แต่ในวงการ manufacturing / retail / healthcare / finance — EDI (Electronic Data Interchange) ยังเป็นกระดูกสันหลังของการแลกเปลี่ยนข้อมูล B2B จนถึงทุกวันนี้ครับ
EDI คือการที่บริษัทสองฝ่ายส่งเอกสารธุรกิจหากันแบบ structured format — ไม่ใช่ PDF แนบเมล ไม่ใช่คนนั่งกรอกฟอร์ม เอกสารที่ส่งทาง EDI บ่อยที่สุด: PO (Purchase Order / ใบสั่งซื้อ), invoice, shipping notice (ASN — Advanced Shipping Notice / ใบแจ้งการจัดส่ง), payment remittance
2 มาตรฐานที่ครองตลาด
| Standard | ใครใช้ | ลักษณะ |
|---|---|---|
| EDIFACT | UN standard — ใช้ในยุโรป + เอเชีย + การค้าระหว่างประเทศ | message มี segment + element แยกด้วย special character (+, :, ') |
| X12 | ANSI US standard — ใช้หนักใน US (retail, healthcare, logistics) | message เป็น transaction set มี ID เช่น 850=PO, 810=Invoice, 856=ASN |
ตัวอย่าง EDIFACT message สั้นๆ:
UNH+1+ORDERS:D:96A:UN'BGM+220+PO123456+9'DTM+137:20260520:102'NAD+BY+5412345678901::9'LIN+1++8901234567890:EN'QTY+21:100'UNT+7+1'ดูแล้วเหมือนเอเลี่ยนเขียน 555+ แต่จริงๆ มันคือ purchase order ใบหนึ่ง — BGM = beginning of message (เลข PO), DTM = date, NAD = name and address, LIN = line item, QTY = quantity
EDI risk ที่ auditor ต้องดู
| ความเสี่ยง | ลักษณะ |
|---|---|
| Message integrity | ระหว่างทางมีคนแก้ message มั้ย — สั่ง 100 ชิ้น กลายเป็น 1,000 |
| Sequencing | message มาตามลำดับมั้ย ขาดตัวไหนมั้ย |
| Duplicate transmission | ส่งซ้ำ → invoice ซ้ำ → จ่ายซ้ำ |
| Partner authentication | มั่นใจแค่ไหนว่าคนส่งคือ partner จริง ไม่ใช่คนปลอม |
| Repudiation | partner ปฏิเสธว่า “ฉันไม่ได้ส่ง / ไม่ได้รับ” ได้มั้ย |
Control ที่ตอบ EDI risk แต่ละข้อ
- Message Authentication Code (MAC / รหัสยืนยันความถูกต้องของข้อความ) / Digital signature — กัน tamper + กัน repudiation ในข้อเดียว
- Sequence number check — แต่ละ message มีเลขลำดับ ฝั่งรับเช็คได้ว่าขาดตัวไหน
- ACK (Acknowledgment / ยืนยันรับ) / NACK (Negative Acknowledgment / ยืนยันว่ามีปัญหา) — ฝั่งรับตอบกลับเสมอ “รับครบ” (ACK) หรือ “มีปัญหา” (NACK)
- Message log — บันทึกทุก message ที่เข้า/ออก พร้อม timestamp
- Duplicate detection — ใช้ unique message ID + เช็คว่า ID นี้เคยรับมาแล้วรึยัง
มุม auditor
ถ้าองค์กรใช้ EDI ผ่าน provider (เช่น VAN — Value Added Network) auditor ต้อง:
- ดู SLA (Service Level Agreement / สัญญาระดับการให้บริการ) ของ provider — ถ้า provider ล่ม organization จะ recover ยังไง
- ตรวจ message reconciliation — จำนวน message ที่ส่ง vs ที่ partner ยืนยันรับ ต้องตรงกัน
- validate non-repudiation control — มี digital signature / MAC ครบทุก message มั้ย
- ดู duplicate handling — ระบบ catch invoice/PO ซ้ำได้มั้ย
EDI ไม่ใช่เทคโนโลยีใหม่ แต่ก็ยังไม่ตาย supply chain ทั่วโลกยังพึ่งมันอยู่ ใครทำ audit สาย manufacturing / retail / healthcare ข้าม EDI ไม่ได้ครับ
API — interface ยุคใหม่ที่ทุก app ต้องคุย
ถ้า EDI คือกระดูกสันหลังของ B2B ยุคก่อน API (Application Programming Interface) ก็คือกระดูกสันหลังของ B2B ยุคนี้
ทุก mobile app ทุก SaaS ทุก microservice — ข้างหลังคุยกันด้วย API ทั้งนั้น แปลว่า API คือ interface ที่ auditor จะเจอบ่อยที่สุดในยุค cloud + mobile
CRM พูดถึง API ในมุม “ใช้ control เดียวกับ MFT” แต่จริงๆ API มี risk + control เฉพาะตัวที่ควรรู้แยกออกมา
API risk ที่ต้องเข้าใจ
| ความเสี่ยง | ลักษณะ |
|---|---|
| Authentication weakness | token ถูกขโมย (token theft) → คนอื่นเรียก API ในนามของเราได้ |
| Replay attack | คนดักจับ request ที่ valid แล้วส่งซ้ำ → ถ้าไม่มี timestamp/nonce ก็ผ่าน |
| Injection | ส่ง payload ที่ฝัง SQL / command / script เข้ามา → API server ทำตามที่ผู้โจมตีต้องการ |
| Schema drift | API เปลี่ยน schema โดยไม่บอก client → ระบบ partner พังเงียบ |
| Rate-limit bypass | ผู้โจมตีหาวิธี bypass rate limit → DDoS หรือ brute-force ได้ |
Control ที่ตอบ API risk
- OAuth2 (Open Authorization 2.0 — มาตรฐาน delegated access) / JWT (JSON Web Token — token แบบ self-contained) — มาตรฐาน authentication + authorization สำหรับ API (token มี expiry + scope ชัด)
- API gateway — ประตูกลางที่บังคับ policy ทั้ง authentication, rate limit, logging ก่อนถึง backend
- Rate limiting — จำกัดจำนวน request ต่อ token / IP ต่อหน่วยเวลา
- Input validation — ตรวจ payload ทุกตัวก่อน process (ทั้ง type, range, format)
- Schema versioning — ใช้ versioning (เช่น
/v1/,/v2/) ไม่ break client เก่าตอนเปลี่ยน schema - mTLS (mutual TLS) — ทั้ง client + server ต้องมี certificate → กัน rogue client
Deep dive ที่อยู่นอก scope CISA
API security ลึกลงไปอีกชั้นจะเจอเรื่อง XXE (XML External Entity attack), SOAP (Simple Object Access Protocol — มาตรฐาน web service แบบเก่า) injection, และ OWASP (Open Worldwide Application Security Project / โครงการ open community ด้าน security) API Security Top 10 — ทั้งหมดนี้ผม cover ในซีรีส์ Cybersecurity ไว้แล้ว ใครสนใจตามไปอ่านได้:
- Cybersec EP.15.5 — Web Services & SOAP / REST Security — เจาะ XXE, SOAP injection, REST API authentication
- Cybersec EP.42 — OWASP Top 10 (รวม API Top 10) — top vulnerabilities ของ web + API
CISA auditor ไม่ต้อง exploit เป็น แต่ต้องรู้ว่ามี risk เหล่านี้อยู่ + ต้อง expect ว่า penetration test report จะกล่าวถึง
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 (Hazard Analysis and Critical Control Points / มาตรฐานความปลอดภัยอาหาร) ครบ
แต่ฝ่ายจัดเลี้ยงรู้สึกว่าครัวกลางช้าเกินไป เวลามี 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 ที่ชลบุรี: ฝ่าย HR ของโรงงานสร้าง Excel ตามค่า OT (Overtime / ค่าล่วงเวลา) พนักงาน เพราะ HRMS (Human Resource Management System / ระบบบริหารทรัพยากรบุคคล) ทางการดึง 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 (Chief Information Security Officer / ผู้บริหารด้าน security ขององค์กร) หลายคน — “ออก policy ห้าม Shadow IT”
ผมว่านั่นแก้ไม่ได้หรอกครับ เพราะมัน treat symptom ไม่ใช่ root cause
Shadow IT มันเกิดเมื่อ — official IT ตอบสนองความต้องการ business ไม่ได้
ถ้า ban อย่างเดียว Shadow IT ก็ลงใต้ดินลึกขึ้น IT มองเห็นน้อยลงไปอีก ความเสี่ยงสูงขึ้นไม่ใช่ลด
วิธีที่ work กว่า:
- Discovery — ใช้ tool หา cloud app ที่กำลังใช้ในองค์กร (CASB — Cloud Access Security Broker / ตัวกลางคุม cloud usage)
- 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 คือเรื่องเดียวกัน (จริงๆ มันไม่ใช่)
auditor ที่ตามรอยปัญหาเก่งจะเริ่มที่รอยต่อก่อนเสมอ — เป็น pattern คลาสสิคที่ทุก case study ของ CISA ย้ำซ้ำๆ
อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 4: Section 4.4 System Interfaces + Section 4.5 End-User Computing and Shadow IT
