Data Leakage Management Framework

ประเทศไทยไม่ได้ขาดกฎหมาย มาตรฐาน หรือกรอบกำกับดูแลด้านข้อมูลและความมั่นคงปลอดภัยไซเบอร์ ปัจจุบันเรามีกลไกสำคัญอย่างน้อยสามเสาหลัก ได้แก่ กฎหมายและกรอบการรักษาความมั่นคงปลอดภัยไซเบอร์, กฎหมายคุ้มครองข้อมูลส่วนบุคคลและมาตรการรักษาความมั่นคงปลอดภัย และกรอบธรรมาภิบาลข้อมูลภาครัฐ

คำถามสำคัญจึงเกิดขึ้นว่า หากมีกลไกเหล่านี้อยู่แล้ว เหตุใดจึงยังมีความจำเป็นต้องพัฒนา Data Leakage Management Framework (DLMF) ขึ้นมาอีก? จะกลายเป็น Framework ซ้ำซ้อน เพิ่มภาระ Compliance ให้องค์กรหรือไม่?

คำตอบคือ ไม่ควรซ้ำซ้อน หาก DLMF ถูกวางตำแหน่งอย่างถูกต้อง เพราะ DLMF ไม่ได้ถูกออกแบบมาเพื่อเป็นกฎหมาย Cybersecurity ฉบับใหม่ ไม่ได้ทดแทน PDPA และไม่ได้สร้าง Data Governance Framework ขึ้นมาแข่งขันกับ DGA แต่ทำหน้าที่เติมช่องว่างระหว่างสิ่งที่ Governance และกฎหมายกำหนด กับสิ่งที่เกิดขึ้นกับ “ข้อมูลจริง” ในสภาพแวดล้อมดิจิทัล และพิสูจน์ว่ามาตรการที่มีอยู่สามารถควบคุมเส้นทางการรั่วไหลได้จริงหรือไม่

ประเทศไทยมี Framework สำคัญอยู่แล้ว

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

กล่าวในเชิงสถาปัตยกรรมการกำกับดูแล นี่คือ Cybersecurity Layer ที่มีความสำคัญอย่างยิ่งต่อการสร้างความสามารถในการ Identify, Protect, Detect, Respond และ Recover ตลอดจนการบริหาร Cyber Risk ในระดับองค์กรและระบบสารสนเทศ

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

นี่คือ Privacy and Personal Data Protection Layer

ประเทศไทยยังมี มาตรฐานรัฐบาลดิจิทัลว่าด้วยกรอบธรรมาภิบาลข้อมูลภาครัฐ ฉบับปรับปรุง: แนวปฏิบัติ (มรด. 6 : 2566) ของ DGA ซึ่งครอบคลุมการกำหนดสิทธิ หน้าที่ ความรับผิดชอบ การจำแนกข้อมูล และการบริหารข้อมูลตลอดวงจรชีวิต ตั้งแต่การสร้าง จัดเก็บ ประมวลผล ใช้ เปิดเผย ไปจนถึงการทำลายข้อมูล

นี่คือ Data Governance Layer

ดังนั้น หากมองในระดับนโยบาย ประเทศไทยมีองค์ประกอบสำคัญอยู่แล้วค่อนข้างครบถ้วน

Cybersecurity → Privacy/Data Protection → Data Governance

แต่ปัญหาที่เหลืออยู่ไม่ได้อยู่ที่ว่า “เรามีกฎหรือ Framework หรือไม่” เพียงอย่างเดียว แต่อยู่ที่ว่า เราสามารถเชื่อมข้อกำหนดเหล่านั้นลงไปถึงพฤติกรรมจริงของข้อมูลได้หรือไม่

ช่องว่างอยู่ระหว่าง “สิ่งที่ควรเป็น” กับ “สิ่งที่ข้อมูลกำลังทำอยู่จริง”

ลองพิจารณาข้อมูลประชาชนหนึ่งชุด

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

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

Cybersecurity Framework สามารถกำหนดกระบวนการบริหาร Cyber Risk และมาตรการควบคุมระบบ Identity, Network, Endpoint, Application, Cloud, Logging และ Incident Response

แต่เมื่อถามต่อว่า

ข้อมูลชุดนี้จริง ๆ แล้วอยู่ที่ไหนบ้าง?

คำตอบอาจไม่ได้มีเพียง Database หลัก

ข้อมูลเดียวกันอาจถูก Export ออกมาเป็น Excel อยู่ใน Notebook ของเจ้าหน้าที่ ถูกแนบไปกับ Email ถูกสำรองไว้ใน Backup ถูก Sync ไปยัง Cloud Storage ถูกนำเข้า SaaS ถูกส่งให้ Vendor ถูกเรียกผ่าน API ถูกสร้างเป็น Dataset สำหรับ Analytics หรือถูกนำไปใช้ใน Prompt, Vector Store หรือ Memory ของระบบ AI

