Cybersecurity-Wissen · Redaktion 360digital ·
API-Sicherheit: Was Schweizer KMU vor dem Go-live prüfen sollten
APIs verbinden Portale, mobile Apps, ERP, Partner und Automatisierungen. Eine Anmeldung allein schützt diese Verbindungen nicht: Jede Funktion muss prüfen, wer auf welches Objekt in welchem Kontext zugreifen darf. API-Sicherheit ist deshalb eine Mischung aus sauberem Design, zentralen Kontrollen und beobachtbarem Betrieb.
Inventar und Vertrauensgrenzen
Beginnen Sie mit einem API-Inventar: öffentliche und interne Endpunkte, Versionen, Besitzer, Datenklassen, verwendete Identitäten und abhängige Systeme. Alte Versionen bleiben oft erreichbar, obwohl die Dokumentation sie nicht mehr erwähnt. Markieren Sie administrative, finanzielle und personenbezogene Funktionen. Ein Gateway kann Regeln vereinheitlichen, ersetzt aber keine Autorisierung im Dienst selbst.
Trennen Sie Authentisierung und Autorisierung. Ein gültiges Token beweist eine Identität oder einen Dienst, aber nicht den Zugriff auf jedes Objekt. Die Anwendung muss Mandant, Rolle, Objektbesitzer und Geschäftsstatus prüfen. Fehlermeldungen sollen keine unnötigen Daten verraten; Logs müssen Korrelation erlauben, ohne Geheimnisse oder vollständige Tokens zu speichern.
- Jeder Endpunkt hat Besitzer, Datenklasse, Version und Abschaltplan.
- Objekt- und Funktionsberechtigungen mit positiven und negativen Testfällen prüfen.
- Ausgaben auf notwendige Felder begrenzen; interne IDs und Geheimnisse nicht ausgeben.
Missbrauch kontrollieren
Prüfen Sie Eingaben auf Format, Länge, Typ und erlaubte Werte. Serialisierung, Abfragen und Dateiverarbeitung müssen sichere Bibliotheken und klare Grenzen verwenden. Rate-Limits sollten zur Funktion passen: Ein Suchendpunkt braucht andere Grenzen als eine Überweisung oder eine Passwortänderung. Wiederholungen, Zeitüberschreitungen und Teilfehler brauchen definierte Zustände, damit keine doppelte Buchung entsteht.
Sicherheitskontrollen gehören in automatisierte Tests und in die Bereitstellungspipeline. Vertrags- und Schema-Tests entdecken unbeabsichtigte Änderungen; Berechtigungstests prüfen, dass ein Nutzer fremde Objekte nicht lesen oder verändern kann. Abhängigkeiten, Schlüssel und Zertifikate werden inventarisiert und regelmässig erneuert. Drittanbieterzugänge erhalten minimale Rechte und einen klaren Ablauf.
Für die Praxis lohnt eine kleine Matrix mit Endpunkt, Rolle, erlaubter Aktion, Datenklasse und erwarteter Protokollzeile. Sie macht Lücken sichtbar, bevor ein externer Test beginnt. Prüfen Sie auch negative Fälle: fehlende Anmeldung, abgelaufene Sitzung, falscher Mandant, zu grosse Abfrage und wiederholte Anfrage. Jede Ausnahme braucht einen Besitzer und ein Ablaufdatum. Die Matrix kann bei jedem Release als kurzer Review dienen und ist für Fachpersonen verständlicher als eine lange technische Dokumentation.
Beispiel und Entscheidungsrahmen
Hypothetisches Beispiel: Eine Handelsfirma verbindet ihr Kundenportal mit dem ERP. Ein Kunde ruft eine Bestellnummer auf, die im eigenen Mandanten nicht existiert. Die API darf dabei keinen fremden Datensatz anhand einer erratenen Kennung liefern. Ein Test mit zwei künstlichen Mandanten, drei Rollen und abgelaufenen Sitzungen zeigt, ob die Regel auf den geprüften Routen gilt. Der Befund wird behoben und in der Pipeline als Regressionstest verankert.
Vor dem Go-live sollten Sie Inventar, Rollenmodell, Negativtests, Rate-Limits, Protokollierung und einen Rückfallweg nachweisen können. Ein Pentest ergänzt diese Entwicklungssicherheit, ersetzt aber kein dauerhaftes Eigentum. Bei jeder neuen Version, Integration oder Berechtigungsänderung muss die Risikobewertung erneut geprüft werden. Verantwortlich ist eine benannte Person, die Änderungen an der API verfolgen kann; ohne diese Zuständigkeit veraltet selbst ein guter Prüfbericht schnell. Kleine, regelmässige Kontrollen sind für den Betrieb oft wertvoller als ein einmaliger Test ohne Nachverfolgung. Legen Sie ausserdem fest, welche API-Versionen abgeschaltet werden und wie Partner diese Änderung erfahren. Ein ungenutzter, aber erreichbarer Endpunkt bleibt ein offener Prüfpunkt.
Häufige Fragen
Reicht ein API-Gateway?
Nein. Es kann Authentisierung, Limits und Protokollierung unterstützen. Objekt- und Geschäftsberechtigungen müssen die jeweilige Anwendung durchsetzen.
Sind interne APIs automatisch vertrauenswürdig?
Nein. Interne Netze, Cloud-Dienste und Servicekonten können kompromittiert oder falsch konfiguriert werden. Jede Grenze braucht passende Identität und Autorisierung.
Was soll ins Monitoring?
Fehlgeschlagene Authentisierung, Berechtigungsfehler, ungewöhnliche Mengen, Versionen, privilegierte Aktionen und Korrelationen zu Deployments, ohne Geheimnisse zu protokollieren.
Von der Orientierung zur konkreten Prüfung
Webanwendungen und APIs gezielt prüfen: Anmeldung, Rollen, Mandantentrennung und Geschäftslogik. Klarer Prüfumfang und nachvollziehbare Befunde.
Webapp & API Pentest: Leistung ansehen ↗Quellen und fachliche Orientierung
Die verlinkten Fachquellen erläutern die zugrunde liegenden Konzepte. Checklisten und Planungsbeispiele sind redaktionelle Orientierung für KMU; sie ersetzen keinen auf Ihre Umgebung abgestimmten Prüfauftrag.