BSI, C5 und ISO 27001 für APIs

Drei Ebenen: Methode, Nachweis, Managementsystem

Die deutsche Compliance-Landschaft für IT-Sicherheit ruht auf drei Säulen, die unterschiedliche Fragen beantworten. BSI IT-Grundschutz ist eine Methodik für ein Informationssicherheits-Managementsystem (ISMS) und liefert konkrete Bausteine mit Anforderungen. ISO/IEC 27001 ist der internationale Standard für das ISMS selbst und damit zertifizierbar. BSI C5 ist ein Kriterienkatalog speziell für Cloud-Dienste, der als prüfbarer Nachweis (Attestierung) dient.

Für APIs ist die Einordnung wichtig, weil keines dieser Regelwerke einen eigenen Paragraphen "API-Sicherheit" enthält. API-Sicherheit ergibt sich aus generischen Anforderungen an Authentifizierung, Autorisierung, Protokollierung, Schutz vor automatisiertem Missbrauch und Schutz von Daten, die in Bausteinen und Kontrollen festgeschrieben sind. Ein Prüfer fragt nicht nach einem Score, sondern danach, ob diese Anforderungen für die konkreten Schnittstellen umgesetzt und belegt sind.

Die drei Rahmen sind aufeinander bezogen: IT-Grundschutz ist nach BSI ausdrücklich kompatibel zu ISO/IEC 27001, und eine Organisation kann sich nach ISO 27001 auf Basis von IT-Grundschutz zertifizieren lassen. Die Grundlage bilden die BSI-Standards 200-1 (allgemeine ISMS-Anforderungen), 200-2 (Aufbau des ISMS) und 200-3 (Risikoanalyse).

BSI IT-Grundschutz, BSI C5 und ISO/IEC 27001 im Vergleich

BSI IT-Grundschutz: der Baustein APP.3.1 für Webanwendungen und Webservices

Das IT-Grundschutz-Kompendium gliedert Sicherheit in Bausteine. Für APIs ist der Baustein APP.3.1 Webanwendungen und Webservices zentral. Er betrachtet ausdrücklich auch Webservices, also Anwendungen, die über HTTP(S) Daten für andere Anwendungen bereitstellen und in der Regel nicht direkt von Menschen, sondern von Programmen aufgerufen werden. Der Baustein nennt REST-basierte Webservices explizit als Anwendungsbereich.

Die im Baustein beschriebene Gefährdungslage liest sich wie eine Vorstufe der OWASP API Top 10. Genannt werden unter anderem unzureichende Protokollierung sicherheitsrelevanter Ereignisse, Offenlegung sicherheitsrelevanter Informationen (etwa Framework-Versionen in Antworten), Missbrauch durch automatisierte Nutzung (Brute Force gegen Logins, Enumeration gültiger Benutzernamen, Denial of Service auf Anwendungsebene durch ressourcenintensive Aufrufe) und unzureichende Authentifizierung.

Die Anforderungen sind konkret und API-relevant:

• APP.3.1.A1 Authentisierung: Zugriff auf geschützte Ressourcen nur nach Authentifizierung, mit definierten Schwellwerten für fehlgeschlagene Anmeldeversuche.
• APP.3.1.A7 Schutz vor unbefugter automatisierter Nutzung: Maßnahmen gegen automatisierten Missbrauch, mit Ausnahme explizit für Automatisierung vorgesehener Funktionen.
• APP.3.1.A14 Schutz vertraulicher Daten: serverseitiger Schutz von Zugangsdaten mit gesalzenen Hash-Verfahren.
• APP.3.1.A9 Beschaffung: sichere Eingabevalidierung und Ausgabekodierung, sicheres Session-Management, ausreichende Protokollierung und angemessenes Zugriffsmanagement.

Verantwortlich für die Erfüllung ist laut Baustein der oder die Informationssicherheitsbeauftragte (CISO). Der Baustein deckt den Betrieb ab; Entwicklung gehört in CON.10, Webserver in APP.3.2.

BSI TR-03161: Sicherheitsanforderungen für Anwendungen im Gesundheitswesen

Die Technische Richtlinie BSI TR-03161 richtet sich an Hersteller von Anwendungen im Gesundheitswesen und ist die Grundlage für die Prüfung digitaler Gesundheitsanwendungen. Sie kann laut BSI darüber hinaus als Leitlinie für jede Anwendung dienen, die sensible Daten verarbeitet oder speichert.

Die Richtlinie ist in drei Teile gegliedert, die zusammen den typischen Aufbau einer API-gestützten Anwendung abdecken:

• Teil 1: Mobile Anwendungen (der Client).
• Teil 2: Web-Anwendungen.
• Teil 3: Hintergrundsysteme, also die Backend-Dienste und damit die APIs, über die mobile Apps und Web-Frontends ihre Daten beziehen.

