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 betreiben und Sicherheitsfragebögen von Kunden beantworten müssen. Unser Leitfaden zum SaaS-Plattform-Engineering behandelt die grundlegenden Sicherheitsaspekte in einem kurzen Abschnitt; diese Seite wandelt sie in Punkte um, die ein Team abhaken kann, inklusive der beizufügenden Nachweise.

In diesem Leitfaden

• So verwenden Sie die Checkliste
• Zehn Bereiche auf einen Blick
• Tenant-Isolation: wo SaaS-Produkte versagen
• Identitäts-, API- und Geschäftslogik-Prüfungen
• Daten, Secrets und die Lieferkette
• Logging, Recovery und Incident Response
• Sicherheit für KI-Funktionen
• Wer führt das Review durch: Alternativen und Auswahlkriterien
• Ein Review-Plan
• Wie baut und prüft Netbase SaaS-Produkte?
• Welcher Liefernachweis besteht, und welcher nicht?
• Was sind die 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 als unerledigt, unabhängig davon, was der Code tut. Halten Sie die Antworten an einem Ort fest, z. B. im Repository, damit Sicherheitsreviews von Kunden aus der Dokumentation heraus beantwortet werden können, nicht aus dem Gedächtnis.

Zwei Regeln halten die Liste ehrlich. Haken Sie einen Punkt erst ab, wenn ein Test, ein Log, eine Einstellung oder ein Dokument ihn belegt, und wenden Sie die Liste auf das Produkt an, das Sie heute betreiben, nicht auf das Architekturdiagramm.

Zehn Bereiche auf einen Blick

Tenant-Isolation: wo SaaS-Produkte versagen

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

• Tenant an eine verifizierte Identität binden. Entnehmen Sie den Tenant aus der serverseitigen Session, nicht aus einem vom Client gesendeten Wert, und prüfen Sie die Zugehörigkeit bei jeder Anfrage.
• Jeden Lookup auf den Tenant beschränken. Schließen Sie den Tenant in Datenbankabfragen ein oder erzwingen Sie ihn in der Datenbank mit Row-Level-Policies, damit ein erratener Bezeichner keine Daten eines anderen Tenants zurückgibt.
• Caches nach Tenant schlüsseln. Ein Cache-Eintrag ohne den Tenant im Schlüssel kann die Seite eines Kunden einem anderen ausliefern.
• Tenant durch Warteschlangen und Jobs mitführen. Ein Hintergrundauftrag muss den Tenant, für den er ausgeführt wird, erneut prüfen; Speicherpfade und signierte Dateilinks benötigen denselben Geltungsbereich und eine kurze Lebensdauer.
• Sauber offboarden. Widerrufen Sie Zugangsdaten und wenden Sie die Aufbewahrungsregel auf Backups und Dateispeicher an, wenn ein Tenant das Produkt 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 danach fragen. Halten Sie Rollen sparsam und spezifisch, lassen Sie Sessions ablaufen und überprüfen Sie die Administrator-Berechtigungen jedes Quartal.

API-Sicherheit. Da die meisten SaaS-Funktionen APIs sind, ist das 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 jedes Endpunkts, einschließlich alter Versionen: Improper Inventory Management ist API9.

Geschäftslogik. Manche Schwachstellen liegen nicht in einer einzelnen Anfrage, sondern in einer Abfolge: das Überspringen eines Zahlungsschritts, das Wiederverwenden einer Einladung oder das Exportieren von mehr als ein Plan erlaubt. 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 erzwungen wird, nicht nur in der Oberfläche ausgeblendet 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. Ermitteln Sie, welche Felder personenbezogen oder sensibel sind, wo sie kopiert werden, z. B. in Logs, Exporten und Analytics, und wie lange jede Kopie aufbewahrt wird.
• Halten Sie Secrets aus Repositories heraus. Scannen Sie auf sie, verwenden Sie einen Secret Store, geben Sie jeder Umgebung eigene Zugangsdaten und rotieren Sie diese, wenn Mitarbeitende das Unternehmen verlassen.
• Kennen Sie Ihre Abhängigkeiten. Scannen Sie Packages und Container-Images, prüfen Sie Code vor dem Merge und führen Sie ein Protokoll darüber, welche Version wo läuft. Das NIST Secure Software Development Framework (SP 800-218) beschreibt die entsprechenden Praktiken, und der OWASP Application Security Verification Standard listet Anforderungen auf, die Sie in Tickets referenzieren können.
• Behandeln Sie Drittanbieter-Services als Teil Ihrer Angriffsfläche. Jeder Integrationsschlüssel ist auf das Minimum beschränkt, das er benötigt, und OWASP weist auf den unsicheren Konsum von APIs (API10) hin, wenn Sie einer vorgelagerten Antwort zu sehr vertrauen.

