คู่มือการเปิดเผย Gateway

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

เลือกรูปแบบการเปิดเผย

ควรใช้รูปแบบที่แคบที่สุดซึ่งตอบโจทย์เวิร์กโฟลว์

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

รายการตรวจสอบก่อนดำเนินการ

บันทึกสิ่งเหล่านี้ก่อนเปลี่ยนนโยบาย bind, proxy, Tailscale หรือ channel:

• โฮสต์ Gateway, ผู้ใช้ OS และไดเรกทอรีสถานะ
• URL ของ Gateway และโหมด bind
• โหมดการยืนยันตัวตน, แหล่ง token/password หรือแหล่งตัวตนของ trusted proxy
• channel ทั้งหมดที่เปิดใช้งานและระบุว่ายอมรับ DM, กลุ่ม หรือ webhooks หรือไม่
• เอเจนต์ที่ผู้ส่งที่ไม่ใช่ local เข้าถึงได้
• โปรไฟล์เครื่องมือ, โหมด sandbox และนโยบายเครื่องมือแบบยกระดับสำหรับเอเจนต์แต่ละตัวที่เข้าถึงได้
• ข้อมูลประจำตัวภายนอกที่เอเจนต์เหล่านั้นเข้าถึงได้
• ตำแหน่งสำรองสำหรับ ~/.openclaw/openclaw.json และข้อมูลประจำตัว

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

การตรวจสอบพื้นฐาน

รันคำสั่งเหล่านี้ก่อนเปิดการเข้าถึง:

openclaw doctoropenclaw security auditopenclaw security audit --deepopenclaw health

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

สำหรับการตรวจสอบ CLI ระยะไกล ให้ส่งข้อมูลประจำตัวอย่างชัดเจน:

openclaw gateway probe --url ws://127.0.0.1:18789 --token "$OPENCLAW_GATEWAY_TOKEN"

อย่าถือว่าข้อมูลประจำตัวใน config local จะใช้กับ URL ระยะไกลที่ระบุอย่างชัดเจน

baseline ขั้นต่ำที่ปลอดภัย

ใช้รูปแบบนี้เป็นจุดเริ่มต้นสำหรับการปรับใช้ที่เปิดเผย:

{  gateway: {    bind: "loopback",    auth: {      mode: "token",      token: "replace-with-a-long-random-token",    },  },  session: {    dmScope: "per-channel-peer",  },  agents: {    defaults: {      sandbox: { mode: "non-main" },    },  },  tools: {    profile: "messaging",    exec: { security: "deny", ask: "always" },    elevated: { enabled: false },  },}

จากนั้นค่อยขยายการควบคุมทีละอย่าง ตัวอย่างเช่น เพิ่ม allowlist ของ channel ที่เจาะจงก่อนเปิดใช้งานเครื่องมือที่เขียนได้ หรือเปิดใช้งาน reverse proxy ก่อนยอมรับทราฟฟิก Control UI ระยะไกล

baseline exec.security: "deny" ที่เข้มงวดจะบล็อกการเรียก exec ทั้งหมด รวมถึงการวินิจฉัยที่ไม่เป็นอันตราย หากต้องใช้การวินิจฉัยหรือคำสั่งที่มีความเสี่ยงต่ำ ให้ผ่อนคลายค่านี้เฉพาะหลังจากเลือกผู้ส่ง เอเจนต์ คำสั่ง และโหมดการอนุมัติที่ตรงกับโมเดลภัยคุกคามของคุณแล้ว

การเปิดรับ DM และกลุ่ม

channel การส่งข้อความเป็นพื้นผิวรับ input ที่ไม่น่าเชื่อถือ ก่อนอนุญาต DM หรือกลุ่ม:

• ควรใช้ dmPolicy: "pairing" หรือรายการ allowFrom ที่เข้มงวด
• หลีกเลี่ยง dmPolicy: "open" เว้นแต่ว่าผู้ส่งทุกคนเชื่อถือได้
• อย่ารวม allowlist "*" กับการเข้าถึงเครื่องมือแบบกว้าง
• กำหนดให้มี mention ในกลุ่ม เว้นแต่ว่าห้องจะถูกควบคุมอย่างเข้มงวด
• ใช้ session.dmScope: "per-channel-peer" เมื่อหลายคนสามารถส่ง DM ถึงบอตได้
• กำหนดเส้นทาง channel ที่ใช้ร่วมกันไปยังเอเจนต์ที่มีเครื่องมือน้อยที่สุดและไม่มีข้อมูลประจำตัวส่วนตัว

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

การตรวจสอบ reverse proxy

สำหรับ proxy ที่รับรู้ตัวตน:

• proxy ต้องยืนยันตัวตนผู้ใช้ก่อนส่งต่อไปยัง Gateway
• การเข้าถึงพอร์ต Gateway โดยตรงต้องถูกบล็อกด้วยไฟร์วอลล์หรือนโยบายเครือข่าย
• gateway.trustedProxies ต้องมีเฉพาะ IP ต้นทางของ proxy เท่านั้น
• proxy ต้อง strip หรือ overwrite header ระบุตัวตนและ forwarding ที่ client ส่งมา
• gateway.auth.trustedProxy.allowUsers ควรระบุผู้ใช้ที่คาดไว้เมื่อ proxy ให้บริการมากกว่าหนึ่งกลุ่มผู้ชม
• โหมด proxy loopback บนโฮสต์เดียวกันควรใช้ allowLoopback เฉพาะเมื่อ process local เชื่อถือได้และ proxy เป็นเจ้าของ header ระบุตัวตน

