Empfehlungen, um die wichtigsten 10 Bedrohungen laut OWASP API Security mithilfe von API Management zu entschärfen

  • Artikel

GILT FÜR: Alle API Management-Ebenen

Die Open Web Application Security Project (OWASP)-Foundation arbeitet daran, die Softwaresicherheit durch ihre communitygeführten Open Source-Softwareprojekte, Hunderte von Kapiteln weltweit, Zehntausende Mitglieder und durch das Hosten lokaler und globaler Konferenzen zu verbessern.

Das API Security Project von OWASP konzentriert sich auf Strategien und Lösungen, um die einzigartigen Sicherheitslücken und -risiken von APIs zu verstehen und zu entschärfen. In diesem Artikel werden Empfehlungen zur Verwendung von Azure API Management erläutert, um die von OWASP identifizierten wichtigsten 10 API-Bedrohungen zu entschärfen.

Hinweis

Zusätzlich zu den Empfehlungen in diesem Artikel können Sie Defender for APIs, eine Funktion von Microsoft Defender for Cloud um Erkenntnisse zur API-Sicherheit, Empfehlungen und Bedrohungserkennungen zu erhalten. Weitere Informationen zur Verwendung von Defender for APIs mit API Management

Fehlerhafte Autorisierung auf Objektebene (Broken Object Level Authorization)

API-Objekte, die nicht mit der entsprechenden Autorisierungsebene geschützt sind, können für Datenlecks und unbefugte Datenmanipulation durch schwache Objektzugriffsbezeichner anfällig sein. Ein Angreifer könnte beispielsweise einen ganzzahligen Objektbezeichner ausnutzen, der iteriert werden kann.

Weitere Informationen zu dieser Bedrohung: API1:2019 Broken Object Level Authorization (Fehlerhafte Autorisierung auf Objektebene)

Empfehlungen

  • Der beste Ort zum Implementieren von Autorisierung auf Objektebene ist in der Back-End-API selbst. Im Back-End können die richtigen Autorisierungsentscheidungen auf Anforderungsebene (oder Objektebene) getroffen werden, sofern zutreffend, mithilfe einer Logik, die auf die Domäne und API anwendbar ist. Erwägen Sie Szenarien, in denen eine bestimmte Anforderung je nach Berechtigungen und Autorisierung des Anfordernden unterschiedliche Detailebenen in der Antwort liefern kann.

  • Wenn eine aktuelle anfällige API nicht im Back-End geändert werden kann, könnte API Management als Fallback verwendet werden. Beispiel:

    • Verwenden Sie eine benutzerdefinierte Richtlinie, um die Autorisierung auf Objektebene zu implementieren, wenn sie nicht im Back-End implementiert ist.

    • Implementieren Sie eine benutzerdefinierte Richtlinie, um Bezeichner von der Anforderung zum Back-End zuzuordnen und vom Back-End zum Client, sodass interne Bezeichner nicht verfügbar gemacht werden.

      In diesen Fällen kann es sich bei der benutzerdefinierten Richtlinie um einen Richtlinienausdruck mit einem Lookup (z. B. einem Wörterbuch) oder um die Integration in einen anderen Dienst über die Anforderung senden-Richtlinie (send-request) handeln.

  • Erzwingen Sie für GraphQL-Szenarien die Autorisierung auf Objektebene über die GraphQL-Anforderung überprüfen-Richtlinie mithilfe des authorize-Elements.

Fehlerhafte Benutzerauthentifizierung

Authentifizierungsmechanismen werden häufig falsch oder gar nicht implementiert, was es Angreifern erlaubt, Implementierungsfehler auszunutzen, um auf Daten zuzugreifen.

Weitere Informationen zu dieser Bedrohung: API2:2019 Broken User Authentication (Fehlerhafte Benutzerauthentifizierung)

Empfehlungen

