Podręcznik udostępniania Gateway

​

Wybierz model udostępniania

​

Inwentaryzacja przed wdrożeniem

• Host Gateway, użytkownika systemu operacyjnego i katalog stanu (domyślnie ~/.openclaw).
• Adres URL Gateway i tryb powiązania (gateway.bind; domyślny port 18789).
• Tryb uwierzytelniania, źródło tokenu/hasła lub źródło tożsamości zaufanego proxy.
• Każdy włączony kanał oraz informację, czy przyjmuje wiadomości prywatne, grupy lub elementy Webhook.
• Agentów dostępnych dla nadawców spoza hosta lokalnego.
• Profil narzędzi, tryb izolacji i zasady narzędzi z podwyższonymi uprawnieniami dla każdego dostępnego agenta.
• Zewnętrzne dane uwierzytelniające dostępne dla tych agentów.
• Lokalizację kopii zapasowej ~/.openclaw/openclaw.json i danych uwierzytelniających.

​

Kontrole bazowe

openclaw doctor
openclaw security audit
openclaw security audit --deep
openclaw health

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

​

Minimalna bezpieczna konfiguracja bazowa

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

​

Udostępnianie wiadomości prywatnych i grup

• Preferuj dmPolicy: "pairing" lub ścisłą listę allowFrom zamiast dmPolicy: "open".
• Nie łącz list dozwolonych zawierających "*" z szerokim dostępem do narzędzi.
• Wymagaj wzmianek w grupach, chyba że pokój jest ściśle kontrolowany.
• Ustaw session.dmScope: "per-channel-peer" (lub "per-account-channel-peer" dla kanałów z wieloma kontami), gdy wiele osób może wysyłać botowi wiadomości prywatne, aby sesje wiadomości prywatnych nie współdzieliły kontekstu.
• Kieruj współdzielone kanały do agentów z minimalnym zestawem narzędzi i bez osobistych danych uwierzytelniających.

​

Kontrole odwrotnego proxy

• Proxy musi uwierzytelniać użytkowników przed przekazaniem ruchu do Gateway.
• Zapora lub zasady sieciowe muszą blokować bezpośredni dostęp do portu Gateway.
• gateway.trustedProxies musi zawierać wyłącznie źródłowe adresy IP proxy.
• Proxy musi usuwać lub zastępować dostarczone przez klienta nagłówki tożsamości i przekazywania.
• Ustaw gateway.auth.trustedProxy.allowUsers, gdy proxy obsługuje więcej niż jedną grupę odbiorców.
• Używaj gateway.auth.trustedProxy.allowLoopback tylko w przypadku proxy działającego na tym samym hoście, gdy procesy lokalne są zaufane, a proxy kontroluje nagłówki tożsamości.

​

Przegląd narzędzi i izolacji

• Sprawdź, które sesje działają na hoście, a które w izolacji.
• Zabroń wykonywania poleceń na hoście lub wymagaj ich zatwierdzania.
• Pozostaw narzędzia z podwyższonymi uprawnieniami wyłączone, chyba że potrzebuje ich konkretny, zaufany nadawca.
• Unikaj narzędzi przeglądarki, canvas, node, cron, gateway i tworzenia sesji na otwartych lub częściowo otwartych powierzchniach komunikacyjnych.
• Ogranicz punkty montowania; unikaj ścieżek do danych uwierzytelniających, katalogu domowego, gniazda Docker i ścieżek systemowych.
• Używaj oddzielnych instancji Gateway, użytkowników systemu operacyjnego lub hostów dla istotnie różnych granic zaufania.

​

Weryfikacja po zmianach

1. Ponownie uruchom openclaw security audit --deep.
2. Potwierdź, że autoryzowane połączenie zostaje pomyślnie nawiązane.
3. Potwierdź, że nieautoryzowany nadawca lub sesja przeglądarki zostaje odrzucona.
4. Potwierdź, że dzienniki ukrywają dane poufne.
5. Potwierdź, że routing wiadomości prywatnych/grup kieruje je wyłącznie do zamierzonego agenta.
6. Potwierdź, że narzędzia o dużym wpływie wymagają zatwierdzenia lub są blokowane.
7. Udokumentuj zaakceptowane ostrzeżenia dotyczące ryzyka rezydualnego.

​

Plan wycofania zmian

{
  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. Zatrzymaj publiczne przekierowanie, Tailscale Funnel lub trasy odwrotnego proxy.
2. Zmień tokeny/hasła Gateway oraz dane uwierzytelniające powiązanych integracji.
3. Usuń "*" i nieoczekiwanych nadawców z list dozwolonych.
4. Przejrzyj ostatnie dzienniki audytu, historię uruchomień, wywołania narzędzi i zmiany konfiguracji.
5. Ponownie uruchom openclaw security audit --deep.
6. Ponownie włącz dostęp przy użyciu najwęższego modelu spełniającego wymagania przepływu pracy.

​

Lista kontrolna przeglądu

• Gateway pozostaje dostępny wyłącznie przez local loopback, chyba że istnieje udokumentowany powód zmiany.
• Dostęp spoza local loopback ma uwierzytelnianie, zabezpieczenie zaporą i nie ma bezpośredniej trasy publicznej.
• Wdrożenia z zaufanym proxy mają ściśle określone adresy IP proxy i kontrolę nagłówków.
• Wiadomości prywatne domyślnie używają parowania lub list dozwolonych, a nie otwartego dostępu.
• Grupy wymagają wzmianek lub jawnych list dozwolonych.
• Współdzielone kanały nie mają dostępu do osobistych danych uwierzytelniających.
• Sesje inne niż główna działają w trybie izolacji.
• Wykonywanie poleceń na hoście i narzędzia z podwyższonymi uprawnieniami są zabronione lub wymagają zatwierdzenia.
• Dzienniki ukrywają dane poufne.
• Krytyczne ustalenia audytu zostały usunięte.
• Kroki wycofania zmian zostały przetestowane i udokumentowane.