Federatief API-beheer met werkruimten

VAN TOEPASSING OP: Basic v2 | Standard v2 | Premium | Premium v2

Dit artikel bevat een overzicht van API Management-werkruimten en hoe ze gedecentraliseerde API-ontwikkelteams in staat stellen hun API's te beheren en te productiseren in een algemene service-infrastructuur.

Waarom moeten organisaties API Management federeren?

Tegenwoordig staan organisaties steeds vaker voor uitdagingen bij het beheren van een verspreiding van API's. Naarmate het aantal API's en API-ontwikkelteams groeit, is het ook complex om ze te beheren. Deze complexiteit kan leiden tot verhoogde operationele overhead, beveiligingsrisico's en verminderde flexibiliteit. Aan de ene kant willen organisaties een gecentraliseerde API-infrastructuur opzetten om API-governance, beveiliging en naleving te garanderen. Aan de andere kant willen ze dat hun API-teams innoveren en snel reageren op bedrijfsbehoeften, zonder dat ze een API-platform hoeven te beheren.

Een federatief model van API Management voldoet aan deze behoeften. Federatief API-beheer maakt gedecentraliseerde API-beheer mogelijk door ontwikkelteams met de juiste isolatie van besturings- en gegevensvlakken, terwijl gecentraliseerd beheer, bewaking en API-detectie worden onderhouden die worden beheerd door een API-platformteam. Dit model ondervangt de beperkingen van alternatieve benaderingen, zoals volledig gecentraliseerd API-beheer door het platformteam of api-beheer in silo's door elk ontwikkelteam.

Federatieve API-beheer biedt:

• Gecentraliseerd API-beheer en waarneembaarheid
• Een uniforme ontwikkelaarsportal voor effectieve API-detectie en onboarding
• Gescheiden beheermachtigingen tussen API-teams, waardoor de productiviteit en beveiliging worden verbeterd
• Gescheiden API-runtime tussen API-teams, verbetering van betrouwbaarheid, tolerantie en beveiliging

Hoe werkruimten federatief API-beheer inschakelen

Gebruik in Azure API Management werkruimten om federatief API-beheer te implementeren. Werkruimten werken als 'mappen' in een API Management-service:

• Elke werkruimte bevat API's, producten, abonnementen, benoemde waarden en gerelateerde resources. Zie de API Management REST API-referentie voor een volledige lijst met resources en bewerkingen die worden ondersteund in werkruimten.
• De toegang van Teams tot resources in een werkruimte wordt beheerd via op rollen gebaseerd toegangsbeheer (RBAC) van Azure met ingebouwde of aangepaste rollen die kunnen worden toegewezen aan Microsoft Entra-accounts en die zijn afgestemd op een werkruimte.
• Elke werkruimte is gekoppeld aan een of meer gateways voor het routeren van API-verkeer naar de back-endservices van API's in de werkruimte. Afhankelijk van de servicelaag en uw vereisten kan een werkruimte gebruikmaken van de standaard beheerde gateway van de service of een of meer werkruimtegateways.
• Het platformteam kan beleidsregels toepassen voor API's en producten in werkruimten om DE API-runtime in de hele organisatie te beheren. Met een ingebouwde Azure Policy-definitie (API Management policies should inherit parent scope policies using <base/>) kunt u controleren of afdwingen dat dit beleid wordt toegepast op alle werkruimtebronnen.
• Het platformteam kan een gecentraliseerde API-detectie-ervaring implementeren met een ontwikkelaarsportal.
• Elk werkruimteteam kan gatewayresourcelogboeken verzamelen en analyseren om hun eigen werkruimte-API's te bewaken, terwijl het platformteam federatieve toegang heeft tot logboeken in alle werkruimten in de API Management-service, waarbij toezicht, beveiliging en naleving worden geboden in hun API-ecosysteem.

Terwijl werkruimten onafhankelijk van de API Management-service en andere werkruimten worden beheerd, kunnen ze standaard verwijzen naar geselecteerde resources op serviceniveau. Zie werkruimten en andere API Management-functies verderop in dit artikel.

Overzicht van voorbeeldscenario's

Een organisatie die API's beheert met behulp van Azure API Management kan meerdere ontwikkelteams hebben die verschillende sets API's ontwikkelen, definiëren, onderhouden en productiseren. Met behulp van werkruimten kunnen deze teams API Management gebruiken om hun API's afzonderlijk en onafhankelijk van het beheren van de service-infrastructuur te beheren, te openen en te beveiligen.

In de volgende werkstroom ziet u een voorbeeldproces voor het maken en gebruiken van een werkruimte.

