Welche Teile einer selbstgehosteten Anwendung benötigen Internetzugang? Eine Checkliste zur Zuordnung der Exponierung

Warum „öffentlich erreichbar“ keine vollständige Bereitstellungsanforderung ist

„Die Anwendung muss öffentlich sein“ kann sehr unterschiedliche Dinge bedeuten. Es kann heißen, dass jede Person eine Website aufrufen können soll, dass sich nur namentlich benannte Mitarbeitende von überall anmelden dürfen, dass ein Partnersystem Webhooks zustellen muss oder dass die Anwendung lediglich eine externe API aufrufen muss. Diese Anforderungen führen zu unterschiedlichen Entscheidungen über die Netzwerkexponierung.

Behandeln Sie eingehende Erreichbarkeit und ausgehende Konnektivität als getrennte Entscheidungen. In Docker-Netzwerken kann ein Container ausgehende Verbindungen herstellen, wenn sein Host Internetzugang hat, während ein Container-Port normalerweise nicht von außerhalb des Hosts erreichbar ist, sofern er nicht bewusst veröffentlicht oder weitergeleitet wird. Eine Anwendung kann daher Internetzugang benötigen, ohne einen öffentlich erreichbaren Anwendungsport zu brauchen.

Das Ziel ist nicht, jede Komponente privat oder jede Komponente öffentlich zu machen. Ziel ist, jeden Datenfluss ausdrücklich zu autorisieren, nur die erforderlichen Einstiegspunkte offenzulegen und zu dokumentieren, warum jeder davon existiert. Dies entspricht dem Ergebnis des NIST Cybersecurity Framework 2.0, Darstellungen autorisierter interner und externer Netzwerkkommunikation und Datenflüsse aufrechtzuerhalten.

• Ersetzen Sie „öffentlich“ durch eine konkrete Aussage: Wer verbindet sich, von wo, mit welchem Hostnamen, über welches Protokoll und zu welchem Zweck?
• Trennen Sie Browserzugriff, eingehende Machine-to-Machine-Anfragen, ausgehende Aufrufe und Administratorzugriff.
• Entscheiden Sie für jeden Fluss, ob er über das öffentliche Internet, nur von bekannten IP-Adressen, ausschließlich über private Netzwerke oder gar nicht zulässig ist.
• Dokumentieren Sie die in jedem Fluss ausgetauschten Daten, insbesondere Zugangsdaten, personenbezogene Daten, Kundendatensätze, Dateien und API-Tokens.

Beginnen Sie mit einer Exponierungszuordnung: Nutzer, Administratoren, Integrationen und unterstützende Dienste

Eine Exponierungszuordnung ist ein praktisches Inventar der zulässigen Kommunikationspfade einer Anwendung. Erstellen Sie sie, bevor Sie Domains auswählen, Firewall-Regeln öffnen oder Container-Ports veröffentlichen. Sie sollte mehr abdecken als den Hauptbildschirm der Anwendung: Unterstützende Dienste, Administrationstools, Identitätssysteme, E-Mail-Anbieter und Monitoring-Ziele können jeweils Netzwerkabhängigkeiten schaffen.

Beginnen Sie mit der Auflistung von Ressourcen und Akteuren. NIST CSF 2.0 betrachtet Software, Dienste, Systeme, Daten und Lieferantendienste als Ressourcen, die identifiziert und verwaltet werden müssen. Für eine selbstgehostete Bereitstellung bedeutet dies, sowohl eigene Komponenten als auch die externen Dienste zu dokumentieren, mit denen sie kommunizieren.

Zeichnen Sie anschließend gerichtete Pfeile. Jeder Pfeil sollte einen Verantwortlichen und eine Entscheidung haben: erlaubt, eingeschränkt, nur privat oder abgelehnt. Dadurch werden verborgene Annahmen früh sichtbar – etwa ein Automatisierungs-Workflow, der einen Webhook eines Anbieters empfangen muss, oder ein internes Dashboard, bei dem vorausgesetzt wurde, dass es aus jedem Mitarbeitendennetz erreichbar ist.

