Transfer in typische Anwendungsszenarien

Transfer in typische Anwendungsszenarien

0:00 Wir sind beim letzten Kapitel, und es ist das praktischste von allen. Prinzipien und Methoden haben wir jetzt — aber Prinzipien zeigen ihren Wert erst dort, wo sie auf echte Systeme treffen. Genau das machen wir jetzt: Wir nehmen dieselbe Denkweise und legen sie nacheinander über drei sehr unterschiedliche Anwendungstypen.

0:18 Sie werden sehen, dass die Bedrohungen jedes Mal anders aussehen, die Fragen aber gleich bleiben. Und am Ende spielen wir das Ganze einmal komplett durch, an einem System, das jeder kennt. Damit haben Sie nicht nur Wissen, sondern einen Ablauf, den Sie am Montag anwenden können.

Transfer in typische Anwendungsszenarien

0:35 Der Weg durch dieses Abschlusskapitel: Zuerst klären wir, was Transfer überhaupt bedeutet — warum dieselben Prinzipien in verschiedenen Kontexten zu verschiedenen Maßnahmen führen. Dann drei Szenarien: Desktop-Anwendungen, Webanwendungen und APIs, schließlich Backend-Dienste mit ihren externen Integrationen. Und zum Abschluss ein durchgehendes Bedrohungsszenario, in dem alles aus den Kapiteln eins bis fünf zusammenkommt.

1:00 Vier Dinge stehen an. Erstens übertragen wir Prinzipien und Threat Modeling auf konkrete Anwendungstypen — weg von der Regel, hin zur Entscheidung. Zweitens schauen wir uns je Szenario typische Bedrohungen und ihre Gegenmaßnahmen an, damit Sie einen Ausgangspunkt haben und nicht bei null anfangen müssen. Drittens, und das ist der eigentliche Ertrag: Wir suchen die gemeinsamen Muster über alle Typen hinweg.

1:22 Denn wenn Sie in fünf Jahren an einem Anwendungstyp arbeiten, den es heute noch nicht gibt, brauchen Sie die Muster, nicht die Listen. Und viertens spielen Sie ein Szenario selbst durch.

Vom Prinzip zum Szenario

1:33 Beginnen wir mit der Frage, was Transfer eigentlich heißt. Denn die naheliegende Erwartung — für jeden Anwendungstyp eine eigene Sicherheitslehre — trifft nicht zu, und das ist eine gute Nachricht. Sie müssen nicht für jede Technologie neu lernen, was sicher ist. Was Sie brauchen, ist eine Denkweise, die sich mitnehmen lässt, und ein Gespür dafür, wo in einem bestimmten Kontext die typischen Schwachpunkte sitzen.

1:57 Transfer bedeutet, die allgemeinen Prinzipien und das Threat Modeling auf den konkreten Kontext anzuwenden. Der entscheidende Halbsatz: Die Bedrohungen unterscheiden sich, die Denkweise bleibt gleich. Ein Bild dazu: Ein Arzt lernt nicht für jedes Organ eine eigene Medizin, sondern eine Untersuchungsmethode, die er überall anwendet — er weiß nur, worauf er an welcher Stelle besonders achtet.

2:20 Genauso hier. Least Privilege gilt auf dem Desktop wie im Backend; nur sieht die Umsetzung völlig anders aus. Wer das einmal verinnerlicht hat, steht auch vor einem unbekannten Anwendungstyp nicht ratlos da, sondern stellt die immer gleichen vier Fragen. Drei Gründe, warum sich der Blick auf die Szenarien lohnt. Erstens hat jeder Anwendungstyp eine eigene, typische Angriffsfläche — beim Desktop ist es die fremde Ausführungsumgebung, im Web die öffentliche Erreichbarkeit, im Backend das Vertrauen zwischen Diensten.

2:50 Wer das kennt, weiß, wo er zuerst hinschaut. Zweitens führen dieselben Prinzipien zu unterschiedlichen Maßnahmen; Fail Secure im Frontend sieht anders aus als in einer Zugriffsprüfung. Und drittens, sehr praktisch: Wiederkehrende Muster beschleunigen den Entwurf. Sie müssen die typischen Bedrohungen eines Webservice nicht jedes Mal neu entdecken — Sie prüfen, ob die bekannten zutreffen, und haben dann Zeit für die untypischen.

Desktop-Anwendungen

