Verteilte Systeme End-to-End absichern: Kontrollen für APIs, Daten und Workloads

Der klassische Netzwerkperimeter verliert in modernen IT-Landschaften zunehmend an Bedeutung. Anwendungen, APIs, Daten und Workloads verteilen sich heute über Cloud-Plattformen, Rechenzentren und SaaS-Dienste hinweg.

Damit verschiebt sich auch der Fokus der Sicherheit. Entscheidend ist nicht mehr allein, ob sich etwas innerhalb oder ausserhalb eines Netzwerks befindet, sondern wer auf welche Ressourcen zugreifen kann – und wie sich dieser Zugriff kontrollieren und nachvollziehen lässt.

APIs müssen geschützt, Datenzugriffe überwacht und Workloads abgesichert werden. Sicherheitskontrollen dürfen dabei nicht an Infrastrukturgrenzen enden, sondern müssen entlang des gesamten Datenflusses greifen.

Die eigentliche Herausforderung besteht darin, Kontrolle nicht nur organisatorisch festzulegen, sondern technisch durchzusetzen. Wer jederzeit nachvollziehen kann, welche Identitäten auf welche Ressourcen zugreifen und welche Schutzmechanismen dabei greifen, schafft die Grundlage für ein belastbares Sicherheitsmodell.

Warum klassische Perimetersicherheit in verteilten Systemen versagt

Firewalls und VPNs wurden für eine Welt gebaut, in der Ressourcen zentral lagen und der Netzwerkrand klar definiert war. In modernen verteilten Architekturen existiert dieser Rand nicht mehr: Dienste kommunizieren über APIs, Workloads laufen in Clouds verschiedener Anbieter, Identitäten sind mobil.

Wer trotzdem am Perimeter-Modell festhält, schützt eine Grenze, die längst aufgelöst ist. Sicherheit muss auf Identität basieren, nicht auf Netzwerkposition.

Die drei Ebenen sicherer Infrastruktur

Prävention, Erkennung und Reaktion sind keine Optionen. Wer nur präventiv denkt, bemerkt Angriffe nicht. Wer nur auf Erkennung setzt, ohne die Angriffsfläche vorher systematisch verkleinert zu haben, kämpft mit strukturellem Nachteil – und verliert meistens langsam genug, um es lange nicht zu merken.

Ebene 1: Prävention – die Angriffsfläche systematisch verkleinern

API-Sicherheit: Wo Angreifer bevorzugt einsteigen

Programmierschnittstellen verbinden moderne Systeme. Sie sind per Definition erreichbar – und genau deshalb der bevorzugte Einstiegspunkt. Organisatorisch fallen sie häufig zwischen Teams. Technisch sind sie häufig stärker exponiert als notwendig.

Laut OWASP sind zwei Schwachstellen seit Jahren dominant:

• Excess Data Exposure: Schnittstellen geben mehr Daten zurück als für die Anfrage nötig. Ein Endpunkt, der das vollständige Nutzerobjekt zurückgibt, obwohl nur der Name benötigt wird, vergrössert die angreifbare Datenmenge ohne funktionalen Mehrwert.
• Broken Object Level Authorization (BOLA): Authentifizierte Nutzer:innen können durch Manipulation von Datensatz-IDs auf fremde Datensätze zugreifen – weil die Zugriffsprüfung auf Objektebene fehlt, nicht weil Authentifizierung fehlt.

Beides ist eine Architekturentscheidung, die jemand nicht bewusst getroffen hat.

Sicherheitsregeln gehören nicht in die Geschäftslogik einzelner Dienste. Sie gehören auf Plattformebene. Ein zentrales API-Gateway übernimmt Authentifizierung, Zugriffsbeschränkung und Eingabevalidierung. Ein Token, das pauschal alles erlaubt, ist ein offenes Fenster mit Schloss auf der Aussenseite.

Datenverschlüsselung in der Cloud: drei Zustände, ein blinder Fleck

Daten existieren in drei Zuständen. Die meisten Sicherheitskonzepte adressieren zwei davon.

At Rest – gespeicherte Daten: Verschlüsselung schützt gegen physischen Verlust von Speichermedien, nicht gegen eine:n Angreifer:in mit laufendem Systemzugriff. Die eigentliche Kontrolle liegt im Schlüsselmanagement. Wer Daten und Verschlüsselungsschlüssel beim selben Anbieter ablegt, hat eine Abhängigkeit geschaffen, die bei einer Behördenanfrage, einer Kontosperrung oder einem Sicherheitsvorfall nicht kontrollierbar ist.

Das gilt insbesondere für Anbieter unter US-amerikanischem Recht. Der CLOUD Act erlaubt US-Behörden den Zugriff auf Daten amerikanischer Unternehmen – unabhängig davon, wo diese Daten physisch liegen. Europäische Unternehmen, die das nicht eingepreist haben, verfügen über keine ausreichende Datenstrategie.

