Security-Basics, die für ein kleines SaaS wirklich zählen

Security-Basics, die ein kleines SaaS zuerst absichert

Wenn ein kleines Produkt live geht, taucht das Thema Sicherheit selten als geordnete Liste auf. Es kommt als diffuses Unbehagen: Was, wenn jemand reinkommt? Was, wenn Daten verloren gehen? Die gute Nachricht ist, dass du für ein typisches SaaS mit ein paar Hundert Nutzern keinen Sicherheitsapparat brauchst. Du brauchst eine Handvoll Grundlagen, die sauber sitzen. Security-Basics für ein kleines SaaS bedeuten: die wahrscheinlichen Angriffe und die wahrscheinlichen Pannen abdecken, nicht die exotischen. Genau in dieser Reihenfolge gehen wir die Themen durch, von dem, was am häufigsten schiefgeht, zu dem, was du dir später ansiehst.

Wir betreiben mit Wortfreunde und Reazon eigene Produkte und tragen die Konsequenzen dieser Entscheidungen selbst. Das färbt auf die Empfehlungen ab. Was hier steht, ist das, was wir nachts ruhig schlafen lässt, nicht das, was sich in einem Pitch gut anhört.

Updates: der unspektakuläre Dauerläufer

Die meisten Einbrüche in kleine Anwendungen passieren nicht über raffinierte Zero-Days, sondern über bekannte Lücken in veralteten Abhängigkeiten. Eine Bibliothek, die du vor anderthalb Jahren eingebunden und nie wieder angefasst hast, ist das Einfallstor. Der Angreifer muss nichts erfinden, die Lücke und der passende Exploit stehen öffentlich im Netz.

Deshalb steht das Aktuellhalten ganz oben. Konkret heisst das: dein Framework, deine Laufzeitumgebung, dein Betriebssystem-Image und vor allem die dritten Pakete, die deine App zieht. Richte einen automatischen Dependency-Scanner ein, der dir meldet, wenn ein Paket eine bekannte Schwachstelle hat. GitHub Dependabot oder ein vergleichbares Werkzeug erledigt das kostenlos und schickt dir Pull Requests mit den Updates. Du musst sie nur regelmässig durchwinken und testen.

Der Aufwand ist gering, aber er ist nie fertig. Plane dafür einen festen Rhythmus ein, etwa eine halbe Stunde pro Woche. Patchen ist langweilig, und genau deshalb wird es vergessen, und genau deshalb funktioniert der Angriff darüber. Wer hier diszipliniert bleibt, hat den grössten Hebel schon gezogen.

Authentifizierung, die du nicht selbst erfindest

Auth ist der Bereich, in dem Eigenbau am teuersten wird. Passwörter richtig speichern, Sessions sicher verwalten, Reset-Flows ohne Lücken, Schutz gegen das massenhafte Durchprobieren von Login-Daten: jeder einzelne Punkt hat Fallstricke, die schon viele kluge Teams übersehen haben. Für ein kleines Produkt lautet die nüchterne Antwort fast immer, das nicht von Grund auf selbst zu bauen.

Nimm eine etablierte Bibliothek oder einen Identity-Provider. Passwörter werden mit einem starken, langsamen Hashverfahren gespeichert, bcrypt oder argon2, niemals im Klartext und niemals mit einem schnellen Hash wie MD5. Biete Zwei-Faktor-Authentifizierung wenigstens für Administratoren an, denn ein übernommener Admin-Zugang ist das Worst-Case-Szenario. Begrenze die Login-Versuche, damit niemand in Ruhe Passwörter durchprobiert.

Ein wunder Punkt, den viele unterschätzen: der Passwort-Reset. Wenn dein Reset-Link nicht abläuft, nicht an die richtige Adresse gebunden ist oder erraten werden kann, ist deine gesamte Auth wertlos. Tiefer steigen wir an anderer Stelle ein, in Auth, Billing und Compliance: was ein SaaS wirklich braucht ordnen wir diese Bausteine in den Gesamtkontext ein. Für hier reicht die Faustregel: bei Auth kaufst oder integrierst du, du erfindest nicht.

Verschlüsselung im Transport und im Ruhezustand

