# Ein praktisches Bedrohungsmodell für Ihr gehostetes Projekt | SwissOctet Insights https://swissoctet.com/de/insights/threat-model-a-hosted-project/ SwissOctet / Einblicke / Betrieb ab Tag zwei Betrieb ab Tag zwei Angewandt · 6 Min. Lesezeit Ein praktisches Bedrohungsmodell für Ihr gehostetes Projekt Ordnen Sie Assets und Vertrauensgrenzen zu, wählen Sie einige realistische Ausfallszenarien und verwandeln Sie diese in testbare Kontrollen. Von SwissOctet Editorial Leitfaden speichern Link kopieren AUF DIESER SEITE 01 Definieren Sie einen Umfang, der klein genug zum Durchdenken ist 02 Zeichnen Sie die Stellen ein, an denen sich das Vertrauen ändert 03 Wählen Sie konkrete Ausfallszenarien 04 Priorisieren Sie nach Auswirkung und glaubhaftem Pfad 05 Testen Sie die Kontrollen in einer autorisierten Umgebung 06 Halten Sie das Modell mit Änderungen verbunden Ihre praktische Checkliste Quellen & weiterführende Literatur Zurück zur Bibliothek DIE DIREKTE ANTWORT Ein nützliches Bedrohungsmodell erklärt, was Sie schützen, wer oder was es beeinflussen kann, wo sich das Vertrauen ändert und wie Sie die wichtigsten Risiken reduzieren und testen werden. Beginnen Sie mit dem tatsächlichen Projekt statt mit einer generischen Liste von Werkzeugen. 01 Definieren Sie einen Umfang, der klein genug zum Durchdenken ist Beginnen Sie mit einem funktionierenden Dienst: einem Kundenportal, einer Publishing-Seite oder einer internen Anwendung. Schreiben Sie die Komponenten auf, die Sie betreiben, und die externen Systeme, auf die Sie sich verlassen. Ein Bedrohungsmodell sollte Annahmen sichtbar machen, nicht suggerieren, dass jeder mögliche Angriff gelöst wurde. Halten Sie die erste Version klein genug, dass die Personen, die die Anwendung bereitstellen, sie ohne einen separaten Berater zur Interpretation des Diagramms erklären können. Listen Sie die wertvollen Ergebnisse und Assets auf. Dazu können Kundendaten, Administratorzugriff, Zahlungsstatus, veröffentlichte Inhalte und die Fähigkeit zur Wiederherstellung des Dienstes gehören. Verfügbarkeit kann ein Asset sein, auch wenn die Informationen öffentlich sind. Entscheiden Sie, welche Ausfälle unpraktisch wären und welche Menschen oder die Organisation schädigen würden. Diese Unterscheidung hilft Ihnen, Kontrollen zu priorisieren, statt jede Warnung gleich zu behandeln. 02 Zeichnen Sie die Stellen ein, an denen sich das Vertrauen ändert Die Threat-Modeling-Leitlinien von OWASP verwenden Datenflüsse und Vertrauensgrenzen, um ein Design verständlich zu machen. Zeichnen Sie für eine kleine gehostete Anwendung den Browser, den Webprozess, die Datenbank, den Administrator, das Backup-Ziel und externe Integrationen. Markieren Sie die Informationen, die sich zwischen ihnen bewegen. Eine Anfrage, die von einem nicht vertrauenswürdigen Client in eine privilegierte Serveroperation übergeht, verdient ausdrückliche Validierung und Autorisierung. Gehen Sie nicht davon aus, dass Komponenten innerhalb derselben Maschine alle gleichermaßen vertrauenswürdig sind. Ein öffentlicher Upload-Prozess sollte nicht dieselben Berechtigungen haben wie die Datenbankadministration. Ein Backup-Job benötigt möglicherweise Lesezugriff, ohne Live-Anwendungsdatensätze ändern zu können. Die Trennung dieser Rollen macht die Auswirkung einer kompromittierten Komponente leichter eindämmbar und die erforderlichen Berechtigungen leichter überprüfbar. 03 Wählen Sie konkrete Ausfallszenarien Verwenden Sie eine Handvoll plausibler Ereignisse, um das Design herauszufordern. Ein Angreifer stiehlt ein Administratorkennwort; ein Benutzer fordert den Datensatz eines anderen Benutzers an; ein Upload füllt die Festplatte; eine Bereitstellung legt eine Konfigurationsdatei offen; eine Wiederherstellungskopie kann nicht wiederhergestellt werden. Beschreiben Sie die Ausgangsbedingung, die betroffene Komponente und die Konsequenz. Ein konkretes Szenario ist leichter zu testen als eine breite Anweisung zur Verbesserung der Sicherheit. Beziehen Sie Fehler und Missbrauch legitimer Workflows ebenso ein wie externe Eindringlinge. Ein Wiederholungsversuch kann zwei wertvolle Vorgänge erzeugen, oder zwei Anfragen können um dieselbe Änderung an einem Objekt konkurrieren. Die Business-Logic-Leitlinien von OWASP heben diese Prozessannahmen hervor. Prüfen Sie, wer einen Workflow in seinen nächsten Zustand versetzen darf und ob das Wiederholen oder Umordnen einer Anfrage das Ergebnis unerwartet ändert. Szenario Zu untersuchende Kontrolle Zu erfassende Nachweise Gestohlenes Administrationskennwort Eingeschränkter Zugriff und ein zweiter Faktor, wo unterstützt Eine unbefugte Anmeldung kann nicht abgeschlossen werden Objekt eines anderen Benutzers angefordert Serverseitige Objekt-Autorisierung Ein isolierter Test liefert ein verweigertes Ergebnis Festplatte durch Uploads erschöpft Größen-, Quota- und Aufbewahrungskontrollen Ein Limit wird vor dem Dienstausfall durchgesetzt Doppelte Workflow-Anfrage Idempotenz und Transaktionsgrenzen Eine wiederholte Anfrage erzeugt ein Ergebnis 04 Priorisieren Sie nach Auswirkung und glaubhaftem Pfad Notieren Sie für jedes Szenario seine potenzielle Auswirkung und die Bedingungen, unter denen es auftreten kann. Vermeiden Sie die Vortäuschung, dass eine geschätzte numerische Punktzahl eine präzise Wahrscheinlichkeit ist. Sie können dennoch ein im Internet exponiertes schwaches Passwort von einem stark bedingten lokalen Ereignis unterscheiden. Weisen Sie den wichtigen Risiken einen Verantwortlichen und einen praktischen nächsten Schritt zu, damit das Modell Arbeit erzeugt, die jemand tatsächlich erledigen kann. Betrachten Sie neben der Kompromittierung der Anwendung auch den Informationslebenszyklus. Ein Diagnose-Export kann während des ansonsten normalen Betriebs unnötige Daten offenlegen. Ein aufbewahrtes Kontofeld kann lange nach dem Ende seines Zwecks eine Exposition erzeugen. Eine Datenschutzprüfung kann daher Informationen entfernen oder die Aufbewahrung verkürzen, während eine Sicherheitsprüfung den Zugriff auf das verbleibende beschränkt. Beide Änderungen gehören ins Modell, wenn sie das Projekt schützen. 05 Testen Sie die Kontrollen in einer autorisierten Umgebung Erstellen Sie eine Staging-Umgebung mit repräsentativen Berechtigungen und fiktiven Datensätzen. Testen Sie verweigerten Zugriff, Anfragegrenzen, Workflow-Wiederholungen und Wiederherstellung. Verwenden Sie keine echten Kundendaten, wenn synthetische Daten das Verhalten demonstrieren können. Ziel ist es, die Kontrolle zu überprüfen, nicht beeindruckenden Angriffsverkehr zu erzeugen. Bleiben Sie innerhalb von Systemen, die Ihnen gehören oder deren Bewertung Sie ausdrücklich autorisiert haben. Halten Sie fest, was bestanden wurde, was fehlgeschlagen ist und was unbekannt bleibt. Ein Scanner-Ergebnis kann als Nachweis dienen, ersetzt aber keinen Test der Geschäftsregeln der Anwendung. Ebenso verifiziert eine Netzwerkschutzoption nicht die Objektberechtigung oder den Umgang mit geheimen Dateien. Fügen Sie die nützlichen Ergebnisse dem Szenario bei, damit künftige Betreuer verstehen, warum eine bestimmte Kontrolle existiert. 06 Halten Sie das Modell mit Änderungen verbunden Überprüfen Sie die relevanten Teile, wenn Sie eine Integration hinzufügen, einen neuen Endpunkt bereitstellen, ein Recht ändern oder Daten an ein anderes Ziel verschieben. Sie müssen nicht die gesamte Architektur für eine kleinere Textänderung neu zeichnen. Der Auslöser ist eine geänderte Annahme über Zugriff, Informationen oder Systemverhalten. Bewahren Sie das Modell neben der Bereitstellungs- und Wiederherstellungsdokumentation auf, anstatt es als einmaliges Workshop-Ergebnis zu belassen. SwissOctet bietet einen Katalog von Infrastrukturoptionen, kein vollständiges Bedrohungsmodell für Anwendungen. Wählen Sie die Konfiguration und Optionen, die Ihre Kontrollen unterstützen, und überprüfen Sie dann die Bereitstellung, die Sie erstellen. Ein kleines, gepflegtes Modell mit getesteten Maßnahmen ist nützlicher als eine große Sammlung von Sicherheitsprodukten ohne klare Erklärung der Risiken, die sie adressieren. MACHEN SIE ES ZU HANDLUNG Ihre praktische Checkliste. ✓ Listen Sie Assets und Folgen eines Fehlschlags auf. ✓ Zeichnen Sie Datenflüsse und Vertrauensgrenzen. ✓ Wählen Sie spezifische Szenarien für Eindringen, Fehler und Workflows. ✓ Weisen Sie den wichtigen Risiken Kontrollen und Verantwortliche zu. ✓ Testen Sie mit synthetischen Daten in einer autorisierten Umgebung. ✓ Überprüfen Sie das Modell, wenn sich eine relevante Annahme ändert. Checkliste herunterladen HÄUFIGE FRAGEN Die Details, die zählen. Brauche ich ein formales Framework, um anzufangen? + Nein. Ein kleines Diagramm und eine dokumentierte Sammlung von Szenarien können nützlich sein. Ein Framework hilft sicherzustellen, dass Sie Risiken konsistent überprüfen. Ersetzt ein Schwachstellenscanner die Bedrohungsmodellierung? + Nein. Scanner können technische Schwächen finden, während ein Bedrohungsmodell auch Designannahmen, Berechtigungen und Geschäftsworkflows untersucht. Wie oft sollte ich das Modell aktualisieren? + Aktualisieren Sie die betroffenen Teile, wenn sich Datenflüsse, Integrationen, Berechtigungen oder exponierte Funktionalität ändern, und überprüfen Sie ungelöste Risiken regelmäßig. PRIMÄRE REFERENZEN Gehen Sie zur Quelle. Diese Referenzen unterstützen die technischen Konzepte in diesem Leitfaden. Folgen Sie der aktuellen Dokumentation, bevor Sie ein Produktionssystem ändern. OWASP: Threat Modeling Cheat Sheet cheatsheetseries.owasp.org OWASP: Bedrohungsmodellierung in der Praxis devguide.owasp.org OWASP: Sicherheit der Geschäftslogik cheatsheetseries.owasp.org Redaktionelle Beratung durch SwissOctet. Beispiele sind illustrativ. Servicespezifikationen, verfügbare Optionen und vertragliche Bedingungen müssen separat überprüft werden. VERBINDEN SIE DAS WISSEN Verwandte Infrastruktur. Vector VPS Schweiz Metal Atlas Schweiz Canvas Web Schweiz HALTEN SIE DEN FADEN Ihre nächsten Feldnotizen. Alle Leitfäden entdecken FELDNOTIZ / 01 + Betrieb ab Tag zwei Angewandt Bauen Sie ein Backup, das Sie tatsächlich wiederherstellen können Wählen Sie ein Wiederherstellungsziel, schützen Sie eine unabhängige Kopie und üben Sie die Wiederherstellung, bevor ein Vorfall die Sache erzwingt. 4 Min. Lesezeit Den Leitfaden lesen FELDNOTIZ / 02 + Betrieb ab Tag zwei Angewandt Sichere Windows RDP-Administration ohne Zugriffsverlust Trennen Sie Netzwerkerreichbarkeit, Authentifizierung und Berechtigungen und prüfen Sie einen Wiederherstellungsweg, bevor Sie den Fernzugriff einschränken. 6 Min. Lesezeit Den Leitfaden lesen FELDNOTIZ / 03 + Betrieb ab Tag zwei Angewandt Eine Linux VPS-Härtungsgrundlage, die Sie pflegen können Sichere Administration, nur erforderliche Dienste bereitstellen und Updates sowie Wiederherstellung einrichten, ohne sich selbst auszusperren. 6 Min. Lesezeit Den Leitfaden lesen