Logging, Recovery und Incident Response

Ein Produkt, das die Frage "Wer hat wann auf die Daten dieses Tenants zugegriffen?" nicht beantworten kann, ist weder in der Lage zu untersuchen noch etwas zu beweisen. Protokollieren Sie Anmeldungen, Berechtigungsänderungen, Exporte und Administratoraktionen mit Tenant und Nutzer, schützen Sie die Logs vor den Personen, die sie beschreiben, und benachrichtigen Sie bei wiederholten Fehlern sowie bei jedem abgewiesenen Cross-Tenant-Versuch.

Backups zählen nur, wenn sie wiederhergestellt wurden. Stellen Sie eine gesamte Umgebung und auch einen einzelnen Tenant in eine saubere Umgebung wieder her, dokumentieren 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 Tabletop-Übung durch, bevor der erste echte Vorfall eintritt.

Wer führt das Review durch: Alternativen und Auswahlkriterien

Wählen Sie nach vier Kriterien: was Kunden in Verträgen fordern, wie sensibel die Daten sind, wie häufig Sie Releases durchführen und ob jemand im Team die Verantwortung für Sicherheit übernehmen kann. Die meisten Produkte benötigen die ersten beiden gemeinsam: eine routinemäßige Checkliste und einen Test durch Externe vor einem größeren Launch.

Wie baut und prüft Netbase SaaS-Produkte?

Netbase entwickelt Multi-Tenant-Produkte für Kunden und betreibt eigene. Die veröffentlichten Sicherheitspraktiken umfassen: sicheres Code-Review und Versionskontrolle, TLS bei Übertragung und AES im Ruhezustand, rollenbasierte Zugriffskontrolle, MFA für Admin-Dashboards, Schwachstellen-Scanning und Penetrationstests sowie Disaster Recovery; NDAs, Datenverarbeitungsverträge und SLAs sind auf Anfrage verfügbar. Netbase richtet sich nach ISO 27001 und SOC 2 Type II. Beide betreffen die Betriebsweise von Netbase selbst, nicht das Produkt oder Hosting eines Kunden, das weiterhin eigene Maßnahmen, Nachweise und, sofern Kunden es verlangen, ein eigenes Audit benötigt. Netbase arbeitet auf AWS, Google Cloud, DigitalOcean und Cloudflare und beansprucht keine Cloud-Partner-Stufe. Die meisten Netbase-Projekte werden auf Festpreisbasis nach einer Discovery-Phase abgewickelt. Siehe SaaS-Entwicklung, den SaaS-Produktbeschleuniger für wiederverwendbare Accounts, Tenants und Rollen sowie Application Security Assurance für Tests. Die MVP-Roadmap platziert diese Prüfungen in den ersten Wochen; um die Antworten eines Anbieters zu bewerten, siehe Sicherheitsfragen für einen Software-Entwicklungspartner.

Welcher Liefernachweis besteht, und welcher nicht?

• Was besteht. Netbase entwickelt und betreibt Cloodo Workspace, einen Multi-Tenant-Digital-Workplace, sowie Printcart, ein SaaS für viele Händler. Seit 2020 arbeitet Netbase als Offshore-Entwicklungs- und Managing-Partner an einem Multi-Tenant-Cloud-ERP für einen US-Kunden, dessen Name nicht genannt wird.
• Was nicht besteht. Kein Netbase-Dokument veröffentlicht Penetrationstestergebnisse, Vorfallshistorie, Audit-Befunde, Schwachstellenzahlen oder Reaktionszeiten, und keines wird als Nachweis für die Wirksamkeit einer bestimmten Maßnahme angeboten. Nichts auf dieser Seite zertifiziert ein Produkt.

Was sind die Grenzen dieses Leitfadens?

• Es handelt sich um eine praktische Checkliste, kein Compliance-Programm; regulierte Bereiche wie Zahlungsverkehr oder Gesundheitswesen stellen eigene Anforderungen, holen Sie daher Fachberatung ein.
• Standards ändern sich: Prüfen Sie am Tag Ihres Reviews die aktuellen OWASP-, NIST- und Anbieterrichtlinien.
• Eine Checkliste kann unbekannte Schwachstellen nicht aufdecken; das ist die Aufgabe von Tests und unabhängigen Reviews.

Nächster Schritt

Teilen Sie Ihr Tenancy-Modell, Ihre aktuellen Nachweise und die Fragebögen, die Kunden Ihnen zusenden, und wir vereinbaren einen Solution-Review, um Lücken den zehn Bereichen zuzuordnen. Sie können auch SaaS-Entwicklung oder weitere Netbase JSC Insights erkunden.

Verwandte Leistungen und Lösungen