Top-10-API-Bedrohungen des OWASP

Sie sehen sich die Dokumentation zu Apigee Edge an.
Sehen Sie sich die Apigee X-Dokumentation an. info

In diesem Dokument werden verschiedene Ansätze beschrieben, mit denen Sie in Apigee Sicherheitslücken beheben können, die von OWASP identifiziert wurden. Weitere für Apigee dokumentierte Ansätze finden Sie unter OWASP Top 10 2021 – Optionen zur Risikominimierung in Google Cloud.

Einführung

OWASP ist eine offene Community, die Organisationen dabei unterstützt, vertrauenswürdige Anwendungen und APIs zu entwickeln, zu kaufen und zu verwalten. Im Rahmen des OWASP API Security Project veröffentlicht OWASP die wichtigsten Sicherheitsrisiken für Webanwendungen und REST APIs und gibt Empfehlungen zur Behebung dieser Risiken.

In diesem Dokument werden Ansätze zum Schutz vor gängigen API-basierten Angriffen beschrieben, die in den Top 10 der API-Sicherheitsbedrohungen 2019 von OWASP aufgeführt sind. Ein häufiges Thema bei den wichtigsten Bedrohungen, die in der neuesten Liste aufgeführt sind, ist die falsche Platzierung von Authentifizierungs- und Autorisierungssteuerungen. Dazu gehört beispielsweise die Filterung von Daten, die von einer API-Anfrage in Clientanwendungen zurückgegeben werden, indem das Anti-Muster verwendet wird, dass die Zugriffssteuerung von der Clientanwendung ausgeführt wird.

Das API-Ökosystem wächst weiterhin rasant. API-Missbrauch und ‑Missachtung, die zur Datenextraktion durch Angreifer führen, werden leider zu einem der häufigsten Angriffsvektoren. Sicherheit hat für Apigee weiterhin oberste Priorität. Wir haben eine Reihe neuer Funktionen wie Advanced API Ops eingeführt, die Sicherheitsberichte und Funktionen zur Anomalieerkennung umfassen. Es ist jedoch wichtig, die Sicherheitsfunktionen von Apigee richtig zu entwerfen und zu implementieren, um die Wahrscheinlichkeit erfolgreicher Angriffe auf Ihre APIs zu verringern.

Verbraucheranwendungen sollten als nicht vertrauenswürdig oder „öffentlich“ eingestuft werden, da Sie die Plattform, auf der die App ausgeführt wird, nicht steuern. Angenommen, jede öffentliche App kann und wird manipuliert. Daher können sie nicht vertrauenswürdig sein, um die Zugriffssteuerung (API1, API5) durchzusetzen, Antwortdaten zu filtern (API6) oder Clientgeheimnisse (API2) wie API-Schlüssel oder Zugriffstokens sicher zu speichern. Einige Empfehlungen ergeben sich aus der Prüfung der OWASP Top 10 2019:

  • Legen Sie fest, welche Art von Client-Apps Ihre APIs verwenden werden (SPA, mobile oder browserbasiert), und entwerfen Sie die entsprechenden Authentifizierungs-, Autorisierungs- und Sicherheitsmuster.
  • Verwenden Sie immer OAuth- oder OpenID Connect-Abläufe für „öffentliche Clients“. Die Verwendung von PKCE wird dringend empfohlen.
  • Überlegen Sie sich die Geschäftslogik Ihrer App, definieren Sie zuerst Ihre OpenAPI-Spezifikation und entwerfen Sie Ihre API-Proxys so, dass alle Antwortdaten aus dem Backend in Apigee gefiltert werden. Verwende niemals die Logik des App-Codes, um dies zu tun.
  • Filtern Sie alle Datenanfragen, die personenidentifizierbare Informationen enthalten, sodass nur Daten aus Ihrem Backend zugelassen werden, die dem anfragenden Nutzer gehören.

API1:2019 Broken object level authorization

Beschreibung der Bedrohung

Eine unzureichende Autorisierungsbestätigung einer Objektzugriffsanfrage ermöglicht es einem Angreifer, eine nicht autorisierte Aktion auszuführen, indem er ein Zugriffstoken wiederverwendet. Diese Bedrohung wird durch eine fehlerhafte Konfiguration der Autorisierungsbestätigungen verursacht. Apigee stellt VerifyApiKey-, OAuth- und JWT-Richtlinien (JSON Web Token) bereit, die vor dieser Sicherheitslücke schützen. Es ist jedoch wichtig, dass diese Richtlinien richtig konfiguriert sind, um diese Bedrohung zu verhindern.

Um diese Bedrohung zu verhindern, ist es wichtig, dass die Entwicklungs- und Sicherheitsteams eng zusammenarbeiten. Autorisierung ist von Natur aus ein komplexes Thema und eine effektive, detaillierte Autorisierung erfordert ein tiefes Verständnis der Geschäftslogik der Anwendung.

Aus Sicht der Apigee-Implementierung sind zwei Hauptaspekte zu berücksichtigen:

  • Integrität des Zugriffstokens
  • Zugriffssteuerung erzwingen

Integrität des Zugriffstokens

Es ist wichtig, zu prüfen, ob das vom anfragenden Client bereitgestellte Token nicht manipuliert wurde. Verwenden Sie dazu den richtigen OAuth- oder OpenID Connect-Ablauf zusammen mit dem entsprechenden Mechanismus zur Validierung oder Signatur von Anmeldedaten. Apigee unterstützt alle gängigen OAuth-Abläufe.

Zu den Apigee-Richtlinien für die Überprüfung von Zugriffstokens gehören:

Zugriffssteuerung erzwingen

Nachdem die Gültigkeit des Zugriffstokens überprüft wurde, müssen Sie Richtlinien zur Durchsetzung der Zugriffssteuerung implementieren, um jede eingehende API-Anfrage anhand der Zugriffsberechtigungen des Autorisierungstokens zu prüfen.

Apigee bietet zwei Hauptmechanismen zur Überprüfung und Durchsetzung von Autorisierungsrichtlinien:

  • Intern: Bei der Verwendung von bedingten Ablaufvorgängen werden Zugriffsanfragen anhand von Ansprüchen ausgewertet, die als Ablaufvariablen aus einem Autorisierungstoken extrahiert wurden.
  • Delegiert: Verwendung eines Dienst-Aufrufs für eine Lösung zur Zugriffsverwaltung von Drittanbietern

Der interne Ansatz (in der Abbildung oben dargestellt) wird empfohlen, wenn das Zugriffssteuerungsmodell relativ einfach ist. Beispielsweise können Ansprüche, die aus einem Zugriffstoken extrahiert wurden, verwendet werden, um eine API-Objektanfrage direkt zu bewerten und zu autorisieren.

Verwenden Sie die für die OAuth- oder JWT-Richtlinien verfügbaren Ablaufvariablen, um Zugriffsanfragen mithilfe bedingter Ablaufanweisungen zu bewerten.

Der delegierte Ansatz (in der Abbildung oben dargestellt) wird empfohlen, wenn aus einem Zugriffstoken extrahierte Berechtigungen nicht direkt zur Autorisierung einer API-Anfrage an ein Backend-Objekt verwendet werden können, oder für komplexere OAuth-Ablauftypen, bei denen ein separater Aufruf eines Autorisierungsservers erforderlich ist, um ein Zugriffstoken zu erhalten.