Verschlüsselung zerfällt in zwei Fragen. Erstens: Sind die Daten unterwegs geschützt, während sie zwischen Browser und Server reisen? Das ist TLS, also HTTPS für jede Verbindung. Heute ist das fast geschenkt. Ein Zertifikat von Let's Encrypt kostet nichts und erneuert sich automatisch, die meisten Hosting-Plattformen schalten es mit einem Klick frei. Es gibt keinen vertretbaren Grund, eine Anwendung ohne HTTPS zu betreiben.

Zweitens: Sind die Daten geschützt, wenn sie auf der Platte liegen? Das ist Verschlüsselung im Ruhezustand. Bei den meisten Managed-Datenbanken und Cloud-Speichern ist das standardmässig aktiv, du musst es nur nicht ausschalten. Der Schutz greift, wenn jemand physischen Zugriff auf das Speichermedium bekommt oder ein Backup-Volume in falsche Hände gerät.

Hier lohnt eine Abgrenzung gegen Übertreibung. Du brauchst für ein normales SaaS in aller Regel keine feldweise Verschlüsselung einzelner Datenbankspalten und keine selbstverwaltete Schlüssel-Infrastruktur. Solche Mechanismen haben ihren Platz, wenn du etwa Gesundheitsdaten oder Zahlungsdetails im Vollumfang selbst hältst. Für die meisten Produkte ist das Sicherheitstheater, das Komplexität bringt, ohne ein reales Risiko zu senken. Transport verschlüsseln ist Pflicht, im Ruhezustand verschlüsseln nimmst du mit, alles darüber hinaus rechtfertigst du mit einem konkreten Bedrohungsmodell.

Backups, die du auch zurückspielen kannst

Der häufigste Datenverlust kommt nicht vom Angreifer, sondern von einem fehlerhaften Deployment, einem versehentlichen DELETE ohne WHERE oder einer kaputten Migration. Backups sind deshalb keine reine Sicherheitsmassnahme, sie sind deine Versicherung gegen die eigene Fehlbarkeit.

Drei Eigenschaften machen ein Backup brauchbar. Es läuft automatisch, denn jedes manuelle Backup wird irgendwann vergessen. Es liegt getrennt von der Produktivumgebung, idealerweise bei einem anderen Anbieter oder in einer anderen Region, sonst reisst ein einziger Ausfall beides mit. Und es lässt sich tatsächlich zurückspielen. Den letzten Punkt überspringen fast alle. Ein Backup, das du nie wiederhergestellt hast, ist eine Vermutung, kein Plan. Spiele es mindestens einmal probeweise in eine Testumgebung zurück und schau, ob die Daten vollständig und konsistent ankommen.

Zwei Kennzahlen helfen beim Festlegen des Anspruchs. Wie viel Datenverlust verträgst du im Ernstfall, eine Stunde oder einen Tag? Und wie lange darf die Wiederherstellung dauern? Daraus ergibt sich, wie oft du sicherst und ob du eine kontinuierliche Sicherung brauchst. Wie das mit Monitoring und Alarmierung zusammenspielt, hat eine eigene Tiefe, die wir in Monitoring, Backups und Alerting: das betriebliche Minimum ausführen. Der Kern hier: ein ungetestetes Backup zählt nicht.

Zugriffsrechte nach dem Prinzip der minimalen Rechte

Nicht jeder, der mit deinem System arbeitet, braucht alle Rechte. Das gilt für deine Nutzer, für dein Team und für die technischen Konten, mit denen Dienste miteinander reden. Das Prinzip der minimalen Rechte besagt schlicht: jeder bekommt genau so viel Zugriff, wie er für seine Aufgabe braucht, und keinen Schritt mehr.

In der Praxis fängst du klein an. Trenne Rollen, etwa normale Nutzer und Administratoren, und gib administrative Rechte sparsam. Der Datenbankbenutzer, mit dem deine App arbeitet, sollte nicht der Superuser sein, der die ganze Datenbank löschen kann. Wenn ein externer Dienst über eine Schnittstelle nur lesen muss, gib ihm keinen Schreibzugriff. Jede überflüssige Berechtigung ist eine Tür, die im Ernstfall offensteht.

Dazu gehört eine unbequeme Routine, die niemand mag: das Entziehen von Zugriff. Wenn ein Teammitglied geht oder ein Dienstleister sein Mandat beendet, müssen die Schlüssel und Konten zeitnah deaktiviert werden. Verwaiste Zugänge, von denen keiner mehr weiss, sind ein klassisches Einfallstor. Führe eine kurze Liste, wer worauf Zugriff hat, und schau sie ein paarmal im Jahr durch.

