SaaS-Sicherheits-Checkliste für Produktteams: zehn Bereiche vor dem Launch und bei jedem Release prüfen

Diese Checkliste richtet sich an Product Manager, Engineering Leads und Gründer, die ein Multi-Tenant-Produkt entwickeln und Sicherheitsfragebögen von Kunden beantworten müssen. Unser Leitfaden zum SaaS-Plattform-Engineering behandelt die Sicherheitsgrundlagen in einem kurzen Abschnitt; diese Seite wandelt sie in Punkte um, die ein Team abhaken kann – inklusive der beizufügenden Nachweise.

Inhalt

• So verwenden Sie die Checkliste
• Zehn Bereiche auf einen Blick
• Tenant-Isolation: wo SaaS-Produkte scheitern
• Identitäts-, API- und Geschäftslogik-Prüfungen
• Daten, Secrets und die Lieferkette
• Logging, Wiederherstellung und Incident Response
• Sicherheit für KI-Funktionen
• Wer führt die Prüfung durch: Alternativen und Auswahlkriterien
• Ein Prüfplan
• Wie Netbase SaaS-Produkte entwickelt und prüft
• Welcher Liefernachweis existiert und welcher nicht
• Grenzen dieses Leitfadens
• Häufig gestellte Fragen
• Nächster Schritt

So verwenden Sie die Checkliste

Behandeln Sie jeden Punkt als Frage mit drei Teilen: Wer ist verantwortlich, welcher Nachweis liegt heute vor und wann wurde er zuletzt geprüft? Ein Punkt ohne Verantwortlichen gilt nicht als erledigt, unabhängig davon, was der Code tut. Halten Sie die Antworten an einem zentralen Ort fest, etwa im Repository, damit eine Sicherheitsprüfung eines Kunden aus dem Protokoll heraus beantwortet werden kann und nicht aus dem Gedächtnis.

Zwei Regeln halten die Liste ehrlich. Haken Sie einen Punkt nur ab, wenn ein Test, ein Log, eine Einstellung oder ein Dokument dies belegt, und führen Sie die Liste gegen das Produkt aus, das Sie heute betreiben – nicht gegen das Architekturdiagramm.

Zehn Bereiche auf einen Blick

Tenant-Isolation: wo SaaS-Produkte scheitern

Zugriffskontrolle ist der Bereich, in dem Webanwendungen am häufigsten versagen: Die OWASP Top 10:2025 führt Broken Access Control an erster Stelle. Bei einem Multi-Tenant-Produkt kann eine einzige fehlende Tenant-Prüfung die Daten eines Kunden einem anderen zeigen. Das OWASP Multi-Tenant Security Cheat Sheet macht daraus konkrete Maßnahmen:

• Binden Sie den Tenant an eine verifizierte Identität. Entnehmen Sie den Tenant aus der serverseitigen Sitzung, nicht aus einem vom Client gesendeten Wert, und prüfen Sie die Mitgliedschaft bei jeder Anfrage.
• Begrenzen Sie jede Abfrage. Fügen Sie den Tenant in Datenbankabfragen ein oder erzwingen Sie ihn in der Datenbank mit Row-Level-Richtlinien, damit ein erratener Bezeichner nicht den Datensatz eines anderen Tenants zurückgibt.
• Schlüsseln Sie Caches nach Tenant. Ein Cache-Eintrag ohne den Tenant im Schlüssel kann die Seite eines Kunden an einen anderen ausliefern.
• Führen Sie den Tenant durch Queues und Jobs weiter. Ein Hintergrundjob muss den Tenant, für den er läuft, erneut prüfen; Speicherpfade und signierte Dateilinks benötigen denselben Geltungsbereich und eine kurze Lebensdauer.
• Offboarding sauber durchführen. Widerrufen Sie Anmeldedaten und wenden Sie die Aufbewahrungsregel auf Backups und Dateispeicher an, wenn ein Tenant den Dienst verlässt.

Unser Leitfaden zur Multi-Tenant-SaaS-Architektur vergleicht die Isolationsmodelle hinter diesen Maßnahmen.

