REST API: Architektur, Zugriffskontrolle und Nachweise bei Systemschnittstellen

Eine REST API ist eine HTTP-basierte Schnittstelle nach dem Architekturstil Representational State Transfer, bei der jede fachliche Einheit als Ressource mit eigener Adresse (URI) erscheint und ausschliesslich über standardisierte Methoden gelesen oder verändert wird.

Aus Governance-Sicht ist das mehr als ein technisches Detail. Jede Anfrage ist in sich vollständig und legt Methode, Ressource und Berechtigung offen. Damit lässt sich jeder Zugriff einzeln prüfen, protokollieren und einer Anwendung zuordnen. Zugleich ist eine REST API ein direkter Weg zu Personen- und Geschäftsdaten. Gerade in Banken, Versicherungen, Spitälern und Verwaltungen empfiehlt es sich deshalb, Schnittstellen wie jeden anderen privilegierten Zugang zu führen: mit Verantwortlichen, Freigaben und Nachweisen. Den Grundbegriff Programmierschnittstelle erklärt der Glossarartikel API.

Die Kernpunkte

• Prüfbar: Methode, Ressource und Identität des Aufrufers stehen in jeder Anfrage. Der Server hält keinen Sitzungszustand.
• Vorhersehbar: GET, PUT und DELETE sind nach RFC 9110 idempotent, POST und PATCH nicht. Davon hängt ab, welche Wiederholungen unbedenklich sind.
• Zugriff: API-Schlüssel identifizieren eine Anwendung, OAuth 2.0 vergibt zeitlich und inhaltlich begrenzte Berechtigungen.
• Hauptrisiko: fehlende Berechtigungsprüfung je Objekt (OWASP API1:2023).
• Rechtsbezug Schweiz: Datensicherheit nach Art. 8 DSG, in bestimmten Fällen Protokollierung nach Art. 4 DSV, für Banken zusätzlich das FINMA-Rundschreiben 2023/1.

Stand: November 2026 · Abgeglichen mit der Dissertation von Roy T. Fielding, RFC 9110, RFC 6749 und RFC 9700, der OWASP API Security Top 10 2023, DSG und DSV auf Fedlex sowie dem FINMA-Rundschreiben 2023/1 (Quellen am Ende)

Architekturprinzipien und ihre Kontrollwirkung

Roy T. Fielding hat REST im Jahr 2000 in seiner Dissertation an der University of California, Irvine, als Satz von Randbedingungen beschrieben. Jede davon hat Folgen für Sicherheit und Nachvollziehbarkeit:

• Client-Server: Wer die Daten hält, entscheidet über den Zugriff. Prüfungen gehören auf den Server, eine Einschränkung nur in der Oberfläche des Clients schützt nichts.
• Zustandslosigkeit: Jede Anfrage bringt ihre Berechtigung selbst mit und lässt sich einzeln autorisieren und protokollieren. Die Kehrseite: Ein entwendetes Token wirkt bis zu seinem Ablauf. Kurze Laufzeiten begrenzen den Schaden.
• Cache: Antworten legen fest, ob Zwischenspeicher sie aufbewahren dürfen. Für Personendaten verhindert Cache-Control: no-store, dass Kopien in Proxys liegen bleiben (RFC 9111).
• Einheitliche Schnittstelle: Ressourcen, Repräsentationen, selbstbeschreibende Nachrichten und Hypermedia-Links. Gleichförmige Muster erleichtern Prüfungen, weil sich Regeln je Methode und Ressource formulieren lassen.
• Schichtenarchitektur: API-Gateways und Web Application Firewalls können zentral authentisieren, Raten begrenzen und protokollieren, ohne dass die Fachanwendung angepasst werden muss.
• Code on Demand: optional und für Schnittstellen zwischen Systemen ohne Bedeutung.

Ressourcen bewusst schneiden