Verwenden Sie API Management für die Benutzerauthentifizierung und -autorisierung:

  • Authentifizierung: API Management unterstützt die folgenden Authentifizierungsmethoden:

    • Standardauthentifizierungsrichtlinie: Anmeldeinformationen mit Benutzername und Kennwort.

    • Abonnementschlüssel: Ein Abonnementschlüssel bietet eine ähnliche Sicherheitsstufe wie die Standardauthentifizierung und ist möglicherweise alleine nicht ausreichend. Wenn der Abonnementschlüssel kompromittiert wird, erhält ein Angreifer möglicherweise unbegrenzten Zugriff auf das System.

    • Clientzertifikatrichtlinie: Die Verwendung von Clientzertifikaten ist sicherer als Standardanmeldeinformationen oder Abonnementschlüssel, ermöglicht aber nicht die Flexibilität, die von tokenbasierten Autorisierungsprotokollen wie OAuth 2.0 bereitgestellt wird.

  • Autorisierung: API Management unterstützt eine JWT überprüfen-Richtlinie, um die Gültigkeit eines eingehenden OAuth 2.0 JWT-Zugriffstokens basierend auf Informationen zu überprüfen, die vom Metadatenendpunkt des OAuth-Identitätsanbieters abgerufen wurden. Konfigurieren Sie die Richtlinie, um relevante Tokenansprüche, die Zielgruppe und die Ablaufzeit zu überprüfen. Weitere Informationen zum Schutz einer API mit OAuth 2.0 Autorisierung und Microsoft Entra ID.

Weitere Empfehlungen:

  • Verwenden Sie Richtlinien in der API-Verwaltung, um die Sicherheit zu erhöhen. Das Beschränken der Aufrufrate bremst beispielsweise böswillige Akteure aus, die Brute-Force-Angriffe nutzen, um Anmeldeinformationen zu kompromittieren.

  • APIs sollten TLS/SSL (Transportsicherheit) verwenden, um die Anmeldeinformationen oder Token zu schützen. Anmeldeinformationen und Token sollten in Anforderungsheadern und nicht als Abfrageparameter gesendet werden.

  • Konfigurieren Sie im Entwicklerportal der API-Verwaltung Microsoft Entra ID oder Azure Active Directory B2C als Identitätsanbieter, um die Kontosicherheit zu erhöhen. Das Entwicklerportal verwendet CAPTCHA, um Brute-Force-Angriffe zu entschärfen.

Übermäßige Offenlegung von Daten

Ein gutes API-Schnittstellendesign ist eine trügerische Herausforderung. Häufig enthalten die Anforderungs- und Antwortschnittstellen, insbesondere bei Legacy-APIs, die sich im Laufe der Zeit entwickelt haben, mehr Datenfelder als die nutzenden Anwendungen benötigen.

Ein böswilliger Akteur könnte versuchen, direkt auf die API zuzugreifen (vielleicht durch Wiedergeben einer gültigen Anforderung) oder den Datenverkehr zwischen Server und API abzuhören („sniffing“). Die Analyse der API-Aktionen und der verfügbaren Daten könnte dem Angreifer vertrauliche Daten liefern, die nicht in der Front-End-Anwendung verfügbar gemacht oder verwendet werden.

Weitere Informationen zu dieser Bedrohung: API3:2019 Excessive Data Exposure (Übermäßige Offenlegung von Daten)

