Jak bezpiecznie uruchomić OpenClaw na VPS

Czym jest OpenClaw i dlaczego należy zacząć od jego zabezpieczenia

OpenClaw to samodzielnie hostowany agent AI. Uruchamia się go na własnym serwerze, łączy z dużym modelem językowym, co pozwala mu na wykonywanie poleceń powłoki, sterowanie przeglądarką, odczyt i zapis plików oraz reagowanie na wiadomości przesyłane z komunikatorów. Ten szeroki zakres możliwości stanowi główny cel narzędzia, ale jest również źródłem ryzyka. Agent zdolny do wykonywania dowolnych poleceń jest tak bezpieczny, jak serwer, na którym działa, oraz ograniczenia, które zostaną na niego nałożone.

Dwa fakty determinują podejście opisane w tym przewodniku. Po pierwsze, OpenClaw został zaprojektowany z myślą o samodzielnym zabezpieczeniu przez użytkownika. Jego model bezpieczeństwa przenosi odpowiedzialność za restrykcyjne polityki narzędzi, izolację (sandboxing) oraz precyzyjne uprawnienia na operatora, zamiast polegać na bezpiecznych ustawieniach domyślnych. Po drugie, projekt ma już za sobą poważne incydenty bezpieczeństwa: National Vulnerability Database odnotowała 199 luk CVE dla OpenClaw opublikowanych tylko w marcu 2026 roku, z czego 46 w ciągu czterech dni od 4 do 7 marca (dane zweryfikowane 13 października 2026 roku). Wśród błędów z tego miesiąca znajduje się krytyczne podniesienie uprawnień, CVE-2026-32922, ocenione na 9.9 w skali 10 i naprawione w wersji 2026.3.11. Żaden z tych faktów nie oznacza, że należy unikać OpenClaw. Oznaczają one, że nie należy uruchamiać go w sposób niedbały, a niniejszy przewodnik wskazuje sposób bezpieczny. Częścią bezpiecznego podejścia jest podjęcie decyzji, na ile agent może sobie pozwolić bez pytania o zgodę – jest to wybór, który Claude Code czyni jawnym poprzez swoje tryby uprawnień, przy czym serwer, przy którym nie siedzisz bezpośrednio, wymaga bardziej restrykcyjnych ustawień niż laptop, który masz na oku.

Są też dobre wieści. OpenClaw podejmuje już jedną bezpieczną decyzję za użytkownika: jego brama, czyli pojedynczy proces kontrolujący wszystko, domyślnie nasłuchuje na adresie loopback, więc nie jest dostępna z Internetu, chyba że celowo zostanie wystawiona. Większość poniższych działań ma na celu utrzymanie tego stanu oraz ograniczenie zasięgu ewentualnej awarii, jeśli coś pójdzie nie tak.

Nadanie OpenClaw własnego użytkownika bez uprawnień

Nigdy nie uruchamiaj agenta jako root. Jeśli OpenClaw działa jako root, a wystąpi błąd, błędna instrukcja lub luka typu CVE, podobna do wspomnianej powyżej, zakres potencjalnych szkód jest nieograniczony. Utwórz dedykowanego użytkownika systemowego bez powłoki logowania i bez dostępu do sudo, a następnie uruchom agenta na tym koncie:

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

Wszystkie zasoby należące do OpenClaw znajdują się w /opt/openclaw i są własnością tego konta. Jest to najważniejszy krok, oparty na tej samej zasadzie, co uruchamianie usług jako użytkownik bez uprawnień: konto, na którym działa agent, wyznacza górną granicę tego, co może on uszkodzić.

Instalacja OpenClaw

OpenClaw jest dystrybuowany jako pakiet npm, więc jeśli serwer go nie posiada, należy najpierw zainstalować Node.js; projekt wymaga wersji Node 24.16 lub nowszej, albo 26.1 lub nowszej. Pakiet należy zainstalować globalnie, co umieści plik binarny openclaw w zmiennej PATH dla każdego użytkownika, a następnie wykonać jednorazową procedurę konfiguracji początkowej:

sudo npm install -g openclaw@latest --allow-scripts=openclaw
sudo -u openclaw openclaw onboard

Flaga --allow-scripts=openclaw jest wymagana, ponieważ npm 12 domyślnie blokuje skrypty instalacyjne pakietów, a OpenClaw wymaga ich uruchomienia. W przypadku npm 11.15 lub starszych, które nie posiadają tej opcji, należy pominąć tę flagę. Uruchomienie konfiguracji jako użytkownik openclaw sprawia, że konfiguracja agenta trafia do jego katalogu domowego, /opt/openclaw, a nie do katalogu root. Projekt oferuje również instalator curl -fsSL https://openclaw.ai/install.sh | bash, który wykonuje tę samą instalację w jednej linii. Podczas konfiguracji należy pominąć flagę --install-daemon: zarejestrowałaby ona własną usługę OpenClaw, a tworzona poniżej wzmocniona jednostka systemd jest bardziej restrykcyjna.

Utrzymanie bramy na interfejsie loopback za firewallem

Brama domyślnie wiąże się z 127.0.0.1. Należy pozostawić to ustawienie bez zmian. Prawie nigdy nie ma uzasadnienia dla wystawiania tego portu do Internetu. Takie działanie daje każdemu, kto go odnajdzie, zdalny punkt zaczepienia w procesie, którego zadaniem jest wykonywanie poleceń.

Należy umieścić firewall z domyślną polityką odmowy (default-deny) przed serwerem, aby uniknąć przypadkowego wystawienia usług:

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

Należy unikać dwóch pułapek. Firewall obejmujący tylko IPv4 może pozostawić tę samą usługę w pełni dostępną przez IPv6, co stanowi dokładnie lukę w firewallu IPv6, na którą naraża się wiele osób. Jeśli konieczny jest dostęp do bramy z laptopa, nie należy otwierać portu. Należy połączyć się przez VPN lub tunel SSH, aby agent nigdy nie nasłuchiwał ruchu z otwartego Internetu.

Izolacja sekretów

OpenClaw wymaga klucza API dla wybranego modelu językowego. Klucz ten umożliwia wydawanie środków finansowych oraz działanie w imieniu użytkownika za pośrednictwem agenta, dlatego należy traktować go jak hasło. Nie należy umieszczać go w pliku jednostki ani w żadnym repozytorium. Należy zapisać go w pliku, do którego dostęp ma wyłącznie użytkownik 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

Jednostka systemd wczytuje ten plik za pomocą EnvironmentFile, dzięki czemu klucz trafia do procesu, nie pojawiając się w wierszu poleceń, dziennikach ani historii powłoki. Ten schemat dotyczy każdego sekretu w systemie: utwardzanie instancji Vaultwarden sprowadza się do ochrony tokena administratora i pliku kopii zapasowej, a nie samego szyfrowania, ponieważ to uprawnienia do plików decydują o tym, kto może odczytać sekret przechowywany na dysku.

Uruchomienie jako zabezpieczona usługa systemd

Uruchomienie agenta w ramach systemd zapewnia automatyczne restarty, przejrzyste logi dzięki journalctl oraz, co najważniejsze, zestaw opcji piaskownicy na poziomie jądra, które ograniczają dostęp procesu nawet w przypadku jego przejęcia. Najistotniejsze dla agenta opcje to NoNewPrivileges, aby proces nie mógł uzyskać nowych uprawnień, ProtectSystem=strict, aby system plików był tylko do odczytu poza wyznaczonymi miejscami, PrivateTmp dla odizolowanego katalogu tymczasowego oraz ProtectHome, aby uniemożliwić odczyt katalogów domowych.

Wygeneruj kompletną, zabezpieczoną jednostkę, a następnie skopiuj ją do /etc/systemd/system/openclaw.service:

Jednostka uruchamia openclaw gateway, długo działający proces sterujący agentem; jeśli which openclaw wskazuje inną ścieżkę na serwerze, dostosuj ExecStart. Pełny opis tych dyrektyw oraz daemon-reload i enable --now znajduje się w uruchamianie programu jako usługi systemd. Wersja skrócona po wklejeniu jednostki:

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

Wzmocnienie zabezpieczeń punktu wejścia

Bezpieczeństwo serwera z agentem zależy od zabezpieczenia całego systemu. Dwie dodatkowe warstwy kończą ten proces. Należy ograniczyć uwierzytelnianie SSH wyłącznie do kluczy i wyłączyć logowanie na konto root, zgodnie z instrukcją utwardzanie SSH na VPS, aby uniemożliwić ataki typu brute-force na konto administratora. Następnie należy dodać Fail2ban, aby blokować skanery sprawdzające wszystkie publiczne porty. Żadne z tych rozwiązań nie ingeruje bezpośrednio w OpenClaw, ale oba eliminują ścieżki, których atakujący mógłby użyć, aby uzyskać dostęp do usługi.

Utrzymywanie aktualności jako cel

Ujawnienia z marca 2026 roku stanowią najsilniejszy argument za utrzymywaniem aktualnego oprogramowania. Błąd eskalacji uprawnień w agencie jest znacznie poważniejszy niż w typowej aplikacji webowej, ponieważ agent już posiada uprawnienia do wykonywania poleceń. Należy monitorować wydania projektu, szybko wdrażać aktualizacje bezpieczeństwa i traktować aktualizację OpenClaw jako rutynową konserwację, a nie zadanie, które można odłożyć w czasie.

Aby zrozumieć, co dokładnie jest zabezpieczane, architektura agenta typu OpenClaw omawia poszczególne komponenty, a budowa własnego agenta AI na VPS przedstawia ogólny schemat działania każdego agenta. W przypadku uruchamiania drugiego agenta obok pierwszego, należy pamiętać, że dwie sesje Claude Code na jednym VPS mogą przekazywać sobie zadania, dlatego każda z nich wymaga własnego konta i własnych limitów, zamiast dziedziczenia uprawnień użytkownika.

FAQ

Czy uruchamianie OpenClaw na publicznym serwerze VPS jest bezpieczne?

Może być, pod warunkiem odpowiedniego zabezpieczenia. OpenClaw z założenia posiada duże uprawnienia: wykonuje polecenia powłoki i steruje przeglądarką, więc nieostrożna konfiguracja stwarza realne zagrożenie. Projekt posiada już historię krytycznej luki (CVE-2026-32922 z marca 2026 roku). Model bezpieczeństwa zakłada, że to operator nakłada ograniczenia. Uruchamiaj aplikację jako użytkownik bez uprawnień, utrzymuj bramę (gateway) na interfejsie loopback za zaporą sieciową z domyślną polityką odrzucania ruchu (default-deny), izoluj klucze API i uruchamiaj proces jako zabezpieczona usługa systemd.

Czy należy wystawiać bramę OpenClaw na dostęp z Internetu?

Nie. Brama domyślnie nasłuchuje na interfejsie loopback i należy to ustawienie zachować. Jest to jedyny proces sterujący agentem, więc wystawienie bramy tworzy zdalną ścieżkę dostępu do narzędzia, którego głównym zadaniem jest wykonywanie poleceń. Jeśli wymagany jest zdalny dostęp, należy użyć VPN lub tunelu SSH zamiast otwierać port.

Z jakimi uprawnieniami użytkownika powinien działać OpenClaw?

Z dedykowanym użytkownikiem systemowym, który nie posiada powłoki logowania ani uprawnień sudo. Nigdy nie należy używać konta root. W przypadku przejęcia agenta, konto użytkownika stanowi górną granicę możliwych szkód, dlatego powinno ono posiadać dostęp wyłącznie do własnych plików w katalogu takim jak /opt/openclaw i żadnych innych.

Jak zabezpieczyć klucze API OpenClaw?

Należy przechowywać je w pliku dostępnym do odczytu wyłącznie dla użytkownika OpenClaw (tryb 600) i ładować do usługi za pomocą dyrektywy EnvironmentFile w systemd. Klucz nie powinien znajdować się w pliku jednostki (unit file), historii powłoki ani w żadnym repozytorium git. W przypadku podejrzenia wycieku klucza, należy przeprowadzić jego rotację.