RBAC

RBAC ย่อจาก Role Based Access Control คือวิธีจัดสิทธิ์การเข้าถึงที่ผูกสิทธิ์ไว้กับบทบาทในองค์กร ไม่ใช่ผูกไว้กับตัวบุคคลทีละคน หน้าโครงการของ NIST อธิบายกลไกไว้ตรงไปตรงมาว่า ผู้ใช้แต่ละคนจะถูกกำหนดบทบาทหนึ่งบทบาทหรือมากกว่านั้น และแต่ละบทบาทจะถูกกำหนดสิทธิ์หนึ่งอย่างหรือมากกว่านั้นที่ผู้ใช้ในบทบาทนั้นได้รับอนุญาต ผลในทางปฏิบัติคือคนเข้าใหม่ในตำแหน่งเดิมได้สิทธิ์ชุดเดิมทันทีโดยไม่ต้องไล่ติ๊กทีละช่อง และคนย้ายแผนกก็เปลี่ยนบทบาทครั้งเดียวจบ หน้าเดียวกันระบุว่าแนวคิดนี้ถูกทำให้เป็นทางการในปี 1992 โดย David Ferraiolo และ Rick Kuhn ส่วนตัวที่ถูกรับเป็นมาตรฐานแห่งชาติของสหรัฐ ANSI/INCITS 359-2004 เมื่อ 11 กุมภาพันธ์ 2004 คือโมเดล RBAC ของ NIST ซึ่งต่อมาปรับปรุงเป็น INCITS 359-2012 ในปี 2012 สิ่งที่ต้องบอกไว้ด้วยคือหน้าโครงการนี้ของ NIST ติดป้ายกำกับว่าเป็นโครงการที่เก็บเข้าคลังแล้ว ไม่มีการอัปเดตเนื้อหาต่อ

หน้าตาจริงของ RBAC บนแพลตฟอร์ม AI ระดับองค์กรมักเริ่มจากรายชื่อบทบาทสำเร็จรูปที่ผู้ให้บริการเตรียมไว้ให้ แล้วต่อยอดด้วยบทบาทที่องค์กรตั้งเองในแผนระดับสูง เอกสารช่วยเหลือของ Claude ระบุบทบาทมาตรฐานสี่ตัวสำหรับแผน Team และ Enterprise คือ User, Admin, Owner และ Primary Owner โดยเขียนกำกับว่าองค์กรแบบ Team และ Enterprise มี Primary Owner ได้เพียงคนเดียว และที่นั่งของ Primary Owner กินหนึ่ง license ของแผนที่ซื้อไว้ ส่วนบทบาทที่ตั้งเองหรือ custom role นั้นมีเฉพาะแผน Enterprise เอกสารเขียนว่าสมาชิกที่ตั้งบทบาทเป็น Custom จะไม่มีสิทธิ์ตั้งต้นใดๆ เลย สิทธิ์ทั้งหมดขึ้นกับ custom role ที่ผูกกับกลุ่มของคนคนนั้น ส่วนคู่มือการตั้ง role based permission บนแผน Enterprise ระบุว่าแต่ละพื้นที่ของผู้ดูแลระบบตั้งได้สามระดับคือไม่เห็นพื้นที่นั้นในหน้าตั้งค่าเลย เห็นแบบอ่านอย่างเดียว หรือจัดการได้เต็มที่ ขณะที่ส่วน connector ใช้ตัวเลือกคนละชุดซึ่งมีสี่แบบ ฝั่ง Microsoft ก็มีบทบาทสำเร็จรูปสำหรับงาน AI โดยเฉพาะชื่อ AI Administrator ซึ่งตารางบทบาทของ Microsoft Entra ID อธิบายว่าใช้จัดการทุกด้านของ Microsoft 365 Copilot และบริการองค์กรที่เกี่ยวกับ AI ใน Microsoft 365 หน้าเดียวกันจัดบทบาทนี้เป็นบทบาทที่มีสิทธิ์สูง และไล่รายการงานที่ทำได้ไว้เป็นข้อๆ รวมถึงการดูแลวงจรชีวิตทั้งหมดของ agent identity ไปจนถึงการกู้คืนรายการที่ถูกลบไปแล้ว