นี่คือจุดที่การบริหารความเสี่ยงเริ่มซับซ้อน

เพราะเราอาจมี Governance ที่ถูกต้อง ระบบที่ผ่าน Security Assessment และ Privacy Policy ที่ครบถ้วน แต่ยังไม่ทราบว่า Information Instance ของข้อมูลสำคัญกระจายอยู่ที่ใด ใครสามารถทำอะไรกับแต่ละ Instance และข้อมูลสามารถออกจากขอบเขตที่ได้รับอนุญาตผ่านเส้นทางใดบ้าง

DLMF ถูกออกแบบมาเพื่อจัดการกับพื้นที่ตรงกลางนี้ ซึ่งอาจเรียกว่า “Missing Middle”

Governance Requirement → Actual Data Behaviour → Leakage Path → Risk → Control → Evidence

ปัญหาสำคัญคือ “Access ได้” ไม่เท่ากับ “ทำอะไรก็ได้”

ระบบ Access Control แบบดั้งเดิมมักตอบคำถามว่า

“บุคคลนี้สามารถเข้าถึงข้อมูลนี้ได้หรือไม่?”

แต่ Data Leakage ต้องถามลึกกว่านั้นว่า

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

ตัวอย่างเช่น เจ้าหน้าที่ฝ่ายบริการลูกค้าอาจมีสิทธิ์เปิดดูข้อมูลลูกค้าอย่างถูกต้องตามหน้าที่ แต่ไม่ได้หมายความว่าเจ้าหน้าที่คนนั้นได้รับอนุญาตให้ Download ลูกค้าทั้งฐาน ส่งออกเป็น Spreadsheet ส่งเข้า Personal Email หรือ Upload เข้า Public Generative AI

ดังนั้น หลักสำคัญของ DLMF คือ

Access Does Not Equal Authorization.

สิทธิ์ในการเข้าถึงข้อมูลเป็นเพียงหนึ่งองค์ประกอบของ Authorization เท่านั้น ยังต้องพิจารณา Actor, Action, Purpose, Channel, Location และ Trust Boundary ร่วมกันด้วย

อีกช่องว่างหนึ่งคือ “มี Control” ไม่ได้แปลว่า “Control ป้องกันข้อมูลรั่วได้จริง”

องค์กรหนึ่งอาจตอบแบบประเมินได้ว่า

• มี DLP — Yes

• มี MFA — Yes

• มี Encryption — Yes

• มี SIEM — Yes

• มี Access Control — Yes

• มี Policy — Yes

และอาจดูมีระดับ Cybersecurity Maturity ที่ดี

แต่คำถามของ DLMF แตกต่างออกไป:

ถ้าพนักงานที่ได้รับอนุญาตเปิดฐานข้อมูลลูกค้า Export ออกมาเป็นไฟล์ แล้ว Upload ไฟล์ดังกล่าวไปยัง Personal Cloud หรือ Generative AI วันนี้ — Control ที่องค์กรมีจะป้องกันได้หรือไม่? หากป้องกันไม่ได้ จะตรวจจับได้หรือไม่? มี Log หรือ Evidence เพียงพอที่จะ Trace กลับได้หรือไม่?

นี่คือความแตกต่างระหว่าง Control Existence กับ Control Effectiveness

DLMF จึงใช้หลักการ

• Evidence over Assumption

• Control Effectiveness over Control Existence

กล่าวคือ ไม่ควรสรุปว่าความเสี่ยงได้รับการจัดการแล้วเพียงเพราะองค์กรมี Policy หรือ Security Product แต่ต้องสามารถเชื่อม Control เข้ากับ Leakage Path และมีหลักฐานที่เหมาะสมว่ามาตรการนั้นทำงานจริง

DLMF จึงไม่ใช่ “Framework ตัวที่สี่” ที่มาทับสาม Framework เดิม

หากออกแบบอย่างถูกต้อง ความสัมพันธ์ควรเป็นดังนี้:

Data Governance

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

↓

Privacy / PDPA

กำหนดข้อกำหนดและความรับผิดชอบต่อ Personal Data และสิทธิของเจ้าของข้อมูล

↓

Cybersecurity Framework & Controls

สร้างความสามารถและมาตรการสำหรับ บริหาร Cyber Risk และปกป้องระบบและข้อมูล

↓

DLMF

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

DLMF จึงควรเป็น Integration and Operationalization Layer ไม่ใช่ Replacement Layer

ที่สำคัญ DLMF reuse สิ่งที่องค์กรมีอยู่แล้ว เช่น Data Owner และ Classification จาก Data Governance, Processing Purpose จาก Privacy Management, Identity และ Security Control จาก Cybersecurity, Risk Criteria จาก Enterprise Risk Management และ Evidence จาก SOC/Audit แทนที่จะบังคับให้องค์กรสร้างข้อมูลชุดใหม่ซ้ำทั้งหมด

DLMF เติมอะไรที่ยังขาดอยู่?