Prinzipien sicherer Softwarearchitektur

Prinzipien sicherer Softwarearchitektur

0:00 Aus dem Threat Modeling ist eine Liste von Bedrohungen entstanden. Jetzt geht es um gute Antworten darauf — und die muss niemand neu erfinden. Sicherheitsprinzipien sind im Kern das Gedächtnis vergangener Vorfälle, verdichtet zu Entwurfsregeln. Jedes der sieben Prinzipien, die wir uns ansehen, ist aus Schaden entstanden, den andere schon genommen haben.

0:20 Das macht sie so wertvoll: Sie erlauben es, aus fremdem Lehrgeld zu lernen. Und sie funktionieren unabhängig von Sprache, Framework und Cloud-Anbieter, was in einem Fach, in dem sich alle drei Jahre alles ändert, eine seltene Eigenschaft ist.

Prinzipien sicherer Softwarearchitektur

0:35 Sieben Prinzipien stehen auf dem Programm, und wir gehen sie in Gruppen durch. Zuerst der Überblick — was ein Prinzip überhaupt leistet. Dann die beiden Rechte-Prinzipien Least Privilege und Separation of Duties. Danach Defense in Depth und Fail Secure, die sich mit dem Fall beschäftigen, dass etwas schiefgeht. Und zum Schluss die drei, die uns aus den vorigen Kapiteln schon begegnet sind: sichere Voreinstellungen, kleine Angriffsfläche, klare Vertrauensgrenzen.

1:02 Vier Punkte prägen dieses Kapitel. Erstens: Die sieben Prinzipien sind ein Werkzeugkasten für Architekturentscheidungen — Sie greifen zu dem, was zur Situation passt, nicht zu allen gleichzeitig. Zweitens, und das ist wichtig: Sie wirken zusammen, keines ersetzt die anderen. Wer nur eines konsequent umsetzt, hat eine starke Wand und offene Fenster daneben.

1:23 Drittens gehen wir von der abstrakten Regel zum konkreten Entwurf und zu Codebeispielen, damit die Prinzipien nicht Merksätze bleiben. Und viertens üben wir das, was Sie im Alltag am häufigsten brauchen werden: Prinzipverletzungen im Review erkennen und benennen können.

Prinzipien im Überblick

1:39 Bevor wir die einzelnen Regeln durchgehen, lohnt die Frage, warum es überhaupt sinnvoll ist, mit Prinzipien statt mit konkreten Vorgaben zu arbeiten. Die Antwort hat mit Haltbarkeit zu tun — und mit der Tatsache, dass Sie im Projektalltag ständig Entscheidungen treffen müssen, für die niemand eine Vorschrift geschrieben hat.

1:57 Genau für diese Lücke sind Prinzipien gemacht: Sie geben eine Richtung, wo eine Anleitung fehlt. Sicherheitsprinzipien sind bewährte, kontextunabhängige Entwurfsregeln, die das Risiko strukturell senken — unabhängig von Technologie oder Programmiersprache. Der Vergleich, der hier passt: Prinzipien verhalten sich zu konkreten Sicherheitsvorgaben wie Verkehrsregeln zu einem Navigationssystem.

2:20 Das Navi kennt den heutigen Weg, die Regel "rechts vor links" gilt auch auf einer Kreuzung, die noch niemand kartiert hat. Genauso überleben Prinzipien den nächsten Framework-Wechsel. Das ist keine Nebensächlichkeit: Eine konkrete Härtungsanleitung ist in drei Jahren veraltet. Least Privilege war vor dreißig Jahren richtig und wird es in dreißig Jahren noch sein.

2:42 Drei Gründe, warum sich das Auswendiglernen hier ausnahmsweise lohnt. Der erste: Sie leiten Entscheidungen, wenn konkrete Vorgaben fehlen — und das ist der Normalfall. Niemand hat für Ihre spezielle Architekturfrage eine Vorschrift geschrieben. Der zweite Grund ist praktischer, als er klingt: Prinzipien machen Sicherheit im Review benennbar.

3:02 "Das fühlt sich unsicher an" ist keine Diskussionsgrundlage, "das verletzt Least Privilege, weil der Dienst mit Adminrechten läuft" schon. Der dritte: Sie wirken in Kombination. Erst das Zusammenspiel erzeugt die Tiefe, die einen Angriff nicht nur erschwert, sondern ins Leere laufen lässt. Lesen Sie diese Übersicht nicht als Katalog, aus dem man auswählt, sondern als sieben Blickwinkel auf dieselbe Frage: Wie begrenzen wir Schaden?

