راهنمای عملیاتی در معرض‌گذاری Gateway

این راهنمای عملیاتی، راهنمای گسترده‌تر امنیت را به یک چک‌لیست عملیاتی برای دسترسی راه دور و در معرض قرار گرفتن پیام‌رسانی تبدیل می‌کند.

الگوی در معرض قرار دادن را انتخاب کنید

باریک‌ترین الگویی را ترجیح دهید که نیاز گردش کار را برآورده می‌کند.

از بازفرستادن مستقیم پورت عمومی به Gateway پرهیز کنید. اگر به دسترسی عمومی نیاز دارید، یک پراکسی آگاه از هویت جلوی آن قرار دهید و پراکسی را تنها مسیر شبکه به Gateway کنید.

موجودی پیش از اجرا

پیش از تغییر bind، پراکسی، Tailscale، یا سیاست کانال، این موارد را ثبت کنید:

• میزبان Gateway، کاربر سیستم‌عامل، و دایرکتوری وضعیت.
• URL و حالت bind مربوط به Gateway.
• حالت احراز هویت، منبع توکن/گذرواژه، یا منبع هویت پراکسی مورد اعتماد.
• همه کانال‌های فعال و اینکه آیا DMها، گروه‌ها، یا webhookها را می‌پذیرند.
• عامل‌هایی که از فرستندگان غیرمحلی قابل دسترسی‌اند.
• پروفایل ابزار، حالت sandbox، و سیاست ابزارهای ارتقایافته برای هر عامل قابل دسترسی.
• اعتبارنامه‌های خارجی در دسترس آن عامل‌ها.
• محل پشتیبان برای ~/.openclaw/openclaw.json و اعتبارنامه‌ها.

اگر بیش از یک نفر می‌تواند به ربات پیام بدهد، این را اختیار ابزار واگذارشده مشترک در نظر بگیرید، نه ایزوله‌سازی میزبان برای هر کاربر.

بررسی‌های مبنا

پیش از باز کردن دسترسی، این‌ها را اجرا کنید:

openclaw doctoropenclaw security auditopenclaw security audit --deepopenclaw health

ابتدا یافته‌های بحرانی را رفع کنید. هشدارها فقط زمانی ممکن است قابل قبول باشند که برای استقرار عمدی و مستند شده باشند.

برای اعتبارسنجی CLI راه دور، اعتبارنامه‌ها را صریح ارسال کنید:

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

فرض نکنید اعتبارنامه‌های پیکربندی محلی برای یک URL راه دور صریح اعمال می‌شوند.

حداقل مبنای امن

از این شکل به‌عنوان نقطه شروع برای استقرارهای در معرض دسترسی استفاده کنید:

{  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 مشخص برای کانال اضافه کنید، یا پیش از پذیرش ترافیک راه دور Control UI یک پراکسی معکوس را فعال کنید.

مبنای سخت‌گیرانه exec.security: "deny" همه فراخوانی‌های exec را، از جمله عیب‌یابی‌های بی‌خطر، مسدود می‌کند. اگر عیب‌یابی یا فرمان‌های کم‌ریسک لازم است، این را فقط پس از انتخاب فرستندگان، عامل‌ها، فرمان‌ها، و حالت تأیید مشخصی که با مدل تهدید شما همخوان است، سست‌تر کنید.

در معرض قرار گرفتن DM و گروه

کانال‌های پیام‌رسانی سطوح ورودی غیرقابل اعتماد هستند. پیش از اجازه دادن به DMها یا گروه‌ها:

• dmPolicy: "pairing" یا فهرست‌های سخت‌گیرانه allowFrom را ترجیح دهید.
• از dmPolicy: "open" پرهیز کنید، مگر اینکه هر فرستنده مورد اعتماد باشد.
• allowlistهای "*" را با دسترسی گسترده به ابزارها ترکیب نکنید.
• در گروه‌ها mention را الزامی کنید، مگر اینکه اتاق کاملا کنترل‌شده باشد.
• وقتی چند نفر می‌توانند به ربات DM بدهند، از session.dmScope: "per-channel-peer" استفاده کنید.
• کانال‌های مشترک را به عامل‌هایی هدایت کنید که ابزارهای حداقلی دارند و اعتبارنامه شخصی ندارند.

pairing فرستنده را برای فعال کردن ربات تأیید می‌کند. این کار آن فرستنده را به یک مرز امنیتی میزبان جداگانه تبدیل نمی‌کند.

بررسی‌های پراکسی معکوس

برای پراکسی‌های آگاه از هویت:

• پراکسی باید پیش از ارسال به Gateway کاربران را احراز هویت کند.
• دسترسی مستقیم به پورت Gateway باید با دیوار آتش یا سیاست شبکه مسدود شود.
• gateway.trustedProxies باید فقط IPهای منبع پراکسی را در بر داشته باشد.
• پراکسی باید سرآیندهای هویت و forwarding ارائه‌شده توسط کلاینت را حذف یا بازنویسی کند.
• وقتی پراکسی به بیش از یک مخاطب سرویس می‌دهد، gateway.auth.trustedProxy.allowUsers باید کاربران مورد انتظار را فهرست کند.
• حالت پراکسی loopback روی همان میزبان فقط زمانی باید از allowLoopback استفاده کند که فرایندهای محلی مورد اعتماد باشند و پراکسی مالک سرآیندهای هویت باشد.

پس از تغییرات پراکسی، openclaw security audit --deep را اجرا کنید. یافته‌های trusted-proxy عمدا سیگنال بالایی دارند، چون پراکسی به مرز احراز هویت تبدیل می‌شود.

بازبینی ابزار و sandbox

پیش از در معرض قرار دادن یک عامل برای فرستندگان راه دور:

• تأیید کنید کدام نشست‌ها روی میزبان اجرا می‌شوند و کدام‌ها در sandbox.
• اجرای میزبان را رد کنید یا برای آن تأیید بخواهید.
• ابزارهای ارتقایافته را غیرفعال نگه دارید، مگر اینکه یک فرستنده مشخص و مورد اعتماد به آن‌ها نیاز داشته باشد.
• برای سطوح پیام‌رسانی باز یا نیمه‌باز، از ابزارهای مرورگر، canvas، Node، Cron، Gateway، و session-spawn پرهیز کنید.
• bind mountها را محدود نگه دارید و از مسیرهای اعتبارنامه، home، سوکت Docker، و سیستم پرهیز کنید.
• برای مرزهای اعتماد با تفاوت معنادار، از gatewayها، کاربران سیستم‌عامل، یا میزبان‌های جداگانه استفاده کنید.

اگر کاربران راه دور کاملا مورد اعتماد نیستند، ایزوله‌سازی باید از استقرارهای جداگانه بیاید، نه فقط از promptها یا برچسب‌های نشست.

اعتبارسنجی پس از تغییر

پس از هر تغییر در معرض‌سازی:

1. openclaw security audit --deep را دوباره اجرا کنید.
2. یک اتصال مجاز موفق را آزمایش کنید.
3. آزمایش کنید که یک فرستنده یا نشست مرورگر غیرمجاز رد می‌شود.
4. تأیید کنید لاگ‌ها اسرار را redact می‌کنند.
5. تأیید کنید مسیریابی DM/گروه فقط به عامل مورد نظر می‌رسد.
6. تأیید کنید ابزارهای پراثر درخواست تأیید می‌کنند یا رد می‌شوند.
7. هشدارهای باقیمانده پذیرفته‌شده را مستند کنید.

تا زمانی که تغییر فعلی در معرض‌سازی کاملا فهمیده نشده است، به تغییر بعدی نروید.

برنامه بازگشت

اگر ممکن است 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. بازفرستادن عمومی، Tailscale Funnel، یا مسیرهای پراکسی معکوس را متوقف کنید.
2. توکن‌ها/گذرواژه‌های Gateway و اعتبارنامه‌های integration آسیب‌دیده را rotate کنید.
3. "*" و فرستندگان غیرمنتظره را از allowlistها حذف کنید.
4. لاگ‌های ممیزی اخیر، تاریخچه اجرا، فراخوانی‌های ابزار، و تغییرات پیکربندی را بازبینی کنید.
5. openclaw security audit --deep را دوباره اجرا کنید.
6. دسترسی را با باریک‌ترین الگویی که نیاز گردش کار را برآورده می‌کند دوباره فعال کنید.

چک‌لیست بازبینی

• Gateway فقط روی loopback باقی می‌ماند، مگر اینکه دلیل مستندی وجود داشته باشد.
• دسترسی غیر loopback احراز هویت، دیوار آتش، و نبود مسیر مستقیم عمومی دارد.
• استقرارهای trusted-proxy دارای IPهای پراکسی و کنترل‌های سرآیند سخت‌گیرانه هستند.
• DMها به‌صورت پیش‌فرض از pairing یا allowlistها استفاده می‌کنند، نه دسترسی باز.
• گروه‌ها به mention یا allowlistهای صریح نیاز دارند.
• کانال‌های مشترک به اعتبارنامه‌های شخصی دسترسی پیدا نمی‌کنند.
• نشست‌های غیر main در حالت sandbox اجرا می‌شوند.
• اجرای میزبان و ابزارهای ارتقایافته رد می‌شوند یا پشت تأیید قرار دارند.
• لاگ‌ها اسرار را redact می‌کنند.
• یافته‌های بحرانی ممیزی رفع شده‌اند.
• مراحل بازگشت آزمایش و مستند شده‌اند.