การแชร์ข้อมูลบน Microsoft Fabric อย่างปลอดภัยไม่ได้จบแค่การให้สิทธิ์เข้าใช้งานระบบ แต่ต้องอาศัยการออกแบบสิทธิ์หลายชั้น (Multi-layered Defense) เพื่อให้มั่นใจว่าผู้ใช้แต่ละคนเข้าถึงได้เฉพาะข้อมูลที่จำเป็นจริงๆ เท่านั้น บทความนี้สรุปแนวคิดสำคัญพร้อมกรณีศึกษาจำลอง จากวิดีโอสอนของ 9Expert Training ว่าทำไมเรื่องนี้ถึงสำคัญ
ในองค์กรที่เริ่มรวมข้อมูลไว้บน Microsoft Fabric ความเสี่ยงที่พบบ่อยที่สุดไม่ใช่การถูกเจาะระบบจากภายนอก แต่คือการ “ให้สิทธิ์เกินความจำเป็น” กับภายใน
- ให้สิทธิ์ง่ายเกินไป: เพราะการดึงคนเข้า Workspace Role ทำได้เร็วกว่า หลายทีมจึงเลือกวิธีนี้ ผลคือผู้ใช้เห็นข้อมูลของแผนกอื่นที่ไม่ควรเห็น
- ตรวจสอบย้อนหลังยาก: เมื่อสิทธิ์กระจุกอยู่ที่ระดับ Workspace จะบอกได้ยากว่าใครเข้าถึงตารางไหนได้บ้าง
- กระทบงาน Compliance: ข้อมูลอ่อนไหว เช่น เงินเดือนหรือข้อมูลลูกค้า ต้องพิสูจน์ได้ว่ามีการจำกัดการเข้าถึงจริง
การเข้าใจโครงสร้างสิทธิ์ของ Fabric ตั้งแต่ต้น จึงช่วยลดทั้งความเสี่ยงด้านข้อมูลรั่วไหลและภาระในการจัดการสิทธิ์ระยะยาว
1. ด่านการควบคุมการเข้าถึง (Access Control Gates)
การเข้าถึงข้อมูลบน Microsoft Fabric จะต้องผ่านด่านความปลอดภัยสำคัญตามลำดับ ดังนี้
ด่านแรก: การพิสูจน์ตัวตน (Authentication)
ด่านแรกสุดที่ทุกคนต้องผ่านคือการยืนยันตัวตนผ่านระบบ Microsoft Entra ID (หรือบัญชี Microsoft Account ที่ผูกไว้กับฝั่ง Microsoft 365 หรือ Azure Entra ID) หากไม่สามารถพิสูจน์ตัวตนผ่านด่านนี้ได้ ก็จะไม่มีสิทธิ์เข้าไปทำกระบวนการใดๆ ต่อได้เลย
ด่านที่สอง: สิทธิ์การเข้าใช้งานระบบ vs. สิทธิ์เข้าถึงข้อมูล
การที่ผู้ใช้ได้รับสิทธิ์ให้ล็อกอินเข้ามาใช้งานระบบ Microsoft Fabric ได้นั้น ไม่ได้หมายความว่าจะสามารถมองเห็นหรือเข้าถึงข้อมูลภายในได้โดยอัตโนมัติ ระบบยังจำเป็นต้องมีการควบคุมความปลอดภัยลึกลงไปในระดับข้อมูลจริงๆ อีกชั้นหนึ่ง
2. แนวคิดการออกแบบสิทธิ์บน Workspace Roles และ Granular Access
ในการแชร์ข้อมูล หลายคนมักเข้าใจผิดว่าผู้ใช้ทุกคนจำเป็นต้องถูกเพิ่มเข้าไปในบทบาท (Roles) ของ Workspace เสมอ แต่แท้จริงแล้วไม่จำเป็นต้องทำเช่นนั้น
ข้อจำกัดของ Workspace Roles
บทบาทในระดับ Workspace มีอยู่จำกัดเพียง 4 บทบาทหลัก (เช่น Admin ที่ทำได้ทุกอย่าง, Contributor ที่สามารถสร้าง Object ต่างๆ ได้ และ Viewer ที่เข้ามาใช้งานหรือดูได้อย่างเดียว) บทบาทเหล่านี้เป็นสิทธิ์แบบคงที่ (Fixed Roles) ที่ไม่สามารถปรับแต่งให้ยืดหยุ่นได้ หากดึงผู้ใช้ทั่วไปเข้ามาใส่ในระดับนี้ อาจทำให้ผู้ใช้ได้รับสิทธิ์ที่มากเกินความจำเป็น (Over-privileged)
ทางเลือกที่ดีกว่าด้วย One Lake Catalog
ผู้ใช้ไม่จำเป็นต้องได้รับสิทธิ์ให้เห็นพื้นที่ Workspace ทั้งหมด แต่สามารถเข้าถึงข้อมูลเฉพาะไอเทมที่ได้รับอนุญาตได้โดยตรงผ่าน One Lake Catalog
3. การจัดการสิทธิ์ระดับไอเทมแบบละเอียด (Granular Access Control)
ภายใต้ Workspace จะมีไอเทมประเภทต่างๆ เช่น Lakehouse หรือ Warehouse ซึ่งแต่ละไอเทมมีวิธีการจัดสรรสิทธิ์ในระดับที่ละเอียดลงไป (Granular Access) แตกต่างกันเล็กน้อย
- ฝั่ง Warehouse: มีรูปแบบการจัดการสิทธิ์ที่คล้ายคลึงกับบน SQL Server โดยใช้ภาษา SQL ผ่านคำสั่งอย่าง GRANT, DENY และ REVOKE เพื่อควบคุมสิทธิ์การเข้าถึง
- ฝั่ง Lakehouse: เนื่องจากมีลักษณะการเก็บข้อมูลเป็นไฟล์และโฟลเดอร์ จึงใช้รูปแบบการให้สิทธิ์แบบไฟล์และโฟลเดอร์แทน
บทสรุป: ความปลอดภัยด้วยหลักการ Least Privilege
การออกแบบระบบความปลอดภัยในลักษณะนี้คือหลักปฏิบัติที่เรียกว่า Least Privilege หรือการพยายามกำหนดสิทธิ์ให้ผู้ใช้เข้าถึงเฉพาะข้อมูลที่จำเป็นและมีสิทธิ์น้อยที่สุดเท่าที่จะเป็นไปได้ การผสมผสานสิทธิ์ระดับไอเทมร่วมกับการกำหนดสิทธิ์แบบละเอียดในระดับฐานข้อมูล ช่วยลดความเสี่ยงจากการให้สิทธิ์เกินความจำเป็น และทำให้ Microsoft Fabric มีความปลอดภัยที่รัดกุมสูงสุด
