Fallstricke vermeiden beim Schnittstellen-Design

Egal, ob beim Daten-Austausch von System zu System oder mit Kunden und Dienstleistern, beim Anreichern künstlicher Intelligenzen mit Daten oder bei der Analyse und Optimierung von Prozessen: Schnittstellen / APIs sind der Backbone digitaler Strukturen und Prozesse – nicht nur im Unternehmen, sondern in der gesamten digitalen Welt. Damit Schnittstellen allerdings ihr jeweils angedachtes Anwendungsszenario erfüllen, gilt es einige Grundlagen zu beachten.

Zunächst ist es wichtig zu verstehen, welche Systeme beim gewünschten Datenaustausch überhaupt beteiligt sind. Denn meist handelt es sich nicht nur um zwei miteinander kommunizierende Systeme, sondern es sind auch diverse Middleware bzw. weitere Stationen auf dem Weg zu und vom jeweiligen Schnittstellenpartner involviert. Es stellt sich also die Frage, ob alle beteiligten Systeme überhaupt miteinander kommunizieren können bzw. ob dafür ggf. noch zusätzliche Komponenten benötigt werden. Ein gängiges Beispiel im Bereich der Webservices ist die „Übersetzung“ des Netzwerkprotokolls SOAP (Simple Object Access Protocol) in das REST-Format (Representional State Transfer). Mit Tools wie beispielsweise Orchestra lassen sich solche Konvertierungen optimal durchführen.

Ein weiterer, zentraler Aspekt ist die Sicherheit der Schnittstelle. Der Austausch spezieller Zertifikate bildet dabei die Grundsicherung. Darüber hinaus bietet sich die Verwendung diverser Authentifizierungsmöglichkeiten wie die Token-basierten Verfahren Oauth und Oauth 2.0 oder Credential-basierte Verfahren wie Basic an. Die Sicherheit gilt es allerdings nicht nur bei der Infrastruktur zu beachten, sondern auch Softwarearchitekten und Softwareentwickler müssen diesbezüglich gebrieft sein. Hier lohnt ein Blick in das ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge)-Framework, das aktuell 14 Kategorien aufzählt, die Angreifer nutzen, um ihre Ziele zu erreichen. Beispiele sind etwa die Privilege-Eskalation oder auch Command & Control. Werden diese schon bei der Architektur und Entwicklung der Schnittstellen beachtet, lassen sich potenzielle Sicherheitslücken bereits im Vorfeld proaktiv schließen.

Genauso wichtig ist es, einzelne Operationen sowie das API-Mapping innerhalb der Schnittstelle sauber zu definieren. Hier ist es wichtig festzulegen, welche Schnittstellen-Operationen überhaupt notwendig sind. Darüber hinaus bietet es sich an, weitere Rahmenbedingungen mit dem jeweiligen Schnittstellenpartner abzuklären. Denn es macht einen Unterschied, ob beispielsweise eine Master-Slave- oder eine Push-Push-Schnittstelle entwickelt wird und ob diese synchron oder asynchron verläuft.

Auch Sicherheitsaspekte beeinflussen das Schnittstellen-Design

Die Kunst bei der Definition einer Schnittstelle ist es, weder zu grob noch zu granular vorzugehen – abhängig ist dies allerdings auch von der Art der Schnittstelle: Werden zum Beispiel Assets importiert, genügt es mitunter schon, eine Schnittstellenaktion zum Erstellen und Updaten der Assets anzubieten. Ob für den Import tatsächlich Daten zu löschen sind, gilt es vorab genau zu prüfen. Falls versehentlich oder gar durch einen Cyberangriff Datensätze aus dem System entfernt werden, ist es oftmals sinnvoller, die Daten einfach zu deaktivieren oder zu archivieren.

