Sicherheit im Systementwurf

Sicherheit lässt sich nicht nachträglich auf ein fertiges System streuen. Die wichtigsten Entscheidungen fallen im Entwurf: Wo liegen welche Daten, wer darf was, welche Dienste sprechen miteinander, welche Eingaben kommen von außen? Ein System, das von Anfang an mit Blick auf Angriffe entworfen wurde, ist nicht nur sicherer, sondern auch günstiger, denn nachträgliche Korrekturen an der Architektur sind teuer. Diese Lektion zeigt, wie man Bedrohungen systematisch findet, welche Angriffe am häufigsten sind und wie man mehrere Verteidigungsschichten kombiniert.

1. Bedrohungen modellieren

Das Herzstück ist die Frage nach den Vertrauensgrenzen: Überall dort, wo Daten von einer weniger vertrauenswürdigen Zone in eine vertrauenswürdigere wechseln – vom Browser zum Server, vom Partner-Webhook in die eigene API, von einem hochgeladenen Dokument in den Kontext eines Sprachmodells –, muss geprüft werden. Erkunden Sie die Grenzen einer typischen Anwendung:

Für jede Grenze fragt man nach typischen Bedrohungen. Eine hilfreiche Merkhilfe ist STRIDE: Identität vortäuschen, Daten manipulieren, Handlungen abstreiten, Informationen preisgeben, Dienst lahmlegen, Rechte ausweiten. Für ein kleines Team genügt oft eine Stunde am Whiteboard mit dem Architekturdiagramm und diesen sechs Fragen, um die wichtigsten Risiken zu finden.

2. Die häufigsten Angriffe

Viele erfolgreiche Angriffe nutzen seit Jahren dieselben Schwächen. Ganz vorn stehen fehlerhafte Zugriffskontrollen, die in der vorigen Lektion behandelt wurden. Dazu kommen Injection-Angriffe, bei denen Eingaben als Code interpretiert werden. Probieren Sie den Klassiker aus:

Das Prinzip gilt weit über SQL hinaus: Eingaben dürfen nie direkt in Befehle, Abfragen, HTML oder Prompts eingefügt werden, sondern werden als Daten übergeben. Bei HTML heißt die Entsprechung Cross-Site Scripting: Wird ein Kommentar ungeprüft angezeigt, kann er Skripte enthalten, die im Browser anderer Nutzer laufen. Moderne Frameworks wie React kodieren Ausgaben automatisch, eine Content Security Policy begrenzt zusätzlich, welche Skripte überhaupt laufen dürfen. Weitere wichtige Angriffe sind Server-Side Request Forgery, bei der der Server dazu gebracht wird, interne Adressen aufzurufen, und bei KI-Anwendungen Prompt Injection.

3. Verteidigung in der Tiefe

Keine einzelne Maßnahme ist perfekt. Deshalb kombiniert man mehrere Schichten, sodass ein Angreifer, der eine überwindet, an der nächsten scheitert. Klicken Sie sich durch die Schichten:

4. Sichere Standards

Viele Lücken entstehen nicht durch raffinierte Angriffe, sondern durch unsichere Grundeinstellungen: eine Datenbank, die aus dem Internet erreichbar ist, ein Objektspeicher mit öffentlichem Lesezugriff, ein Admin-Konto mit Standardpasswort, ein Testsystem mit echten Kundendaten. Gute Entwürfe machen das Sichere zur Voreinstellung: Datenbanken nur im privaten Netz, Speicher standardmäßig privat, Geheimnisse in einem Geheimnisspeicher statt im Code, getrennte Konten je Dienst mit minimalen Rechten. Üben Sie, Lücken zu erkennen:

5. Wenn doch etwas passiert

