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 mandantenfähiges Produkt ausliefern und Sicherheitsfragebögen von Kunden beantworten müssen. Unser Leitfaden für SaaS-Plattform-Engineering enthält die Sicherheitsgrundlagen in einem kurzen Abschnitt; diese Seite wandelt sie in Punkte um, die ein Team abhaken kann, einschließlich der beizufügenden Nachweise.

In diesem Leitfaden

• So verwenden Sie die Checkliste
• Zehn Bereiche auf einen Blick
• Tenant-Isolation: wo SaaS-Produkte versagen
• Prüfungen für Identität, API und Geschäftslogik
• Daten, Secrets und die Supply Chain
• Logging, Recovery und Incident Response
• Sicherheit für KI-Funktionen
• Wer führt das Review durch: Alternativen und Auswahlkriterien
• Ein Review-Plan
• Wie Netbase SaaS-Produkte entwickelt und prüft
• Welche Referenzen existieren – und welche 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 existiert heute, und wann wurde er zuletzt geprüft? Ein Punkt ohne Verantwortlichen ist nicht erledigt, unabhängig davon, was der Code tut. Halten Sie die Antworten an einem Ort fest – etwa im Repository –, damit ein Sicherheits-Review 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 versagen

Zugriffskontrolle ist der Bereich, in dem Webanwendungen am häufigsten versagen: Das OWASP Top 10:2025 listet Broken Access Control an erster Stelle. Bei einem mandantenfähigen Produkt kann eine fehlende Mandantenprüfung die Daten eines Kunden einem anderen anzeigen. Das OWASP Multi-Tenant Security Cheat Sheet überführt das in konkrete Maßnahmen:

• Mandanten an eine verifizierte Identität binden. Entnehmen Sie den Mandanten der serverseitigen Sitzung, nicht aus einem vom Client gesendeten Wert, und prüfen Sie die Mitgliedschaft bei jeder Anfrage.
• Jeden Lookup eingrenzen. Schließen Sie den Mandanten in Datenbankabfragen ein oder erzwingen Sie ihn in der Datenbank mit Row-Level-Policies, damit ein erratener Bezeichner keinen Datensatz eines anderen Mandanten zurückliefert.
• Caches nach Mandant schlüsseln. Ein Cache-Eintrag ohne den Mandanten in seinem Schlüssel kann die Seite eines Kunden einem anderen ausliefern.
• Den Mandanten durch Queues und Jobs durchgeben. Ein Hintergrundjob muss den Mandanten, für den er läuft, erneut prüfen; Speicherpfade und signierte Dateilinks benötigen denselben Geltungsbereich und eine kurze Lebensdauer.
• Sauber offboarden. Entziehen Sie Zugangsdaten und wenden Sie die Aufbewahrungsregel auf Backups und Dateispeicher an, wenn ein Mandant die Plattform verlässt.

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

Prüfungen für Identität, API und Geschäftslogik

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

API-Sicherheit. Da die meisten SaaS-Funktionen APIs sind, ist das OWASP API Security Top 10 (2023) eine praktische Prüfliste. Beginnen Sie mit Autorisierung auf Objektebene (API1), Authentifizierung (API2), Autorisierung auf Property-Ebene (API3), uneingeschränktem Ressourcenverbrauch (API4) und Autorisierung auf Funktionsebene (API5). Führen Sie ein Inventar jedes Endpunkts, einschließlich alter Versionen: Unsachgemäßes Inventar-Management ist API9.

Geschäftslogik. Manche Schwachstellen sind keine Fehler in einer einzelnen Anfrage, sondern in einer Abfolge: das Überspringen eines Zahlungsschritts, die Wiederverwendung einer Einladung oder der Export über das erlaubte Planvolumen hinaus. API6 bezeichnet dies als uneingeschränkten Zugang zu sensiblen Geschäftsabläufen. Schreiben Sie die beabsichtigten Abläufe für Registrierung, Einladungen, Abrechnung und Export auf und testen Sie, dass jeder Schritt serverseitig erzwungen wird – nicht nur in der Oberfläche versteckt ist.

Daten, Secrets und die Supply Chain