Empfehlungen

  • Der beste Ansatz zur Entschärfung dieser Sicherheitsanfälligkeit besteht darin, sicherzustellen, dass die in der Back-End-API definierten externen Schnittstellen sorgfältig und idealerweise unabhängig von der Datenpersistenz entwickelt werden. Sie sollten nur die Felder enthalten, die von Consumern der API benötigt werden. APIs sollten häufig überprüft und ältere Felder als veraltet markiert und dann entfernt werden.

    Verwenden Sie in API Management:

    • Revisionen (Überarbeitungen), um Änderungen, die keine Breaking Changes sind, zu steuern, z. B. das Hinzufügen eines Felds zu einer Schnittstelle. Sie können Revisionen zusammen mit einer Versionsverwaltungsimplementierung im Back-End verwenden.

    • Versionen für Breaking Changes, z. B. das Entfernen eines Felds aus einer Schnittstelle.

  • Wenn es nicht möglich ist, das Design der Back-End-Schnittstelle zu ändern, und übermäßige Daten ein Problem darstellen, verwenden Sie API Management-Transformationsrichtlinien, um Antwortnutzlasten erneut zu generieren und Daten zu maskieren oder zu filtern. Entfernen Sie beispielsweise nicht benötigte JSON-Eigenschaften aus einem Antworttext.

  • Die Antwortinhaltsüberprüfung in API Management kann mit einem XML- oder JSON-Schema verwendet werden, um Antworten mit nicht dokumentierten Eigenschaften oder ungeeigneten Werten zu blockieren. Die Richtlinie unterstützt außerdem das Blockieren von Antworten, die eine festgelegte Größe überschreiten.

  • Verwenden Sie die Statuscode überprüfen-Richtlinie zum Blockieren von Antworten mit Fehlern, die im API-Schema nicht definiert sind.

  • Verwenden Sie die Header überprüfen-Richtlinie, um Antworten mit Headern zu blockieren, die im Schema nicht definiert sind oder die nicht der Definition im Schema entsprechen. Entfernen Sie unerwünschte Header mit der Header festlegen-Richtlinie.

  • Verwenden Sie für GraphQL-Szenarien die GraphQL-Anforderung überprüfen-Richtlinie, um GraphQL-Anforderungen zu überprüfen, den Zugriff auf bestimmte Abfragepfade zu autorisieren und die Antwortgröße einzuschränken.

Ressourcenmangel und Ratenbeschränkung

Fehlende Ratenbeschränkungen können zu Datenexfiltration oder erfolgreichen DDoS-Angriffen auf Back-End-Dienste führen, was zu einem Ausfall für alle Consumer führt.

Weitere Informationen zu dieser Bedrohung: API4:2019 Lack of resources and rate limiting (Ressourcenmangel und Ratenbeschränkung)

Empfehlungen

  • Verwenden Sie Richtlinien für Ratenbeschränkungen (kurzfristig) und für Kontingentgrenzwerte (langfristig), um die zulässige Anzahl von API-Aufrufen oder die Bandbreite pro Consumer zu kontrollieren.

  • Definieren Sie strenge Anforderungsobjektdefinitionen und deren Eigenschaften in der OpenAPI-Definition. Definieren Sie z. B. den Höchstwert für das Paging von ganzen Zahlen, maxLength und einen regulären Ausdruck (regex) für Zeichenfolgen. Erzwingen Sie diese Schemas mit den Richtlinien Inhalte überprüfen und Parameter überprüfen in API Management.

  • Erzwingen Sie die maximale Größe der Anforderung mit der Inhalt überprüfen-Richtlinie.

  • Optimieren Sie die Leistung mit integrierter Zwischenspeicherung, wodurch der Verbrauch von CPU, Arbeitsspeicher und Netzwerkressourcen für bestimmte Vorgänge verringert wird.

  • Erzwingen der Authentifizierung für API-Aufrufe (siehe fehlerhafte Benutzerauthentifizierung). Widerrufen des Zugriffs für Benutzer mit missbräuchlicher Nutzung. Deaktivieren Sie z. B. den Abonnementschlüssel, blockieren Sie die IP-Adresse mit der Aufrufer-IPs einschränken-Richtlinie, oder lehnen Sie Anforderungen für einen bestimmten Benutzeranspruch aus einem JWT-Token ab.

  • Wenden Sie eine CORS-Richtlinie an, um die Websites zu kontrollieren, die die über die API bedienten Ressourcen laden dürfen. Um übermäßig freizügige Konfigurationen zu vermeiden, verwenden Sie keine Platzhalterwerte (*) in der CORS-Richtlinie.

  • Minimieren Sie die Reaktionsdauer eines Back-End-Diensts. Je länger es dauert, bis der Back-End-Dienst reagiert, desto länger ist die Verbindung in API Management belegt, wodurch sich die Anzahl der Anforderungen verringert, die in einem bestimmten Zeitrahmen verarbeitet werden können.

  • Obwohl API Management Back-End-Dienste vor DDoS-Angriffen schützen kann, kann es doch selbst für diese Angriffe anfällig sein. Stellen Sie einen Bot-Schutzdienst vor API Management bereit (z. B. Azure Application Gateway, Azure Front Door oder Azure DDoS Protection), um besser vor DDoS-Angriffen zu schützen. Wenn Sie eine WAF mit Azure Application Gateway oder Azure Front Door verwenden, erwägen Sie die Verwendung von Microsoft_BotManagerRuleSet_1.0.

