© 2026 Koder.ai สงวนลิขสิทธิ์
หน้าแรก › บล็อก › สิทธิ์ใน SaaS แบบมัลติเทนแนนท์: องค์กร ทีม บทบาท อธิบายให้ชัดเจน ทำไมสิทธิ์ใน SaaS ถึงสับสนเร็วขนาดนี้
ปัญหาเรื่องสิทธิ์มักเริ่มจากเรื่องเล็กๆ ที่สร้างความรำคาญ บิลถูกเปิดตั๋อว่า: "ฉันเป็นแอดมินแต่ดูใบแจ้งหนี้ไม่ได้" อีกตั๋วหนึ่ง: "ทำไมเพื่อนร่วมทีมของฉันแก้ไขการตั้งค่าได้?" ผู้คนคลิกไปมาเดาแล้วบางทีมก็แชร์ล็อกอิน "เจ้าของ" หนึ่งบัญชีเพราะมันเร็วกว่าแก้สิทธิ์ให้ถูกต้อง
จากนั้นวิธีแก้ชั่วคราวก็สะสม ทีมตั้งบทบาทแบบ "Admin 2" หรือ "Manager (no delete)" วิศวกรใส่เช็คเฉพาะที่ว่า "ถ้าผู้ใช้ใน Sales ให้อนุญาต export" เพราะแก้บั๊กวันนี้ได้ เดือนต่อมาไม่มีใครรู้ว่ากฎไหนจงใจตั้งไว้และอันไหนเป็นผลพลอยได้
สถานการณ์จะแย่ลงทันทีที่เพิ่มลูกค้ามากขึ้น กฎที่ดูพอใช้ได้กับบัญชีบริษัทหนึ่ง ("แอดมินเห็นข้อมูลทั้งหมด") จะพังเมื่อมีหลายร้อยองค์กรที่คาดหวังต่างกัน บางลูกค้าต้องการการแยกข้อมูลอย่างเข้มงวด บางคนต้องการที่ทำงานร่วมกัน บางคนต้องการให้ผู้รับเหมาเข้าถึงโปรเจกต์เดียวเท่านั้น หากโมเดลของคุณไม่ชัดเจน ลูกค้าใหม่ทุกคนจะกลายเป็นข้อยกเว้นใหม่
เป้าหมายชัดเจน: กฎการเข้าถึงที่คาดเดาได้และอธิบายได้ในหนึ่งนาที ตัวอย่าง: "องค์กรเป็นเจ้าของข้อมูล ทีมจัดกลุ่มคน บทบาทกำหนดสิ่งที่ทำได้ ทรัพยากรเป็นขององค์กร และบางครั้งเป็นของทีม การแชร์ปฏิบัติตามค่าเริ่มต้นไม่กี่ข้อ" ถ้าพูดไม่ได้อย่างชัดเจน จะยากต่อการสร้าง ทดสอบ และกลัวเมื่อต้องเปลี่ยน
สิทธิ์ใน SaaS แบบมัลติเทนแนนท์: องค์กร ทีม บทบาท อธิบายให้ชัดเจน | Koder.ai สัญญาที่คุ้มค่าคือ: บทบาทน้อยลง ความเป็นเจ้าของชัดเจน ค่าเริ่มต้นปลอดภัย เริ่มจากบทบาทเล็กๆ ที่ผูกกับงานจริง ทำให้การเป็นเจ้าของชัดเจนสำหรับทุกทรัพยากร และตั้งค่าเริ่มต้นให้เข้าถึงน้อยที่สุด แล้วอนุญาตการแชร์ด้วยความตั้งใจ ไม่ใช่โดยบังเอิญ
แผนที่ภาษาเรียบง่าย: องค์กร ทีม ผู้ใช้ และทรัพยากร ถ้าแอปของคุณให้บริการลูกค้ามากกว่าหนึ่งราย ให้ตั้งภาพรวมในหัวให้ถูกต้องก่อนเขียนกฎ ความสับสนในสิทธิ์ 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
Role View Edit Invite users Billing Scope note Owner Yes Yes Yes Yes Org-wide, can transfer ownership Admin Yes Yes Yes No/Yes Org-wide, no ownership changes Member Yes Limited No No Own + team (where assigned) Viewer Yes No No No Read-only in assigned scope
เช็คความสมเหตุผล: ให้เพื่อนร่วมงานที่ไม่ใช่สายเทคนิคดูหน้านี้แล้วถามว่า "สมาชิก 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 พร้อมสแนปชอตและการย้อนกลับเป็นวิธีปฏิบัติที่เป็นประโยชน์ในการทดลองสถานการณ์เหล่านี้และยืนยันว่ากฎทำงานเหมือนกันทั้งเว็บ แบ็กเอนด์ และมือถือ.
