Auch ohne VPN kommt man um feste IP-Adressen nicht herum. Eine praxistaugliche Lösung für den Umstieg kleiner Unternehmen auf Zero Trust

Hallo, ich bin Otsuka, CTO bei Liberogic.

„VPN, langsam wird's eng“

Wer in einem kleinen Unternehmen die IT-Verantwortung nebenbei mitträgt, hat sicher schon einmal so gedacht.
Bei uns war es genau so.

Zero Trust, SASE, weg vom VPN ...
Die Begriffe begegnen einem ständig, wirken aber wie Themen für Großunternehmen, und es ist nicht leicht zu erkennen, wo man anfangen soll.

Vor diesem Hintergrund hat Liberogic Inc., eine Webagentur mit rund zehn Mitarbeitenden, von einem VPN auf eine Zero-Trust-Architektur umgestellt.
In diesem Beitrag berichten wir aus der Praxis, warum wir umgestellt haben, was sich verändert hat und wo die Schwachstellen liegen.

Wenn das VPN an seine Grenzen stößt

Wir haben im Büro lange die VPN-Funktion des Office-Routers genutzt.
Die gängige Konfiguration: Von zu Hause oder unterwegs verbindet man sich zunächst mit dem Firmennetz und gelangt von dort ins Internet.
Seit einigen Jahren beschäftigte uns jedoch Folgendes.

• Die Regel „Bitte außerhalb des Büros erst mit dem VPN verbinden“ blieb letztlich eine bloße Bitte.
• In Cafés, bei Geschäftsreisen oder in den Büros von Kunden funktioniert VPN manchmal nicht.
• Web-Meetings und die Dateisynchronisation in der Cloud laufen alle über die Firmenleitung und sind dadurch langsam.
• Router sind dafür da, den Datenverkehr weiterzuleiten. Gefährliche Websites blockieren sie nicht.

Wenn auch nur einer dieser Punkte auf Sie zutrifft, ist es vielleicht an der Zeit, Ihre Sicherheitsstrategie zu überprüfen.

Besonders problematisch war, dass sich die Nutzung eines VPNs nicht erzwingen ließ.
Das in macOS integrierte VPN muss bei jedem Start manuell verbunden werden. Gerät, deren Verbindung vergessen wurde, senden ihren Datenverkehr ungeschützt über die jeweils verfügbare Netzwerkverbindung nach außen.

Das Risiko unsicherer Netzwerke steigt

Außerdem möchte ich noch auf einen aktuellen Vorfall hinweisen.

Im Oktober 2026 wurde bekannt, dass die privaten Schlüssel von acht Zwischenzertifikaten der indischen Zertifizierungsstelle eMudhra kompromittiert waren.
Laut einer Analyse von Cloudflare waren die Schlüssel selbst schwach, sodass sich damit gefälschte Zertifikate für beliebige Domains erstellen ließen.
Diese Zertifikate waren übrigens von Browsern und Betriebssystemen weitgehend als vertrauenswürdig eingestuft.

Bisher bin ich bei der Risikobewertung für unbekannte WLAN-Netze davon ausgegangen, dass das Risiko relativ gering ist, weil heutzutage über HTTPS statt über HTTP kommuniziert wird. Dieser Punkt sollte ich aber noch einmal überdenken.

Zero Trust / SASE / ZTNA im Überblick

Wer sich damit beschäftigt, gerät zuerst leicht durcheinander. Für ein kleines Unternehmen, das sich einen Überblick verschaffen will, reicht dieser Umfang meiner Ansicht nach völlig aus.

Zero Trust ist der Name eines Denkansatzes. Die konkreten Dienstformen, die ihn umsetzen, sind ZTNA und SWG, und das Gesamtbild, das sie zusammenfasst, heißt SASE.

Statt sich unter Druck zu setzen, SASE einführen zu müssen, passt für kleine Unternehmen meist besser, wenn man bei dem ansetzt, was am VPN konkret stört und was man lösen möchte.

In unserem Unternehmen gab es kaum interne Fachsysteme

Der typische Einsatz eines VPNs besteht wohl darin, dass man von außerhalb auf interne Fachanwendungen oder Dateiserver zugreift.

