การออกแบบเมทริกซ์สิทธิ์สำหรับเครื่องมือภายใน: บทบาทและขอบเขต

ปัญหาที่การออกแบบเมทริกซ์สิทธิ์จะแก้

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

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

สิทธิ์จะยุ่งเหยิงอย่างรวดเร็วเพราะเครื่องมือภายในเติบโตเป็นชั้น ๆ บทบาทใหม่ปรากฏ บทบาทเก่าแยกตัวออก และข้อยกเว้นแบบครั้งเดียวสะสม: “อนุญาตให้ Maria คืนเงินได้”, “บล็อกผู้รับจ้างจากการเขียนบันทึก”, “ให้หัวหน้าทีมอนุมัติได้สูงสุด $500 เท่านั้น” เมื่อกฎอยู่แค่ในหัวคน (หรือกระจัดกระจายในตั๋ว) หน้าจอและ endpoints ของ API จะเบี่ยงออกจากกัน และช่องโหว่ด้านความปลอดภัยจะเกิดขึ้น

การออกแบบเมทริกซ์สิทธิ์แก้ปัญหานี้โดยการสร้างแผนที่ร่วมเดียวที่บอกว่าใครทำอะไรกับข้อมูลใด และภายใต้ข้อจำกัดแบบไหน มันกลายเป็นแหล่งข้อมูลจริงสำหรับการตัดสินใจทั้งใน UI (หน้าจอ ปุ่ม ฟิลด์ที่ปรากฏ) และฝั่งแบ็กเอนด์ (สิ่งที่เซิร์ฟเวอร์อนุญาตจริง แม้มีคนพยายามข้าม UI)

มันไม่ได้มีไว้แค่สำหรับนักพัฒนา เมทริกซ์ที่ดีเป็นเอกสารการทำงานที่ฝ่ายผลิตภัณฑ์ ปฏิบัติการ และผู้สร้างตกลงร่วมกันได้ หากคุณสร้างด้วยแพลตฟอร์มแบบ no-code อย่าง AppMaster เมทริกซ์ยังคงจำเป็น: มันชี้แนะแนวทางการตั้งค่าบทบาท การนิยามทรัพยากร และการรักษาความสอดคล้องระหว่างหน้าจอที่มองเห็นได้กับ endpoints ที่ถูกสร้าง

เมทริกซ์ง่าย ๆ จะช่วยให้คุณ:

• ทำให้กฎชัดเจนก่อนสร้าง
• ลดความยุ่งเหยิงจากกรณีพิเศษ
• รักษาความสอดคล้องระหว่างสิทธิ์ UI และ API
• ตรวจสอบการเปลี่ยนแปลงการเข้าถึงโดยไม่ต้องเดา

คำศัพท์สำคัญ: บทบาท ทรัพยากร การกระทำ ขอบเขต ข้อยกเว้น

การออกแบบเมทริกซ์สิทธิ์ที่ดีเริ่มจากคำศัพท์ร่วมกัน ถ้าทีมใช้คำเหล่านี้เหมือนกัน คุณจะหลีกเลี่ยงกฎที่ยุ่งยากในภายหลัง

บทบาท (role) คือกลุ่มคนตามงานที่มักต้องการการเข้าถึงแบบเดียวกัน คิดถึง Support, Finance, Ops หรือ Manager บทบาทควรอธิบายสิ่งที่คนทำในแต่ละวัน ไม่ใช่ระดับตำแหน่ง คนหนึ่งคนอาจมีมากกว่าหนึ่งบทบาทแต่ควรใช้ให้น้อย

ทรัพยากร (resource) คือสิ่งที่คุณปกป้อง ในเครื่องมือภายใน ทรัพยากรทั่วไปคือลูกค้า ตั๋ว ใบแจ้งหนี้ รายงาน การเชื่อมต่อ และการตั้งค่า ตั้งชื่อทรัพยากรเป็นคำนาม เพื่อช่วยตอนที่คุณแปลงกฎเป็นหน้าจอและ endpoints ของ API

การกระทำ (action) คือสิ่งที่คนทำกับทรัพยากร รักษาคำกริยาให้สอดคล้องเพื่อให้เมทริกซ์อ่านง่าย การกระทำทั่วไปรวมถึง:

• view
• create
• edit
• delete
• approve
• export