Die Anforderungen sind entlang der Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit formuliert und behandeln Themen wie sichere Kommunikation, Authentifizierung, Datenspeicherung und Schnittstellensicherheit. Für Anbieter im Gesundheitssektor ist TR-03161 damit der konkreteste deutsche Maßstab dafür, was eine API zwischen App und Backend an Sicherheit leisten muss.

BSI C5 als Nachweis und ISO/IEC 27001 als Managementsystem

Der Cloud Computing Compliance Criteria Catalogue (C5) wurde vom BSI erstmals 2016 veröffentlicht und legt ein Mindestniveau an Sicherheit für Cloud-Dienste fest. Wer eine API als Cloud-Dienst anbietet oder bezieht, trifft auf C5 als Nachweisinstrument. Der Mechanismus: Der Anbieter lässt die Erfüllung der C5-Kriterien durch unabhängige Wirtschaftsprüfer nach anerkannten internationalen Prüfungsstandards (Typ ISAE 3000) attestieren. Das Ergebnis ist ein detaillierter Prüfbericht mit Systembeschreibung, der jährlich erneuert wird. Das BSI selbst prüft die Berichte nicht; der Kunde wertet sie im Rahmen seiner eigenen Risikoanalyse aus. C5 macht damit die Aufteilung sicherheitskritischer Aufgaben zwischen Anbieter und Kunde transparent. Aktuell sind die Fassungen C5:2020 und das überarbeitete C5:2026 relevant.

ISO/IEC 27001 in der Fassung von 2022 spezifiziert die Anforderungen an Aufbau, Betrieb und kontinuierliche Verbesserung eines ISMS und ist durch akkreditierte Stellen zertifizierbar. Die zugehörigen Kontrollen aus Annex A werden in ISO/IEC 27002:2022 beschrieben und in vier Themen gegliedert: organisatorische, personenbezogene, physische und technologische Maßnahmen. API-relevant sind vor allem die technologischen Kontrollen, etwa zu sicherer Authentifizierung, Zugriffssteuerung, sicherer Entwicklung, Protokollierung und Netzwerksicherheit. ISO 27001 verlangt keinen API-spezifischen Nachweis, sondern dass die anwendbaren Kontrollen risikobasiert ausgewählt, umgesetzt und ihre Wirksamkeit regelmäßig überprüft werden.

Verhältnis zu DORA, NIS2 und DSGVO

Die deutschen Rahmen stehen nicht neben den europäischen Regulierungen, sondern liefern den Umsetzungs- und Nachweispfad für sie. DSGVO Art. 32, NIS2 und DORA verlangen jeweils dem Risiko angemessene, dem Stand der Technik entsprechende Maßnahmen, ohne eine konkrete Kontrollliste vorzugeben. Genau diese Konkretisierung leisten IT-Grundschutz, ISO 27001 und C5.

• Ein ISO-27001-Zertifikat oder ein nachgewiesenes IT-Grundschutz-ISMS ist ein anerkannter Beleg dafür, dass die nach DSGVO Art. 32 und NIS2 geforderten organisatorischen und technischen Maßnahmen systematisch betrieben werden.
• Ein C5-Prüfbericht dient als Nachweis bei der Auswahl und Steuerung von Cloud-Dienstleistern und unterstützt damit die nach DORA und NIS2 geforderte Kontrolle von Drittparteien und IKT-Lieferketten.
• Die Bausteine und Kontrollen (etwa APP.3.1 oder die technologischen ISO-Kontrollen) liefern die prüfbaren Einzelmaßnahmen, die ein Audit zu konkreten Endpunkten sehen will.

Entscheidend bleibt für alle Rahmen dasselbe Prinzip wie bei DORA, NIS2 und DSGVO: nicht ein Zertifikat oder ein Score zählt, sondern der belegbare Bezug zwischen geforderter Maßnahme, getestetem Endpunkt und dokumentiertem Ergebnis. Ein Befund je API mit nachvollziehbarem Protokoll, das die Prüfung, das Ergebnis und den Umgang damit festhält, ist genau die Evidenz, die ein ISMS-Audit oder eine C5-Attestierung verlangt.

Quellen

• IT-Grundschutz: A systematic basis for information security BSI, 2022
• IT-Grundschutz-Compendium, Edition 2022, Baustein APP.3.1 Web Applications and Web Services BSI, 2022
• BSI TR-03161 Anforderungen an Anwendungen im Gesundheitswesen BSI, 2024
• C5 criteria catalogue (Cloud Computing Compliance Criteria Catalogue) BSI, 2026
• ISO/IEC 27001 Information security management systems - Requirements ISO/IEC, 2022
• ISO/IEC 27002:2022 Information security controls ISO/IEC, 2022
• Art. 32 DSGVO: Sicherheit der Verarbeitung gdpr-info.eu, 2016