Allerdings verfügen wir intern kaum über solche Strukturen. Die Tools, mit denen wir arbeiten, sind fast ausschließlich Cloud-Dienste. Deshalb stellte sich die Frage, wie man den Zugang zu internen Systemen ersetzt, bei uns nie.

Bei Unternehmen mit eigenen Geschäftsanwendungen steht dieser Punkt meiner Meinung nach im Mittelpunkt der Überlegungen.

Bei der Migration bleibt man häufig an der "festen IP" hängen.

Bei Agenturen ist es häufig so, dass die Verwaltungsoberflächen und der SSH-Zugang der Server unserer Kunden nur von bestimmten IP-Adressen aus erreichbar sind. Das dient der Sicherheit und ist eine sehr richtige Vorgehensweise.

Gleichzeitig haben wir über Jahre hinweg zahlreichen Kunden gebeten, "unsere feste IP-Adresse freizugeben". Diese Einstellungen sind sozusagen ein über die Zeit aufgebautes Kapital.

Auch Zero-Trust-Dienste bieten die Möglichkeit, Datenverkehr über feste IP-Adressen zu leiten.
Cloudflare bietet zwar einen "Dedicated Egress IP"-Dienst an, dieser ist jedoch ein Add-on des Enterprise-Tarifs und setzt einen Vertrag für Großunternehmen voraus.
Für kleine Unternehmen wie uns war er daher kaum praktikabel.

Ändert sich zudem die ausgehende IP-Adresse, müssten alle Kunden ihre Einstellungen erneut anpassen.
Das ist in der Praxis nicht realistisch.

Wir wünschten uns also drei Dinge.

1. Von überall aus alle Mitarbeitenden lückenlos schützen
2. Normalen Datenverkehr nicht unnötig über das Büronetzwerk leiten
3. Für benötigte Zieladressen weiterhin über die feste IP-Adresse des Unternehmens ausgehen

Unsere Entscheidung: Die Absicherung wandert in die Cloud, nur der Ausgang bleibt bei der bestehenden festen IP

Wir haben uns für Cloudflare One entschieden.

• Auf jedem PC wird die Software WARP installiert: Sie stellt die Verbindung beim Start automatisch her, sodass seltener vergessen wird, sich zu verbinden.
• Das Gateway blockiert Verbindungen zu gefährlichen Websites: Verbindungen zu Seiten mit Malware oder Phishing werden unternehmensweit nach einheitlichen Regeln unterbunden.
• Der normale Datenverkehr geht direkt von Cloudflare ins Internet: Er wird nicht über die Leitung des Unternehmens geführt.
• Nur die Server unserer Kunden werden über die feste IP des Unternehmens ausgehend angesprochen: Dafür steht ein kleines Gerät im Büro, das über Cloudflare Tunnel mit Cloudflare verbunden ist.

Den letzten Punkt haben wir als ausschlaggebend empfunden: Man kann pro Zieladresse festlegen, dass der Datenverkehr über das Unternehmensnetz laufen soll.
Für unsere Kunden bleibt der Zugriff von außen gleich, weil weiterhin dieselbe feste IP erscheint. Auf ihrer Seite muss nichts geändert werden.

Da sich die Firmengeräte selbstständig mit Cloudflare verbinden, müssen keine Ports am Router geöffnet werden, und es entstehen keine zusätzlichen Einstiegspunkte von außen in das Firmennetzwerk.

Ein wichtiger Vorteil ist außerdem, dass bei Problemen wie dem Zwischenzertifikat nicht allein auf die Aufmerksamkeit einzelner Personen gesetzt werden muss.
Im Fall eMudhra hat Cloudflare mitgeteilt, dass Kunden mit Gateway und aktuellem Client automatisch geschützt sind.

Was sich geändert hat

WARP startet zusammen mit dem Mac und verbindet sich automatisch. Die Mitarbeitenden müssen weder einen VPN-Verbindungsablauf lernen noch sich um detaillierte Einstellungen kümmern. Sicherheitsmaßnahmen bedeuten im Alltag oft mehr Aufwand, doch in diesem Fall hat sich der Aufwand sogar verringert. Die gute Nutzerfreundlichkeit (UX) hat uns bei der Einführung am meisten überrascht.

