Teilen über


Was sind Arbeitsbereiche in Azure API Management?

GILT FÜR: Premium

In API Management bieten Arbeitsbereiche ein neues Maß an Autonomie für die API-Teams einer Organisation, sodass sie APIs schneller, zuverlässiger, sicherer und produktiver innerhalb eines API Management-Diensts erstellen, verwalten und veröffentlichen können. Durch die Bereitstellung eines isolierten administrativen Zugriffs und einer API-Runtime bieten Arbeitsbereiche den API-Teams mehr Möglichkeiten, während das API-Plattformteam weiterhin den Überblick behält. Dazu gehören zentrale Überwachung, Durchsetzung von API-Richtlinien und Compliance sowie die Veröffentlichung von APIs für die Ermittlung über ein einheitliches Entwicklerportal.

Arbeitsbereiche funktionieren wie „Ordner“ in einem API Management-Dienst:

  • Jeder Arbeitsbereich enthält APIs, Produkte, Abonnements, benannte Werte und zugehörige Ressourcen.
  • Der Zugriff auf Ressourcen in einem Arbeitsbereich wird über die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) in Azure mit integrierten oder benutzerdefinierten Rollen verwaltet, die Microsoft Entra-Konten zugewiesen werden können.
  • Jeder Arbeitsbereich ist einem Arbeitsbereichs-Gateway für das Routing von API-Datenverkehr an die Back-End-Dienste von APIs im Arbeitsbereich zugeordnet.

Konzeptionelles Diagramm des API Management-Diensts mit Arbeitsbereichen

Hinweis

  • Die aktuellen Arbeitsbereichsfunktionen werden in der API Management-REST-API-Version 2023-09-01-preview oder höher unterstützt.
  • Informationen zur Preisgestaltung finden Sie unter API Management – Preise.

API-Verbundverwaltung mit Arbeitsbereichen

Arbeitsbereiche bieten zusätzlich zu den bereits unterstützten zentralisierten und isolierten Modellen erstklassige Unterstützung für ein Verbundmodell der Verwaltung von APIs in API Management. Die folgende Tabelle enthält einen Vergleich dieser Modelle.

Modell Beschreibung
Zentralisiert

Diagramm: Zentralisiertes Modell von Azure API Management
Vorteile
• Zentrale API-Governance und -Beobachtbarkeit
• Einheitliches Entwicklerportal für effektives Ermitteln und Onboarden von APIs
• Kosteneffizienz der Infrastruktur

Nachteile
• Keine Trennung von Administratorberechtigungen zwischen Teams
• API-Gateway als Single Point of Failure
• Keine Möglichkeit, Runtimeprobleme bestimmten Teams zuzuordnen
• Verringerung des API-Wachstums aufgrund der Belastung des Plattformteams zur Erleichterung der Zusammenarbeit
Isoliert

Diagramm: Isoliertes Modell von Azure API Management
Vorteile
• Die Trennung von Administratorberechtigungen zwischen Teams erhöht die Produktivität und Sicherheit.
• Die Trennung der API-Runtime zwischen Teams erhöht die Zuverlässigkeit, Resilienz und Sicherheit der API
• Runtimeprobleme werden eingegrenzt und können bestimmten Teams zugeordnet werden.

Nachteile
• Fehlende zentrale API-Governance und -Beobachtbarkeit
• Fehlendes einheitliches Entwicklerportal
• Höhere Kosten und schwierigere Plattformverwaltung
Im Verbund

Diagramm: Verbundmodell von Azure API Management
Vorteile
• Zentrale API-Governance und -Beobachtbarkeit
• Einheitliches Entwicklerportal für effektives Ermitteln und Onboarden von APIs
• Die Trennung von Administratorberechtigungen zwischen Teams erhöht die Produktivität und Sicherheit.
• Die Trennung der API-Runtime zwischen Teams erhöht die Zuverlässigkeit, Resilienz und Sicherheit der API
• Runtimeprobleme werden eingegrenzt und können bestimmten Teams zugeordnet werden.

Nachteile
• Höhere Plattformkosten und schwierigere Verwaltung als im zentralisierten Modell, aber niedrigere Kosten bzw. einfachere Verwaltung als im isolierten Modell

Beispielszenario (Übersicht)

In einer Organisation, die APIs mithilfe von Azure API Management verwaltet, arbeiten möglicherweise mehrere Entwicklungsteams, die verschiedene Arten von APIs entwickeln, definieren, verwalten und in die Produktion überführen. Mithilfe von Arbeitsbereichen können diese Teams API Management nutzen, um ihre APIs separat und unabhängig von der Verwaltung der Dienstinfrastruktur zu verwalten, zu schützen und darauf zuzugreifen.

Im Folgenden sehen Sie einen Beispielworkflow zum Erstellen und Verwenden eines Arbeitsbereichs.

  1. Ein zentrales API-Plattformteam, das die API Management-Instanz verwaltet, erstellt einen Arbeitsbereich und weist Arbeitsbereichsmitarbeitern mithilfe von RBAC-Rollen Berechtigungen zu, beispielsweise Berechtigungen zum Erstellen oder Lesen von Ressourcen im Arbeitsbereich. Außerdem wird ein dediziertes API-Gateway für den Arbeitsbereich erstellt.

  2. Ein zentrales API-Plattformteam verwendet DevOps-Tools, um eine DevOps-Pipeline für APIs in diesem Arbeitsbereich zu erstellen.

  3. Arbeitsbereichsmitglieder entwickeln, veröffentlichen, verwalten APIs im Arbeitsbereich und überführen sie in die Produktion.

  4. Das zentrale API-Plattformteam verwaltet die Infrastruktur des Diensts, z. B. Überwachung, Resilienz und Durchsetzung von für alle APIs geltenden Richtlinien.

API Management in einem Arbeitsbereich

Teams verwalten ihre eigenen APIs, Produkte, Abonnements, Back-Ends, Richtlinien, Protokollierungen und andere Ressourcen in Arbeitsbereichen. Eine vollständige Liste der Ressourcen und Vorgänge, die in Arbeitsbereichen unterstützt werden, finden Sie in der REST-API-Referenz von API Management.

Arbeitsbereiche werden zwar unabhängig vom API Management-Dienst und anderen Arbeitsbereichen verwaltet, können aber entwurfsbedingt auf ausgewählte Ressourcen auf Dienstebene verweisen. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Arbeitsbereiche und andere Features von API Management.

Arbeitsbereichs-Gateway

Jeder Arbeitsbereich kann Arbeitsbereichs-Gateways zugeordnet werden, um die Runtime der im Arbeitsbereich verwalteten APIs zu aktivieren. Das Arbeitsbereichs-Gateway ist eine eigenständige Azure-Ressource mit der gleichen Kernfunktionalität wie das in Ihren API Management-Dienst integrierte Gateway.

Arbeitsbereichs-Gateways werden unabhängig vom API Management-Dienst und voneinander verwaltet. Sie stellen die Isolation der Runtime zwischen Arbeitsbereichen sicher und erhöhen dadurch die API-Zuverlässigkeit, -Resilienz und -Sicherheit und ermöglichen die Zuordnung von Runtimeproblemen zu Arbeitsbereichen.

Gatewayhostname

Jede Zuordnung eines Arbeitsbereichs zu einem Arbeitsbereichs-Gateway erstellt einen eindeutigen Hostnamen für in diesem Arbeitsbereich verwaltete APIs. Standardhostnamen folgen dem Muster <workspace-name>-<hash>.gateway.<region>.azure-api.net. Derzeit werden benutzerdefinierte Domänennamen für Arbeitsbereichs-Gateways nicht unterstützt.

Hinweis

Bis Oktober 2024 kann auf APIs in Arbeitsbereichen zur Laufzeit über den Gatewayhostnamen Ihrer API Management-Instanz sowie über den Hostnamen des Arbeitsbereich-Gateways zugegriffen werden.

Netzwerkisolation

Ein Arbeitsbereichs-Gateway kann optional in einem privaten virtuellen Netzwerk konfiguriert werden, um eingehenden und/oder ausgehenden Datenverkehr zu isolieren. Wird diese Einstellung konfiguriert, muss das Arbeitsbereichs-Gateway ein dediziertes Subnetz im virtuellen Netzwerk verwenden.

Ausführliche Anforderungen finden Sie unter Netzwerkressourcenanforderungen für die Integration eines Arbeitsbereichs-Gateways in ein virtuelles Netzwerk.

Hinweis

  • Die Netzwerkkonfiguration eines Arbeitsbereichs-Gateways ist unabhängig von der Netzwerkkonfiguration der API Management-Instanz.
  • Derzeit kann ein Arbeitsbereichs-Gateway nur in einem virtuellen Netzwerk konfiguriert werden, wenn das Gateway erstellt wird. Sie können die Netzwerkkonfiguration oder -einstellungen des Gateways später nicht mehr ändern.

Skalieren der Kapazität

Verwalten Sie die Gatewaykapazität, indem Sie Skalierungseinheiten manuell hinzufügen oder entfernen, ähnlich wie die Einheiten, die der API Management-Instanz in bestimmten Dienstebenen hinzugefügt werden können. Die Kosten für ein Arbeitsbereichs-Gateway basieren auf der Anzahl der ausgewählten Einheiten.

Regionale Verfügbarkeit

Arbeitsbereichs-Gateways sind derzeit in den folgenden Regionen verfügbar:

Hinweis

Diese Regionen sind eine Teilmenge der Regionen, in denen API Management verfügbar ist.

  • USA (Westen)
  • USA Nord Mitte
  • USA (Ost) 2
  • UK, Süden
  • Frankreich, Mitte
  • Deutschland, Westen-Mitte
  • Nordeuropa
  • Asien, Osten
  • Asien, Südosten
  • Australien (Osten)
  • Japan, Osten

Einschränkungen für Gateways

Die folgenden Einschränkungen gelten derzeit für Arbeitsbereichs-Gateways:

  • Ein Arbeitsbereichs-Gateway muss sich in derselben Region wie die primäre Azure-Region der API Management-Instanz und im selben Abonnement befinden.
  • Ein Gateway kann nur einem Arbeitsbereich zugeordnet werden.
  • Einem Arbeitsbereich kann kein selbstgehostetes Gateway zugeordnet werden.
  • Arbeitsbereichs-Gateways unterstützen keine eingehenden privaten Endpunkte.
  • APIs in Arbeitsbereich-Gateways können keine benutzerdefinierten Hostnamen zugewiesen werden.
  • APIs in Arbeitsbereichen werden von Defender für APIs nicht abgedeckt.
  • Arbeitsbereichs-Gateways unterstützen die Anmeldeinformationsverwaltung des API Management-Diensts nicht.
  • Arbeitsbereichs-Gateways unterstützen nur internen Cache. Externer Cache wird nicht unterstützt.
  • Arbeitsbereichs-Gateways unterstützen keine synthetischen GraphQL-APIs und WebSocket-APIs.
  • Die Erstellung von APIs direkt aus Azure-Ressourcen wie Azure OpenAI Service, App Service, Function Apps usw. wird von Arbeitsbereichs-Gateways nicht unterstützt.
  • Anforderungsmetriken können nicht nach Arbeitsbereich in Azure Monitor aufgeteilt werden. Alle Arbeitsbereichsmetriken werden auf Dienstebene aggregiert.
  • Azure Monitor-Protokolle werden auf Dienstebene aggregiert. Protokolle auf Arbeitsbereichsebene sind nicht verfügbar.
  • Arbeitsbereichs-Gateways unterstützen keine Zertifizierungsstellenzertifikate.
  • Arbeitsbereichs-Gateways unterstützen keine automatische Skalierung.
  • Arbeitsbereichs-Gateways unterstützen keine verwalteten Identitäten, einschließlich verwandter Features wie das Speichern von Geheimnissen in Azure Key Vault und die Verwendung der Richtlinie authentication-managed-identity.

RBAC-Rollen für Arbeitsbereiche

Mit Azure RBAC werden Berechtigungen von Personen mit der Rolle „Projektmitarbeiter im Arbeitsbereich“ zum Lesen und Bearbeiten von Entitäten im Arbeitsbereich konfiguriert. Eine Liste der Rollen finden Sie unter Verwenden der rollenbasierten Zugriffssteuerung in API Management.

Um APIs und andere Ressourcen im Arbeitsbereich zu verwalten, müssen Arbeitsbereichsmitgliedern Rollen (oder gleichwertige Berechtigungen mit benutzerdefinierten Rollen) zugewiesen werden, die auf den API Management-Dienst, den Arbeitsbereich und das Arbeitsbereichs-Gateway ausgerichtet sind. Die servicebezogene Rolle ermöglicht es, bestimmte Ressourcen auf Dienstebene von Ressourcen auf Arbeitsplatzebene aus zu referenzieren. Organisieren Sie z. B. einen Benutzer in einer Gruppe auf Arbeitsbereichsebene, um die API und die Produktsichtbarkeit zu steuern.

Hinweis

Richten Sie zur einfacheren Verwaltung Microsoft Entra ID-Gruppen ein, um Arbeitsbereichsberechtigungen für mehrere Benutzer zuzuweisen.

Arbeitsbereiche und andere Features von API Management

Arbeitsbereiche sind so konzipiert, dass sie eigenständig sind, um die Trennung des administrativen Zugriffs und der API-Runtime zu maximieren. Es gibt mehrere Ausnahmen, um eine höhere Produktivität zu gewährleisten und plattformweite Governance, Beobachtbarkeit, Wiederverwendbarkeit und API-Ermittlung zu ermöglichen.

  • Ressourcenverweise: Ressourcen in einem Arbeitsbereich können auf andere Ressourcen im Arbeitsbereich und auf ausgewählte Ressourcen der Dienstebene verweisen, etwa Benutzer, Autorisierungsserver oder integrierte Benutzergruppen. Sie können nicht auf Ressourcen aus einem anderen Arbeitsbereich verweisen.

    Aus Sicherheitsgründen ist es nicht möglich, von Richtlinien auf Arbeitsbereichsebene (z. B. benannten Werten) auf Ressourcen auf Dienstebene zu verweisen. Auch Verweise anhand von Ressourcennamen, z. B. backend-id in der Richtlinie set-backend-service, sind nicht zulässig.

    Wichtig

    Alle Ressourcen in einem API Management-Dienst (z. B. APIs, Produkte, Tags oder Abonnements) müssen eindeutige Namen aufweisen, auch wenn sie sich in verschiedenen Arbeitsbereichen befinden. Es dürfen keine Ressourcen desselben Typs und mit demselben Azure-Ressourcennamen im selben Arbeitsbereich, in anderen Arbeitsbereichen oder auf Dienstebene vorhanden sein.

  • Entwicklungsportal: Arbeitsbereiche sind ein administratives Konzept und werden Kunden im Entwicklungsportal nicht als solche angezeigt. Dies gilt auch für die Benutzeroberfläche und die zugrunde liegende API des Entwicklungsportals. APIs und Produkte innerhalb eines Arbeitsbereichs können im Entwicklerportal veröffentlicht werden, genau wie APIs und Produkte auf Serviceebene.

    Hinweis

    API Management unterstützt das Zuweisen von auf Dienstebene definierten Autorisierungsservern zu APIs innerhalb von Arbeitsbereichen.

Migrieren von Vorschauarbeitsbereichen

Wenn Sie Vorschauarbeitsbereiche in Azure API Management erstellt haben und diese weiterhin verwenden möchten, migrieren Sie Ihre Arbeitsbereiche zur allgemein verfügbaren Version, indem Sie jeden Arbeitsbereich ein Arbeitsbereichs-Gateway zuordnen.

Einzelheiten und Informationen zu anderen Änderungen, die sich auf Ihre Vorschauarbeitsbereiche auswirken könnten, finden Sie unter Breaking Changes für Arbeitsbereiche (März 2025).

Löschen eines Arbeitsbereichs

Beim Löschen eines Arbeitsbereichs werden alle untergeordneten Ressourcen (APIs, Produkte usw.) und das zugehörige Gateway gelöscht, wenn Sie den Arbeitsbereich über die Azure-Portalschnittstelle löschen. Die API Management-Instanz oder andere Arbeitsbereiche werden nicht gelöscht.