• Nutzer: öffentliche Besucher, Kunden, Mitarbeitende, Auftragnehmer, mobile Nutzer und Dienstkonten.
• Administratoren: Anwendungsadministratoren, Infrastrukturadministratoren und Supportpersonal.
• Eingehende Integrationen: Webhooks, API-Clients, Rückrufe von Identitätsanbietern und Partnersysteme.
• Ausgehende Integrationen: E-Mail-Zustellung, Identitätsanbieter, externe APIs, Software-Downloads, Modelldownloads und Monitoring-Ziele.
• Unterstützende Dienste: Datenbanken, Caches, Queues, Objektspeicher, Suchdienste, Reverse Proxies und Administrations-Dashboards.
• Erfassen Sie für jeden Fluss Quelle, Ziel, Protokoll und Port, Hostname, Richtung, Authentifizierungsmethode, Datenklassifizierung, Verantwortlichen und geschäftliche Begründung.

Klassifizieren Sie eingehenden Zugriff: öffentliche Weboberfläche, authentifizierte Nutzer, Partnerendpunkte und Webhook-Empfänger

Eingehender Zugriff ist das, was die meisten Teams mit Exponierung meinen, sollte jedoch in verschiedene Klassen aufgeteilt werden. Eine öffentliche Marketing- oder Veröffentlichungsoberfläche hat ein anderes Risikoprofil als eine Anwendung nur für Mitarbeitende. Ein Webhook-Empfänger muss möglicherweise Anfragen von einem externen System akzeptieren, auch wenn keine für Menschen bestimmte Oberfläche breit verfügbar sein soll.

Nutzen Sie den Reverse Proxy als bewussten eingehenden Einstiegspunkt. Im Modell von Traefik nehmen Entry Points TCP- oder UDP-Verkehr entgegen, Router gleichen eingehende Anfragen ab und Dienste erhalten den weitergeleiteten Backend-Verkehr. Dies unterstützt ein Design, bei dem der Proxy nur genehmigten Verkehr akzeptiert, während Anwendungscontainer dahinter bleiben.

Wenn ein Endpunkt nur von bekannten Parteien verwendet wird, dokumentieren Sie, ob zusätzlich zur Authentifizierung auf Anwendungsebene eine IP-basierte Regel geeignet ist. Traefik bietet einen IP-Allowlist-Mechanismus, der Anfragen akzeptiert oder ablehnt, bevor sie ein Backend erreichen. Dies kann unnötige Exponierung reduzieren, hängt jedoch von stabilen und korrekt identifizierten Quelladressen ab und sollte nicht als Ersatz für angemessene Authentifizierung betrachtet werden.

• Öffentliche Weboberfläche: für nicht authentifizierte Besucher vorgesehen; legen Sie nur die erforderlichen Webrouten und den erforderlichen Hostnamen offen.
• Zugriff authentifizierter Nutzer: für Kunden oder Mitarbeitende vorgesehen; definieren Sie Identitäts-, Anmelde-, Sitzungs- und Zugriffsanforderungen im Anwendungsdesign.
• Partner-API-Endpunkt: definieren Sie den Partner, die Authentifizierungsmethode, das erwartete Quellnetzwerk, erwartete Raten und die genauen Routen.
• Webhook-Empfänger: definieren Sie Absender, Signatur- oder Authentifizierungsprüfung, Route, erwartete Payload-Daten und Fehlerbehandlung.
• Administrationsoberfläche: klassifizieren Sie sie getrennt von der Hauptanwendung; nehmen Sie nicht an, dass sie auf den öffentlichen Hostnamen gehört.
• Lehnen Sie pauschale Exponierung ab: Ein extern erreichbarer Port oder Hostname sollte einen benannten Zweck und einen Verantwortlichen haben.

Ermitteln Sie ausgehende Abhängigkeiten, bevor Sie annehmen, dass die Anwendung privat betrieben werden kann

Privater eingehender Zugriff bedeutet nicht, dass eine Anwendung keine Internetabhängigkeit hat. Viele Geschäfts-, Automatisierungs- und KI-Workloads müssen Verbindungen zu Diensten außerhalb des Hosts initiieren. Dazu können E-Mail-Zustelldienste, Identitätsanbieter, Drittanbieter-APIs, Paketquellen, Modelldownloads oder Monitoring-Ziele gehören.

Bestimmen Sie für jede Abhängigkeit, ob sie bei der Installation, beim Start, nach Zeitplan oder während der normalen Nutzeraktivität erforderlich ist. Diese Unterscheidung ist in eingeschränkten Umgebungen wichtig. Ein einmaliger Software- oder Modelldownload kann anders behandelt werden als eine dauerhaft bestehende Verbindung zu einem Identitätsanbieter oder einer externen Geschäfts-API.