1. Een centraal API-platformteam dat het API Management-exemplaar beheert, maakt een werkruimte en wijst machtigingen toe aan werkruimtemedewerkers met behulp van RBAC-rollen. Wijs bijvoorbeeld machtigingen toe om resources in de werkruimte te maken of te lezen. Het team maakt of koppelt een API-gateway aan de werkruimte om API-verkeer te routeren.

2. Een centraal API-platformteam maakt gebruik van DevOps-hulpprogramma's om een DevOps-pijplijn voor API's in die werkruimte te maken.

3. Werkruimteleden ontwikkelen, publiceren, productiseren en onderhouden API's in de werkruimte.

4. Het centrale API-platformteam beheert de infrastructuur van de service, zoals bewaking, tolerantie en afdwinging van beleid voor alle API's.

Werkruimte-gateway

Elke werkruimte is geconfigureerd met een of meer gateways om de uitvoering mogelijk te maken van API's die binnen de werkruimte worden beheerd. Afhankelijk van de servicelaag en uw vereisten kunt u de standaard beheerde gateway van de service en/of een of meer werkruimtegateways (afzonderlijke gatewayresources) gebruiken.

Standaard beheerde gateway

In de v2-lagen kunt u een werkruimte configureren om API-verkeer te routeren via de standaard beheerde gateway van de service, naast een of meer afzonderlijke werkruimtegatewayresources. Wanneer een werkruimte gebruikmaakt van de standaard beheerde gateway:

• API-verkeer routeert via de standaardhostnaam van de service (bijvoorbeeld <service-name>.azure-api.net).
• De werkruimte deelt de capaciteit en configuratie van de gateway met andere werkruimten en API's op serviceniveau.

Werkruimte-gateway

Een werkruimtegateway is een zelfstandige Azure resource (workspace gateway premium) met dezelfde kernfunctionaliteit als de standaard beheerde gateway.

U beheert werkruimtegateways onafhankelijk van de API Management-service en van elkaar. Ze maken isolatie van runtime mogelijk tussen werkruimten of gebruiksvoorbeelden, wat de betrouwbaarheid, tolerantie en beveiliging van DE API verhoogt. Ze maken ook het toewijzen van runtimeproblemen aan werkruimten mogelijk.

• Zie prijzen voor API Management voor informatie over de kosten van werkruimte-gateways.
• Zie het overzicht van API Management-gateways voor een gedetailleerde vergelijking van API Management-gateways.

Werkruimten koppelen aan een werkruimtegateway

Afhankelijk van de behoeften van uw organisatie kunt u één werkruimte of meerdere werkruimten koppelen aan een werkruimtegateway.

• Een werkruimtegateway heeft bepaalde configuratie-instellingen, zoals virtueel netwerk, schaal en hostnaam, en toegewezen rekenresources, waaronder CPU, geheugen en netwerkresources.
• Alle werkruimten die op een gateway zijn geïmplementeerd, delen de configuratie- en rekenresources.
• Bugs in een API of afwijkend verkeer kunnen uitputting van deze resources veroorzaken, wat van invloed is op alle werkruimten op die gateway. Met andere woorden, hoe meer werkruimten u implementeert op een gateway, hoe hoger het risico dat een API van de ene werkruimte betrouwbaarheidsproblemen ondervindt die worden veroorzaakt door een API uit een andere werkruimte.
• Bewaak de prestaties van uw werkruimtegateway met behulp van ingebouwde metrische gegevens voor CPU- en geheugengebruik.

Overweeg betrouwbaarheid, beveiliging en kosten bij het kiezen van een implementatiemodel voor werkruimten.

• Wijs een werkruimte toe aan een eigen toegewezen werkruimtegateway voor bedrijfskritieke workloads : als u de betrouwbaarheid en beveiliging van de API wilt maximaliseren, wijst u elke bedrijfskritieke werkruimte toe aan een eigen gateway en vermijdt u gedeeld gebruik met andere werkruimten.
• De betrouwbaarheid, beveiliging en kosten in balans brengen: koppel meerdere werkruimten aan een werkruimtegateway (of, indien van toepassing, de standaard beheerde gateway) om de betrouwbaarheid, beveiliging en kosten voor niet-kritieke workloads te verdelen. Verdeel werkruimtes over ten minste twee gateways om te helpen voorkomen dat problemen, zoals uitputting van resources of configuratiefouten, gevolgen hebben voor alle API's binnen de organisatie.
• Afzonderlijke gateways gebruiken voor verschillende use cases : werkruimten groeperen op een werkruimtegateway op basis van een use-case of netwerkvereisten. U kunt bijvoorbeeld onderscheid maken tussen interne en externe API's door ze toe te wijzen aan afzonderlijke gateways, elk met een eigen netwerkconfiguratie.
• Voorbereiding voor het in quarantaine plaatsen van werkruimten : gebruik een proxy, zoals Azure Application Gateway of Azure Front Door, voor de gateways van een gedeelde werkruimte om het verplaatsen van een werkruimte die bronuitputting veroorzaakt naar een andere gateway te vereenvoudigen. Deze aanpak voorkomt gevolgen voor andere werkruimten die de gateway delen.

