Jede Security-Architektur macht dieselbe implizite Zusage: Wenn eine Komponente kompromittiert wird, enthält die Grenze den Schaden. Das Web-Interface fällt, aber die Firmware hält. Die Mobile-App wird reverse-engineered, aber das Backend verifiziert. Diese Zusage ist leicht zu zeichnen und schwer zu halten, потому sie hängt daran, dass jeder Übergangspunkt das durchsetzt, was das Diagramm annimmt.
In der Praxis erodieren Grenzen während der Entwicklung. Ein Debug-Pfad kommt dazu, der ohne Authentisierung kreuzt. Ein Dienst wird aus Performance geteilt, und die interne Schnittstelle erbt Vertrauen, das nie erneut geprüft wurde. Ein Firmware-Update bringt eine neue Komponente auf die falsche Seite einer Grenze. Keine dieser Änderungen sieht nach Security-Entscheidung aus, sie sehen nach Engineering aus, und das Diagramm beschreibt still das Produkt nicht mehr.
Die Architektur-Frage ist deshalb nicht „haben wir Grenzen“, sondern „erzwingt das implementierte Produkt noch die Grenze, die das Design verspricht“. Diese Frage lässt sich nur beantworten, indem man Angriffspfade durch das echte System geht, nicht durch Review des Diagramms.
Grenz-Integrität hängt von mehreren technischen Annahmen ab.
- Grenz-Definition Welche Vertrauensgrenzen existieren tatsächlich im implementierten Produkt, nicht nur im Design-Dokument?
- Übergangs-Durchsetzung Ist jeder Übergangspunkt authentisiert und autorisiert, oder vertrauen manche Übergänge dem Caller per Position?
- Privilegien-Trennung Wenn eine Komponente auf der Low-Seite kompromittiert ist: Welche Privilegien erbt der Angreifer an der nächsten Grenze?
- Secret-Platzierung Welche Secrets sind von welcher Seite aus zugänglich, und exponiert eine Low-Seite-Kompromittierung High-Seite-Credentials?
- Annahmen-Gültigkeit Welche Annahmen (physischer Zugriff ist schwer, interne Netze sind sicher, Debug ist deaktiviert) halten in eingesetzten Produkten noch?
- Angriffspfad-Abdeckung Wurden die dokumentierten Angriffspfade end-to-end am realen Produkt gegangen?
- Drift seit dem Design Welche Implementierungs-Änderungen haben Komponenten bewegt oder Übergänge hinzugefügt, seit die Architektur zuletzt reviewt wurde?
Die Grenze war korrekt gezeichnet. Die Implementierung hat sie gekreuzt.
Die Architektur trennt die nutzerseitige Schnittstelle von der Steuerkomponente durch eine authentisierte Grenze. Während der Entwicklung kam ein Diagnose-Feature dazu, das aus einem niedriger privilegierten Kontext über die Grenze ruft, implementiert für Geschwindigkeit, authentisiert per Netz-Position statt Identität.
Der Angreifer kompromittiert die Interface-Komponente, nutzt den Diagnosepfad, und landet innerhalt der Grenze mit den Privilegien eines vertrauten internen Callers. Die Zeichnung war nie falsch; das Produkt ist von ihr abgedriftet.
Die Architektur validieren, indem man echte Angriffspfade geht.
Wir mappen die implementierten Vertrauensgrenzen aus dem laufenden Produkt, identifizieren die Übergänge und die Annahmen, die sie tragen, und gehen dann die Angriffspfade, die die Architektur zu blocken beansprucht: Low-Seite-Komponente kompromittieren und exakt testen, was die Grenze stoppt, und was nicht.
- Neue Produkt-Architektur oder großes Redesign
- Komponente geteilt, fusioniert oder verlegt
- Eine Kompromittierung wirft die Frage nach Containment
- Architektur-Dokumentation und Implementierung sind auseinandergedriftet
- Threat-Modell wird erstellt oder aufgefrischt
- Kunden-Assurance verlangt Architektur-Validierung