TSD โดนเจาะตรงไหน? แกะรอยช่องโหว่ในระบบ Investor Portal

เหตุข้อมูลรั่วไหลของ TSD ไม่ใช่ภาพของแฮกเกอร์ที่บุกเข้าไปในระบบซื้อขายหุ้น แล้วกดขายหุ้นของนักลงทุนออกจากพอร์ต แต่เป็นเหตุที่สะท้อนปัญหาคลาสสิกของระบบเว็บสมัยใหม่อย่างชัดเจนกว่า: ผู้ใช้ที่ล็อกอินได้ตามปกติ อาจเข้าถึงข้อมูลที่ไม่ใช่ของตัวเองได้ หากระบบตรวจสอบ “สิทธิ์ในการดูข้อมูลแต่ละรายการ” ไม่รัดกุมพอ

ความต่างระหว่างสองประโยคนี้สำคัญมาก

• “ผู้ใช้เข้าสู่ระบบสำเร็จ”

• “ผู้ใช้ได้รับอนุญาตให้เข้าถึงข้อมูลชิ้นนี้”

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

จากข้อมูลที่เปิดเผยต่อสาธารณะ เหตุเกิดขึ้นกับ TSD Investor Portal ซึ่งเป็นบริการออนไลน์สำหรับผู้ถือหุ้นและผู้ลงทุน ไม่ใช่ระบบซื้อขายหลักทรัพย์โดยตรง TSD ระบุว่าพบการเข้าถึงข้อมูลส่วนบุคคลโดยไม่ได้รับอนุญาต และดำเนินการปิดกั้นการเข้าถึงทันที โดยยืนยันว่าไม่กระทบการซื้อขายหลักทรัพย์หรือทรัพย์สินภายใต้การดูแลของบริษัท
รายงานที่อ้างคำชี้แจงผู้บริหารด้านเทคโนโลยีระบุว่า จุดที่มีปัญหาอยู่บริเวณหน้า User Profile และเกี่ยวข้องกับการเปลี่ยนค่า ID เพื่อเรียกดูข้อมูลผู้ใช้งานรายอื่น ไม่ใช่การเจาะเข้าสู่ระบบซื้อขายหรือระบบถือครองหลักทรัพย์โดยตรง

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

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

เริ่มจากการแยกระบบที่คนมักปนกัน

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

คำตอบที่ต้องแยกให้ชัดคือ ระบบดิจิทัลขององค์กรขนาดใหญ่ไม่ใช่กล่องใบเดียวที่เก็บทุกอย่างไว้รวมกัน

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

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

ข้อมูลที่รายงานต่อสาธารณะระบุว่า ระบบ Investor Portal เป็นระบบแสดงข้อมูลที่แยกจากระบบหลังบ้านซึ่งเก็บข้อมูลการถือครองหลักทรัพย์จริง และระบบหลังบ้านดังกล่าวไม่ได้เชื่อมต่ออินเทอร์เน็ตโดยตรง จึงไม่พบการเข้าถึงข้อมูลการถือครองหุ้นหรือการซื้อขายจากเหตุนี้
TSD ยังยืนยันในประกาศว่าผลกระทบไม่ครอบคลุมการซื้อขายหลักทรัพย์ ข้อมูลด้านการเงิน หรือทรัพย์สินภายใต้การดูแลของบริษัท

สิ่งนี้อธิบายได้ว่าทำไมคำตอบต่อคำถาม “หุ้นหายไหม” จึงต่างจากคำตอบต่อคำถาม “ข้อมูลรั่วไหม” ได้ หุ้นและข้อมูลส่วนบุคคลอาจอยู่คนละระบบ คนละฐานข้อมูล คนละสิทธิ์การเข้าถึง และคนละรูปแบบของความเสียหาย

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

ดังนั้น การบอกว่า “หุ้นยังอยู่” เป็นข้อเท็จจริงสำคัญที่ช่วยลดความตื่นตระหนก แต่ไม่ควรถูกตีความต่อว่า “จึงไม่มีอะไรน่ากังวล”

ประตูบานแรก: Authentication

ก่อนจะเข้าใจช่องโหว่ ต้องแยกสองคำที่มักถูกใช้แทนกันแบบผิด ๆ คือ authentication และ authorization

