Eine selbst gehostete App oder mehrere? Ein Entscheidungsrahmen für die Trennung von Teams und Kunden

Ein Arbeitsbereich, eine Rolle und eine Bereitstellung lösen unterschiedliche Probleme

Die Frage ist nicht einfach, ob Personen unterschiedliche Ordner, Projekte oder Datensätze sehen sollen. Entscheidend ist, welche Grenze durchgesetzt werden muss, wer auf jeder Seite dieser Grenze als vertrauenswürdig für den Betrieb gilt und wie unabhängig jede Gruppe Änderungen vornehmen und sich von Störungen erholen muss.

Eine Rolle innerhalb der Anwendung regelt üblicherweise, was ein authentifizierter Benutzer tun darf. Ein Arbeitsbereich, eine Organisation, ein Projekt oder ein ähnlicher logischer Container kann Datensätze organisieren und einschränken, welche Benutzer sie ansehen oder bearbeiten dürfen. Diese Kontrollen können wirksam sein, wenn die Anwendung sie gut umsetzt und sie konfiguriert, überprüft und getestet werden. Sie bleiben jedoch Kontrollen innerhalb einer Anwendungsbereitstellung.

Eine separate Bereitstellung ist eine Infrastruktur- und Betriebsgrenze. In einer containerbasierten Einrichtung fasst ein [Docker-Compose-Projekt](https://docs.docker.com/compose/intro/compose-application-model/) die Ressourcen einer Bereitstellung zusammen und kann sie von anderen Installationen mit anderen Parametern trennen. Ein separates Projekt kann auch über ein eigenes Standardnetzwerk verfügen. Das macht es weder zu einem vollständig unabhängigen Host noch beseitigt es die Bedeutung der Host-Administration, unterscheidet sich aber wesentlich davon, einen weiteren Arbeitsbereich in derselben Anwendung anzulegen.

Verwenden Sie einen Arbeitsbereichsnamen nicht als Kurzform für eine Sicherheitsarchitektur. Stellen Sie zuerst fest, was die Anwendung tatsächlich isoliert; entscheiden Sie dann, ob diese Isolierung dem Versprechen gegenüber einem Team, Kunden, einer Rechtseinheit oder Aufsichtsbehörde entspricht.

• Benutzerrollen-Grenze: Welche angemeldeten Benutzer dürfen welche Aktionen ausführen?
• Logische Datengrenze: Auf welche Datensätze, Projekte oder Arbeitsbereiche dürfen Benutzer innerhalb einer Anwendung zugreifen?
• Bereitstellungsgrenze: Welche Anwendungsdienste, Konfigurationen, persistenten Daten, Zugangsdaten, Routen und Release-Zeitpläne gehören zusammen?
• Host-Administrator-Grenze: Wer darf Server, Container-Laufzeit, Speicher und Bereitstellungskonfiguration administrieren?
• Wiederherstellungsgrenze: Welche Daten können unabhängig wiederhergestellt werden, durch wen und mit welchen Auswirkungen auf andere Benutzer?

Benennen Sie zuerst die tatsächliche Grenze

Ein Team ist nicht immer die Einheit, die getrennt werden muss. Die relevante Grenze kann eine Kundenorganisation, eine Rechtseinheit, ein Geschäftsbereich mit eigenen Administratoren, eine Produktionsumgebung oder eine Datenkategorie mit besonderen Anforderungen an die Verarbeitung sein. Ein hilfreiches Design beginnt mit einer klaren Formulierung dessen, was die Grenze nicht überschreiten darf.

Beispielsweise ist „Die Mitarbeitenden von Kunde A dürfen nicht auf die Datensätze von Kunde B zugreifen“ primär eine Anforderung an den Anwendungszugriff. „Kunde A muss über einen separat wiederherstellbaren Datenbestand, separat verantwortete Integrationen verfügen und darf nicht von der Release-Freigabe von Kunde B abhängen“ erfordert eine stärkere Betriebsgrenze. „Ein externer Kunde darf unseren internen Administratoren nicht hinsichtlich des Zugriffs auf seine Dienstkonfiguration und gespeicherten Daten vertrauen müssen“ wirft eine Frage des Hostings und des administrativen Vertrauens auf, nicht nur eine Frage des Rollendesigns.

Wenn personenbezogene Daten betroffen sind, sollte die Governance sowohl Prävention als auch Wiederherstellung abdecken. [Artikel 5 DSGVO](https://eur-lex.europa.eu/eli/reg/2016/679/oj?locale=EN) verlangt geeignete technische oder organisatorische Maßnahmen zum Schutz vor unbefugter oder unrechtmäßiger Verarbeitung sowie vor unbeabsichtigtem Verlust, Zerstörung oder Schädigung. Er umfasst auch die Speicherbegrenzung: Personenbezogene Daten in identifizierbarer Form sollten nicht länger als für ihren Zweck erforderlich aufbewahrt werden, vorbehaltlich der genannten Ausnahmen. Unterschiedliche Aufbewahrungs- oder Löschpflichten sind häufig ein praktischer Grund, einen einzigen undifferenzierten Datenbestand zu vermeiden.

• Bestimmen Sie die geschützte Gruppe: interne Mitarbeitende, ein Kunde, eine Rechtseinheit, eine regulierte Funktion oder eine Produktionsumgebung.
• Benennen Sie die Folge eines Zugriffsfehlers: Unannehmlichkeit, Vertragsverletzung, Offenlegung vertraulicher Informationen oder regulatorische Auswirkungen.
• Listen Sie Personen auf, die erweiterten Zugriff benötigen: Anwendungsadministratoren, Verantwortliche für Integrationen, Infrastrukturadministratoren und Supportpersonal.
• Halten Sie fest, ob Daten für jede Gruppe nach einem anderen Zeitplan exportiert, aufbewahrt, gelöscht oder wiederhergestellt werden müssen.
• Dokumentieren Sie, ob die Grenze eine organisatorische Präferenz oder eine vertragliche, rechtliche oder sicherheitsrelevante Anforderung ist.

Wann eine gemeinsam genutzte Instanz die einfachere und passende Wahl ist

Eine gemeinsam genutzte Instanz kann die richtige Lösung sein, wenn die Gruppen tatsächlich unter demselben Governance-Modell arbeiten. Sie zentralisiert Upgrades, Monitoring, die Administration der Authentifizierung, Anwendungskonfiguration, Backup-Routinen und Benutzerunterstützung. Sie kann außerdem die Zusammenarbeit und Berichterstattung teamübergreifend weniger fragmentieren, wenn Teilen beabsichtigt ist und das eigene Zugriffsmodell der Anwendung die erforderlichen Einschränkungen unterstützt.

Ein gemeinsames Modell ist am stärksten, wenn die Organisation eine einheitliche administrative Domäne beschreiben und betreiben kann. Dieselben vertrauenswürdigen Administratoren können das System verwalten, ein Release-Kalender ist akzeptabel, Integrationen können zentral gesteuert werden, und eine Wiederherstellung mit Auswirkungen auf die gesamte Anwendung ist ein akzeptables Wiederherstellungsereignis. Dies ist oft ein sinnvoller Ausgangspunkt für interne Abteilungen einer Organisation mit vergleichbarer Sensibilität und ähnlichen Lebenszyklusanforderungen.

Der Nachteil ist die Kopplung. Eine anwendungsweite Konfigurationsänderung, eine weitreichende Administratorrolle, gemeinsam genutzte Zugangsdaten für eine Integration oder die Wiederherstellung der gesamten Instanz können Auswirkungen auf alle Gruppen haben. Das Modell ist nicht per Definition unsicher; es benötigt lediglich eine disziplinierte Governance, die den betroffenen Daten und Stakeholdern angemessen ist.

• Wählen Sie eine gemeinsam genutzte Instanz, wenn Zusammenarbeit zwischen Gruppen erwartet und erlaubt ist.
• Stellen Sie sicher, dass die Anwendung über die erforderlichen Rollen und logischen Isolierungskontrollen verfügt, bevor Sie sensible Gruppen aufnehmen.
• Wenden Sie das Prinzip der geringsten Berechtigung sowohl für gewöhnliche Benutzer als auch für Administratoren an; erteilen Sie keinen umfassenden administrativen Zugriff allein aus Bequemlichkeit.
• Pflegen Sie einen regelmäßigen Prozess zur Überprüfung von Zugriffsrechten, insbesondere nach Personalwechseln oder dem Offboarding von Kunden.
• Behandeln Sie anwendungsweite Upgrades, Konfigurationsänderungen, Exporte und Wiederherstellungen als Änderungen, die jede Gruppe betreffen können.

Wann separate Instanzen üblicherweise die sicherere betriebliche Wahl sind

Separate Instanzen sind in der Regel die sicherere Wahl, wenn Gruppen unabhängig gesteuerte Daten, unterschiedliche vertrauenswürdige Administratoren, nicht vereinbare Zugangsdaten für Integrationen oder eigene Anforderungen an Lebenszyklus und Wiederherstellung haben. Agenturen begegnen diesem Fall häufig, wenn jeder Kunde eigene Benutzer, eine eigene Domain, angebundene Dienste, Datenexporte, Offboarding-Prozesse und Freigabewege für Änderungen erwartet.

Separate Instanzen können den Schadensradius einer fehlerhaften Konfigurationsänderung oder Wiederherstellung verringern, da jede Instanz über eine eigene Anwendungskonfiguration und einen eigenen Umfang persistenter Daten verfügen kann. Sie erleichtern zudem die Erklärung der Verantwortlichkeit: Diese Domain, Route, Instanz, dieser Satz an Zugangsdaten, Backup-Umfang und dieses Runbook gehören zu dieser Organisation. Der Vorteil besteht nicht darin, dass Container jedes Risiko verschwinden lassen. Er besteht darin, dass sich Betriebskontrollen enger an der tatsächlichen Organisationsgrenze ausrichten lassen.

[Docker empfiehlt](https://docs.docker.com/engine/security/), dass nur vertrauenswürdige Benutzer den Docker-Daemon steuern dürfen, da dessen Fähigkeiten das Einhängen von Host-Verzeichnissen in Container erlauben können, ohne die Zugriffsrechte des Containers einzuschränken. Daher entfällt bei separaten Anwendungen auf einem gemeinsam genutzten Host nicht die Notwendigkeit, den Zugriff von Infrastrukturadministratoren zu steuern. Der [Rootless-Modus von Docker](https://docs.docker.com/engine/security/rootless/) kann die Gefährdung reduzieren, indem Daemon und Container als Nicht-Root-Benutzer ausgeführt werden; er ist jedoch eine Maßnahme zur Härtung des Hosts und kein Ersatz für unabhängige administrative Domänen.

• Trennen Sie nach Organisation, wenn ein Kunde unabhängige Eigentümerschafts-, Offboarding- oder Wiederherstellungsentscheidungen benötigt.
• Trennen Sie, wenn der Administrator einer Gruppe nicht die Anwendungskonfiguration einer anderen Gruppe administrieren soll.
• Trennen Sie, wenn Zugangsdaten, Webhooks, API-Schlüssel oder externe Konten unabhängig verantwortet und rotiert werden müssen.
• Trennen Sie, wenn sich Release-Zeitpunkt, individuelle Konfiguration, Aufbewahrung oder Änderungsfreigabe wesentlich unterscheiden.
• Gehen Sie über separate Instanzen auf einem Host hinaus, wenn die erforderliche Grenze unabhängiges Vertrauen in Infrastrukturadministratoren oder eine stärkere vertragliche Isolierung einschließt.

Bewerten Sie fünf Entscheidungsfaktoren, bevor Sie das Modell wählen

Nutzen Sie die folgenden Faktoren als Praxistest. Bewerten Sie jeden Faktor für jede vorgeschlagene Gruppe hinsichtlich des Bedarfs an Unabhängigkeit mit niedrig, mittel oder hoch. Eine einzelne Anforderung mit hohem Risiko kann mehrere Bequemlichkeitsvorteile eines gemeinsamen Modells überwiegen.

Entscheidend ist, nachgewiesene Kontrollen statt Bezeichnungen zu bewerten. Wenn die Anwendung angibt, Organisationen oder Arbeitsbereiche zu besitzen, testen Sie die genauen relevanten Aktionen: Datensätze ansehen, suchen, exportieren, Benutzer einladen, Berechtigungen ändern, Integrationen administrieren und Daten löschen. Wenn eine Anforderung nicht in einer Testumgebung nachgewiesen oder durch die Anwendungsdokumentation gestützt werden kann, behandeln Sie sie als unerfüllt, bis das Gegenteil bewiesen ist.

• 1. Datensichtbarkeit: Können Benutzer, Administratoren und Supportmitarbeitende nur die Datensätze einsehen, für deren Bearbeitung sie berechtigt sind? Testen Sie direkte Navigation, Suche, Berichte, Benachrichtigungen, Exporte und Massenaktionen – nicht nur die normale Benutzeroberfläche.
• 2. Administratorzugriff: Wer kann Rollen, Konfiguration, Speicher, Protokolle und Bereitstellungseinstellungen ändern? Trennen Sie Anwendungsrollen vom Zugriff auf Docker-Host, Laufzeit und persistenten Speicher. Wenden Sie, wo praktikabel, Funktionstrennung und geringste Berechtigung an.
• 3. Integrationen und Geheimnisse: Benötigt jede Gruppe eigene API-Schlüssel, ein eigenes E-Mail-Konto, ein eigenes Webhook-Ziel, eine eigene Identitätskonfiguration oder externe Datenverbindung? [Docker Compose kann ein Geheimnis](https://docs.docker.com/compose/how-tos/use-secrets/) nur Diensten gewähren, die es ausdrücklich deklarieren, und bindet es als Datei ein. Behandeln Sie Umgebungsvariablen nicht als unbedenklichen Speicher für Geheimnisse; Docker warnt, dass dort hinterlegte Passwörter und API-Schlüssel unbeabsichtigt offengelegt werden können, auch über Debug-Protokolle.
• 4. Unabhängigkeit des Lebenszyklus: Kann jede Organisation dasselbe Upgrade-Fenster, dieselbe Konfigurationsbasis, denselben Supportprozess und denselben Freigabeweg für Änderungen akzeptieren? Falls nicht, erzeugt eine gemeinsame Mandantenstruktur Koordinationsschuld.
• 5. Backup- und Wiederherstellungsgrenzen: Kann eine Gruppe wiederhergestellt werden, ohne eine andere zurückzusetzen, offenzulegen oder zu beeinträchtigen? Entscheidend ist, ob das geplante Wiederherstellungsverfahren die benötigte Grenze nachweist.

Erfassen Sie das Isolierungsmodell der Anwendung, bevor Sie sich darauf verlassen

Jede Anwendung hat ihr eigenes Modell, und allgemeine Begriffe reichen nicht aus. Bevor Sie entscheiden, dass eine gemeinsam genutzte Instanz geeignet ist, erstellen Sie eine evidenzbasierte Übersicht ihrer Kontrollen. Nutzen Sie die für Ihre geplante Bereitstellung relevante Version und Dokumentation und validieren Sie wichtige Annahmen anschließend mit Testkonten.

Beginnen Sie beim Verhalten gewöhnlicher Benutzer und arbeiten Sie sich dann nach außen vor. Was definiert die Mitgliedschaft? Kann eine Person mehreren Arbeitsbereichen angehören? Gelten Rollen global oder für einen Arbeitsbereich? Können Benutzer über Suche, Links, Berichte, Benachrichtigungen oder Exporte Datensätze außerhalb ihres erwarteten Bereichs entdecken? Sind Audit-, Administrations- und Integrationsansichten für einen größeren Benutzerkreis verfügbar als operative Ansichten?

Erfassen Sie als Nächstes den Datenpfad. Identifizieren Sie Datenbank oder persistenten Speicher, hochgeladene Dateien, Anwendungsprotokolle, Exporte, E-Mail- oder Webhook-Ziele und Backups. Ein separater Frontend-Container ist keine unabhängige Wiederherstellungsgrenze, wenn zwei Organisationen weiterhin denselben Datenspeicher oder dasselbe Backup-Artefakt verwenden. Die [Docker-Anleitung zu Volumes](https://docs.docker.com/engine/storage/volumes/) umfasst Verfahren zum Archivieren und Wiederherstellen benannter Volumes. Das unterstreicht eine grundlegende Planungsregel: Persistente Daten und ein getestetes Wiederherstellungsverfahren müssen Teil des Grenzdesigns sein.

• Dokumentieren Sie globale Rollen und bereichsbezogene Rollen getrennt.
• Testen Sie das Entfernen von Mitgliedschaften, die Deaktivierung von Benutzern, Einladungsabläufe und die Übergabe der Administration.
• Testen Sie die Sichtbarkeit von Datensätzen über normale Ansichten, Suche, gegebenenfalls APIs, erzeugte Berichte, Benachrichtigungen und Exporte.
• Ermitteln Sie, wo Anhänge, Protokolle, Exporte und persistente Daten gespeichert sind.
• Dokumentieren Sie, wer Zugriff auf Anwendungskonfiguration, Bereitstellungsmanifeste, Host-Speicher, Backups und geheimes Material hat.
• Bewahren Sie Testnachweise zusammen mit dem Entscheidungsprotokoll auf, insbesondere bei Kundenzusagen oder sensiblen Daten.

Vergleichen Sie drei praktische Bereitstellungsmuster

Muster eins ist eine gemeinsam genutzte Anwendungsinstanz. Sie ist betrieblich wirtschaftlich und kann für eine einzelne Organisation oder eine eng gesteuerte Gruppe interner Teams gut funktionieren. Sie stützt sich stark auf das Autorisierungsmodell der Anwendung sowie auf die sorgfältige Verwaltung globaler Administratoren, gemeinsamer Konfigurationen, Integrationen und Wiederherstellungsverfahren.

Muster zwei ist eine Anwendungsinstanz pro Organisation. Jede Organisation erhält ihre eigene Bereitstellungskonfiguration, ihren eigenen Umfang persistenter Daten, einen Hostnamen oder eine Routing-Regel, eine Anwendungsadministration und eine Betriebsdokumentation. Dies bietet typischerweise eine klarere Grundlage für separate Zugangsdaten, Release-Entscheidungen, Exporte, Aufbewahrungsmaßnahmen und Wiederherstellungen. Es führt wiederkehrende Betriebsarbeit ein, die geplant statt improvisiert werden muss.

Muster drei sind gemeinsam genutzte Infrastrukturdienste mit getrennten Anwendungsinstanzen. Beispielsweise können [separate Compose-Projekte](https://docs.docker.com/compose/how-tos/networking/) ihre eigenen projektspezifischen Netzwerke für interne Komponenten wie Anwendung und Datenbank verwenden und sich gleichzeitig gezielt mit einem extern erstellten gemeinsamen Netzwerk verbinden, wenn die Kommunikation mit einem gemeinsamen Edge- oder Support-Dienst erforderlich ist. Dies kann Konsistenz mit begrenzter Anwendungskonnektivität verbinden, doch Netzwerkmitgliedschaften und Routen müssen ausdrücklich gestaltet und überprüft werden.

• Eine gemeinsam genutzte Instanz: am besten geeignet, wenn Governance, Administration, Lebenszyklus und Wiederherstellung tatsächlich gemeinsam sind.
• Eine Instanz pro Organisation: am besten geeignet, wenn Eigentümerschaft und betriebliche Entscheidungen unabhängig sein müssen.
• Gemeinsam genutzte Dienste mit separaten Anwendungsinstanzen: am besten geeignet, wenn eine Organisation ausgewählte Plattformfunktionen sicher zentralisieren kann und zugleich die Grenzen zwischen Anwendung und Datenebene getrennt hält.
• Entscheiden Sie bei jedem Muster ausdrücklich, ob die Host-Administration gemeinsam genutzt, eingeschränkt oder ein stärkeres Trennungsmodell erforderlich ist.

Planen Sie die Betriebsarbeit ein, die sich mit jeder Instanz vervielfacht

Separate Instanzen verringern einige Governance-Kopplungen, erhöhen jedoch den betrieblichen Bestand. Jede Instanz benötigt einen bekannten Verantwortlichen, ein Zugriffsmodell, eine Domain oder Routing-Regel, Anwendungskonfiguration, Zugangsdaten, einen Backup-Umfang, Monitoring-Erwartungen, einen Upgrade-Verlauf und einen Weg für die Reaktion auf Vorfälle. Eine Agentur, die Instanzen schnell erstellt, aber deren Verantwortliche oder Wiederherstellungsverfahren nicht benennen kann, hat vermeidbares Risiko geschaffen.

Domain- und TLS-Verwaltung gehören zu dieser Arbeit. Die [dynamische Konfiguration von Traefik](https://doc.traefik.io/traefik/reference/routing-configuration/dynamic-configuration-methods/) bestimmt, wie eingehende Anfragen an Dienste geleitet werden; diese Konfiguration kann über Mechanismen wie Docker-Labels und Dateien bereitgestellt werden. Jede Instanz benötigt daher eine korrekte und gepflegte Zuordnung von Hostname oder Regel zu ihrem Dienst. Ein [für TLS konfigurierter Traefik-Router](https://doc.traefik.io/traefik/v3.2/routing/routers/) verarbeitet HTTPS-Anfragen und terminiert TLS, bevor er entschlüsselten Datenverkehr an den konfigurierten Dienst weiterleitet.

Auch die Zertifikatsautomatisierung hat einen Lebenszyklus. [Let’s Encrypt wendet Ausstellungsgrenzen an](https://letsencrypt.org/docs/rate-limits/) auf Anfragen über seinen New-Order-API-Endpunkt. Verwenden Sie ein kontrolliertes Namensschema, validieren Sie DNS vor dem Go-live, vermeiden Sie wiederholte Zertifikatsanfragen bei Ad-hoc-Tests und bewahren Sie ein klares Verfahren für Domain-Änderungen auf.

Airbip betreibt Anwendungsinstanzen als Docker-Workloads auf Airbip-Cloud-Servern und automatisiert Routing und TLS-Zertifikate über Traefik und Let’s Encrypt. Außerdem bietet Airbip DNS-Prüfungen, Verwaltung des Dienstlebenszyklus, konfigurierbare tägliche, wöchentliche und monatliche Backups sowie die Wahl zwischen einer Airbip-Subdomain und einer kompatiblen benutzerdefinierten Domain. Diese Plattformfunktionen können wiederkehrende Infrastrukturarbeit reduzieren, Kunden müssen jedoch weiterhin Verantwortlichkeiten, Zugriffe, Datenverarbeitung, Backup-Umfang, Wiederherstellungsverfahren und das passende Trennungsmodell definieren.

• Führen Sie ein Instanzregister: Organisation, Verantwortlicher, Zweck, Domain, Administratoren, angebundene Dienste, Datenklassifizierung und gegebenenfalls Offboarding-Datum.
• Verwenden Sie eine vorhersehbare Domain-Konvention und prüfen Sie die Verantwortlichkeit für das Routing vor dem Start.
• Verfolgen Sie Anwendungs-Releases, Konfigurationsänderungen und Freigabeanforderungen pro Instanz.
• Definieren Sie Monitoring- und Incident-Kontakte für jede Instanz; gehen Sie nicht davon aus, dass ein zentrales Team den relevanten Kundenkontext kennt.
• Planen Sie Backup- und Wiederherstellungstests in dem Umfang, der der Organisation zugesagt wurde.
• Planen Sie Migrationsarbeiten, bevor Sie separate Instanzen einführen, einschließlich der Datenübertragung, der Umstellung von Zugriffen sowie der Aufbewahrung oder Löschung der ursprünglichen Daten.