راهنمای ایمن‌سازی OpenClaw روی VPS

OpenClaw چیست و چرا باید ابتدا آن را ایمن‌سازی کنید

OpenClaw یک ایجنت هوش مصنوعی خود-میزبان (self-hosted) است. شما آن را روی سرور شخصی خود اجرا می‌کنید، به یک مدل زبانی بزرگ متصل می‌نمایید و این ایجنت می‌تواند دستورات shell را اجرا کند، مرورگر را کنترل نماید، فایل‌های شما را بخواند یا بنویسد و بر اساس پیام‌هایی که از اپلیکیشن‌های چت برایش می‌فرستید، عمل کند. این سطح از دسترسی، تمام هدف این ابزار و در عین حال تمام ریسک آن است. امنیت ایجنتی که می‌تواند هر دستوری را اجرا کند، تنها به اندازه امنیت سروری است که روی آن اجرا می‌شود و محدودیت‌هایی که شما برای آن تعیین می‌کنید.

دو واقعیت، لحن این راهنما را تعیین می‌کنند. نخست، OpenClaw به‌گونه‌ای طراحی شده که توسط شما ایمن‌سازی شود. مدل امنیتی آن، مسئولیت سیاست‌های سخت‌گیرانه ابزار، سندباکس کردن (sandboxing) و مجوزهای دقیق را بر عهده اپراتور می‌گذارد، نه بر عهده تنظیمات پیش‌فرض امن. دوم، این پروژه قبلاً یک رویداد امنیتی جدی را تجربه کرده است: در مارس 2026، نه مورد امنیتی در عرض چهار روز افشا شد که شامل یک نقص بحرانی ارتقای سطح دسترسی با شناسه CVE-2026-32922 با امتیاز 9.9 از 10 بود. هیچ‌کدام از این دو واقعیت به این معنا نیست که باید از OpenClaw دوری کنید. بلکه به این معناست که نباید آن را به روشی سهل‌انگارانه اجرا کنید؛ این راهنما روش دقیق و اصولی را به شما نشان می‌دهد. بخشی از این روش دقیق، تصمیم‌گیری از پیش درباره میزان اختیارات ایجنت بدون پرسش از شماست؛ انتخابی که Claude Code آن را با حالت‌های مجوز خود شفاف می‌کند، جایی که سروری که پشت آن نشسته‌اید، نیازمند تنظیمات سخت‌گیرانه‌تری نسبت به لپ‌تاپی است که مستقیماً آن را زیر نظر دارید.

خبرهای خوبی هم وجود دارد. OpenClaw یک انتخاب امن برای شما انجام داده است: gateway آن، یعنی همان تک‌فرآیندی که همه چیز را کنترل می‌کند، به‌صورت پیش‌فرض روی آدرس loopback گوش می‌دهد؛ بنابراین تا زمانی که خودتان برای در معرض قرار دادن آن اقدام نکنید، از طریق اینترنت قابل دسترسی نیست. بخش عمده‌ای از کارهای زیر، حفظ همین وضعیت و محدود کردن شعاع انفجار (blast radius) در صورت بروز مشکل است.

ایجاد یک کاربر بدون دسترسی ویژه برای OpenClaw

هرگز یک agent را با کاربر root اجرا نکنید. اگر OpenClaw با دسترسی root اجرا شود و مشکلی پیش بیاید—خواه یک باگ باشد، یک دستور مخرب یا یک CVE مانند مورد بالا—هیچ محدودیتی برای میزان خسارت وجود نخواهد داشت. یک کاربر سیستمی اختصاصی بدون shell ورود و بدون دسترسی sudo ایجاد کنید و agent را با همان کاربر اجرا نمایید:

sudo useradd --system --home /opt/openclaw --shell /usr/sbin/nologin openclaw

تمام دارایی‌های OpenClaw در مسیر /opt/openclaw قرار دارند و مالکیت آن‌ها متعلق به همان حساب کاربری است. این مهم‌ترین گام است و از همان اصلی پیروی می‌کند که در اجرای سرویس‌ها با کاربر بدون دسترسی ویژه توضیح داده شد: حسابی که یک agent با آن اجرا می‌شود، سقف توانایی آن برای ایجاد خرابی را تعیین می‌کند.

نصب OpenClaw

برنامه OpenClaw به عنوان یک بسته npm توزیع می‌شود، بنابراین اگر سرور Node.js ندارد، ابتدا آن را نصب کنید. بسته را به صورت سراسری (globally) نصب کنید تا فایل اجرایی openclaw برای همه کاربران در PATH قرار بگیرد، سپس مرحله یک‌باره راه‌اندازی (onboarding) را اجرا کنید:

sudo npm install -g openclaw@latest
sudo -u openclaw openclaw onboard

اجرای مرحله راه‌اندازی با کاربر openclaw باعث می‌شود پیکربندی عامل (agent) در دایرکتوری خانگی آن یعنی /opt/openclaw ذخیره شود، نه در دایرکتوری root. این پروژه همچنین یک نصب‌کننده curl -fsSL https://openclaw.ai/install.sh | bash ارائه می‌دهد که همین عملیات نصب را در یک خط انجام می‌دهد. در طول مرحله راه‌اندازی، از پرچم --install-daemon صرف‌نظر کنید: این پرچم سرویس اختصاصی OpenClaw را ثبت می‌کند، در حالی که unit سیستم‌عاملی (systemd unit) سخت‌گیرانه‌ای که در ادامه می‌سازید، محدودیت‌های بیشتری اعمال می‌کند.

درگاه را روی loopback و پشت فایروال نگه دارید

درگاه به‌صورت پیش‌فرض روی 127.0.0.1 گوش می‌دهد. آن را در همان وضعیت باقی بگذارید. تقریباً هیچ دلیلی برای انتشار این پورت روی اینترنت وجود ندارد؛ انجام این کار به هر کسی که آن را پیدا کند، یک جای پای از راه دور در فرآیندی می‌دهد که وظیفه‌اش اجرای دستورات است.

یک فایروال با سیاست default-deny در مقابل سرور قرار دهید تا هیچ سرویسی به‌طور تصادفی در معرض دید قرار نگیرد:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

در اینجا باید از دو دام اجتناب کرد. فایروالی که فقط IPv4 را پوشش می‌دهد، می‌تواند همان سرویس را روی IPv6 کاملاً باز بگذارد، که دقیقاً همان شکاف فایروال IPv6 است که بسیاری از افراد را گرفتار می‌کند. همچنین اگر نیاز دارید از لپ‌تاپ خود به درگاه دسترسی پیدا کنید، پورت را باز نکنید. از طریق یک VPN یا یک SSH tunnel به آن متصل شوید تا عامل (agent) هرگز روی اینترنت آزاد گوش ندهد.

ایزوله‌سازی اسرار

برنامه OpenClaw برای اتصال به هر مدل زبانی که انتخاب می‌کنید، به یک API key نیاز دارد. این کلید می‌تواند هزینه مالی برای شما ایجاد کند و از طریق عامل (agent) به جای شما عمل کند؛ بنابراین با آن مانند یک رمز عبور رفتار کنید. آن را در فایل unit یا هیچ مخزنی (repository) قرار ندهید. کلید را در فایلی بگذارید که فقط کاربر OpenClaw امکان خواندن آن را داشته باشد:

sudo install -o openclaw -g openclaw -m 600 /dev/null /opt/openclaw/openclaw.env
sudoedit /opt/openclaw/openclaw.env      # add ANTHROPIC_API_KEY=... or your model provider's key

فایل unit در systemd این فایل را با EnvironmentFile بارگذاری می‌کند، بنابراین کلید بدون اینکه در خط فرمان، لاگ‌ها یا تاریخچه shell شما باقی بماند، به پردازش می‌رسد. این الگو برای تمام اسرار موجود در سرور صادق است: یک بررسی امنیتی برای Vaultwarden خودمیزبان بیش از آنکه به رمزنگاری وابسته باشد، به توکن مدیریتی و فایل پشتیبان آن برمی‌گردد، زیرا مجوزهای فایل در نهایت تعیین می‌کنند که چه کسی می‌تواند یک راز ذخیره‌شده را بخواند.

اجرای آن به‌عنوان یک سرویس systemd امن‌سازی‌شده

اجرای agent تحت systemd، قابلیت راه‌اندازی مجدد خودکار، لاگ‌های تمیز از طریق journalctl و مهم‌تر از همه، مجموعه‌ای از گزینه‌های sandbox در سطح هسته را در اختیار شما قرار می‌دهد که حتی در صورت نفوذ به پردازش، دسترسی‌های آن را به‌شدت محدود می‌کند. گزینه‌هایی که برای یک agent بیشترین اهمیت را دارند عبارتند از: NoNewPrivileges تا پردازش هرگز نتواند امتیازات جدیدی کسب کند، ProtectSystem=strict تا سیستم فایل به‌جز در مسیرهایی که اجازه نوشتن داده‌اید، فقط‌خواندنی باشد، PrivateTmp برای داشتن یک دایرکتوری موقت ایزوله، و ProtectHome تا پردازش نتواند دایرکتوری‌های home را بخواند.

یک unit کامل و امن‌سازی‌شده را در اینجا ایجاد کنید و سپس آن را در /etc/systemd/system/openclaw.service کپی کنید:

این unit، پردازش openclaw gateway را که یک پردازش طولانی‌مدت برای کنترل agent است، اجرا می‌کند؛ اگر which openclaw مسیر متفاوتی را در سرور شما نشان می‌دهد، ExecStart را مطابق با آن تغییر دهید. راهنمای کامل این دستورالعمل‌ها و همچنین daemon-reload و enable --now در اجرای یک برنامه به‌عنوان سرویس systemd موجود است. خلاصه کار پس از جای‌گذاری unit:

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw

امن‌سازی ورودی اصلی

امنیت یک سرور واسط (agent box) به اندازه امنیت کل سروری است که آن را میزبانی می‌کند. دو لایه دیگر کار را تکمیل می‌کنند. احراز هویت SSH را به حالت فقط-کلید (key-only) تغییر دهید و ورود کاربر root را غیرفعال کنید، همان‌طور که در سخت‌سازی SSH روی VPS توضیح داده شده است؛ با این کار، حسابی که با آن سرور را مدیریت می‌کنید در برابر حملات brute-force ایمن می‌شود. سپس Fail2ban را اضافه کنید تا اسکنرهایی که تمام پورت‌های عمومی را هدف قرار می‌دهند، مسدود شوند. هیچ‌کدام از این موارد مستقیماً با OpenClaw در ارتباط نیستند، اما هر دو مسیرهایی را که یک مهاجم برای دسترسی به آن استفاده می‌کند، مسدود می‌کنند.

به‌روزرسانی هدفمند و مستمر

افشای اطلاعات در مارس 2026، روشن‌ترین دلیل برای به‌روز ماندن است. یک باگ افزایش سطح دسترسی (privilege-escalation) در یک agent، بسیار جدی‌تر از یک برنامه وب معمولی است، زیرا agent در حال حاضر دستورات را اجرا می‌کند. نسخه‌های منتشرشده (releases) پروژه را زیر نظر داشته باشید، به‌روزرسانی‌های امنیتی را به‌سرعت اعمال کنید و ارتقای OpenClaw را به‌جای کاری که باید به تعویق بیفتد، به‌عنوان بخشی از نگهداری روتین در نظر بگیرید.

برای درک اینکه دقیقاً چه چیزی را ایمن‌سازی می‌کنید، معماری یک agent به سبک OpenClaw اجزای متحرک آن را بررسی می‌کند و ساخت AI agent شخصی روی یک VPS ساختار کلی هر agent را توضیح می‌دهد. اگر در نهایت قصد دارید agent دومی را در کنار آن اجرا کنید، به یاد داشته باشید که دو نشست Claude Code روی یک VPS می‌توانند کارها را به یکدیگر محول کنند؛ بنابراین هر کدام باید حساب کاربری و محدودیت‌های خاص خود را داشته باشند و نباید دسترسی‌های شما را به ارث ببرند.

FAQ

آیا اجرای OpenClaw روی یک VPS عمومی امن است؟

اگر آن را ایمن‌سازی (harden) کنید، می‌تواند امن باشد. OpenClaw ذاتاً ابزاری قدرتمند است: دستورات shell را اجرا می‌کند و یک مرورگر را کنترل می‌کند؛ بنابراین پیکربندی بی‌دقت آن واقعاً خطرناک است. این پروژه قبلاً یک CVE بحرانی داشته است (CVE-2026-32922 در مارس 2026). مدل امنیتی آن انتظار دارد که شما به عنوان مدیر سیستم، محدودیت‌ها را اعمال کنید. آن را با یک کاربر بدون دسترسی‌های ویژه (unprivileged) اجرا کنید، gateway آن را روی loopback و پشت یک فایروال با سیاست default-deny نگه دارید، کلیدهای API آن را ایزوله کنید و آن را به عنوان یک سرویس systemd ایمن‌شده اجرا کنید.

آیا باید gateway مربوط به OpenClaw را در معرض اینترنت قرار دهم؟

خیر. gateway به‌صورت پیش‌فرض روی loopback متصل می‌شود و باید همان‌جا باقی بماند. این تنها فرآیندی است که agent را کنترل می‌کند؛ بنابراین یک gateway در معرض دید، مسیری از راه دور به چیزی است که وظیفه‌اش اجرای دستورات است. اگر نیاز دارید از راه دور به آن دسترسی داشته باشید، به‌جای باز کردن پورت، از یک VPN یا SSH tunnel استفاده کنید.

OpenClaw باید با چه کاربری اجرا شود؟

با یک کاربر سیستمی اختصاصی که shell ورود ندارد و دسترسی sudo هم ندارد؛ هرگز از root استفاده نکنید. اگر agent مورد نفوذ قرار گیرد، حساب کاربری آن سقف میزان خسارت خواهد بود؛ بنابراین آن حساب باید فقط مالک فایل‌های خودش در مسیری مانند /opt/openclaw باشد و هیچ دسترسی دیگری نداشته باشد.

چگونه کلیدهای API مربوط به OpenClaw را امن نگه دارم؟

آن‌ها را در فایلی ذخیره کنید که فقط توسط کاربر OpenClaw قابل خواندن باشد (با مجوز 600) و آن را با استفاده از EnvironmentFile در systemd به سرویس تزریق کنید. کلید را خارج از فایل unit، خارج از تاریخچه shell و خارج از هرگونه مخزن git نگه دارید. اگر به نشت کلید مشکوک شدید، آن را تغییر دهید (rotate).