راهنمای عملیاتی در معرض قرار دادن Gateway

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

انتخاب الگوی دسترسی

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

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

فهرست پیش از اجرا

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

• میزبان Gateway، کاربر سیستم‌عامل و دایرکتوری وضعیت (پیش‌فرض ~/.openclaw).
• نشانی Gateway و حالت اتصال (gateway.bind؛ درگاه پیش‌فرض 18789).
• حالت احراز هویت، منبع توکن/گذرواژه یا منبع هویت پراکسی مورداعتماد.
• همه کانال‌های فعال و اینکه آیا پیام‌های مستقیم، گروه‌ها یا Webhookها را می‌پذیرند.
• عامل‌هایی که فرستندگان غیرمحلی می‌توانند به آن‌ها دسترسی داشته باشند.
• پروفایل ابزار، حالت سندباکس و سیاست ابزارهای دارای دسترسی ارتقایافته برای هر عامل قابل‌دسترسی.
• اعتبارنامه‌های خارجی در دسترس آن عامل‌ها.
• محل پشتیبان‌گیری از ~/.openclaw/openclaw.json و اعتبارنامه‌ها.

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

بررسی‌های پایه

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

openclaw doctoropenclaw security auditopenclaw security audit --deepopenclaw health

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

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

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

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

حداقل خط‌مبنای امن

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

{  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 },  },}

هر بار تنها یک کنترل را گسترش دهید: پیش از فعال کردن ابزارهای دارای قابلیت نوشتن، فهرست مجاز یک کانال مشخص را اضافه کنید، یا پیش از پذیرش ترافیک راه دور رابط کنترل، یک پراکسی معکوس را فعال کنید.

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

دسترسی پیام مستقیم و گروه

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

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

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

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

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

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

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

بازبینی ابزار و سندباکس

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

• مشخص کنید کدام نشست‌ها روی میزبان و کدام‌یک در سندباکس اجرا می‌شوند.
• اجرای فرمان روی میزبان را رد کنید یا برای آن تأیید الزامی کنید.
• ابزارهای دارای دسترسی ارتقایافته را غیرفعال نگه دارید، مگر اینکه فرستنده‌ای مشخص و مورداعتماد به آن‌ها نیاز داشته باشد.
• برای سطوح پیام‌رسانی باز یا نیمه‌باز، از ابزارهای مرورگر، بوم، node، cron، gateway و ایجاد نشست خودداری کنید.
• اتصال‌های mount را محدود نگه دارید؛ از مسیرهای اعتبارنامه، خانه، سوکت Docker و سیستم خودداری کنید.
• برای مرزهای اعتماد با تفاوت اساسی، از Gatewayها، کاربران سیستم‌عامل یا میزبان‌های جداگانه استفاده کنید.

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

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

پس از هر تغییر در دسترسی:

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

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

• Gateway همچنان صرفاً روی loopback باقی می‌ماند، مگر اینکه دلیلی مستند وجود داشته باشد.
• دسترسی غیر loopback دارای احراز هویت و دیوار آتش است و مسیر مستقیم عمومی ندارد.
• استقرارهای پراکسی مورداعتماد دارای IPهای سخت‌گیرانه پراکسی و کنترل سرآیند هستند.
• پیام‌های مستقیم به‌طور پیش‌فرض از جفت‌سازی یا فهرست‌های مجاز استفاده می‌کنند، نه دسترسی باز.
• گروه‌ها به ذکر نام یا فهرست‌های مجاز صریح نیاز دارند.
• کانال‌های مشترک به اعتبارنامه‌های شخصی دسترسی ندارند.
• نشست‌های غیر اصلی در حالت سندباکس اجرا می‌شوند.
• اجرای فرمان روی میزبان و ابزارهای دارای دسترسی ارتقایافته رد می‌شوند یا به تأیید نیاز دارند.
• گزارش‌ها اطلاعات محرمانه را می‌پوشانند.
• یافته‌های بحرانی ممیزی برطرف شده‌اند.
• مراحل بازگشت آزمایش و مستند شده‌اند.