Authentication คือการพิสูจน์ตัวตน ระบบกำลังถามว่า “คุณคือใคร”

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

Authorization คือการตรวจสอบสิทธิ์ ระบบกำลังถามว่า “คุณทำอะไรได้บ้าง” และในกรณีที่ละเอียดขึ้น ระบบจะถามว่า “คุณทำสิ่งนี้กับข้อมูลชิ้นนี้ได้หรือไม่”

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

ข้อผิดพลาดที่พบบ่อยในการพัฒนาระบบคือ ทีมงานให้ความสำคัญมากกับประตูหน้า รหัสผ่านต้องยาวพอ ต้องมี OTP ต้องล็อกบัญชีเมื่อกรอกรหัสผิดหลายครั้ง ต้องจับบอต และต้องมี CAPTCHA แต่เมื่อผู้ใช้ผ่านประตูหน้าเข้ามาแล้ว ระบบกลับเชื่อคำขอจากผู้ใช้มากเกินไป

เช่น ระบบอาจรับคำขอที่ความหมายใกล้เคียงกับ “ขอดูข้อมูลบัญชีหมายเลขนี้” โดยตรวจสอบเพียงว่าผู้ส่งคำขอล็อกอินแล้ว แต่ไม่ได้ตรวจให้แน่ชัดว่า บัญชีหมายเลขนั้นเป็นของผู้ส่งคำขอจริงหรือไม่

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

นี่คือเหตุผลที่ความปลอดภัยของระบบไม่ควรถูกประเมินจากคำถามว่า “มีการล็อกอินหรือไม่” เพียงอย่างเดียว คำถามที่สำคัญกว่าคือ “ทุกครั้งที่มีการขอข้อมูล ระบบตรวจสอบเจ้าของข้อมูลและขอบเขตสิทธิ์จริงหรือไม่”

ประตูบานที่สอง: Authorization

ระบบเว็บจำนวนมากทำงานผ่านตัวระบุบางอย่างเสมอ อาจเป็นเลขสมาชิก เลขเอกสาร เลขคำสั่งซื้อ รหัสบัญชี รหัสพอร์ต รหัสผู้ถือหุ้น หรือค่าเฉพาะในฐานข้อมูล

ตัวระบุเหล่านี้จำเป็นต่อการทำงาน เพราะระบบต้องรู้ว่าจะดึงข้อมูลรายการใดมาแสดง หากผู้ใช้เปิดหน้าประวัติส่วนตัว ระบบก็ต้องทราบว่าจะแสดงข้อมูลของใคร หากเปิดเอกสาร ระบบก็ต้องทราบว่าจะส่งเอกสารฉบับไหนกลับมา

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

ในภาษาทางเทคนิค แนวคิดนี้มักถูกอธิบายภายใต้กลุ่ม Broken Access Control หรือความบกพร่องในการควบคุมสิทธิ์เข้าถึง ส่วนกรณีที่ผู้ใช้อ้างอิงวัตถุหรือเรคคอร์ดที่ไม่ใช่ของตนได้โดยตรง มักถูกเรียกในวงการว่า Insecure Direct Object Reference หรือ IDOR

ชื่ออาจฟังซับซ้อน แต่แก่นของมันเรียบง่ายมาก

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

จุดสำคัญคือ ตัวระบุที่คาดเดายากไม่ได้แก้ปัญหาในระดับหลักการ

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

ความปลอดภัยที่แท้จริงจึงไม่ใช่ “ทำให้คนอื่นเดารหัสไม่ออก” แต่คือ “ต่อให้รู้รหัสของข้อมูลชิ้นนั้น ก็ยังอ่านไม่ได้หากไม่มีสิทธิ์”

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

โค้ดที่ควรเป็นในเชิงตรรกะต้องใกล้เคียงกับ “ค้นหาเอกสารหมายเลขนี้ โดยเงื่อนไขว่าต้องเป็นเอกสารที่อยู่ภายใต้สิทธิ์ของผู้ใช้ที่ล็อกอินอยู่เท่านั้น” ความแตกต่างระหว่างสองประโยคนี้คือเส้นแบ่งระหว่างระบบที่แสดงข้อมูลได้ กับระบบที่คุ้มครองข้อมูลได้

