สิทธิ์ใน SaaS แบบมัลติเทนแนนท์: องค์กร ทีม บทบาท อธิบายให้ชัดเจน

ทำไมสิทธิ์ใน SaaS ถึงสับสนเร็วขนาดนี้

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

จากนั้นวิธีแก้ชั่วคราวก็สะสม ทีมตั้งบทบาทแบบ "Admin 2" หรือ "Manager (no delete)" วิศวกรใส่เช็คเฉพาะที่ว่า "ถ้าผู้ใช้ใน Sales ให้อนุญาต export" เพราะแก้บั๊กวันนี้ได้ เดือนต่อมาไม่มีใครรู้ว่ากฎไหนจงใจตั้งไว้และอันไหนเป็นผลพลอยได้

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

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

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

แผนที่ภาษาเรียบง่าย: องค์กร ทีม ผู้ใช้ และทรัพยากร

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

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

คำศัพท์เรียบง่ายที่ยังชัดเมื่อเติบโต:

• องค์กร (tenant): บัญชีลูกค้าและขอบเขตข้อมูลที่ชัดเจน
• ผู้ใช้ (identity): บุคคลที่มีล็อกอินหนึ่งบัญชี
• การเป็นสมาชิก: การเชื่อมโยงที่บอกว่าผู้ใช้เป็นส่วนหนึ่งขององค์กร พร้อมบทบาทของพวกเขา
• ทีม (ถ้ามี): การจัดกลุ่มภายในองค์กรสำหรับการทำงานประจำวัน
• ทรัพยากร: สิ่งที่ต้องปกป้อง (โปรเจกต์ ใบแจ้งหนี้ ตั๋ว คีย์ API)

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

ทีมมีประโยชน์เมื่อสะท้อนการจัดกลุ่มจริงเช่น "Support" หรือ "Finance" แต่จะเป็นแหล่งเสียงรบกวนเมื่อทีมกลายเป็นระบบสิทธิ์ที่สอง แบบทดสอบที่มีประโยชน์คือ คุณสามารถอธิบายทีมด้วยประโยคเดียวโดยไม่เอ่ยถึงกฎฟีเจอร์เฉพาะหรือไม่

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

บทบาท สิทธิ์ และขอบเขตแบบไม่ใช้ศัพท์เทคนิค

สิทธิ์ใน SaaS แบบมัลติเทนแนนท์จะยังเข้าใจได้เมื่อคุณแยกสามสิ่งออกจากกัน:

• บทบาท: ป้ายบอกความรับผิดชอบ
• สิทธิ์: สิ่งที่ทำได้ (การกระทำ)
• ขอบเขต: ที่ที่ทำได้

RBAC พูดง่ายๆ

RBAC (role-based access control) หมายถึง: คุณให้บทบาทกับผู้ใช้ และบทบาทนั้นให้การกระทำที่อนุญาต ชื่อบทบาทควรบอกความรับผิดชอบ ไม่ใช่สถานะ "Billing Admin" ชัดเจนกว่า "Power User" ที่มักก่อปัญหา

มองสิทธิ์เป็นคำกริยาและทำให้สอดคล้องทั่วทั้งผลิตภัณฑ์:

• ดู (อ่าน)
• สร้าง
• แก้ไข
• ลบ
• จัดการ (เชิญ ตั้งค่า ส่งออก และการกระทำพิเศษอื่นๆ)

แล้วเพิ่มขอบเขตให้คำกริยาเดียวกันใช้ได้ในหลายที่ นี่คือวิธีหลีกเลี่ยงการสร้างบทบาทย่อย 20 แบบ

ขอบเขตทั่วไปที่อ่านง่าย:

• ระดับองค์กร
• เฉพาะทีม
• ของตัวเอง
• ที่มอบหมาย

เมื่อการเป็นเจ้าของดีกว่าการสร้างบทบาทใหม่

ถ้าคุณพบว่าตัวเองกำลังสร้างบทบาทแบบ "Project Editor" และ "Project Editor (Own)" ปัญหามักเป็นเรื่องขอบเขต ไม่ใช่บทบาท

