Das Verbot externer APIs ist kein Verbot von Remote-Arbeit. Das sind zwei verschiedene Dinge, und die Verwechslung dieser beiden kostet Unternehmen unnötige Einschränkungen dort, wo sie nicht sein sollten.
⚡ Kurz gesagt
- ✅ Hauptidee: Ein VPN-Tunnel und ein Aufruf an eine Cloud-AI-API sind prinzipiell unterschiedliche Dinge, das Verbot des letzteren bedeutet nicht das Verbot des ersteren.
- ✅ Corporate VPN ≠ Consumer VPN: Es geht nicht darum, die Geolokalisierung zu ändern, sondern einen privaten "Korridor" zu Ihrem internen Netzwerk zu schaffen.
- ✅ Architektur ohne Kompromisse: Mitarbeiter → verschlüsselter Tunnel → interner Server → lokale LLM. Kein Datenpaket verlässt Ihre Infrastruktur.
- 🎯 Sie erhalten: ein Verständnis dafür, wie eine strenge Sicherheitsrichtlinie mit dem tatsächlichen Bedarf an Fernzugriff kombiniert werden kann – ohne Kompromisse auf einer der Seiten.
- 👇 Unten finden Sie detaillierte Erklärungen, Diagramme und Antworten auf praktische Fragen
📚 Inhalt des Artikels
- 📌 Warum "kein externes API" nicht "kein Fernzugriff" bedeutet
- 📌 Was ist ein VPN und wie unterscheidet sich ein Corporate VPN von einem üblichen "VPN für Netflix"
- 📌 Wie sich Fernzugriff in die Architektur einer Self-Hosted-Lösung einfügt
- 📌 Wer ist für die Einrichtung verantwortlich – Sie oder Ihre IT-Abteilung
- 📌 Was kostet es zusätzlich und wovon hängt der Preis ab
- ❓ Häufig gestellte Fragen (FAQ)
- ✅ Schlussfolgerungen
Warum "kein externes API" nicht "kein Fernzugriff" bedeutet
Stellen Sie sich eine Situation vor: Ihr Unternehmen arbeitet in der kritischen Infrastruktur, im Rechts- oder Finanzwesen. Die Sicherheitsrichtlinie ist klar – keine Daten verlassen Ihr Netzwerk, keine Aufrufe an externe Cloud-AI-Dienste. Das ist eine logische und begründete Entscheidung, die oft nicht nur durch interne Vorschriften, sondern auch durch Anforderungen von Regulierungsbehörden oder vertragliche Verpflichtungen gegenüber Kunden festgelegt wird. Aber Sie haben Mitarbeiter, die remote arbeiten, auf Geschäftsreisen sind, zu Hause krank mit einem Laptop unter der Hand liegen oder einfach abends ein Dokument überprüfen möchten, anstatt bis zum Morgen im Büro zu warten. Frage: Bedeutet das Verbot externer APIs, dass sie für immer an den Bürostuhl gebunden sind?
Häufiger Fehler
Wenn ein Unternehmen die Anforderung "keine externen APIs" formuliert, entsteht im Kopf oft ein vereinfachtes Bild: "Alles muss in den vier Wänden des Büros bleiben, und damit auch die Mitarbeiter." Das ist eine logische, aber falsche Schlussfolgerung. Sie entsteht, weil beide Szenarien – "Daten gehen nach draußen" und "Person verbindet sich von außen" – das Wort "extern" enthalten, und das Gehirn sie automatisch in eine Risikokategorie zusammenfasst.
Tatsächlich geht es um zwei völlig unterschiedliche Konzepte:
- Wohin Ihre Daten gehen – ob sie auf die Server eines Drittanbieters (OpenAI, Google, jedes SaaS) gelangen, wo sie außerhalb Ihrer Kontrolle verarbeitet werden, gemäß einer fremden Aufbewahrungsrichtlinie gespeichert werden und theoretisch zum Training fremder Modelle verwendet werden können
- Von wo sich der Mitarbeiter verbindet – von welchem physischen Punkt aus er eine Verbindung zu Ihrem System herstellt: vom Bürotisch, von zu Hause, aus einem Hotelzimmer in einer anderen Stadt
Das sind voneinander unabhängige Parameter, und genau hier liegt die Quelle der Verwirrung. Der Standort der Person während der Verbindung hat keinerlei Einfluss darauf, ob die Daten Ihre Infrastruktur nach der Verbindung verlassen. Man kann ein System haben, das unter keinen Umständen jemals auf externe APIs zugreift – und trotzdem Mitarbeitern von überall auf der Welt Zugriff gewähren, wenn der Netzwerkperimeter um dieses System herum richtig aufgebaut ist.
Der Unterschied ist ungefähr derselbe wie zwischen "Wer betritt die Bankfiliale?" und "Wohin schickt die Bank Kundengelder?". Das sind zwei separate Sicherheitsprobleme, die mit unterschiedlichen Werkzeugen gelöst werden und nicht zu einer einzigen Anforderung vermischt werden sollten.
Öffentliches API zu einem Cloud-Dienst vs. privater Tunnel zu Ihrer eigenen Infrastruktur
Um den imaginären Widerspruch endgültig aufzulösen, lohnt es sich, beide Szenarien im Detail zu betrachten – was genau passiert in jedem von ihnen mit den Daten.
Aufruf eines Cloud-AI-APIs. Wenn ein System einen Drittanbieter kontaktiert – zum Beispiel, wenn es eine Anfrage an OpenAI oder einen anderen Cloud-AI-Dienst sendet –, geschieht Folgendes: Ein Teil des Dokuments oder die Benutzeranfrage wird in eine HTTP-Anfrage verpackt und an Server gesendet, die physisch diesem Anbieter gehören und von ihm verwaltet werden. Dort wird die Anfrage auf fremden Kapazitäten, mit fremder Software und nach Regeln verarbeitet, die der Anbieter selbst diktiert und nicht Ihr Unternehmen. Die Daten verlassen für einen bestimmten Zeitraum physisch Ihre Infrastruktur und geraten unter die Gerichtsbarkeit und die Richtlinien einer anderen Organisation. Genau dieses Szenario, und nur dieses, verbieten strenge Sicherheitsprotokolle wie "keine externen APIs".
VPN-Tunnel eines Mitarbeiters zu Ihrem Server. Dies ist eine prinzipiell andere Aktion. Wenn sich ein Mitarbeiter über VPN verbindet, findet kein Aufruf an einen externen Datenverarbeitungsdienst statt. Stattdessen wird ein verschlüsselter "Korridor" zwischen dem Gerät des Mitarbeiters und Ihrem eigenen Server geschaffen – genau dem Server, auf dem die Dokumente gespeichert sind und das lokale Modell läuft. Der gesamte Verkehr durch diesen Korridor geht direkt zu Ihrer Infrastruktur und zurück. Kein Dritter erhält Zugriff auf den Inhalt dieses Verkehrs, verarbeitet ihn nicht und sieht ihn nicht einmal in entschlüsselter Form – der VPN-Anbieter (wenn es nicht der eigene Server des Unternehmens ist) sieht im besten Fall die Tatsache der Verbindung, aber nicht deren Inhalt.
Das Verbot des ersten Szenarios erstreckt sich logisch in keiner Weise auf das zweite. Das sind zwei unterschiedliche Richtungen der Datenbewegung:
- Im ersten Fall bewegen sich die Daten nach außen, zur fremden Infrastruktur
- Im zweiten Fall bewegt sich die Person (bildlich gesprochen) nach innen, zu Ihrer eigenen Infrastruktur
Sie werden oft verwechselt, gerade wegen des Wortes "extern", das in beiden Formulierungen intuitiv gleich erscheint – obwohl es sich technisch um Prozesse mit entgegengesetzter Richtung handelt. Das Verständnis dieses Unterschieds ist das Fundament, auf dem die gesamte Architektur des sicheren Fernzugriffs aufgebaut ist, die wir in den folgenden Abschnitten untersuchen werden.
Was ist ein VPN und wie unterscheidet sich ein Corporate VPN von einem üblichen "VPN für Netflix"
Die meisten Menschen haben von VPNs im Kontext von "Netflix USA ansehen" oder "regionale Website-Blockaden umgehen" gehört. Das ist richtig, aber das ist nur eines der möglichen Anwendungsszenarien für VPNs – und nicht unbedingt das, was ein Unternehmen benötigt. Die Verwechslung dieser beiden Szenarien hindert oft nicht-technische Führungskräfte daran zu verstehen, warum VPNs überhaupt als Lösung für strenge Sicherheitsanforderungen in Betracht gezogen werden – denn "VPN für Netflix" assoziiert man eher mit der Umgehung von Beschränkungen als mit Datenschutz.
Consumer VPN: Geolokalisierung ändern
Wenn Sie in Kiew ein "USA" VPN einschalten, geht Ihr Datenverkehr nicht direkt zu der Website, die Sie besuchen. Stattdessen gelangt er zuerst zu einem Zwischenserver des VPN-Anbieters irgendwo in New York, und von dort geht er weiter ins Internet. Jede Website, die Sie besuchen, sieht die IP-Adresse dieses Zwischenservers – und denkt, Sie befinden sich physisch dort, nicht in Kiew.
Das Ziel eines solchen VPNs ist es, Ihre tatsächliche Position beim Surfen im normalen öffentlichen Internet zu verbergen oder zu fälschen. Der Endpunkt der Route ist immer eine öffentlich zugängliche Website oder ein Dienst, der grundsätzlich für jeden auf der Welt offen ist. Das VPN dient hier als "Maske", nicht als "Schlüssel zu verschlossenen Türen".
Corporate VPN: Tunnel in ein geschlossenes Netzwerk
Ein Corporate VPN löst eine völlig andere Aufgabe. Sein Ziel ist es nicht, zu verbergen, wo Sie sich befinden, sondern Ihnen Zugang zu dem zu verschaffen, wozu ein normaler Internetnutzer überhaupt keinen Zugang hat: in das interne, geschlossene Netzwerk des Unternehmens, das grundsätzlich aus dem öffentlichen Internet nicht sichtbar ist.
Hier gibt es keine "Zwischenserver in einem anderen Land", der Ihre Geolokalisierung verschleiert. Stattdessen gibt es eine direkte verschlüsselte Verbindung zwischen Ihrem Gerät und einem bestimmten Server des Unternehmens. Dieser Server hat normalerweise keine öffentliche IP-Adresse – das heißt, er ist physisch nicht mit einer normalen Anfrage aus dem Internet erreichbar, egal wie Ihr Browser oder Standort aussieht. Die einzige Möglichkeit, dorthin zu gelangen, ist, den richtigen Zugangsschlüssel (ein Zertifikat oder eine Konfiguration) zu haben, den das Unternehmen speziell für Sie ausgestellt hat.
Consumer VPN vs Corporate VPN: Vergleich
| Kriterium | Consumer VPN | Corporate VPN |
|---|---|---|
| Ziel | Geolokalisierung verbergen/fälschen | Zugang zum geschlossenen internen Netzwerk ermöglichen |
| Zielserver | Öffentliches Internet (Google, Netflix, beliebige Websites) | Spezifischer interner Unternehmensserver |
| Sichtbarkeit des Servers von außen | Nicht anwendbar – es geht um öffentliche Websites | Server hat oft überhaupt keine öffentliche IP – unsichtbar für das normale Internet |
| Wer sich verbinden kann | Jeder, der das Service-Abonnement bezahlt hat | Nur wer einen persönlichen Zugangsschlüssel erhalten hat |
| Typischer Benutzer | Privatperson | Mitarbeiter des Unternehmens |
Diese Tabelle zeigt das Gesamtbild, aber auch innerhalb der Kategorie Corporate VPN gibt es Auswahlmöglichkeiten – insbesondere zwischen verschiedenen Protokollen. Wenn Sie an einem detaillierten Vergleich von WireGuard und OpenVPN für Unternehmen interessiert sind, haben wir das in einem separaten Artikel behandelt.
Analogie: "Virtuelles Kabel ins Büro"
Am einfachsten stellt man sich ein Corporate VPN so vor: Sie verbinden von zu Hause aus ein virtuelles Netzwerkkabel direkt mit dem Büronetzwerk. Ihr Laptop wird technisch gesehen "teleportiert" ins Büro – Sie sehen dieselben internen Ressourcen, auf die Sie zugreifen würden, wenn Sie am Schreibtisch sitzen würden: interne Dienste, freigegebene Ordner, und in unserem Fall – die Benutzeroberfläche des KI-Assistenten auf der internen Serveradresse.
Dabei fliesst Ihr übriger Internetverkehr (E-Mail, normale Websites, soziale Netzwerke) nicht über dieses "Kabel" – nur der Verkehr, der für den internen Unternehmensserver bestimmt ist. Das nennt man Split-Tunneling, und genau so wird ein Corporate VPN normalerweise eingerichtet – um den internen Unternehmenskanal nicht mit überflüssigem Datenverkehr zu überlasten und das normale Surfen im Internet des Mitarbeiters nicht zu verlangsamen.
Wichtiger Hinweis: Im Gegensatz zu Consumer VPNs, bei denen das Ziel ist, "von woanders" auszusehen, spielt die Geolokalisierung des Mitarbeiters bei Corporate VPNs überhaupt keine Rolle. Egal ob aus Kiew oder aus einem Hotel in einer anderen Stadt – das Ergebnis ist dasselbe: eine direkte, kontrollierte Verbindung zum internen Unternehmensserver, ohne einen einzigen Zwischenvermittler, der die Daten verarbeitet oder einsehen kann.
Warum kann man die Weboberfläche nicht einfach ins Internet stellen?
Eine logische Frage: Wenn AskYourDocs eine Webanwendung ist, warum nicht einfach einen Port nach außen öffnen und über den normalen Browser darauf zugreifen? In der Praxis birgt dies sofort mehrere ernsthafte Risiken.
- Scanner finden ihn sofort. Jeder offene Port im Internet gerät innerhalb weniger Stunden nach seinem Erscheinen ins Visier automatischer Scanner (Shodan, masscan und ähnliche) – unabhängig davon, wie "unauffällig" die Adresse erscheint.
- Brute-Force-Angriffe beginnen. Ein nach außen geöffnetes Login-Formular erhält fast sofort eine Flut von automatisierten Versuchen, Passwörter zu erraten – das ist keine Frage von "ob", sondern von "wann".
- WAF erforderlich. Um bösartige Anfragen (SQLi, XSS und andere Angriffe auf Anwendungsebene) zu filtern, muss ein Web Application Firewall (WAF) eingesetzt und gewartet werden – eine zusätzliche Komponente mit Konfiguration und Kosten.
- Schutz vor Bots erforderlich. Ohne eine separate Anti-Bot/Rate-Limiting-Schicht verbraucht der Server Ressourcen für die Verarbeitung von bösartigem Datenverkehr anstelle von echten Benutzern, und die Protokolle füllen sich mit Rauschen, in dem echte verdächtige Aktivitäten schwer zu erkennen sind.
VPN eliminiert all diese Risiken auf einmal: Der Dienst ist einfach nicht von außen sichtbar. Kein offener Port – nichts zu scannen, zu erraten oder anzugreifen. Anstatt einen Schutzperimeter um eine öffentliche Anwendung herum aufzubauen, nehmen wir sie komplett aus dem öffentlichen Raum heraus und lassen den Zugriff nur über einen verschlüsselten WireGuard-Tunnel zu.
Warum wir WireGuard verwenden
Wir haben WireGuard nicht aus modischen Gründen gewählt, sondern aufgrund spezifischer technischer Vorteile, die sich direkt auf die Geschwindigkeit und Zuverlässigkeit des Zugriffs auf AskYourDocs auswirken.
- Moderne Kryptographie. WireGuard basiert auf einem aktuellen Satz kryptografischer Primitive (Noise Protocol Framework, Curve25519, ChaCha20Poly1305), ohne veraltete Algorithmen und ohne "überflüssige Optionen", die separat konfiguriert und auf Sicherheit überprüft werden müssten.
- Höhere Geschwindigkeiten im Vergleich zu OpenVPN. Geringerer Protokoll-Overhead und die Arbeit auf Kernelebene (für Linux) bieten eine spürbar bessere Bandbreite und geringere Latenz – das ist selbst bei normaler Arbeit mit Dokumenten über AskYourDocs spürbar.
- Einfachere Konfiguration. Eine Konfigurationsdatei mit einem Schlüsselpaar – und der Client ist bereit für die Verbindung. Keine komplizierte Verteilung von Zertifikaten wie bei einem klassischen OpenVPN-Setup.
- Weniger Code – weniger Angriffsfläche. Der WireGuard-Kern besteht aus etwa 4.000 Codezeilen, verglichen mit Hunderttausenden bei OpenVPN/OpenSSL. Weniger Code ist leichter zu prüfen und es gibt weniger Stellen, an denen Schwachstellen lauern könnten.
- Plattformübergreifend. Offizielle Clients gibt es für Linux, Windows, macOS, Android und iOS/iPhone – der Mitarbeiter verbindet sich von jedem Gerät aus genauso einfach.
Ein detaillierter Vergleich mit der Alternative finden Sie in unserem separaten Artikel: WireGuard vs OpenVPN: Was für Unternehmen wählen?.
Wie sich Fernzugriff in die Architektur einer Self-Hosted-Lösung einfügt
Nun fügen wir alles zusammen und sehen uns an, wie das auf der Ebene der tatsächlichen Architektur eines Self-Hosted-KI-Assistenten aussieht – nicht abstrakt, sondern Schritt für Schritt, von dem Moment an, in dem ein Mitarbeiter zu Hause seinen Laptop öffnet, bis zu dem Moment, in dem er eine Antwort auf dem Bildschirm erhält.
Der Anfragepfad des Mitarbeiters
- Der Mitarbeiter aktiviert den VPN-Client auf seinem Gerät (zu Hause, auf Geschäftsreise – überall, der Standort spielt keine Rolle)
- Ein verschlüsselter Tunnel zum internen Unternehmensnetzwerk wird aufgebaut – ab diesem Moment "befindet" sich das Gerät des Mitarbeiters technisch gesehen innerhalb des Büronetzwerks
- Der Mitarbeiter öffnet den Browser und ruft die interne Serveradresse auf (z. B. ein interner DNS-Alias wie
askyourdocs.internal) – genau so, wie er es von seinem Arbeitsplatz im Büro tun würde - Die Anfrage erreicht den internen Server, auf dem das gesamte System läuft – die Weboberfläche, die lokale LLM, die Dokumentendatenbank. Alle diese Komponenten befinden sich physisch auf einem Server oder in einem internen Netzwerk des Unternehmens
- Das lokale Modell verarbeitet die Anfrage und generiert eine Antwort, ohne jegliche externe Anfragen – die Suche in Dokumenten, die Vektorsuche, die Textgenerierung durch das Modell erfolgen lokal, ohne eine einzige HTTP-Anfrage außerhalb des Perimeters
- Die Antwort wird über denselben verschlüsselten Tunnel an den Mitarbeiter zurückgesendet – derselbe "Korridor", über den die Anfrage gekommen ist
In keinem dieser Schritte verlassen die Daten den Unternehmensperimeter. Es gibt keinen Moment, in dem ein Teil des Dokuments oder die Anfrage des Mitarbeiters auf dem Server eines Drittanbieters landet – die gesamte Route, vom ersten bis zum letzten Schritt, bleibt innerhalb des Netzwerks, das das Unternehmen selbst kontrolliert.
Warum das gerade für Kunden mit strengen Anforderungen entscheidend ist
Für ein normales Unternehmen liegt der Unterschied zwischen einer "Cloud"- und einer "Self-Hosted"-Lösung oft im Bereich der Bequemlichkeit – etwas längere Einrichtung für etwas mehr Kontrolle. Aber für bestimmte Branchen ist dies keine Frage der Bequemlichkeit, sondern eine Frage der Einhaltung von regulatorischen und internen Sicherheitsanforderungen, deren Nichteinhaltung ganz konkrete Folgen hat:
- Kritische Infrastruktur – die Offenlegung technischer Dokumentation, Wartungsanleitungen oder Systemdiagramme kann Folgen haben, die weit über Reputationsverlust hinausgehen. In dieser Branche gelten oft separate Cybersicherheitsstandards (z. B. IEC 62443 für industrielle Steuerungssysteme), die die Isolierung von Netzwerken mit kritischen Daten direkt regeln
- Rechtswesen – die Vertraulichkeit von Kundendokumenten ist oft vertraglich (NDA, Mandatsbedingungen) geregelt und nicht nur als gute Praxis erwünscht. Die Übermittlung von Dokumententeilen eines Kunden an einen externen KI-Anbieter ohne ausdrückliche Genehmigung kann eine Verletzung dieser vertraglichen Verpflichtungen darstellen
- Finanzen – regulatorische Anforderungen an die Verarbeitung von Kundendaten (je nach Gerichtsbarkeit – das kann die DSGVO in Europa oder Branchenstandards wie PCI DSS für Zahlungsdaten sein) verbieten in der Regel ausdrücklich die Übermittlung von persönlichen oder Finanzdaten an Dritte ohne gesonderte Genehmigung oder Datenverarbeitungsvereinbarung
Hinweis: Die aufgeführten Beispiele für Verordnungen veranschaulichen den allgemeinen Kontext der Branche und stellen keine Rechtsberatung für Ihre spezifische Situation dar – die genaue Einhaltung sollte mit Ihrer Compliance-Abteilung oder Ihrem Anwalt überprüft werden.
Für solche Unternehmen ist die Architektur "alles bleibt innerhalb des Perimeters, der Zugriff nur über einen kontrollierten Tunnel" keine zusätzliche Option, sondern die Grundvoraussetzung, unter der die Lösung überhaupt in Betracht gezogen werden kann. Deshalb existiert der Self-Hosted-Ansatz mit VPN-Zugang nicht als Kompromiss zwischen Sicherheit und Bequemlichkeit, sondern als Möglichkeit, beides gleichzeitig zu erhalten: volle Kontrolle über die Daten und vollen Fernzugriff für das Team.