Hostnaam van de werkruimtegateway

Elke werkruimtegateway biedt een unieke hostnaam voor API's die worden beheerd in een gekoppelde werkruimte. Standaardhostnamen volgen het patroon <gateway-name>-<hash>.gateway.<region>.azure-api.net. Gebruik de hostnaam van de gateway om API-aanvragen naar de API's van uw werkruimte te routeren.

Momenteel bieden werkruimtegateways geen ondersteuning voor aangepaste hostnamen. U kunt Azure Application Gateway of Azure Front Door configureren met een aangepaste hostnaam voor een werkruimtegateway.

Netwerkisolatie voor werkruimtegateways

U kunt eventueel een gatewayresource voor een werkruimte configureren in een privé virtueel netwerk om inkomend en uitgaand verkeer te isoleren. Als u deze isolatie configureert, moet de werkruimtegateway een toegewezen subnet in het virtuele netwerk gebruiken.

Zie Netwerkresourcevereisten voor werkruimtegateways voor gedetailleerde vereisten.

Capaciteit opschalen voor gateways voor werkruimten

Beheer de capaciteit van een werkruimtegateway door schaaleenheden toe te voegen of te verwijderen, vergelijkbaar met de eenheden die u kunt toevoegen aan het API Management-exemplaar in bepaalde servicelagen. De kosten van een werkruimtegateway zijn gebaseerd op het aantal eenheden dat u selecteert.

Regionale beschikbaarheid van gateways voor werkruimten

Zie Beschikbaarheid van v2-lagen en werkruimtegateways voor een actuele lijst van regio's waar werkruimtegateways beschikbaar zijn.

Beperkingen van werkruimte en gateway voor werkruimten

Beperkingen voor werkruimten

• Een werkruimte kan niet worden gekoppeld aan een zelf-hostende gateway
• API's in werkruimten vallen niet onder Defender for API's
• Werkruimten bieden geen ondersteuning voor referentiebeheer
• Werkruimten ondersteunen alleen interne cache; externe cache wordt niet ondersteund
• Werkruimten bieden geen ondersteuning voor synthetische GraphQL-API's
• Werkruimten bieden geen ondersteuning voor het rechtstreeks maken van API's vanuit Azure resources, zoals Azure OpenAI Service, App Service, Functie-apps, enzovoort in de Azure-portal
• Werkruimten bieden geen ondersteuning voor MCP-servers
• Metrische gegevens van aanvragen kunnen niet worden gesplitst per werkruimte in Azure Monitor; alle metrische gegevens van de werkruimte worden geaggregeerd op serviceniveau
• Werkruimten bieden geen ondersteuning voor CA-certificaten
• Werkruimten bieden geen ondersteuning voor beheerde identiteiten, waaronder gerelateerde functies zoals het opslaan van geheimen in Azure Key Vault en het gebruik van het beleid authentication-managed-identity

Gatewaybeperkingen voor werkruimten

De volgende beperkingen zijn van toepassing op de gatewayresource van de beheerde werkruimte. Ze zijn niet van toepassing wanneer u werkruimten gebruikt op de standaard beheerde gateway van de service.

• Werkruimtegateways bieden geen ondersteuning voor binnenkomende privé-eindpunten
• Werkruimtegateways bieden geen ondersteuning voor aangepaste hostnamen
• Werkruimten kunnen alleen worden gekoppeld aan werkruimtegateways in dezelfde regio en hetzelfde abonnement als de API Management-resource

Erfenis van wereldwijd beleid in werkruimtegateways

Werkruimtegateways voeren de volledige beleidsketen uit, inclusief het wereldwijde beleid op serviceniveau (global.policy.xml). Dit gedrag betekent dat elk beleid dat is gedefinieerd op het globale bereik, wordt geëvalueerd en uitgevoerd voor API-aanroepen die worden verwerkt door werkruimtegateways, net zoals voor de standaardgateway. Dit gedrag is standaard en consistent met het API Management-beleidsevaluatiemodel, waarbij u beleid hiërarchisch toepast op de volgende bereiken: globale (service) > werkruimteproduct-API-bewerking >>> .