3:28 Interessant ist, wie sie sich gegenseitig stützen. Least Privilege verkleinert den Schaden eines kompromittierten Kontos — und genau davon lebt Defense in Depth, das darauf setzt, dass eine durchbrochene Schicht nicht alles öffnet. Secure Defaults sorgen dafür, dass die anderen Prinzipien in der Praxis überhaupt ankommen, statt in der Dokumentation zu stehen.

3:48 Und die minimierte Angriffsfläche macht alle übrigen billiger, weil weniger zu schützen bleibt. Kein Prinzip steht für sich; sie verstärken einander — deshalb ist Rosinenpicken hier eine schlechte Strategie.

Least Privilege und Separation of Duties

4:00 Beginnen wir mit den beiden Prinzipien, die sich um Rechte drehen. Das eine begrenzt, wie viel jemand darf. Das andere sorgt dafür, dass niemand allein zu viel entscheiden kann. Beide arbeiten mit derselben Annahme, und die ist unbequem: Irgendwann wird ein Konto in falsche Hände geraten oder eine Person eine folgenschwere Entscheidung allein treffen.

4:20 Diese beiden Prinzipien sorgen dafür, dass daraus kein Totalschaden wird. Least Privilege heißt: Jeder Akteur bekommt nur die Rechte, die er wirklich braucht — und zwar auch nur so lange, wie er sie braucht. Separation of Duties verteilt kritische Abläufe auf mehrere Rollen, sodass keine einzelne Person allein Schaden anrichten kann.

4:39 Das Alltagsbild dafür kennt jeder aus dem Bankwesen: Wer eine Zahlung erfasst, gibt sie nicht selbst frei. Nicht, weil man den Mitarbeitenden misstraut, sondern weil ein Vier-Augen-Prinzip Fehler und Missbrauch gleichermaßen abfängt. Übertragen auf Software heißt das: Der Dienst, der Bestellungen schreibt, braucht kein Recht, die Benutzertabelle zu löschen — und die Freigabe eines Deployments gehört nicht in dieselbe Hand wie sein Bau.

5:04 Der stärkste Grund für Least Privilege ist die Schadensbegrenzung im Ernstfall. Sie können nicht ausschließen, dass ein Konto kompromittiert wird — aber Sie können entscheiden, was einem Angreifer damit offensteht. Ein Konto mit Leserechten auf eine Tabelle ist ein anderes Ereignis als ein Konto, das alles darf. Separation of Duties zielt auf eine andere Gefahr: Alleingänge, ob böswillig oder schlicht unbedacht.

5:28 Und ein dritter Punkt, den man leicht unterschätzt: Kleine Rechteräume sind überhaupt erst prüfbar. Bei einer Handvoll gezielt vergebener Rechte kann jemand nachvollziehen, ob sie stimmen. Bei einem pauschalen "darf alles" gibt es nichts mehr zu prüfen. Das Beispiel zeigt zwei Datenbank-Berechtigungen im Vergleich. Oben die bequeme Variante: Das Anwendungskonto darf alles in der Datenbank — auch löschen, auch Strukturen ändern, auch in Tabellen, die es nie anfassen wird.

5:56 Unten dieselbe Anwendung mit exakt den Rechten, die sie zum Arbeiten braucht, und das auch nur auf einer Tabelle. Worauf es hier ankommt, ist nicht die SQL-Syntax, sondern die Richtung, aus der man kommt: Beginnen Sie bei null und fügen Sie hinzu, was nachweislich gebraucht wird — statt breit zu vergeben und später aufzuräumen.

6:15 Denn dieses Aufräumen findet in der Praxis nie statt. Im Zweifel entziehen, nicht vorsorglich vergeben. Die drei häufigsten Verstöße im Alltag. Erstens: Dienste, die pauschal als Administrator oder root laufen — meistens, weil es beim Aufsetzen schneller ging und niemand später den Mut hatte, Rechte wegzunehmen. Zweitens: Rechte, die einmal breit vergeben und nie wieder aufgeräumt wurden; das betrifft besonders Konten von Menschen, die längst in anderen Projekten arbeiten.