ขอบเขต (scope) ตอบคำถามว่า “รายการไหนบ้าง?” โดยไม่ต้องสร้างบทบาทเพิ่ม ขอบเขตมักเป็นความต่างระหว่างการเข้าถึงที่ปลอดภัยกับไม่ปลอดภัย ขอบเขตทั่วไปคือ:

• own (รายการที่คุณสร้างหรือถูกมอบหมาย)
• team (กลุ่มของคุณ)
• region (พื้นที่ของคุณ)
• all (ทั้งหมด)

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

ตัวอย่าง: เจ้าหน้าที่ฝ่ายบริการอาจ “view tickets” ด้วยขอบเขต “team” แต่ได้ข้อยกเว้นชั่วคราวให้ “export tickets” เพื่อทบทวนเหตุการณ์ ในเครื่องมือที่สร้างด้วย AppMaster กฎแบบนี้จะจัดการได้ง่ายขึ้นถ้าคุณตั้งชื่อบทบาท ทรัพยากร การกระทำ และขอบเขตให้สอดคล้องตั้งแต่ต้น

การตัดสินใจก่อนวาดเมทริกซ์

เริ่มด้วยการตกลงว่าคุณกำลังปกป้องอะไรจริง ๆ ให้ระบุพื้นที่ของเครื่องมือภายในเป็นทรัพยากร ไม่ใช่หน้าจอ หน้าจออาจแสดง “Orders”, “Refunds” และ “Customers” ในที่เดียว แต่เป็นทรัพยากรต่างกันและมีความเสี่ยงต่างกัน

ก่อนเขียนสิทธิ์ตัวเดียว ให้ทำให้คำกริยามาตรฐาน ความแตกต่างของคำเพียงเล็กน้อยจะสร้างกฎซ้ำซ้อน (edit vs update, remove vs delete, view vs read) เลือกชุดคำสั้น ๆ และใช้กับทุกทรัพยากร สำหรับเครื่องมือภายในส่วนใหญ่ ชุดง่าย ๆ เช่น view, create, update, delete, approve, export ก็เพียงพอ

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

• own (รายการที่คุณสร้าง)
• team (รายการของทีมคุณ)
• location (สาขาหรือภูมิภาค)
• all (ทั้งหมด)
• none (ไม่มีการเข้าถึง)

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

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

ถ้าคุณสร้างใน AppMaster การตัดสินใจเหล่านี้จะแมปกับ endpoints ฝั่งแบ็กเอนด์และตรรกะ Business Process ในภายหลัง แต่เมทริกซ์ต้องชัดเจนก่อน

ขั้นตอนทีละข้อ: สร้างเมทริกซ์สิทธิ์ตั้งแต่ต้น

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

วิธีง่าย ๆ ในการออกแบบเมทริกซ์คือถือมันเป็นแผนที่จากงานไปสู่การเข้าถึง แล้วแปลงเป็นแอปของคุณทีหลัง

ลำดับการสร้างที่ปฏิบัติได้

1. เขียนรายการงานของธุรกิจด้วยภาษาธรรมดา ตัวอย่าง: “ออกใบคืนเงิน”, “เปลี่ยนอีเมลลูกค้า”, “ส่งออกใบแจ้งหนี้เดือนที่ผ่านมา” รักษาให้สั้นและจริง

2. แปลงงานเป็นทรัพยากรและการกระทำ ทรัพยากรเป็นคำนาม (Invoice, Ticket, Customer), การกระทำเป็นคำกริยา (view, create, edit, approve, export) มอบเจ้าของให้แต่ละทรัพยากร: คนหนึ่งที่อธิบายกรณีขอบเขตและบอกว่า “ใช่ นั่นถูกต้อง”

3. กำหนดบทบาทตามทีมที่มั่นคง ใช้กลุ่มเช่น Support, Finance, Operations, Team Lead หลีกเลี่ยงตำแหน่งที่เปลี่ยนบ่อย (Senior, Junior) เว้นแต่จริง ๆ แล้วเปลี่ยนการเข้าถึง

4. เติมเมทริกซ์ด้วยการเข้าถึงขั้นต่ำที่แต่ละบทบาทต้องการเพื่อทำงานให้เสร็จ ถ้า Support ต้องดูใบแจ้งหนี้เพื่อช่วยลูกค้า อย่าให้สิทธิ์ “export” โดยดีฟอลต์ คุณเพิ่มการเข้าถึงได้ แต่การถอดสิทธิ์ภายหลังทำให้เกิดนิสัยที่ผิดพลาด