หน้าเว็บไม่ใช่ระบบรักษาความปลอดภัย

อีกความเข้าใจผิดที่พบได้บ่อยคือ ถ้าหน้าเว็บไม่มีปุ่มให้กด ผู้ใช้ก็ไม่น่าจะทำสิ่งนั้นได้

แต่นั่นเป็นการมองระบบจากมุมของคนที่ใช้หน้าจอ ไม่ใช่มุมของคนที่มองการสื่อสารระหว่างเบราว์เซอร์กับเซิร์ฟเวอร์

เมื่อคุณกดปุ่ม “ดูข้อมูลส่วนตัว” หน้าเว็บไม่ได้เสกข้อมูลขึ้นมาเอง เบราว์เซอร์ต้องส่งคำขอไปยังระบบหลังบ้าน แล้วระบบหลังบ้านจึงตอบกลับด้วยข้อมูลที่เหมาะสม คำขอนั้นอาจไปในรูปแบบการเปิดหน้าเว็บ การเรียก API การขอไฟล์ หรือการส่งข้อมูลแบบฟอร์ม

ปุ่มบนหน้าจอเป็นเพียงอินเทอร์เฟซ ไม่ใช่ขอบเขตของสิทธิ์

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

พูดให้ตรงที่สุดคือ ฝั่งหน้าจอบอกผู้ใช้ว่า “คุณควรทำอะไร” แต่ฝั่งเซิร์ฟเวอร์ต้องเป็นผู้ตัดสินว่า “คุณทำอะไรได้จริง”

ในกรณีที่รายงานระบุถึงหน้า User Profile และการเปลี่ยนค่า ID ประเด็นที่น่าสนใจทางวิศวกรรมจึงไม่ใช่แค่ว่า ค่า ID อยู่ตรงไหน แต่คือเส้นทางทั้งหมดตั้งแต่เบราว์เซอร์ส่งคำขอ ไปจนถึงระบบอ่านฐานข้อมูลกลับมา มีจุดใดที่ขาดการตรวจสิทธิ์หรือไม่

คำถามเชิงเทคนิคที่ทีมตรวจสอบควรถาม ได้แก่

• ผู้ใช้รายหนึ่งสามารถร้องขอข้อมูลของอีกบัญชีได้ผ่านเส้นทางใด

• มีการตรวจว่าตัวระบุข้อมูลสัมพันธ์กับ session ของผู้ใช้หรือไม่

• การตรวจสิทธิ์ทำอยู่ที่หน้าเว็บ API หรือชั้นฐานข้อมูล

• ทุก endpoint ใช้มาตรฐานการตรวจสิทธิ์เดียวกันหรือไม่

• มี endpoint เก่าหรือ endpoint ภายในที่ยังเปิดอยู่โดยไม่ผ่านการตรวจแบบเดียวกันหรือไม่

• ระบบบันทึกการเข้าถึงข้อมูลละเอียดพอจะย้อนรอยได้หรือไม่

• การเข้าถึงข้อมูลจำนวนมากในเวลาสั้น ๆ ถูกตรวจจับหรือไม่

• บัญชีที่มีพฤติกรรมผิดปกติถูกระงับอัตโนมัติได้เร็วเพียงใด

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

จากข้อมูลหนึ่งรายการสู่ข้อมูลจำนวนมาก

หลายคนอาจสงสัยว่า ต่อให้ระบบพลาดจริง มันจะสร้างความเสียหายระดับใหญ่ได้อย่างไร ในเมื่อผู้โจมตีต้องขอข้อมูลทีละคน

คำตอบคือ ระบบดิจิทัลมีคุณสมบัติที่มนุษย์ไม่มี: การทำซ้ำอย่างรวดเร็วและสม่ำเสมอ

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

นี่คือเหตุผลที่การป้องกันต้องเป็นหลายชั้น

ชั้นแรกคือ authorization ที่ถูกต้อง ต่อให้มีการส่งคำขอจำนวนเท่าใด ถ้าไม่มีสิทธิ์ก็ต้องไม่ได้ข้อมูลกลับไป

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