• Verschlüsselung während der Übertragung und im Ruhezustand, und halten Sie Schlüssel außerhalb des Anwendungscodes mit einem namentlich genannten Verantwortlichen für jeden Schlüssel.
• Daten klassifizieren. Wissen Sie, welche Felder personenbezogen oder vertraulich sind, wo sie kopiert werden – etwa in Logs, Exporten und Analytics –, und wie lange jede Kopie aufbewahrt wird.
• Secrets aus Repositories heraushalten. Scannen Sie danach, verwenden Sie einen Secret Store, geben Sie jeder Umgebung eigene Zugangsdaten und rotieren Sie diese, wenn Mitarbeiter ausscheiden.
• Ihre Abhängigkeiten kennen. Scannen Sie Pakete und Container-Images, überprüfen Sie Code vor dem Merge und führen Sie ein Protokoll, welche Version wo läuft. Das NIST Secure Software Development Framework (SP 800-218) beschreibt die Praktiken dahinter, und der OWASP Application Security Verification Standard listet Anforderungen, die Sie in Tickets referenzieren können.
• Drittanbieterdienste als Teil Ihrer Angriffsfläche behandeln. Jeder Integrationsschlüssel ist auf das Mindestmaß beschränkt, das er benötigt, und OWASP weist auf den unsicheren Verbrauch von APIs (API10) hin, wenn Sie einer Upstream-Antwort zu weit vertrauen.

Logging, Recovery und Incident Response

Ein Produkt, das nicht beantworten kann, wer wann auf die Daten dieses Mandanten zugegriffen hat, kann nichts untersuchen oder beweisen. Protokollieren Sie Anmeldungen, Berechtigungsänderungen, Exporte und Administratoraktionen mit Mandant und Benutzer, schützen Sie die Logs vor den Personen, die sie beschreiben, und alarmieren Sie bei wiederholten Fehlern und bei jedem abgelehnten mandantenübergreifenden Zugriffsversuch.

Backups zählen nur, wenn sie wiederhergestellt werden. Stellen Sie eine gesamte Umgebung und auch einen einzelnen Mandanten in eine saubere Umgebung wieder her, protokollieren Sie Datum und Ergebnis und wiederholen Sie dies nach größeren Änderungen. Für die Incident Response schreiben Sie einen kurzen Plan mit namentlich genannten Rollen, einer Entscheidung, wann Kunden informiert werden, und einer Vorlage für die Mitteilung; 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 anhand von vier Kriterien: was Kunden vertraglich verlangen, wie sensibel die Daten sind, wie oft Sie releasen, 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 Externe vor einem Major Launch.

Wie Netbase SaaS-Produkte entwickelt und prüft

Netbase entwickelt mandantenfähige 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 die internen Abläufe von Netbase ab – 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-Partnerstatus. Die meisten Netbase-Projekte werden auf Basis von Festpreisverträgen durchgeführt, die nach der Discovery-Phase vereinbart werden. Siehe SaaS-Entwicklung, den SaaS-Produktbeschleuniger für wiederverwendbare Accounts, Mandanten 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 beurteilen, lesen Sie Sicherheitsfragen für einen Softwareentwicklungspartner.

Welche Referenzen existieren – und welche nicht

• Was existiert. Netbase entwickelt und betreibt Cloodo Workspace, einen mandantenfähigen digitalen Arbeitsplatz, und Printcart, eine SaaS-Plattform für viele Händler. Seit 2020 ist es als Offshore-Entwicklungs- und Managing-Partner an einem mandantenfähigen Cloud-ERP für einen US-Kunden beteiligt, dessen Name zurückgehalten wird.
• Was nicht existiert. Kein Netbase-Bericht veröffentlicht Penetrationstestergebnisse, Vorfallshistorie, Audit-Befunde, Schwachstellenzahlen oder Reaktionszeiten, und keines davon wird als Nachweis angeboten, dass eine bestimmte Maßnahme funktioniert. Nichts auf dieser Seite zertifiziert ein Produkt.

Grenzen dieses Leitfadens

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

Nächster Schritt

Teilen Sie Ihr Mandantenmodell, Ihre aktuellen Nachweise und die Fragebögen, die Kunden Ihnen senden, mit uns, und wir werden ein Solution Review buchen, um Lücken den zehn Bereichen zuzuordnen. Sie können auch SaaS-Entwicklung oder weitere Netbase Insights ansehen.

Verwandte Leistungen und Lösungen