5. เพิ่มขอบเขตเฉพาะที่จำเป็น แทนที่จะมีสิทธิ์ “edit” เดียว ให้ระบุขอบเขตเช่น “edit own”, “edit assigned”, หรือ “edit all” เพื่อให้กฎชัดเจนโดยไม่สร้างบทบาท 50 ตัว

เก็บข้อยกเว้นในตารางแยก ไม่เทเป็นบันทึกย้อมภายในเมทริกซ์ ข้อยกเว้นแต่ละรายการต้องมีช่องเหตุผลชัดเจน (ความสอดคล้อง, ความเสี่ยงการฉ้อโกง, การแยกหน้าที่) และเจ้าของคนเดียวที่อนุมัติ

เมื่องานนี้เสร็จ เครื่องมืออย่าง AppMaster จะทำให้ง่ายขึ้นในการแปลงเมทริกซ์เป็น endpoints ที่ป้องกันและหน้าจอแอดมินโดยไม่ต้องเดาระหว่างการสร้าง

วิธีจัดโครงสร้างเมทริกซ์ให้คงใช้ได้

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

เริ่มด้วยการแยกเมทริกซ์ตามโดเมน แทนที่จะใช้ชีตเดียวสำหรับทุกอย่าง ให้ใช้แท็บแยกตามพื้นที่ธุรกิจ เช่น Customers, Billing, Content บทบาทส่วนใหญ่จะเกี่ยวข้องกับโดเมนน้อย ๆ ดังนั้นวิธีนี้ช่วยให้การตรวจทานเร็วและลดความเปลี่ยนแปลงโดยไม่ได้ตั้งใจ

ใช้รูปแบบการตั้งชื่อที่สอดคล้องข้ามแท็บ รูปแบบง่าย ๆ เช่น Resource.Action.Scope ทำให้เห็นชัดว่าสิทธิ์แต่ละตัวหมายถึงอะไร และป้องกันการซ้ำที่ดูต่างกันแต่ความหมายเดียวกัน เช่น Invoice.Approve.Department อ่านเหมือนกับ Customer.Edit.Own

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

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

เพื่อให้เมทริกซ์คงทนตามเวลา ให้เวอร์ชันมันเหมือนเอกสารจริง:

• v1, v2, ฯลฯ พร้อมวันที่
• เจ้าของ (คนรับผิดชอบหนึ่งคน)
• สรุปการเปลี่ยนแปลงสั้น ๆ

เมื่อเมทริกซ์เสถียร การสร้างหน้าจอและ endpoints ใน AppMaster จะง่ายขึ้น เพราะปุ่มและการกระทำของ API ทุกอย่างจะจับคู่กับชื่อสิทธิ์ที่ชัดเจน

แปลงเมทริกซ์เป็นหน้าจอและ endpoints

เมทริกซ์สิทธิ์มีประโยชน์เมื่อมันกลายเป็นกฎจริงในสองที่: API และ UI เริ่มจากการถือว่าทรัพยากรแต่ละตัวในเมทริกซ์ (เช่น Tickets, Invoices, Users) เป็นกลุ่ม endpoint เก็บการกระทำให้สอดคล้องกับกริยาในเมทริกซ์: view, create, edit, approve, export, delete

ฝั่ง API ให้บังคับสิทธิ์ในทุกคำขอ การตรวจสอบใน UI ช่วยให้ชัดเจนแต่ไม่ใช่ความปลอดภัย ปุ่มที่ซ่อนอยู่ไม่หยุดคำขอ API โดยตรง

วิธีง่าย ๆ ในการแปลงเมทริกซ์เป็นสิทธิ์ API คือการตั้งชื่อตามมาตรฐานและผูกที่จุด boundary ที่การกระทำเกิดขึ้น:

• tickets:view, tickets:edit, tickets:export
• invoices:view, invoices:approve, invoices:delete
• users:view, users:invite

แล้วใช้ชื่อสิทธิ์เดียวกันในการควบคุมการมองเห็น UI: เมนู หน้าถึง ปุ่ม และแม้แต่ฟิลด์ ตัวอย่าง: เจ้าหน้าที่ฝ่ายบริการอาจเห็นรายชื่อ Ticket และเปิดดู แต่ฟิลด์ “Refund” จะเป็นแบบอ่านอย่างเดียวจนกว่าจะมีสิทธิ์ invoices:approve

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