Identitäts-, API- und Geschäftslogik-Prüfungen

Identität und Zugriff. Verlangen Sie Multi-Faktor-Authentifizierung für Administratoren und bieten Sie sie jedem Nutzer an; unterstützen Sie Single Sign-on für Geschäftskunden, die darum bitten. Halten Sie Rollen wenige und spezifisch, lassen Sie Sitzungen ablaufen und überprüfen Sie Administrator-Rechte vierteljährlich.

API-Sicherheit. Die meisten SaaS-Funktionen sind APIs, daher ist die OWASP API Security Top 10 (2023) eine praktische Testliste. Beginnen Sie mit der Autorisierung auf Objektebene (API1), Authentifizierung (API2), Autorisierung auf Eigenschaftsebene (API3), uneingeschränktem Ressourcenverbrauch (API4) und Autorisierung auf Funktionsebene (API5). Führen Sie ein Inventar aller Endpunkte, einschließlich alter Versionen: unzureichendes Inventar-Management ist API9.

Geschäftslogik. Manche Schwachstellen liegen nicht in einer einzelnen Anfrage, sondern in einer Abfolge: einen Zahlungsschritt überspringen, eine Einladung wiederverwenden oder mehr als ein Plan erlaubt exportieren. API6 bezeichnet dies als uneingeschränkten Zugriff auf sensible Geschäftsabläufe. Dokumentieren Sie die vorgesehenen Abläufe für Registrierung, Einladungen, Abrechnung und Export, und testen Sie, dass jeder Schritt serverseitig durchgesetzt wird – nicht nur in der Benutzeroberfläche versteckt ist.

Daten, Secrets und die Lieferkette

• Verschlüsseln Sie bei Übertragung und im Ruhezustand, und bewahren Sie Schlüssel außerhalb des Anwendungscodes auf, mit einem benannten Verantwortlichen für jeden Schlüssel.
• Klassifizieren Sie die Daten. Wissen Sie, welche Felder personenbezogen oder sensibel sind, wo sie kopiert werden – etwa in Logs, Exports und Analytics – und wie lange jede Kopie aufbewahrt wird.
• Halten Sie Secrets aus Repositories heraus. Scannen Sie danach, verwenden Sie einen Secret Store, geben Sie jeder Umgebung eigene Zugangsdaten und rotieren Sie diese, wenn Personen das Unternehmen verlassen.
• Kennen Sie Ihre Abhängigkeiten. Scannen Sie Pakete und Container-Images, überprüfen Sie Code vor dem Merge und führen Sie Protokoll darüber, welche Version wo läuft. Das NIST Secure Software Development Framework (SP 800-218) beschreibt die dahinterstehenden Praktiken, und der OWASP Application Security Verification Standard listet Anforderungen auf, die Sie in Tickets referenzieren können.
• Behandeln Sie Drittanbieterdienste als Teil Ihrer Angriffsfläche. Jeder Integrationsschlüssel ist auf das Minimum beschränkt, das er benötigt; OWASP nennt den unsicheren Konsum von APIs (API10), wenn man einer Upstream-Antwort zu sehr vertraut.

Logging, Wiederherstellung und Incident Response

Ein Produkt, das nicht beantworten kann, wer wann auf die Daten eines Tenants zugegriffen hat, kann nichts untersuchen oder beweisen. Protokollieren Sie Anmeldungen, Berechtigungsänderungen, Exporte und Administratoraktionen mit Tenant und Benutzer, schützen Sie die Logs vor den Personen, die sie beschreiben, und alarmieren Sie bei wiederholten Fehlern und bei jedem abgelehnten Cross-Tenant-Versuch.

Backups zählen nur, wenn sie wiederhergestellt wurden. Stellen Sie eine ganze Umgebung und auch einen einzelnen Tenant in einer sauberen Umgebung wieder her, notieren Sie Datum und Ergebnis und wiederholen Sie dies nach größeren Änderungen. Für die Incident Response schreiben Sie einen kurzen Plan mit benannten Rollen, einer Entscheidung darüber, wann Kunden informiert werden, und einer Vorlage für die Benachrichtigung; führen Sie eine Tischübung durch, bevor der erste echte Vorfall eintritt.