คนทำงานทั่วไปมักเจอเรื่องนี้ตอนองค์กรเปิดใช้ผู้ช่วย AI ทั้งบริษัท แล้วมีคนถามว่าถามผู้ช่วยไปแล้วมันจะเห็นไฟล์ของแผนกอื่นไหม เอกสาร Data, Privacy, and Security for Microsoft 365 Copilot ตอบข้อนี้ว่า Microsoft 365 Copilot จะแสดงเฉพาะข้อมูลขององค์กรที่ผู้ใช้แต่ละคนมีสิทธิ์ดูเป็นอย่างน้อยอยู่แล้ว และเขียนต่อในประโยคถัดมาว่าจึงสำคัญที่องค์กรต้องใช้โมเดลสิทธิ์ที่มีอยู่แล้วในบริการของ Microsoft 365 เช่น SharePoint เพื่อให้คนหรือกลุ่มที่ถูกต้องเข้าถึงเนื้อหาที่ถูกต้อง รวมถึงสิทธิ์ที่ให้คนนอกองค์กรผ่านการทำงานข้ามองค์กร เช่น shared channel ใน Microsoft Teams เอกสารหน้าเดียวกันยังเขียนต่อในหัวข้อการปกป้องข้อมูลองค์กรว่ากลไกที่ใช้ตัดสินว่าใครเห็นอะไรได้นั้นเป็นชุดเดียวกับที่บริการอื่นของ Microsoft 365 ใช้อยู่ และระบุว่า Semantic Index เคารพขอบเขตสิทธิ์ที่อิงตัวตนของผู้ใช้ ทำให้ขั้นตอนดึงข้อมูลมาตอบแตะได้เฉพาะเนื้อหาที่ผู้ใช้คนนั้นมีสิทธิ์ ส่วนผลที่ตามมาในทางปฏิบัติคือ Microsoft 365 Copilot ไม่ได้เพิ่มสิทธิ์ใหม่ให้ใคร แต่มันเดินเข้าประตูที่เปิดค้างไว้อยู่แล้วได้เร็วกว่าคนมาก โฟลเดอร์ที่เคยแชร์ทั้งบริษัทไว้เมื่อสามปีก่อนแล้วลืม จะถูกงัดขึ้นมาตอบคำถามภายในไม่กี่วินาที นี่คือที่มาของปัญหา oversharing และเป็นเหตุผลที่การจัดบทบาทควรถูกนับเป็นงาน data-governance ที่ทำก่อนเปิดใช้ ไม่ใช่งานที่ตามเก็บทีหลัง เอกสารของ Microsoft ยังระบุว่าผู้ดูแลใช้ Content search หรือ microsoft-purview เข้าไปดูและจัดการข้อมูลบทสนทนาที่ระบบเก็บไว้ได้ อีกเรื่องที่ต้องอ่านให้ครบคือเงื่อนไขแพ็กเกจ คู่มือการตั้ง role based permission ของ Claude ระบุว่าฟีเจอร์นี้อยู่บนแผน Enterprise และเตือนว่าต่างจากสมาชิกที่ถือบทบาท User ตรงที่สมาชิกซึ่งถูกกำหนด custom role จะไม่ได้รับความสามารถที่องค์กรเปิดไว้โดยอัตโนมัติ ทุกความสามารถต้องให้ผ่านบทบาทอย่างชัดเจน คู่มือฉบับเดียวกันยังเขียนถึงสองกรณีที่คนตั้งค่ามักพลาด คือถ้าองค์กรอยู่บนแผน Enterprise รุ่นเดิมที่มีที่นั่งสองแบบ ทั้งแบบ Chat และแบบ Chat + Claude Code ซึ่งคู่มือกำกับไว้ว่าเป็นที่นั่งของแผนรุ่นเก่า custom role จะไม่ลบล้างข้อจำกัดระดับที่นั่ง สมาชิกที่ถือที่นั่งแบบ Chat-only จึงเข้าใช้ Claude Code ไม่ได้แม้ custom role จะให้สิทธิ์นั้นไว้ และคู่มือเขียนกรณีกลับด้านไว้ด้วยว่าถ้า custom role ไม่ได้ให้ความสามารถด้าน chat สมาชิกคนนั้นก็ไม่มีสิทธิ์ใช้ chat ไม่ว่าจะถือที่นั่งแบบใด ส่วนอีกกรณีคือสิทธิ์เรื่อง connector ซึ่งครอบคลุมเฉพาะ connector ที่ Owner หรือ Primary Owner เพิ่มเข้าไปในการตั้งค่าองค์กรและเชื่อมต่อด้วยข้อมูลรับรองระดับผู้ดูแลระบบไว้แล้วเท่านั้น เงื่อนไขทำนองนี้ต่างกันไปตามผู้ให้บริการ ก่อนตัดสินใจจึงควรไล่อ่านของเจ้าที่องค์กรใช้จริง เทียบกับหน้า chatgpt-enterprise ในคลังนี้ประกอบได้

ตัวอย่างจากบทสนทนาจริง

หัวหน้าฝ่ายบุคคล: ฝ่าย IT ส่งแบบฟอร์มมาให้ระบุว่าใครเป็น Owner ใครเป็น Admin ก่อนเปิดใช้ผู้ช่วย AI ทั้งบริษัท ทำไมต้องแยกละเอียดขนาดนั้นคะ ให้ทุกคนใช้เหมือนกันไปเลยไม่ได้เหรอ

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

ระวังสับสนกับ

• least-privilege : least privilege คือหลักการว่าให้สิทธิ์เท่าที่จำเป็นต่อการทำงานเท่านั้น ส่วน RBAC คือกลไกที่ใช้จัดโครงสร้างเพื่อทำตามหลักการนั้น องค์กรที่ใช้ RBAC แล้วยังผิดหลักนี้ได้ ถ้ายัดสิทธิ์เข้าไปในบทบาทเดียวจนบทบาทนั้นใหญ่เกินงานที่คนกลุ่มนั้นทำจริง
• sensitivity-label : RBAC ผูกสิทธิ์ไว้กับคนหรือบทบาท ส่วน sensitivity label ผูกการคุ้มครองไว้กับตัวเอกสาร ฉลากจึงติดไปกับไฟล์แม้ไฟล์จะถูกส่งต่อออกไปนอกที่เดิม
• dlp : RBAC ตัดสินตั้งแต่ต้นทางว่าใครเปิดอะไรได้ ส่วน DLP คอยดูปลายทางว่าข้อมูลที่เปิดได้แล้วกำลังจะไหลออกไปทางไหน สองชั้นนี้ทำงานคนละจังหวะกันและใช้แทนกันไม่ได้
• audit-log : RBAC เป็นการตัดสินใจล่วงหน้าว่าใครทำอะไรได้ ส่วน audit log เป็นบันทึกย้อนหลังว่าเกิดอะไรขึ้นจริง ตั้งบทบาทดีแค่ไหนก็ยังต้องมีบันทึกไว้ตรวจสอบ