Was als Ressource erscheint, bestimmt auch, was geschützt werden muss. Eine Adresse wie /kunden/1043/vertraege legt offen, dass Verträge einem Kunden zugeordnet sind. Die Prüfung muss dann bei jedem Aufruf sicherstellen, dass der Aufrufer genau diesen Kunden sehen darf. Datenminimierung beginnt beim Zuschnitt: Felder, die eine Anwendung nicht braucht, liefert die Schnittstelle gar nicht erst aus, statt sie im Client auszublenden.

Als Repräsentation dient meist JSON. RFC 8259 schreibt für den Austausch zwischen offenen Systemen die Kodierung UTF-8 vor. Ob eine Schnittstelle im strengen Sinn «RESTful» ist, hängt nach Fielding auch an Hypermedia-Links, auf die viele Implementierungen verzichten. Für die Governance zählt weniger das Etikett als eine dokumentierte und gleichförmige Umsetzung.

Methoden und Statuscodes als Prüfgrundlage

Ob eine Methode nur liest oder Daten verändert und ob sie sich gefahrlos wiederholen lässt, legt RFC 9110 fest. Diese Eigenschaften bestimmen, welche Kontrollen je Methode nötig sind.

Bei den Statuscodes ist die saubere Trennung von 401 (nicht authentisiert) und 403 (authentisiert, aber nicht berechtigt) für Prüfungen wertvoll. Häufen sich 403-Antworten für dasselbe technische Konto, deutet das auf eine Fehlkonfiguration oder auf Versuche, fremde Objekte abzurufen. 429 zeigt an, dass ein Ratenlimit greift. Fehlerantworten im Format Problem Details nach RFC 9457 sind einheitlich und maschinenlesbar. Interne Angaben wie Stacktraces oder Datenbankmeldungen gehören ins Protokoll, nicht in die Antwort.

Einordnung von SOAP und GraphQL

SOAP, ein vom W3C spezifiziertes XML-Format, kennt mit WS-Security ein Sicherheitsmodell auf Ebene der einzelnen Nachricht und findet sich noch in vielen älteren Banken- und Behördenschnittstellen. GraphQL bündelt Abfragen an einem Endpunkt. Berechtigungen müssen dort je Objekt und oft je Feld geprüft werden, was die Kontrolle anspruchsvoller macht. Einen Überblick über Schnittstellenarten gibt der Glossarartikel API, die ereignisgesteuerte Gegenrichtung der Artikel Webhook.

Von der Spezifikation bis zur Abschaltung

Angenommen, ein Versicherer in Bern möchte, dass sein Kundenportal bei technischen Störungen selbst ein Ticket im ITSM-Werkzeug eröffnet. Die Schnittstelle durchläuft sechs Schritte, jeder mit einem eigenen Nachweis:

1. Spezifikation: Eine OpenAPI-Beschreibung legt Ressourcen, Felder, Fehlercodes und benötigte Berechtigungen fest. Jedes Feld erhält eine Datenklassifizierung.
2. Freigabe: Die neue Schnittstelle läuft als Change mit Risikobeurteilung und Vier-Augen-Prinzip. Im Inventar stehen Eigentümer, technisches Konto, Scopes, Datenkategorien und Ablaufdatum des Geheimnisses.
3. Umsetzung mit Idempotenz: Das Portal sendet einen Schlüssel mit, damit eine Wiederholung nach einer Zeitüberschreitung kein zweites Ticket erzeugt (Beispiel unten).
4. Betrieb und Protokollierung: Erfasst werden technisches Konto, Methode, Ressource, Zeitpunkt, Statuscode und eine Korrelations-ID.
5. Änderungen und Versionen: Inkompatible Änderungen erscheinen nur als neue Hauptversion, alte Versionen laufen parallel und werden mit Frist abgekündigt. Auch das ist ein Change.
6. Rezertifizierung und Abschaltung: Regelmässig wird geprüft, ob Konto und Berechtigungen noch nötig sind. Nicht mehr genutzte Versionen werden abgeschaltet.

