Sichern Sie eine API für regulierte Daten ab, indem Sie modellieren, wer sie missbrauchen könnte, die Autorisierung für jedes Objekt und jedes Feld prüfen, so wenig Daten wie möglich erheben und zurückgeben und Secrets sowie Audit-Logs unter strikter Kontrolle halten. Die Schwachstellen, die in der Praxis am meisten zählen, sind Lücken in der Autorisierung und Antworten, die zu viele Daten preisgeben, nicht geknackte Verschlüsselung.
Beginnen Sie mit einem Bedrohungsmodell für die Daten, nicht für das Framework
Bevor Sie Tools auswählen, halten Sie fest, was die API preisgibt und wer sie missbrauchen könnte. Bei einer Bank sind das Konto- und Transaktionsdaten; bei einem Energie- oder Versorgungsunternehmen können es Zählerdaten, Kundenverträge und Betriebsmesswerte aus dem Netz sein.
Ein nützliches Bedrohungsmodell ist kurz. Es listet die sensiblen Daten auf, jeden Aufrufer, der sie erreichen kann, die Aktionen, die jeder Aufrufer ausführen können soll, und was passiert, wenn einer davon kompromittiert wird. Dieses Dokument steuert dann jede der folgenden Kontrollen und sagt den Prüfern, was sie testen müssen.
- Welche Daten personenbezogen, vertraulich oder reguliert sind und wo sie gespeichert werden.
- Jeder Nutzer der API: interne Dienste, Partner, mobile Apps und Administratoren.
- Was jeder Nutzer lesen, ändern oder auslösen darf.
- Die Folgen eines geleakten Tokens, eines böswilligen Insiders oder eines kompromittierten Partnersystems.
Authentifizieren Sie jeden Aufrufer, dann autorisieren Sie jedes Objekt
Nutzen Sie ein Standardprotokoll wie OAuth 2.0 mit OpenID Connect für Nutzer und kurzlebige Tokens oder mutual TLS für Aufrufe zwischen Diensten. Vermeiden Sie langlebige, gemeinsam genutzte API-Schlüssel, denn niemand kann sagen, welches System sie verwendet hat, oder sie widerrufen, ohne andere Systeme lahmzulegen.
Authentifizierung beweist nur, wer aufruft. Der erste Eintrag der OWASP API Security Top 10 ist Broken Object Level Authorization: Ein gültiger Nutzer ändert eine Kennung in der Anfrage und liest den Datensatz eines anderen. Prüfen Sie auf dem Server für jedes Objekt, jede Funktion und jedes sensible Feld die Eigentümerschaft oder Mandantenzugehörigkeit, und vertrauen Sie nie einer Kennung oder Rolle, die der Client schickt.
Geben Sie jedem Client und Dienst nur die minimal nötigen Rechte
Minimale Rechte begrenzen den Schaden, wenn doch etwas schiefgeht. Vergeben Sie getrennte Zugangsdaten pro Nutzer der API, beschränken Sie Tokens auf bestimmte Operationen und legen Sie administrative Endpoints auf einen separaten Pfad mit strengeren Prüfungen.
Wenden Sie dieselbe Regel unterhalb der API an. Das Dienstkonto, das Zählerdaten liest, sollte sie nicht löschen können, und ein Reporting-Job sollte sich mit einer Datenbankrolle mit reinen Leserechten verbinden. Überprüfen Sie Berechtigungen regelmäßig, denn Zugriffe, die für eine einmalige Aufgabe vergeben wurden, bleiben gern für immer.
Erheben Sie weniger, geben Sie weniger zurück und speichern Sie kürzer
Datenminimierung ist sowohl ein Grundsatz der DSGVO als auch eine wirksame Sicherheitskontrolle: Daten, die Sie nie speichern, können nicht abfließen. Fragen Sie bei jedem Feld, ob der Dienst es wirklich braucht, und verwerfen oder pseudonymisieren Sie, was er nicht braucht.
Wenden Sie dieselbe Disziplin auf Antworten an. Definieren Sie explizite Antwortschemata, statt ganze Datenbankobjekte zu serialisieren, maskieren Sie Kennungen wie Kontonummern, wo der vollständige Wert nicht nötig ist, und legen Sie Aufbewahrungsfristen fest, damit alte Datensätze gelöscht werden. Dokumentieren Sie die Rechtsgrundlage für jeden Verarbeitungszweck und schließen Sie Auftragsverarbeitungsverträge mit jedem Dienstleister, der die Daten verarbeitet. Das ist Engineering-Praxis, keine Rechtsberatung: Ziehen Sie für die rechtliche Bewertung Ihren Datenschutzbeauftragten oder Ihre Rechtsberatung hinzu.
Validieren Sie jede Eingabe und begrenzen Sie, was ein Aufrufer verbrauchen kann
Behandeln Sie jede Anfrage als feindlich, bis sie validiert ist. Erzwingen Sie für jeden Endpoint ein Schema, weisen Sie unbekannte Felder zurück und verwenden Sie parametrisierte Abfragen, damit Eingaben nie Teil eines Datenbankbefehls werden.
Mehrere API-Risiken aus der OWASP-Liste entstehen durch fehlende Grenzen statt durch schlechten Code. Begrenzen Sie die Anfragerate pro Client, deckeln Sie Seiten- und Payload-Größen und schützen Sie sensible Geschäftsabläufe wie Zahlungen oder Vertragsänderungen vor automatisiertem Missbrauch. Ruft die API im Auftrag von Aufrufern entfernte URLs ab, beschränken Sie die Ziele, um Server-Side Request Forgery zu verhindern.
Halten Sie Secrets aus Code, Images und Logs heraus
Datenbankpasswörter, Signaturschlüssel und Zugangsdaten von Partnern gehören in einen eigenen Secrets-Manager, werden zur Laufzeit eingespielt und regelmäßig rotiert. Durchsuchen Sie Repositories und Container-Images in der Build-Pipeline nach Secrets und behandeln Sie jedes Secret, das in die Versionskontrolle gelangt, als kompromittiert.
Trennen Sie Secrets nach Umgebung, damit geleakte Test-Zugangsdaten nie die Produktion öffnen. Beschränken Sie, wer Secrets in der Produktion lesen darf, und protokollieren Sie jeden Zugriff darauf.
Protokollieren Sie für das Audit und gestalten Sie für weniger Vorfälle
Regulierte Umgebungen müssen im Nachhinein eine einfache Frage beantworten können: Wer hat wann über welchen Client auf welche Daten zugegriffen? Erfassen Sie das für jeden sensiblen Lese- und Schreibzugriff, speichern Sie Logs dort, wo die Betreiber der Anwendung sie nicht ändern können, und halten Sie personenbezogene Daten aus Log-Meldungen heraus.
Kombinieren Sie das Logging mit Alarmen bei ungewöhnlichen Mustern, etwa wenn ein Client weit mehr Datensätze liest als üblich, und mit einem getesteten Plan für die Reaktion auf Vorfälle. Über Sopra Steria haben unsere Entwickler sichere APIs für sensible Versorgerdaten unter regulatorischen Vorgaben gebaut und ein Tool zur operativen Überwachung verantwortet, bei dem durchgesetzte Sicherheitsstandards mit weniger Produktionsvorfällen einhergingen. SDK Enterprises wendet dieselben Praktiken heute in Kundenprojekten an.
Das Wichtigste in Kürze
- Ein kurzes, schriftliches Bedrohungsmodell für die Daten sollte jede Sicherheitskontrolle der API steuern.
- Prüfen Sie die Autorisierung auf dem Server für jedes Objekt, jede Funktion und jedes sensible Feld, nicht nur bei der Anmeldung.
- Minimale Rechte gelten für Tokens, Dienstkonten und Datenbankrollen gleichermaßen.
- Datenminimierung verringert sowohl das DSGVO-Risiko als auch die Folgen jedes Datenlecks.
- Audit-Logs müssen zeigen, wer wann auf was zugegriffen hat, ohne selbst personenbezogene Daten preiszugeben.
FAQ
Reicht HTTPS, um eine API abzusichern?
Nein. TLS schützt Daten bei der Übertragung, aber bei vielen API-Sicherheitsvorfällen gelangen authentifizierte Aufrufer an Daten, die sie nicht sehen sollten. Autorisierungsprüfungen, Eingabevalidierung, Rate Limits und Audit-Logging bleiben notwendig.
Was ist Broken Object Level Authorization?
Eine Schwachstelle, bei der die API prüft, ob ein Aufrufer angemeldet ist, aber nicht, ob der angeforderte Datensatz ihm gehört. Ändert man dann eine Kennung in der URL oder im Anfragetext, werden Daten anderer Nutzer sichtbar. Die Lösung ist eine Prüfung von Eigentümerschaft oder Mandantenzugehörigkeit auf dem Server für jedes Objekt.
Schreibt die DSGVO bestimmte Sicherheitskontrollen für APIs vor?
Die DSGVO verlangt geeignete technische und organisatorische Maßnahmen, die dem jeweiligen Risiko angemessen sind, ohne bestimmte Tools vorzuschreiben. Kontrollen wie Zugriffsbeschränkung, Minimierung, Pseudonymisierung und Protokollierung sind gängige Wege, diese Anforderung zu erfüllen, und Ihre Rechtsberatung sollte bestätigen, was in Ihrem Fall gilt.