ชั้นที่สามคือ anomaly detection หรือการตรวจจับความผิดปกติ เช่น บัญชีหนึ่งเข้าดูข้อมูลซ้ำ ๆ ในรูปแบบที่ต่างจากพฤติกรรมปกติ มีการเปลี่ยนตัวระบุบ่อยครั้ง มีการเรียกข้อมูลจากหลายบัญชี หรือทำงานต่อเนื่องในลักษณะที่ไม่เหมือนมนุษย์ใช้บริการ

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

ชั้นที่ห้าคือ incident response หรือการตอบสนองเมื่อเกิดเหตุ หากตรวจพบความผิดปกติ ต้องมีอำนาจและขั้นตอนในการปิด endpoint ระงับบัญชี บังคับเปลี่ยนข้อมูลยืนยันตัวตน ทบทวน log และแจ้งผู้ได้รับผลกระทบตามความเหมาะสม

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

สิ่งที่เหตุการณ์นี้ไม่ใช่

การอธิบายเหตุการณ์ให้ถูกต้อง ต้องระวังไม่ให้ใช้คำกว้างจนเกินจริง

นี่ไม่ใช่หลักฐานว่าระบบซื้อขายหลักทรัพย์ถูกยึด
ไม่ใช่ข้อมูลว่าหุ้นถูกโอน
ไม่ใช่การยืนยันว่าผู้ใช้ทุกคนได้รับผลกระทบ
ไม่ใช่เหตุที่แปลว่ารหัสผ่านหรือ OTP ของทุกคนถูกเปิดเผย
และไม่ควรสรุปว่าเป็นการเจาะระบบแกนกลางเพียงเพราะมีคำว่า “แฮก” ในพาดหัวข่าว

แต่ในทางกลับกัน ก็ไม่ควรลดทอนว่าเป็นเพียงบั๊กเล็ก ๆ เพราะคำว่า “ไม่กระทบเงินโดยตรง” ไม่ได้ลบความรุนแรงของข้อมูลระบุตัวตนที่รั่วไหล

ชุดข้อมูลส่วนบุคคลที่เชื่อมกันหลายมิติมีมูลค่าสูงกว่าข้อมูลชิ้นเดียวมาก เบอร์โทรศัพท์อย่างเดียวอาจทำให้เกิดสแปม อีเมลอย่างเดียวอาจทำให้เกิดฟิชชิง แต่เมื่อมิจฉาชีพมีชื่อจริง ข้อมูลติดต่อ เลขบัตร ข้อมูลโบรกเกอร์ และข้อมูลธนาคาร การหลอกลวงสามารถออกแบบให้เฉพาะเจาะจงและน่าเชื่อถือกว่ามาก

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

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

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

ทำไมการแบ่งแยกระบบจึงมีความหมาย

ถ้ามองเหตุการณ์นี้ในแง่บวกเชิงวิศวกรรม สิ่งหนึ่งที่ควรให้ความสำคัญคือการแบ่งส่วนของระบบ หรือ segmentation

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

เมื่อยอมรับว่าความผิดพลาดอาจเกิดขึ้น การออกแบบที่ดีจึงไม่ใช่แค่พยายามป้องกันไม่ให้ใครผ่านเข้ามาได้ แต่ต้องจำกัดด้วยว่า ถ้าผ่านเข้ามาได้แล้ว เขาจะไปต่อได้ไกลแค่ไหน

นี่คือหลักของ blast radius หรือรัศมีความเสียหาย

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

การแยกระบบที่ดีไม่ได้หมายถึงแยกด้วยชื่อโปรเจกต์หรือแยกด้วยคนละหน้าจอเท่านั้น แต่ต้องแยกในระดับที่ตรวจสอบได้จริง เช่น

• แยกเครือข่ายและเส้นทางการเชื่อมต่อ

• แยกบัญชีบริการและสิทธิ์ของแต่ละระบบ

• แยกฐานข้อมูลหรืออย่างน้อยแยกสิทธิ์การอ่านเขียน

• แยก secret และกุญแจเข้ารหัส

• จำกัด API ให้เข้าถึงเฉพาะข้อมูลที่จำเป็น

• ตรวจสอบและบันทึกการข้ามขอบเขตระบบ

