Tages-Archive: Februar 6, 2026

OpenClaw sicher betreiben: Zero Trust statt VPN

OpenClaw sicher betreiben: Eine pragmatische Zero-Trust-Referenzarchitektur mit Access, Policy-Gateway und „Allowed Actions“ für kontrollierbare AI-Agents AI-Agents können inzwischen mehr als „antworten“. Sie lösen Aktionen aus: Inhalte ändern, Tickets erstellen, Integrationen triggern, Daten abfragen. Genau darin liegt der Produktivitätsgewinn – und genau deshalb müssen wir Sicherheit neu denken. Denn mit Agenten bekommt „AI“ plötzlich Hände. Und sobald ein System handeln darf, ist nicht mehr das Modell der entscheidende Risikofaktor, sondern die Zugriffsschicht: Identitäten, Berechtigungen, Token-Lebenszyklen – und die Frage, welche Aktionen technisch überhaupt erlaubt sind.   Warum Agenten „anders“ sind: Identität + Zugriff + Aktion Ein klassisches System liefert Daten oder nimmt Eingaben an. Ein Agent kombiniert drei Dinge, die zusammen kritisch werden: Identität (Service Account / Token / Zertifikat) Zugriff (Netzwerk + APIs + interne UIs) Aktion (create/update/delete, Trigger, Automatisierung) Damit wird aus „AI“ faktisch ein privilegierter technischer Benutzer – nur schneller, skalierbarer und schwerer zu überblicken, wenn keine Leitplanken existieren. Das Risiko sitzt deshalb selten im Modell, sondern in Rechten, Tokens, Scope und erlaubten Aktionen.   Kurz eingeordnet OpenClaw ist frühe Software. Schutzschichten wie Zero Trust, Gateways und Allow-Lists machen ein Setup kontrollierbarer, ersetzen aber keine sichere Softwareentwicklung, keine Härtung, keine Updates und keine saubere Berechtigungsarbeit. Der Beitrag ist deshalb kein Tool-Pitch, sondern ein architektonisches Referenzmodell: Cloudflare eignet sich als anschauliches Beispiel (Tunnel/Access/Worker), die Muster funktionieren aber genauso mit anderen ZTNA- und Gateway-Stacks. In diesem Artikel zeige ich ein Referenzmodell, mit dem Sie Agenten kontrollierbar machen: vendor-agnostisch, pragmatisch und auditierbar – ideal für Piloten und Enterprise-Umgebungen mit Compliance-Anspruch. Was Sie erwartet: Was kann alles schiefgehen? Threat Model in 90 Sekunden: Over-permissioning (zu breite Rechte) Der Agent bekommt „zur Sicherheit“ globale Rechte (Admin-Scopes, zu viele Apps/Endpoints). Ergebnis: Ein Fehler oder Missbrauch hat maximalen Blast Radius. Secret Sprawl (Tokens verlieren ihren Kontext) Nicht die Existenz von .env-Dateien ist das Problem. Eine .env kann völlig sauber sein, wenn sie nicht committet wird, nur zur Runtime lokal genutzt wird und Rotation/Entzug geregelt ist. Problematisch wird es, wenn Secrets: in Code oder Configs landen, die verteilt oder versioniert werden in Logs, Debug-Outputs oder Crashdumps auftauchen im Agent-Kontext (Prompts, Memory, „Skill-Inputs“) wiederverwendet werden langlebig sind und nie rotiert/entzogen werden in Skills/Extensions ohne Review-Prozess stecken Prompt/Action Injection (Agent wird „überredet“) Agenten konsumieren Kontext aus Tickets, E-Mails, Webseiten, Dokus. Angreifer können Inhalte so platzieren, dass der Agent zu falschen Aktionen gedrängt wird („mach X“, „poste Y“, „exfiltriere Z“). Supply-Chain (Skills/Extensions) Sobald ein Agent ein Ökosystem an Skills/Extensions nutzt, entsteht ein Supply-Chain-Risiko: Erweiterungen können unerwünschte Aktionen auslösen oder Sicherheitsannahmen unterlaufen. ⚠️ Wichtig:  Agents sind IAM- und Governance-Projekte – nicht nur AI-Projekte. Zielbild: Zero Trust für Agenten (statt “Agent im LAN”) VPN löst vor allem Netzwerkzugang („du bist drin“). Zero Trust/Access löst App- und Request-Zugang („du darfst genau diese Anwendung, unter diesen Bedingungen, mit Protokollierung“). Ein robustes Zielbild für Agenten umfasst: Outbound-only Connectivity: keine offenen Inbound-Ports, Verbindung wird von innen initiiert Identity-first: jede Anfrage wird identitätsbasiert geprüft Least Privilege: minimaler Scope, minimale Endpoints, minimale Aktionen Policy Enforcement: „Allowed Actions“ technisch erzwingen (nicht nur dokumentieren) Audit-by-default: nachvollziehbare Logs/Events pro Action Fast Revocation: Tokens/Access in Minuten entziehbar (Kill Switch) Wichtige Einordnung: Diese Schichten machen ein Setup kontrollierbarer – sie machen aber keine unsichere Software automatisch sicher. Härtung, Updates, sichere Defaults und Rechtekonzepte bleiben Pflicht. Referenzarchitektur für Compliance Die 3 Ebenen der Kontrolle Die folgenden Ebenen sind ein Referenzmodell. Die genannten Komponenten sind Beispiele – die Muster funktionieren unabhängig vom Hersteller. Warum diese 3 Ebenen? Zero-Trust-Architekturen zielen darauf ab, autorisierten Zugriff auf Anwendungen/Services/Daten auf Basis definierter Policies durchzusetzen – nicht pauschal „Netzzugang = Vertrauen“. Die Ebenen trennen sauber Exponierung, Identität/Policy und erlaubte Aktionen. Ebene 1: Exposure Layer (Outbound-only Publishing / „keine Inbound-Exponierung“) Ziel: Den Agent-Endpoint (UI/API) nicht direkt öffentlich erreichbar machen, sondern kontrolliert veröffentlichen – ohne klassische Inbound-Portfreigaben. ✅ Leistet: Reduziert Angriffsfläche (kein „offener Dienst“ am Perimeter) Schafft einen klaren Eintrittspunkt, der überwacht und abgeschaltet werden kann In vielen Setups „Outbound-only Connector“: der Dienst baut die Verbindung von innen nach außen auf ❌ Leistet nicht: Keine Authentifizierung/Autorisierung – das kommt erst in Ebene 2 Keine Absicherung gegen Schwachstellen in OpenClaw selbst (frühe Software bleibt frühe Software) Praxis-Notiz: Bei Outbound-Connector/Tunnel-Modellen müssen Outbound-Regeln passen. Bei Cloudflare Tunnel ist z. B. Port 7844 für TCP und UDP relevant (HTTP/2 bzw. QUIC); wenn UDP blockiert ist, fällt der Betrieb typischerweise auf HTTP/2/TCP zurück. Umsetzbar mit: Cloudflare Tunnel (Outbound-only Connector) Alternativ: andere ZTNA-Publisher / Reverse-Proxy-Setups / Private Access Lösungen (vendor-agnostisch) Ebene 2: Identity & Policy Gate (ZTNA / Access Layer) Ziel: Zugriff auf den Agent-Endpoint identitätsbasiert steuern (User/Service), inklusive Policies, Protokollierung und schnellem Entzug. ✅ Leistet: „Identity-first“ Zugriff: wer darf wann worauf (Rollen/Groups/Policies) Für Automationen/Services: Service-Identitäten statt Shared Credentials Kill-Switch auf Access-Ebene: Zugriff in Minuten entziehbar (Token widerrufen/rotieren) ❌ Leistet nicht: Keine fachliche Autorisierung in Zielsystemen (z. B. Confluence-Rechte) Keine Begrenzung der konkreten Agent-Aktionen (das ist Ebene 3) Praxis-Notiz: Wenn Sie automatisierte Zugriffe zulassen, sind kurzlebige Service-Credentials und ein definierter Widerrufsprozess zentral. Bei Cloudflare Access sind Service Tokens genau dafür gedacht und können vor Ablauf durch Löschen widerrufen werden. Umsetzbar mit: Cloudflare Access (Service Tokens) Alternativ: andere ZTNA/Access-Gates (SSO/MFA/Policy-Engines), unabhängig vom Hersteller Ebene 3: Policy-Gateway (Allowed Actions Enforcer) Ziel: Nicht nur „wer darf rein“, sondern „was darf der Agent technisch tun“ – durch harte Schranken vor den Ziel-APIs. ✅ Leistet: Reduziert Blast Radius (minimiert Missbrauchs-/Fehlerfolgen) Verhindert offensichtlichen Missbrauch (z. B. verbotene Endpunkte/Methoden) Erzwingt technische Leitplanken, z. B.: Path/Method Allow-Lists (nur definierte Endpunkte, kein Admin/Bulk) Request-Validierung (Schema, Content-Type, Größenlimits, erlaubte Felder) Rate Limits / Abuse Controls (Write-Spikes, ungewöhnliche Muster) Audit-Events pro Aktion (Rule-ID, Target, Zeit, Ergebnis) ❌ Leistet nicht: Kein vollständiger Ersatz für fachliche Autorisierung: Confluence-APIs sind generisch; ein Gateway sieht Pfade/Payloads, aber oft nicht den gesamten fachlichen Kontext Kein Ersatz für saubere Confluence-Rechte, getrennte technische Nutzer und menschliche Review-Prozesse Wo „Allowed Actions“ besonders gut funktioniert (Praxis): Draft-only Workflows (Agent schreibt nur Entwürfe) Feste Spaces / klar definierte Bereiche (z. B. „Agent Drafts“) Eng begrenzte Endpunkte (z. B. Create/Update Draft, kein Delete, kein Permissions-Mgmt) Umsetzbar mit: Cloudflare Worker / API-Gateway-Pattern (als Beispiel) Alternativ: klassische API-Gateways/Proxies (z. B. Envoy/NGINX/Kong/Apigee/AWS API Gateway) – entscheidend sind Allow-Lists, Validierung, Rate Limits…

