Gateway-Exposition · Whitelists · Skill-Audit · Heartbeats und Modell-Stufen
Kleine Teams und Plattformverantwortliche, die OpenClaw bereits installiert haben und es in eine Phase bringen wollen, in der Sie nach außen Zusagen treffen können, stoßen oft auf eine andere Engstelle als beim ersten Start: Das Gateway lauscht zu weit, es gibt zu viele Kanäle parallel, Skills und Skripte sind nicht auditierbar, und Heartbeats verbrennen Token-Budgets. Dieser Artikel ordnet aus Produktionssicht eine minimale Topologie mit klaren Geheimnisgrenzen, eine Konvergenztabelle für die Expositionsfläche (Bind-Adresse, Reverse Proxy, TLS), sechs Schritte für ein gestaffeltes Mehrkanal-Rollout, eine Checkliste für Skills und Automatisierungsskripte sowie steuerbare Parameter für Heartbeats und Modell-Stufen, die sich in Konfigurationsdateien und Change-Tickets schreiben lassen. Installations- und Doctor-Baselines finden Sie in Installation und Gateway-Fehlerbehebung; Dauerbetrieb und 24/7-Disziplin in OpenClaw rund um die Uhr in der Cloud; Fernzugriff und Übergaben in SSH versus VNC für Remote-Mac-Übergaben.
Der Weg von „läuft bei mir“ zu „wir gehen live“ tauscht die Diskussion von Feature-Listen gegen eine Verantwortungskarte: Wer startet den Gateway-Prozess, auf welcher Schnittstelle lauscht er, welche Credentials nutzt jeder Kanaladapter, welche Pfade dürfen Skills beschreiben, und wohin fließen Audit-Logs mit Aufbewahrungsfrist. Ohne diese Karte wirken Vorfälle wie „das Modell ist plötzlich langsam“ oder „Telegram antwortet nicht“, obwohl die Ursache eine fehlende Whitelist oder ein gemeinsam genutzter Bot-Token zwischen zwei Kanälen ist.
Fünf Lücken tauchen in Reviews ständig auf: mündlich als erledigt markiert, in der Praxis offen. Schreiben Sie sie als Checkliste und verknüpfen Sie sie mit Installations- und Doctor-Leitfaden, damit Prozess- und Parserfehler von Produktions-Exposition und Identitätsmodell getrennt bleiben.
Gateway und Dashboard nicht getrennt: Wenn Verwaltungs-UI und Nachrichteneingang dieselbe Bind-Adresse teilen, reicht ein Fehler, um Debug-Endpunkte und Webhooks gemeinsam zu exponieren. Produktion braucht zwei Rollen: „nur intern“ und „nur über Reverse Proxy“, jeweils mit eigenem Abnahmeprotokoll.
Geteilte Geheimnis-Pools je Kanal: Slack-, Discord- und Telegram-Tokens in einem Umgebungsblock erschweren Rotationen: Eine Zeile wird vergessen, Callbacks zeigen auf alte Hosts. Benennen Sie Geheimnisse kanalspezifisch, weisen Sie Rotationsverantwortliche zu und halten Sie Smoke-Tests je Adapter fest.
Fehlender Arbeitsbereich und Skill-Sandkasten: Ohne erlaubte Schreibpfade kann Prompt-Drift sensible Verzeichnisgrenzen überschreiten. Listen Sie erlaubte Wurzeln, testen Sie in Staging mit einem read-only-Benutzer und dokumentieren Sie Abweichungen.
Keine Kontingent-Sicht auf ausgehende LLM- und Tool-Aufrufe: Wenn Heartbeats, interaktive Chats und Batch-Jobs dasselbe API-Kontingent teilen, kollidieren Rate-Limits und Kosten. Führen Sie Modell-Stufen und getrennte Schlüssel oder Budgets.
Leere Strategie zu Logs und Löschfristen: Wenn Aufsicht oder Kundinnen fragen, wer welche Anweisung auslöste, fehlen stabile Request-IDs und Kanal-zu-Identität-Mappings. Legen Sie Zweck, Speicherorte, Aufbewahrung, Zugriffsrollen und Pseudonymisierung fest; im europäischen Kontext sollten Sie Datenminimierung, Zweckbindung und Löschkonzepte dokumentieren, insbesondere wenn Protokolle Inhalte aus Chat, Dateianhängen oder Bildschirmstreams enthalten können.
Nach diesen Punkten ist klar, ob Sie primär IP- und Portflächen oder vor allem menschliche und botseitige Identitäten schließen müssen. Das nächste Kapitel fasst die technische Seite in einer Gate-Tabelle zusammen.
Ein verbreiteter Fehler 2026 ist, das Gateway an 0.0.0.0 zu binden, weil Remote-Debug bequem wirkt, während das Dashboard-Passwort nebenbei in Startparametern landet. Scanner und Credential-Stuffing interessieren sich nicht für Pilotstatus. Solider Pfad: Prozess lauscht auf Loopback oder privates RFC1918-Segment, ein kontrollierter Reverse Proxy terminiert TLS, setzt Rate-Limits und schreibt Zugriffslogs, Whitelists begrenzen teure Werkzeugaufrufe.
Die Tabelle eignet sich als Ticket-Vorlage: Jede Zeile braucht Verantwortliche und einen Nachweis (Screenshot, Config-Hash). Für Fernzugriff und Tunnel lesen Sie SSH versus VNC, damit Betriebshandbuch und Agent-Automation nicht um dieselbe Port-Erzählung konkurrieren. Aus DSGVO-Sicht gehört zu TLS und Protokollen auch die Klärung, welche personenbezogenen Daten in Zugriffslogs landen, wer sie verarbeitet und ob Dienstleister als Auftragsverarbeiter gebunden sind; VNC- oder Bildschirmübertragungen können Inhalte Dritter erfassen, die Sie vorab klassifizieren und ggf. filtern sollten.
| Prüfpunkt | Empfohlene Produktionshaltung | Typisches Warnsignal | Abnahme |
|---|---|---|---|
| Bind-Adresse | 127.0.0.1 oder privates Segment; kein Default auf allen Schnittstellen | Fremde Sonden in öffentlichen Scan-Logs | ss oder lsof gegen Konfiguration; Übereinstimmung mit allow-from am Proxy |
| Reverse Proxy | Einheitliches TLS, HSTS, Verbindungs- und Body-Limits | Große Uploads oder Callbacks beenden Node | Lasttest auf Webhook-Pfade, Timeouts prüfen |
| Zertifikate und Kette | Unternehmens-MITM separat vertrauen; Renewal-Alarm | Sporadische TLS-Handshake-Fehler | curl und openssl s_client parallel |
| Verwaltungsfläche isoliert | Dashboard nur über VPN oder Zero Trust | Dashboard von externen IPs erreichbar | Negativtest aus nicht autorisierten Netzen |
| Whitelist und Raten | Autorisierung nach Nutzer-ID, Workspace oder signiertem Token | Jede Absenderkennung darf teure Tools starten | Tests mit gefälschten Absendern |
Sicherheit ist nicht nur ein weiteres Passwort, sondern drei getrennte Netze für Verwaltung, Nachrichten und Modell-Ausgang, jeweils mit eigener Abnahme.
Hier geht es um Orchestration: Wenn der zweite Kanal aktiv wird und der erste zuckt, liegen Routing- oder Geheimnisprobleme vor, nicht die Doctor-Ausgabe vom ersten Tag. Strategie: pro neuem Adapter nur eine Konfigurationsklasse ändern, in Staging echte Webhook-Stichproben abspielen. Entwicklung darf locker sein; Produktion braucht strengere Whitelists, kürzere Token-Laufzeiten und Log-Level info statt debug.
Ohne grüne Einzelkanal-Baseline aus Installations-Checkliste mischen sich Parserfehler und Routerfehler in einem Stream. Erst Einzelkanal stabilisieren, dann die sechs Schritte.
Kanalliste einfrieren: Namen der Messenger und Webhooks, Owner, erwartete Peak-Last; nicht gelistete Eingänge bleiben zu.
Service-Identität je Kanal: Keine Token-Sharing mit Privatkonten; Bot-Credentials im Secret-Store mit Feld-IDs dokumentieren.
Getrennte Callback-Hosts: Staging- und Produktions-Webhooks auf verschiedene Domains, damit Testtraffic nicht in Live-Sessions landet.
Smokes je Kanal: Text, Anhang, Slash-Befehl; Request-ID und Latenz protokollieren.
Parallelität und Queue-Caps: Obergrenzen für gleichzeitige Sessions und klare Drop-Strategien, damit LLM-Konten bei Peaks nicht kollabieren.
Rollback-Übung: Einzelnen Kanal abschalten, prüfen dass andere unberührt bleiben; Config-Diff archivieren.
export OPENCLAW_GATEWAY_BIND=127.0.0.1 export OPENCLAW_PUBLIC_BASE_URL=https://hooks.example.com export OPENCLAW_CHANNEL_ALLOWLIST=team-alpha,team-beta export OPENCLAW_LOG_LEVEL=info openclaw gateway start
Hinweis: Platzhalter ersetzen; nach Änderungen in Staging erneut Kanal-Smokes fahren, bevor das Produktionsfenster startet.
AgentSkills und eigene Skripte verwandeln OpenClaw von Chatbot in Operator mit Systemzugriff; Lieferkettenrisiken wandern damit in die Produktion. Ziel ist ein wiederholbares Gate: deklarierte Rechte, feste Netz-Ausgänge, sichtbare Shell-Aufrufe, nachvollziehbare Updates. Vollständiges Zeilenlesen jedes Repos ist selten nötig; wiederholbare Kriterien schon.
Die Tabelle ist für Plattformteams gedacht, die Häkchen setzen. Fehlt eines, bleibt der Skill in Staging oder auf read-only-Arbeitswurzeln.
| Auditgegenstand | Prüfinhalt | Maßnahme bei Fail |
|---|---|---|
| Skill-Metadaten | Name, Version, Herkunft, deklarierte Tools und Pfad-Whitelist | Auto-Updates sperren; Signatur oder interner Fork verlangen |
| Netzausgang | Externe APIs, feste Domain-Liste | Egress-Proxy-ACL oder interner Spiegel |
| Dateisystem | Schreibpfade innerhalb der Workspace-Wurzel | Separater OS-Benutzer oder eingeschränkter Pfad |
| Subprozesse | Versteckte curl, bash, git-Aufrufe | Explizit deklarieren und im Code Review verbindlich prüfen |
| Geheimnisse | Nur aus Umgebung oder Secret-Store, keine Hardcodes | Merge ablehnen und auf Secret-Referenzen umstellen |
| Update-Kanal | Herleitbarer Ursprung, Prüfsummen | Version einfrieren; nur interne Artefakte |
Achtung: Community-Skills per Ein-Klick auf Produktionsknoten ohne Audit sind für Pilots okay, nicht aber vor externen SLA-Zusagen. Stufen Sie auf kontrollierte Releases um.
Teure Unfälle entstehen oft durch doppelte Heartbeats und doppelte Syncs: Cron, Kanal-Polling und interne Timer laufen parallel, Logs nennen alles „sync“. Drei Leitplanken helfen Finance und Engineering auf einer Seite: Sie ersetzen keine Cloud-Rechnung, machen aber „zu teuer“ messbar.
| Aufgabentyp | Empfohlene Stufe | Frequenz-Obergrenze | Metrik |
|---|---|---|---|
| Kanal-Gesundheit | Billiges Modell oder reiner HTTP-Check | Subminütlich nur mit Freigabe | Fehlerrate, P95-Latenz |
| Zeitgesteuerte Summaries | Mittleres Kontextfenster | An Business-Tageswechsel koppeln | Output-Länge, Retries |
| Interaktiver Chat | Hauptmodell hoher Qualität | Parallel-Session-Cap | Token-Zeitreihe je Session |
| Tool-lastig | Starkes Reasoning oder langer Kontext | Nur mit Whitelist-Nutzerinnen | Verteilung der Tool-Aufrufe |
Wenn diese Parameter ins Change- und On-Call-Handbuch wandern, wird stabiler Knoten zur Voraussetzung: Schlafmodus und Ad-hoc-Updates verzerren Heartbeats und Alarme. Prozessüberwachung, Ports und Log-Rotation beschreibt Dauerbetrieb in der Cloud; für Kapazität und Laufzeitentscheidungen nutzen Sie Mietpreise und Bestellung. Verbindungs- und Portfragen klären Sie zuerst im Hilfezentrum.
Sicherheit: Modell-Stufen nicht nur im Chat ankündigen; Ticket mit Config-Diff, damit nächtliche Änderungen sichtbar bleiben.
Gegenüber geteilten Laptops und wechselnden Büronetzen sind exklusive, regional wählbare Cloud-Mac-Knoten leichter unter SLA zu halten: Gateway, Kanäle und Skill-Audits sitzen auf einem stabilen Untergrund, während lokale Maschinen Ruhezustand, Dialoge und Mehrbenutzer-Sitzungen mitbringen. Teams, die OpenClaw produktionsreif machen und Exposition wie Token-Kosten steuern wollen, profitieren typischerweise von VpsMesh Mac Mini Cloud-Miete: natives Apple Silicon, durchgehende Verfügbarkeit, flexible Laufzeiten, damit Engineering an Whitelists, Heartbeats und Modell-Stufen arbeitet statt an Maschinenzuständen.
Ergänzend zur Technik sollten Betriebs- und Datenschutzrollen abstimmen, welche Chat-Inhalte in Logs und Traces landen, wie lange sie aufbewahrt werden und wie Widerruf oder Löschanfragen technisch unterstützt werden, wenn personenbezogene Daten aus Nachrichtenkanälen verarbeitet werden. Eine klare Trennung zwischen technischen Debug-Logs und geschäftlichen Nachweisen reduziert spätere Korrekturaufwände und erleichtert Nachweise gegenüber internen und externen Prüferinnen.
Ein Bind an alle Schnittstellen vergrößert die Scanfläche für Verwaltungs- und Nachrichteneingänge. Bevorzugen Sie Loopback oder private Netze, setzen Sie Reverse Proxy und TLS ein und ergänzen Sie Whitelists. Fernzugriff lesen Sie in SSH versus VNC.
Zuerst Identität und Geheimnisse: getrennte Tokens je Kanal, Rotationsverantwortliche und konsistente Audit-Felder, danach Routing verfeinern. Installationsbasis in Installations-Checkliste.
Pakete auf Mietpreise, Regionen und Bestellflow auf Bestellung; SSH- und VNC-Stichworte im Hilfezentrum, bevor Sie ein Ticket öffnen.