3:15 Fangen wir mit dem Szenario an, das am meisten unterschätzt wird. Beim Desktop läuft Ihr Code auf einem Gerät, das Ihnen nicht gehört — und das ändert alles. Unterschätzt wird es deshalb, weil Desktop-Anwendungen als das Sichere, Altvertraute gelten, gegenüber der offenen Weboberfläche. In Wahrheit geben Sie hier etwas aus der Hand, das Sie im Web behalten: die Kontrolle über die Ausführungsumgebung.

3:39 Bei Desktop-Anwendungen läuft der Code auf einem Gerät, das der Anbieter nicht kontrolliert. Daraus folgt eine Konsequenz, die man sich immer wieder klarmachen muss: Alles im Client ist einsehbar, manipulierbar und damit nicht vertrauenswürdig. Auch kompilierter Code, auch verschleierter. Denken Sie an ein Auto, das Sie verkauft haben: Der neue Besitzer kann die Motorhaube öffnen, Teile ausbauen und Software aufspielen — Ihre Garantiebedingungen ändern daran nichts.

4:05 Genau so verhält es sich mit Ihrer Anwendung auf einem fremden Rechner. Die praktische Regel lautet deshalb: Alles, worauf Sie sich verlassen müssen, muss auf dem Server passieren. Hinter den vier Zeilen steckt ein gemeinsamer Gedanke: Was auf dem fremden Gerät liegt, gehört Ihnen nicht mehr. Update-Dateien lassen sich austauschen — deshalb Signaturen, die Ihr Programm prüft, bevor es installiert.

4:28 Lokale Daten kann jeder lesen, der Zugriff auf das Gerät hat — deshalb verschlüsselt speichern, wobei die Frage nach dem Schlüssel dann die eigentlich schwierige ist. Bibliotheken lassen sich unterschieben, wenn Ladepfade nicht festgelegt sind. Und Geheimnisse im Client sind schlicht keine Geheimnisse mehr, egal wie tief sie vergraben sind.

4:47 Die Fußzeile bringt es auf den Punkt: Vertrauenswürdige Entscheidungen gehören auf den Server. Drei Fehler, die immer wieder passieren. Der erste: Lizenz- oder Zugriffsprüfungen nur im Client. Das fühlt sich sicher an, weil man den Dialog sieht — nur entscheidet über das Ergebnis am Ende der Rechner des Nutzers. Der zweite: mitgelieferte API-Schlüssel.

5:09 Sie sind in jeder ausgelieferten Kopie enthalten und werden regelmäßig binnen Stunden gefunden; es gibt Werkzeuge, die genau danach suchen. Und der dritte ist eine Haltungsfrage: auf Verschleierung statt echte Schutzmaßnahmen zu setzen. Obfuskation erhöht den Aufwand für einen Angreifer, aber sie ersetzt keine serverseitige Prüfung. Sie kauft Zeit, keine Sicherheit.

Webanwendungen und APIs

5:32 Weiter zum Szenario, das am häufigsten angegriffen wird — nicht weil es besonders verwundbar wäre, sondern weil es für jeden erreichbar ist, jederzeit, aus der ganzen Welt. Der Unterschied zum Desktop ist bemerkenswert: Dort verlieren Sie die Kontrolle über die Umgebung, hier behalten Sie sie, bekommen aber ein Publikum, das Sie sich nicht ausgesucht haben.

5:52 Beides verlangt Vorsicht, nur an unterschiedlichen Stellen. Web- und API-Endpunkte sind öffentlich erreichbar und damit die am häufigsten angegriffene Fläche. Der Grundsatz, der sich daraus ergibt: Jede Eingabe ist potenziell feindlich und gehört serverseitig validiert und autorisiert. Das ist keine Paranoia-Haltung, sondern schlichte Statistik — automatisierte Scanner klopfen jeden öffentlich erreichbaren Endpunkt binnen Minuten ab, ohne dass jemand Sie persönlich ins Visier genommen hätte.

6:21 Wichtig ist das Wort "serverseitig". Ihr Formular mit seiner hübschen Validierung ist nur eine von vielen Möglichkeiten, eine Anfrage zu stellen — und die anderen Möglichkeiten halten sich an keine Ihrer Regeln. Diese vier stehen seit Jahren stabil auf den einschlägigen Listen, etwa den OWASP Top Ten — und das sagt etwas aus: Es sind keine exotischen Angriffe, sondern die immer gleichen.