สุดท้าย แมปการบันทึก audit เข้ากับการกระทำที่สำคัญ การส่งออก การลบ การอนุมัติ การเปลี่ยนบทบาท และการดาวน์โหลดข้อมูลควรสร้างเหตุการณ์ audit พร้อมใคร ทำอะไร เมื่อไร และเป้าหมาย หากสร้างใน AppMaster คุณสามารถสะท้อนสิ่งนี้ในตรรกะ endpoint และ Business Process เพื่อให้กฎเดียวกันทั้งเรียกการกระทำและสร้างรายการบันทึก

ความผิดพลาดและกับดักที่พบบ่อย

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

กับดักอีกอย่างคือการเพิ่มบทบาทจนล้น ทีมมักเพิ่มบทบาท (Support Level 1, Support Level 2, Support Manager ฯลฯ) ในขณะที่ชุดบทบาทเล็ก ๆ พร้อมขอบเขตชัดเจนก็เพียงพอ ขอบเขตเช่น “own team”, “assigned region”, หรือ “accounts you manage” มักอธิบายความแตกต่างได้ดีกว่าบทบาทใหม่

ข้อผิดพลาดที่พบบ่อยในเครื่องมือภายในจริง ๆ ได้แก่:

• นิยามแค่ “view” และ “edit” แต่ลืมการกระทำเช่น export, bulk edit, refund, impersonate, หรือ “change owner”.
• ใช้ข้อยกเว้นเป็นแพตช์ระยะยาว การให้สิทธิ์ครั้งเดียวแบบชั่วคราวมักกลายเป็นถาวรและซ่อนโมเดลบทบาทที่ผิดพลาด
• ซ่อนปุ่มใน UI แล้วคิดว่าปลอดภัย API ต้องปฏิเสธคำขอเช่นกัน แม้ผู้ใช้จะค้นพบ endpoint โดยตรง
• ไม่ตัดสินใจว่าต้องเกิดอะไรเมื่อขอบเขตของใครสักคนเปลี่ยน เช่น ย้ายทีมหรือเปลี่ยนภูมิภาค สิทธิ์ควรอัปเดตอย่างคาดเดาได้ ไม่กระจัดกระจาย
• ถือว่า “admin” คือไม่จำกัดโดยไม่มีกลไกควบคุม แม้แต่แอดมินก็อาจต้องแยก เช่น “จัดการผู้ใช้ได้” แต่ “ไม่สามารถอนุมัติการจ่ายเงิน”

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

ตัวอย่างสั้น ๆ: ในเครื่องมือสำหรับ support และ finance Support ดูโปรไฟล์ลูกค้าและสร้างตั๋วได้ แต่ Finance ส่งออกใบแจ้งหนี้และออกคืนเงินได้ ถ้าคุณรักษาความปลอดภัยแค่หน้าจอ เจ้าหน้าที่ Support อาจเรียก endpoint การส่งออกโดยตรง ไม่ว่าคุณจะสร้างด้วยโค้ดเองหรือแพลตฟอร์มอย่าง AppMaster ที่สร้าง endpoints ฝั่งแบ็กเอนด์ กฎควรอยู่ที่เซิร์ฟเวอร์ ไม่ใช่แค่ใน UI

เช็คลิสต์ด่วนก่อนเริ่มสร้าง

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

สร้างกฎก่อน สร้าง UI

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

ตรวจสอบว่าคุณมีแหล่งความจริงเดียวสำหรับสิทธิ์ ไม่ว่าจะเป็นเอกสาร ตารางในฐานข้อมูล หรือการตั้งค่า no-code ทุกคนในทีมควรรู้ว่ากฎปัจจุบันอยู่ที่ไหน ถ้า spreadsheet บอกอย่างหนึ่งและแอปบอกอีกอย่าง คุณจะส่งบัก

เช็คลิสต์สั้น ๆ ก่อนสร้างที่ใช้ได้จริงสำหรับการออกแบบเมทริกซ์:

• ปฏิเสธโดยดีฟอลต์ถูกบังคับทุกที่ (ปุ่ม UI, endpoints API, การส่งออก, งานพื้นหลัง)
• แต่ละการกระทำมีคำนิยามขอบเขตชัดเจน (own record, team, region, all, หรือตัวอย่างย่อยที่ตั้งชื่อ)
• ความสามารถของแอดมินแยกจากการกระทำทางธุรกิจ (การจัดการบทบาทไม่ใช่การ “อนุมัติคืนเงิน”)
• การกระทำที่อ่อนไหวต้องการการควบคุมเข้มกว่า (ขั้นตอนอนุมัติ การบันทึก และควรมีการแจ้งเตือนสำหรับกิจกรรมผิดปกติ)
• ข้อยกเว้นมีเจ้าของและวันหมดอายุ เพื่อไม่ให้ “การเข้าถึงชั่วคราว” กลายเป็นถาวร

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

ถ้าคุณสร้างใน AppMaster ให้มองรายการเหล่านี้เป็นข้อกำหนดทั้งสำหรับหน้าจอและตรรกะธุรกิจ ปุ่มอาจซ่อนการกระทำ แต่กฎฝั่งแบ็กเอนด์เท่านั้นที่บังคับจริง

ตัวอย่างสถานการณ์: เครื่องมือภายในสำหรับ support และ finance

สมมติบริษัทขนาดกลางมีเครื่องมือภายในเดียวที่ใช้โดย Support และ Finance ฐานข้อมูลเดียวเก็บ Customers, Tickets, Refunds, Payouts และ Settings เล็ก ๆ (เช่น แม่แบบและการเชื่อมต่อ) นี่คือแอปชนิดที่การตรวจสอบแค่การล็อกอินไม่พอ

บทบาทเริ่มต้นที่พวกเขาตกลงกันได้แก่:

• Support Agent: ทำงานกับตั๋วในคิวหนึ่ง
• Support Lead: ช่วยข้ามคิวและอนุมัติการกระทำบางอย่าง
• Finance: จัดการงานที่เกี่ยวกับเงิน
• Ops Admin: เป็นเจ้าของการควบคุมการเข้าถึงและการตั้งค่าระบบ

การออกแบบเมทริกซ์ปฏิบัติเริ่มจากการเขียนการกระตุ้นต่อทรัพยากรก่อน แล้วค่อยคับด้วยขอบเขต

สำหรับ Tickets, Support Agents ดูและอัปเดตสถานะตั๋วได้เฉพาะตั๋วในคิวที่มอบหมายให้พวกเขา พวกเขาสามารถเพิ่มโน้ตได้ แต่ไม่สามารถเปลี่ยนเจ้าของตั๋ว Support Leads ทำได้ทุกอย่างที่ Support Agent ทำได้ และยังย้ายตั๋วภายในภูมิภาคของตนได้

สำหรับ Refunds, Finance สร้างและอนุมัติการคืนเงินได้ แต่มีขีดจำกัดจำนวนเงิน Support สามารถสร้างคำขอคืนเงินได้แต่ไม่สามารถอนุมัติได้ การอนุมัติคืนเงินเป็นการกระทำแยกต่างหากจากการสร้าง เพื่อให้มองเห็นในเมทริกซ์และไม่ถูกให้โดยไม่ตั้งใจ

สำหรับ Payouts และ Settings เครื่องมือจะเข้มงวด: Finance เท่านั้นที่ดู Payouts ได้ และ Ops Admin เท่านั้นที่เปลี่ยน Settings Support ไม่เห็นหน้าจอเหล่านี้ เพื่อลดความผิดพลาด

เพิ่มกฎข้อยกเว้น: Support Lead มาช่วยอีกภูมิภาคเป็นเวลา 2 สัปดาห์ แทนการให้บทบาทกว้าง ๆ อย่าง Ops Admin เมทริกซ์สามารถรวมการขยายขอบเขตชั่วคราว (Support Lead + Region B, หมดอายุในวันที่ระบุ) ข้อยกเว้นเดียวนี้ปลอดภัยกว่าการก็อปปี้สิทธิ์ระหว่างบทบาท

ถ้าสร้างใน AppMaster เมทริกซ์เดียวกันจะชี้ว่าเพจใดปรากฏใน UI และ endpoints ฝั่งแบ็กเอนด์อนุญาตอะไร เพื่อไม่ให้คนเข้าถึง Payouts หรือ Settings โดยเดา endpoint

วิธีทดสอบและดูแลสิทธิ์เมื่อเวลาผ่านไป

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

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

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

