IT-Sicherheit bei eigener Software: Die zehn Fragen, die ein Inhaber stellen sollte
Sie müssen Sicherheit nicht verstehen, um sie einzufordern. Zehn Fragen an Ihren Anbieter, die Sie ohne technisches Wissen stellen können, mit der Antwort, die Sie hören sollten, und dem Grund, warum sie zählt.
Wenn eine Anwendung Kundendaten, Preise und Aufträge hält, ist ihre Sicherheit Ihre Verantwortung, auch wenn jemand anderes sie gebaut hat. Das Gute: Die meisten Sicherheitsprobleme in Anwendungen sind seit Jahren bekannt und haben bekannte Lösungen. Die Liste der häufigsten Schwachstellen in Webanwendungen führt die Organisation OWASP öffentlich unter dem Namen Top 10. Sie müssen sie nicht lesen. Sie müssen die richtigen Fragen stellen und wissen, welche Antwort Sie hören wollen.
Die zehn Fragen
- 011. Wie melden sich Benutzer an?
Gute Antwort: mit Passkeys oder mit Passwort und zweitem Faktor; Administratoren ohne Ausnahme mit zweitem Faktor. Schlechte Antwort: «Benutzername und Passwort». Gestohlene Passwörter sind der häufigste Weg in eine Anwendung, und ein zweiter Faktor macht sie weitgehend wertlos.
- 022. Wer sieht was, und wie wird das geprüft?
Gute Antwort: Jede Abfrage prüft auf dem Server, ob diese Person diese Daten sehen darf; die Prüfung steht an einer Stelle, nicht in jedem Bildschirm einzeln. Schlechte Antwort: «Die Knöpfe sind ausgeblendet.» Ausgeblendete Knöpfe halten niemanden auf, der die Adresse im Browser ändert.
- 033. Was passiert, wenn der Server heute Nacht ausfällt?
Gute Antwort: Es gibt eine Sicherung, sie läuft automatisch, sie liegt an einem anderen Ort, und die Wiederherstellung wurde ausprobiert, mit Datum. Schlechte Antwort: «Es gibt ein Backup.» Ein Backup, das nie zurückgespielt wurde, ist eine Hoffnung.
- 044. Wie kommen Sicherheitsupdates in die Anwendung?
Gute Antwort: Die verwendeten Bausteine werden automatisch auf bekannte Schwachstellen geprüft, Updates werden regelmässig eingespielt, und jemand ist dafür zuständig. Schlechte Antwort: «Bei Bedarf.» Bedarf ist dann, wenn es zu spät ist.
- 055. Wo läuft die Anwendung, und wer kommt an den Server?
Gute Antwort: Hosting in der Schweiz oder EU bei einem benannten Anbieter, Zugang nur für benannte Personen mit zweitem Faktor, auf Ihren Namen eingerichtet. Schlechte Antwort: «Auf unserem Server.» Dann hängt Ihre Anwendung am Konto und an der Sorgfalt eines Dritten.
- 066. Wird protokolliert, wer was getan hat?
Gute Antwort: Anmeldungen, Änderungen an Daten und Rechten und fehlgeschlagene Zugriffe werden festgehalten, ohne Personendaten im Klartext, und es gibt einen Alarm bei Auffälligkeiten. Schlechte Antwort: «Wir können das im Zweifel nachschauen.» Ohne Protokoll gibt es nichts nachzuschauen.
- 077. Was wurde getan, damit Eingaben keinen Schaden anrichten?
Gute Antwort: Alle Eingaben werden geprüft, Datenbankabfragen werden so gebaut, dass Eingaben nie als Befehl verstanden werden, und die Anwendung läuft mit einer Inhaltsrichtlinie, die fremde Skripte blockiert. Das sind drei der ältesten Punkte der OWASP-Liste, und sie sind bei sorgfältiger Arbeit Standard.
- 088. Wo liegen Passwörter und Schlüssel?
Gute Antwort: Zugangsdaten zu Datenbank, Mailversand und KI-Anbietern liegen als Umgebungsvariablen beim Hosting, nie im Quellcode, und sie lassen sich austauschen, ohne dass die Anwendung neu gebaut wird. Schlechte Antwort: Zögern. Ein Schlüssel im Code ist ein Schlüssel in jeder Kopie des Codes.
- 099. Was passiert mit den Daten, die an KI-Anbieter gehen?
Gute Antwort: Es gibt einen Vertrag, der Training auf Ihren Daten ausschliesst, es werden nur die nötigen Daten übermittelt, und es ist dokumentiert, welche. Schlechte Antwort: «Das ist Standard bei dem Anbieter.» Standard ist bei vielen Anbietern das Gegenteil, wenn man den Vertrag nicht anpasst.
- 1010. Was tun wir, wenn trotzdem etwas passiert?
Gute Antwort: Es gibt eine schriftliche Liste, wen man anruft, wie man die Anwendung vom Netz nimmt, wie man Zugangsdaten austauscht und wann der Datenschutzbeauftragte zu informieren ist. Schlechte Antwort: «Dann melden Sie sich bei uns.» Ein Notfallplan, der von der Erreichbarkeit einer Person abhängt, ist keiner.
Was diese Fragen gemeinsam haben
Keine davon verlangt technisches Wissen. Alle verlangen eine konkrete Antwort, und bei allen ist die schlechte Antwort erkennbar an ihrer Unbestimmtheit. Ein Anbieter, der Sicherheit ernst nimmt, hat diese Antworten schriftlich, weil er sie sich selbst beantwortet hat, bevor die Anwendung produktiv ging. Bei uns ist das die Sicherheitscheckliste, die jedes Projekt vor der Übergabe durchläuft, und sie ist Teil der Dokumentation, die Sie bekommen. Das ist in Modul 08 und Modul 09 beschrieben.
Sicherheit bei KI-gestützter Entwicklung
Wir schreiben Code mit Claude Code und Codex, und das verändert die Sicherheitsarbeit in zwei Richtungen. Einerseits machen KI-Werkzeuge bekannte Fehler seltener, weil sie die sicheren Muster kennen und konsequent anwenden. Andererseits erzeugen sie Code schneller, als ein Mensch ihn lesen kann, und das ist das Risiko: Was niemand gelesen hat, hat niemand geprüft. Darum lesen wir sicherheitsrelevanten Code vollständig, lassen ihn von einem zweiten Werkzeug prüfen und testen die Abnahmefälle, die etwas verbieten sollen («Kunde A sieht die Daten von Kunde B nicht»), ausdrücklich. Mehr dazu im Artikel Wir entwickeln mit KI.
Was Sie selbst tun können
- Zweiten Faktor für alle Konten, die mit der Anwendung zu tun haben, auch für Hosting, Domain und Mail. Die Anwendung ist nur so sicher wie das schwächste Konto darum herum.
- Einen Passwortmanager für den Betrieb, mit Freigaben pro Person. Zugangsdaten in einer Excel-Tabelle oder im Teams-Chat sind ein Notfall, der noch nicht passiert ist.
- Rechte entziehen, wenn jemand geht, am selben Tag. Dazu gehört eine Liste, welche Konten die Person hatte.
- Einmal im Jahr die Wiederherstellung aus der Sicherung verlangen, mit Protokoll. Das ist der einzige Beweis, dass sie funktioniert.
- Phishing ernst nehmen: Der häufigste Einbruch läuft über eine Mail, nicht über die Anwendung. Schulung hilft hier mehr als jede Technik.
Wenn Sie heute eine Anwendung im Einsatz haben, stellen Sie Ihrem Anbieter die zehn Fragen. Die Antworten sagen Ihnen in einer Stunde, wo Sie stehen. Wenn Sie ein neues Projekt planen, gehören sie ins Erstgespräch, und wir beantworten sie gern schriftlich.
Häufige Fragen
Ist eine eigene Anwendung unsicherer als Standardsoftware?
Nicht grundsätzlich. Standardsoftware hat mehr Augen darauf, ist aber auch ein lohnenderes Ziel, weil eine Schwachstelle tausende Installationen betrifft. Eine eigene Anwendung ist nur so sicher wie die Sorgfalt, mit der sie gebaut und betrieben wird. Die zehn Fragen helfen, diese Sorgfalt zu prüfen.
Was kostet Sicherheit zusätzlich?
Bei uns nichts extra, weil sie Teil des Baus ist: Anmeldung mit zweitem Faktor, Rechteprüfung, Sicherung, Protokolle und die Checkliste vor der Übergabe sind in jedem Projekt drin. Was extra kostet, ist eine unabhängige Prüfung durch Dritte, und die empfehlen wir bei besonders schützenswerten Daten.
Müssen wir einen Vorfall melden?
Das revidierte Datenschutzgesetz verlangt eine Meldung an den Eidgenössischen Datenschutz- und Öffentlichkeitsbeauftragten, wenn eine Verletzung der Datensicherheit voraussichtlich zu einem hohen Risiko für die betroffenen Personen führt. Was das im Einzelfall heisst, gehört in den Notfallplan und im Zweifel zu einer Fachperson. Wir sind keine Juristen.
Kommt aus dem digitalen Produktmanagement: hat Software gebaut, betreut und optimiert. Führt bei Synesis jedes Projekt selbst, vom Erstgespräch bis zur Abnahme, und baut Anwendungen mit KI, etwa den Pumpenauslegungs-Auftritt für Biral und den 3D-Konfigurator mit CRM und Produktionsportal für Nokto. Versteht zuerst den Ablauf, legt dann Architektur und Schnittstellen fest und prüft jede Änderung, bevor sie live geht.
Mehr über uns →