So kann die Anfrage aus Schritt 3 aussehen. Pfade und Felder sind frei gewählt und gehören zu keinem bestimmten Produkt:

POST /api/v1/tickets HTTP/1.1
Host: itsm.example.com
Authorization: Bearer <Token>
Idempotency-Key: 5d2e8b40-…
Content-Type: application/json

{ "titel": "Portal: Zeitüberschreitung",
  "kategorie": "incident",
  "quelle": "kundenportal" }

Der Server bestätigt mit 201 Created und nennt im Header Location die neue Adresse, etwa /api/v1/tickets/20931. Sendet das Portal dieselbe Anfrage mit demselben Schlüssel erneut, liefert ein Server mit Unterstützung für Idempotenz das ursprüngliche Ergebnis. Der Header ist bei der IETF als Internet-Draft in Arbeit und noch kein verabschiedeter Standard.

Rechtlicher Rahmen in der Schweiz

• Art. 8 DSG verlangt eine dem Risiko angemessene Datensicherheit durch technische und organisatorische Massnahmen.
• Art. 4 DSV: Werden besonders schützenswerte Personendaten in grossem Umfang automatisiert bearbeitet oder findet ein Profiling mit hohem Risiko statt, und genügen präventive Massnahmen nicht, sind mindestens Speichern, Verändern, Lesen, Bekanntgeben, Löschen und Vernichten zu protokollieren. Das Protokoll muss die Identität der bearbeitenden Person zeigen und ist mindestens ein Jahr getrennt aufzubewahren.
• FINMA-Rundschreiben 2023/1: Banken müssen für das Änderungsmanagement Verfahren und Kontrollen festlegen, ein Inventar der IKT führen, das auch Schnittstellen zu wesentlichen externen Dienstleistern berücksichtigt, und den Zugriff auf kritische Daten über ein Autorisierungssystem regeln und regelmässig überprüfen.

ky2help^® unterstützt diese Nachweise mit automatischer Historisierung und integriertem Daten-Audit. Das Personalamt des Kantons Thurgau nutzt ky2help®, um HR-Prozesse lückenlos nachvollziehbar zu dokumentieren und zu archivieren. Wie neue Schnittstellen als Change geführt werden, zeigt die Seite zum Change Management.

Change Management ansehen

Risiken nach Priorität

Die OWASP API Security Top 10 2023 ordnen die häufigsten Schwachstellen. Für Schnittstellen auf Personen- und Geschäftsdaten ergibt sich daraus diese Reihenfolge:

1. Fehlende Prüfung je Objekt (API1): Ein Aufrufer ersetzt /tickets/20931 durch /tickets/20932 und sieht fremde Daten. Massnahme: serverseitige Prüfung bei jedem Zugriff und Tests mit zwei getrennten Konten.
2. Schwache Authentisierung (API2): langlebige, geteilte API-Schlüssel ohne Ablauf oder Schlüssel in URLs. Massnahme: OAuth 2.0 mit kurzlebigen Tokens und engen Scopes. RFC 9700 empfiehlt zusätzlich, Tokens an den Client zu binden, etwa per Mutual TLS oder DPoP, damit ein abgegriffenes Token allein nicht genügt.
3. Zu viele Felder in Antworten (API3): Die Schnittstelle liefert mehr Attribute als nötig, etwa Geburtsdaten in einer Ticketliste. Massnahme: Feldauswahl auf dem Server, abgestimmt auf die Datenklassifizierung.
4. Unbegrenzter Ressourcenverbrauch (API4): Abfragen ohne Obergrenze legen den Dienst lahm. Massnahme: Ratenlimits mit 429, Paginierung mit fester maximaler Seitengrösse, Zeitlimits.
5. Fehlendes Inventar (API9): vergessene Testumgebungen und alte Versionen ohne aktuelle Kontrollen. Massnahme: vollständiges Schnittstelleninventar und Abschaltung nach Frist.