Das bedeutet, dass auch Sicherheitsaspekte die Schnittstellenarchitektur beeinflussen. Je mehr Schnittstellenoperationen zugelassen und je offener die APIs gestaltet sind, desto mehr Einfallstore bieten sie für potenzielle Angreifer. Schnittstellen-Entwickler sollten sich also fragen: Welche Daten sollen sichtbar sein und welche Daten sollen wann veränderbar sein? Schützenswerte Daten sind in diesem Zusammenhang ein weiterer, wichtiger Aspekt. Empfehlenswert ist es daher, nur die notwendigsten Daten zugänglich zu machen, getreu dem Motto: so wenig wie möglich, so viel wie nötig. Dabei müssen immer – speziell in Bezug auf Kundendaten – auch etwaige Richtlinien wie die Norm ISO-27000 oder die GDPR (General Data Protection Resolution) im Blick behalten werden.

Natürlich spielt auch das Zusammenspiel zwischen API-Methoden und API-Mapping eine elementare Rolle im Schnittstellendesign. Als anschauliches Beispiel dient beispielsweise ein Change in einem Ticketsystem. Ein Change ist in der Regel ein linearer Prozess, der optimalerweise phasensynchron mit dem jeweiligen Schnittstellenpartner ablaufen sollte. Hier gilt es darauf zu achten, dass jeweils nur Schnittstellenaufrufe passend zur aktuellen Phase des Changes abgesetzt werden können. Denn es kann fatal sein, wenn der Schnittstellenpartner z.B. die eigene Risikobewertung oder Klassifizierung in dieser Implementierungsphase – also zu einem Zeitpunkt, zu dem diese Werte bereits feststehen müssen – ändern kann. Eine Lösung für diese Problemstellung kann beispielsweise das Ablehnen der Daten oder gar des kompletten Schnittstellenaufrufs mit einem eindeutigen Fehlerhinweis sein.

Gewünschten Nutzen der API definieren und Kosten- / Nutzen-Rechnung aufstellen

Alle oben genannten Punkte sind wichtige Überlegungen in Bezug auf das Schnittstellen-Design. Wichtig dabei ist es, niemals den Überblick über das Große und Ganze zu verlieren und stets den Kontext bzw. den Anwendungsfall und gewünschten Nutzen der geplanten Schnittstelle im Blick zu behalten. Sinnvolle Fragen sind in diesem Kontext z.B.: Gibt es interne Abhängigkeiten? Können Mitarbeiter die Schnittstelle nutzen, um beispielsweise Bestellungen für IT-Equipment oder Büromaterial zu tätigen? Wer arbeitet mit der Schnittstelle? Gibt es externe Abhängigkeiten? Wird Kunden durch beispielsweise Chatbots, oder durch Selfservice mit anschließender Ticketerstellung mehr Usability geboten? Auch hier: Wer arbeitet mit der Schnittstelle?

Im Falle der genannten Beispiele zeigt sich, dass APIs den Nutzern einen gewissen Komfort bieten können und dem Unternehmen möglicherweise auch dabei helfen, Geld einzusparen. Dabei spielt jedoch auch das Mengengerüst eine Rolle und es lohnt sich, vorab eine Kosten-Nutzen-Rechnung aufzustellen: Eine aufwändige Schnittstelle für 20 Anwender zu erstellen, wird sich in den seltensten Fällen lohnen, eine Schnittstelle für 200 Anwender hingegen sehr wahrscheinlich schon. Ein Gesamtüberblick lässt sich oft sehr gut mit Hilfe von Visualisierungen verschaffen – etwa in Form eines detaillierten Plans, der alle eingesetzten Komponenten, Anwender und alle weiteren beteiligten Faktoren aufzählt, Mengengerüste beziffert sowie Kosten abwägt. Hierbei gilt es, nicht nur die Kosten, sondern auch die Kostenersparnis bzw. den Benefit der API mit einzurechnen. Eine gute Schnittstelle kann ein hohes Investment sein, das sich mit der Zeit aber durchaus amortisiert und bezahlt macht – mit welchem Ziel auch immer.

Fazit

Zusammengefasst lässt sich feststellen, dass ein Schnittstellenprojekt kein Adhoc-Projekt sein kann, sondern in jeder Projektphase genügend Zeit bedarf, um insbesondere alle aktuellen und zukünftigen Szenarien, die die Schnittstelle betreffen, zu beleuchten und somit einen effizienten, langfristigen und nutzbaren Einsatz im jeweiligen Anwendungsfall zu gewährleisten.

Lukas Brinkmann, Solution Architect Enterprise Service Management bei der handz.on GmbH