Beschreiben Sie ausgehenden Zugriff nicht als eine einzige pauschale Berechtigung. Identifizieren Sie Ziel-Hostname oder Dienst, Protokoll, Betriebszweck, gesendete und empfangene Daten, verwendete Zugangsdaten und das Ausweichverhalten, wenn das Ziel nicht verfügbar ist. Prüfen Sie die offizielle Dokumentation der jeweiligen Anwendung und Integration, da Abhängigkeiten je nach Produkt und Konfiguration variieren.

• E-Mail-Zustellung: identifizieren Sie den Anbieter, die Verbindungsmethode, die Absenderidentität und ob die Anwendung Passwortzurücksetzungen, Benachrichtigungen oder Workflow-Nachrichten senden muss.
• Identitätsanbieter: identifizieren Sie Authentifizierungsendpunkte, Token-Endpunkte, Ausstellerdetails und ob die Anmeldung nicht mehr funktioniert, wenn der Anbieter nicht erreichbar ist.
• Externe APIs: führen Sie jeden Anbieter getrennt auf, ebenso die ausgetauschten Daten, den Ansatz zur Speicherung von Zugangsdaten und ob Aufrufe nutzergesteuert oder automatisiert erfolgen.
• Paket-, Plugin- oder Modelldownloads: klären Sie, ob Internetzugang nur bei Einrichtung oder Updates oder regelmäßig zur Laufzeit benötigt wird.
• Monitoring und Fehlerberichterstattung: klären Sie, welche Telemetrie- oder Ereignisdaten die Umgebung verlassen und wer diese Übertragung genehmigt.
• Update-Prüfungen und lizenzbezogene Aufrufe: prüfen Sie diese direkt in der offiziellen Herstellerdokumentation, statt anzunehmen, dass sie erforderlich sind oder fehlen.

Halten Sie Datendienste standardmäßig privat

Eine Datenbank, ein Cache, eine Queue, ein Objektspeicher oder ein Suchdienst ist üblicherweise eine unterstützende Komponente und kein internetfähiges Produkt. Beginnen Sie mit ausschließlich privatem Zugriff und fügen Sie eine Route nur hinzu, wenn es einen dokumentierten betrieblichen Grund gibt. In einer Docker-Bridge-Konfiguration können Dienste, die mit dem Host oder demselben Netzwerk verbunden sind, wie konfiguriert kommunizieren, während Container-Ports standardmäßig nicht von außerhalb des Hosts zugänglich sind, sofern sie nicht veröffentlicht oder anderweitig bewusst weitergeleitet werden.

Seien Sie besonders vorsichtig beim bequemen Veröffentlichen von Ports. Docker dokumentiert, dass das Veröffentlichen eines Ports ohne Angabe einer Hostadresse standardmäßig an alle Hostadressen bindet, wodurch der Dienst extern erreichbar werden kann. Wenn ein Dienst im dokumentierten NAT-Modus-Szenario nur für den lokalen Host vorgesehen ist, verhindert die Bindung an Loopback, dass entfernte Hosts auf diesen veröffentlichten Port zugreifen.

Administrations-Control-Planes verdienen dieselbe standardmäßig private Behandlung. Traefik warnt, dass seine Produktions-API und sein Dashboard Konfigurationselemente einschließlich sensibler Daten offenlegen können, und empfiehlt, seinen API-Port auf interne Netzwerke zu beschränken. Wenden Sie dieses Prinzip auch auf Anwendungsadministrationsoberflächen, Schnittstellen zur Containerverwaltung und Observability-Tools an.

• Datenbanken: erlauben Sie Zugriff nur für Anwendungskomponenten und genehmigte Wartungswege.
• Caches und Queues: halten Sie sie in privaten Netzwerken; legen Sie sie nicht nur zur Vereinfachung der Fehlerbehebung offen.
• Objektspeicher und interne Dateidienste: definieren Sie, welche Anwendungskomponenten Zugriff benötigen und wie Backups mit ihnen interagieren.
• Such-, Vektor- und KI-Unterstützungsdienste: dokumentieren Sie, ob sie interne Backends oder bewusst bereitgestellte APIs für andere Systeme sind.
• Proxy-Dashboards, Anwendungs-Adminpanels und Infrastruktur-Control-Planes: verwenden Sie getrennte, eingeschränkte Zugriffswege.
• Überprüfen Sie vor dem Start jeden veröffentlichten Port und bestätigen Sie seine Host-Bindung, die vorgesehenen Clients und den Verantwortlichen.