6:44 Injection entsteht, wo Eingaben zu Befehlen werden. Broken Authentication trifft die Frage, ob Sie wissen, wer da anfragt. Fehlende Zugriffskontrolle ist der Fall, in dem jemand zwar authentifiziert ist, aber Dinge sieht, die ihm nicht gehören — in der Praxis der häufigste Befund überhaupt. Und übermäßige Datenpreisgabe passiert, wenn eine API mehr zurückgibt, als die Oberfläche anzeigt.

7:07 Der gemeinsame Nenner steht in der Fußzeile: Nie dem Client vertrauen, jede Prüfung serverseitig wiederholen. Zwei Datenbankabfragen, die dasselbe tun sollen. Oben wird die Benutzereingabe direkt in den Abfragetext hineingeschrieben — und damit entscheidet der Inhalt der Eingabe mit, welcher Befehl am Ende ausgeführt wird.

7:27 Genau das ist Injection: Daten werden zu Code. Unten dieselbe Abfrage, aber der Wert wird getrennt übergeben; die Datenbankschnittstelle weiß dann, dass es sich um einen Wert handelt und nicht um Befehlstext. Worauf es ankommt, ist dieses Prinzip der Trennung, nicht die konkrete Bibliothek. Und es gilt weit über SQL hinaus: überall dort, wo Sie Eingaben in Kommandos, Pfade, Templates oder Abfragesprachen einsetzen, ist Interpolation die falsche Antwort.

Backend-Dienste und externe Integrationen

7:55 Bleibt das dritte Szenario — und das mit den hartnäckigsten Annahmen. Hinter der Fassade reden Dienste miteinander, und die Frage, warum sie einander eigentlich glauben, wird selten gestellt. Meist lautet die Antwort, wenn man nachfragt: weil sie im selben Netz stehen. Das war einmal ein Argument, als Netze klar abgegrenzt waren.

8:14 Mit Cloud, Partneranbindungen und verteilten Diensten trägt es nicht mehr. Backend-Dienste kommunizieren untereinander und mit Drittsystemen. Der entscheidende Satz: Auch interne und Partner-Aufrufe brauchen Identität, Autorisierung und Misstrauen gegenüber empfangenen Daten. Das widerspricht dem Reflex, hinter der Firewall sei man unter sich — genau dieser Reflex ist der Grund, warum sich Angreifer nach dem ersten Fuß in der Tür oft so frei bewegen können.

8:42 Ein Bild: In einem Bürogebäude reicht es nicht, dass am Empfang kontrolliert wird, wenn danach jede Tür offensteht. Wer einmal drin ist, kommt sonst überall hin. Zero Trust ist im Kern nichts anderes als diese Beobachtung, konsequent zu Ende gedacht. Auch hier lohnt der Blick auf das gemeinsame Muster. Ungeprüfte Service-Aufrufe begegnet man mit Identität für jeden Dienst, technisch etwa über gegenseitige TLS-Authentifizierung — jeder Dienst weist sich aus, in beide Richtungen.

9:11 Secrets gehören nicht in Konfiguration oder Code, sondern in eine Verwaltung, die sie auch turnusmäßig wechseln kann; das Wechseln ist dabei der Teil, der meist fehlt. Bei kompromittierten Dritt-APIs hilft nur, empfangene Daten wie jede andere Eingabe zu behandeln — auch wenn der Partner vertrauenswürdig ist, sein System muss es nicht bleiben.

9:30 Und Ratenbegrenzung samt Zeitlimits schützt Sie davor, dass ein Ausfall anderswo Ihren Dienst mitreißt. Die Fußzeile ist die Quintessenz: "Internes Netz" ist keine Vertrauensgrenze. Drei Annahmen, die teuer werden können. Erstens: interne Aufrufe grundsätzlich als vertrauenswürdig behandeln. Genau darauf bauen laterale Bewegungen nach einem erfolgreichen Erstzugriff.

9:52 Zweitens: Antworten von Drittsystemen ungeprüft weiterverarbeiten — Sie haben die Anfrage gestellt, aber Sie kontrollieren nicht, was zurückkommt, und schon gar nicht, ob das System auf der anderen Seite heute noch dasselbe ist wie gestern. Und drittens die fehlende Absicherung gegen Ausfall und Überlast der Integration.

10:11 Das ist im engeren Sinn kein Sicherheitsthema, trifft aber die Verfügbarkeit — und die ist eines unserer drei Schutzziele.

