导航|地址|刷新
Sichere nichtöffentliche Netzwerke für a…









Zum Inhalt springen
















Alle Kategorien

AI

Entwickler

Radar

Produkt-News

Sicherheit

Politik & Rechtliches

Zero Trust

Speed & Zuverlässigkeit

Karriere

Partner



Dieser Beitrag ist verfügbar in

English

Español

Español (Latinoamérica)

Français

Italiano

日本語

한국어

繁體中文

简体中文

Nederlands

Websitesprache wechseln

English

Deutsch

Español

Español (Latinoamérica)

Français

Italiano

日本語

한국어

繁體中文

简体中文

Português

Русский

Bahasa Indonesia

ภาษาไทย

Tiếng Việt

Polski

العربية

עברית

Svenska

Nederlands

Türkçe

AnmeldenKontaktieren Sie uns










Blog

Agents WeekAICloudflare One+66 weitere Tags anzeigen


9 Tags9 Tags anzeigen






Ausgewählte Tags

Agents WeekAICloudflare OneCloudflare WorkersEntwicklerEntwicklerplattformSASEWorkers AIZero Trust

Alle Tags

Passende Tags

Keine Tags gefunden

1.1.1.1

Agententauglichkeit

Agents

Agents Week

AI

AI Bots (DE)

AI Gateway (DE)

AI Week

Allgemein Verfügbar

Always Online (DE)

AMD (DE)

Analysen

Angriffe

Anonymous (DE)

Anwendungsservices

Anwendungssicherheit

Anycast (DE)

API

API-Sicherheit

Athenian Project (DE)

Ausfall

Auswirkung

Automatisierung

AWS

Bedrohungen

Bedrohungsinformationen

Beta

Betrug

Birthday Week

Black Friday (DE)

Bot-Management

Botnet (DE)

Bots

Brief der Gründer

Browser-Rendering

Browser Run

Bug Bounty (DE)

Cache

CASB

CDN

Certificate Authority (DE)

China (DE)

CIO Week

CISA (DE)

Clientlos

Cloud Email Security

Cloudflare Access

Cloudflare Calls

Cloudflare für Startups

Cloudflare Gateway

Cloudflare One

Cloudflare Pages

Cloudflare Queues

Cloudflare Workers

Cloudflare Zero Trust

Cloudforce One

Code Orange

Coinbase

Compliance

Compression

Connectivity Cloud

Connectivity (DE)

Container

Content Independence Day

Crawler Hints

CrowdStrike (DE)

Crypto Week (DE)

D1

Das Jahr im Rückblick

Das Team

Data Catalog

Data Localization (DE)

Data Localization Suite (DE)

Data Privacy Day (DE)

Datenbank

Datenschutz

DDoS

DDoS-Berichte

DDoS-Warnungen

Developer Week

DevOps (DE)

Digital Experience Monitoring (DE)

Diversity (DE)

DLP

DMARC (DE)

DNS

DNS Flood (DE)

Dogfooding (DE)

DoH (DE)

Dokumentation für Entwickler

Durable Objects

Early Hints (DE)

EC2 (DE)

Echtzeit

Egress (DE)

E-Mail-Sicherheit

Emissions

Entropie

Entwickler

Entwicklerplattform

Erweiterte DDoS-Abwehr

Firmenstandorte

Forrester

Forschung

Foundation DNS (DE)

Free (DE)

Freedom of Speech (DE)

Front-End

Full Stack

Gartner (DE)

Gatebot (DE)

GDPR (DE)

Generative KI

Geo Key Manager (DE)

Germany (DE)

Geschwindigkeit

GitHub

Google Cloud

HTTP2 (DE)

Hyperdrive

Impact Week (DE)

Intel

Interconnection

Internetabschaltung

Internet-Performance

Internetqualität

Internet-Traffic

Internet-Trends

IWD (DE)

JAMstack (DE)

Jengo (DE)

Karriere

Killnet (DE)

KI-Suche

Kontext

Kryptographie

Lateinamerika

LavaRand

Lissabon

LLM

Log4J (DE)

Log4Shell (DE)

Logs (DE)

Maßnahmen zur Bedrohungsbekämpfung

MCP

Microsoft Azure (DE)

Mirai

Mobile (DE)

Model Kontext Protokoll,

Multi-Cloud (DE)

MySQL

NaaS (DE)

Network Interconnect (DE)

Network Protection (DE)

Netzwerk-Services

NGINX