Aanbevelingen voor globaal beleid met werkruimtegateways

• Controleer uw globale beleid om ervoor te zorgen dat het alleen beleidsregels bevat die zijn bedoeld om toe te passen op alle gateways, inclusief werkruimtegateways.

• Als u per gateway ander gedrag nodig hebt, gebruikt u het choose-beleid met context.Deployment.Gateway.Id om beleid voorwaardelijk uit te voeren op basis van de gateway die het verzoek verwerkt.

• Als u een door verificatie beheerde identiteit definieert in het globale bereik, maar het token niet beschikbaar moet zijn voor API's met werkruimtebereik, verplaatst u het beleid naar een smaller bereik (bijvoorbeeld product- of API-niveau) in plaats van het globale beleid.

RBAC-rollen voor werkplekken

Azure RBAC wordt gebruikt om de machtigingen van medewerkers voor werkruimten te configureren voor het lezen en bewerken van entiteiten in de werkruimte. Zie Op rollen gebaseerd toegangsbeheer gebruiken in API Management voor een lijst met rollen.

Als u API's en andere resources in de werkruimte wilt beheren, wijst u rollen toe aan werkruimteleden (of gelijkwaardige machtigingen via aangepaste rollen) die zijn afgestemd op de API Management-service en de werkruimte. Met de rol met servicespecifiek bereik kunt u vanuit werkruimteniveau resources verwijzen naar bepaalde resources op serviceniveau. Organiseer bijvoorbeeld een gebruiker in een groep op werkruimteniveau om de API en de zichtbaarheid van producten te beheren.

Als de werkruimte gebruikmaakt van een toegewezen werkruimtegateway, moeten leden die de gateway beheren, ook een rol toegewezen krijgen die is afgestemd op de werkruimtegatewayresource.

Werkruimten en andere API Management-functies

Werkruimten zijn zelfstandig om de scheiding van beheerderstoegang en API-runtime te maximaliseren. Om een hogere productiviteit te garanderen en platformbrede governance, waarneembaarheid, herbruikbaarheid en API-detectie mogelijk te maken, bestaan er verschillende uitzonderingen.

• Resourceverwijzingen : resources in een werkruimte kunnen verwijzen naar andere resources in de werkruimte en geselecteerde resources op serviceniveau, zoals gebruikers, autorisatieservers of ingebouwde gebruikersgroepen. Ze kunnen niet verwijzen naar resources uit een andere werkruimte.

  Om veiligheidsredenen kunt u niet vanuit beleid op werkruimteniveau verwijzen naar resources op serviceniveau (bijvoorbeeld benoemde waarden) of via resourcenamen, zoals backend-id in het set-backend-service-beleid.

  Important

  Alle resources in een API Management-service (bijvoorbeeld API's, producten, tags of abonnementen) moeten unieke namen hebben, zelfs als ze zich in verschillende werkruimten bevinden. U kunt geen resources van hetzelfde type en met dezelfde Azure resourcenaam in dezelfde werkruimte, in andere werkruimten of op serviceniveau hebben.

• Ontwikkelaarsportal : werkruimten zijn een beheerconcept en worden niet als zodanig weergegeven voor gebruikers van de ontwikkelaarsportal, zoals via de gebruikersinterface van de ontwikkelaarsportal en de onderliggende API. U kunt API's en producten in een werkruimte publiceren naar de ontwikkelaarsportal, net zoals API's en producten op serviceniveau.

  Note

  API Management biedt ondersteuning voor het toewijzen van autorisatieservers die zijn gedefinieerd op serviceniveau aan API's binnen werkruimten.

Migreren vanuit preview-werkruimten

Als u preview-werkruimten hebt gemaakt in Azure API Management en deze wilt blijven gebruiken, migreert u uw werkruimten naar de algemeen beschikbare versie door een werkruimtegateway te koppelen aan elke werkruimte.

Zie Kritieke wijzigingen in werkruimten (maart 2025) voor details en meer informatie over andere wijzigingen die van invloed kunnen zijn op uw preview-werkruimten.

Een werkruimte verwijderen

Wanneer u een werkruimte verwijdert met behulp van de Azure portalinterface, verwijdert u ook alle onderliggende resources (API's, producten, enzovoort) en een toegewezen werkruimtegateway als er een is gekoppeld. Het API Management-exemplaar of andere werkruimten worden niet verwijderd.

Verwante inhoud

• Een werkruimte maken
• Breekbare wijzigingen in werkruimten - juni 2024
• Brekende wijzigingen in werkruimtes - maart 2025
• Limieten - API Management-werkruimten