Interne Apps, die nur über WARP erreichbar sind

Cloudflare One bietet mit Access die Möglichkeit, zu steuern, welche Personen und Geräte auf eine Web-Anwendung zugreifen dürfen. Damit lässt sich eine App erstellen, die nur von Geräten aus erreichbar ist, die über WARP mit dem Cloudflare One des Unternehmens verbunden sind.

Beispielsweise können Sie den Zugriff nur dann erlauben, wenn beide der folgenden Bedingungen erfüllt sind.

• Die Anmeldung erfolgt mit der geschäftlichen E-Mail-Adresse.
• Das Gerät ist über WARP mit Cloudflare One des Unternehmens verbunden.

Selbst wenn die URL bekannt ist, lässt sich die Seite von Geräten, die die Bedingungen nicht erfüllen, nicht öffnen. Damit lässt sich ein ähnlicher Schutz wie bei einem internen System „hinter dem VPN“ aufbauen, und zwar ganz ohne VPN.

Auch Anwendungen, die auf internen Servern laufen, lassen sich auf die gleiche Weise schützen, indem sie über Cloudflare Tunnel angebunden werden, ohne dass Ports geöffnet werden müssen.

Auch die folgende Verwaltungsanwendung ist auf diese Weise abgesichert.

Nach dem Do-it-yourself-Prinzip haben wir außerdem eine kleine Verwaltungsanwendung entwickelt.

Eine Herausforderung blieb jedoch bestehen: Mit jedem neuen Kundenserver muss ein Ziel registriert werden, das über eine feste IP-Adresse angesprochen wird. Das Cloudflare-Dashboard enthält viele Fachbegriffe, und eine falsche Einstellung wirkt sich auf die Verbindungen aller Nutzer aus. Außerdem können wir nicht allen Mitarbeitenden Administratorrechte geben.

Deshalb haben wir eine interne Anwendung entwickelt, mit der Mitarbeitende ein Ziel einfach durch die Auswahl des Zwecks registrieren können.

• Es bleibt nachvollziehbar, wer die Registrierung vorgenommen hat und zu welchem Zweck.
• Dienste, die unternehmensweit genutzt werden, oder zu weit gefasste Bereiche können nicht registriert werden.
• Nach der Registrierung lässt sich direkt prüfen, ob die Änderungen korrekt übernommen wurden.

Cloudflare lässt sich über eine API konfigurieren, weshalb auch solche internen Tools entwickelt werden können. Da wir ohnehin regelmäßig Webanwendungen entwickeln, ist das unser Fachgebiet.

Zu den Kosten

Cloudflare One bietet ein kostenloses Kontingent für bis zu 50 Nutzer.
Da dieselbe Nutzergrenze auch für Cloudflare Access gilt, das wir für die Anmeldung in internen Tools verwenden, lässt sich der Dienst besonders unkompliziert testen, wenn Sie Access bereits nutzen.
Bei mehr als 50 Nutzern wird ein kostenpflichtiger Tarif fällig, der öffentlich mit 7 US-Dollar pro Nutzer und Monat angegeben ist.

Für die feste IP-Adresse nutzen wir weiterhin die bestehende Internetverbindung.
Zusätzlich wird ein Rechner benötigt, der im Büro dauerhaft läuft.
Wir haben dafür einen kleinen, eigens angeschafften PC eingerichtet.

Ehrlich gesagt: Es ist keine Universallösung

Damit es nicht nur nach Vorteilen klingt, nennen wir auch die Punkte, auf die man achten sollte.