Mit der Richtlinie für Service-Hinweise können Sie entweder eine Autorisierungsrichtlinienentscheidung von einem Drittanbieterdienst anfordern oder zusätzliche Informationen zu Ansprüchen des anfragenden Bevollmächtigten erhalten, um dann mithilfe eines bedingten Ablaufs eine Entscheidung zur Zugriffssteuerung zu treffen.

API2:2019 Fehlerhafte Nutzerauthentifizierung

Beschreibung der Bedrohung

Durch schlecht implementierte Richtlinien für die Nutzerauthentifizierung können Angreifer sich als rechtmäßige Nutzer ausgeben, indem sie Implementierungsfehler in der Authentifizierung ausnutzen. Bei der Implementierung von Authentifizierungsansätzen sollten Sie die folgenden Authentifizierungsprinzipien beachten:

  • Authentifizieren Sie immer sowohl den User-Agent (die App) als auch den anfragenden Nutzer.
  • Verwenden Sie Muster für die delegierte Authentifizierung und Autorisierung und vermeiden Sie das Übergeben von Passwörtern direkt in einer API-Anfrage.
  • Prüfen Sie immer die Signatur der Anmeldedaten und achten Sie darauf, dass alle verwendeten Anmeldedaten eine definierte Ablaufzeit haben.
  • Brute-Force-Angriffe verhindern, indem Sie Quoten festlegen und mit Apigee Sense botgestützte Brute-Force-Angriffe erkennen und darauf reagieren

Beim Outside-In-Paradigma wird das API-Design nicht anhand der Struktur der vorhandenen Daten in Ihren Back-End-Systemen, sondern anhand der Anwendungsfälle der Nutzer für die Daten entwickelt. Sicherheit ist ein wichtiges Element beim Entwerfen von APIs für externe Nutzer. Backend-Systeme werden in der Regel nicht mit ausreichend starken Authentifizierungsimplementierungen für die Nutzung in öffentlichen Netzwerken entwickelt. Hier können Apigee in Kombination mit einer Lösung für die Identitäts- und Zugriffsverwaltung leistungsstarke Lösungen zum Schutz vor dieser Bedrohung bieten.

Es gibt hier einige wichtige Elemente, die in den folgenden Abschnitten behandelt werden:

  • Sicherheitsdesign: Apigee-Funktionen für die Implementierung von Authentifizierungsmustern optimal nutzen
  • Governance: Dafür sorgen, dass die Authentifizierungsmuster einheitlich in allen veröffentlichten API-Produkten verwendet werden
  • Betriebssicherheit: Erkennen verdächtiger oder anomaler Verhaltensweisen und Versuche, authentifizierte API-Proxys zu umgehen oder per Brute-Force-Methode zu knacken

Sicherheitsdesign

Ziel des Sicherheitsdesigns ist es, Authentifizierungsabläufe und die Integration mit Identitätstools von Drittanbietern korrekt zu implementieren. Das Sicherheitsdesign ist eine kritische Phase. Sie beginnt damit, die richtige Art der delegierten Authentifizierung zu ermitteln, die je nach Art der App verwendet werden soll, die Ihre API-Endpunkte nutzt. Im nächsten Schritt definieren Sie gemeinsam mit Ihrem Identitätsteam die Integrationsmuster, die mit Ihrer Identitätslösung implementiert werden sollen.

Die RFCs für OpenID Connect und OAuth bieten eine breite Palette von delegierten Authentifizierungs- und Autorisierungsabläufen sowie Akteure, die an diesen Abläufen beteiligt sind. Dies ist ein komplexes Thema und es ist nicht überraschend, dass eine fehlerhafte Authentifizierung eine der größten OWASP-API-Bedrohungen ist. Eine umfassende Einführung in die korrekte Implementierung von Identitätsstandards würde den Rahmen dieses Dokuments sprengen. Apigee bietet jedoch viele zusätzliche Ressourcen, um OAuth-Abläufe besser zu verstehen, z. B. dieses E-Book, diesen Webcast und eine Beispielimplementierung.

Authentifizierungsrichtlinien

Zu den Apigee-Richtlinien, die bei Problemen mit Identität und Authentifizierung helfen, gehören:

Traffic-Verwaltung

Die folgenden Apigee-Features zur Trafficverwaltung schützen vor Brute-Force-Angriffen:

  • Die Spike Arrest-Richtlinie, um ein Gesamtlimit für die laufende durchschnittliche Rate für einen API-Proxy festzulegen
  • Kontingentrichtlinien, um API-Proxys detaillierte Tariflimits basierend auf Kontingenten festzulegen, die durch App-Schlüssel, Entwickler oder API-Produktkontingente definiert sind
  • Cache-Richtlinien zum Caching gespeicherter Zugriffstokens basierend auf ihren definierten Ablaufzeiten sowie die Möglichkeit, im Cache gespeicherte Anmeldedaten invalidate (z. B. in einer Situation, in der ein gültiges Zugriffstoken manipuliert wurde)

Governance

Sicherheit ist ein fortlaufender Prozess, kein Projekt, das man einmal einrichtet und dann vergisst. Eine der Hauptursachen für Sicherheitsverletzungen sind Fehlkonfigurationen. Nachdem Authentifizierungsabläufe, Muster für die Identitätsintegration und authentifizierungsbezogene Richtlinien für die Verkehrsverwaltung definiert wurden, ist es absolut entscheidend, dass sie korrekt und konsistent implementiert werden.

Apigee bietet eine Reihe von Funktionen und Tools, um die Implementierungsintegrität zu gewährleisten und Fehlkonfigurationen zu vermeiden.

Rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC)

Unabhängig davon, ob Sie ein großes Unternehmen oder ein kleines Start-up sind, sollten Sie dafür sorgen, dass nur die richtigen Personen und Teams auf API-Proxy-Konfigurationen zugreifen und diese ändern können. API-Programme werden von multidisziplinären Teams in Ihrer Organisation unterstützt. Es ist absolut wichtig, dass jedem Team nur die Berechtigungen gewährt werden, die für die Ausführung seiner Aufgaben im Rahmen Ihres API-Vorhabens erforderlich sind.

Apigee bietet Funktionen zum Verwalten des rollenbasierten Zugriffs. Sie können Nutzern vordefinierte Rollen zuweisen oder benutzerdefinierte Rollen für Ihre API-Teams erstellen. Die korrekte Definition und Verwaltung von Rollenzuweisungen ist entscheidend, damit Sie Ihr API-Programm sicher skalieren können. Sie können auch die Verknüpfung verwenden, um eine Integration in Ihr vorhandenes Unternehmensverzeichnis vorzunehmen und die Notwendigkeit zu verringern, in Apigee ein zweites Administratorkonto zu verwalten.

Freigegebene Abläufe

Mit freigegebenen Abläufen können Sie Richtlinien und Ressourcen in einem wiederverwendbaren Objekt definieren, das in API-Proxys implementiert werden kann. Angenommen, Sie haben gemeinsam mit Ihren Sicherheitsteams mehrere Authentifizierungs-Designmuster entwickelt, die auf der Art der App basieren, die eine API nutzt. Ein API-Entwickler muss kein Experte für Identitäten sein, um diese zu verwenden. Er muss lediglich den richtigen gemeinsamen Ablauf kennen, den er seiner vorhandenen API-Proxy-Konfiguration mithilfe der Richtlinie Flow-Hinweis hinzufügen kann.

Abbildung: Freigegebene Abläufe sind wiederverwendbare Bündel von Richtlinien und bedingter Logik, mit denen Sie ein zusammengesetztes Muster beibehalten können.