• ไม่อนุญาตให้บริการฝั่งอินเทอร์เน็ตมีสิทธิ์ผู้ดูแลระบบแกนกลาง

• ใช้หลัก least privilege หรือให้สิทธิ์น้อยที่สุดเท่าที่จำเป็น

จากข้อมูลที่เปิดเผย การแยก Investor Portal ออกจากระบบข้อมูลการถือครองหลักทรัพย์ช่วยอธิบายได้ว่าทำไมเหตุจึงไม่ลุกลามสู่การซื้อขายหรือการย้ายทรัพย์สิน[youtube]
นี่ไม่ใช่เหตุผลให้หยุดตั้งคำถามต่อความปลอดภัยของพอร์ทัล แต่เป็นบทเรียนว่า การออกแบบระบบให้แยกขอบเขตสามารถลดระดับความรุนแรงของเหตุการณ์ได้จริง

บทเรียนที่ยากกว่า: ข้อมูลใดควรอยู่ตรงนั้น

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

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

หลัก data minimization หรือการเก็บและใช้ข้อมูลเท่าที่จำเป็น จึงไม่ใช่เพียงประเด็นกฎหมายคุ้มครองข้อมูลส่วนบุคคล แต่เป็นแนวทางลดผลกระทบทางเทคนิค

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

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

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

ช่องโหว่ไม่ได้เริ่มและจบที่โค้ด

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

คำถามสำคัญคือ ช่องโหว่ผ่านมาถึงระบบจริงได้อย่างไร

อาจเกิดจาก requirement ที่ไม่ได้ระบุเงื่อนไขสิทธิ์ชัดเจน
อาจเกิดจากนักพัฒนามองว่า user ID ที่มาจากหน้าเว็บเชื่อถือได้
อาจเกิดจาก code review ที่มองฟังก์ชันการทำงาน แต่ไม่ทดสอบกรณีผู้ใช้พยายามเข้าถึงข้อมูลคนอื่น
อาจเกิดจากชุดทดสอบที่ทดสอบเฉพาะ “เจ้าของบัญชีดูข้อมูลตัวเองได้” แต่ไม่ทดสอบ “คนอื่นดูข้อมูลบัญชีนี้ไม่ได้”
อาจเกิดจากการปรับปรุงระบบหลายรอบจนมาตรฐานการยืนยันสิทธิ์ไม่เหมือนกันในแต่ละ endpoint
อาจเกิดจากการพึ่งพา frontend เพื่อซ่อนเมนูมากเกินไป
หรืออาจเกิดจากการทดสอบเจาะระบบที่ตรวจภาพรวม แต่ไม่ได้ลงลึกใน authorization matrix ของทุกฟังก์ชัน

คำว่า authorization matrix ฟังดูเป็นเอกสารราชการ แต่มีประโยชน์มาก มันคือการกำหนดอย่างเป็นระบบว่า บทบาทไหนทำอะไรกับทรัพยากรใดได้บ้าง

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

เมื่อมีตารางสิทธิ์ชัดเจน ทีมพัฒนาสามารถแปลงมันเป็น test case ได้ ระบบทดสอบอัตโนมัติสามารถลองในเชิงป้องกันว่า ผู้ใช้ A เข้าถึงของ A ได้จริงหรือไม่ และผู้ใช้ A ถูกปฏิเสธเมื่อขอของ B หรือไม่

ความแตกต่างระหว่างการทดสอบสองแบบนี้เล็กมากในจำนวนบรรทัด แต่ใหญ่โตในความหมาย

• ทดสอบว่าอนุญาตสิ่งที่ควรอนุญาต

• ทดสอบว่าปฏิเสธสิ่งที่ไม่ควรอนุญาต

ทีมที่ทดสอบเฉพาะข้อแรกอาจมีระบบที่ “ใช้ได้” แต่ยังไม่ใช่ระบบที่ “ปลอดภัย”

Secure SDLC ไม่ใช่เอกสารที่วางไว้เฉย ๆ

หลายองค์กรมีนโยบาย Secure Software Development Life Cycle หรือ Secure SDLC อยู่แล้วในรูปเอกสาร มีการอบรม มี checklist มีการสแกนช่องโหว่ และมีการทดสอบก่อนปล่อยระบบ แต่คำถามสำคัญคือ กระบวนการเหล่านั้นสัมผัสกับความเสี่ยงจริงของระบบหรือไม่

การสแกนโค้ดช่วยค้นหารูปแบบอันตรายได้ดี เช่น การฝังรหัสผ่านในโค้ด การใช้ฟังก์ชันไม่ปลอดภัย หรือการรับข้อมูลผู้ใช้แบบเสี่ยง แต่ช่องโหว่การตรวจสิทธิ์มักต้องอาศัยความเข้าใจบริบทธุรกิจร่วมด้วย

เครื่องมืออาจรู้ว่า endpoint นี้รับเลขบัญชี แต่ไม่รู้เองว่าผู้ใช้คนนี้ควรเห็นบัญชีใด
เครื่องมืออาจเห็นว่ามีการตรวจ token แล้ว แต่ไม่รู้ว่า token นั้นถูกนำมาเชื่อมกับเจ้าของข้อมูลอย่างถูกต้องหรือไม่
เครื่องมืออาจเห็นว่า API ตอบกลับสถานะ 200 ตามปกติ แต่ไม่รู้ว่าควรตอบ 403 เพราะผู้ใช้ไม่มีสิทธิ์

นี่จึงเป็นเหตุผลที่การทดสอบ authorization ต้องผสมกันระหว่างเครื่องมืออัตโนมัติ การทบทวนโดยมนุษย์ และการทำ threat modeling

Threat modeling คือการถามล่วงหน้าว่า ถ้าผู้ใช้หรือผู้ไม่หวังดีพยายามใช้ระบบนอกเส้นทางปกติ จะเกิดอะไรขึ้น

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

หลังเหตุ TSD มีรายงานว่าองค์กรดำเนินการปิดช่องโหว่ ปรับปรุงการยืนยันตัวตน ใช้ AI สแกนโค้ดในระบบเครือ SET Group และเพิ่มความเข้มงวดของการทดสอบเจาะระบบ
มาตรการเหล่านี้มีความหมาย แต่ความท้าทายที่แท้จริงคือการเปลี่ยนผลจากการตรวจสอบให้กลายเป็นมาตรฐานการพัฒนาอย่างต่อเนื่อง ไม่ใช่กิจกรรมเฉพาะกิจหลังเกิดเหตุ

สิ่งที่ผู้ใช้ควรเข้าใจโดยไม่ต้องเป็นผู้เชี่ยวชาญ

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

ข้อแรกคือ แยกเหตุข้อมูลรั่วออกจากข้อความที่มิจฉาชีพส่งมา

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

ข้อสองคือ ไม่ใช้ลิงก์ใน SMS หรืออีเมลเป็นประตูไปสู่การแก้ปัญหา

หากสงสัยว่ามีเรื่องเกี่ยวกับบัญชี ให้เปิดแอปหรือเว็บไซต์ทางการด้วยตัวเอง หรือโทรไปยังหมายเลขที่ได้จากเว็บไซต์หลัก ไม่ใช่หมายเลขในข้อความที่เพิ่งได้รับ

ข้อสามคือ ไม่ยืนยันสิ่งที่เราไม่ได้เริ่ม

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

ข้อสี่คือ ระวังการเปลี่ยนเกมของมิจฉาชีพ

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

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

บทสรุปที่ไม่ควรถูกสรุปง่ายเกินไป

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

แต่ประโยคเดียวนี้ยังมีบทเรียนซ่อนอยู่หลายชั้น

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

เหตุนี้จึงไม่ควรถูกจำแค่ว่า “TSD โดนแฮก” หรือ “หุ้นไม่หาย” เพราะทั้งสองประโยคง่ายเกินไปสำหรับปัญหาที่ซับซ้อนกว่า สิ่งที่เกิดขึ้นจริงเป็นบททดสอบของการออกแบบสิทธิ์ การแบ่งแยกระบบ การเฝ้าระวังพฤติกรรมผิดปกติ วินัยในการพัฒนาซอฟต์แวร์ และความเข้าใจของผู้ใช้ต่อภัยคุกคามที่ตามมาหลังข้อมูลรั่ว

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

“คนที่กำลังขอข้อมูลนี้ มีสิทธิ์เห็นมันจริงหรือไม่”