ตัวอย่าง: ใน CRM ให้ "Sales Rep" สร้างและแก้ดีลได้ แต่จำกัดขอบเขตไว้ที่ "ของตัวเอง" ให้ "Sales Manager" มีคำกริยาคล้ายกันแต่ขอบเขตเป็น "เฉพาะทีม" หรือ "ระดับองค์กร" คุณจะได้บทบาทน้อยลง กฎชัดขึ้น และไม่ประหลาดใจเมื่อคนย้ายทีม

ค่าเริ่มต้นที่แน่นอนคือ: บทบาทให้คำกริยา และการเป็นเจ้าของ (หรือการมอบหมาย) จำกัดที่ที่คำกริยานั้นทำงานได้

ชุดกฎง่ายๆ ที่ขยายได้เป็นร้อยองค์กร

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

ชุดกฎที่ขยายได้:

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

ตัวอย่าง: แซมเป็นสมาชิก Org A และ Org B ใน Org A แซมเป็น Member และสร้าง/แก้รายงานของตัวเองได้แต่แก้บิลไม่ได้ ใน Org B แซมเป็น Billing Manager และอัปเดตวิธีการชำระเงินและดาวน์โหลดใบแจ้งหนี้ได้ แต่ก็ยังดูโปรเจกต์ส่วนตัวไม่ได้เว้นแต่การเป็นสมาชิกรวมพื้นที่นั้นด้วย

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

ทีละขั้น: ออกแบบโมเดลสิทธิ์ของคุณบนหน้าเดียว

เขียนหน้าเดียวที่เพื่อนร่วมงานอ่านในสองนาที ถ้าคุณอธิบายสิทธิ์โดยไม่เปิดโค้ดได้ คุณอยู่ในจุดที่ดี

1) เขียนอินพุตก่อนกฎ

เก็บส่วนประกอบให้เล็กตั้งใจไว้:

• เลือกสี่ประเภทผู้ใช้ที่อธิบายได้: owner, admin, member, viewer
• ระบุ 3-6 ทรัพยากรที่คนใช้ประจำ (โปรเจกต์ ลูกค้า รายงาน การเงิน)
• สำหรับแต่ละทรัพยากร ให้รายการ 2-4 การกระทำ (ดู สร้าง แก้ไข ลบ เชิญ ส่งออก)
• ตัดสินใจว่าสมาชิกใหม่ได้อะไรเป็นค่าเริ่มต้น (มักเป็น viewer หรือ member ไม่ใช่ admin)
• ตัดสินใจว่า "ทีม" เปลี่ยนอะไร เก็บไว้ที่การมองเห็น การมอบหมาย และการรายงาน ไม่ใช่อำนาจพิเศษที่น่าประหลาดใจ

2) ใส่กฎในตารางง่ายๆ

ใช้ขอบเขตเพื่อหลีกเลี่ยงการระเบิดของบทบาท ผลิตภัณฑ์หลายตัวต้องการเพียงสามขอบเขต: own, team, org

เช็คความสมเหตุผล: ให้เพื่อนร่วมงานที่ไม่ใช่สายเทคนิคดูหน้านี้แล้วถามว่า "สมาชิก Support แก้รายงานของ Sales ได้ไหม?" ถ้าพวกเขานึกนาน แปลว่าขอบเขตหรือคำนิยามทีมยังไม่ชัด

ความเป็นเจ้าของทรัพยากรและกฎการแชร์ที่มีเหตุผล

เพื่อให้สิทธิ์เข้าใจได้ ตัดสินใจก่อนว่าใครเป็นเจ้าของแต่ละทรัพยากร แล้วจำกัดตัวเลือกการแชร์

โมเดลความเป็นเจ้าของเริ่มต้น

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

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

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

ชุดกฎการแชร์สั้นๆ ที่อ่านได้:

• องค์กรเป็นเจ้าของโดยเริ่มต้น: เก็บไอเท็มภายใต้ org_id เดียว
• ติดป้ายทีมเพื่อการทำงาน: ติดป้ายให้ทีมเพื่อการกำหนดเส้นทาง แต่ไม่ใช่การควบคุมการเข้าถึงแบบแข็ง
• ของผู้ใช้สำหรับไอเท็มส่วนตัว: ส่วนตัวเว้นแต่จะแชร์ชัดเจน
• ระดับการแชร์เพียงสามแบบ: ส่วนตัว (เจ้าของ), ทีม, องค์กร — หลีกเลี่ยง ACL ต่อชิ้นในระยะแรก
• แยกระหว่าง "มอบหมายให้" กับ "สามารถเข้าถึง": การมอบหมายคือความรับผิดชอบ ไม่ใช่สิทธิ์

การแชร์แบบเรียบง่าย

เมื่อใครสักคนบอกว่า "ฉันต้องการการเข้าถึง" ให้ถามทันทีว่าเป็นระดับไหน: ไอเท็มส่วนตัวของเขา งานของทีม หรือทั้งองค์กร ถ้าไม่เข้าเกณฑ์ทั้งสาม มักเป็นสัญญาณว่าขอบเขตยังไม่ชัด ไม่ใช่ว่าต้องการโหมดแชร์ใหม่

ตัวอย่าง: ตั๋ว support อาจเป็นขององค์กร (เพื่อให้ผู้จัดการรายงานได้ทั้งหมด) ถูกติดป้ายทีม Support (เพื่อให้แสดงในคิวที่ถูกต้อง) และมอบหมายให้ Jordan (เพื่อความรับผิดชอบ) การมอบหมายไม่ควรปิดกั้นบทบาทที่ได้รับอนุญาตอื่นจากการดูตั๋วนั้น

คำเชิญ การเปลี่ยนการเป็นสมาชิก และการสลับองค์กร

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

คำเชิญ

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

เก็บกฎให้เข้ม:

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

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

การออกและเข้าร่วม โดยไม่สูญเสียความเป็นเจ้าของ

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

ถ้าคุณมีทรัพยากรที่เป็นของผู้ใช้ ให้บังคับการโอนก่อนลบสำหรับสิ่งที่สำคัญ (โปรเจกต์ เอกสาร คีย์ API)

การสลับองค์กรอย่างปลอดภัย

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

การปิดใช้งานมักดีกว่าการลบ มันเอาการเข้าถึงออกทันทีพร้อมเก็บการกระทำในอดีตเพื่อการตรวจสอบ

ข้อผิดพลาดทั่วไปและกับดักที่หลีกเลี่ยงได้

โมเดลสิทธิ์ส่วนมากล้มเหลวเพราะเติบโตเร็วกว่าเหตุผล รักษาพื้นฐาน (ขอบเขต tenant ความเป็นเจ้าของ ขอบเขต) ไว้ แล้วมองทุกอย่างที่เหลือเป็นรายละเอียด

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

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

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

สัญญาณเตือนล่วงหน้า:

• "super admin" ที่มองเห็นข้อมูลข้ามองค์กรทั้งหมดโดยดีฟอลต์
• การป้องกันแค่บน UI (ซ่อนปุ่ม) แทนเช็คฝั่งเซิร์ฟเวอร์
• คีย์ API และบัญชีบริการที่ข้ามกฎการเป็นสมาชิก
• บทบาทนิยามตามชื่อตำแหน่งงาน ไม่ใช่การกระทำ
• ข้อยกเว้นที่อธิบายไม่ได้ด้วยประโยคเดียว

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

การตรวจสอบด่วนก่อนส่งขึ้นใช้งาน

ทุกคำขอควรแก้บริบทองค์กรปัจจุบันก่อน (จากซับโดเมน เฮดเดอร์ เซสชัน หรือเส้นทาง) และปฏิเสธสิ่งที่ไม่ตรงกัน

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

รันชุดเทสแบบ end-to-end เล็กๆ ด้วยบัญชีจริง ไม่ใช่แค่ unit tests:

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

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

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

