APIs als Teil der Lieferkette: warum Schnittstellensicherheit zur Nachweispflicht wird
NIS2 zieht die Lieferkette in die Risikobetrachtung, und APIs sind ihre stillen Verbindungsstücke. Warum Berechtigungsfehler die größte API-Schwachstelle sind und warum sich nur absichern lässt, was sauber dokumentiert ist.
Software ist heute selten ein Monolith. Module, Partnerdienste und Mandanten reden über Schnittstellen miteinander, und genau diese APIs sind die stillen Verbindungsstücke der Lieferkette. NIS2 verlangt in der Risikobetrachtung ausdrücklich die Sicherheit der Lieferkette. Damit rückt eine Frage in den Vordergrund, die lange als rein technisch galt: Wie sicher und wie prüfbar sind die eigenen Schnittstellen?
Die Schnittstelle ist die Angriffsfläche
Die häufigsten API-Schwachstellen sind keine exotischen Exploits, sondern Berechtigungsfehler. In der OWASP API Security Top 10 steht Broken Object Level Authorization an erster Stelle: Eine API liefert Daten aus, ohne sauber zu prüfen, ob der anfragende Account sie überhaupt sehen darf. Eine veränderte Objekt-ID im Request genügt dann, um fremde Datensätze abzurufen. Drei Kontrollpunkte entscheiden in der Praxis über die Robustheit:
- Autorisierung pro Objekt: Jede Anfrage prüft, ob der Aufrufer genau dieses Objekt sehen oder ändern darf, nicht nur, ob er angemeldet ist.
- Authentifizierung: Tokens sind kurzlebig, gebunden und widerrufbar, statt langlebiger Allzweckschlüssel.
- Begrenzung: Rate-Limiting und Quoten verhindern, dass eine Schnittstelle zur Datenabflussstelle oder zum Lastvektor wird.
Was man nicht dokumentiert, kann man nicht absichern
Viele Vorfälle gehen nicht auf bekannte, sondern auf vergessene Schnittstellen zurück: Shadow-APIs, die nie im Inventar landeten, und Zombie-APIs, die nach einem Versionswechsel offen blieben. Ohne vollständiges, aktuelles Inventar bleibt jede Absicherung lückenhaft. Eine gepflegte OpenAPI-Beschreibung ist dabei mehr als Komfort für Entwickler: Sie ist der Vertrag, gegen den sich Berechtigungen, Versionen und erwartetes Verhalten überhaupt prüfen lassen. Ein dediziertes Developer-Portal, das diese Beschreibungen mandantenfähig und versioniert vorhält, macht aus verstreutem Wissen ein nachvollziehbares Verzeichnis.
Sicherheit als nachweisbare Eigenschaft
Im Prüfungsfall genügt es nicht zu sagen, die APIs seien abgesichert. Gefragt ist Evidenz: welche Schnittstellen existieren, in welcher Version, mit welchen Berechtigungen, und wer wann was abgerufen hat. Versionierung, Zugriffsprotokolle und ein gepflegtes Schnittstellenverzeichnis verwandeln Sicherheit von einer Behauptung in eine belegbare Eigenschaft. Das ist dieselbe Logik, die NIS2 an anderer Stelle für Monitoring und Meldung anlegt, nur angewandt auf die Verbindungsstücke zwischen den Systemen.
Die Lieferkette ist nur so vertrauenswürdig wie ihre Schnittstellen. Und eine Schnittstelle, die niemand vollständig kennt, lässt sich weder absichern noch belegen.