Foto zum Beitrag API zwischen Unternehmenssoftware: Anforderungen, Kontrollen und Personendaten
Foto von Christina Morillo auf Pexels

Prozessautomatisierung

API zwischen Unternehmenssoftware: Anforderungen, Kontrollen und Personendaten

So gestalten Sie eine Integration zwischen Unternehmenssoftware über APIs: Mapping der Datenflüsse, Sicherheitskontrollen, Zugriffsverwaltung und Umgang mit Personendaten gemäss dem Datenschutzgesetz (DSG).

Was eine API zwischen zwei Unternehmenssoftwarelösungen wirklich verbindet

Eine API (Application Programming Interface, Programmierschnittstelle) ist eine Software-Brücke, die es unterschiedlichen Anwendungen ermöglicht, zu kommunizieren und Daten auszutauschen. Im Unternehmen dient sie dazu, Integrationsflüsse bereitzustellen und Anwendungen, Systeme, Prozesse und Daten zu verknüpfen. Es reicht nicht aus, zwei Programme miteinander sprechen zu lassen: Die Informationen müssen entlang eines definierten Pfades reisen, wobei es einen Anbieter und einen Abnehmer gibt.

Die operative Wirkung betrifft diejenigen, die Prozesse und Systeme verwalten. Abläufe werden verschlankt, repetitive Workflows automatisiert und Informationen in Echtzeit aktualisiert, ohne dass Daten von einem Bildschirm zum anderen kopiert oder Dateien neu geladen werden müssen. Eine im ERP erfasste Bestellung kann gleichzeitig Logistik, Fakturierung und Kundenservice aktualisieren. Eine Änderung der Stammdaten kann sich auf alle Systeme auswirken, die diese nutzen.

Praktisch gesehen liegt der Unterschied zwischen einem einzelnen Aufruf und einer strukturierten Integrationsverwaltung darin. Ersteres löst einen spezifischen Einzelfall: Ein System liest einmalig ein Datum aus einem anderen. Letzteres ist ein organisiertes Bündel von Flüssen mit mehreren beteiligten Systemen, vereinbarten Formaten, definierten Verantwortlichkeiten und laufender Betreuung. Man befindet sich im zweiten Szenario, sobald die Integration mehr als zwei Anwendungen verbindet, Daten berührt, die kritische Prozesse speisen, oder Versionsänderungen, neue Funktionen oder Softwareaustausche bewältigen muss. In solchen Situationen wird aus einem isolierten Aufruf eine Integration, die geplant, dokumentiert und gewartet werden muss.

Isolierte Integration vs. strukturierte Integration: Hauptunterschiede

Zweck
Lösung eines spezifischen Falls
Umfang
Ein aufrufendes und ein aufgerufenes System
Dauer
Punktuell, ohne geplante Wartung
Verwaltung
Ohne formale Dokumentation oder Versionierung
Gegenteiliger Zweck
Entwicklung eines organisierten Flusses zwischen mehreren Systemen
Umfang
Mehrere Anwendungen, kritische Prozesse, gemeinsame Daten
Dauer
Langfristig tragfähig, mit kontinuierlicher Wartung
Verwaltung
Dokumentiert, versioniert, mit definierten Verantwortlichkeiten

Anforderungen, die eine Integration langfristig tragfähig machen

Die erste Anforderung ist die Klarheit des Flusses. Für jede Integration muss festgelegt werden, wer das Datum bereitstellt und wer es konsumiert, in welchem Format, mit welcher Frequenz und in welche Richtung. Ein ambiguos beschriebener Fluss führt zu Integrationen, die in Tests funktionieren, aber in der Produktion scheitern. Beide Seiten interpretieren Pflichtfelder, zulässige Werte und Grenzfälle (fehlende Datensätze, Duplikate, nachträgliche Korrekturen) unterschiedlich.

Technisch gesehen umfasst eine nachhaltige Integration vier wiederkehrende Elemente. Versionierung, um Änderungen einzuführen, ohne bestehende Konsumenten zu unterbrechen. Dokumentation für Entwickler mit Endpoints, akzeptierten Parametern und erwarteten Fehlermeldungen. Zugriffsverwaltung zwischen Systemen: Wer darf welche Schnittstelle mit welchen Anmeldedaten aufrufen? Verwaltung des Lebenszyklus der APIs, von der Veröffentlichung bis zur Stilllegung, einschliesslich zurückgezogener Versionen.

API-Sicherheit: Welche Kontrollen vor der Freigabe eines Kanals vorgesehen werden müssen

API-Sicherheit bedeutet die Implementierung von Kontrollen und Protokollen, um Angriffe oder unbefugte Zugriffe zu verhindern. Jeder freigegebene Endpoint ist eine Angriffsfläche: Er ist ein von aussen erreichbarer Kanal der Anwendung, der für den Datentransfer konzipiert ist. Er kann daher von Akteuren missbraucht werden, die Daten lesen, verändern oder blockieren wollen.

Die vor der Freigabe des Kanals zu planenden Kontrollen lassen sich in vier Bereiche unterteilen. Authentifizierung: Der Aufrufer muss seine Identität mit systemspezifischen Anmeldedaten nachweisen, die nicht mit menschlichen Benutzern geteilt werden. Autorisierung: Nach der Identifikation des Aufrufers muss festgelegt werden, auf welche Ressourcen und Operationen er Zugriff hat, wobei das Prinzip der minimalen Rechte anstatt eines generalisierten Zugangs angewendet wird.