6:43 Und drittens ein subtiler Fall: das Vier-Augen-Prinzip, das organisatorisch gilt, technisch aber umgehbar ist. Wenn derselbe Mensch beide Freigaben klicken kann, weil er beide Rollen hat, ist es ein Papierprinzip. Prüfen Sie das ruhig einmal in Ihrem eigenen Deployment-Prozess — die Ergebnisse sind oft überraschend.

Defense in Depth und Fail Secure

7:02 Die nächsten beiden Prinzipien gehen von einer unbequemen Annahme aus: Etwas wird schiefgehen. Die Frage ist nur, was dann passiert — und darauf kann man einen Entwurf vorbereiten. Das ist ein anderer Blick als der, den wir aus dem Testen kennen. Dort versuchen wir, Fehler zu verhindern. Hier planen wir für den Fall, dass die Verhinderung misslingt — und genau diese Vorsorge unterscheidet robuste Systeme von hoffnungsvollen.

7:28 Defense in Depth staffelt mehrere unabhängige Schutzschichten, sodass eine überwundene Schicht nicht gleich das ganze System öffnet. Fail Secure sorgt dafür, dass ein System im Fehlerfall in den sicheren Zustand fällt. Das Bild für das erste Prinzip ist die Burg: Graben, Mauer, Innenhof, Bergfried — nicht weil man der Mauer misstraut, sondern weil man weiß, dass irgendwann jemand darüberkommt.

7:50 Wichtig ist dabei das Wort "unabhängig": Drei Schichten, die alle auf derselben Annahme beruhen, sind in Wahrheit eine. Fail Secure wiederum ist die Frage, was die Tür macht, wenn der Strom ausfällt — und in der Software heißt die richtige Antwort fast immer: sie bleibt zu. Der Ausgangspunkt ist Demut: Keine einzelne Schutzmaßnahme ist unfehlbar.

8:10 Jede Bibliothek hat Lücken, jede Konfiguration kann falsch sein, jeder Mensch klickt irgendwann auf den falschen Link. Wer davon ausgeht, baut anders. Beim Fail Secure geht es um eine Entscheidung, die im Code oft unbewusst fällt: Ein Fehler soll Zugriff verweigern, nicht versehentlich gewähren — und die Betonung liegt auf "versehentlich", denn genau so passiert es.

8:32 Und ein Argument, das im Betrieb zählt: Schichten kaufen Zeit. Ein Angreifer, der sich durch mehrere Ebenen arbeiten muss, hinterlässt Spuren und braucht länger — und in dieser Zeit kann jemand reagieren. Ein kurzer Ausschnitt mit großer Wirkung. Eine Zugriffsprüfung ruft eine Funktion auf, die entscheidet, ob jemand darf.

8:51 Interessant ist der Fehlerzweig: Wenn die Prüfung selbst scheitert — die Datenbank nicht erreichbar, ein unerwarteter Zustand —, dann lautet die Antwort "nein". Das klingt selbstverständlich, ist es im Alltag aber nicht. Der bequeme Weg wäre, im Fehlerfall durchzulassen, damit niemand ausgesperrt wird und das Support-Telefon still bleibt.

9:11 Genau dieser Reflex hat schon Systeme geöffnet. Merken Sie sich den Satz aus der Fußzeile: Der Default-Zweig einer Zugriffsprüfung heißt "nein". Wenn Sie die Prüfung nicht durchführen konnten, wissen Sie nicht, ob jemand darf — und Nichtwissen ist kein Grund zu erlauben. Jetzt drehen wir die Perspektive: Statt Prinzipien anzuwenden, suchen Sie ihre Verletzung.

9:33 Sie bekommen einen bewusst schwach entworfenen Service und benennen mindestens zwei verletzte Prinzipien — jeweils mit Begründung und einem konkreten Verbesserungsvorschlag. Genau diese Fähigkeit brauchen Sie im Code-Review, und die Begründung ist dort wichtiger als der Befund: Ein Hinweis, der ein Prinzip benennt, lässt sich diskutieren, ein Bauchgefühl nicht.

9:53 Nehmen Sie sich Zeit für die Verbesserung — oft merkt man erst beim Formulieren der Lösung, ob man das Problem wirklich verstanden hat.

Secure Defaults, Angriffsfläche und Vertrauensgrenzen

