Vor mehr als zwei Jahrzehnten erklärte Jeff Bezos, dass alle Amazon-Teams „ihre Daten und Funktionen über Service-Schnittstellen offenlegen müssen“ – ohne Ausnahme. Das Memo (jetzt bekannt als das „API Mandate“ bzw. „API-Gebot“) erklärte im Wesentlichen, dass App-Programmierschnittstellen (API) kein Nice-to-Have sondern ein absolutes Muss sind – und es löste einen Wettlauf unter Entwicklern aus, alles via APIs zu verknüpfen. Für viele Unternehmen hinkt die API-Sicherheit jedoch hinter dem rasanten Tempo der API-Bereitstellung hinterher.
Laut dem kürzlich erschienenen Bericht zu API-Sicherheit und -Verwaltung 2024 macht der API-bezogene Datenverkehr mittlerweile den Großteil (ca. 57 %) des gesamten dynamischen Internet-Traffics aus. Unternehmen haben jedoch häufig mit Problemen zu kämpfen, darunter etwa folgende:
Unsichtbare, ungeschützte Angriffsfläche: IT und Sicherheit können nicht verteidigen, was sie nicht sehen – und Organisationen haben „Schatten-APIs“ – APIs, die ihre IT- oder Sicherheitsteams nicht verwalten. Dies führt zur Offenlegung von Daten, lateraler Bewegung und anderen Cyberrisiken.
Allzu großzügige Zugriffsrechte: In den falschen Händen macht ein Schreibzugriff auf APIs, auf die ursprünglich nur ein Lesezugriff vorgesehen war, die Systeme anfällig für Angriffe und möglichen Datenverlust. Fast 60 % aller Unternehmen gewähren Schreibzugriff für mindestens die Hälfte ihrer APIs.
Unternehmen können die Ursachen für API-bezogene Fehler leicht übersehen und falsch einordnen: Nicht alle API-Fehler werden durch Angriffe verursacht, und nicht alle Angriffe auf APIs können auf die gleiche Weise abgewehrt werden. Ein Fehler oder eine Schwachstelle, die übersehen oder falsch diagnostiziert wird, kann zu einer schlechten Endnutzererfahrung oder – schlimmer noch – zu einem Cyberangriff führen.
Mehr als 200 Millionen öffentliche und private APIs sind im Einsatz, Tendenz steigend. Um die Leistungsfähigkeit dieser (und zukünftiger) APIs sicher nutzen zu können, benötigen Unternehmen einen speziell entwickelten Ansatz zur API-Verwaltung, der die folgenden 3 „Do's“ und „Don'ts“ umfasst.
Nehmen wir an, das Acme Hospital bietet digitale Initiativen an, die von Patienten und Gesundheitsanbietern geschätzt werden: von nahtloser mobiler Telemedizin bis hin zu KI-gestützter Aktenbearbeitung. Eines Tages ermöglicht einer der Entwickler von Acme den „Schreibzugriff“ auf die API eines Abrechnungssystems ohne entsprechende Dokumentation. Einige Monate später wird der Anbieter gehackt – und dann können Angreifer durch laterale Bewegung die öffentliche API von Acme missbrauchen, um in die Patientendaten des Krankenhauses einzudringen.
Acme hätte dieses Szenario früher erkennen und abwehren können, wenn Folgendes automatisch möglich gewesen wäre:
Erkennung aller öffentlichen API-Endpunkte (einschließlich nicht-authentifizierter APIs) und des damit verbundenen Datenverkehrs
Erkennung von API-Schemata – die Metadaten, die die Spezifikationen eines gültigen API-Aufrufs/einer gültigen Antwort definieren
Erkennung von Angriffsvarianten auf APIs
Genau hier kommen API-Sicherheitslösungen ins Spiel, die Machine Learning-Modelle nutzen und keine manuelle, zeitpunktbezogene Kommunikation zwischen IT, Sicherheit und Entwicklern erfordern.
Beispielsweise können Unternehmen wie Acme mit Hilfe von Machine Learning-basierter API-Erkennung und und Erkennung von API-Schemata eine vollständigere Bestandsaufnahme ihrer APIs erstellen: Was sind diese APIs? Auf welche Daten und Systeme greifen sie zu? Wann und wo wird auf sie zugegriffen? Wem wurde eine Berechtigung mit Leserechten bzw. eine mit Schreibrechten erteilt?
Diese Art von Daten ist von absolut essenziell, um die Ausbreitung von Schatten-APIs zu verhindern. Bei der Entwicklung neuer Funktionalitäten für Kunden (die häufig zunächst als internetseitige APIs offengelegt werden) werden die API-Dokumentation und die „besten Sicherheitsverfahren“ in der Regel dem Ermessen der einzelnen Entwickler überlassen. Oftmals fehlt es an Zeit oder Ressourcen, um die Sicherheitsteams einzubinden.
Aus diesem Grund entstehen Sicherheitsprobleme: Unternehmen können nicht schützen, was sie nicht sehen können. Tatsächlich haben die Machine Learning-Modelle von Cloudflare 31 % mehr API-Endpunkte aufgedeckt, als die Unternehmen selbst angegeben haben – was darauf hindeutet, dass fast ein Drittel von API eigentlich Schatten-APIs sind.
Schatten-API (oft unabsichtlich bei häufigen Codeänderungen eingeführt) sind nicht von Natur aus bösartig. Wenn man jedoch bedenkt, dass 86 % der Entwickler die Anwendungssicherheit nicht als oberste Priorität betrachten, stellen Schatten-API eine große Bedrohung dar. Wenn sie missbraucht werden, können sie zur Offenlegung von Daten, ungepatchten Sicherheitslücken, Verstößen gegen die Datenkonformität und anderen Risiken führen. Machine Learning hilft, diese Schatten-API ans Tageslicht zu bringen.
Webanwendungen und APIs sind grundlegend verschieden. Eine Ride-Sharing-App ist für ihre Nutzenden „sichtbar“, aber die API, die Anwendungen den Zugriff auf Google Maps-Daten ermöglicht, ist „unsichtbar“. In Anbetracht dieser (und anderer) Unterschiede benötigen Unternehmen zum Schutz von APIs maßgeschneiderte API-Sicherheit, nicht nur Sicherheit für Webanwendungen.
Eine herkömmliche Web Application Firewall (WAF) zum Beispiel filtert und überwacht den HTTP-Traffic zwischen einer Webanwendung und dem Internet auf der Grundlage einer Blockliste. Die WAF sucht nach bekannten Anzeichen eines Angriffs und ergreift dann Maßnahmen, um diese Angriffe zu stoppen. Jeder andere Traffic ist gestattet. Dies ist das „negative“ Sicherheitsmodell, das für die Sicherheit von Webanwendungen wirksam sein kann, wo es einfacher ist, bösartigen Web-Traffic zu erkennen und zu blockieren.
Der Schutz von APIs vor Missbrauch – API-Sicherheit – erfordert jedoch „positive“ Sicherheit. Anstatt nur nach „bekannten schlechten“ Anfragen zu suchen, sollten Sie nach „bekannten guten“ Anfragen suchen und lassen Sie nur diese durch: blockieren Sie alles andere. (Nähere Informationen dazu, was diese Anfragen ausmacht – d.h. API-Aufrufe erhalten Sie hier).
Warum?
Nehmen wir das Beispiel eines australischen Telekommunikationsanbieters, bei dem im Zuge eines Datenverstoßes die Daten von mehr als 10 Millionen Kunden offengelegt wurden. Der Hacker hatte über eine nicht-authentifizierte API auf eine bestimmte Kundendatenbank zugegriffen. Während die vollständigen Details des Angriffs der Öffentlichkeit nicht vorliegen, ist es erwähnenswert, dass ein „positives“ API-Sicherheitsmodell nur API-Traffic zugelassen hätte, der den API-Spezifikationen des Unternehmens entsprochen hätte.
Mit anderen Worten: Stellen Sie auf „positive“ API-Sicherheit um und lassen Sie nur Datenverkehr von authentifizierten Nutzenden aus authentifizierten Unternehmensnetzwerken zu, die autorisierte Aktionen durchführen. (Unternehmen können auch Sicherheitsmodelle kombinieren, z. B. indem sie die „negative“ Sicherheit einer WAF mit der „positiven“ Sicherheit eines API-Gateways kombinieren).
Unterm Strich: APIs erfordern einen umfassenden Ansatz zur Abwehr einer breiten Palette von API-Bedrohungen, zu denen die folgenden 6 größten API-Bedrohungen gehören:
Quelle: Bericht zu API-Sicherheit und -Verwaltung 2024
Wie aus dem obigen Diagramm hervorgeht, machten HTTP-Anomalien den Großteil (60,7 %) der abgewehrten API-Bedrohungen aus. HTTP-Anomalien (z. B. fehlende User Agents – die Software, die Internet-Inhalte für Endnutzenden abruft – und andere Anomalien) sind häufige Anzeichen für bösartige Anfragen.
Durch die Anwendung von „positiver“ Sicherheit (wie oben beschrieben) können Unternehmen HTTP-Anomalien und andere Bedrohungen erkennen und nur „sauberen“ Datenverkehr für jede API zu ihren API-Servern zulassen.
IT-Mitarbeitende, Sicherheitsexperten und Anwendungsentwickler sollten sich die Verantwortung für den Schutz der riesigen Angriffsfläche teilen, die mit Tausenden von API-unterstützten Assets einhergeht. Allerdings haben diese Abteilungen auf widerstreitende Prioritäten:
73 % der Entwickler sagen, dass die Arbeit oder die Tools, die ihr Sicherheitsteam von ihnen verlangt, „ihre Produktivität und Innovation beeinträchtigen“.
87 % der CIOs glauben, dass Softwareingenieure und -entwickler „Kompromisse bei Sicherheitsrichtlinien und -kontrollen eingehen, um neue Produkte und Dienstleistungen schneller auf den Markt zu bringen“.
Nur die Hälfte der CISOs sind der Meinung, dass Entwickler mit den Sicherheitsrisiken von Entwicklungs- und Workflow-Tools „sehr vertraut“ sind.
Dies kann dazu führen, dass Unternehmen einen „Kompromiss“ zwischen schnellerer Innovation und besserer Sicherheit eingehen und ihre API angreifbar machen. Dem Bericht zufolge gestatten fast 60 % der Unternehmen mindestens der Hälfte ihrer APIs einen Schreibzugriff – doch wer stellt letztendlich sicher, dass der Schreibzugriff nicht an den falschen Nutzenden vergeben wird?
Für Unternehmen, die ständig neue Dienste über API bereitstellen, kann eine Connectivity Cloud als dieses Bindeglied zwischen der Anwendungsbereitstellung und der Tiefenverteidigung der API dienen.
Eine Connectivity Cloud ist eine einheitliche Plattform von Cloud-nativen Diensten, die eine sichere Any-to-Any-Verbindung über IT-Umgebungen hinweg vereinfacht. Dies wiederum hilft Unternehmen, die Kontrolle und den Überblick über ihre ausgedehnten digitalen Domains zurückzugewinnen – einschließlich ihres API-Traffics.
Mit einer Connectivity Cloud können Unternehmen die folgenden Aufgaben (und mehr) mit einer einzigen Steuerungsebene meistern:
Automatisierung API-Erkennung und -Sichtbarmachung, mit der alle Beteiligten eine klare Vorstellung von ihrem API-Bestand erhalten
Modernisierung der API-Authentifizierungs- und Autorisierungsprozesse von Anfang an
API-Endpunktverwaltung zur Überwachung von Kennzahlen wie Latenz, Fehlern, Fehlerquoten und Antwortgrößen für API-orientierte Domains
Schutz vor Bedrohungen auf API-Anwendungsschicht (L7) wie DDoS-Angriffen, Brute-Force-Anmeldeversuchen und anderem API-Missbrauch
API-Technologie ist nicht neu, doch die ganzheitliche Betrachtung der API-Sicherheit ist für viele AppSec- und AppDev-Teams neu. Dennoch muss jeder Fortschritt irgendwo starten, und API-Sicherheit kann stufenweise in Angriff genommen werden:
Stufe 1 – Sichtbarkeit: Beginnen Sie damit, alle in Ihrem Unternehmen verwendeten API zu identifizieren. Verwenden Sie API-Ermittlungstools, prüfen Sie die technische Dokumentation und Vereinbarungen, sprechen Sie mit Ihren Entwicklern und überwachen Sie Ihren Web-Traffic.
Stufe 2 – Allgemeiner Schutz vor Webangriffen: Webanwendungen und APIs arbeiten oft zusammen (z. B. eine E-Commerce-Website, die eine API zur Zahlungsabwicklung nutzt). Verwenden und integrieren Sie Tools, die direkt darauf ausgelegt sind, Webanwendungen (und in gewissem Maße auch die API dahinter) vor DoS- und DDoS-Angriffen, Credential Stuffing, Zero-Day-Schwachstellen und anderen Bedrohungen zu schützen.
Stufe 3 – Konsolidierte erweiterte API-Sicherheit: Das Cloudflare-Portfolio für Webanwendungs- und API-Schutz (WAAP), basierend auf einer Connectivity Cloud, bietet ganzheitliche Sicherheit und Performance für öffentlich zugängliche APIs, ohne die Produktivität zu beeinträchtigen. Mit der Erfassung von APIs, integrierter API-Verwaltung und -Analyse sowie mehrschichtigen Schutzmaßnahmen ermöglicht Cloudflare der IT- und Sicherheitsabteilung, Transparenz und Kontrolle über ihre APIs zu erlangen.
Dieser Beitrag ist Teil einer Serie zu den neuesten Trends und Themen, die für Entscheidungsträger aus der Tech-Branche heute von Bedeutung sind.
Holen Sie sich den Bericht zu API-Sicherheit und -Verwaltung 2024, um die häufigsten API-Schwachstellen, Branchenprognosen und detailliertere Empfehlungen zum Schutz von APIs zu erfahren.
Folgende Informationen werden in diesem Artikel vermittelt:
3 gängige Probleme bei der API-Nutzung
Die „Do's“ und „Don'ts“ der maßgeschneiderten API-Verwaltung
Schrittweise zur stärker ausgereiften API-Sicherheit