KRITIS Dachgesetz 2026

KRITIS-Dachgesetz 2026: Was jetzt auf Betreiber zukommt – und wie Atlassian bei Nachweisen, Workflows und Resilienz hilft Kritische Einrichtungen sollen in Deutschland einheitlicher und ganzheitlicher geschützt werden – nicht nur digital, sondern auch physisch und organisatorisch. Genau dafür schafft das KRITIS-Dachgesetz einen sektorübergreifenden Rahmen zur Umsetzung der EU-CER-Richtlinie (EU 2022/2557). Kurz gesagt: Es geht um Risiken erkennen, Resilienzmaßnahmen steuern, Vorfälle melden und Nachweise sauber dokumentieren – auditfähig und wiederholbar.   Hinweis zum Stand (05.02.2026): Der Bundestag hat das KRITIS-Dachgesetz am 29.01.2026 beschlossen; Details zur Konkretisierung (z. B. Mindestanforderungen/Schwellen) werden teils über nachgelagerte Regelungen präzisiert. Was Sie erwartet: Was ist das KRITIS-Dachgesetz? Das KRITIS-Dachgesetz schafft erstmals einen bundesweit einheitlichen Rahmen für die Resilienz kritischer Anlagen und Einrichtungen. Es setzt die EU-CER-Richtlinie um und erweitert den Fokus deutlich über klassische IT-Security hinaus: Im Zentrum stehen physischer Schutz, Organisation & Verantwortlichkeiten, Krisenfähigkeit sowie Governance und belastbare Nachweisführung.   Kurz: Resilienz wird vom „Konzeptpapier“ zum Betriebsmodell – mit klaren Anforderungen, die im Alltag wiederholbar umgesetzt und bei Bedarf belegt werden müssen. Was ändert sich? Resilienz als Zyklus statt Einzelaktionen: wiederkehrende Risiko- & Resilienzbetrachtung inkl. Dokumentation Resilienzmaßnahmen + Resilienzplan: nachvollziehbare Ableitung aus Risiken (statt „Insellösungen ohne Klammer“) Vorfälle operativ managen und melden: definierte Meldeprozesse inkl. Audit-Trail/Nachweislogik Mehr Transparenz & Governance: Registrierung, klare Zuständigkeiten, erreichbare Kontaktpunkte gegenüber Behörden Konsequenzen bei Verstößen: Sanktions-/Bußgeldrahmen ist vorgesehen Warum jetzt handeln? Wer ist betroffen? Warum Unternehmen jetzt aktiv werden müssen   Resilienz ist kein Projekt, sondern ein Betriebsmodell. Wenn Risikoanalyse, Maßnahmen, Nachweise und Incident-Meldungen nicht zusammenpassen, wird’s in Prüfungen teuer – vor allem zeitlich.   Nachweise entstehen im Alltag – oder gar nicht. Wer erst kurz vor Audit/Behördenanfrage „Dokumentation baut“, verliert Wochen.   Abhängigkeiten wachsen. Kritische Services hängen voneinander ab (Dienstleister, Standorte, IT/OT, Logistik). Ohne zentrales Steuerungsmodell werden Lücken normal.   Bußgelder & Anordnungen sind realistische Risiken. Der Gesetzesrahmen sieht Ordnungswidrigkeiten oder Bußgelder vor. Welche Unternehmen sind betroffen?     Betroffen sind Betreiber kritischer Anlagen/Einrichtungen in Sektoren wie z. B. Energie & Wasser, Gesundheit Transport IT/TK Finanz/Versicherung öffentliche/weitere essenzielle Dienste   Wichtig: Ob eine Organisation konkret unter die Pflichten fällt, hängt von Definitionen und Schwellenwerten ab, die sektorspezifisch präzisiert werden (in der Praxis ist genau das oft der Knackpunkt in der Einordnung). Was ändert sich konkret? Die 4 größten Veränderungen durch das KRITIS-Dachgesetz 1) Pflicht zur Registrierung + behördliche Zuordnung (und laufende Aktualisierung) Neu ist vor allem: Es gibt eine zentrale, formale „Onboarding“-Pflicht ins Regime – inkl. definierter Stammdaten, Kontaktstelle und späterer Behördenzuständigkeit. Was konkret verlangt wird: Betreiber müssen ihre kritischen Anlagen über eine gemeinsame Registrierungsmöglichkeit von BSI & BBK registrieren.   In der Registrierung stecken u. a.: Betreiber-Identität, Kontaktdaten, Sektor/Branche, kritische Dienstleistung, Standort/Versorgungsgebiet, ggf. EU-Bezug und eine erreichbare Kontaktstelle.   Fristenlogik: spätestens 3 Monate nach Einstufung, frühestens jedoch bis einschließlich 17. Juli 2026.   Änderungen müssen gepflegt werden (teils jährlich, teils „unverzüglich“ innerhalb von 2 Wochen).   Wenn Betreiber nicht registrieren, kann das BBK nach Anhörung die Registrierung selbst vornehmen. Warum das in der Praxis ein großer Shift ist Ohne saubere Stammdaten/Ownership (24/7-Kontakt, klare Verantwortlichkeit je Anlage, konsistente Anlagen-Grenzen) kommt ihr in den Folgepflichten sofort ins Straucheln. Das ist der perfekte Punkt, um Governance in Tools zu „verankern“ (Owner, Rollen, RACI, Nachweisstruktur). Unsere Lösungen Beratungstermin vereinbaren 2) Regelmäßige Risikoanalyse nach All-Gefahren-Ansatz (inkl. Interdependenzen) Der Kernwechsel: Nicht „nur Cyber“ und nicht „nur punktuelle BCM-Dokumente“, sondern wiederkehrende, nachvollziehbare Risikoanalyse für physische, technische und menschliche Ursachen – plus Abhängigkeiten zu anderen Sektoren/Anbietern. Was konkret verlangt wird: Betreiber müssen mindestens alle vier Jahre eine Risikoanalyse und Risikobewertung durchführen – auf Basis nationaler Risikoanalysen/Risikobewertungen und weiterer vertrauenswürdiger Quellen.      Die Analyse muss explizit Risiken und Abhängigkeiten berücksichtigen: Abhängigkeit des Betreibers von kritischen Dienstleistungen anderer Betreiber (auch sektorenübergreifend, auch EU/Drittstaaten). Abhängigkeit anderer Sektoren von der eigenen kritischen Dienstleistung (ebenfalls EU/Drittstaaten).       Praktische Konsequenzen (die viele unterschätzen): Ihr braucht ein einheitliches Modell: Asset/Anlage → kritische Dienstleistung → Szenario → Eintrittswahrscheinlichkeit/Impact → Maßnahmen → Rest-Risiko. Interdependenzen sind der „Audit-Killer“: Lieferketten, Single Points of Failure, zentrale Standorte, Personalengpässe, externe Dienstleister, Strom/Telekom-Abhängigkeiten – das muss strukturiert rein, nicht als Fließtext. Unsere Lösungen Beratungstermin vereinbaren 3) Verbindliche Resilienz-Ziele + Maßnahmenpaket (physisch, organisatorisch, technisch) – dokumentiert im Resilienzplan Das ist der Paradigmenwechsel: Das Gesetz beschreibt sehr klar, welche Resilienz-Ziele erreicht werden müssen – und nennt typische Maßnahmen, die darunterfallen.   Die vier Resilienz-Ziele : Betreibe müssen Maßnahmen treffen um: Vorfälle zu verhindern, angemessenen physischen Schutz von Liegenschaften & Anlagen sicherzustellen, auf Vorfälle zu reagieren/abzuwehren und Auswirkungen zu begrenzen, Wiederherstellung der kritischen Dienstleistung zügig zu gewährleisten.   explizit adressierte Maßnahmen (Beispiele aus dem Gesetzestext): Objekt-/Perimeterschutz und organisatorischer Schutz (z. B. bauliche/technische Sicherung) Überwachung der Umgebung, Detektion und Zugangskontrollen Risiko- und Krisenmanagementverfahren, Alarmabläufe   Wichtig: „verhältnismäßig“ – aber nicht beliebig: Maßnahmen müssen auf den Risikoanalysen basieren und verhältnismäßig sein („Zweck-Mittel-Relation“, Stand der Technik, wirtschaftliche Aspekte). Praktische Konsequenzen (die viele unterschätzen): Viele Organisationen haben „irgendwo“ Sicherheitskonzepte, Zutrittsprozesse, BCM-Pläne – aber nicht als geschlossenes, versioniertes, auditierbares System, das direkt auf Risiken einzahlt.   Genau hier entsteht der Bedarf nach Workflows + Wissensbasis + Nachweislogik (statt Dokument-Friedhof). Unsere Lösungen Beratungstermin vereinbaren 4) Meldewesen für Vorfälle: 24h-Erstmeldung + Folgebericht + standardisierte Inhalte (über gemeinsame Meldestelle) Neu ist vor allem: Ein einheitlicher, fristgebundener Meldeprozess für relevante Vorfälle im KRITIS-Kontext (nicht nur IT-Incidents). Was konkret verlangt wird: Vorfälle müssen dem BBK unverzüglich, spätestens 24 Stunden nach Kenntnis gemeldet werden – über die gemeinsame Meldestelle (BBK/BSI).   Bei andauernden Vorfällen muss die Erstmeldung aktualisiert werden.   Spätestens einen Monat nach Kenntnis ist ein ausführlicher Bericht zu übermitteln.   Die Meldung soll bereits in der Erstmeldung strukturierte Kerndaten enthalten (z. B. Umfang der Betroffenheit, (voraussichtliche) Dauer, geografisches Gebiet). Warum das ein echter Implementierungsblock ist: Ohne sauberes Ticketing/Eskalation/Audit-Trail wird die 24h-Frist schnell sportlich – vor allem, wenn mehrere Stellen (Betrieb, Security, BCM, Standortschutz, Legal/Comms) koordiniert werden müssen.   „Nachweisfähigkeit“ ist hier nicht Kür, sondern Teil des Designs: Wer wusste wann was? Welche Entscheidungen? Welche Maßnahmen? Welche Kommunikation? Die Lösung: Wie Atlassian-Tools KRITIS-Unternehmen bei der Umsetzung helfen Die Anforderungen des KRITIS-Dachgesetzes sind stark prozess-, dokumentations- und governance-getrieben: Risiken müssen strukturiert bewertet, Maßnahmen gesteuert, Vorfälle nachvollziehbar bearbeitet und Nachweise konsistent dokumentiert…