Exemplarisches Bedrohungsszenario

10:19 Zum Abschluss führen wir alles zusammen. Ein System, ein vollständiger Durchlauf — vom Systembild bis zum benannten Restrisiko. Genau so, wie es in Ihrem nächsten Projekt aussehen sollte. Und es ist wichtig, das einmal am Stück gesehen zu haben: Die einzelnen Bausteine wirken für sich betrachtet manchmal akademisch. Erst im Durchlauf zeigt sich, wie schnell sie ineinandergreifen und wie wenig Zeit das Ganze braucht.

10:44 Das Beispiel ist bewusst alltäglich gewählt: ein kleiner Web-Shop mit API und Zahlungsanbindung. Wir skizzieren ihn als System, markieren die Vertrauensgrenzen und bedrohen ihn mit STRIDE. Das Schöne an diesem Beispiel ist, dass es alle drei Szenarien dieses Kapitels berührt — es gibt eine öffentliche Weboberfläche, eine API, Backend-Dienste und eine externe Integration zum Zahlungsanbieter.

11:06 Damit lässt sich an einem einzigen, überschaubaren System zeigen, wie die verschiedenen Blickwinkel ineinandergreifen. Und es zeigt etwas Beruhigendes: Sie brauchen kein kompliziertes System, um die Methode sinnvoll anzuwenden. Fünf Schritte — und Sie erkennen sie wieder, es ist exakt der Ablauf aus Kapitel 3. Erst den Systemkontext und die Datenflüsse skizzieren, ganz einfach, Kästen und Pfeile.

11:31 Dann Vertrauensgrenzen und Angriffsfläche markieren; besonders interessant wird es an der Grenze zum Zahlungsanbieter. Drittens je Element mit STRIDE Bedrohungen suchen, systematisch statt nach Gefühl. Viertens Gegenmaßnahmen aus den Prinzipien ableiten — und weil Sie das Prinzip benennen können, ist die Maßnahme auch begründet. Fünftens priorisieren und das Restrisiko benennen.

11:54 Was zunächst nach viel klang, ist am Ende ein Workshop von zwei bis drei Stunden. Die Abschlussübung ist zugleich die nützlichste: Wählen Sie selbst einen Anwendungstyp — am besten den, mit dem Sie tatsächlich arbeiten — und erstellen Sie ein kompaktes Bedrohungsmodell. Eine Systemskizze, drei priorisierte Bedrohungen, und zu jeder eine Gegenmaßnahme, die Sie an einem Prinzip festmachen können.

12:17 Diese letzte Anforderung ist der Kern: Wenn Sie sagen können "diese Maßnahme folgt aus Least Privilege", haben Sie ein Argument, das im Projekt trägt. Und wenn Sie das Ergebnis mitnehmen und im eigenen Team weiterentwickeln, hat dieses Seminar genau das erreicht, wofür es gedacht war. Blicken wir zurück auf sechs Kapitel. Sicherheit entsteht im Entwurf und trägt durch den ganzen Lebenszyklus — das war der rote Faden von der ersten Folie an.

12:42 Threat Modeling und STRIDE liefern die Methode, mit der Sie systematisch statt zufällig suchen; die sieben Prinzipien liefern die Leitplanken für die Antworten. Jeder Anwendungstyp hat seine typischen Bedrohungen, aber die Denkweise bleibt dieselbe — und diese Denkweise ist das, was Sie überallhin mitnehmen. Und schließlich: Sicherheit ist ein kontinuierlicher Prozess, kein einmaliges Projekt.

13:05 Wenn Sie einen Satz mitnehmen, dann vielleicht diesen: Fragen Sie früh, wer hier wem vertraut — und warum.

Danke!

13:11 Damit sind wir am Ende. Alle sechs Kapitel und die Übungsvorlagen liegen in der Freigabe — inklusive der Diagramm- und STRIDE-Vorlagen, der Prinzipien-Checkliste und der Phasenübersicht. Nehmen Sie ruhig eine Kleinigkeit mit in den Alltag: ein erstes Threat Model für ein einzelnes Feature, oder einen ADR mit einem Absatz zur Sicherheitsabwägung.

13:32 Das wirkt mehr als ein großer Vorsatz. Feedback und Fragen sind jederzeit willkommen, auch später — Sie erreichen uns unter info@HCO.de. Vielen Dank für Ihre Aufmerksamkeit und die Diskussionen.