• Fällt der Tunnel aus, ist über die feste IP kein Zugriff mehr möglich: Wenn der kleine PC im Büro oder die Internetverbindung ausfällt, können Kundenserver nicht mehr erreicht werden. Das normale Web funktioniert weiterhin, doch ein Ausfall muss unbedingt durch eine Benachrichtigung auffallen.
• Mehr Abhängigkeit von Cloudflare: Authentifizierung und Netzwerkpfade laufen über einen einzigen Anbieter. Das ist der Preis für den Komfort.
• Installation auf jedem Gerät nötig: WARP und das Zertifikat müssen pro Gerät einmal eingerichtet werden. Bei Smartphones kommt mehr manueller Aufwand hinzu.
• Kombination mit einem VPN des Kunden erfordert Prüfung: Je nach Routing- und DNS-Konfiguration kann der Gateway-Schutz unwirksam werden. Wir stellen dafür eine Verbindungsanleitung mit den einzelnen Schritten bereit.
• Der Datenverkehr wird nicht inhaltlich geprüft: Wir führen kein TLS-Decryption durch. Wenn der gesamte Datenverkehr im Detail untersucht werden soll, ist eine andere Lösung zu prüfen.
• Der kostenlose Tarif bietet keinen umfassenden Support: Fehler müssen im Wesentlichen selbst analysiert werden. Außerdem beträgt die Log-Aufbewahrung im kostenlosen Tarif maximal 24 Stunden.

Für wen sich das eignet und für wen nicht

Geeignet ist es unserer Einschätzung nach vor allem für Unternehmen wie diese:

• Unternehmen mit wenigen bis einigen Dutzend Mitarbeitenden, in denen Personen extern oder remote arbeiten
• Zugriffsbeschränkung per feste IP-Adresse lässt sich nicht aufgeben
• Der Schwerpunkt liegt auf Cloud-Diensten, eigene Serverinfrastruktur ist gering
• Mindestens eine Person mit Erfahrung ist vorhanden, sodass man beim Ausprobieren nachschlagen kann.

Umgekehrt empfehlen wir in folgenden Fällen, auch andere Produkte oder die Beratung durch spezialisierte Unternehmen in Betracht zu ziehen.

• Branchenvorgaben erfordern die langfristige Speicherung von Protokollen oder eine detaillierte Prüfung der Kommunikation.
• Viele Geräte sind nicht im Besitz des Unternehmens und lassen sich nicht mit Software ausstatten.
• Wenn der Tunnel ausfällt, ist niemand da, der darauf reagieren kann.

Fazit

Bisher wurde auf den Macs lediglich eine Virenschutzsoftware installiert, ohne detaillierte Einstellungen vorzugeben. Im Zuge der Einführung von Cloudflare One wurden nun die macOS-Einstellungen sowie die Konfiguration der Virenschutzsoftware intern vollständig eingerichtet.

Angesichts der zunehmenden Angriffe auf Entwickler und Ersteller von Inhalten reicht der Schutz allerdings nicht aus. Liberogic arbeitet deshalb auch an weiteren Maßnahmen.

Verwaltung von Abhängigkeiten
Da Supply-Chain-Angriffe auf Entwickler zunehmen, überprüfen wir, wie Pakete hinzugefügt und aktualisiert werden, anstatt sie einfach auf „die neueste Version“ zu setzen.

Umgang mit Geheimnissen
API-Schlüssel und SSH-Schlüssel verwalten wir nach festgelegten 1Password-Regeln und speichern sie in Entwicklungsumgebungen möglichst nicht im Klartext.

Minimierung und Überprüfung von Berechtigungen
Zugänge, Schlüssel und Berechtigungen für Kundenumgebungen und Dienste beschränken wir auf das notwendige Maß und entfernen sie nach Abschluss eines Projekts.

Wissensaustausch
Wir nutzen tatsächlich veröffentlichte Sicherheitsvorfälle als Themen für interne Lernrunden und überlegen dabei, wie sehr uns ein ähnlicher Vorfall in unserem eigenen Umfeld treffen würde.

Es versteht sich von selbst, dass wir größere Sicherheitsvorfälle vermeiden wollen. Da unser Unternehmen gemessen an seiner Größe viele Geschäftsbeziehungen mit großen Kunden unterhält, müssen wir jedoch durchgängig ein stabiles Sicherheitsniveau gewährleisten.
Spektakulär klingt das nicht, aber wir bauen Schritt für Schritt auf, was in unserer Hand liegt.

Wenn dies auch anderen Unternehmen mit ähnlichen Fragen weiterhilft, freuen wir uns.