Security by Design in der Praxis: Architekturmuster für sichere Microservices

Security by Design heißt bei Microservices: Jeder Dienst geht davon aus, dass sein Nachbar kompromittiert sein könnte, und prüft deshalb selbst, wer ihn aufruft. Wer Sicherheit erst nach dem Bau vor die Anwendung stellt, bekommt eine Firewall um ein Haus mit offenen Innentüren.

API-Gateway: ein Eingang statt vieler

Ein API-Gateway bündelt den gesamten Verkehr von außen und übernimmt Authentifizierung, Ratenbegrenzung und Protokollierung, bevor eine Anfrage einen internen Dienst erreicht. Die Dienste dahinter sind von außen nicht erreichbar; sie akzeptieren nur Aufrufe, die das Gateway signiert hat. Damit gibt es genau einen Punkt, an dem Regeln durchgesetzt und gehärtet werden, statt zehn Dienste mit zehn Interpretationen derselben Regel.

Vor das Gateway gehört eine Web Application Firewall (WAF), die Bots, Massenanfragen und bekannte Angriffsmuster abfängt, bevor sie Rechenzeit kosten. Für eine Bestandsanwendung ist das oft der erste Schritt, der sich ohne Umbau erreichen lässt.

Service Mesh: verschlüsselte Kommunikation zwischen Diensten

Ein Service Mesh wie Istio oder Linkerd legt eine Netzwerkschicht über alle Dienste, in der jeder Aufruf verschlüsselt und beide Seiten sich gegenseitig ausweisen (mTLS). Die Anwendungslogik ändert sich dafür nicht; das Mesh stellt Zertifikate aus, erneuert sie und lehnt Verbindungen ohne gültiges Zertifikat ab. Ein Bestandsdienst spricht dann nur mit dem Versanddienst, wenn beide sich ausgewiesen haben, egal ob ein Angreifer im selben Netz sitzt.

Ehrlich eingeordnet: Ein Mesh lohnt sich ab einer gewissen Anzahl Dienste. Für eine Anwendung mit drei Komponenten reicht oft TLS zwischen den Diensten und ein sauberes Netzsegment.

Token-basierte Autorisierung: jeder Dienst prüft selbst

Jeder Dienst prüft das eingehende JSON Web Token (JWT) eigenständig: Ist es gültig, von wem ausgestellt, welche Rolle enthält es. OAuth regelt, wer solche Token überhaupt bekommt. Ein Dienst für Kundenprofile liefert Daten nur an Aufrufer mit der passenden Rolle und weist alles andere ab, auch wenn die Anfrage aus dem eigenen Netz kommt. Der Gewinn: Ein gekaperter Dienst kann nicht beliebig andere Dienste aufrufen, weil ihm dafür die Berechtigung im Token fehlt.

Verschlüsselung ruhender und übertragener Daten

Sensible Daten liegen verschlüsselt in der Datenbank und werden nur über TLS übertragen. Das ist die Grundlage für Nachweise nach der DSGVO und branchenspezifischen Vorgaben. Entscheidend ist die Schlüsselverwaltung: Liegt der Schlüssel neben den Daten, hilft die Verschlüsselung bei einem Datenbankabzug nichts. Ein Secrets-Manager wie HashiCorp Vault trennt Schlüssel von Daten und protokolliert jeden Zugriff.

Fehlerisolierung: ein kompromittierter Dienst legt nicht alles lahm

Das Bulkhead-Muster gibt jedem Dienst eigene Ressourcen, damit ein überlasteter oder angegriffener Dienst die anderen nicht mitreißt. Ein Circuit Breaker unterbricht Aufrufe an einen Dienst, der wiederholt fehlschlägt, statt den Fehler durch die ganze Kette zu tragen. Fällt der Anmeldedienst unter Last aus, bleibt die Übersicht für bereits angemeldete Nutzer erreichbar. Sicherheit und Verfügbarkeit sind hier dasselbe Muster.

Sicherheitsupdates und Backups auslagern: Betrieb gehört zur Architektur

Die meisten erfolgreichen Angriffe auf Webanwendungen nutzen keine Lücke im Architekturmuster, sondern ein Update, das seit Monaten aussteht, oder ein Backup, das nie zurückgespielt wurde. Wer Security by Design ernst meint, plant deshalb den Betrieb mit: Wer spielt Sicherheitsupdates ein, in welcher Frist, wer prüft, dass Backups wiederherstellbar sind, wer schaut nachts auf das Monitoring.

Für IT-Leitungen ohne eigenes Entwicklungsteam ist das der Punkt, an dem Auslagern sinnvoll wird. dataso betreibt Anwendungen mit Rund-um-die-Uhr-Monitoring, Sicherheitsupdates, Backups und verbindlichen Reaktionszeiten; die Architekturmuster oben bauen wir ein, bevor die Anwendung live geht, nicht danach. Grenze ehrlich benannt: Die Reaktionszeit garantieren wir, die Lösung nach bestem Bemühen.

Der nächste Schritt

Zeichnen Sie Ihre Anwendung mit allen Diensten auf und markieren Sie an jeder Verbindung, wer dort prüft, ob der Aufrufer berechtigt ist. Wo die Markierung fehlt, ist die offene Innentür. Wenn Sie den Plan mit jemandem durchgehen wollen, der solche Systeme baut und betreibt, nehmen wir uns eine halbe Stunde: Potenzial-Check buchen.