Secrets: Schlüssel, Passwörter und Tokens richtig aufbewahren

Secrets sind die sensiblen Zugangsdaten deiner Anwendung: das Datenbankpasswort, API-Schlüssel für Zahlungsdienst oder Mailversand, Signaturschlüssel für Sessions. Der mit Abstand häufigste Fehler ist es, diese Werte fest in den Code zu schreiben und mit ins Repository zu commiten. Sobald ein Schlüssel einmal in der Git-Historie steht, ist er kompromittiert, auch wenn du ihn später wieder herauslöschst. Die Historie vergisst nichts.

Der richtige Weg trennt Konfiguration vom Code. Secrets gehören in Umgebungsvariablen oder in einen dedizierten Secret-Manager, den deine Hosting-Plattform meist mitbringt. Im Repository steht dann nur ein Platzhalter, niemals der echte Wert. Eine .gitignore, die deine lokale Konfigurationsdatei ausschliesst, ist die erste Verteidigungslinie, ein automatischer Secret-Scanner, der pro Commit prüft, die zweite.

Und wenn doch einmal ein Schlüssel nach aussen gerät, zählt nur eines: sofort rotieren. Den alten Schlüssel ungültig machen, einen neuen erzeugen, fertig. Deshalb baust du deine Anwendung so, dass ein Schlüsselwechsel eine Sache von Minuten ist und nicht von einem halben Tag Nervenkrieg. Wer Secrets von Anfang an aus dem Code heraushält, erspart sich die unangenehmste aller Aufräumaktionen.

Wann du es bewusst lassen solltest

Nicht jede Sicherheitsmassnahme zahlt sich für jedes Produkt aus, und das offen zu sagen gehört zu einer brauchbaren Beratung. Solange du eine Handvoll Pilotkunden hast und das Produkt noch sucht, ob es überhaupt trägt, ist ein vollständiger Penetrationstest, eine ISO-Zertifizierung oder ein durchgespieltes Notfallhandbuch verfrüht. Diese Dinge kosten Wochen und binden Aufmerksamkeit, die du gerade besser ins Produkt steckst.

Die Linie verläuft entlang der Daten und der Kunden. Sobald du sensible Daten verarbeitest, Gesundheits-, Finanz- oder umfangreiche Personendaten, oder sobald grössere Kunden mit eigenen Sicherheitsanforderungen anklopfen, verschiebt sich das Bild. Dann werden Audits, Verträge zur Auftragsverarbeitung und formale Nachweise zur Eintrittskarte, nicht zur Kür. Der Fehler in beide Richtungen ist gleich teuer: zu früh überzusichern lähmt, zu spät nachzurüsten kostet Aufträge.

Die ständig wiederkehrende Frage, ob man so etwas selbst stemmt oder abgibt, behandeln wir grundsätzlicher in Hosting selbst betreiben oder managed: die Operator-Frage. Für die Security-Basics gilt: das Minimum aus diesem Artikel ist für fast jedes ernsthafte Produkt der richtige Startpunkt, alles darüber entscheidest du anhand deiner konkreten Lage.

Das Minimum, das wirklich trägt

Wenn du die sechs Themen dieses Artikels sauber abdeckst, hast du den überwiegenden Teil der realen Risiken eines kleinen SaaS im Griff, ohne einen einzigen Franken in Sicherheitstheater zu stecken. Aktuelle Abhängigkeiten, eingekaufte Auth, durchgängiges HTTPS, getestete Backups, sparsame Rechte und Secrets ausserhalb des Codes. Keine dieser Massnahmen ist spektakulär, und genau das ist der Punkt: Sicherheit für kleine Produkte ist Handwerk, kein Heldentum.

Die meisten dieser Grundlagen baust du nicht nach dem Start dazu, sondern legst sie beim ersten produktionsreifen Aufsetzen mit an. Wie dieser Übergang vom Prototyp zum belastbaren Betrieb aussieht, vertiefen wir im Produkt-Betrieb, wo wir genau diese Verantwortung für eigene und fremde Produkte übernehmen. Sicherheit ist kein Projekt mit Enddatum, sie ist ein paar gute Gewohnheiten, die du dir früh angewöhnst und dann nicht mehr ablegst.