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

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

แนวทางทั่วไปมีการระบุไว้ในขั้นตอนต่อไปนี้:

1. เข้าใจสถาปัตยกรรมแบบหลายผู้เช่า
2. จัดรูปแบบกรณีการใช้งานแอปพลิเคชันแบบหลายผู้เช่าของคุณ
3. บรรลุการแยกผู้เช่า
4. กำหนดวิธีการที่คุณต้องการจัดการตัวตน
5. เลือกรูปแบบการอนุญาตที่เหมาะสม

สถาปัตยกรรมแบบหลายผู้เช่าคืออะไร#

ซอฟต์แวร์ multi-tenancy คือ สถาปัตยกรรมซอฟต์แวร์ ที่มี อินสแตนซ์ เดียวของ ซอฟต์แวร์ รันบนเซิร์ฟเวอร์และให้บริการผู้เช่าหลายราย ระบบที่ออกแบบในลักษณะนี้จะเป็น "แชร์" (แทนที่จะเป็น "เฉพาะ" หรือ "แยก")

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

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

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

กรณีการใช้งานสำหรับแอปพลิเคชันแบบหลายผู้เช่าคืออะไร?#

ผู้เช่าใน SaaS#

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

ผู้เช่าในกรณีการใช้งาน B2B ทั่วไป#

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

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

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

ทำไมคุณถึงควรใช้ผู้เช่าหลายรายในผลิตภัณฑ์ SaaS#

การปรับตัวให้สามารถขยายได้ด้วยผู้เช่าหลายราย#

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

การสร้างประสบการณ์ที่เป็นอันหนึ่งอันเดียวกัน#

เมื่อพิจารณาผลิตภัณฑ์ SaaS ซึ่งมีลักษณะคล้ายคลึงกับตึกอพาร์ตเมนต์ที่มีหลายห้อง ทั้งหมดในนั้นแชร์ฟังก์ชันการใช้งานทั่วไป เช่น น้ำ ไฟฟ้า และแก๊ส แต่ยังคงมีการควบคุมการจัดการพื้นที่และทรัพยากรของตนเอง นี่คือแนวทางที่ง่ายต่อการจัดการทรัพย์สิน

การรับรองความปลอดภัยโดยการแยกผู้เช่า#

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

ทำไมคุณควรบรรลุการแยกผู้เช่า?#

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

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

การแยกผู้เช่าไม่ได้ขัดแย้งกับมุมมอง "การแชร์" ของหลายผู้เช่า#

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

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

การตรวจสอบและการอนุญาตไม่เท่ากับ "การแยก"#

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

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

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

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

ใช้ "องค์กร" เพื่อแสดงผู้เช่าผลิตภัณฑ์ SaaS สำหรับบรรลุการแยกผู้เช่า#

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

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

การจัดการตัวตนในแอปพลิเคชันแบบหลายผู้เช่า#

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

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

1. ตัวตนทั้งสองสามารถดำรงอยู่ภายในระบบตัวตนเดียว ตัวอย่างเช่น ซาร่าห์อาจมีอีเมลส่วนตัวลงทะเบียนพร้อมกับอีเมลองค์กรที่เชื่อมต่อผ่านการลงชื่อเข้าใช้เดียว (SSO)
2. ผู้ใช้รักษาตัวตนที่แตกต่างกันสองตัวภายในระบบตัวตนที่แตกต่างกันซึ่งแสดงถึงผลิตภัณฑ์ที่แตกต่างกันโดยสิ้นเชิง ผลิตภัณฑ์เหล่านี้ไม่เกี่ยวข้องกันเลย

บางครั้งซาริโอเหล่านี้ถูกเรียกว่า "การแยกตัวตน" จึงอาจไม่ช่วยในการตัดสินใจ

แทนที่จะตัดสินใจว่าคุณต้องการ "การแยกตัวตน" หรือไม่ ให้พิจารณา

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

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

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

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

วิธีการเลือกและออกแบบโมเดลการอนุญาตที่เหมาะสม#

เมื่อเลือกรูปแบบการอนุญาตที่เหมาะสม ให้พิจารณาคำถามเหล่านี้:

1. คุณกำลังพัฒนาผลิตภัณฑ์ B2C, B2B หรือแบบผสมอยู่หรือไม่?
2. แอปของคุณมีสถาปัตยกรรมแบบหลายผู้เช่าหรือไม่?
3. มีความต้องการระดับการแยกบางประเภทในแอปของคุณที่หน่วยธุรกิจกำหนดหรือไม่?
4. มีบทบาทและสิทธิ์อะไรบ้างที่ต้องกำหนดในบริบทขององค์กร และที่ไม่ใช่?

โมเดลการอนุญาตที่แตกต่างกันใน Logto มีอะไรบ้าง?#

การควบคุมการเข้าถึงแบบมุ่งบทบาท#

RBAC (การควบคุมการเข้าถึงตามบทบาท) เป็นวิธีการเพื่อให้สิทธิ์ผู้ใช้ตามบทบาทของพวกเขา ช่วยให้สามารถจัดการการเข้าถึงทรัพยากรได้อย่างมีประสิทธิภาพ

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

การควบคุมการเข้าถึงแบบมุ่งบทบาทสำหรับ API#

เพื่อปกป้องทรัพยากร API ทั่วไปที่ไม่เฉพาะเจาะจงกับองค์กรใดๆ และไม่ต้องการข้อจำกัดบริบท ฟีเจอร์ API RBAC เหมาะสมอย่างยิ่ง

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

ทรัพยากร API บทบาทและสิทธิ์ที่นี่เป็น "สาธารณะ" ภายใต้ระบบตัวตนที่เป็นหนึ่งเดียว นี่เป็นสิ่งที่พบบ่อยในผลิตภัณฑ์ B2C ซึ่งมีความลำดับขั้นที่น้อยและไม่ต้องการการแยกที่ลึกเกินไป

การควบคุมการเข้าถึงแบบมุ่งบทบาทสำหรับองค์กร#

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

Organizational RBAC มุ่งเน้นไปที่การควบคุมการเข้าถึงในระดับองค์กรแทนที่จะเป็นระดับ API วิธีนี้ให้ความยืดหยุ่นที่สำคัญในการจัดการตนเองในระดับองค์กรระยะยาวแต่ยังอยู่ภายในระบบตัวตนที่เป็นหนึ่งเดียว

คุณสมบัติสำคัญของ Organizational RBAC คือบทบาทและสิทธิ์นั้นเหมือนกันระหว่างองค์กรทั้งหมดโดยปกติ ทำให้ "เทมเพลตองค์กร Logto" มีความหมายอย่างยิ่งในการปรับประสิทธิภาพการพัฒนา นี่สอดคล้องกับปรัชญาที่แชริ่งของแอปพลิเคชันหลายผู้เช่า ซึ่งแนวคิดการควบคุมการเข้าถึงและตัวตนนั้นเป็นส่วนประกอบโครงสร้างพื้นฐานทั่วไปในหมู่ผู้เช่าทั้งหมด (ผู้เช่าในแอป) สิ่งนี้ถือเป็นวิธีการทั่วไปในผลิตภัณฑ์ SaaS

ปิดท้าย#

บทความนี้ให้ทุกสิ่งที่คุณต้องการเพื่อเริ่มต้นในการเตรียมและกำหนดค่าแอปพลิเคชันแบบหลายผู้เช่า ลองใช้ Logto วันนี้และเริ่มใช้แนวทางปฏิบัติที่ดีที่สุดสำหรับการพัฒนาแอปพลิเคชันแบบหลายผู้เช่าด้วยองค์กร