SaaS-Entwicklung · mandantenfähig
SaaS-Plattformen und Cloud-Anwendungen entwickeln
Sie wollen Ihre Anwendung als Dienst für eigene Kunden anbieten. Wir bauen das Produkt und treffen mit Ihnen die frühen, schwer umkehrbaren Entscheidungen zu Mandantentrennung, Identität und Abrechnung.
- Mandantentrennung in PostgreSQL
- Identität über OpenID Connect
- Optional Abrechnung über Stripe
- Betrieb auf Kubernetes
01Ausgangslage
Vier Festlegungen, die ein SaaS-Produkt ein Leben lang begleiten
Bei SaaS entscheiden wenige frühe Festlegungen über Sicherheit, Kosten und Skalierbarkeit der gesamten Lebensdauer. Wer sie nachträglich ändert, ändert das Produkt. Diese Seite richtet sich an Geschäftsführung, CTOs und Produktverantwortliche, die ein Produkt aufbauen und diese Entscheidungen von Anfang an richtig treffen wollen. Für die interne Fachanwendung statt eines Produkts siehe Individuelle Softwareentwicklung.
- Mandantenmodell: wie werden Daten verschiedener Kunden getrennt?
- Identität: wie melden sich Nutzer an, wie werden Rollen je Mandant verwaltet?
- Abrechnung: wie hängen Tarife, Nutzung und Zugriffsrechte zusammen?
- Betrieb: welche Umgebung, welche Verfügbarkeitsziele, wer ist rufbereit?
02Mandantenmodell
Welches Mandantenmodell trägt Ihr Produkt?
Drei Wege, Kundendaten zu trennen. Keiner ist grundsätzlich richtig; er muss zu Mandantenzahl und Trennungsanforderung passen.
| Kriterium | Gemeinsames Schema (Mandantenkennung je Zeile) | Schema je Mandant | Datenbank je Mandant |
|---|---|---|---|
| Trennung | logisch, muss konsequent durchgesetzt werden | stärker, innerhalb einer Datenbank | stark, getrennte Instanzen |
| Betriebsaufwand bei vielen Mandanten | gering | mittel (viele Schemas, Migrationen je Schema) | hoch (viele Datenbanken) |
| Schemaänderungen | eine Migration | eine Migration je Schema | eine Migration je Datenbank |
| Auswertungen über Mandanten | einfach | möglich, aufwendiger | aufwendig |
| Individuelle Wiederherstellung je Mandant | schwer | möglich | einfach |
| Passt, wenn | viele kleine bis mittlere Mandanten, einheitliche Anforderungen | mittlere Zahl Mandanten, höhere Trennungswünsche | wenige große Mandanten mit strengen Vorgaben (Datenort, Isolation) |
| Risiko | Programmierfehler legt Fremdmandanten-Daten offen | Betriebsaufwand wächst mit Mandantenzahl | Kosten und Betriebsaufwand je Mandant |
03PostgreSQL
Row-Level Security: wo die Trennung wirklich hält
Beim gemeinsamen Schema setzen wir PostgreSQL Row-Level Security ein: Richtlinien legen fest, welche Zeilen eine Sitzung sehen oder ändern darf, ohne Richtlinie sind standardmäßig keine Zeilen sichtbar.
Wichtig: Superuser und Rollen mit BYPASSRLS umgehen die Sicherheit immer, Tabelleneigentümer standardmäßig auch, solange die Tabelle nicht mit FORCE ROW LEVEL SECURITY gesetzt ist. Deshalb verwendet die Anwendung eine eigene Rolle ohne diese Rechte, und die Mandantenkennung wird pro Verbindung oder Transaktion gesetzt und im Test gegengeprüft.
Datenbankdetails: PostgreSQL-Beratung und Datenbankarchitektur.
04Abnahmekriterien
Acht Prüfpunkte, bevor ein Mandant echte Daten einträgt
- Jede Tabelle mit Mandantendaten trägt die Mandantenkennung oder liegt im Schema des Mandanten.
- Trennung wird in der Datenbank durchgesetzt (Row-Level Security), nicht nur in der Anwendung.
- Anwendungsrolle ist weder Eigentümer noch Superuser noch
BYPASSRLS. - Automatisierte Tests prüfen aktiv, dass Mandant A keine Daten von Mandant B lesen, ändern oder löschen kann, auch über Verknüpfungen, Hintergrundjobs und Exporte.
- Caches, Suchindizes, Dateiablagen und Protokolle sind ebenfalls mandantengetrennt.
- Administrative und Support-Zugriffe laufen über eigene, protokollierte Wege.
- Sicherung und Wiederherstellung sind je Mandant beschrieben (Granularität, Dauer), soweit zugesagt.
- Löschung und Datenexport eines Mandanten sind als Funktion vorhanden.
05Architektur
Der Weg einer Anfrage durch die Plattform
Vom Nutzer eines Mandanten über Identität und Anwendung bis in die Datenbank. Die Vertrauensgrenze zwischen Mandant A und Mandant B verläuft durch alle Schichten.
06Identität
Anmeldung, Rollen und Single Sign-On je Mandant
Anmeldung über OpenID Connect, wahlweise mit Anbindung an Kunden-Identitätssysteme (Single Sign-On je Mandant), Rollen und Berechtigungen je Mandant, Prüfung der Mandantenzugehörigkeit bei jedem Zugriff. Das Zugriffsmodell richtet sich nach IAM und Zero Trust.
07Abrechnung
Stripe-Webhooks: der Teil, der in der Praxis Fehler verursacht
Wenn Sie Abonnements oder Nutzung abrechnen, binden wir Stripe an. Nach der Stripe-Dokumentation zu Webhooks gelten unter anderem diese Regeln, die wir umsetzen. Tarife und Berechtigungen werden aus dem Abrechnungszustand abgeleitet und in Ihrer Datenbank geführt; die Zuordnung eines Ereignisses zu Ihrem Mandanten erfolgt über eigene Kennungen, nicht über Annahmen. Ob Stripe oder ein anderer Dienst passt, klären wir mit Ihnen; Stripe ist optional.
- Die Signatur jedes Ereignisses wird mit dem Signaturgeheimnis des Endpunkts geprüft, auf Basis des unveränderten Roh-Bodys.
- Der Endpunkt antwortet schnell mit 2xx, bevor aufwendige Logik läuft; die Verarbeitung erfolgt asynchron über eine Warteschlange.
- Doppelte Zustellungen werden über die Ereignis-ID erkannt (bereits verarbeitete IDs werden protokolliert).
- Die Reihenfolge der Ereignisse ist nicht garantiert; die Verarbeitung darf nicht von ihr abhängen.
- Nur die tatsächlich benötigten Ereignistypen werden abonniert.
08Betrieb
Absichern, ausliefern, betreiben
Verfügbarkeitszusagen an Ihre Kunden setzen wir erst, wenn Architektur und Betrieb sie tragen.
-
Absicherung in der Pipeline
Geheimnisse außerhalb des Codes, Prüfungen in der Lieferkette: DevSecOps und Software-Lieferketten.
-
Härtung auf Kubernetes
Netzwerkbeschränkung und Härtung: Kubernetes Security.
-
Auslieferung per CI/CD
Automatisierte Auslieferung und, wo gewünscht, GitOps: CI/CD-Pipelines.
-
Plattform Ihrer Wahl
Betrieb auf Kubernetes in Ihrer Umgebung oder auf STACKIT bzw. in einer Private Cloud.
-
Betrieb durch SKAFFON
Auf Wunsch: Managed Kubernetes und Managed PostgreSQL.
-
Cloud-native Muster
Architekturmuster für Dienste, Beobachtbarkeit und Resilienz: Cloud-native Entwicklung.
09Projektablauf
Vom Produktzuschnitt bis zur Übergabe
- 01
Produktzuschnitt
Ergebnis: ADRsZielkunden, Mandantenanforderungen, Tarifmodell, Betriebsanforderungen; Entscheidungen als ADR.
- 02
Fundament
Ergebnis: PlattformMandantenmodell, Identität, Pipeline, Plattformanbindung, Beobachtbarkeit.
- 03
Kernfunktionen
EtappenUmsetzung in Etappen mit Demonstration; Billing-Anbindung, wo gewünscht.
- 04
Härtung
Ergebnis: NachweiseMandanten-Isolationstests, Lasttests, Sicherheitsprüfungen, Wiederherstellungstest.
- 05
Übergabe
Ergebnis: BetriebÜbergabe an Ihr Team oder in den Betrieb durch SKAFFON.
10Technologie
Womit wir SaaS-Produkte bauen
Sprachen
- Go
- TypeScript
Daten und Plattform
- PostgreSQL
- Kubernetes
Identität und Abrechnung
- OIDC
- Stripe (optional)
11Passung
Wann Sie kein individuelles SaaS-Projekt brauchen
Aufwand bestimmen Funktionsumfang, Mandantenmodell, Zahl der Integrationen (Identität, Billing, Fremdsysteme), Anforderungen an Verfügbarkeit, Isolation und Datenort sowie der Betriebsanteil.
Das passt zu uns
- Sie bauen ein eigenes Produkt mit mandantenfähiger Architektur.
- Sie wollen die schwer umkehrbaren Entscheidungen früh und dokumentiert treffen.
Das passt nicht
- Eine bestehende SaaS-Standardlösung deckt Ihr Geschäftsmodell ab.
- Sie suchen Produktstrategie oder Marketing, nicht technische Umsetzung.
- Sie erwarten einen Festpreis für ein Produkt, dessen Funktionsumfang noch nicht abgegrenzt ist.
12
Häufige Fragen
Warum reicht Mandantentrennung in der Anwendung allein nicht?
Ein einzelner Programmierfehler kann dann Daten eines anderen Mandanten offenlegen. Deshalb wird die Trennung in der Datenbank durchgesetzt, etwa mit Row-Level Security, und mit automatisierten Tests gegengeprüft.
Ist Stripe für die Abrechnung Pflicht?
Nein. Stripe ist eine gängige Wahl, aber kein Bestandteil, den wir voraussetzen. Wir wählen den Zahlungsdienst gemeinsam mit Ihnen nach Zielmärkten und Abrechnungsmodell.
Nennen Sie Verfügbarkeitszahlen für meine Kunden?
Nicht pauschal. Eine Zahl, die Sie Ihren Kunden zusagen, muss durch Architektur, Wiederherstellungstests und Betriebsmodell gedeckt sein. Erst dann sagen wir sie zu.
Wer betreibt das Produkt nach dem Start?
Entweder Ihr Team nach der Übergabe oder auf Wunsch SKAFFON, zum Beispiel über Managed Kubernetes.
Beschreiben Sie Produkt, Zielkunden und Abrechnungsmodell
Mit diesen drei Angaben können wir die Mandantenfrage und den Projektzuschnitt konkret besprechen. Weitere Leistungen: Software Engineering.