Prüfen Sie häufige Sonderfälle, die das Zugriffskonzept verändern

Mehrere Bereitstellungsdetails werden leicht erst spät entdeckt, nachdem bereits ein Hostname oder eine Firewall-Richtlinie ausgewählt wurde. Behandeln Sie sie frühzeitig, da sie bestimmen können, ob ein öffentlicher Hostname, ein stabiler Callback-Pfad oder eine bestimmte Netzwerkquelle erforderlich ist.

OAuth ist ein wichtiges Beispiel. Weiterleitungs- und Callback-URLs sind Bereitstellungsanforderungen und keine kosmetischen Einstellungen. RFC 9700 verlangt von Autorisierungsservern einen exakten String-Abgleich mit vorregistrierten Redirect-URIs, abgesehen von der angegebenen Localhost-Behandlung für native Apps. Ein geändertes Schema, ein geänderter Hostname, Pfad oder abschließender Schrägstrich kann daher die Anmeldung unterbrechen.

Sichern Sie auch den Callback-Pfad selbst. RFC 9700 warnt davor, dass Redirect-URI-Endpunkte nicht als offene Weiterleitungen fungieren dürfen. Zudem wird ein Risiko benannt, wenn Seiten zur Verarbeitung von OAuth-Antworten auf angreifergesteuerte Seiten verlinken oder Drittanbieterinhalte laden, die die URL der Autorisierungsantwort über den Referer-Header offenlegen könnten. Halten Sie die Callback-Verarbeitung bewusst eng begrenzt und vermeiden Sie unnötige eingebettete Drittanbieterinhalte auf dieser Seite.

• OAuth und SSO: bestätigen Sie die genaue externe URL, das Protokoll, den Hostnamen und den Callback-Pfad, die beim Identitätsanbieter registriert werden müssen.
• Eingebettete Inhalte: identifizieren Sie Iframes, Skripte, Bilder oder Widgets, die Verbindungen zu Dritten herstellen, insbesondere auf Seiten für Authentifizierungsantworten.
• Mobile und Desktop-Clients: bestätigen Sie, ob sie einen öffentlichen Endpunkt, einen festen Hostnamen, Localhost-Behandlung oder einen privaten Netzwerkpfad benötigen.
• IP-Allowlists: validieren Sie die tatsächlichen Quelladressen, nachdem Zwischeninstanzen, NAT, Content-Delivery-Netzwerke oder Partnerinfrastruktur berücksichtigt wurden.
• Eingehende E-Mails oder Dateiübertragungen: bestimmen Sie, ob sie direkt an die Anwendung zugestellt oder ausgehend von einem anderen Dienst abgerufen werden.
• WebSockets, Streaming und langlebige Verbindungen: prüfen Sie Anforderungen von Proxy und Anwendung in der offiziellen Dokumentation, statt anzunehmen, dass gewöhnliche HTTP-Standardwerte ausreichen.

Fragen, die vor der Bereitstellung in der offiziellen Anwendungsdokumentation geprüft werden sollten

Die Anwendungsdokumentation ist die maßgebliche Quelle für produktspezifische Anforderungen. Leiten Sie nicht allein daraus ab, dass eine Anwendung eine private Bereitstellung, ein bestimmtes Proxy-Verhalten, einen SSO-Anbieter oder ein Webhook-Muster unterstützt, weil eine andere Anwendung dies tut. Bestätigen Sie die Anforderungen anhand der offiziellen Dokumentation für die Version und Konfiguration, die Sie verwenden möchten.

Die Antworten sollten in der Exponierungszuordnung erfasst und bei Änderungen an Integrationen erneut geprüft werden. Falls die Dokumentation eine Frage offenlässt, behandeln Sie sie als Implementierungsrisiko, statt die Lücke mit einer Annahme zu füllen.

Diese Prüfung ist besonders wichtig für Anwendungen, die eine Weboberfläche mit Hintergrund-Workern, Automatisierungs-Engines, KI-Modelldiensten oder mehreren unterstützenden Containern kombinieren. Die sichtbare Browseroberfläche ist oft nur ein Teil des Betriebsdesigns.