Schutz der Endpoints: Begrenzung der Anzahl der Aufrufe, Validierung der empfangenen Daten, kontrollierte Handhabung von Fehlermeldungen. Dies dient dazu, den Endpoint nicht in eine offene Tür oder eine Informationsquelle für Angreifer zu verwandeln. Observability: Protokollierung von Aufrufen und Ergebnissen, um Anomalien und verdächtige Versuche nachvollziehen zu können.

Die kontinuierliche Überwachung ist kein Zusatz zur Sicherheit, sondern ein Bestandteil davon. Das Verhalten der APIs muss im Zeitverlauf überwacht werden, da sich die Bedingungen durch Nutzung, Softwareentwicklung und Missbrauchsversuche ändern. Wer die Integration verwaltet, benötigt Tools, um anomale Volumina, wiederholte fehlgeschlagene Authentifizierungen, Aufrufe stillgelegter Endpoints oder zunehmende Fehlerantworten zu erkennen. Es muss eingegriffen werden, bevor das Ereignis zu einem Datenvorfall wird.

Wenn Personendaten über APIs fliessen: Der Rahmen des DSG in der Schweiz

Das Bundesgesetz über den Datenschutz gilt für die Bearbeitung von Personendaten natürlicher Personen durch Private und Bundesorgane. Für diejenigen, die Unternehmenssoftware integrieren, hat dies direkte Konsequenzen. Wenn über eine API Personendaten wie Name, Adresse, Kontaktdaten oder Informationen über Kunden oder Mitarbeitende fliessen, fällt diese Bearbeitung in den Anwendungsbereich des Gesetzes.

Die Gestaltung der Flüsse spiegelt die allgemeinen Grundsätze der Datenbearbeitung wider, die in der Praxis zu technischen Entscheidungen werden. Entscheiden, welche Felder tatsächlich übertragen werden müssen, indem vermieden wird, ganze Objekte offenzulegen, wenn nur drei Attribute benötigt werden. Festlegen, wo und wie lange die Daten beim Empfänger gespeichert werden. Definieren, wer den Endpoint aufrufen und die Antwort einsehen darf. Sicherstellen, dass das Datum über den gesamten Weg hinweg, von der Quelle bis zur Kopie, korrekt ist.

Dies sind Entscheidungen, die in der Planungsphase der Integration getroffen werden müssen und nicht nachträglich hinzugefügt werden dürfen. Bei aktiven Flüssen und Daten, die über mehrere Systeme verteilt sind, erfordert die Korrektur der Minimierung oder der Aufbewahrung Eingriffe in bereits produktive Anwendungen.

Betroffene Personen können Ansprüche gegenüber dem Verantwortlichen geltend machen. Dieser muss daher antworten können: wissen, welche Personendaten welches System verlassen, über welche Integration, an welchen Empfänger und zu welchem Zweck. Ein Inventar der über APIs laufenden Flüsse ist aus dieser Sicht primär ein Instrument zur Compliance und nicht nur zur technischen Dokumentation.

Die Aufsichtsbehörde ist der Eidgenössische Datenschutz- und Öffentlichkeitsbeauftragte (EDÖB). Mit Entscheid vom 17. April 2026, der nach Ablauf der Rekursfrist rechtskräftig wurde, hat der EDÖB die Modeunternehmen Cream della Cream und Philipp Plein im Zusammenhang mit Direktmarketing und dem Widerspruchsrecht sanktioniert.

Vom Mapping der Flüsse zur periodischen Kontrolle: So wird das Projekt aufgesetzt

Phase 1 – Mapping. Auflisten der beteiligten Systeme und für jeden geplanten Fluss Angabe des anbietenden Systems, des konsumierenden Systems, der ausgetauschten Daten, der Frequenz und des geschäftlichen Zwecks. Bereits in dieser Phase müssen Felder mit Personendaten und die im Unternehmen für diese Bearbeitung verantwortliche Person hervorgehoben werden. Das Ergebnis ist die Grundlage, auf der alle folgenden Entscheidungen, einschliesslich der Sicherheitsmassnahmen, gerechtfertigt werden.

Phase 2 – Anforderungen und Absicherung. Für jeden Fluss Format, Versionierung und Dokumentation für Entwickler definieren. Authentifizierung und Autorisierung für das aufrufende System festlegen, mit auf die notwendigen Operationen beschränkten Berechtigungen. Eine vom Produktivsystem getrennte Testumgebung vorsehen. Logs und Metriken sofort definieren: Ohne diese ist die spätere Überwachung nicht möglich.

Phase 3 – Personendaten. Prüfen, welche Personendaten übertragen werden. Minimierung anwenden, indem die ausgetauschten Felder auf das Notwendige reduziert werden. Aufbewahrungsfristen und Löschregeln in den nachgelagerten Kopien festlegen. Sicherstellen, dass auf eine Anfrage der betroffenen Person geantwortet werden kann, indem der Weg des Datums nachvollzogen wird. Wer das Projekt intern präsentiert, muss angeben können, wer der Verantwortliche ist und wer diese Abteilung zwischen IT und Compliance betreut.

Phase 4 – Betrieb und periodische Kontrolle. Nach dem Release geht die Integration in die Wartung über. Aktualisierung der Versionen und periodische Überprüfung der Liste der Flüsse und ausgetauschten Felder. Dies dient dazu, sicherzustellen, dass keine unerwarteten Daten oder Zugriffe hinzugekommen sind.

Mehr aus Prozessautomatisierung