10:01 Bleiben die drei Prinzipien, die uns in diesem Seminar schon begegnet sind. Sie tauchen hier wieder auf, weil sie an dieser Stelle etwas anderes sind als vorher: nicht mehr Analyse, sondern Entwurfsregel. Im Threat Modeling haben wir Vertrauensgrenzen benutzt, um Bedrohungen zu finden. Jetzt benutzen wir sie, um ein System zu bauen.

10:21 Derselbe Begriff, andere Richtung — und das ist typisch für Sicherheitsarbeit. Drei Regeln, ein gemeinsamer Gedanke. Secure Defaults liefern den sicheren Zustand ab Werk — der sichere Weg ist der Standardweg, nicht die Fleißaufgabe. Angriffsflächen- minimierung entfernt, was nicht gebraucht wird, denn was nicht existiert, kann nicht angegriffen werden.

10:42 Und sichere Vertrauensgrenzen machen explizit, wo Vertrauen endet und Prüfung beginnt. Was die drei verbindet: Sie senken das Risiko, ohne dass jemand im laufenden Betrieb etwas richtig machen muss. Das ist ihre eigentliche Stärke. Alle Sicherheit, die von Disziplin abhängt, erodiert unter Zeitdruck — Sicherheit, die in der Struktur steckt, hält auch am Freitagnachmittag.

11:06 Vier Schritte, die diese drei Prinzipien in Handgriffe übersetzen. Erstens: Jede Voreinstellung auf "sicher, Abschalten möglich" stellen — nicht umgekehrt. Zweitens alles abschalten, was nicht gebraucht wird: Endpunkte, Ports, Features aus Projekten, die nie zu Ende gingen. Drittens die Vertrauensgrenzen im Entwurf markieren, sichtbar im Diagramm, damit sie nicht nur im Kopf einer Person existieren.

11:30 Und viertens, der Schritt, der die anderen wirksam macht: An jeder dieser Grenzen wird validiert und autorisiert. Der Leitgedanke steht in der Fußzeile — Sicherheit als Standardpfad, nicht als Zusatzaufwand. Was Aufwand ist, wird weggelassen; was Standard ist, passiert. Drei Klassiker zum Abschluss. Bequeme, aber offene Voreinstellungen — sie entstehen fast immer aus guter Absicht, nämlich dem Wunsch, dass die Software beim ersten Start einfach läuft.

11:59 Der zweite: das interne Netz oder "unser eigener Client" als vertrauenswürdig anzunehmen. Bei Clients ist das besonders heikel, denn alles, was auf einem fremden Gerät läuft, gehört Ihnen nicht, egal wer es geschrieben hat. Und drittens, direkt daran anschließend: Validierung nur im Frontend. Die gehört ins Frontend, unbedingt — für die Benutzerfreundlichkeit.

12:20 Aber sie ersetzt keine Prüfung hinter der Vertrauensgrenze, denn eine Anfrage muss nicht aus Ihrem Formular kommen. Halten wir fest: Sieben Prinzipien bilden einen Werkzeugkasten für sichere Architektur — kontextunabhängig, langlebig und im Review benennbar. Least Privilege und Separation of Duties begrenzen Rechte und Macht und sorgen dafür, dass ein Zwischenfall lokal bleibt.

12:43 Defense in Depth und Fail Secure machen das System fehlertolerant sicher: Sie funktionieren gerade dann, wenn etwas nicht funktioniert. Und Secure Defaults, kleine Angriffsfläche und klare Vertrauensgrenzen sorgen dafür, dass Sicherheit nicht von Disziplin abhängt. Was jetzt noch fehlt, ist der lange Atem — wie diese Prinzipien über den ganzen Lebenszyklus getragen werden.

Fragen & Ausblick

13:05 Kapitel 5 nimmt sich genau das vor: Security im Software Development Lifecycle — von der Anforderung über Review und Testautomatisierung bis in den Betrieb. Denn ein Prinzip, das nur im Entwurfsdokument steht, verändert kein System. In der Freigabe finden Sie eine Prinzipien-Checkliste, die sich gut als Ausgangspunkt für die eigene Review-Vorlage eignet — passen Sie sie ruhig an Ihren Kontext an.

13:29 Fragen jetzt gern, besonders zu den Prinzipien, die in Ihrem Projekt schwer durchzusetzen sind. Ansonsten erreichen Sie uns unter info@HCO.de.