• Welche eingehenden Ports und Protokolle werden gegebenenfalls benötigt, und welche Komponente beendet TLS?
• Kann die Anwendung hinter einem Reverse Proxy betrieben werden, und benötigt sie Einstellungen für vertrauenswürdige Proxies oder externe URLs?
• Welche kanonische URL oder Basis-URL benötigt die Anwendung?
• Welche Routen müssen Webhooks, OAuth-Callbacks, SSO-Assertions oder Partner-API-Anfragen empfangen?
• Welche ausgehenden Hostnamen oder Dienstkategorien sind für normalen Betrieb, Einrichtung, Updates, E-Mail, Identität, Monitoring oder optionale Integrationen erforderlich?
• Welche Datendienste werden benötigt und sollten deren Ports privat bleiben?
• Werden getrennte Worker-Prozesse oder -Container benötigt, und was müssen sie erreichen können?
• Welche Backup-Daten, Speicherorte und Wiederherstellungsschritte sind erforderlich? Airbip bietet konfigurierbare tägliche, wöchentliche und monatliche Backups, doch der Verantwortliche für die Anwendung muss weiterhin entscheiden, welche Daten in den Umfang gehören, und für seine Umgebung geeignete Wiederherstellungsverfahren testen.

Integrieren Sie Domains, TLS und Reverse Proxies in das Design, ohne unnötige Dienste offenzulegen

Wählen Sie Domains, nachdem Sie die vorgesehenen Einstiegspunkte ermittelt haben. Ein Hostname sollte einen bewussten Zugriffszweck darstellen, etwa eine nutzerseitige Anwendung, einen eng begrenzten Webhook-Endpunkt oder einen Administrationspfad mit zusätzlichen Einschränkungen. Vermeiden Sie es, öffentliche DNS-Namen für interne Dienste anzulegen, nur weil sie bequem zu merken sind.

Die Validierung von TLS-Zertifikaten ist ebenfalls Teil des Exponierungsdesigns. Bei der HTTP-01-Validierung von Let’s Encrypt ruft die Zertifizierungsstelle eine Challenge-Datei unter dem Hostnamen ab, und die HTTP-01-Challenge ist auf Port 80 beschränkt. Das kann für einen öffentlichen Webendpunkt geeignet sein, ist jedoch eine konkrete Erreichbarkeitsanforderung, die eingeplant werden muss. Die DNS-01-Validierung von Let’s Encrypt kann Namen validieren, deren Webserver nicht dem öffentlichen Internet ausgesetzt sind, da die Validierung über einen DNS-TXT-Eintrag erfolgt.

Ein Reverse Proxy ermöglicht es einem Team, den Proxy – und nicht jede Anwendungskomponente – zum ausgewählten öffentlichen Edge zu machen. Er kann genehmigte Hostnamen und Pfade zu Backend-Diensten weiterleiten, während Backend-Ports privat bleiben. Das macht eine Architektur nicht automatisch sicher; das Team benötigt weiterhin eine korrekte Anwendungskonfiguration, Zugriffskontrollen, DNS-Inhaberschaft, Zertifikatserneuerung und Change Control.

Airbip stellt Kataloganwendungen als Docker-Workloads auf Airbip-Cloud-Servern bereit und automatisiert Routing und TLS-Zertifikate über Traefik und Let’s Encrypt. Kunden können eine Airbip-Subdomain oder eine kompatible benutzerdefinierte Domain verwenden. Diese Funktionen sind nützlich, wenn das dokumentierte Design einen verwalteten öffentlichen Anwendungsendpunkt erfordert, ersetzen aber nicht die Entscheidung darüber, welche Routen und Datenflüsse genehmigt sind.

• Weisen Sie für jede DNS-Zone und jeden Hostnamen einen Verantwortlichen zu.
• Dokumentieren Sie anhand des Zugriffskonzepts, ob die Zertifikatsvalidierung einen öffentlichen HTTP-Pfad oder DNS-Validierung verwendet.
• Legen Sie die Reverse-Proxy-Einstiegspunkte offen, die von den genehmigten öffentlichen Diensten benötigt werden; halten Sie Backend-Dienstports privat.
• Nutzen Sie getrennte Hostnamen oder sorgfältig eingegrenzte Routen, wenn sich öffentliche und eingeschränkte Funktionen innerhalb der Anwendung nicht sauber trennen lassen.
• Testen Sie das extern sichtbare Ergebnis von außerhalb des Servernetzwerks, nicht nur vom Host selbst.
• Prüfen Sie Verantwortlichkeiten für Zertifikatserneuerung und DNS-Änderungen als Teil der betrieblichen Zuständigkeit.