In Transit – übertragene Daten: TLS nach aktuellem Standard ist nicht verhandelbar. Veraltete Protokollversionen in Produktivumgebungen sind ein bekanntes Problem – und eines, das sich ohne grossen Aufwand beheben lässt. Dass es trotzdem regelmässig nicht passiert, ist eine einfache Organisationsfrage.

In Use – Daten in aktiver Verarbeitung: Zur Verarbeitung müssen Daten entschlüsselt werden. In diesem Moment sind sie angreifbar. Hardwarebasierte Isolationsverfahren – sogenannte Trusted Execution Environments (TEEs) – bieten Schutz auch in diesem Zustand. Kein Allheilmittel, aber für kritische Workloads die konsequenteste verfügbare Antwort auf die Frage, was passiert, wenn jemand Zugriff auf die Infrastruktur erhält.

Zero Trust Architektur als Architekturprinzip

Zero Trust bedeutet: Kein Prozess, keine:r Nutzer:in und kein System erhält Vertrauen allein auf Basis seiner Netzwerkposition. Jeder Zugriff wird explizit autorisiert, kontinuierlich geprüft und minimal gewährt. Identität wird zur zentralen Kontrollinstanz – für Personen ebenso wie für technische Dienste.

In containerisierten Umgebungen bedeutet das: explizite Kommunikationsregeln zwischen Diensten, verschlüsselt verwaltete Zugangsdaten und automatisierte Sicherheitsprüfungen direkt im Entwicklungsprozess. Eine fehlerhaft konfigurierte Ressource schlägt beim Überprüfungsschritt fehl – nicht erst beim externen Sicherheitstest.

Ebene 2: Erkennung – sehen, was in der eigenen Infrastruktur passiert

Prävention allein reicht nicht. Ein:e Angreifer:in, der oder die trotz aller Kontrollen eindringt, hinterlässt Spuren – aber nur dann, wenn man sie aufzeichnet und versteht.

Anfragen über mehrere Dienste hinweg müssen nachvollziehbar sein. Ein Dienst, der plötzlich zehnmal mehr ausgehende Verbindungen aufbaut als üblich, ist ein Signal – unabhängig davon, ob das verwendete Protokoll bekannt ist.

Verhaltensbasierte Erkennung schlägt musterbasierte Erkennung, wenn es um neue Angriffsmethoden geht. Bekannte Angriffsmuster kann man nachschlagen. Unbekannte erkennt man nur durch ein präzises Verständnis des normalen Verhaltens – eines, das kontinuierlich aufgebaut und gepflegt wird. Wer dieses Bild nicht hat, sieht Angreifer:innen erst, wenn es zu spät ist.

Ebene 3: Reaktion – Schadensbegrenzung als Architekturentscheidung

Auch bei hohen Sicherheitsstandards lassen sich Risiken nicht vollständig ausschliessen. Die Frage ist, wie schnell man es bemerkt und wie gross der Schaden bis dahin ist.

Drei Designprinzipien begrenzen diesen Schaden strukturell:

01 / Minimale Berechtigungen (Least Privilege): Ein kompromittierter Prozess kann nur tun, was er darf – nicht alles, was technisch möglich wäre. Breite Berechtigungen sind daher eine unnötige Risikoentscheidung.

02 / Netzwerksegmentierung: Hält einen Angriff lokal, statt ihn unkontrolliert ausbreiten zu lassen. Wer alles in einem flachen Netzwerk betreibt, hat keine Schadensbegrenzung eingebaut – nur eine Frage der Zeit bis zur lateralen Ausbreitung.

03 / Bedrohungsmodellierung im Entwurfsprozess: Strukturiertes Nachdenken über Angriffsvektoren, bevor die erste Zeile Code geschrieben wird, ist günstiger als jede nachträgliche Korrektur. Deutlich günstiger.

Geteilte Verantwortung ist keine Entschuldigung

In Cloud- und Managed-Service-Umgebungen definiert der Anbieter, was er absichert. Der Rest liegt bei den Betreiber:innen. Wer das nicht explizit geklärt hat, hat eine Lücke im Sicherheitsmodell – und erfährt es meistens dann, wenn jemand anderes sie gefunden hat.

Das gilt für jeden Anbieter. Es gilt besonders für Anbieter, bei denen unklar ist, ob eine Behördenanfrage in einem anderen Rechtsraum die eigene Compliance-Architektur übersteigen kann.

Souveräne Infrastruktur ist die Antwort auf die Frage, wer im Ernstfall das letzte Wort über die eigenen Daten hat.

Sicherheit ist eine Architekturentscheidung

Die Angriffsfläche lässt sich nicht auf null reduzieren. Sie lässt sich systematisch verkleinern – durch explizite statt implizite Vertrauensbeziehungen, Verschlüsselung auf allen drei Ebenen, Sichtbarkeit, die sicherheitsrelevante Ereignisse erkennbar macht, und organisatorische Klarheit darüber, wer für welchen Teil der Infrastruktur verantwortlich ist.

Und durch die Entscheidung, bei wem man diese Infrastruktur betreibt.

Wer das als zu aufwändig einstuft, sollte die Kosten eines ernsthaften Sicherheitsvorfalls dagegen rechnen.