Sicherheit entsteht nicht beim Deployment, sondern davor. Diese Seite beschreibt, wie eine Änderung bei uns von der Idee in den Betrieb kommt – und was sie unterwegs bestehen muss.
Was jede Änderung besteht
- Statische Analyse beim Kompilieren: Code-Analyzer (StyleCop, Sonar und die .NET-Analyse in der strengsten Stufe) laufen in jedem Build mit. Ihre Befunde erscheinen dort als Warnungen; den Build brechen die Punkte 2 bis 4.
- Architekturtests: Ein Modul darf nicht in ein anderes hineingreifen, jeder Endpunkt muss angeben, ob und welche Berechtigung er verlangt, mandantenübergreifende Endpunkte sind namentlich bekannt – Regeln, die als Tests formuliert sind und den Build brechen.
- Unit-Tests je Modul und Integrationstests gegen echte Datenbank und Warteschlange in Containern (Testcontainers), darunter Tests, die die Mandantentrennung und das Änderungsprotokoll nachweisen.
- Schwachstellen-Tore: Das Auflösen der Abhängigkeiten prüft jedes Paket gegen bekannte Schwachstellen und bricht ab – serverseitig ab mittlerer Schwere (NuGet-Audit), in der Oberfläche für alles, was an den Browser ausgeliefert wird, ab hoher Schwere (npm-Audit). Ein wöchentlicher Lauf prüft auch dann, wenn sich nichts geändert hat.
- Auslieferung mit Rückweg: Nach dem Ausrollen wird die Gesundheitsprüfung abgefragt; fällt sie rot aus, rollt die Pipeline automatisch auf das zuletzt laufende Image zurück. Der Ablauf im Detail steht unter Betrieb und Standorte.
Drei Umgebungen, keine Produktivdaten außerhalb von prod
Entwicklung, Staging und Produktion sind vollständig getrennte Umgebungen – eigene Ressourcengruppen, eigene Datenbanken, eigene Speicherkonten, eigene Schlüsseltresore, eigene Identitäten. Es gibt keinen Weg, mit dem eine Umgebung die Daten einer anderen liest.
In Entwicklung und Staging liegen keine Kundendaten. Für Tests, Screenshots und Vorführungen nutzen wir einen Demo-Mandanten mit erfundenen Sendungen, Adressen und Belegen. Mails aus Nicht-Produktivumgebungen erreichen keine echten Empfänger: Ein Schutz lässt nur Adressen aus einer Freigabeliste zu.
Geheimnisse und Zugänge
Konfigurationsgeheimnisse liegen je Umgebung im Azure Key Vault und werden zur Laufzeit über die Identität der Anwendung aufgelöst – sie stehen weder im Code noch in der Pipeline. Auf Produktivdaten greifen zwei benannte Personen zu; Verwaltungszugänge sind gedrosselt und protokolliert. Eine Auslieferung in die Produktivumgebung verlangt eine Freigabe durch einen Menschen; einen zweiten Freigeber sieht der Ablauf nicht vor – bei zwei Gesellschaftern wäre er eine Formalie, keine Kontrolle.
Interne Sicherheitsprüfung
Am 13.08.2026 haben wir die gesamte Codebasis werkzeuggestützt geprüft – Endpunkte, Autorisierung, Mandantentrennung, Eingabeverarbeitung, Abhängigkeiten. Ergebnis: kein bestätigter mandantenübergreifender Datenzugriff, keine anonyme Datenexposition, keine SQL-Injection, keine Umgehung der Anmeldung. Ein Befund hoher Schwere (eine verwundbare Abhängigkeit) und sechs mittlerer Schwere wurden am selben Tag behoben; die verbliebenen niedrigen Hinweise sind erfasst. Ein externes Audit oder ein Penetrationstest durch Dritte ist der nächste Schritt.
Melden Sie uns Schwachstellen
Wer eine Schwachstelle findet, erreicht uns über die Adresse in unserer
security.txt. Wir antworten, beheben und nennen die Meldung auf Wunsch.