Betreiber kritischer Infrastrukturen müssen dem Bundesamt für Cybersicherheit (BACS) seit dem 1. April 2025 Cyberangriffe innert 24 Stunden nach der Entdeckung melden, unter anderem wenn ein Angriff die Funktionsfähigkeit gefährdet oder zu einer Manipulation oder einem Abfluss von Informationen geführt hat. Ein Datenabfluss über eine Schnittstelle kann darunter fallen. Wer Prüfungen oder Härtung extern begleiten lassen möchte, findet Angebote bei unseren Cybersecurity Services.

Fragen und Antworten

Was versteht man unter einer REST API?

Eine REST API ist eine HTTP-Schnittstelle, bei der Daten als Ressourcen mit eigener Adresse erscheinen und über Standardmethoden wie GET, POST, PUT, PATCH und DELETE gelesen oder verändert werden. Jede Anfrage ist in sich vollständig und trägt ihre Berechtigung selbst.

Warum ist Idempotenz für die Nachvollziehbarkeit wichtig?

Bricht eine Verbindung ab, wiederholen Clients ihre Anfragen. Bei idempotenten Methoden wie PUT oder DELETE bleibt das Ergebnis gleich. Ein wiederholtes POST kann dagegen doppelte Datensätze erzeugen, die sich später kaum noch eindeutig zuordnen lassen. Ein Idempotenzschlüssel verhindert das.

Reicht ein API-Schlüssel als Schutz?

Für wenig sensible Daten kann ein API-Schlüssel genügen, wenn er nur im Header übertragen, sicher verwahrt und regelmässig getauscht wird. Für Personen- und Geschäftsdaten sind OAuth 2.0 mit kurzlebigen Tokens und engen Scopes sowie eine Prüfung jedes Objektzugriffs angemessener.

Wie begrenzt man, wie viele Daten eine REST API ausliefert?

Mit Paginierung und einer festen maximalen Seitengrösse, mit einer Feldauswahl auf dem Server, die sich an der Datenklassifizierung orientiert, und mit Ratenlimits, die bei Überschreitung den Statuscode 429 liefern. Das senkt das Risiko von Datenabflüssen und schützt die Verfügbarkeit.

Wie versioniert man eine REST API kontrolliert?

Inkompatible Änderungen erhalten eine neue Hauptversion, etwa im Pfad als /v2/. Die alte Version läuft eine angekündigte Zeit parallel und wird danach abgeschaltet. Jede neue Version läuft als Change mit Freigabe und wird im Schnittstelleninventar geführt.

Hält ky2help® Änderungen nachvollziehbar fest?

Ja. ky2help® historisiert Änderungen automatisch, verfügt über ein integriertes Daten-Audit und arbeitet revisionssicher. Drittsysteme werden über eine REST-API für Webservices und über Standardschnittstellen angebunden. Betrieben wird ky2help® als SaaS mit eigener Instanz in einem Schweizer Rechenzentrum oder On-Premises.

Quellen und vertiefende Artikel

Quellen

• Roy T. Fielding: Representational State Transfer (REST), Dissertation Kapitel 5
• IETF: RFC 9110 – HTTP Semantics und RFC 9111 – HTTP Caching
• IETF: RFC 8259 – JSON und RFC 9457 – Problem Details
• IETF: RFC 6749 – OAuth 2.0 und RFC 9700 – OAuth 2.0 Security Best Current Practice
• IETF: Internet-Draft zum Header Idempotency-Key
• OWASP: API Security Top 10 2023
• Fedlex: Bundesgesetz über den Datenschutz (DSG) und Datenschutzverordnung (DSV)
• FINMA: Rundschreiben 2023/1 «Operationelle Risiken und Resilienz – Banken»
• BACS: Meldepflicht für Cyberangriffe

Vertiefen im Glossar und auf kyberna.ch

• API und Webhook
• Authentifizierung und ISO 27001
• ITIL Change Management
• ky2help® für die Finanzbranche
• Cloud oder On-Premises