รัน openclaw security audit --deep หลังเปลี่ยน proxy ผลการตรวจสอบ trusted-proxy ตั้งใจให้มีสัญญาณสูง เพราะ proxy กลายเป็นขอบเขตการยืนยันตัวตน

การตรวจสอบเครื่องมือและ sandbox

ก่อนเปิดเผยเอเจนต์ให้ผู้ส่งระยะไกล:

• ยืนยันว่าเซสชันใดรันบน host เทียบกับ sandbox
• ปฏิเสธหรือกำหนดให้ต้องอนุมัติสำหรับ host exec
• ปิดใช้งานเครื่องมือแบบยกระดับไว้ เว้นแต่ว่าผู้ส่งที่เจาะจงและเชื่อถือได้จำเป็นต้องใช้
• หลีกเลี่ยงเครื่องมือ browser, canvas, node, cron, gateway และ session-spawn สำหรับพื้นผิวการส่งข้อความที่เปิดหรือกึ่งเปิด
• จำกัด bind mount ให้แคบ และหลีกเลี่ยงข้อมูลประจำตัว, home, Docker socket และ path ระบบ
• ใช้ gateways, ผู้ใช้ OS หรือ hosts แยกกันสำหรับขอบเขตความเชื่อถือที่แตกต่างกันอย่างมีนัยสำคัญ

หากผู้ใช้ระยะไกลไม่ได้เชื่อถือได้ทั้งหมด การแยกต้องมาจากการปรับใช้แยกกัน ไม่ใช่จาก prompt หรือ label ของเซสชันเท่านั้น

การตรวจสอบหลังการเปลี่ยนแปลง

หลังจากการเปลี่ยนแปลงการเปิดเผยแต่ละครั้ง:

1. รัน openclaw security audit --deep อีกครั้ง
2. ทดสอบการเชื่อมต่อที่ได้รับอนุญาตสำเร็จ
3. ทดสอบว่าผู้ส่งหรือเซสชันเบราว์เซอร์ที่ไม่ได้รับอนุญาตถูกปฏิเสธ
4. ยืนยันว่า log ปกปิดความลับ
5. ยืนยันว่าการกำหนดเส้นทาง DM/กลุ่มเข้าถึงเฉพาะเอเจนต์ที่ตั้งใจไว้
6. ยืนยันว่าเครื่องมือที่มีผลกระทบสูงขอการอนุมัติหรือถูกปฏิเสธ
7. บันทึกคำเตือนคงเหลือที่ยอมรับไว้

อย่าดำเนินการเปลี่ยนแปลงการเปิดเผยถัดไปจนกว่าจะเข้าใจการเปลี่ยนแปลงปัจจุบัน

แผน rollback

หาก Gateway อาจถูกเปิดเผยมากเกินไป:

{  gateway: {    bind: "loopback",  },  channels: {    whatsapp: { dmPolicy: "disabled" },    telegram: { dmPolicy: "disabled" },    discord: { dmPolicy: "disabled" },    slack: { dmPolicy: "disabled" },  },  tools: {    exec: { security: "deny", ask: "always" },    elevated: { enabled: false },  },}

จากนั้น:

1. หยุด public forwarding, Tailscale Funnel หรือเส้นทาง reverse proxy
2. หมุนเวียน token/password ของ Gateway และข้อมูลประจำตัวของ integration ที่ได้รับผลกระทบ
3. ลบ "*" และผู้ส่งที่ไม่คาดคิดออกจาก allowlists
4. ตรวจสอบ audit logs, run history, tool calls และ config changes ล่าสุด
5. รัน openclaw security audit --deep อีกครั้ง
6. เปิดใช้งานการเข้าถึงอีกครั้งด้วยรูปแบบที่แคบที่สุดซึ่งตอบโจทย์เวิร์กโฟลว์

เช็กลิสต์การตรวจทาน

• Gateway ยังคงเป็น loopback-only เว้นแต่จะมีเหตุผลที่บันทึกไว้
• การเข้าถึงแบบ non-loopback มีการยืนยันตัวตน ไฟร์วอลล์ และไม่มีเส้นทางตรงสาธารณะ
• การปรับใช้ trusted-proxy มี IP ของ proxy และการควบคุม header ที่เข้มงวด
• DM ใช้ pairing หรือ allowlists ไม่ใช่การเข้าถึงแบบเปิดเป็นค่าเริ่มต้น
• กลุ่มต้องมี mention หรือ allowlists ที่ชัดเจน
• channel ที่ใช้ร่วมกันไม่เข้าถึงข้อมูลประจำตัวส่วนตัว
• เซสชัน non-main รันในโหมด sandbox
• host exec และเครื่องมือแบบยกระดับถูกปฏิเสธหรือถูก gate ด้วยการอนุมัติ
• log ปกปิดความลับ
• ผลการตรวจสอบระดับ critical ได้รับการแก้ไขแล้ว
• ขั้นตอน rollback ได้รับการทดสอบและบันทึกไว้