ตัวอย่าง: จากองค์กรเดียวไปเป็นหลายร้อยโดยไม่ต้องออกแบบใหม่

เริ่มจากการตั้งค่าจริงเล็กๆ: บริษัทลูกค้าหนึ่งองค์กร มีสองทีม Sales และ Ops ทุกคนล็อกอินครั้งเดียว แล้วเลือกองค์กรที่เป็นสมาชิก Sales ต้องการบันทึกลูกค้าและใบเสนอราคา Ops ต้องการการเงินและการตั้งค่าภายใน

ขั้นที่ 1: หนึ่งองค์กร สองทีม

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

ขั้นที่ 2: บทบาทคงที่ ขอบเขตคาดเดาได้

เลือกบทบาทเล็กๆ แล้วคงไว้เมื่อฟีเจอร์ออก: Admin, Member, Viewer บทบาทตอบคำถามว่า "คุณทำอะไรได้ในองค์กรนี้?" ขอบเขตตอบว่า "คุณทำที่ไหนได้?"

ขั้นที่ 3: ความเป็นเจ้าของทำให้การแก้ง่าย

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

ตัวอย่าง: สมาชิก Sales สร้างใบเสนอราคา สมาชิก Sales คนอื่นดูได้ แต่แก้ไม่ได้เว้นแต่แชร์กับทีมหรือมอบหมายใหม่ Ops Viewer ดูได้ก็ต่อเมื่อกฎอนุญาตให้ Ops ดูทรัพยากรของ Sales

ขั้นที่ 4: 200 องค์กร กฎเดิม

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

ขั้นตอนต่อไป: ลงมือ ทดสอบ และปรับอย่างปลอดภัย

ถือหน้าโมเดลหน้าเดียวเป็นสัญญา ปฏิบัติตามกฎที่คุณสามารถบังคับใช้ในทุกการเรียก API และทุกหน้าจอ UI มิฉะนั้นสิทธิ์จะลอยเป็น "แล้วแต"

เริ่มเล็ก: บทบาทไม่กี่แบบ ขอบเขตชัดเจน และความเป็นเจ้าของเรียบง่าย เมื่อมีคำขอใหม่ ("เพิ่มบทบาท Editor-Manager ได้ไหม?") ให้ปรับความเป็นเจ้าของหรือขอบเขตก่อน บทบาทใหม่ควรเกิดขึ้นไม่บ่อย

สำหรับทรัพยากรใหม่ทุกชิ้น ให้ทำพื้นฐานให้สอดคล้อง:

• เก็บ org_id (และ team_id หากทีมเกี่ยวข้อง)
• มีกฎการมองเห็น (ส่วนตัว ทีม องค์กร)
• บันทึกเหตุการณ์ตรวจสอบสำหรับการกระทำสำคัญ (เชิญ เปลี่ยนบทบาท ส่งออก)
• กรองตามขอบเขตในทุกการค้นหา (ไม่ใช่แค่ใน UI)
• มีค่าเริ่มต้นคาดเดาได้ (ใครเห็นได้ทันทีหลังสร้าง)

ทดสอบโฟลว์จริงก่อนขัดเกลากรณีขอบ: คำเชิญ การสลับองค์กร หน้าแอดมิน และสิ่งที่เกิดขึ้นเมื่อใครบางคนถูกตัดการเข้าถึงกลางเซสชัน

ถ้าคุณสร้างด้วยตัวช่วยสร้างแอปที่มีแชท มันช่วยให้เขียนโมเดลสิทธิ์เป็นภาษาธรรมดาก่อนแล้วเก็บไว้กับสเป็กผลิตภัณฑ์ ใน Koder.ai (koder.ai), Planning Mode พร้อมสแนปชอตและการย้อนกลับเป็นวิธีปฏิบัติที่เป็นประโยชน์ในการทดลองสถานการณ์เหล่านี้และยืนยันว่ากฎทำงานเหมือนกันทั้งเว็บ แบ็กเอนด์ และมือถือ.