สรุปสั้นๆ (TL;DR)
การควบคุมการเข้าถึงตามบทบาท (Role-Based Access Control - RBAC) เป็นโมเดลความปลอดภัยที่กำหนดสิทธิ์ให้กับบทบาทแทนที่จะเป็นผู้ใช้แต่ละคน ทำให้การจัดการทีม API สามารถปรับขนาดและตรวจสอบได้ ระบบ RBAC ที่เหมาะสมสำหรับการทำงานร่วมกันด้าน API ควรมอบลำดับชั้นของสิทธิ์สามระดับ (องค์กร → ทีม → โปรเจกต์), การสร้างบทบาทที่กำหนดเองเพื่อการควบคุมที่ละเอียด และการผสานรวมกับระบบองค์กรเช่น SSO และ SCIM Apidog มอบกรอบการทำงาน RBAC ที่ครอบคลุมด้วย 12 บทบาทในสามระดับ และบทบาทโปรเจกต์ที่กำหนดเองสำหรับทีมองค์กร ซึ่งให้คุณควบคุมได้อย่างแม่นยำว่าใครสามารถดู แก้ไข ทดสอบ หรือจัดการสินทรัพย์ API ของคุณได้บ้าง
ทำไม RBAC จึงสำคัญสำหรับทีม API
การพัฒนา API เกี่ยวข้องกับผู้มีส่วนได้ส่วนเสียหลายฝ่าย: นักพัฒนาที่เขียนเอนด์พอยต์, วิศวกร QA ที่ดำเนินการทดสอบ, ผู้จัดการผลิตภัณฑ์ที่ตรวจสอบข้อกำหนด, นักเขียนด้านเทคนิคที่สร้างเอกสาร และทีมรักษาความปลอดภัยที่ตรวจสอบบันทึกการเข้าถึง หากไม่มีการควบคุมการเข้าถึงที่เป็นโครงสร้าง ความวุ่นวายจะตามมา
ปัญหาในโลกแห่งความเป็นจริง: นักพัฒนารุ่นเยาว์แก้ไขข้อกำหนด API ที่ใช้งานจริงโดยไม่ได้ตั้งใจ ผู้รับเหมาเข้าถึงเอนด์พอยต์การชำระเงินที่ละเอียดอ่อนที่พวกเขาไม่ควรเห็น ข้อมูลประจำตัวของอดีตพนักงานยังคงใช้งานได้หลายเดือนหลังจากลาออก นี่ไม่ใช่สถานการณ์สมมติ แต่เป็นสิ่งที่เกิดขึ้นทุกวันในองค์กรที่จัดการ API โดยไม่มี RBAC ที่เหมาะสม
รายงานความปลอดภัยของ API พบว่า 61% ของเหตุการณ์ความปลอดภัยของ API เกี่ยวข้องกับการเข้าถึงโดยไม่ได้รับอนุญาตหรือสิทธิ์ที่มากเกินไป สาเหตุหลักคืออะไร? ทีมงานขาดการควบคุมที่ละเอียดว่าใครสามารถทำอะไรกับสินทรัพย์ API ของตนได้บ้าง
RBAC แก้ไขปัญหานี้โดย:
- การกำหนดสิทธิ์ให้กับบทบาท ไม่ใช่ผู้ใช้แต่ละคน — เมื่อมีคนเข้าร่วมหรือลาออก คุณจะอัปเดตการมอบหมายบทบาทของพวกเขา ไม่ใช่สิทธิ์ 50 รายการ
- การบังคับใช้หลักการเข้าถึงที่มีสิทธิ์น้อยที่สุด (least-privilege access) — แต่ละบทบาทจะได้รับสิทธิ์ขั้นต่ำที่จำเป็น
- การสร้างบันทึกการตรวจสอบ (audit trails) — ทุกการกระทำจะถูกแมปกับบทบาท ทำให้การรายงานการปฏิบัติตามกฎระเบียบเป็นเรื่องง่าย
- การปรับขนาดการเติบโตของทีม — เพิ่มสมาชิกทีมใหม่ 100 คนโดยการมอบหมายบทบาท ไม่ใช่การกำหนดค่าบัญชีแต่ละบัญชี
ระบบ RBAC ของ Apidog จัดการกับความท้าทายเหล่านี้ด้วยโมเดลสิทธิ์สามระดับที่ออกแบบมาโดยเฉพาะสำหรับขั้นตอนการทำงานของการพัฒนา API มาดูกันว่ามันทำงานอย่างไร
ลำดับชั้นของสิทธิ์สามระดับ
RBAC สำหรับการทำงานร่วมกันของ API ที่มีประสิทธิภาพต้องใช้สิทธิ์ในหลายระดับ ไม่ใช่แค่ "สามารถเข้าถึงโปรเจกต์นี้ได้" Apidog ใช้ลำดับชั้นสามระดับที่สะท้อนถึงวิธีที่องค์กรจริงจัดโครงสร้างงานของตน:
| ระดับ | ขอบเขต | สิ่งที่ควบคุม |
|---|---|---|
| องค์กร | ทั่วทั้งบริษัท | การเรียกเก็บเงิน, SSO, การจัดการสมาชิก, การกำหนดบทบาทที่กำหนดเอง |
| ทีม | แผนก/หน่วยธุรกิจ | การเป็นสมาชิกทีม, การสร้างโปรเจกต์, ทรัพยากรทีม |
| โปรเจกต์ | API แต่ละรายการ | เอนด์พอยต์, การทดสอบ, เอกสาร, สภาพแวดล้อม, สาขา (branches) |
ทำไมสามระดับจึงสำคัญ: ลองพิจารณาบริษัทฟินเทคที่มีสามทีม ได้แก่ ทีมการชำระเงิน, ทีมข้อมูลประจำตัว และทีมวิเคราะห์ แต่ละทีมจัดการโปรเจกต์ API หลายรายการ นักพัฒนาในทีมการชำระเงินควรเข้าถึง Payment API ได้ แต่ไม่ควรเข้าถึงโปรเจกต์ Identity หรือ Analytics ผู้ดูแลระบบองค์กรจำเป็นต้องกำหนดค่า SSO สำหรับทุกทีม แต่ไม่จำเป็นต้องแก้ไขเอนด์พอยต์ API ทุกรายการ วิศวกร QA ต้องดำเนินการทดสอบในโปรเจกต์ที่เฉพาะเจาะจงโดยไม่ต้องแก้ไขข้อกำหนด API
แนวทางลำดับชั้นนี้ป้องกันความล้มเหลวสองประการที่พบบ่อย:
- การให้สิทธิ์มากเกินไป (Over-permissioning): การให้สิทธิ์ผู้ดูแลระบบแก่ทุกคนเนื่องจากการควบคุมที่ละเอียดนั้นซับซ้อนเกินไป
- ช่องว่างของสิทธิ์ (Permission gaps): การสร้างสิทธิ์ระดับทีมแต่ลืมความละเอียดระดับโปรเจกต์
มาสำรวจบทบาทและความสามารถของแต่ละระดับกัน
บทบาทและสิทธิ์ระดับองค์กร
บทบาทองค์กรควบคุมการตั้งค่าทั่วทั้งบริษัท—การเรียกเก็บเงิน, การรวมผู้ให้บริการข้อมูลประจำตัว, การจัดการสมาชิก และการกำกับดูแลทรัพยากร บทบาทเหล่านี้มีผลกับทุกทีมและทุกโปรเจกต์ภายใต้ขอบเขตขององค์กร
บทบาทองค์กรที่มาพร้อมระบบ
| บทบาท | คำอธิบาย | ความสามารถหลัก |
|---|---|---|
| เจ้าขององค์กร (Org Owner) | ผู้สร้างองค์กร, ผู้มีอำนาจสูงสุด | เปลี่ยนชื่อ/โอน/ยุบองค์กร, มีอำนาจผู้ดูแลระบบเต็มรูปแบบ |
| ผู้ดูแลองค์กร (Org Admin) | การจัดการองค์กร | จัดการสมาชิก, ทีม, SSO, บทบาทที่กำหนดเอง, ทรัพยากรองค์กร |
| สมาชิกองค์กร (Org Member) | ผู้เข้าร่วมพื้นฐาน | เข้าร่วมทีม, มีส่วนร่วมในโปรเจกต์ (ขึ้นอยู่กับสิทธิ์ของทีม/โปรเจกต์) |
| ผู้จัดการการเรียกเก็บเงิน (Billing Manager) | ผู้ดูแลระบบการเงินเท่านั้น | จัดการการสมัครสมาชิกและการเรียกเก็บเงิน (บทบาทอิสระ, ซ้อนทับกับบทบาทอื่นได้) |
เมทริกซ์สิทธิ์: การตั้งค่าองค์กร
| คุณสมบัติ | เจ้าขององค์กร | ผู้ดูแลองค์กร | สมาชิกองค์กร | ผู้จัดการการเรียกเก็บเงิน |
|---|---|---|---|---|
| เข้าถึงการตั้งค่าองค์กร | ✅ | ✅ | ❌ | ❌ |
| เปลี่ยนชื่อองค์กร | ✅ | ✅ | ❌ | ❌ |
| โอนความเป็นเจ้าขององค์กร | ✅ | ❌ | ❌ | ❌ |
| ยุบองค์กร | ✅ | ❌ | ❌ | ❌ |
เมทริกซ์สิทธิ์: การจัดการทีม
| คุณสมบัติ | เจ้าขององค์กร | ผู้ดูแลองค์กร | สมาชิกองค์กร | ผู้จัดการการเรียกเก็บเงิน |
|---|---|---|---|---|
| สร้างทีมใหม่ | ✅ | ✅ | ❌ | ❌ |
| โอนทีมเข้าองค์กร | ✅ | ✅ | ❌ | ❌ |
| โอนทีมออกจากองค์กร | ✅ | ✅ | ❌ | ❌ |
เมทริกซ์สิทธิ์: การจัดการสมาชิก
| คุณสมบัติ | เจ้าขององค์กร | ผู้ดูแลองค์กร | สมาชิกองค์กร | ผู้จัดการการเรียกเก็บเงิน |
|---|---|---|---|---|
| เชิญสมาชิก | ✅ | ✅ | ❌ | ❌ |
| เปลี่ยนบทบาทองค์กรของสมาชิก | ✅ | ✅ | ❌ | ❌ |
| ลบสมาชิก | ✅ | ✅ | ❌ | ❌ |
บทบาทสมาชิกองค์กรถูกจำกัดโดยเจตนา—เป็นบทบาท "ผู้รับเฉื่อย" สมาชิกสามารถเข้าร่วมทีมและมีส่วนร่วมในโปรเจกต์ตามสิทธิ์ระดับทีม/โปรเจกต์ แต่ไม่สามารถจัดการการตั้งค่าองค์กรได้ การออกแบบนี้ป้องกันการเปลี่ยนแปลงทั่วทั้งองค์กรโดยไม่ตั้งใจ ในขณะเดียวกันก็ส่งเสริมการทำงานร่วมกัน
ผู้จัดการการเรียกเก็บเงินเป็นบทบาทที่ไม่เหมือนใคร: บทบาทนี้เป็นอิสระและสามารถซ้อนทับกับบทบาทอื่นได้ ผู้ใช้สามารถเป็นทั้งสมาชิกองค์กรและผู้จัดการการเรียกเก็บเงินได้ ผู้จัดการการเรียกเก็บเงินไม่สามารถเข้าถึงการตั้งค่าองค์กร จัดการสมาชิก หรือกำหนดค่า SSO ได้—พวกเขามีหน้าที่จัดการการสมัครสมาชิกและการเรียกเก็บเงินเท่านั้น
บทบาทและสิทธิ์ระดับทีม
บทบาททีมควบคุมการดำเนินการระดับแผนก—การจัดการสมาชิกทีม, การสร้างโปรเจกต์ และการกำหนดค่าทรัพยากรทีม ทีมโดยทั่วไปจะแสดงถึงหน่วยธุรกิจ, สายผลิตภัณฑ์ หรือกลุ่มงาน (เช่น ทีมโมบาย, ทีมแบ็กเอนด์, ทีม QA)
บทบาททีมที่มาพร้อมระบบ
| บทบาท | คำอธิบาย | ความสามารถหลัก |
|---|---|---|
| เจ้าของทีม (Team Owner) | ผู้สร้างทีม, ควบคุมทีมเต็มรูปแบบ | โอน/ยุบทีม, จัดการการตั้งค่าทีมทั้งหมด |
| ผู้ดูแลทีม (Team Admin) | การจัดการทีม | เชิญสมาชิก, กำหนดบทบาท, สร้าง/ลบโปรเจกต์, จัดการทรัพยากรทีม |
| สมาชิกทีม (Team Member) | ผู้เข้าร่วมทีม | ดูรายละเอียดสมาชิก, มีส่วนร่วมในโปรเจกต์ (ขึ้นอยู่กับสิทธิ์ของโปรเจกต์) |
| แขก (Guest) | ผู้ทำงานร่วมกันภายนอก | ไม่มีสิทธิ์จัดการทีม, เข้าถึงโปรเจกต์เท่านั้น |
เมทริกซ์สิทธิ์: การจัดการทีม
| สิทธิ์ | เจ้าของทีม | ผู้ดูแลทีม | สมาชิกทีม | แขก |
|---|---|---|---|---|
| ดูรายละเอียดสมาชิกทีม | ✅ | ✅ | ✅ | ❌ |
| เชิญสมาชิกทีม | ✅ | ✅ | ❌ | ❌ |
| กำหนด/ลบบทบาทสมาชิกทีม | ✅ | ✅ | ❌ | ❌ |
| ดูบทบาทโปรเจกต์ | ✅ | ✅ | ❌ | ❌ |
| เพิ่ม/แก้ไข/ลบบทบาทโปรเจกต์ | ✅ | ✅ | ❌ | ❌ |
เมทริกซ์สิทธิ์: การตั้งค่าทีม
| สิทธิ์ | เจ้าของทีม | ผู้ดูแลทีม | สมาชิกทีม | แขก |
|---|---|---|---|---|
| แก้ไขชื่อทีม | ✅ | ✅ | ❌ | ❌ |
| โอนทีม | ✅ | ❌ | ❌ | ❌ |
| ยุบทีม | ✅ | ❌ | ❌ | ❌ |
เมทริกซ์สิทธิ์: การดำเนินการโปรเจกต์
| สิทธิ์ | เจ้าของทีม | ผู้ดูแลทีม | สมาชิกทีม | แขก |
|---|---|---|---|---|
| สร้างโปรเจกต์ใหม่ | ✅ | ✅ | ❌ | ❌ |
| โคลนโปรเจกต์ | ✅ | ✅ | ❌ | ❌ |
| ลบ/โอนโปรเจกต์ | ✅ | ✅ | ❌ | ❌ |
| แก้ไขชื่อโปรเจกต์ | ✅ | ✅ | ❌ | ❌ |
บทบาทแขกมีประสิทธิภาพสำหรับการทำงานร่วมกันภายนอก ที่ปรึกษา, ผู้รับเหมา หรือผู้ทำงานร่วมกันข้ามแผนกสามารถเข้าร่วมทีมในฐานะแขก โดยเข้าถึงได้เฉพาะโปรเจกต์ที่เฉพาะเจาะจงเท่านั้น—ไม่ใช่คุณสมบัติการจัดการทีมหรือโปรเจกต์ทีมอื่น ๆ สิ่งนี้ช่วยป้องกันผู้ใช้ภายนอกจากการเห็นพื้นที่ธุรกิจที่ไม่เกี่ยวข้อง
บทบาทและสิทธิ์ระดับโปรเจกต์
บทบาทโปรเจกต์ควบคุมการดำเนินการระดับ API—การแก้ไขเอนด์พอยต์, การดำเนินการทดสอบ, การจัดการสภาพแวดล้อม, การเผยแพร่เอกสาร นี่คือที่ที่งาน API รายวันเกิดขึ้น
บทบาทโปรเจกต์ที่มาพร้อมระบบ
| บทบาท | คำอธิบาย | กรณีใช้งาน |
|---|---|---|
| ผู้ดูแลระบบ (Admin) | ควบคุมโปรเจกต์เต็มรูปแบบ | หัวหน้าโปรเจกต์, เจ้าของ API |
| ผู้แก้ไข (Editor) | แก้ไขเนื้อหา | นักพัฒนา, วิศวกร QA |
| อ่านอย่างเดียว (Read-only) | ดูและรันเท่านั้น | ผู้จัดการผลิตภัณฑ์, ผู้มีส่วนได้ส่วนเสีย, ผู้ตรวจสอบ |
| ต้องห้าม (Forbidden) | ไม่สามารถเข้าถึงได้ | ผู้ใช้ที่ถูกจำกัด, โปรเจกต์ที่ละเอียดอ่อน |
หมวดหมู่สิทธิ์
สิทธิ์โปรเจกต์ครอบคลุมแปดหมวดหมู่หลัก:
- การจัดการสาขา (Branch Management) — สาขา Sprint, คำขอผสาน (merge requests), สาขาที่ได้รับการป้องกัน, เวอร์ชัน API
- การจัดการเอนด์พอยต์ (Endpoint Management) — เอนด์พอยต์, กรณีใช้งาน, Schema, คอมโพเนนต์, คำขอ, การดำเนินการกับถังขยะ
- การทดสอบอัตโนมัติ (Automated Tests) — สถานการณ์ทดสอบ, การทดสอบประสิทธิภาพ, งานที่กำหนดเวลาไว้, รายงานการทดสอบ
- การจัดการสภาพแวดล้อม (Environment Management) — ตัวแปรทั่วโลก, พารามิเตอร์, สภาพแวดล้อม, Vault Secrets
- การแบ่งปันเอกสาร (Documentation Sharing) — การแบ่งปันด่วน, การเผยแพร่เว็บไซต์เอกสาร
- การตั้งค่าโปรเจกต์ (Project Settings) — การตั้งค่าพื้นฐาน, การจัดการสมาชิก, การตั้งค่าคุณสมบัติ, การแจ้งเตือน
- ประวัติคำขอ (Request History) — ประวัติคำขอในเครื่องและที่แชร์
- นำเข้า/ส่งออก (Import/Export) — การนำเข้าข้อมูล, การนำเข้าที่กำหนดเวลาไว้, การดำเนินการส่งออก
จุดเด่นของสิทธิ์ที่สำคัญ
| สิทธิ์ | ผู้ดูแลระบบ | ผู้แก้ไข | อ่านอย่างเดียว | ต้องห้าม |
|---|---|---|---|---|
| ดู, รันเอนด์พอยต์ | ✅ | ✅ | ✅ | ❌ |
| เพิ่ม, ลบ, แก้ไขเอนด์พอยต์ | ✅ | ✅ | ❌ | ❌ |
| รันการทดสอบฟังก์ชัน | ✅ | ✅ | ✅ | ❌ |
| เพิ่ม, ลบ, แก้ไขสถานการณ์ทดสอบ | ✅ | ✅ | ❌ | ❌ |
| ดู, แก้ไขตัวแปรสภาพแวดล้อม | ✅ | ✅ | ✅ | ❌ |
| เพิ่ม, ลบ, แก้ไขสภาพแวดล้อม | ✅ | ✅ | ❌ | ❌ |
| เข้าถึง Vault Secrets | ✅ | ✅ | ❌ | ❌ |
| เผยแพร่การตั้งค่าเว็บไซต์เอกสาร | ✅ | ❌ | ❌ | ❌ |
| โคลนโปรเจกต์ | ✅ | ❌ | ❌ | ❌ |
| จัดการสมาชิกโปรเจกต์ | ✅ | ❌ | ❌ | ❌ |
บทบาท "ต้องห้าม" มีความสำคัญต่อความปลอดภัย เมื่อสมาชิกทีมไม่ควรเข้าถึงโปรเจกต์ที่เฉพาะเจาะจง (เช่น API การชำระเงินที่ละเอียดอ่อน) ให้กำหนดบทบาทต้องห้ามแทนการลบออกจากทีม พวกเขายังคงเป็นสมาชิกทีมแต่ไม่สามารถเข้าถึงโปรเจกต์นั้นได้เลย
บทบาทที่กำหนดเองสำหรับการควบคุมที่ละเอียด
บทบาทที่มาพร้อมระบบครอบคลุมกรณีส่วนใหญ่ แต่ทีมองค์กรมักต้องการสิทธิ์ที่ละเอียดอ่อนซึ่งไม่ตรงกับหมวดหมู่มาตรฐาน แผน Enterprise ของ Apidog รองรับบทบาทโปรเจกต์ที่กำหนดเองพร้อมการควบคุมสิทธิ์ที่ละเอียด
เมื่อคุณต้องการบทบาทที่กำหนดเอง
- บทบาทวิศวกร QA: สามารถรันการทดสอบและแก้ไขสถานการณ์ทดสอบได้ แต่ไม่สามารถแก้ไขข้อกำหนด API ได้
- บทบาทนักเขียนด้านเทคนิค: สามารถแก้ไขเอกสารได้ แต่ไม่สามารถแก้ไขเอนด์พอยต์หรือสภาพแวดล้อมได้
- บทบาทผู้ตรวจสอบความปลอดภัย: สิทธิ์อ่านอย่างเดียวพร้อมความสามารถในการดู Vault Secrets แต่ไม่สามารถแก้ไขอะไรได้
- บทบาทพนักงานฝึกหัด: สามารถดูเอนด์พอยต์และส่งคำขอได้ แต่ไม่สามารถลบอะไรได้
การสร้างบทบาทโปรเจกต์ที่กำหนดเอง
ไปที่ Team → Members → Roles and Permissions หรือ Organization → Members → Roles and Permissions จากนั้นคลิก + Add เพื่อสร้างบทบาทที่กำหนดเอง
คุณสามารถกำหนดค่าสิทธิ์ในแปดหมวดหมู่ทั้งหมด:
| หมวดหมู่ | การควบคุมที่ละเอียด |
|---|---|
| การจัดการสาขา | ดูสาขา, ผสานสาขา, ส่งคำขอผสาน, แก้ไขสาขาที่ได้รับการป้องกัน |
| การจัดการเอนด์พอยต์ | ดู/รัน, เพิ่ม/แก้ไข/ลบ, สร้างโค้ด, จัดการกรณีใช้งาน, Schema, คอมโพเนนต์, คำขอ |
| การทดสอบอัตโนมัติ | รันการทดสอบฟังก์ชัน, รันการทดสอบประสิทธิภาพ, แก้ไขสถานการณ์, จัดการงานที่กำหนดเวลาไว้, ลบรายงาน |
| การจัดการสภาพแวดล้อม | ดู/แก้ไขค่าปัจจุบัน, เพิ่ม/แก้ไข/ลบ, จัดการ Vault Secrets |
| เอกสาร | ดูการแบ่งปันด่วน, แก้ไขการแบ่งปันด่วน, ดูตัวอย่างเว็บไซต์เอกสาร, เผยแพร่การตั้งค่า |
| การตั้งค่าโปรเจกต์ | ดูการตั้งค่า, แก้ไขการตั้งค่า, จัดการสมาชิก, กำหนดค่าการแจ้งเตือน, จัดการการนำเข้า/ส่งออก |
| ประวัติคำขอ | ดูประวัติในเครื่อง, แชร์ประวัติ, ดูประวัติที่แชร์, ลบประวัติที่แชร์ |
แนวทางปฏิบัติที่ดีที่สุดสำหรับบทบาทที่กำหนดเอง
- เริ่มต้นด้วยการคัดลอก — คัดลอกบทบาทที่มีอยู่ (Editor, Read-only) และแก้ไขแทนที่จะเริ่มต้นจากศูนย์
- ใช้ช่องทำเครื่องหมาย "All Permissions" — การทำเครื่องหมาย "All Permissions" สำหรับโมดูลจะให้สิทธิ์ในอนาคตที่เพิ่มเข้ามาในโมดูลนั้นโดยอัตโนมัติ
- ทดสอบก่อนนำไปใช้ — สร้างโปรเจกต์ทดสอบ, กำหนดบทบาทที่กำหนดเอง และตรวจสอบว่าสิทธิ์ทำงานได้ตามที่คาดไว้
- บันทึกบทบาทที่กำหนดเอง — สร้างข้อตกลงการตั้งชื่อบทบาทและบันทึกว่าแต่ละบทบาทที่กำหนดเองสามารถทำอะไรได้บ้าง
- ตรวจสอบเป็นประจำทุกไตรมาส — บทบาทที่กำหนดเองควรได้รับการตรวจสอบเป็นระยะเพื่อให้แน่ใจว่ายังคงตรงกับความต้องการของทีม
คุณสมบัติความปลอดภัยระดับองค์กร
RBAC เป็นพื้นฐาน แต่โปรแกรม API ระดับองค์กรต้องการความสามารถด้านความปลอดภัยเพิ่มเติม Apidog ผสานรวมคุณสมบัติด้านความปลอดภัยระดับองค์กรที่ทำงานร่วมกับ RBAC
Single Sign-On (SSO)
SSO ด้วย SAML 2.0 ช่วยให้การรับรองความถูกต้องแบบรวมศูนย์ผ่านผู้ให้บริการข้อมูลประจำตัวเช่น:
- Microsoft Entra ID (Azure Active Directory)
- Okta
- Google Workspace
- OneLogin
- ผู้ให้บริการ SAML 2.0 ที่กำหนดเอง
ทำไม SSO จึงสำคัญสำหรับ RBAC:
- ลดความเสี่ยงจากรหัสผ่านในเครื่อง — ไม่มีรหัสผ่านที่อ่อนแอ, ไม่มีการแชร์รหัสผ่าน, ไม่มีการลืมข้อมูลประจำตัว
- รวมศูนย์การจัดการข้อมูลประจำตัว — HR เพิ่ม/ลบผู้ใช้ในที่เดียว; การเปลี่ยนแปลงจะซิงค์กับ Apidog
- บังคับใช้การรับรองความถูกต้องหลายปัจจัย (multi-factor authentication) — MFA ระดับ IdP มีผลกับการเข้าถึง Apidog
- ลดความยุ่งยากในการเริ่มต้นใช้งาน — พนักงานใหม่ลงชื่อเข้าใช้ด้วยข้อมูลประจำตัวขององค์กร ไม่ต้องสร้างบัญชีแยกต่างหาก
การจัดเตรียม SCIM
SCIM (System for Cross-domain Identity Management) ทำให้การจัดเตรียมผู้ใช้เป็นไปโดยอัตโนมัติ:
| ความสามารถ | สิ่งที่ทำ |
|---|---|
| เพิ่มผู้ใช้ | เมื่อ IdP สร้างผู้ใช้, ผู้ใช้จะถูกเพิ่มไปยังองค์กร Apidog โดยอัตโนมัติ |
| ลบผู้ใช้ | เมื่อ IdP ลบผู้ใช้, ผู้ใช้จะถูกลบออกจาก Apidog—ไม่มีการเข้าถึงที่ค้างอยู่ |
| เชื่อมโยงบัญชี | ข้อมูลประจำตัว SSO จะเชื่อมโยงกับบัญชี Apidog ที่มีอยู่โดยอัตโนมัติ |
ข้อดีของ SCIM:
- การยกเลิกการจัดเตรียมทันที — อดีตพนักงานจะสูญเสียการเข้าถึงภายในไม่กี่นาที ไม่ใช่หลายวัน
- ลดภาระการดูแลระบบ — ไม่มีขั้นตอนการเชิญ/ลบด้วยตนเอง
- การปฏิบัติตามกฎระเบียบ — บันทึกการตรวจสอบแสดงให้เห็นอย่างชัดเจนว่าเมื่อใดที่ได้รับ/ถูกลบการเข้าถึง
- กำจัดการผิดพลาด — ไม่มีบัญชีที่ถูกลืมหรือข้อผิดพลาดด้วยตนเอง
การแมปกลุ่มไปยังทีม
Apidog รองรับการแมปกลุ่ม SAML—กลุ่ม IdP จะถูกแมปไปยังทีม Apidog โดยอัตโนมัติ:
- กำหนดค่าการอ้างสิทธิ์กลุ่มใน IdP ของคุณ (เช่น กลุ่ม Azure AD)
- แมปแต่ละกลุ่ม IdP กับทีม Apidog
- ตั้งค่าสิทธิ์บทบาททีมสำหรับแต่ละกลุ่ม
ตัวอย่าง: กลุ่ม Azure AD "API Developers" แมปกับ "Backend Team" ของ Apidog ด้วยบทบาทสมาชิกทีม กลุ่ม Azure AD "API Admins" แมปกับ "Platform Team" ด้วยบทบาทผู้ดูแลทีม
เมื่อพนักงานลงชื่อเข้าใช้ผ่าน SSO พวกเขาจะเข้าร่วมทีมที่ถูกต้องพร้อมสิทธิ์ที่เหมาะสมโดยอัตโนมัติ—ไม่ต้องมีการกำหนดด้วยตนเอง
Vault Secrets
Vault Secrets ให้การจัดการข้อมูลประจำตัวแบบรวมศูนย์:
| คุณสมบัติ | ประโยชน์ด้านความปลอดภัย |
|---|---|
| การจัดเก็บที่เข้ารหัส | คีย์ API, รหัสผ่าน, โทเค็นถูกจัดเก็บแบบเข้ารหัส ไม่ใช่ในไฟล์สภาพแวดล้อม |
| การเข้าถึงแบบอ้างอิง | ผู้ใช้อ้างอิงความลับด้วยชื่อ ไม่เคยเห็นค่าจริง |
| การมองเห็นตามบทบาท | เฉพาะผู้ดูแลระบบและผู้แก้ไขเท่านั้นที่สามารถเพิ่ม/แก้ไข Vault Secrets ได้ |
| บันทึกการตรวจสอบ | การเข้าถึงความลับทุกครั้งจะถูกบันทึกเพื่อการปฏิบัติตามกฎระเบียบ |
Vault Secrets เทียบกับไฟล์สภาพแวดล้อมในเครื่อง:
| แนวทาง | ความเสี่ยงด้านความปลอดภัย |
|---|---|
| ไฟล์สภาพแวดล้อมในเครื่อง | ความลับสามารถมองเห็นได้สำหรับทุกคนที่เข้าถึงโปรเจกต์ อาจถูกแชร์ผ่าน Git |
| Vault Secrets | รวมศูนย์, เข้ารหัส, ควบคุมตามบทบาท, ตรวจสอบได้ |
วิธีตั้งค่า RBAC ใน Apidog
มาดูขั้นตอนการตั้งค่าโครงสร้าง RBAC ที่สมบูรณ์สำหรับทีม API ทั่วไปกัน
ขั้นตอนที่ 1: กำหนดโครงสร้างทีมของคุณ
ก่อนที่จะกำหนดค่าบทบาท ให้แมปองค์กรของคุณ:
องค์กร: บริษัทของคุณ
├── ทีม: การชำระเงิน (Payments)
│ ├── โปรเจกต์: Payment Gateway API
│ ├── โปรเจกต์: Fraud Detection API
│ └── โปรเจกต์: Billing Service API
├── ทีม: ข้อมูลประจำตัว (Identity)
│ ├── โปรเจกต์: Auth Service API
│ └── โปรเจกต์: User Management API
└── ทีม: การวิเคราะห์ (Analytics)
├── โปรเจกต์: Metrics API
└── โปรเจกต์: Reporting APIขั้นตอนที่ 2: กำหนดค่าบทบาทองค์กร
- เจ้าขององค์กร (Org Owner) (1 คน): CEO, CTO หรือหัวหน้าแพลตฟอร์ม
- ผู้ดูแลองค์กร (Org Admins) (2-3 คน): ผู้จัดการฝ่ายวิศวกรรม, หัวหน้าฝ่ายความปลอดภัย
- สมาชิกองค์กร (Org Members) (คนอื่นๆ ทั้งหมด): นักพัฒนา, QA, PM, นักเขียน
ขั้นตอนที่ 3: กำหนดค่าบทบาททีม
สำหรับแต่ละทีม:
| ทีม | เจ้าของทีม | ผู้ดูแลทีม | สมาชิกทีม |
|---|---|---|---|
| การชำระเงิน | หัวหน้าฝ่ายชำระเงิน | ผู้จัดการฝ่ายชำระเงิน | นักพัฒนา 5 คน, QA 2 คน |
| ข้อมูลประจำตัว | หัวหน้าฝ่ายข้อมูลประจำตัว | ผู้จัดการฝ่ายข้อมูลประจำตัว | นักพัฒนา 3 คน, QA 1 คน |
| การวิเคราะห์ | หัวหน้าฝ่ายวิเคราะห์ | ผู้จัดการฝ่ายวิเคราะห์ | นักพัฒนา 2 คน |
ขั้นตอนที่ 4: กำหนดค่าบทบาทโปรเจกต์
สำหรับแต่ละโปรเจกต์ ให้กำหนดบทบาทตามความรับผิดชอบ:
| บุคคล | Payment Gateway API | Fraud Detection API | Auth Service API |
|---|---|---|---|
| นักพัฒนารุ่นพี่ A | ผู้ดูแลระบบ | ผู้แก้ไข | ต้องห้าม |
| นักพัฒนารุ่นพี่ B | ผู้แก้ไข | ผู้ดูแลระบบ | ต้องห้าม |
| นักพัฒนารุ่นน้อง C | ผู้แก้ไข | อ่านอย่างเดียว | ต้องห้าม |
| วิศวกร QA | ผู้แก้ไข | ผู้แก้ไข | ต้องห้าม |
| ผู้จัดการผลิตภัณฑ์ | อ่านอย่างเดียว | อ่านอย่างเดียว | ต้องห้าม |
| ผู้รับเหมา | ผู้แก้ไข | ต้องห้าม | ต้องห้าม |
ขั้นตอนที่ 5: เชิญสมาชิกด้วยบทบาทที่กำหนดค่าไว้ล่วงหน้า
เมื่อเชิญผู้ใช้ คุณสามารถกำหนดบทบาทได้ทันที:
- การเชิญเข้าทีม — เชิญเข้าทีมด้วยบทบาททีม + บทบาทโปรเจกต์เริ่มต้น
- การเชิญเข้าโปรเจกต์ — เชิญเข้าโปรเจกต์ที่เฉพาะเจาะจงด้วยบทบาทโปรเจกต์ + ถูกเพิ่มเข้าทีมโดยอัตโนมัติในฐานะสมาชิก
สำหรับผู้ทำงานร่วมกันภายนอก: ใช้การเชิญระดับโปรเจกต์ด้วย Other Projects = Forbidden เพื่อจำกัดการมองเห็นเฉพาะโปรเจกต์ที่ได้รับเชิญเท่านั้น
ขั้นตอนที่ 6: กำหนดค่า SSO และ SCIM (Enterprise)
- ตั้งค่า SAML SSO ในการตั้งค่าองค์กร
- กำหนดค่าโทเค็น SCIM จากแดชบอร์ด IdP
- แมปกลุ่ม IdP กับทีม Apidog
- ทดสอบกับกลุ่มนำร่องก่อนนำไปใช้จริง
แนวทางปฏิบัติที่ดีที่สุดสำหรับความปลอดภัยในการทำงานร่วมกันของ API
1. ใช้หลักการสิทธิ์ขั้นต่ำ
เริ่มต้นด้วยสิทธิ์ขั้นต่ำ เพิ่มตามที่จำเป็น:
- สมาชิกทีมใหม่: อ่านอย่างเดียว → เพิ่มตามความจำเป็นที่แสดงให้เห็น
- ผู้รับเหมา: ต้องห้ามสำหรับโปรเจกต์ส่วนใหญ่ → ผู้แก้ไขสำหรับโปรเจกต์ที่ได้รับมอบหมายเท่านั้น
- วิศวกร QA: ผู้แก้ไขสำหรับการทดสอบ, อ่านอย่างเดียวสำหรับข้อกำหนด
2. แยกการเข้าถึงการพัฒนาและการผลิต
สร้างโปรเจกต์หรือสาขาแยกต่างหากสำหรับการพัฒนา/การจัดเตรียม/การผลิต:
| สภาพแวดล้อม | สิทธิ์นักพัฒนา | สิทธิ์ QA | สิทธิ์ผู้ดูแลระบบ |
|---|---|---|---|
| การพัฒนา | ผู้แก้ไข | ผู้แก้ไข | ผู้ดูแลระบบ |
| การจัดเตรียม | อ่านอย่างเดียว | ผู้แก้ไข | ผู้ดูแลระบบ |
| การผลิต | ต้องห้าม | อ่านอย่างเดียว | ผู้ดูแลระบบ |
3. ใช้บทบาทที่กำหนดเองสำหรับฟังก์ชันที่เชี่ยวชาญ
อย่าบังคับให้คนทำงานในบทบาททั่วไปเมื่อการทำงานของพวกเขาเป็นเรื่องเฉพาะทาง:
- ทีมความปลอดภัย: อ่านอย่างเดียว + เข้าถึง Vault Secrets
- นักเขียนด้านเทคนิค: ผู้แก้ไขสำหรับเอกสาร, อ่านอย่างเดียวสำหรับเอนด์พอยต์
- วิศวกรประสิทธิภาพ: ผู้แก้ไขสำหรับการทดสอบ, อ่านอย่างเดียวสำหรับข้อกำหนด
4. ตรวจสอบสิทธิ์เป็นประจำทุกไตรมาส
RBAC ไม่ใช่การตั้งค่าแล้วลืม กำหนดการตรวจสอบรายไตรมาส:
- ตรวจสอบสิทธิ์ที่สะสม (role creep)
- ยืนยันว่าการเข้าถึงของผู้รับเหมาไม่ได้ขยายเกินขอบเขตโปรเจกต์
- อัปเดตบทบาทที่กำหนดเองสำหรับคุณสมบัติใหม่หรือความรับผิดชอบที่เปลี่ยนแปลง
- ลบการเข้าถึงสำหรับพนักงานที่ลาออกทันทีผ่าน SCIM
5. จัดทำเอกสารคำจำกัดความบทบาท
สร้างเอกสารที่ชัดเจนแสดง:
- แต่ละบทบาทสามารถและไม่สามารถทำอะไรได้บ้าง
- ใครควรมีบทบาทใด
- วิธีการขอเปลี่ยนแปลงบทบาท
- เส้นทางการยกระดับสำหรับการระงับข้อพิพาทการเข้าถึง
6. เปิดใช้งานการบันทึกการตรวจสอบ (Audit Logging)
แผน Enterprise มีบันทึกการตรวจสอบที่ติดตาม:
- ใครเข้าถึงอะไร
- เมื่อใดที่พวกเขาเข้าถึง
- การกระทำใดที่พวกเขาดำเนินการ
- การมอบหมายบทบาทและการเปลี่ยนแปลง
ใช้บันทึกการตรวจสอบสำหรับ:
- การรายงานการปฏิบัติตามกฎระเบียบ
- การสอบสวนเหตุการณ์ความปลอดภัย
- การวิเคราะห์การเพิ่มประสิทธิภาพสิทธิ์
การเปรียบเทียบ RBAC: Apidog เทียบกับเครื่องมืออื่นๆ
RBAC ของ Apidog เปรียบเทียบกับแพลตฟอร์มการทำงานร่วมกันของ API อื่นๆ อย่างไร?
| คุณสมบัติ | Apidog | Postman | SwaggerHub | Bruno |
|---|---|---|---|---|
| ระดับสิทธิ์ | 3 (องค์กร/ทีม/โปรเจกต์) | 2 (องค์กร/ทีม) | 2 (องค์กร/พื้นที่ทำงาน) | 1 (อิง Git) |
| บทบาทที่มาพร้อมระบบ | 12 บทบาท | 5 บทบาท | 4 บทบาท | ไม่มี (สิทธิ์ Git) |
| บทบาทที่กำหนดเอง | ✅ (Enterprise) | ✅ (Enterprise) | ✅ (Enterprise) | ❌ |
| SSO/SAML | ✅ | ✅ | ✅ | ❌ |
| การจัดเตรียม SCIM | ✅ | ✅ | ❌ | ❌ |
| การแมปกลุ่ม | ✅ | ✅ | ✅ | ❌ |
| Vault Secrets | ✅ | ✅ (Enterprise) | ❌ | ❌ |
| การแยกโปรเจกต์ | ✅ (บทบาทต้องห้าม) | จำกัด | จำกัด | อิง Git |
| การควบคุมผู้ทำงานร่วมกันภายนอก | ✅ (แขก + ต้องห้าม) | จำกัด | จำกัด | การควบคุมการเข้าถึง Git |
ข้อดีของ Apidog:
- ลำดับชั้นสามระดับ — ละเอียดกว่าสองระดับของ Postman/SwaggerHub
- บทบาทต้องห้าม — การควบคุมการไม่เข้าถึงที่ชัดเจนภายในทีม
- บทบาทแขก — ผู้ทำงานร่วมกันภายนอกพร้อมการมองเห็นที่ควบคุมได้
- การผสานรวม SCIM — การจัดเตรียม/การยกเลิกการจัดเตรียมอัตโนมัติ
- แพลตฟอร์มแบบครบวงจร — RBAC ครอบคลุมการออกแบบ, การทดสอบ, เอกสาร, การจำลอง (mocking) ในเครื่องมือเดียว
เมื่อ RBAC ของ Apidog เหมาะสมที่สุด:
- องค์กรขนาดใหญ่ที่มีทีม API หลายทีม
- ข้อกำหนดการปฏิบัติตามกฎระเบียบขององค์กร (SSO, SCIM, การตรวจสอบได้)
- ทีมข้ามสายงาน (นักพัฒนา, QA, PM, ความปลอดภัย, นักเขียน)
- ผู้ทำงานร่วมกันภายนอกที่ต้องการการเข้าถึงที่ควบคุม
- API ที่ละเอียดอ่อนที่ต้องการขอบเขตการเข้าถึงที่เข้มงวด
สรุป
การควบคุมการเข้าถึงตามบทบาท (Role-Based Access Control) เปลี่ยนการทำงานร่วมกันของ API จากความวุ่นวายไปสู่การกำกับดูแล หากไม่มี RBAC การเติบโตของทีมหมายถึงความซับซ้อนของสิทธิ์, ความเสี่ยงด้านความปลอดภัย และปัญหาการปฏิบัติตามกฎระเบียบ ด้วย RBAC ที่เหมาะสม คุณจะสามารถปรับขนาดได้อย่างมั่นใจ—เพิ่มสมาชิกทีม, ผู้รับเหมา และผู้มีส่วนได้ส่วนเสียโดยไม่สูญเสียการควบคุม
ประเด็นสำคัญ:
- ลำดับชั้นสามระดับ (องค์กร → ทีม → โปรเจกต์) ตรงกับวิธีที่ทีมจริงทำงาน
- 12 บทบาทที่มาพร้อมระบบ ครอบคลุมสถานการณ์มาตรฐานโดยไม่ต้องกำหนดค่าเอง
- บทบาทโปรเจกต์ที่กำหนดเอง ช่วยให้สิทธิ์ที่ละเอียดอ่อนสำหรับความต้องการเฉพาะทาง
- SSO และ SCIM ผสานรวมกับการจัดการข้อมูลประจำตัวขององค์กร
- Vault Secrets รวมศูนย์การจัดการข้อมูลประจำตัวด้วยการเข้าถึงตามบทบาท
- บทบาทต้องห้าม ให้การควบคุมการไม่เข้าถึงที่ชัดเจนสำหรับโปรเจกต์ที่ละเอียดอ่อน
- การแมปกลุ่ม ทำให้การกำหนดทีมเป็นไปโดยอัตโนมัติตามกลุ่ม IdP
ระบบ RBAC ของ Apidog มอบเครื่องมือให้คุณในการใช้หลักการทั้งเจ็ดนี้—ไม่ว่าคุณจะเป็นสตาร์ทอัพห้าคนหรือองค์กรพันคนก็ตาม
คำถามที่พบบ่อย: การควบคุมการเข้าถึงตามบทบาทสำหรับทีม API
การควบคุมการเข้าถึงตามบทบาท (RBAC) ในการพัฒนา API คืออะไร?
RBAC ในการพัฒนา API คือโมเดลสิทธิ์ที่กำหนดสิทธิ์การเข้าถึงให้กับบทบาท แทนที่จะเป็นผู้ใช้แต่ละคน ผู้ใช้จะได้รับบทบาท (เช่น ผู้ดูแลระบบ, ผู้แก้ไข, อ่านอย่างเดียว) และบทบาทเหล่านั้นจะกำหนดว่าพวกเขาสามารถดู, แก้ไข, ทดสอบ หรือจัดการทรัพยากร API ใดได้บ้าง ซึ่งทำให้การจัดการทีมง่ายขึ้น เพราะการเปลี่ยนบทบาทของบุคคลจะอัปเดตสิทธิ์ทั้งหมดของพวกเขาพร้อมกัน
ทำไมการทำงานร่วมกันของ API จึงต้องมีสิทธิ์สามระดับ?
ทีม API ทำงานในสามระดับ: ทั่วทั้งองค์กร (การเรียกเก็บเงิน, SSO), ทั่วทั้งทีม (การสร้างโปรเจกต์, การจัดการสมาชิก) และเฉพาะโปรเจกต์ (การแก้ไขเอนด์พอยต์, การดำเนินการทดสอบ) RBAC สามระดับจะตรงกับโครงสร้างนี้ ป้องกันการให้สิทธิ์มากเกินไป (ให้สิทธิ์มากเกินความจำเป็น) และช่องว่างของสิทธิ์ (ขาดการควบคุมที่จำเป็น)
อะไรคือความแตกต่างระหว่างผู้ดูแลองค์กรและผู้ดูแลทีม?
ผู้ดูแลองค์กรจัดการการตั้งค่าทั่วทั้งบริษัท: การเชิญสมาชิก, การสร้างทีม, การกำหนดค่า SSO, การกำหนดบทบาทที่กำหนดเอง ผู้ดูแลทีมจัดการการดำเนินการเฉพาะทีม: การเชิญสมาชิกทีม, การสร้างโปรเจกต์ภายในทีม, การกำหนดค่าทรัพยากรทีม ผู้ดูแลองค์กรมีขอบเขตกว้างกว่า; ผู้ดูแลทีมมีการควบคุมทีมที่เน้นไปที่เฉพาะส่วน
บทบาทโปรเจกต์ "ต้องห้าม" ทำงานอย่างไร?
บทบาท "ต้องห้าม" จะปฏิเสธการเข้าถึงโปรเจกต์ที่เฉพาะเจาะจงโดยชัดแจ้ง ผู้ใช้ยังคงเป็นสมาชิกทีมได้ แต่ไม่สามารถมองเห็นโปรเจกต์ที่ถูกห้ามได้เลย ซึ่งมีประโยชน์สำหรับ API ที่ละเอียดอ่อน (ระบบการชำระเงิน, บริการรักษาความปลอดภัย) ที่สมาชิกทีมบางคนไม่ควรเห็นเนื้อหาโปรเจกต์ใดๆ
บทบาททีม "แขก" มีไว้เพื่ออะไร?
บทบาทแขกมีไว้สำหรับผู้ทำงานร่วมกันภายนอก (ผู้รับเหมา, ที่ปรึกษา, ผู้ที่มาช่วยงานข้ามแผนก) ที่ต้องการเข้าถึงโปรเจกต์ แต่ไม่ควรจัดการทีม แขกไม่สามารถดูรายละเอียดสมาชิกทีม, เชิญสมาชิก หรือเข้าถึงการตั้งค่าทีมได้—พวกเขามีส่วนร่วมในโปรเจกต์ตามสิทธิ์ระดับโปรเจกต์เท่านั้น
ฉันสามารถสร้างบทบาทที่กำหนดเองพร้อมสิทธิ์เฉพาะได้หรือไม่?
ได้ แผน Apidog Enterprise รองรับบทบาทโปรเจกต์ที่กำหนดเอง คุณสามารถกำหนดบทบาทด้วยสิทธิ์ที่ละเอียดในแปดหมวดหมู่: การจัดการสาขา, การจัดการเอนด์พอยต์, การทดสอบอัตโนมัติ, การจัดการสภาพแวดล้อม, การแบ่งปันเอกสาร, การตั้งค่าโปรเจกต์, ประวัติคำขอ และการนำเข้า/ส่งออก สร้างบทบาทเช่น "วิศวกร QA" (แก้ไขการทดสอบเท่านั้น) หรือ "นักเขียนด้านเทคนิค" (แก้ไขเอกสารเท่านั้น)
การผสานรวม SSO ทำงานร่วมกับ RBAC อย่างไร?
SSO รวมศูนย์การรับรองความถูกต้องผ่านผู้ให้บริการข้อมูลประจำตัว (Okta, Microsoft Entra ID) เมื่อเปิดใช้งาน SSO สมาชิกทีมจะลงชื่อเข้าใช้ด้วยข้อมูลประจำตัวขององค์กร SSO ยังสามารถแมปกลุ่ม IdP ไปยังทีมและบทบาทของ Apidog ได้—โดยกำหนดสิทธิ์ที่ถูกต้องโดยอัตโนมัติตามการเป็นสมาชิกกลุ่ม
SCIM Provisioning คืออะไร และทำไมจึงควรใช้?
SCIM ทำให้การจัดการวงจรชีวิตของผู้ใช้เป็นไปโดยอัตโนมัติ เมื่อมีคนเข้าร่วมบริษัทของคุณ IdP จะจัดเตรียมบัญชี Apidog ของพวกเขาโดยอัตโนมัติ เมื่อมีคนลาออก SCIM จะลบการเข้าถึงของพวกเขาทันที สิ่งนี้ช่วยลดขั้นตอนการเชิญ/ลบด้วยตนเอง และป้องกันข้อมูลประจำตัวของอดีตพนักงานที่ยังคงค้างอยู่
Vault Secrets ทำงานร่วมกับ RBAC อย่างไร?
Vault Secrets จัดเก็บข้อมูลประจำตัวที่เข้ารหัส (คีย์ API, รหัสผ่าน, โทเค็น) แบบรวมศูนย์ ผู้ใช้อ้างอิงความลับด้วยชื่อโดยไม่เห็นค่าจริง RBAC ควบคุมว่าใครสามารถเพิ่ม, แก้ไข หรือเข้าถึง Vault Secrets ได้—โดยทั่วไปคือผู้ดูแลระบบและผู้แก้ไข สิ่งนี้ป้องกันการเปิดเผยข้อมูลประจำตัวผ่านไฟล์สภาพแวดล้อมหรือที่เก็บ Git
ผู้รับเหมาควรมีบทบาทสมาชิกองค์กรหรือบทบาทแขก?
โดยทั่วไปผู้รับเหมาควรเป็นแขกในระดับทีม โดยมีสิทธิ์ผู้แก้ไขหรืออ่านอย่างเดียวในระดับโปรเจกต์ ใช้การเชิญระดับโปรเจกต์ด้วย "Other Projects = Forbidden" เพื่อจำกัดการมองเห็นเฉพาะโปรเจกต์ที่ได้รับมอบหมายเท่านั้น เพื่อป้องกันการเข้าถึงพื้นที่ธุรกิจที่ไม่เกี่ยวข้อง