راهنمای عملیاتی در معرض‌گذاری 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 و ایجاد نشست خودداری کنید.
• اتصال‌های پوشه‌ای را محدود نگه دارید؛ از مسیرهای اعتبارنامه، پوشه خانه، سوکت 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 همچنان فقط روی local loopback باقی می‌ماند، مگر اینکه دلیل مستندی وجود داشته باشد.
• دسترسی خارج از local loopback دارای احراز هویت و دیوار آتش است و مسیر عمومی مستقیمی ندارد.
• استقرارهای پراکسی مورداعتماد دارای نشانی‌های IP سخت‌گیرانه برای پراکسی و کنترل سرآیندها هستند.
• پیام‌های خصوصی به‌طور پیش‌فرض از جفت‌سازی یا فهرست‌های مجاز استفاده می‌کنند، نه دسترسی باز.
• گروه‌ها به اشاره یا فهرست‌های مجاز صریح نیاز دارند.
• کانال‌های مشترک به اعتبارنامه‌های شخصی دسترسی ندارند.
• نشست‌های غیر اصلی در حالت محیط ایزوله اجرا می‌شوند.
• اجرای فرمان روی میزبان و ابزارهای دارای دسترسی ارتقایافته ممنوع یا مشروط به تأیید هستند.
• گزارش‌ها اطلاعات محرمانه را پنهان می‌کنند.
• یافته‌های بحرانی ممیزی برطرف شده‌اند.
• مراحل بازگشت آزمایش و مستند شده‌اند.