Wer führt die Prüfung durch: Alternativen und Auswahlkriterien

Wählen Sie anhand von vier Kriterien: Was Kunden in Verträgen verlangen, wie sensibel die Daten sind, wie häufig Sie Releases durchführen und ob jemand im Team Sicherheit verantworten kann. Die meisten Produkte benötigen die ersten beiden zusammen: eine routinemäßige Checkliste und einen Test durch Außenstehende vor einem größeren Launch.

Wie Netbase SaaS-Produkte entwickelt und prüft

Netbase entwickelt Multi-Tenant-Produkte für Kunden und betreibt eigene. Die veröffentlichten Sicherheitspraktiken umfassen: sicheres Code-Review und Versionskontrolle, TLS bei der Übertragung und AES im Ruhezustand, rollenbasierte Zugriffskontrolle, MFA für Admin-Dashboards, Vulnerability-Scanning und Penetrationstests sowie Disaster Recovery; NDAs, Datenverarbeitungsverträge und SLAs sind auf Anfrage erhältlich. Netbase hält die ISO-27001-Zertifizierung und eine SOC-2-Type-II-Bescheinigung. Beide decken ab, wie Netbase selbst arbeitet, nicht das Produkt oder Hosting eines Kunden, das weiterhin eigene Maßnahmen, Nachweise und – wo Kunden es verlangen – ein eigenes Audit benötigt. Netbase arbeitet auf AWS, Google Cloud, DigitalOcean und Cloudflare und beansprucht keinen Cloud-Partner-Status. Die meisten Netbase-Projekte werden auf Basis von Festpreisverträgen geliefert, die nach einer Discovery-Phase vereinbart werden. Siehe SaaS-Entwicklung, den SaaS-Produkt-Accelerator für wiederverwendbare Konten, Tenants und Rollen sowie Application Security Assurance für Tests. Die MVP-Roadmap platziert diese Prüfungen in den ersten Wochen; zur Bewertung der Antworten eines Anbieters siehe Sicherheitsfragen für einen Software-Entwicklungspartner.

Welcher Liefernachweis existiert und welcher nicht

• Was existiert. Netbase entwickelt und betreibt Cloodo Workspace, einen Multi-Tenant-Digital-Workplace, und Printcart, ein SaaS für viele Händler. Seit 2020 arbeitet Netbase als Offshore-Entwicklungs- und Managing-Partner an einer Multi-Tenant-Cloud-ERP für einen US-Kunden, dessen Name nicht genannt wird.
• Was nicht existiert. Kein Netbase-Nachweis veröffentlicht Penetrationstest-Ergebnisse, Vorfallshistorie, Audit-Befunde, Schwachstellenanzahlen oder Reaktionszeiten; keiner wird als Beleg dafür angeboten, dass eine bestimmte Maßnahme funktioniert. Nichts auf dieser Seite zertifiziert ein Produkt.

Grenzen dieses Leitfadens

• Es ist eine Arbeitscheckliste, kein Compliance-Programm; regulierte Sektoren wie Zahlungsverkehr oder Gesundheitswesen stellen eigene Anforderungen – holen Sie daher Fachberatung ein.
• Standards ändern sich: Prüfen Sie am Tag Ihrer Überprüfung die aktuellen OWASP-, NIST- und Anbieterrichtlinien.
• Eine Checkliste kann keine unbekannten Schwachstellen aufdecken; das ist die Aufgabe von Tests und unabhängigen Prüfungen.

Nächster Schritt

Teilen Sie Ihr Tenancy-Modell, Ihre aktuellen Nachweise und die Fragebögen, die Kunden Ihnen schicken, und wir werden eine Lösungsüberprüfung buchen, um Lücken den zehn Bereichen zuzuordnen. Sie können auch SaaS-Entwicklung ansehen oder weitere Netbase Insights.

Verwandte Leistungen und Lösungen