Fehlerhafte Autorisierung auf Funktionsebene

Komplexe Zugriffssteuerungsrichtlinien mit unterschiedlichen Hierarchien, Gruppen und Rollen sowie eine unklare Trennung zwischen administrativen und regulären Funktionen führen zu Autorisierungsfehlern. Durch die Ausnutzung dieser Probleme erhalten Angreifer Zugriff auf die Ressourcen oder administrativen Funktionen anderer Benutzer.

Weitere Informationen zu dieser Bedrohung: API5:2019 Broken function level authorization (Fehlerhafte Autorisierung auf Funktionsebene)

Empfehlungen

  • Schützen Sie standardmäßig alle API-Endpunkte in API Management mit Abonnementschlüsseln.

  • Definieren Sie eine JWT überprüfen-Richtlinie, und erzwingen Sie erforderliche Tokenansprüche. Wenn bestimmte Vorgänge eine strengere Erzwingung von Ansprüchen erfordern, definieren Sie zusätzliche validate-jwt-Richtlinien nur für diese Vorgänge.

  • Verwenden Sie ein virtuelles Azure-Netzwerk oder Private Link, um API-Endpunkte für das Internet auszublenden. Erfahren Sie mehr über virtuelle Netzwerkoptionen mit API Management.

  • Definieren Sie keine API-Platzhaltervorgänge (d. h. „Catch-all“-APIs (APIs, die alles abdecken) mit * als Pfad). Stellen Sie sicher, dass API Management nur Anforderungen für explizit definierte Endpunkte bedient und Anforderungen an nicht definierte Endpunkte ablehnt.

  • Veröffentlichen Sie keine APIs mit offenen Produkten, die kein Abonnement benötigen.

Massenzuweisung

Wenn eine API mehr Felder anbietet, als der Client für eine bestimmte Aktion erfordert, kann ein Angreifer übermäßige Eigenschaften einschleusen, um nicht autorisierte Vorgänge mit Daten auszuführen. Angreifer können nicht dokumentierte Eigenschaften entdecken, indem Sie das Format von Anforderungen und Antworten oder anderen APIs überprüfen oder sie erraten. Dieses Sicherheitsrisiko trifft besonders zu, wenn Sie keine stark typisierten Programmiersprachen verwenden.

Weitere Informationen zu dieser Bedrohung: API6:2019 Mass assignment (Massenzuweisung)

Empfehlungen

  • Externe API-Schnittstellen sollten von der internen Datenimplementierung entkoppelt werden. Vermeiden Sie die Bindung von API-Verträgen direkt an Datenverträge in Back-End-Diensten. Überprüfen Sie häufig das API-Design, und markieren Sie Legacy-Eigenschaften mithilfe der Versionsverwaltung in API Management, und entfernen Sie sie dann.

  • Definieren Sie XML- und JSON-Verträge exakt im API-Schema, und verwenden Sie die Richtlinien Inhalt überprüfen und Parameter überprüfen, um Anforderungen und Antworten mit nicht dokumentierten Eigenschaften zu blockieren. Das Blockieren von Anforderungen mit nicht dokumentierten Eigenschaften entschärft Angriffe, während das Blockieren von Antworten mit nicht dokumentierten Eigenschaften das Reverse-Engineering potenzieller Angriffsvektoren erschwert.

  • Wenn die Back-End-Schnittstelle nicht geändert werden kann, verwenden Sie Transformationsrichtlinien, um Anforderungs- und Antwortnutzlasten erneut zu generieren und die API-Verträge von Back-End-Verträgen zu entkoppeln. Maskieren oder filtern Sie beispielsweise Daten, oder entfernen Sie nicht benötigte JSON-Eigenschaften.

Sicherheitsfehlkonfiguration

Angreifer können versuchen, Sicherheitsfehlkonfigurationen auszunutzen, z. B.:

  • Fehlende Sicherheitshärtung
  • Unnötigerweise aktivierte Features
  • Unnötigerweise für das Internet geöffnete Netzwerkverbindungen
  • Verwendung schwacher Protokolle oder Verschlüsselungsverfahren
  • Andere Einstellungen oder Endpunkte, die möglicherweise nicht autorisierten Zugriff auf das System zulassen

Weitere Informationen zu dieser Bedrohung: API7:2019 Security misconfiguration (Sicherheitsfehlkonfiguration)

Empfehlungen

  • Konfigurieren Sie Gateway-TLS richtig. Verwenden Sie keine anfälligen Protokolle (z. B. TLS 1.0, 1.1) oder Verschlüsselungsverfahren.

  • Konfigurieren Sie APIs so, dass sie nur verschlüsselten Datenverkehr akzeptieren, z. B. über HTTPS- oder WSS-Protokolle.

  • Erwägen Sie, API Management hinter einem privaten Endpunkt bereitzustellen oder angefügt an ein virtuelles Netzwerk, das im internen Modus bereitgestellt ist. In internen Netzwerken kann der Zugriff innerhalb des privaten Netzwerks (per Firewall oder Netzwerksicherheitsgruppen) und über das Internet (über einen Reverseproxy) gesteuert werden.

  • Verwenden Sie Azure API Management-Richtlinien:

    • Erben Sie immer übergeordnete Richtlinien über das <base>-Tag.

    • Konfigurieren und testen Sie bei Verwendung von OAuth 2.0 die JWT überprüfen-Richtlinie, um das Vorhandensein und die Gültigkeit des JWT-Tokens zu überprüfen, bevor es das Back-End erreicht. Überprüfen Sie automatisch die Ablaufzeit des Tokens, die Tokensignatur und den Aussteller. Erzwingen Sie Ansprüche, Zielgruppen, Tokenablauf und Tokensignatur über Richtlinieneinstellungen.

    • Konfigurieren Sie die CORS-Richtlinie, und verwenden Sie für keine Konfigurationsoption Platzhalter (*). Listen Sie stattdessen zulässige Werte explizit auf.

    • Legen Sie Überprüfungsrichtlinien in Produktionsumgebungen auf prevent fest, um JSON- und XML-Schemas, Header, Abfrageparameter und Statuscodes zu überprüfen und die maximale Größe für Anforderungen oder Antworten zu erzwingen.

    • Wenn API Management sich außerhalb einer Netzwerkgrenze befindet, ist die Überprüfung von Client-IP-Adressen weiterhin möglich, indem sie die Aufrufer-IPs beschränken-Richtlinie verwenden. Stellen Sie sicher, dass sie eine Positivliste verwendet, keine Sperrliste.

    • Wenn zwischen dem Aufrufer und API Management Clientzertifikate verwendet werden, verwenden Sie die Clientzertifikat überprüfen-Richtlinie. Stellen Sie sicher, dass die Attribute validate-revocation, validate-trust, validate-not-before und validate-not-after alle auf true festgelegt sind.

      • Clientzertifikate (gegenseitiges TLS) können auch zwischen API Management und dem Back-End angewendet werden. Das Back-End sollte:

        • Autorisierungsanmeldeinformationen konfiguriert haben

        • Wo möglich, die Zertifikatkette überprüfen

        • Wo möglich, den Zertifikatnamen überprüfen

  • Verwenden Sie für GraphQL-Szenarien die GraphQL-Anforderung überprüfen-Richtlinie. Stellen Sie sicher, dass das authorization-Element sowie die Attribute max-size und max-depth festgelegt sind.

  • Speichern Sie keine Geheimnisse in Richtliniendateien oder in der Quellcodeverwaltung. Verwenden Sie immer benannten Werte von API Management, oder rufen Sie die Geheimnisse zur Laufzeit mithilfe benutzerdefinierter Richtlinienausdrücke ab.

    • Benannte Werte sollten in Key Vault integriert oder in API Management verschlüsselt werden, indem sie als „Geheimnis“ markiert werden. Speichern Sie Geheimnisse niemals in benannten Nur-Text-Werten.

  • Veröffentlichen Sie APIs über Produkte, die Abonnements erfordern. Verwenden Sie keine offenen Produkte, für die kein Abonnement erforderlich ist.

  • Verwenden Sie Key Vault-Integration, um alle Zertifikate zu verwalten – dadurch wird die Zertifikatverwaltung zentralisiert, was dabei helfen kann, Vorgangsverwaltungsaufgaben wie die Verlängerung oder Sperrung von Zertifikaten zu erleichtern.

  • Stellen Sie beim Verwenden des selbstgehosteten Gateways sicher, dass es einen Prozess gibt, um das Image regelmäßig auf die neueste Version zu aktualisieren.

  • Stellen Sie Back-End-Dienste als Back-End-Entitäten dar. Konfigurieren Sie, wann immer möglich, Autorisierungsanmeldeinformationen, Zertifikatkettenüberprüfung und Zertifikatnamensüberprüfung.

  • Bei Verwendung des Entwicklerportals:

    • Wenn Sie sich entschließen, das Entwicklerportal selbstzuhosten, stellen Sie sicher, dass es einen Prozess gibt, um das selbstgehostete Portal regelmäßig auf die neueste Version zu aktualisieren. Updates der verwalteten Standardversion erfolgen automatisch.

    • Verwenden Sie Microsoft Entra ID oder Azure Active Directory B2C für die Benutzerregistrierung und -anmeldung. Deaktivieren Sie die Standardauthentifizierung mit Benutzername und Kennwort, die weniger sicher ist.

    • Weisen Sie Produkten Benutzergruppen zu, um die Sichtbarkeit von APIs im Portal zu kontrollieren.

  • Verwenden Sie Azure Policy, um API Management-Konfiguration auf Ressourcenebene sowie rollenbasierte Zugriffssteuerungsberechtigungen (RBAC) zu erzwingen, um den Ressourcenzugriff zu kontrollieren. Erteilen Sie erforderliche Mindestberechtigungen für jeden Benutzer.

  • Verwenden Sie einen Ansatz mit DevOps-Prozess und Infrastructure-as-Code außerhalb einer Entwicklungsumgebung, um die Konsistenz von Änderungen an API Management-Inhalt und -Konfiguration sicherzustellen und menschliche Fehler zu minimieren.

  • Verwenden Sie keine veralteten Features.

Einschleusung

Jeder Endpunkt, der Benutzerdaten akzeptiert, ist potenziell anfällig für einen Einschleusungs-Exploit. Beispiele sind u. a. Folgendes:

  • Einschleusung von Befehlen, bei der ein böswilliger Akteur versucht, die API-Anforderung so zu ändern, dass sie Befehle auf dem Betriebssystem ausführt, das die API hostet.

  • Einschleusung von SQL-Befehlen, bei der ein böswilliger Akteur versucht, die API-Anforderung so zu ändern, dass sie Befehle und Abfragen an die Datenbank ausführt, von der eine API abhängig ist.

Weitere Informationen zu dieser Bedrohung: API8:2019 Injection (Einschleusung)

Empfehlungen

  • Moderne Web Application Firewall-Richtlinien (WAF) decken viele gängige Einschleusungsrisiken ab. Während API Management keine integrierte WAF-Komponente besitzt, wird die Upstream-Bereitstellung einer WAF (vor) der API Management-Instanz dringend empfohlen. Verwenden Sie beispielsweise Azure Application Gateway oder Azure Front Door.

    Wichtig

    Stellen Sie sicher, dass ein böswilliger Akteur das Gateway, das die WAF hostet, nicht umgehen kann, und stellen Sie eine direkte Verbindung mit dem API Management-Gateway oder der Back-End-API selbst her. Mögliche Entschärfungen sind unter anderem: Netzwerk-ACLs, die Verwendung der API Management-Richtlinie zum Beschränken des eingehenden Datenverkehrs nach Client-IP, das Entfernen des öffentlichen Zugriffs, wo nicht erforderlich, und Clientzertifikatauthentifizierung (auch als gegenseitiges TLS oder mTLS (mutual TLS) bezeichnet).

  • Verwenden Sie Schema- und Parameterüberprüfungsrichtlinien, wo anwendbar, um die Anforderung noch weiter einzuschränken und zu überprüfen, bevor sie den Back-End-API-Dienst erreicht.

    In dem mit der API-Definition bereitgestellten Schema sollte eine RegEx-Mustereinschränkung auf anfällige Felder angewendet sein. Jeder reguläre Ausdruck sollte getestet sein, um sicherzustellen, dass er das Feld ausreichend einschränkt, um gängige Einschleusungsversuche zu entschärfen.

Unsachgemäße Verwaltung von Ressourcen

Zu den Sicherheitsrisiken im Zusammenhang mit unsachgemäßer Ressourcenverwaltung gehören:

  • Mangel an ordnungsgemäßer API-Dokumentation oder Besitzinformationen

  • Übermäßige Anzahl älterer API-Versionen, denen möglicherweise Sicherheitsfixes fehlen

Weitere Informationen zu dieser Bedrohung: API9:2019 Improper assets management (Unsachgemäße Verwaltung von Ressourcen)

Empfehlungen

  • Verwenden Sie eine gut definierte OpenAPI-Spezifikation als Quelle für den Import von REST-APIs. Die Spezifikation ermöglicht die Kapselung der API-Definition, einschließlich der Selbstdokumentation von Metadaten.

    • Verwenden Sie API-Schnittstellen mit präzisen Pfaden, Datenschemas, Headern, Abfrageparametern und Statuscodes. Vermeiden Sie Platzhaltervorgänge. Geben Sie Beschreibungen für jede API und jeden Vorgang an, und schließen Sie Kontakt- und Lizenzinformationen ein.

    • Vermeiden Sie Endpunkte, die nicht direkt zum Geschäftsziel beitragen. Diese erhöhen unnötig die Angriffsoberfläche und erschweren die Entwicklung der API.

  • Verwenden Sie Revisionen und Versionen in API Management, um die API-Endpunkte zu steuern und zu kontrollieren. Verwenden Sie eine starke Back-End-Versionsverwaltungsstrategie, und verpflichten Sie sich zu einer Höchstanzahl unterstützter API-Versionen (z. B. 2 oder 3 frühere Versionen). Planen Sie, ältere, häufig auch weniger sichere, API-Versionen schnell als veraltet zu kennzeichnen und schließlich zu entfernen.

  • Verwenden Sie eine API Management-Instanz pro Umgebung (wie Entwicklung, Test und Produktion). Stellen Sie sicher, dass jede API Management-Instanz eine Verbindung mit ihren Abhängigkeiten in derselben Umgebung herstellt. In der Testumgebung sollte die API Management-Testressource beispielsweise eine Verbindung mit einer Azure Key Vault-Testressource und den Testversionen der Back-End-Dienste herstellen. Verwenden Sie DevOps-Automatisierungs- und Infrastructure-as-Code-Methoden, um Konsistenz und Genauigkeit zwischen Umgebungen aufrechtzuerhalten und menschliche Fehler zu verringern.

  • Verwenden Sie Tags, um APIs und Produkte zu organisieren und sie für die Veröffentlichung zu gruppieren.

  • Veröffentlichen Sie APIs für die Nutzung über das integrierte Entwicklerportal. Stellen Sie sicher, dass die API-Dokumentation auf dem neuesten Stand ist.

  • Ermitteln Sie nicht dokumentierte oder nicht verwaltete APIs, und machen Sie sie über API Management verfügbar, um sie besser kontrollieren zu können.

Unzureichende Protokollierung und Überwachung

Unzureichende Protokollierung und Überwachung, gekoppelt mit fehlender oder ineffektiver Integration in Reaktion auf Incidents, ermöglicht Angreifern, Systeme weiter anzugreifen, Persistenz beizubehalten, sich auf mehr Systeme auszuweiten, um Daten zu manipulieren, und Daten zu extrahieren oder zu zerstören. Die meisten Studien zu Sicherheitsverletzungen zeigen, dass die Zeit zum Erkennen einer Sicherheitsverletzung bei mehr als 200 Tagen liegt, und dass die Erkennung in der Regel durch externe Parteien erfolgt statt durch interne Prozesse oder Überwachung.

Weitere Informationen zu dieser Bedrohung: API10:2019 Insufficient logging and monitoring (Unzureichende Protokollierung und Überwachung)

Empfehlungen

Nächste Schritte

Weitere Informationen: