กว่าทีมจะรู้ตัว รายชื่อลูกค้า Source Code หรือแผนธุรกิจสำคัญ อาจถูกนำออกจากองค์กรไปแล้ว

เหตุการณ์ลักษณะนี้เรียกว่า Data Exfiltration หรือการนำข้อมูลออกจากระบบโดยไม่ได้รับอนุญาต

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

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

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

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

ผลกระทบจึงไม่ได้จบอยู่ที่ไฟล์หนึ่งชุด

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

Data Exfiltration ไม่ได้เกิดเหมือนโจรพังประตูโกดังแล้วขนสินค้าออกไปทั้งคันรถเสมอไป

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

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

3 สัญญาณและช่องว่างที่ทีมควรจับตา

1. ข้อมูลถูกทยอยนำออกเป็นชุดเล็กๆ

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

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

2. ข้อมูลซ่อนอยู่ใน Traffic หรือไฟล์ที่ดูปกติ

ข้อมูลอาจถูกส่งผ่านช่องทางที่องค์กรใช้งานอยู่แล้ว เช่น Web Traffic, Cloud Storage, Email หรือ DNS ส่วนบางกรณีอาจใช้เทคนิคอย่าง Steganography เพื่อซ่อนข้อมูลไว้ในไฟล์ภาพหรือสื่อดิจิทัล

การมองเพียงชื่อไฟล์และนามสกุลจึงอาจไม่เพียงพอ ต้องพิจารณาทั้งต้นทาง ปลายทาง พฤติกรรมผู้ใช้ และบริบทของการใช้งานร่วมกัน

3. ความเสี่ยงเพิ่มขึ้นในช่วงที่สิทธิ์และบทบาทกำลังเปลี่ยน

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

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

ก่อนซื้อ Tool เพิ่ม ลองตอบ 3 คำถามนี้ให้ชัด

องค์กรสามารถเริ่มสำรวจสถานการณ์ของตัวเองได้จากคำถามต่อไปนี้

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

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

การรับมือ Data Exfiltration จึงควรทำหลายชั้นร่วมกัน

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

Data-Centric Security เริ่มจากการจัดประเภทข้อมูล กำหนดเจ้าของ และวางมาตรการคุ้มครองให้เหมาะกับระดับความสำคัญ ตั้งแต่การจัดเก็บ การใช้งาน ไปจนถึงการส่งต่อ

จากนั้นจึงเชื่อม Data Loss Prevention, Identity and Access Management, Logging และ Monitoring เข้ากับกระบวนการ Incident Response เพื่อให้การควบคุมสิทธิ์ การตรวจจับ และการตอบสนองทำงานต่อเนื่องกัน

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

ตรงนี้ทำให้ IT Service Desk มีบทบาทมากกว่าการรับแจ้งปัญหา เพราะเป็นจุดเชื่อมระหว่าง Ticket คำขอสิทธิ์ การ Reset Password การติดตั้ง Software และการประสาน Incident ข้ามทีม

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

เมื่อปริมาณ Ticket และคำขอเพิ่มขึ้น ทีมจึงต้องหาวิธีทำให้งาน Routine เดินเร็วขึ้น โดยยังรักษา Policy, Approval และ Auditability ไว้ครบ

Agentic AI เป็นหนึ่งในแนวทางที่นำมาออกแบบ Workflow ลักษณะนี้ได้

ต่างจาก Chatbot ที่เน้นตอบคำถาม AI Agent สามารถรับเป้าหมาย วิเคราะห์ข้อมูล เลือกใช้ Tools และส่งต่องานไปยัง Specialist Agent ภายใน Workflow และขอบเขตสิทธิ์ที่องค์กรกำหนดไว้

ตัวอย่างเช่น เมื่อมีคำขอ Reset Password เข้ามา Agent อาจรวบรวมข้อมูล ตรวจสอบเงื่อนไขเบื้องต้น และเรียกใช้ Tool ที่องค์กรอนุญาต หลังผ่านขั้นตอนยืนยันตัวตนและ Policy ที่กำหนดไว้

ส่วน Action ที่มีความเสี่ยงสูง เช่น การ Disable Account การลบข้อมูล หรือการให้สิทธิ์เข้าถึงระบบสำคัญ สามารถกำหนดให้ Agent หยุด Workflow และรอ Human Approval ก่อนดำเนินการต่อ

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

หากออกแบบ Tool permissions, Approval, Logging และ Escalation อย่างเหมาะสม แนวทางนี้มีโอกาสช่วยลดงาน Routine และทำให้การควบคุม Workflow ตรวจสอบได้ชัดเจนขึ้น

สำหรับ IT Service Desk Managers, IT Operations Leaders และผู้ที่ต้องการออกแบบ Workflow ของ Service Desk ด้วย Agentic AI พร้อมทดลองพัฒนาระบบผ่าน Python

NTC ขอแนะนำหลักสูตร Agentic AI for Next-Generation IT Service Desk

หลักสูตร 3 วันที่พาผู้เรียนตั้งแต่การวิเคราะห์ Bottleneck ของ Service Desk ไปจนถึงการออกแบบและพัฒนา Agentic Workflow ผ่าน Hands-on Lab

• —ผู้เรียนจะเริ่มจากการสร้าง Helpdesk Agent ด้วย OpenAI Codex และ Agents SDK พร้อมออกแบบ Function Tools สำหรับงาน IT Operations โดยทดลองให้ Agent วิเคราะห์ Ticket จัดลำดับ Incident สร้าง Ticket และดำเนินการกับ Service Request ตามเงื่อนไขที่กำหนด
• —จาก Agent ตัวแรก จะต่อยอดสู่ระบบที่ทำงานร่วมกันหลายบทบาท ผ่าน Multi-Agent Handoffs ให้ Triage Agent วิเคราะห์ปัญหาและส่งต่อไปยัง Network, Account หรือ Hardware Specialist Agent ได้ตามสถานการณ์
• —สำหรับ Action ที่มีความเสี่ยงสูง ผู้เรียนจะได้ออกแบบ Human-in-the-loop เพื่อให้ Agent หยุดรอการตรวจสอบจากมนุษย์ พร้อมวาง Audit Trail ให้ทุกขั้นตอนสามารถตรวจสอบย้อนหลังได้
• —วันที่สามจะขยับจากการสร้าง Workflow ไปสู่มุมบริหาร ทั้ง Analytics, Governance การควบคุมข้อมูลที่มีความอ่อนไหว การประเมิน Business Case และการวาง Roadmap ระยะ 3, 6 และ 12 เดือน
• —ก่อนจบหลักสูตร ผู้เรียนจะนำทุกส่วนมาประกอบเป็น Agentic Helpdesk Prototype พร้อม Architecture Diagram, Govern