Freigeben über

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

Hinweis

Dieser Artikel wurde mit der aktuellen Liste der 10 wichtigsten Bedrohungen laut OWASP API Security für 2023 aktualisiert.

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 die neuesten Empfehlungen beschrieben, um mit Azure API Management die 10 wichtigsten API-Bedrohungen zu mindern, die von OWASP in der Liste für 2023 identifiziert wurden.

API Management bietet zwar umfassende Steuerungen für die API-Sicherheit, aber auch andere Microsoft-Dienste stellen ergänzende Funktionen zum Erkennen oder Schützen vor OWASP-API-Bedrohungen bereit:

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 zur Bedrohung: API1:2023 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 Lookup (z. B. einem Wörterbuch) oder um die Integration mit einem anderen Dienst über die Richtlinie send-request (Anforderung senden) handeln.

  • Erzwingen Sie in GraphQL-Szenarien die Autorisierung auf Objektebene über die Richtlinie validate-graphql-request (GraphQL-Anforderung überprüfen) mithilfe des authorize-Elements.

Fehlerhafte Authentifizierung

Der Authentifizierungsmechanismus für eine Website oder API ist besonders anfällig, da er für anonyme Benutzer zugänglich ist. Ressourcen und Endpunkte, die für die Authentifizierung erforderlich sind, z. B. für die Flows bei vergessenen Kennwörtern oder dem Zurücksetzen von Kennwörtern, sollten geschützt werden, um ihre Ausnutzung zu verhindern.

Weitere Informationen zur Bedrohung: API2:2023 Broken Authentication (Fehlerhafte Authentifizierung)

Empfehlungen

  • Verwenden Sie Microsoft Entra, um die API-Authentifizierung zu implementieren. Microsoft Entra stellt automatisch geschützte, resiliente und geografisch verteilte Anmeldeendpunkte bereit. Verwenden Sie die Richtlinie validate-azure-ad-token (Azure AD-Token überprüfen), um Microsoft Entra-Token in eingehenden API-Anforderungen zu überprüfen.
  • Wenn eine Authentifizierung erforderlich ist, unterstützt API Management die Überprüfung von OAuth 2-Token, die Standardauthentifizierung, Clientzertifikate und API-Schlüssel.
    • Stellen Sie die richtige Konfiguration der Authentifizierungsmethoden sicher. Legen Sie z. B. bei der Validierung von OAuth2-Token require-expiration-time und require-signed-tokens mithilfe der Richtlinie validate-jwt (JWT überprüfen) auf true fest.
  • Mithilfe der Ratenbegrenzung können Sie die Auswirkungen von Brute-Force-Angriffen verringern.
  • Mit der Client-IP-Filterung können Sie die Angriffsfläche reduzieren. Netzwerksicherheitsgruppen können auf virtuelle Netzwerke angewandt werden, die in API Management integriert sind.
  • Wenn möglich, authentifizieren Sie sich aus API Management bei Back-Ends über sichere Protokolle und mit verwalteten Identitäten oder der Anmeldeinformationsverwaltung.
  • Stellen Sie sicher, dass Token oder Schlüssel für eingehende Anforderungen an API Management und ausgehende Anforderungen an Back-Ends in Headern und nicht in URLs übergeben werden.
  • Verwenden Sie Microsoft Entra, um den Zugriff auf das API Management-Entwicklerportal zu schützen.

Fehlerhafte Autorisierung auf Objekteigenschaftenebene

Ein gutes API-Schnittstellendesign ist eine trügerische Herausforderung. Häufig enthalten die Anforderungs- und Antwortschnittstellen, insbesondere bei Legacy-APIs, die sich im Lauf der Zeit entwickelt haben, mehr Datenfelder als die Consumeranwendungen benötigen, und ermöglichen damit Einschleusungsangriffe. Angreifer können auch nicht dokumentierte Schnittstellen ermitteln. Über diese Sicherheitsrisiken könnten Angreifer auf vertrauliche Daten zugreifen.

Weitere Informationen zur Bedrohung: API3:2023 Broken Object Property Level Authorization (Fehlerhafte Autorisierung auf Objekteigenschaftenebene)

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 für Änderungen, die keine Breaking Changes sind (z. B. Hinzufügen eines Felds zu einer Schnittstelle), und Versionen, um Breaking Changes zu implementieren. Sie sollten auch für Back-End-Schnittstellen Versionen verwenden, da sie in der Regel einen anderen Lebenszyklus haben als APIs für Consumer.
  • Entkoppeln Sie externe API-Schnittstellen von der internen Datenimplementierung. Vermeiden Sie die Bindung von API-Verträgen direkt an Datenverträge in Back-End-Diensten.
  • 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. Die Inhaltsü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. Entfernen Sie beispielsweise nicht benötigte JSON-Eigenschaften aus einem Antworttext. 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. Die Richtlinie validate-content (Inhalt überprüfen) unterstützt außerdem das Blockieren von Antworten, die eine festgelegte Größe überschreiten.
  • Verwenden Sie die Richtlinie validate-status-code (Statuscode überprüfen) zum Blockieren von Antworten mit Fehlern, die im API-Schema nicht definiert sind.
  • Verwenden Sie die Richtlinie validate-headers (Header überprüfen), 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 Richtlinie set-header (Header festlegen).
  • Verwenden Sie in GraphQL-Szenarien die Richtlinie validate-graphql-request (GraphQL-Anforderung überprüfen), um GraphQL-Anforderungen zu überprüfen, den Zugriff auf bestimmte Abfragepfade zu autorisieren und die Antwortgröße einzuschränken.

Uneingeschränkter Ressourcenverbrauch

APIs erfordern die Ausführung von Ressourcen (z. B. Arbeitsspeicher oder CPU) und können nachgelagerte Integrationen enthalten, die Betriebskosten verursachen (z. B. Dienste mit Abrechnung pro Anforderung). Das Anwenden von Grenzwerten kann dazu beitragen, APIs vor übermäßigem Ressourcenverbrauch zu schützen.

Weitere Informationen zur Bedrohung: API4:2023 Unrestricted Resource Consumption (Uneingeschränkter Ressourcenverbrauch)

Empfehlungen

  • Verwenden Sie die Richtlinien rate-limit-by-key (Ratenbegrenzung nach Schlüssel) oder rate-limit (Ratenbegrenzung), um Drosselung für kürzere Zeitfenster anzuwenden. Wenden Sie strengere Richtlinien für die Ratenbegrenzung für vertrauliche Endpunkte, z. B. für Kennwortzurücksetzung, Anmelde- oder Registrierungsvorgänge, oder für Endpunkte, die sehr viele Ressourcen verbrauchen.
  • Verwenden Sie die Richtlinien quota-by-key (Kontingent nach Schlüssel) oder quota-limit (Kontingentbegrenzung), um die zulässige Anzahl von API-Aufrufen oder die Bandbreiten für längere Zeiträume zu steuern.
  • Optimieren Sie die Leistung mit integrierter Zwischenspeicherung, wodurch der Verbrauch von CPU, Arbeitsspeicher und Netzwerkressourcen für bestimmte Vorgänge verringert wird.
  • Wenden Sie Überprüfungsrichtlinien an.
    • Verwenden des max-size-Attributs in der Richtlinie validate-content (Inhalt überprüfen) zum Erzwingen der maximalen Größe von Anforderungen und Antworten
    • Definieren Sie in der API-Spezifikation Schemas und Eigenschaften, z. B. für die Zeichenfolgenlänge oder die maximale Arraygröße. Verwenden Sie die Richtlinien validate-content (Inhalt überprüfen), validate-parameter (Parameter überprüfen) und validate-headers (Header überprüfen), um diese Schemas für Anforderungen und Antworten zu erzwingen.
    • Verwenden Sie die Richtlinie validate-graphql-request (GraphQL-Anforderung überprüfen) für GraphQL-APIs, und konfigurieren Sie die Parameter max-depth und max-size.
    • Konfigurieren Sie Warnungen in Azure Monitor bei einem übermäßigen Verbrauch von Daten durch Benutzer.
  • Für generative KI-APIs:
  • 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.
    • Definieren Sie timeout in der Richtlinie forward-request (Anforderung weiterleiten), und verwenden Sie dabei möglichst den kürzesten akzeptablen Wert.
    • Begrenzen Sie die Anzahl paralleler Back-End-Verbindungen mit der Richtlinie limit-concurrency (Parallelität begrenzen).
  • 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.
  • Azure verfügt zwar sowohl über den Schutz auf Plattformebene als auch über einen verbesserten Schutz vor verteilten DDoS-Angriffen (Denial of Service), der Anwendungsschutz (Schicht 7) für APIs kann aber noch verbessert werden, indem ein Bot-Schutzdienst vor API Management bereitgestellt wird, z. B. Azure Application Gateway, Azure Front Door oder Azure DDoS Protection. Wenn Sie eine WAF-Richtlinie (Web Application Firewall) mit Azure Application Gateway oder Azure Front Door verwenden, sollten Sie Microsoft_BotManagerRuleSet_1.0 in Betracht ziehen.

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 zur Bedrohung: API5:2023 Broken function level authorization (Fehlerhafte Autorisierung auf Funktionsebene)

Empfehlungen

  • Schützen Sie standardmäßig alle API-Endpunkte in API Management mit Abonnementschlüsseln oder Autorisierungsrichtlinien auf allen API-Ebenen. Definieren Sie ggf. weitere Autorisierungsrichtlinien für bestimmte APIs oder API-Vorgänge.
  • Überprüfen Sie OAuth-Token mithilfe von Richtlinien.
    • Verwenden Sie die Richtlinie validate-azure-ad-token (Azure AD-Token überprüfen), um Microsoft Entra-Token zu überprüfen. Geben Sie alle erforderlichen Ansprüche und ggf. autorisierten Anwendungen an.
    • Zum Überprüfen von Token, die nicht von Microsoft Entra ausgestellt wurden, definieren Sie eine Richtlinie validate-jwt (JWT überprüfen) und erzwingen Tokenansprüche. Wenn möglich, sollte eine Ablaufzeit erzwungen werden.
    • Verwenden Sie nach Möglichkeit verschlüsselte Token oder listen Sie bestimmte Anwendungen auf, über die der Zugriff zulässig ist.
    • Überwachen und überprüfen Sie Anforderungen, die aufgrund fehlender Autorisierung abgelehnt wurden.
  • 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.
  • Wenn die Client-IP-Adressen bekannt sind, verwenden Sie eine Richtlinie ip-filter (IP-Adressfilter), um nur Datenverkehr von autorisierten IP-Adressen zuzulassen.
  • Verwenden Sie die Richtlinie validate-client-certificate (Clientzertifikat überprüfen), um zu erzwingen, dass ein Zertifikat, das einer API Management-Instanz von einem Client präsentiert wird, mit den angegebenen Validierungsregeln und Ansprüchen übereinstimmen muss.

Uneingeschränkter Zugriff auf vertrauliche Geschäftsabläufe

APIs können eine breite Palette von Funktionen für die Consumeranwendung verfügbar machen. Es ist wichtig, dass API-Ersteller die von der API verfügbar gemachten Geschäftsabläufe und die entsprechende Vertraulichkeit verstehen. Es besteht ein größeres Risiko für das Unternehmen, wenn für APIs, die vertrauliche Abläufe verfügbar machen, keine geeigneten Schutzmaßnahmen implementiert werden.

Weitere Informationen zur Bedrohung: API6:2023 Uneingeschränkter Zugriff auf vertrauliche Geschäftsabläufe

Empfehlungen

  • Reduzieren oder blockieren Sie den Zugriff basierend auf Clientfingerabdrücken. Verwenden Sie z. B. die Richtlinie return-response (Antwort zurückgeben) mit der Richtlinie choose (Auswählen), um den Datenverkehr von Browsern ohne Header basierend auf dem User-Agent-Header oder in Übereinstimmung mit anderen Headern zu blockieren.
  • Verwenden Sie die Richtlinie validate-parameters (Parameter überprüfen), um zu erzwingen, dass Anforderungsheader der API-Spezifikation entsprechen müssen.
  • Verwenden Sie die Richtlinie ip-filter (IP-Adressfilter), um Anforderungen nur von bekannten IP-Adressen zuzulassen oder den Zugriff von bestimmten IP-Adressen zu blockieren.
  • Verwenden Sie private Netzwerkfeatures, um externe Konnektivität auf interne APIs zu beschränken.
  • Verwenden Sie die Richtlinie rate-limit-by-key (Ratenbegrenzung nach Schlüssel), um Spitzen bei der API-Nutzung basierend auf Benutzeridentität, IP-Adresse oder einem anderen Wert zu begrenzen.
  • Stellen Sie vor API Management Dienste wie Azure Application Gateway oder Azure DDoS Protection bereit, um Botdatenverkehr zu erkennen und zu blockieren.

Serverseitige Anforderungsfälschung

Das Risiko einer serverseitigen Anforderungsfälschung besteht, wenn die API eine nachgelagerte Ressource basierend auf dem Wert einer URL abruft, die vom API-Aufrufer ohne entsprechende Überprüfungen übergeben wurde.

Weitere Informationen zur Bedrohung: API7:2023 Server Side Request Forgery (Serverseitige Anforderungsfälschung)

Empfehlungen

  • Verwenden Sie nach Möglichkeit keine URLs, die in den Clientnutzdaten bereitgestellt werden, z B. als Parameter für Back-End-URLs, und wenden Sie die Richtlinien send-request (Anforderung senden) oder rewrite-url (URL umschreiben) an.
  • Wenn API Management oder Back-End-Dienste URLs verwenden, die über die Anforderungsnutzdaten für Geschäftslogik bereitgestellt werden, definieren und erzwingen Sie eine begrenzte Liste von Hostnamen, Ports, Medientypen oder anderen Attributen mit API Management-Richtlinien wie z. B. choose (Auswählen) und Richtlinienausdrücken.
  • Definieren Sie das timeout-Attribut in den Richtlinien forward-request (Anforderung weiterleiten) und send-request (Anforderung senden).
  • Überprüfen und Bereinigen von Anforderungs- und Antwortdaten mit Überprüfungsrichtlinien. Verwenden Sie bei Bedarf die Richtlinie set-body (Text festlegen), um die Antwort zu verarbeiten und die Rückgabe von Rohdaten zu vermeiden.
  • Verwenden Sie private Netzwerke, um die Konnektivität einzuschränken. Wenn die API beispielsweise nicht öffentlich sein muss, schränken Sie die Konnektivität aus dem Internet ein, um die Angriffsfläche zu reduzieren.

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

Weitere Informationen zur Bedrohung: API8:2023 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. Sie können diese Einstellung mithilfe von Azure Policy überwachen und erzwingen.
  • 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 Richtlinievalidate-jwt (JWT überprüfen), um das Vorhandensein und die Gültigkeit des 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. Wenn Sie Microsoft Entra verwenden, bietet die Richtlinie validate-azure-ad-token (Azure AD-Token überprüfen) eine umfassendere und einfachere Möglichkeit zum Überprüfen von Sicherheitstoken.
    • 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 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 Richtlinie validate-client-certificate (Clientzertifikat überprüfen). 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 in GraphQL-Szenarien die Richtlinie validate-graphQL-request (GraphQL-Anforderung überprüfen). 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 Azure 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.
  • Stellen Sie sicher, dass Ihre APIs Abonnementschlüssel erfordern, auch wenn alle Produkte so konfiguriert sind, dass Abonnementschlüssel erforderlich sind. Weitere Informationen
  • Erzwingen Sie für alle Produkte die Abonnementgenehmigung, und überprüfen Sie sorgfältig alle Abonnementanforderungen.
  • Verwenden Sie die Key Vault-Integration, um sämtliche Zertifikate zu verwalten. Dadurch wird die Zertifikatverwaltung zentralisiert und kann die Verwaltung von Vorgängen wie Zertifikatsverlängerung oder -sperrung vereinfachen. Verwenden Sie für die Authentifizierung bei Schlüsseltresoren verwaltete Identitäten.
  • 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.
  • Verwenden Sie für die Authentifizierung bei Back-End-Diensten nach Möglichkeit die Anmeldeinformationsverwaltung oder verwaltete Identitäten.
  • 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.

Unsachgemäße Bestandsverwaltung

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 zur Bedrohung: API9:2023 Improper inventory management (Unsachgemäße Bestandsverwaltung)

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 API-Änderungen zu verwalten. 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. Stellen Sie sicher, dass in allen verfügbaren API-Versionen Sicherheitskontrollen implementiert werden.
  • Trennen Sie Ihre Umgebungen (z. B. für Entwicklung, Tests und Produktion) mit verschiedenen API Management-Diensten. Stellen Sie sicher, dass jeder API Management-Dienst eine Verbindung mit seinen 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.
  • Isolieren Sie administrative Berechtigungen für APIs und zugehörige Ressourcen mithilfe von Arbeitsbereichen.
  • Verwenden Sie Tags, um APIs und Produkte zu organisieren und sie für die Veröffentlichung zu gruppieren.
  • Veröffentlichen Sie APIs für den Verbrauch über ein 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.
  • Verwenden Sie Azure API Center, um Ihren Bestand an APIs, Versionen und Bereitstellungen an einem zentralen Ort zu verwalten, auch wenn APIs nicht in Azure API Management verwaltet werden.

Unsicherer Verbrauch von APIs

Ressourcen, die über nachgelagerte Integrationen abgerufen werden, sind tendenziell vertrauenswürdiger als API-Eingaben vom Aufrufer oder Endbenutzer. Wenn die entsprechenden Bereinigungs- und Sicherheitsstandards nicht angewandt werden, kann die API anfällig sein, auch wenn die Integration über einen vertrauenswürdigen Dienst erfolgt.

Weitere Informationen zur Bedrohung: API10:2023 Unsafe Consumption of APIs (Unsicherer Verbrauch von APIs)

Empfehlungen

  • Erwägen Sie die Verwendung von API Management als Front-End für nachgelagerte Abhängigkeiten, in das die Back-End-APIs integriert werden.
  • Wenn vor nachgelagerten Abhängigkeiten API Management bereitgestellt wird oder wenn sie mit einer Richtlinie send-request (Anforderung senden) in API verwendet werden, wenden Sie die Empfehlungen aus den anderen Abschnitten dieser Dokumentation an, um ihre sichere und kontrollierte Nutzung zu gewährleisten, einschließlich:
    • Sicherstellen der Aktivierung des sicheren Transports und Erzwingen einer TLS/SSL-Konfiguration
    • Nach Möglichkeit Authentifizieren mit der Anmeldeinformationsverwaltung einer verwalteten Identität
    • Steuern des Verbrauchs mit den Richtlinien „rate-limit-by-key“ (Ratenbegrenzung nach Schlüssel) und „quota-limit-by-key“ (Kontingentbegrenzung nach Schlüssel)
    • Protokollieren oder Blockieren von Antworten, die mit der API-Spezifikation inkompatibel sind, mithilfe der Richtlinien „validate-content“ (Inhalt überprüfen) und „validate-header“ (Header überprüfen)
    • Transformieren von Antworten mit der Richtlinie „set-body“ (Text festlegen), um z. B. unnötige oder vertrauliche Informationen zu entfernen
    • Konfigurieren von Timeouts und Einschränken der Parallelität

Zugehöriger Inhalt

Weitere Informationen zu: