تشغيل OpenClaw بأمان على خادم VPS

ما هو OpenClaw، ولماذا تحصّنه أولًا

OpenClaw وكيل ذكاء اصطناعي مستضاف ذاتيًا. تشغّله على خادمك الخاص، وتصله بنموذج لغوي كبير، فيصبح قادرًا على تنفيذ أوامر shell، والتحكم في متصفح، وقراءة ملفاتك وكتابتها، والتصرف بناءً على الرسائل التي ترسلها إليه من تطبيقات المراسلة. هذه القدرة على الوصول هي بيت القصيد في الأداة كلها، وهي أيضًا كل الخطر فيها. الوكيل القادر على تنفيذ أي أمر لا يكون آمن من الخادم الذي يعمل عليه ومن الحدود التي تضعها حوله.

حقيقتان تحدّدان نبرة هذا الدليل. الأولى أن OpenClaw مصمَّم على أن تتولى أنت تحصينه؛ فنموذج الأمان فيه يضع مسؤولية سياسات الأدوات الصارمة، والعزل (sandboxing)، والأذونات الدقيقة على عاتق المُشغِّل، لا على إعداد افتراضي آمن. والثانية أن للمشروع تاريخًا أمنيًا حقيقيًا: ففي مارس 2026 جرى الكشف عن تسع مشكلات أمنية في غضون أربعة أيام، من بينها ثغرة حرجة لتصعيد الامتيازات، CVE-2026-32922، بتقييم 9.9 من 10. لا تعني أي من الحقيقتين أن عليك تجنّب OpenClaw؛ بل تعنيان ألا تشغّله بطريقة متساهلة، وهذا الدليل هو الطريقة الحذرة.

وهناك خبر جيد أيضًا. OpenClaw يتخذ عنك خيارًا آمنًا واحدًا مسبقًا: فبوابته (gateway)، وهي العملية الوحيدة التي تتحكم في كل شيء، تستمع افتراضيًا على عنوان الاسترجاع المحلي (loopback)، فلا يمكن الوصول إليها من الإنترنت ما لم تكشفها أنت بنفسك. معظم العمل أدناه هو إبقاء الوضع على هذا النحو، والحد من نطاق الضرر إن ساءت الأمور فعلًا.

امنح OpenClaw مستخدمًا محدود الصلاحيات خاصًا به

لا تُشغّل وكيلًا بحساب root أبدًا. فإن عمل OpenClaw بحساب root وحدث خطأ ما — علة برمجية، أو تعليمة سيئة، أو ثغرة مثل تلك المذكورة أعلاه — فإن الضرر لا سقف له. أنشئ مستخدم نظام مخصصًا لا يملك shell للدخول ولا صلاحيات sudo، وشغّل الوكيل بهذا المستخدم:

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

كل ما يملكه OpenClaw يقيم تحت /opt/openclaw، بملكية هذا الحساب. هذه هي الخطوة الأهم على الإطلاق، وهي المبدأ نفسه الذي يتناوله تشغيل الخدمات بمستخدم محدود الصلاحيات: الحساب الذي يعمل الوكيل تحته هو سقف ما يمكن أن يكسره.

ثبّت OpenClaw

يُوزَّع OpenClaw كحزمة npm، فثبّت Node.js أولًا إن لم يكن موجودًا على الخادم. ثبّت الحزمة تثبيتًا عامًا (global)، ما يضع الملف التنفيذي openclaw على مسار PATH لكل مستخدم، ثم نفّذ خطوة الإعداد الأولي التي تُنفَّذ مرة واحدة فقط:

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

تنفيذ الإعداد الأولي بحساب openclaw يعني أن إعدادات الوكيل تحطّ في دليله الرئيسي (home)، أي /opt/openclaw، لا في دليل root. يقدّم المشروع أيضًا مثبِّتًا عبر curl -fsSL https://openclaw.ai/install.sh | bash يقوم بالتثبيت نفسه في سطر واحد. تجاوَز الخيار --install-daemon أثناء الإعداد الأولي: فهو سيسجّل خدمة OpenClaw الخاصة به، ووحدة systemd المحصّنة التي ستبنيها أدناه أشد صرامة منها.

أبقِ البوابة على loopback، خلف جدار حماية

تربط البوابة (gateway) نفسها بالعنوان 127.0.0.1 افتراضيًا. اتركها هناك. لا يكاد يوجد سبب لنشر ذلك المنفذ على الإنترنت، وفعل ذلك يمنح أي من يعثر عليه موطئ قدم عن بُعد داخل عملية مهنتها تنفيذ الأوامر.

ضع أمام الخادم جدار حماية يرفض كل شيء افتراضيًا (default-deny) حتى لا ينكشف شيء بالخطأ:

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

وهنا فخّان ينبغي تجنّبهما. جدار الحماية الذي يغطي IPv4 فقط قد يترك الخدمة نفسها مفتوحة على مصراعيها عبر IPv6، وهذا بالضبط ثغرة جدار الحماية في IPv6 التي يقع فيها كثيرون. وإن احتجت إلى الوصول إلى البوابة من حاسوبك المحمول، فلا تفتح المنفذ. صِل إليها عبر VPN أو نفق SSH، بحيث لا يستمع الوكيل أبدًا على الإنترنت المفتوح.

اعزل أسراره

يحتاج OpenClaw إلى مفتاح API للنموذج اللغوي الذي تصله به أيًّا كان. هذا المفتاح قادر على إنفاق مالك، وعلى التصرف نيابةً عنك من خلال الوكيل، فعامِله معاملة كلمة المرور. أبقِه بعيدًا عن ملف الوحدة (unit file) وعن أي مستودع. ضعه في ملف لا يقرؤه إلا مستخدم 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

تحمّل وحدة systemd هذا الملف عبر EnvironmentFile، فيصل المفتاح إلى العملية من دون أن يظهر أبدًا في سطر أوامر، أو سجلّ، أو تاريخ الأوامر في الـshell.

شغّله كخدمة systemd محصّنة

تشغيل الوكيل تحت systemd يمنحك إعادة تشغيل تلقائية، وسجلّات نظيفة عبر journalctl، والأهم من ذلك كله، مجموعة من خيارات العزل على مستوى النواة (kernel) تقلّص ما يمكن للعملية لمسه حتى لو تعرّضت للاختراق. أهمّ هذه الخيارات لوكيل هو NoNewPrivileges حتى لا يكتسب صلاحيات جديدة أبدًا، وProtectSystem=strict حتى يصير نظام الملفات للقراءة فقط إلا حيث تسمح أنت بالكتابة، وPrivateTmp لدليل مؤقت معزول خاص به، وProtectHome حتى لا يستطيع قراءة الأدلة الرئيسية لمستخدمي النظام.

وَلِّد هنا وحدة كاملة ومحصّنة، ثم انسخها إلى /etc/systemd/system/openclaw.service:

تُشغّل الوحدة الأمر openclaw gateway، وهو العملية طويلة الأمد التي تتحكم في الوكيل؛ فإن أظهر الأمر which openclaw مسارًا مختلفًا على خادمك، عدّل ExecStart ليطابقه. الشرح الكامل لهذه التوجيهات، ولأمري daemon-reload وenable --now، موجود في تشغيل برنامج كخدمة systemd على خادم VPS. أما النسخة المختصرة بعد لصق الوحدة فهي:

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

حصّن الباب الأمامي أيضًا

خادم الوكيل لا يكون آمن من الخادم المحيط به. طبقتان إضافيتان تُتمّان العمل. انقل SSH إلى المصادقة بالمفاتيح فقط وألغِ دخول root، كما في تحصين SSH على خادم VPS، حتى لا يمكن كسر الحساب الذي تدير منه الخادم بالقوة الغاشمة. ثم أضف Fail2ban لطرد الماسحات التي تدقّ على كل منفذ عام. لا تمسّ أي من الطبقتين OpenClaw مباشرةً، لكن كلتاهما تقطعان الطرق التي قد يستخدمها مهاجم للوصول إليه.

أبقِه محدَّثًا، عن قصد

إفصاحات مارس 2026 هي أوضح حجة ممكنة للبقاء محدَّثًا. علة تصعيد الامتيازات في وكيل أخطر بكثير من مثيلتها في تطبيق ويب عادي، لأن الوكيل ينفّذ الأوامر أصلًا. راقب إصدارات المشروع، وطبّق التحديثات الأمنية بسرعة، وعامِل ترقية OpenClaw بوصفها صيانة روتينية لا أمرًا يمكن تأجيله.

ولفهم ما تحصّنه فعلًا، يستعرض بنية وكيل على طراز OpenClaw أجزاءه المتحركة، ويغطي بناء وكيل ذكاء اصطناعي خاص بك على خادم VPS الشكل العام الذي يتخذه أي وكيل.

FAQ

هل تشغيل OpenClaw على VPS عام آمن؟

يمكن أن يكون كذلك إن حصّنته. OpenClaw قوي بحكم التصميم: فهو ينفّذ أوامر shell ويتحكم في متصفح، لذلك فإن الإعداد غير الحذر خطير فعلًا، وقد سبق للمشروع أن واجه ثغرة CVE حرجة (CVE-2026-32922 في مارس 2026). ونموذج الأمان فيه يتوقع منك أنت، المُشغِّل، أن تضيف الحدود. شغّله بمستخدم محدود الصلاحيات، وأبقِ بوابته على loopback خلف جدار حماية يرفض كل شيء افتراضيًا، واعزل مفاتيح API الخاصة به، وشغّله كخدمة systemd محصّنة.

هل ينبغي أن أعرّض بوابة OpenClaw للإنترنت؟

لا. تربط البوابة نفسها بـ loopback افتراضيًا، وينبغي أن تتركها هناك. فهي العملية الوحيدة التي تتحكم في الوكيل، ولذلك فإن بوابة مكشوفة هي طريق عن بُعد إلى شيء مهنته تنفيذ الأوامر. وإن احتجت إلى الوصول إليها عن بُعد، فاستخدم VPN أو نفق SSH بدلًا من فتح المنفذ.

بأي مستخدم ينبغي أن يعمل OpenClaw؟

مستخدم نظام مخصص لا يملك shell للدخول ولا صلاحيات sudo، وليس root أبدًا. فإن تعرّض الوكيل للاختراق، يكون حساب المستخدم الخاص به سقف الضرر، لذا ينبغي ألا يملك هذا الحساب سوى ملفاته الخاصة تحت دليل مثل /opt/openclaw ولا شيء غيره.

كيف أحافظ على أمان مفاتيح API الخاصة بـ OpenClaw؟

خزّنها في ملف لا يقرؤه إلا مستخدم OpenClaw (بصلاحية 600)، وحمّله إلى الخدمة عبر EnvironmentFile الخاص بـ systemd. أبقِ المفتاح بعيدًا عن ملف الوحدة، وعن تاريخ الأوامر في الـshell، وعن أي مستودع git. بدّله إن ساورك الشك يومًا في أنه تسرّب.