Notifications (DE)

Olympics (DE)

Partner

PCI Certified (DE)

Peering (DE)

Performance

Phishing

Pipelines

Politik & Rechtliches

Portugal

Post-mortem-Analyse

Post-Quanten-Kryptographie

Produkt-News

Project Safekeeping (DE)

Projekt Galileo

Python (DE)

Queues

R2 Super Slurper

Radar

Radar API (DE)

Ransom-Angriffe

Rapid Reset (DE)

Rate Limiting (DE)

RDDoS (DE)

Reading List (DE)

Regional Services (DE)

Registrar

REvil (DE)

Risikomanagement

Routing (DE)

Rust

SaaS (DE)

SaaS-Sicherheit

Sable (DE)

Sandbox

SASE

SDK

Secure Web Gateway

Security Center

Security Posture (DE)

Security Service Edge (DE)

Security Week

Serverless

Sicherheit

SIEM (DE)

SIM (DE)

South America (DE)

Speed Week (DE)

Speed & Zuverlässigkeit

Speicherung

Sports (DE)

SSE (DE)

Sumo Logic (DE)

Supercloud (DE)

Sustainability (DE)

SYN Flood (DE)

Teams Dashboard (DE)

Technik

Testing (DE)

Transparenz

Trends

Trust & Safety (DE)

Tunnel von Cloudflare

TURN-Server

Übernahmen

Umfassende Analyse

Vectorize (DE)

Verbraucherdienste

Verwaltung der Sicherheitsvorkehrungen für KI

Verwaltung des Sicherheitsniveaus

VoIP (DE)

WAF

Waiting Room (DE)

WARP Connector (DE)

WASM (DE)

Web Application Firewall

WebAssembly (DE)

WebRTC

Workers AI

Workers Launchpad

Workers VPC

Workflows

x402

Zero Day Threats (DE)

Zero Trust

Zero Trust Week (DE)

Zertifizierung

Zufälligkeit




Cloudflare WorkersEntwicklerEntwicklerplattformSASEWorkers AIZero Trust





Agents WeekAICloudflare OneCloudflare WorkersEntwicklerEntwicklerplattformSASEWorkers AIZero Trust






14. April 2026
Sichere nichtöffentliche Netzwerke für alle: Nutzer, Netzwerkknoten, Agenten und Workers – mit Cloudflare Mesh




Nikita Cano und Thomas Gauvin



Lesezeit: 14 Min.
URL kopieren



Dieser Beitrag ist auch verfügbar in English,Español,Español (Latinoamérica),Français,Italiano,日本語,한국어,繁體中文,简体中文 und Nederlands.








Durch KI-Agenten hat sich der Blick auf den nichtöffentlichen Netzwerkzugang verändert: Coding-Agenten müssen Abfragen an Staging-Datenbanken stellen, Produktionsagenten müssen interne API aufrufen und persönliche KI-Assistenten müssen Dienste in Heimnetzwerken erreichen. Clients sind heute nicht mehr nur Menschen oder Dienste, sondern auch autonom laufende Agenten, die nicht explizit genehmigte Anfragen an eine Infrastruktur richten, deren Sicherheit gewährleistet werden muss.

Jeder dieser Workflows wirft das gleiche Problem auf: Agenten müssen auf nichtöffentliche Ressourcen zugreifen, doch die Werkzeuge dafür wurden für Menschen entwickelt, nicht für autonome Software. VPN erfordern eine interaktive Anmeldung. SSH-Tunnel müssen manuell eingerichtet werden. Dienste öffentlich zugänglich zu machen, schafft ein Sicherheitsrisiko. Und bei keinem dieser Ansätze hat man Einblick in das, was der Agent wirklich tut, sobald er die Verbindung einmal hergestellt hat.

Heute stellen wir Cloudflare Mesh zur Vernetzung nichtöffentlicher Netzwerke und zur Ermöglichung eines sicheren Zugriffs durch Agenten vor. Mesh wird auch in die Entwickler-Plattform von Cloudflare integriert. Damit können Workers, Durable Objects und Agenten, die mit dem Agenten-SDK erstellt wurden, nichtöffentliche Infrastruktur direkt erreichen.

Wenn Sie die SASE- und Zero Trust-Produktreihe von Cloudflare One nutzen, steht Ihnen Mesh bereits zur Verfügung. Für die Absicherung von Agenten-Workloads ist kein neues technologisches Konzept erforderlich. Benötigt wird ein für das Agenten-Zeitalter geschaffenes SASE-Modell, und das bietet Cloudflare One. Cloudflare Mesh ist ein neues, einfacher gestaltetes Produkt, das die bereits vertrauten Zugangswege nutzt: den WARP Connector (jetzt Cloudflare Mesh-Netzwerkknoten) und den WARP Client (jetzt Cloudflare One Client). Zusammen bilden diese ein nichtöffentliches Netzwerk für den Traffic von Menschen und Agenten. Mesh wird direkt in Ihre bestehende Cloudflare One-Bereitstellung integriert. Ihre vorhandenen Gateway-Richtlinien, Zugriffsregeln und Gerätestatusprüfungen werden automatisch auf Mesh-Datenverkehr angewandt.

Wenn Sie als Entwickler einfach nur nichtöffentliche Netzwerke für Ihre Agenten, Dienste und Ihr Team benötigen, ist Mesh der Einstiegspunkt. Es dauert nur wenige Minuten, die Lösung einzurichten, Ihre Netzwerke zu verbinden und Ihren Traffic abzusichern. Da Mesh auf der Cloudflare One-Plattform läuft, können im Lauf der Zeit anspruchsvollere Funktionen eingegliedert werden: Gateway-Netzwerk-, DNS- und HTTP-Richtlinien für eine präzise Traffic-Kontrolle, Access for Infrastructure für die Verwaltung von SSH- und RDP-Sitzungen, Browserisolierung für sicheren Webzugriff, DLP, um zu verhindern, dass vertrauliche Daten Ihr Netzwerk verlassen, und CASB für SaaS-Sicherheit. Sie müssen nicht alles vom ersten Tag an genau planen: Sie sind nur einfach nicht gezwungen, eine Migration vorzunehmen, wenn Sie eine dieser Funktionen irgendwann benötigen.

Neue Agenten-Workflows

Bei nichtöffentlichen Netzwerken ging es schon immer darum, Clients mit Ressourcen zu verbinden – per SSH zu einem Server, zur Abfrage einer Datenbank oder für den Zugriff auf eine interne API. Was sich geändert hat, ist die Identität der Clients. Vor einem Jahr waren es Ihre Entwickler und Ihre Dienste. Heute sind es zunehmend Ihre Agenten.

Das ist keine theoretische Überlegung. Man muss sich nur das Ökosystem anschauen, etwa die explosionsartige Zunahme von MCP (Model Context Protocol)-Servern, die Tool-Zugriff ermöglichen, Programmier-Agenten, die Daten aus nichtöffentlichen Repositorys und Datenbanken lesen müssen, oder persönliche Assistenten, die auf Heimhardware laufen. Jeder dieser Fälle setzt voraus, dass der Agent die benötigten Ressourcen erreichen kann. Wenn diese Ressourcen also in nichtöffentlichen Netzwerken isoliert sind, kommt der Agent nicht weiter.





Es sind drei Arten von Workflows zu verzeichnen, die sich aktuell schwer absichern lassen:

Zugriff auf einen persönlichen Agenten von einem Mobilgerät aus: Sie nutzen OpenClaw auf einem Mac mini, der sich bei Ihnen zu Hause befindet, und möchten von Ihrem Handy, Ihrem Laptop im Café oder Ihrem Rechner bei der Arbeit darauf zugreifen. Doch wenn Sie den Dienst über das öffentliche Internet zugänglich machen (selbst mit Passwortschutz), könnten dadurch Sicherheitslücken entstehen. Ihr Agent hat in Ihrem Heimnetzwerk Shell-, Dateisystem- und Netzwerkzugriff. Es genügt ein einziger Konfigurationsfehler, und schon ist alles für jedermann zugänglich.

Zugriff eines Coding-Agenten auf eine Staging-Umgebung: Sie verwenden Claude Code, Cursor oder Codex auf Ihrem Laptop. Sie weisen den Agenten an, den Implementierungsstatus zu prüfen, Analysedaten aus einer Staging-Datenbank abzufragen oder Daten aus einem internen Objektspeicher zu lesen. Diese Dienste befinden sich jedoch in einer Virtual Private Cloud (VPC), sodass Ihr Agent sie nicht erreichen kann, ohne sie dem Internet auszusetzen oder für Ihren gesamten Laptop einen Tunnel in die VPC herzustellen.

Verbindung implementierter Agenten mit nichtöffentlichen Diensten: Sie integrieren mithilfe des Agenten-SDK bei Cloudflare Workers Agenten in Ihr Produkt. Diese Agenten müssen interne API aufrufen, Datenbanken abfragen und auf Dienste zugreifen können, die sich nicht im öffentlichen Internet befinden. Sie benötigen Zugang zu diesen nichtöffentlichen Systemen, aber mit begrenzten Berechtigungen, Prüfprotokollen und ohne, dass dabei Anmeldedaten offengelegt werden.

Cloudflare Mesh: ein nichtöffentliches Netzwerk für Nutzer, Netzwerkknoten und Agenten

Cloudflare Mesh ist eine entwicklerfreundliche Lösung für nichtöffentliche Netzwerke. Ein schlanker Connector, eine Binärdatei, verbindet alles: Ihre persönlichen Geräte, Ihre Remote-Server und Ihre Nutzer-Endpunkte. Sie müssen nicht für jedes Szenario separate Tools installieren. Es genügt ein einziger Connector für Ihr Netzwerk, und schon funktioniert jede Art des Zugriffs.

Sobald die Verbindung hergestellt ist, können die Geräte in Ihrem nichtöffentlichen Netzwerk über private IP-Adressen miteinander kommunizieren. Das Routing erfolgt über das Netzwerk von Cloudflare, das sich über mehr als 330 Städte weltweit erstreckt. Das sorgt für höhere Zuverlässigkeit und bietet Ihnen größere Kontrolle über Ihr Netzwerk.



Mit Mesh deckt nun eine einzige Lösung alle gerade beschriebenen Agenten-Zugriffswege ab:

Mit Cloudflare One Client für iOS auf Ihrem Handy können Sie Ihre Mobilgeräte über ein nichtöffentliches Mesh-Netzwerk sicher mit Ihrem lokalen Mac mini verbinden, auf dem OpenClaw läuft.

Mit Cloudflare One Client für macOS auf Ihrem Laptop können Sie Ihren Laptop mit Ihrem nichtöffentlichen Netzwerk verbinden, damit Ihre Coding-Agenten auf Staging-Datenbanken oder API zugreifen und Abfragen an diese stellen können.

Mit Mesh-Netzwerkknoten auf Ihren Linux-Servern können Sie VPC in externen Clouds miteinander vernetzen, sodass Agenten auf Ressourcen und MCP-Server in externen nichtöffentlichen Netzwerken zugreifen können.

Da Mesh den Cloudflare One Client nutzt, werden auf jede Verbindung die Sicherheitskontrollen der Cloudflare One-Plattform angewandt. Für Mesh-Datenverkehr gelten Gateway-Richtlinien, Gerätestatusprüfungen validieren die verbundenen Geräte und die DNS-Filterung fängt verdächtige Anfragen ab. Eine zusätzliche Konfiguration ist dafür nicht erforderlich: Dieselben Richtlinien, die den von Menschen generierten Datenverkehr absichern, schützen auch den Agenten-Traffic.

Die Entscheidung zwischen Mesh und Tunnel

Sie könnten sich die Frage stellen, wann es sinnvoller ist, Mesh anstelle von Tunnel zu nutzen. Beide Produkte verbinden externe Netzwerke auf vertrauliche Weise mit Cloudflare, doch sie dienen unterschiedlichen Zwecken. Cloudflare Tunnel ist die ideale Lösung für unidirektionalen Datenverkehr, der von Cloudflare per Proxy von der Edge zu bestimmten nichtöffentlichen Diensten (wie einem Webserver oder einer Datenbank) geleitet wird. 

Cloudflare Mesh dagegen bietet ein vollständig bidirektionales „Many-to-many“-Netzwerk: Alle Geräte und Knoten in Ihrem Mesh-Netzwerk können mithilfe nichtöffentlicher IP-Adressen aufeinander zugreifen. Eine Anwendung oder ein Agent kann jede andere Ressource im selben Mesh-Netzwerk erkennen und darauf zugreifen, ohne dass die einzelnen Ressourcen dafür einen gesonderten Tunnel benötigen. 

Die Stärken des Cloudflare-Netzwerks nutzen

Cloudflare Mesh bietet die Vorteile eines Mesh-Netzwerks (Ausfallsicherheit, hohe Skalierbarkeit, geringe Latenz und hohe Performance). Gleichzeitig wird dadurch, dass das Routing über Cloudflare läuft, eine wesentliches Problem von Mesh-Netzwerken beseitigt: NAT-Traversal.

…