Security Reporting

Nachdem Sie dafür gesorgt haben, dass nur die richtigen Personen in Ihrer Organisation Ihre Authentifizierungsmuster ändern können, und Sie Ihre freigegebenen Authentifizierungsabläufe definiert haben, müssen Sie dafür sorgen, dass die von Ihren API-Teams entwickelten API-Proxys diese Authentifizierungsmuster konsistent verwenden.

Die neue Funktion Advanced API Ops von Apigee umfasst erweiterte Sicherheitsberichte, mit denen die Betriebs- und Sicherheitsteams Berichte zu allen API-Proxys ganz einfach aufrufen können. Der Schwerpunkt liegt auf der Einhaltung von Sicherheitsrichtlinien wie der Verwendung gemeinsam genutzter Abläufe. Berichte, Protokolle und Benachrichtigungen sind ein wichtiges Element der API-Sicherheit. Weitere Informationen finden Sie unter API10: Unzureichende Protokollierung. Aus Sicht der Vermeidung von Risiken bei unterbrochener Authentifizierung sind sie jedoch äußerst nützlich, um die Einhaltung Ihrer definierten Authentifizierungsstandards zu gewährleisten, die als freigegebene Abläufe implementiert sind.

Betriebssicherheit

Sobald Ihre APIs mit den richtigen Authentifizierungsmustern und einer Baseline-Traffic-Verwaltung in der Produktion sind, muss Ihr SecOps-Team auch verdächtige Aktivitäten überwachen und darauf reagieren können. Diese beginnen oft mit Versuchen, Anmeldedaten zu manipulieren.

Apigee Sense

Apigee Sense schützt Ihre APIs vor unerwünschtem Anfragetraffic, einschließlich Angriffen durch böswillige Clients. Apigee Sense analysiert den API-Anfragetraffic und identifiziert Muster, die auf unerwünschte Anfragen hinweisen könnten. Mithilfe dieser Analyse können Sie Clients ermitteln, die unerwünschte Anfragen stellen, und dann Maßnahmen zum Zulassen, Blockieren oder Melden dieser Anfragen ergreifen. Zu den zukünftigen Funktionen von Sense gehört die Möglichkeit, die reCAPTCHA-Bestätigung bei verdächtigem Traffic automatisch zu aktivieren.

Mit Apigee Sense können Sie Ihre APIs vor Anforderungsmustern schützen, darunter:

  • Automatisiertes Verhalten, das sich in menschliches Verhalten einfügt
  • Wiederholte Versuche von derselben IP-Adresse
  • Ungewöhnliche Fehlerraten
  • Verdächtige Clientanfragen
  • Daten-Crawling
  • Schlüsselernte und Brute-Force-Angriffe auf die Authentifizierung
  • Aktivitätsspitzen
  • Geografische Muster

Advanced API Ops

Während Sense speziell zum Erkennen und Reagieren auf botähnliche Bedrohungen entwickelt wurde, umfasst die erweiterte API-Bereitstellung sowohl die Anomalieerkennung als auch die Definition von erweiterten Benachrichtigungen.

Bei der Anomalieerkennung werden Modelle aus den Bereichen künstliche Intelligenz (KI) und maschinelles Lernen (ML) auf Ihre historischen API-Daten angewendet. Die Anomalieerkennung kann dann Warnungen in Echtzeit für Szenarien auslösen, die Sie noch nicht bedacht haben, und so Ihre Produktivität verbessern und die mittlere Zeit bis zur Lösung (MTTR, Mean Time To Resolution) Ihrer API-Probleme reduzieren.

Advanced API Ops baut auf dem vorhandenen Warnungsmechanismus für das API-Monitoring auf und fügt folgende erweiterte Warnungstypen hinzu:

  • Gesamter Traffic-Warnungen. Löst eine Warnung aus, wenn sich der Traffic innerhalb eines Zeitraums um einen bestimmten Prozentsatz ändert. Beispiel: Sie können eine Warnung auslösen lassen, wenn der Traffic für eine Stunde um 5 % oder mehr steigt oder über eine Woche hinweg um 10% sinkt.
  • Anomaliewarnungen Edge erkennt Traffic- und Leistungsprobleme, damit Sie diese nicht selbst erkennen müssen. Sie können dann eine Warnung für diese Anomalien auslösen lassen.
  • TLS-Expiry-Warnungen. Löst eine Benachrichtigung aus, wenn ein TLS-Zertifikat bald abläuft

API3:2019 Excessive data exposure

Beschreibung der Bedrohung

Eine veröffentlichte API kann mehr Daten als nötig offenlegen und die erforderliche Filterung der Client-App überlassen. Wenn ein Angreifer die zugrunde liegende API direkt abfragt, kann er auf vertrauliche Daten zugreifen.

Einer der Outside-In-Designprinzipien von Apigee für das API-Design ist die Datensparsamkeit. Arbeiten Sie mit Ihren UX-Designern und Entwicklern zusammen, um nur Daten über APIs bereitzustellen, die in der App-Benutzeroberfläche benötigt werden. Backend-Systeme wurden nicht für öffentliche Nutzungsmuster entwickelt. Eine der ersten Aufgaben beim API-first-Design mit Apigee besteht daher darin, die freigegebenen Daten auf das Minimum zu reduzieren, das für ein hervorragendes API-Produkt für Ihre Kunden und Entwickler erforderlich ist.

Ein weiteres Designprinzip von Apigee ist die Wiederverwendbarkeit. Abgesehen von Sicherheitsbedenken bedeutet die Verwendung einer App zum Filtern der von einer API bereitgestellten Daten, dass diese Filterlogik auf jede Plattform portiert werden muss, für die Sie eine App entwickeln.

Aus Sicherheitsperspektive ergibt sich diese Bedrohung aus der Deaktivierung der Autorisierungsdurchsetzung an eine App, oft jedoch auf einer Plattform oder einem Betriebssystem, über die Sie keine Kontrolle haben. Wir haben bereits in API1 und API2 die Bedeutung der korrekten Implementierung von Authentifizierung und Autorisierung zur Vermeidung von unbefugten Datenzugriffen untersucht.

In den folgenden Abschnitten erfahren Sie, wie Sie Folgendes tun:

  • Anfragen und Antworten an Back-End-Dienste umschreiben, um die Datenpräsenz zu minimieren
  • Implementieren Sie eine Fehlerbehandlung, um zu verhindern, dass Angreifer durch ausführliche Fehlermeldungen sensible Umgebungsinformationen zu Ihren Backend-Diensten erhalten.

Antworten und Anfragen umschreiben

Back-End-Systeme sind in der Regel nicht für die Verwendung in öffentlichen Apps oder in nicht vertrauenswürdigen öffentlichen Netzwerken konzipiert. Apigee Edge wurde entwickelt, damit Sie öffentliche API-Produkte bereitstellen können, indem Sie Ihre Back-Ends vor einer übermäßigen Datenpufferung schützen.

Dazu verwendet Apigee drei wichtige Richtlinien:

  • Nachricht zuweisen
  • Code-Hinweise
  • Fehlerbehandlung

Richtlinie „Nachricht zuweisen“

Die AssignMessage-Richtlinie ändert oder erstellt neue Anfrage- und Antwortnachrichten während des API-Proxy-Ablaufs. Mit der Richtlinie können Sie die folgenden Aktionen für diese Nachrichten ausführen:

  • Einer Nachricht neue Formularparameter, Header oder Abfrageparameter hinzufügen
  • Vorhandene Properties von einer Nachricht in eine andere kopieren
  • Entfernen von Headern, Abfrageparametern, Formularparametern und/oder Nachrichtennutzlasten aus einer Nachricht
  • Den Wert vorhandener Eigenschaften in einer Nachricht festlegen

Mit AssignMessage können Sie in der Regel Eigenschaften der Anfrage oder Antwort hinzufügen, ändern oder entfernen. Sie können jedoch AssignMessage auch verwenden, um eine benutzerdefinierte Anfrage oder Antwort zu erstellen und sie an ein alternatives Ziel weiterzuleiten, wie unter Benutzerdefinierte Anfragenachrichten erstellen beschrieben.

Komplexe Umwandlung mit benutzerdefiniertem Code

Für komplexe Datenabläufe und Umschreibregeln, die über die Möglichkeiten der Richtlinie „Nachricht zuweisen“ hinausgehen, können Sie prozedurale Sprachen wie JavaScript, Java oder Python verwenden. Sie können einem API-Proxy benutzerdefinierten Code hinzufügen und ihn dann über Richtlinien aufrufen, die dem Proxy-Ablauf hinzugefügt wurden. Unterstützung für prozeduralen Code soll Ihnen die Implementierung einer komplexen Verarbeitung von Flussvariablen, Fehlern sowie Anfrage- und Antworttexten erleichtern.

Mit proaktivem Code können Sie Folgendes tun:

  • Erstellen oder ändern komplexer Textwerte wie Anfrage- und Antwortwerte.
  • URLs umbenennen, z. B. um eine Ziel-Endpunkt-URL zu maskieren

Apigee Edge enthält für unterstützte Sprachen eine separate Richtlinie: JavaScript-Richtlinie, JavaCallout-Richtlinie und PythonScript-Richtlinie.

Fehlerbehebung

Mit Apigee können Sie benutzerdefinierte Ausnahmen mithilfe einer Richtlinie vom Typ RaiseFault ausführen. Mit der Richtlinie „Raise Fault“, einer Variante der Richtlinie „Assign Message“, können Sie eine benutzerdefinierte Fehlerantwort als Reaktion auf einen Fehler generieren.

Freigegebene Abläufe

Gemeinsam genutzte Abläufe können verwendet werden, um die Standardisierung von Fehlermeldungen zu erzwingen. Beispielsweise können dieselben konfigurierten Richtlinien, die einen bestimmten HTTP-Fehlercode aus dem Backend erkennen, verwendet werden, um die Fehlerantwort umzuschreiben und eine allgemeine Fehlermeldung zurückzugeben.

API4:2019 Mangel an Ressourcen und Ratenbegrenzung

Beschreibung der Bedrohung

Wenn keine Richtlinien zur Ratenbegrenzung implementiert werden, können Angreifer das Backend mit Denial-of-Service-Angriffen überlasten.

Diese Bedrohung lässt sich mit den folgenden Apigee-Funktionen ganz einfach beheben:

  • Kontingente und Spike Arrest-Richtlinien als vorbeugende Maßnahmen, um den Traffic für eingehende API-Anfragen zu begrenzen
  • Apigee Sense zum dynamischen Erkennen und Beheben von botgestützten Angriffen
  • Erweiterte API-Überwachung und -Benachrichtigungen als Aufdeckungskontrollen, um über laufende DDoS-Angriffe informiert zu werden

Ratenbegrenzung mit Kontingent- und Spike Arrest-Richtlinien

Apigee bietet zwei Richtlinien für die Ratenbegrenzung:

  • Spike Arrest ist eine allgemeine Richtlinie, die auf API-Proxy-Ebene definiert wird, um die Gesamtzahl der eingehenden Anfragen an ein Back-End zu begrenzen.
  • Kontingente sind ein detailliertes Richtlinientool zum Erzwingen von Kontingentrichtlinien, entweder auf API-Proxy- oder API-Produktebene.

Spike Arrest

Die SpikeArrest-Richtlinie schützt vor Trafficspitzen. Mit dieser Richtlinie wird die Anzahl der Anfragen, die von einem API-Proxy verarbeitet und an ein Back-End gesendet werden, mithilfe eines in der Richtlinie definierbaren gleitenden Durchschnittswerts gedrosselt. So werden Leistungsverzögerungen und Ausfallzeiten verhindert.

Kontingente

Mit der Kontingentrichtlinie können Sie die Anzahl der Anfragenachrichten konfigurieren, die ein API-Proxy in einem bestimmten Zeitraum zulässt, z. B. in einer Minute, einer Stunde, einem Tag, einer Woche oder einem Monat. Sie können festlegen, dass das Kontingent für alle Anwendungen, die auf den API-Proxy zugreifen, gleich ist, oder Sie können die Kontingente auf folgenden Grundlagen festlegen:

  • Das Produkt, das den API-Proxy enthält
  • Die Anwendung, die die Anfrage an die API sendet
  • Der Entwickler der Anwendung
  • Viele weitere Kriterien

Diese Richtlinie ist detaillierter als die SpikeArrest-Richtlinie und sollte in der Regel gleichzeitig mit dieser verwendet werden.

Bot-Erkennung mit Apigee Sense

Mit Apigee Sense können Sie Maßnahmen ergreifen, um Anfragen von bestimmten Clients, IP-Bereichen oder Organisationen mit autonomen Systemen explizit zuzulassen, zu blockieren oder zu melden, wenn diese Clients oder Standorte schädliches oder verdächtiges Verhalten zeigen. Apigee Edge wendet diese Aktionen auf Anfragen an, bevor sie von Ihren API-Proxys verarbeitet werden. So kann beispielsweise ein IP-Bereich oder ein bestimmter Client, der ein „Brute-Force-Versuch“ ausführt, erkannt und dann blockiert oder gemeldet werden.

Bedrohungserkennung mit Advanced API Ops Monitoring

Mit einer Traffic-Benachrichtigung können Sie eine Benachrichtigung erhalten, wenn sich der Traffic für eine Umgebung, einen Proxy oder eine Region innerhalb eines bestimmten Zeitraums um einen bestimmten Prozentsatz ändert. Mit dieser Funktion kann dynamisch eine Warnung ausgegeben werden, wenn der Traffic deutlich vom erwarteten Durchsatz abweicht, wie es bei einem DDoS-Angriff der Fall wäre. Diese Benachrichtigungen können ganz einfach an eine Logging- und Monitoring-Lösung eines Drittanbieters gesendet werden.

API5:2019 Fehlerhafte Autorisierung auf Funktionsebene

Beschreibung der Bedrohung

Diese Bedrohung ist eine Variante von API1 und stellt auch eine Autorisierungslücke dar. Bei dieser Bedrohung kann ein Angreifer Aktionen ausführen, indem er Anfragen an Funktionen sendet, auf die er keinen Zugriff hat. Ein Angreifer kann beispielsweise Daten ändern oder löschen, für die er nur Leseberechtigungen hat, wenn ein API-Endpunkt das HTTP-Anfrageverb nicht validiert, indem er ein GET durch ein PUT oder DELETE ersetzt. Wenn Sie keine ausreichend restriktiven Zugriffssteuerungen für den URI-Pfad einer API-Ressource implementieren, kann ein API-Endpunkt einem Angreifer ermöglichen, die Daten eines anderen Nutzers einzusehen, indem er einfach den Pfad in einer Anfrage ändert.

Diese Art von Bedrohung unterstreicht den Wert der Verwendung von Apigee als Vermittlungs- und Abstraktionsschicht, da viele Backend-Systeme, die nicht für den öffentlichen Zugriff konzipiert sind, standardmäßig einen einzelnen Endpunkt für die Ausführung mehrerer Funktionen der Geschäftslogik bereitstellen, einschließlich administrativer Funktionen mit hohem Risiko.

Die Konzepte zur Verringerung der Wahrscheinlichkeit dieser Bedrohung werden in der Regel in folgende Bereiche unterteilt:

  • Was wird geschützt? Überlegen Sie sich Ihre API-Produktstrategie und implementieren Sie eine logische Segmentierung der Funktionen, wenn Sie die Pfade und Ressourcen entwerfen, die von Apigee API-Proxys, ‑Produkten und ‑App-Funktionen freigegeben werden. Dabei sollten Sie RESTful Best Practices beachten.
  • Wer greift auf Ihre API-Ressourcen zu? Definieren Sie die übergeordneten Personas und implementieren Sie Standardzugriffsberechtigungen mit den Authentifizierungs- und Autorisierungsfunktionen von Apigee, wie in API1 und API2 beschrieben.
  • Wie werden Ihre Zugriffsrichtlinien durchgesetzt? Verwenden Sie bedingte Ablaufsschritte und Fehler, um den URL-Pfad und das Verb aller API-Anfragen zu validieren.

Abbildung: Dieses Diagramm zeigt, wie die Autorisierung auf Funktionsebene in Apigee erzwungen wird, indem Bereiche in einem Zugriffstoken als Berechtigungen verwendet werden.

Logische Segmentierung mit API-Proxys, ‑Produkten und ‑Apps

Apigee bietet ein äußerst flexibles Toolkit zur logischen Segmentierung von API-Ressourcen, mit dem API-Proxys in beliebig viele API-Produkte gebündelt werden können. Diese werden wiederum von Ihren App-Entwicklern verwendet, die Apps registrieren können, die Ihre API-Produkte nutzen. Zugriffsrichtlinien können auf jeder dieser Ebenen definiert werden.

Für eine effektive funktionale Autorisierung und Segmentierung ist es jedoch wichtig, eine API-Produktstrategie zu definieren. Ein Teil dieses wichtigen und fortlaufenden Prozesses besteht darin, das „Wer“ und „Was“ Ihrer API-Produkte zu definieren. Dazu betrachten Sie Ihre API-Ressourcen aus der Perspektive Ihrer Kunden und Entwickler und legen dann genau fest, welche Arten von Anfragen auf Pfadressourcen- und HTTP-Verbebene zulässig sind.

Abbildung: Die in einem API-Produkt gebündelten API-Ressourcen können aus einer oder mehreren APIs stammen. Sie können also Ressourcen kombinieren, um Nutzungsstufen und Autorisierungsgrenzen zu erstellen.

Zugriffssteuerung auf Funktionsebene mit OAuth-Bereichen und JWT-Ansprüchen

Die oben für API1:2019 Broken object authorization beschriebenen Autorisierungsansätze befassen sich mit der detaillierten Zugriffssteuerung auf Objektebene. Es ist jedoch genauso wichtig, die grobkörnige Zugriffssteuerung auf Funktionsebene zu berücksichtigen. Ist der anfragende Nutzer überhaupt berechtigt, diesen URL-Pfad anzufordern? Diese Art von Richtlinie wird häufig pro User Persona definiert (Kunde, Mitarbeiter, Administrator, interner oder externer Entwickler).

Um das Risiko einer Fehlkonfiguration zu verringern, empfehlen wir dir, mit deinem Sicherheitsteam zusammenzuarbeiten, damit die Behauptungen über den anfragenden Nutzer im Zugriffstoken enthalten sind, entweder mithilfe von OAuth-Bereichen oder JWT-Ansprüchen.

Anfragevalidierung mit bedingten Abläufen

Ein REST API-Aufruf besteht aus folgenden Elementen:

  • Einen Endpunkt
  • Eine Ressource
  • Ein Verb der Handlung
  • Eine beliebige Anzahl zusätzlicher Anfrageattribute, z. B. Abfrageparameter

Die in dieser Bedrohung beschriebene Art von Angriff wird in der Regel durch die unzureichende Filterung einer API-Anfrage verursacht, wodurch ein Angreifer unbefugte Aktionen ausführen oder auf eine geschützte Ressource zugreifen kann. Zusätzlich zur bedingten Logik, mit der Sie Anfragen anhand von Zugriffstokens oder Ansprüchen filtern können, ermöglicht Apigee die Implementierung einer Filterlogik, die auf der Anfrage selbst basiert.

Sobald Sie die Geschäftslogik eines API-Produkts klar verstanden und definiert haben, welche Funktionen von Ihren APIs zulässig sind, besteht der nächste Schritt darin, alle Anfragen, die nicht in diesen Bereich fallen, mithilfe der folgenden Apigee-Produktfunktionen einzuschränken:

  • Bedingte Logik und RaiseFault-Richtlinien, um Ressourcenpfade oder Verben in jedem Schritt einer Proxy-Ablaufkonfiguration einzuschränken
  • JSON- und XML-Bedrohungsschutzrichtlinien zum Schutz vor inhaltsbasierten Angriffen mit fehlerhaften JSON- oder XML-Nutzlastanfragen

API6:2019 – Massenzuweisung

Beschreibung der Bedrohung

Wenn nicht gefilterte Daten über APIs an Client-Apps bereitgestellt werden, können Angreifer Objekteigenschaften über Anfragen erraten oder Endpunktbenennungskonventionen als Hinweise darauf verwenden, wo nicht autorisierte Änderungen oder Zugriffe auf Eigenschaften von im Backend gespeicherten Datenobjekten vorgenommen werden können.

Diese Bedrohung entsteht, wenn ungefilterte Daten (in der Regel in JSON oder XML) an einen Client gesendet werden. So kann ein Angreifer die zugrunde liegenden Implementierungsdetails Ihrer Backend-Systeme sowie die Property-Namen vertraulicher Datenelemente erraten. Diese Art von Angriff kann einem Angreifer möglicherweise die Möglichkeit geben, unangemessene Daten zu lesen oder zu manipulieren. Im schlimmsten Fall können Sicherheitslücken für die Remote-Codeausführung ermöglicht werden.

Es gibt in der Regel zwei Aspekte, die diese Art von Bedrohung ermöglichen:

  • Die Perspektive des API-Designs Verwende niemals die Anwendungslogik für die clientseitige Datenfilterung, da Apps von Angreifern ausgenutzt werden können und als vertrauenswürdig eingestuft werden. Entwerfen Sie Ihr API-Datenschema immer so, dass nur die minimal erforderlichen Daten für die Aktivierung eines API-Dienstes freigegeben werden.
  • Die Perspektive der API-Implementierung. Datenfilterung und Schemavalidierung implementieren, um die unbeabsichtigte Offenlegung vertraulicher Daten an eine Clientanwendung zu verhindern

Aus Sicht von Apigee-Produkten bieten wir mehrere nützliche Funktionen, um eine robuste Datenfilterung für Ihre APIs zu ermöglichen.

Filterrichtlinie für OpenAPI-Spezifikationen

Mit der OASValidation-Richtlinie (OpenAPI-Spezifikation) können Sie eine eingehende Anfrage oder Antwortnachricht mit einer OpenAPI 3.0-Spezifikation (JSON oder YAML) prüfen. Diese Richtlinie ermöglicht Folgendes:

  1. API entwerfen – OpenAPI-Spezifikation (OAS) erstellen
  2. Implementieren Sie die erforderliche Vermittlungs-, Sicherheits- und Caching-Logik, um ein API-Produkt aus Ihrem Backend mit Apigee sicher bereitzustellen.
  3. Prüft eingehende Anfragen anhand des in Ihrer OAS-Spezifikation definierten Datenschemas, einschließlich Basepath, Verb, Request Message Policy und Parameters.

SOAPMessageValidation-Richtlinie

Mit der SOAPMessageValidation-Richtlinie können Sie XML-basierte Anfragen validieren, indem Sie entweder eine XML-Nachricht anhand eines XSD-Schemas oder eine SOAP-Nachricht anhand einer WSDL-Definition validieren. Außerdem können Sie mit der MessageValidation-Richtlinie überprüfen, ob die Nutzlast einer JSON- oder XML-Nachricht wohlgeformt ist. Dazu wird in einer XML- oder JSON-Nachricht Folgendes geprüft:

  • Es gibt ein einziges Stammelement.
  • Der Inhalt enthält keine unzulässigen Zeichen.
  • Objekte und Tags sind ordnungsgemäß verschachtelt.
  • Start- und End-Tags stimmen überein.

API7:2019 Sicherheitsfehlkonfiguration

Beschreibung der Bedrohung

Sicherheitsfehlkonfigurationen sind häufig auf unsichere Standardkonfigurationen, unvollständige oder Ad-hoc-Konfigurationen, offenen Cloud-Speicher, falsch konfigurierte HTTP-Header, unnötige HTTP-Methoden, eine permissive CORS-Nutzung (Cross-Origin Resource Sharing) und ausführliche Fehlermeldungen mit vertraulichen Informationen zurückzuführen. Angreifer versuchen oft, nicht gepatchte Sicherheitslücken, gängige Endpunkte oder ungeschützte Dateien und Verzeichnisse zu finden, um unbefugten Zugriff auf das System zu erhalten oder Informationen über das System zu erhalten, das sie angreifen möchten. Sicherheitsfehler können nicht nur sensible Nutzerdaten, sondern auch Systemdetails offenlegen, die zu einer vollständigen Serverkompromittierung führen können. Weitere Anwendungsfälle für Sicherheitslücken aufgrund von Fehlkonfigurationen:

  • Falsch konfiguriertes TLS
  • Fehlermeldungen mit Stack-Traces
  • Nicht gepatchte Systeme
  • Sichtbare Steuerfelder für die Speicher- oder Serververwaltung

Es gibt verschiedene Schritte, die Organisationen unternehmen können, um die Herausforderungen im Zusammenhang mit Sicherheitskonfigurationsfehlern anzugehen und zu minimieren. Dazu gehören:

  1. Härtungs- und Patchprozesse einrichten und standardisieren
  2. Governance für das API-Ökosystem entwickeln
  3. Administratorzugriff einschränken und Prüfungen und Benachrichtigungen aktivieren

Freigegebene Abläufe und Ablauf-Hooks

Apigee unterstützt das Konzept eines freigegebenen Ablaufs, mit dem API-Entwickler Richtlinien und Ressourcen in einer wiederverwendbaren Gruppe kombinieren können. Durch die Erfassung wiederverwendbarer Funktionen an einem zentralen Ort kann ein freigegebener Ablauf für Konsistenz sorgen, die Entwicklungszeit verkürzen und Code einfacher verwalten. Sie können einen freigegebenen Ablauf in einzelne API-Proxys einfügen. Sie können auch einen Schritt weiter gehen und freigegebene Abläufe in Ablauf-Hooks platzieren, um die Logik des freigegebenen Ablaufs automatisch für jeden API-Proxy auszuführen, der in derselben Umgebung wie der freigegebene Ablauf bereitgestellt wird.

API-Sicherheitsberichte

Wenn Unternehmen ein Governance-Framework entwickeln möchten, bietet Apigee Funktionen für API-Sicherheitsberichte, die den Betriebsteams die nötige Transparenz bei den Sicherheitsattributen von APIs bieten, um:

  • Einhaltung von Sicherheitsrichtlinien und Konfigurationsanforderungen
  • Vertrauliche Daten vor internem und externem Missbrauch schützen
  • Sicherheitsvorfälle proaktiv erkennen, diagnostizieren und beheben

Die Apigee-Sicherheitsberichte bieten Betriebsteams detaillierte Informationen, um die Einhaltung von Richtlinien und Konfigurationsanforderungen sicherzustellen, APIs vor internem und externem Missbrauch zu schützen und Sicherheitsvorfälle schnell zu erkennen und zu beheben.

Mit Sicherheitsberichten können Sicherheitsadministratoren schnell nachvollziehen, wie Ihre API-Proxys für die Sicherheit konfiguriert sind, und die Laufzeitbedingungen ermitteln, die sich auf die Proxysicherheit auswirken können. Anhand dieser Informationen können Sie die Konfiguration so anpassen, dass für jeden Proxy die richtige Sicherheitsstufe festgelegt ist.

API-Monitoring

Apigee bietet eine umfassende API-Monitoring-Plattform, die die Funktionen für Sicherheitsberichte ergänzt. Mit API-Monitoring können Organisationen API-Traffic- und Leistungsprobleme proaktiv erkennen. Apigee API-Monitoring arbeitet mit Apigee Edge for Public Cloud zusammen, um in Echtzeit kontextbezogene Einblicke in die API-Leistung zu erhalten, Probleme schnell zu diagnostizieren und Maßnahmen für die Geschäftskontinuität zu erleichtern.

Abbildung: Das Apigee API-Monitoring bietet eine breite Palette von Tools, mit denen Probleme überwacht, untersucht und behoben werden können. Dabei werden die erstklassigen KI-Funktionen der Google Cloud Platform genutzt.

Apigee Sense

Apigee Sense hilft, die APIs vor unerwünschtem Anfragetraffic zu schützen, einschließlich Angriffen durch böswillige Clients. Apigee Sense analysiert den API-Anfragetraffic und identifiziert Muster, die auf unerwünschte Anfragen hinweisen könnten.

Mithilfe dieser Analyse können Organisationen Clients ermitteln, die unerwünschte Anfragen stellen, und dann Maßnahmen ergreifen, um diese Anfragen zuzulassen, zu blockieren oder zu melden. Mit Apigee Sense können die APIs vor Anfragemustern geschützt werden, darunter:

  • Automatisiertes Verhalten, das sich in menschliches Verhalten einfügt
  • Wiederholte Versuche von derselben IP-Adresse
  • Ungewöhnliche Fehlerraten
  • Verdächtige Clientanfragen
  • Daten-Crawling
  • Key Harvesting
  • Aktivitätsspitzen
  • Geografische Muster

API8:2019 Injection

Beschreibung der Bedrohung

Die nicht vertrauenswürdige Einschleusung von Daten wie SQL, NoSQL, XML-Parsern, ORM, LDAP, Betriebssystembefehlen und JavaScript in API-Anfragen kann zur Ausführung unbeabsichtigter Befehle oder zum unbefugten Datenzugriff führen. Angreifer schleusen über alle verfügbaren Injection-Vektoren (z. B. direkte Eingabe, Parameter, integrierte Dienste) schädliche Daten in die API ein, in der Erwartung, dass sie an einen Interpreter gesendet werden. Angreifer können diese Fehler leicht finden, wenn sie den Quellcode mithilfe von Sicherheitsscannern und Fuzzern prüfen. Eine erfolgreiche Injection kann zur Offenlegung von Informationen führen, was die Vertraulichkeit beeinträchtigt und zu Datenverlusten führt. In einigen Fällen kann sie auch zu einem DoS-Angriff führen.

Best Practices zur Minimierung von Injection-Fehlern/-Angriffen umfassen die strikte Definition der Eingabedaten wie Schemas, Typen, Stringmuster, die Durchführung von Eingabevalidierungen, Grenzwertprüfungen und die Erzwingung dieser bei Laufzeit. Auf der Apigee-Plattform können die eingehenden Daten mithilfe von Filtern validiert werden, um nur gültige Werte für jeden Eingabeparameter zuzulassen.

Apigee Edge, das als Server für eingehende API-Anfragen fungiert, prüft, ob die Nutzlaststruktur in einen akzeptablen Bereich fällt. Diese Prüfung wird auch als Grenzwertprüfung bezeichnet. Sie können einen API-Proxy so konfigurieren, dass die Eingabevalidierungsroutine die Eingabe transformiert, um riskante Zeichensequenzen zu entfernen und sie dann durch sichere Werte zu ersetzen.

Regular Expression Protection-Richtlinie

Die Richtlinie RegularExpressionProtection extrahiert Informationen aus einer Nachricht (z. B. URI-Pfad, Abfrageparameter, Header, Formularparameter, Variable, XML-Nutzlast oder JSON-Nutzlast) und wertet diesen Inhalt anhand von vordefinierten regulären Ausdrücken aus. Wenn einer der angegebenen regulären Ausdrücke als „wahr“ ausgewertet wird, wird die Nachricht als Bedrohung eingestuft und abgelehnt. Ein regulärer Ausdruck, kurz Regex, ist eine Reihe von Strings, die ein Muster in einem String angeben. Mit regulären Ausdrücken können Inhalte programmatisch nach Mustern ausgewertet werden. Mit regulären Ausdrücken lässt sich beispielsweise eine E-Mail-Adresse auf ihre korrekte Struktur prüfen.

Die häufigste Verwendung von RegularExpressionProtection ist die Auswertung von JSON- und XML-Nutzlasten auf schädliche Inhalte.

Kein regulärer Ausdruck kann alle inhaltsbasierten Angriffe eliminieren und mehrere Mechanismen sollten zu einem umfassenden Schutz kombiniert werden. In diesem Abschnitt werden einige empfohlene Muster zum Verhindern des Zugriffs auf Inhalte beschrieben.

Es gibt noch weitere Ansätze zur Validierung von Eingaben mit der Apigee-Plattform:

Inhaltstypen validieren

Der Inhaltstyp bezieht sich auf den Inhalt einer Datei, die über HTTP übertragen und nach einer zweiteiligen Struktur klassifiziert wird. Apigee empfiehlt, die Inhaltstypen für die Anfrage und Antwort mithilfe der unten beschriebenen bedingten Logik zu validieren.

API-Sicherheitsberichte

Wenn Unternehmen ein Governance-Framework entwickeln möchten, bietet Apigee Funktionen für API-Sicherheitsberichte, die den Betriebsteams die nötige Transparenz für die Sicherheit von APIs bieten. So können sie die Sicherheitsattribute von APIs nutzen, um:

  • Sicherheitsrichtlinien und Konfigurationsanforderungen einhalten
  • Schutz sensibler Daten vor internem und externem Missbrauch
  • Sicherheitsvorfälle proaktiv erkennen, diagnostizieren und beheben

API9:2019 Unzureichende Asset-Verwaltung

Beschreibung der Bedrohung

Eine unzureichende Umgebungsverwaltung und -trennung ermöglicht es Angreifern, auf nicht ausreichend gesicherte API-Endpunkte zuzugreifen. Fehlende Governance-Sicherheitsmaßnahmen führen auch dazu, dass nicht mehr unterstützte Ressourcen unnötig gefährdet werden.

Diese Bedrohung kann mit den ausgereiften Funktionen von Apigee bewältigt werden, um den gesamten API-Lebenszyklus zu verwalten. So können Sie ein umfassendes Governance-Modell erstellen, das die Zusammenarbeit zwischen Teams ermöglicht und gleichzeitig eine Trennung der Verantwortlichkeiten zwischen Sicherheitsinteressengruppen und API-Entwicklern vornimmt. Begrenzungen und Steuerelemente können mit folgenden Tools konfiguriert und verwaltet werden:

Organisationen, Umgebungen und Versionen: Virtuelle und physische Schutzmaßnahmen, die durch Laufzeitkontexte eine Isolierung und einen sicheren Release-Prozess gewährleisten.

Rollenbasierte Zugriffssteuerung: Nur die erforderlichen Personen in Ihren API-Teams haben Berechtigungen zum Verwalten von Konfigurationsänderungen und des Prozess zur Umstellung.

Zielgruppenverwaltung für API-Dokumentation: Nachdem eine API im Entwicklerportal veröffentlicht wurde, können Sie die Sichtbarkeit der Dokumentation einschränken, indem Sie Zielgruppen verwalten.

Ablauf-Hooks: Sie können globale Richtlinien und Muster erzwingen, die als privilegierte Sicherheitsmaßnahmen verwaltet werden können und von API-Entwicklern nicht geändert werden können.

Sicherheitsberichte: Sicherheitsverantwortliche haben eine End-to-End-Sichtbarkeit der veröffentlichten APIs und ihrer unterstützenden Konfiguration. Die Einhaltung globaler Sicherheitsrichtlinien kann anhand des Risikoprofils für jeden veröffentlichten API-Endpunkt geprüft und bewertet werden.

Organisationen und Umgebungen

Konfigurationsartefakte, Nutzer und Funktionen in Apigee können auf bestimmte Organisationen und/oder Umgebungen beschränkt werden. Das bedeutet, dass die Plattform vordefinierte Sicherheitsmaßnahmen bietet, die um APIs und ihre unterstützende Konfiguration gelegt werden können.

Organisationen: Eine Organisation ist der übergeordnete Tenant in Apigee. Sie ermöglicht eine vollständige Trennung von Traffic, Konfiguration und Nutzern. Als Best Practice für die Governance sollten Sie separate Produktions- und Nicht-Produktionsorganisationen haben. So wird effektiv verhindert, dass Produktionsdaten, Nutzer und Traffic mit niedrigeren Umgebungen vermischt werden.

Umgebungen: APIs in Apigee können über mehrere Bereitstellungsstatus befördert werden. Jeder Status ist mit einem Ausführungskontext verknüpft. Der Umgebungskontext wird während des Beförderungsprozesses nicht übertragen, sodass sensible Konfigurationen nicht für Nutzer ohne Berechtigungen freigegeben werden.

Überarbeitungen: Mit Überarbeitungen können APIs und einzelne Funktionen nahtlos in verschiedenen Umgebungen bereitgestellt werden.

Rollenbasierte Zugriffssteuerung

Um API9 zu minimieren, ist es unerlässlich, die Aufgaben von Sicherheits-Stakeholdern und API-Entwicklern klar zu definieren und zu trennen. Wie bereits in diesem Dokument erwähnt, bietet Apigee flexible Funktionen für die rollenbasierte Zugriffssteuerung, mit denen Sie benutzerdefinierten Rollen Berechtigungen zuweisen können. Für diese spezifische Bedrohung können Rollen mit eingeschränkten Berechtigungen pro Organisation, Umgebung oder mit detaillierteren Konfigurationsberechtigungen versehen werden. Beschränken Sie Berechtigungen, um den Bereitstellungsstatus von APIs über Umgebungen zu ändern, und achten Sie darauf, dass Entwickler nicht auf globale Sicherheitsbibliotheken (Flow Hooks) zugreifen oder diese ändern können. Diese eingeschränkten Rollen verhindern unbefugte Änderungen an globalen Sicherheitsrichtlinien, die sowohl für alte als auch für aktuelle veröffentlichte Endpunkte gelten.

Zielgruppenverwaltung für API-Dokumentation

Ein Entwicklerportal ist eine wichtige Komponente für den Erfolg Ihrer API-Strategie. Es ermöglicht Ihnen, ein umfassendes Inventar aller Dokumentationen zu Ihren APIs zu führen, einschließlich Hosts/Endpunkte, Ressourcen, Vorgänge, Nutzlastschemata und mehr. In Apigee können Sie Ihre APIs mithilfe von API-Produktkonstrukten gruppieren. API-Produkte werden durch Bündel von Ressourcen und Vorgängen definiert, die in denselben Geschäfts- und Sicherheitskontext fallen (z.B. Serviceplan, Geschäftsdomain, Kategorie, Unternehmenshierarchie usw.).

Mit dem integrierten Entwicklerportal von Apigee können Sie API-Produkte veröffentlichen und die Sichtbarkeit veröffentlichter Inhalte einschränken, indem Sie Zielgruppen verwalten. Diese Funktion entspricht einer Inhaltssegmentierungsstrategie, die den Geschäfts- und Sicherheitsanforderungen entspricht.

Ablauf-Hooks

Die Prozesse zur Bewerbung und Veröffentlichung von APIs müssen immer Sicherheitsanforderungen und Zertifizierungsverfahren umfassen. Um effektiv zu sein, sollten API-Teams mit den entsprechenden Tools in der Lage sein, Leitlinien zu erstellen, die die Trennung der Verantwortlichkeiten gewährleisten und gleichzeitig agile Release-Zyklen beibehalten.

Mit Apigee können Sie die Aufgaben der Sicherheitsverwaltung optimieren, indem Sie globale Richtlinien über Flow Hooks erzwingen. Diese globalen Richtlinien können als privilegierte Sicherheitsmaßnahmen verwaltet werden, die von API-Entwicklern nicht geändert werden können. So wird die Trennung der Verantwortlichkeiten gewährleistet und die Agilität gefördert, indem die Standardsicherheit angewendet und damit die Einhaltung der Sicherheitsanforderungen für alle APIs in einer bestimmten Ausführungsumgebung sichergestellt wird.

Abbildung: Berechtigungsgrenzwerte können in Apigee über Ablauf-Hooks und freigegebene Abläufe konfiguriert werden. Sicherheitsverantwortliche sind für die Einhaltung sicherheitsbezogener globaler Richtlinien verantwortlich. Diese Funktionen sorgen für eine Trennung der Verantwortlichkeiten und fördern agile Entwicklungszyklen.

Security Reporting

Sicherheitsaudits sollen die Sicherheitsrichtlinien bewerten und testen, die zum Schutz der Daten und Geschäftsziele Ihres Unternehmens dienen. APIs sind standardisierte öffentliche oder private Schnittstellen, die durch ein umfassendes und gleichzeitig überprüfbares Sicherheitsgovernance-Modell geschützt werden müssen.

In Apigee haben Sie Zugriff auf spezielle Sicherheitsberichte, mit denen Sie die Einhaltung der definierten Richtlinien sicherstellen und Ihre Sicherheitsteams auf der Grundlage umfassender Informationen zu folgenden Themen Maßnahmen ergreifen können:

Laufzeit-Traffic: Hier finden Sie Statistiken zum API-Traffic, z. B. zu Zielservern, virtuellen Hosts, TLS-Konfiguration und Traffic-Änderungen pro Umgebung.

Konfiguration: Auditfunktion für die Konfiguration von API-Proxys, die eine End-to-End-Sichtbarkeit aller Richtlinien bietet, die auf API-Proxy-Ebene erzwungen werden, sowie das Durchsetzungsspektrum freigegebener Abläufe, die auf Organisations- oder Proxyebene angehängt sind.

Nutzeraktivitäten: Sie können sensible Vorgänge von Plattformnutzern erfassen. Analysieren Sie verdächtige Aktivitäten, indem Sie eine Aufschlüsselung vornehmen.

API10:2019 Unzureichendes Logging und Monitoring

Beschreibung der Bedrohung

Unzureichende Protokollierung, Überwachung und Benachrichtigungen können dazu führen, dass laufende Angriffe nicht erkannt werden. Daher sollte eine Strategie erforderlich sein, um Informationen zu kritischen Ereignissen zu erhalten, die sich auf Ihr Unternehmen auswirken.

Bei der Verwaltung von Ereignissen und Protokollen für APIs sollten die folgenden Best Practices berücksichtigt werden:

  • Richtlinie zur Protokollverwaltung: Regeln dokumentieren und erzwingen, um die Detaillierung, die Ebenen, die Integrität und das zentrale Repository von Protokollen zu standardisieren und zu steuern
  • Richtlinie zur Ereignisverwaltung: Jedes Ereignis muss bis zu seiner Quelle zurückverfolgt werden können. Außerdem sollten Ereignisse nach Wichtigkeit und Geschäftsauswirkung kategorisiert werden können.
  • Berichte und Audits: Sicherheits- und Betriebsmitarbeiter sollten in der Lage sein, in Echtzeit auf Protokolle und Ereignisse zuzugreifen und darauf zu reagieren. Darüber hinaus können Stakeholder Verstärkungszyklen durchführen, um Erkennungsmuster anhand von Verlaufsdaten anzupassen.

Apigee bietet die erforderlichen Tools, um eine umfassende Strategie für die Ereignis- und Protokollverwaltung zu erstellen. beispielsweise:

Richtlinie für die Nachrichtenprotokollierung: Erstellen Sie Logstreams basierend auf Traffic-Daten oder ‑Metadaten aus Ihrem API-Traffic. Sie können die Detaillierung des Streams mithilfe bedingter Logik und Nachrichtenvorlagen festlegen.

Cloud Operations Suite von Google: Sie können die integrierte Einbindung in hoch skalierbare Monitoring- und Logging-Tools von Google nutzen.

Service Callout-Richtlinie: Hiermit wird die Unterstützung für Protokollstreams hinzugefügt, für die HTTP-Endpunkte zum Senden von Ereignissen erforderlich sind.

Analytics: Sie können über vordefinierte und/oder benutzerdefinierte Berichte auf Verlaufsmetadaten zu Zugriffen zugreifen und diese analysieren. Sie können Benachrichtigungen basierend auf Trends erstellen und verwalten sowie Trafficanomalien analysieren.

API-Monitoring: Wie bereits beschrieben, bietet dieses Tool Benachrichtigungsfunktionen, die bei kritischen Ereignissen ausgelöst werden können. Diese Protokolle können weiter analysiert und entsprechend bearbeitet werden.