ขอบเขตของผู้ปฏิบัติงาน

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

เนื้อหาที่เกี่ยวข้อง: ความปลอดภัย, โปรโตคอล Gateway, การจับคู่ Gateway, CLI สำหรับอุปกรณ์

บทบาท

ไคลเอนต์ WebSocket ของ Gateway แต่ละรายจะเชื่อมต่อด้วยบทบาทหนึ่งบทบาท:

• operator: ไคลเอนต์ระนาบควบคุม เช่น CLI, UI ควบคุม, ระบบอัตโนมัติ และ กระบวนการตัวช่วยที่เชื่อถือได้
• node: โฮสต์ความสามารถ (macOS, iOS, Android, แบบไม่มีส่วนติดต่อผู้ใช้) ที่เปิดให้ใช้ คำสั่งผ่าน node.invoke

เมธอด RPC ของผู้ปฏิบัติงานต้องใช้บทบาท operator; เมธอดที่มาจาก Node ต้องใช้บทบาท node

ระดับขอบเขต

ขอบเขต operator.* ในอนาคตที่ไม่รู้จักต้องตรงกันทุกประการ เว้นแต่ผู้เรียก จะมี operator.admin อยู่แล้ว

ขอบเขตของเมธอดเป็นเพียงด่านแรก

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

• agent ต้องใช้ operator.write สำหรับรอบการทำงานทั่วไป และใช้ operator.admin สำหรับ คำสั่งวงจรชีวิตเซสชัน /new หรือ /reset
• node.invoke ต้องใช้ operator.write สำหรับคำสั่งส่งต่อทั่วไป และ ใช้ operator.admin สำหรับ browser.proxy, fs.listDir และ terminal.upload
• talk.config ต้องใช้ operator.read; ส่วน includeSecrets: true ต้องใช้ operator.talk.secrets เพิ่มเติมด้วย

จากนั้นตัวจัดการบางรายการจะใช้การตรวจสอบที่เข้มงวดยิ่งขึ้นตามสิ่งที่ กำลังได้รับการอนุมัติหรือแก้ไข:

• device.pair.approve เข้าถึงได้ด้วย operator.pairing แต่การอนุมัติ อุปกรณ์ของผู้ปฏิบัติงานสามารถออกหรือคงไว้ได้เฉพาะขอบเขตที่ผู้เรียกมีอยู่แล้วเท่านั้น
• node.pair.approve เข้าถึงได้ด้วย operator.pairing จากนั้นจะหา ขอบเขตการอนุมัติเพิ่มเติมจากรายการคำสั่งที่ Node ซึ่งรอดำเนินการประกาศไว้
• chat.send เป็นเมธอดที่มีขอบเขตการเขียน แต่คำสั่งแชต /config set และ /config unset ต้องใช้ operator.admin เพิ่มเติมจากนั้น โดยไม่ขึ้นกับขอบเขตการส่งแชตของผู้เรียก

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

RPC ที่แก้ไขเซสชันจะได้รับอนุญาตตามขอบเขตผู้ปฏิบัติงานที่เจรจาไว้ โดยไม่ขึ้นกับ client.id หรือ client.mode ของไคลเอนต์ที่เชื่อมต่อ อัตลักษณ์ของไคลเอนต์ ยังคงส่งผลต่อนโยบายการเชื่อมต่อและการยืนยันตัวตนของอุปกรณ์ได้ แต่จะไม่ ให้หรือถอนอำนาจในการแก้ไขเซสชัน

การอนุมัติการจับคู่อุปกรณ์

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

การอนุมัติคำขอของอุปกรณ์:

• คำขอที่ไม่มีบทบาทผู้ปฏิบัติงานไม่จำเป็นต้องได้รับการอนุมัติขอบเขตผู้ปฏิบัติงาน
• คำขอบทบาทอุปกรณ์ที่ไม่ใช่ผู้ปฏิบัติงาน (เช่น node) ต้องใช้ operator.admin แม้ว่า device.pair.approve เองจะต้องใช้เพียง operator.pairing
• คำขอ operator.read, operator.write, operator.approvals, operator.questions, operator.pairing หรือ operator.talk.secrets กำหนดให้ ผู้เรียกต้องมีขอบเขตนั้นหรือ operator.admin อยู่แล้ว
• คำขอ operator.admin ต้องใช้ operator.admin
• คำขอซ่อมแซมที่ไม่ได้ระบุขอบเขตอย่างชัดเจนสามารถสืบทอดขอบเขตของโทเค็น ผู้ปฏิบัติงานที่มีอยู่ได้ หากโทเค็นนั้นมีขอบเขตผู้ดูแลระบบ การอนุมัติยังคงต้องใช้ operator.admin

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

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

การอนุมัติการจับคู่ Node

เมธอด node.pair.* แบบเดิมใช้พื้นที่จัดเก็บการจับคู่ Node แยกต่างหากที่ Gateway เป็นเจ้าของ Node แบบ WS ใช้การจับคู่อุปกรณ์ (role: node) แทน แต่ยังใช้ ชุดคำศัพท์การอนุมัติเดียวกัน ดูความสัมพันธ์ระหว่างพื้นที่จัดเก็บทั้งสองได้ที่ การจับคู่ Gateway

node.pair.approve หาขอบเขตที่ต้องใช้เพิ่มเติมจากรายการคำสั่ง ของคำขอที่รอดำเนินการ:

การอนุมัติการประกาศของ Node ไม่ได้เปิดใช้งานคำสั่งที่มีด่านรายการอนุญาต ขณะรันแยกต่างหาก ตัวอย่างเช่น การอนุมัติ Node ที่ประกาศ computer.act ต้องใช้การจับคู่ร่วมกับขอบเขตการเขียน แต่เป็นเพียงการบันทึกพื้นผิวดังกล่าว ผู้ดูแลระบบหรือเจ้าของยังคงต้องเปิดใช้งาน computer.act ขณะที่ยังเปิดใช้งานอยู่ การเรียกผ่าน node.invoke ต้องใช้ขอบเขตการเขียน แต่ไม่ต้องใช้ขอบเขตผู้ดูแลระบบ สำหรับแต่ละการดำเนินการ

การจับคู่ Node สร้างอัตลักษณ์และความเชื่อถือ แต่ไม่ได้ใช้แทน นโยบายการอนุมัติการดำเนินการ system.run ของ Node เอง

การยืนยันตัวตนด้วยข้อมูลลับร่วมกัน

การยืนยันตัวตนด้วยโทเค็น/รหัสผ่าน Gateway ที่ใช้ร่วมกันจะถือเป็นสิทธิ์เข้าถึงของผู้ปฏิบัติงาน ที่เชื่อถือได้สำหรับ Gateway นั้น พื้นผิว HTTP ที่เข้ากันได้กับ OpenAI, /tools/invoke และ ปลายทางประวัติเซสชัน HTTP จะคืนค่าชุดขอบเขตผู้ปฏิบัติงานเริ่มต้นทั้งหมดสำหรับ การยืนยันตัวตนแบบ bearer ด้วยข้อมูลลับร่วมกัน แม้ว่าผู้เรียกจะส่งขอบเขตที่ประกาศไว้ให้แคบกว่าก็ตาม

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