• บทบาท: Support Agent. การกระทำ: Refund. คาดว่า: ปฏิเสธพร้อมข้อความชัดเจน ไม่มีข้อมูลเปลี่ยนแปลง
• บทบาท: Finance. การกระทำ: Refund. คาดว่า: อนุญาต สร้างเรคอร์ดคืนเงิน บันทึกผู้กระทำและเหตุผล
• บทบาท: Manager. การกระทำ: View tickets. ขอบเขต: team เท่านั้น. คาดว่า: ดูตั๋วทีมได้ แต่เปิดตั๋วทีมอื่นไม่ได้

ทดสอบกฎเดียวกันสองครั้ง: ใน UI และใน API ถ้า UI บล็อกการกระทำแต่ API ยังกระทำได้ ใครสักคนอาจข้ามหน้าจอได้ ถ้าสร้างด้วย AppMaster ให้เช็กว่าตรรกะ UI และ endpoints ฝั่งแบ็กเอนด์บังคับกฎทั้งคู่

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

สุดท้าย ตัดสินใจว่าบันทึกอะไรสำหรับการกระทำที่อ่อนไหว (refunds, exports, role changes) บันทึกว่าใคร ทำอะไร เมื่อไร และจากไหน ทบทวนล็อกตามตารางเวลา และตั้งกฎแจ้งเตือนสำหรับการกระทำที่ควรหาได้ยาก เช่น การแก้สิทธิ์หรือการส่งออกเป็นกลุ่ม

ขั้นตอนถัดไป: จากเมทริกซ์สู่เครื่องมือภายในที่ใช้งานได้

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

เริ่มด้วยเวิร์กช็อทสั้น ๆ (30 นาทีพอ) มีตัวแทนจากแต่ละบทบาทบวก “เจ้าของทรัพยากร” (คนรับผิดชอบลูกค้า ใบแจ้งหนี้ การจ่ายเงิน ตั๋ว ฯลฯ) เดินผ่านบทบาท ทรัพยากร การกระทำ และขอบเขต แล้วจดข้อยกเว้นพิเศษ หากข้อยกเว้นดูบ่อย อาจเป็นขอบเขตที่ขาดหายไป

ร่างเมทริกซ์ v1 แล้วทบทวนกับเจ้าของทรัพยากร โฟกัสที่ปฏิบัติได้: “Support ดูใบแจ้งหนี้ได้ไหม?” “Finance แก้ไขรายละเอียดลูกค้าได้ไหม?” ถ้าใครลังเล จดกฎด้วยภาษาง่าย ๆ ก่อน คุณค่อยทำให้เป็นทางการทีหลัง

เมื่อ v1 ตกลงกัน สร้างโดเมนหนึ่งแบบ end-to-end ก่อนขยาย เลือกชิ้นที่ทั้งเกี่ยวข้องข้อมูล ตรรกะ และ UI (เช่น: Ticketing หรือการอนุมัติ Invoice) คุณควรตอบได้ว่า: ใครเห็น ใครเปลี่ยน และเกิดอะไรเมื่อพยายาม

ถ้าใช้ AppMaster ให้แมปเมทริกซ์กับส่วนต่าง ๆ ของผลิตภัณฑ์ก่อนสร้างอะไร:

• Data Designer: จัดทรัพยากรเป็นเอนทิตี (ตาราง) และฟิลด์คีย์ที่ส่งผลต่อขอบเขต (เช่น team_id, region_id)
• Business Processes: บังคับกฎเมื่อการเปลี่ยนแปลงเกิดขึ้น (create, update, approve, export)
• กฎการมองเห็น UI: ซ่อนการกระทำที่ผู้ใช้ทำไม่ได้ และแสดงข้อความอธิบายเมื่อถูกปฏิเสธ
• Endpoints: เผยเฉพาะสิ่งที่แต่ละบทบาทต้องการ แยกการดำเนินการเฉพาะแอดมิน

ตัวอย่างง่าย: สร้างฟลว์ “ขอคืนเงิน” ด้วยสองบทบาท (Support สร้าง, Finance อนุมัติ) เมื่อทำงานได้สะอาดแล้ว คุณสามารถเพิ่มกรณีขอบเช่น “Support ยกเลิกได้เฉพาะภายใน 30 นาที”

ลองทำเครื่องมือภายในเล็ก ๆ ใน AppMaster เพื่อทดสอบบทบาทและฟลว์ตั้งแต่ต้น แล้ววนปรับจากเมทริกซ์ เป้าหมายคือจับความเข้าใจผิดก่อนที่คุณจะมี 20 หน้าจอและกองการแก้สิทธิ์