Auch gut geschützte Systeme können angegriffen werden. Entscheidend ist dann, einen Vorfall zu bemerken und richtig zu reagieren. Dazu gehören Protokolle über sicherheitsrelevante Ereignisse wie Anmeldungen, Rechteänderungen und fehlgeschlagene Zugriffe, Alarme bei Auffälligkeiten, etwa vielen fehlgeschlagenen Logins oder ungewöhnlichen Datenabrufen, und ein vorbereiteter Plan: Wer entscheidet, wie werden Zugänge gesperrt, Schlüssel ausgetauscht und Betroffene informiert? Bei Verletzungen des Schutzes personenbezogener Daten verlangt die DSGVO eine Meldung an die Aufsichtsbehörde innerhalb von 72 Stunden. Wer das erst im Ernstfall klärt, verliert wertvolle Zeit.

6. Sicherheit im Alltag des Teams

Sicherheit ist kein einmaliges Projekt, sondern Gewohnheit. Code-Reviews achten gezielt auf Autorisierung und Eingabeprüfung. Die Pipeline prüft Abhängigkeiten und Images automatisch. Updates werden zügig eingespielt, besonders bei bekannten, aktiv ausgenutzten Lücken. Zugänge ausgeschiedener Beteiligter werden sofort entfernt. Und einmal im Jahr lohnt sich ein Blick von außen, etwa durch einen Penetrationstest. Für ein kleines Unternehmen, etwa einen Onlineshop für Fahrradzubehör, bedeutet das keinen riesigen Aufwand, sondern eine Handvoll fester Routinen, die zusammen einen großen Unterschied machen. Das nächste Kapitel ergänzt diese Grundlagen um zwei Themen, die gerade bei Plattformen für viele Kunden entscheidend sind: die Trennung von Mandanten und den Datenschutz.

7. Ein Beispiel aus der Praxis

Ein kleines Team entwickelt eine Buchungsplattform für Zahnarztpraxen. In einer zweistündigen Sitzung zeichnet es das Architekturdiagramm mit allen Datenflüssen und markiert die Vertrauensgrenzen: den Browser der Patienten, das Praxisportal, die Schnittstelle zur Praxissoftware, den E-Mail-Versand und einen KI-Assistenten, der Fragen zu Behandlungen beantwortet. Für jede Grenze werden die sechs STRIDE-Fragen gestellt. Heraus kommt eine Liste mit zwölf Risiken, von denen vier als hoch eingestuft werden: fehlende Objektprüfung bei Terminen, ungeprüfte Webhooks der Praxissoftware, der API-Schlüssel des Sprachmodells im Frontend-Code und fehlende Mehr-Faktor-Anmeldung für das Praxispersonal.

Alle vier werden vor dem Start behoben. Die Autorisierung wird in einer zentralen Funktion gebündelt und mit Tests abgedeckt, die jede Anfrage auch mit einem fremden Konto ausführen. Webhooks werden per Signatur geprüft. Der Schlüssel wandert auf den Server, der KI-Assistent erhält nur Lesezugriff auf freigegebene Informationstexte und keinerlei Zugriff auf Patientendaten. Für das Praxispersonal werden Passkeys eingeführt. Der Aufwand beträgt wenige Tage – deutlich weniger als die Folgen eines einzigen Datenlecks mit Gesundheitsdaten, das Meldepflichten, Vertrauensverlust und womöglich Bußgelder nach sich ziehen würde.

Das Beispiel zeigt, dass Sicherheit kein Spezialwissen weniger Fachleute sein muss. Ein strukturierter Blick auf das eigene System, die Kenntnis der häufigsten Angriffe und eine Handvoll sicherer Standards reichen aus, um die große Mehrheit realer Angriffe abzuwehren. Wer diese Grundlagen beherrscht, kann gezielt entscheiden, wo darüber hinaus externe Prüfungen oder spezialisierte Werkzeuge sinnvoll sind.

Stand: September 2026. Kursmaterial der Klarwerk Akademie. Zahlen zu Latenzen und Kosten sind Größenordnungen zur Orientierung, keine Messwerte.