Federatief API-beheer met werkruimten

VAN TOEPASSING OP: 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 werkruimtegateways voor het routeren van API-verkeer naar de back-endservices van API's in de werkruimte.
• Het platformteam kan API-beleid toepassen op API's in werkruimten en 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 werkruimten kunnen deze teams API Management gebruiken om hun API's afzonderlijk te beheren, te openen en te beveiligen, en onafhankelijk van het beheren van de service-infrastructuur.

Hier volgt een voorbeeldwerkstroom 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, bijvoorbeeld machtigingen voor het maken of lezen van resources in de werkruimte. Er wordt ook een API-gateway met werkruimtebereik gemaakt voor de werkruimte.

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 werkruimtegateways om runtime van API's in de werkruimte in te schakelen. Een werkruimtegateway is een zelfstandige Azure-resource (werkruimtegateway premium) met dezelfde kernfunctionaliteit als de gateway die is ingebouwd in uw API Management-service.

Werkruimtegateways worden onafhankelijk van de API Management-service en van elkaar beheerd. Ze maken isolatie van runtime mogelijk tussen werkruimten of gebruiksvoorbeelden, waardoor de betrouwbaarheid, tolerantie en beveiliging van API's toenemen en runtimeproblemen kunnen worden toegewezen aan werkruimten.

• 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 een bepaalde configuratie (zoals virtueel netwerk, schaal, hostnaam) en toegewezen rekenresources (CPU, geheugen, netwerkresources).
• Configuratie- en computing hulpbronnen worden gedeeld door alle werkruimten die op een gateway zijn geïmplementeerd.
• Fouten 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 op een gateway worden geïmplementeerd, hoe hoger het risico dat een API uit een werkruimte betrouwbaarheidsproblemen ondervindt die worden veroorzaakt door een API uit een andere werkruimte.
• Bewaak de prestaties van uw gateway met behulp van ingebouwde metrische gegevens voor CPU- en geheugengebruik.

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

• Toegewezen gateways gebruiken voor bedrijfskritieke workloads : als u de betrouwbaarheid en beveiliging van de API wilt maximaliseren, wijst u elke bedrijfskritieke werkruimte toe aan een eigen gateway, zodat u geen gedeeld gebruik met andere werkruimten kunt gebruiken.
• Balans tussen betrouwbaarheid, beveiliging en kosten : koppel meerdere werkruimten aan een gateway om de betrouwbaarheid, beveiliging en kosten voor niet-kritieke workloads te verdelen. Het verdelen van werkplekken over ten minste twee gateways helpt voorkomen dat problemen zoals resourceuitputting of configuratiefouten alle API's binnen de organisatie beïnvloeden.
• Afzonderlijke gateways gebruiken voor verschillende use cases : werkruimten groeperen op een gateway 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.
• Bereid u voor op het in quarantaine plaatsen van problematische werkruimten; gebruik een proxy, zoals Azure Application Gateway of Azure Front Door, voor gedeelde werkruimtegateways om het verplaatsen van een werkruimte die overbelasting veroorzaakt naar een andere gateway te vereenvoudigen, waardoor de impact op andere werkruimten die de gateway delen, wordt voorkomen.

Hostnaam van gateway

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.

Op dit moment worden aangepaste hostnamen niet ondersteund voor werkruimtegateways. U kunt Azure Application Gateway of Azure Front Door configureren met een aangepaste hostnaam voor een werkruimtegateway.

Netwerkisolatie

Een werkruimtegateway kan eventueel worden geconfigureerd in een particulier virtueel netwerk om inkomend en/of uitgaand verkeer te isoleren. Als deze is geconfigureerd, moet de werkruimtegateway een toegewezen subnet in het virtuele netwerk gebruiken.

Zie Netwerkresourcevereisten voor werkruimtegateways voor gedetailleerde vereisten.

Capaciteitsschaal

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

Regionale beschikbaarheid

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

Gatewaybeperkingen

De volgende beperkingen zijn momenteel van toepassing op werkruimtegateways:

• Een werkruimte kan niet worden gekoppeld aan een zelf-hostende gateway
• Werkruimtegateways bieden geen ondersteuning voor binnenkomende privé-eindpunten
• API's in werkruimtegateways kunnen niet worden toegewezen aan aangepaste hostnamen
• API's in werkruimten vallen niet onder Defender for API's
• Werkruimtegateways bieden geen ondersteuning voor referentiebeheer van de API Management-service
• Werkruimtegateways ondersteunen alleen interne cache; externe cache wordt niet ondersteund
• Werkruimtegateways bieden geen ondersteuning voor synthetische GraphQL-API's
• Werkruimtegateways bieden geen ondersteuning voor het rechtstreeks maken van API's vanuit Azure-resources, zoals Azure OpenAI Service, App Service, Functie-apps, enzovoort
• Werkruimtegateways 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
• Werkruimtegateways bieden geen ondersteuning voor CA-certificaten
• Werkruimtegateways bieden geen ondersteuning voor beheerde identiteiten, waaronder gerelateerde functies zoals het opslaan van geheimen in Azure Key Vault en het gebruik van het authentication-managed-identity beleid
• Werkruimtegateways kunnen alleen worden gemaakt in de primaire Azure-regio van het API Management-exemplaar

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, moeten rollen (of gelijkwaardige machtigingen met behulp van aangepaste rollen) aan werkruimteleden worden toegekend binnen de service voor API-beheer, de werkruimte en de werkruimtegateway. 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.

Werkruimten en andere API Management-functies

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

• 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 is het niet mogelijk om vanuit beleid op werkruimteniveau te verwijzen naar resources op serviceniveau (zoals genaamde waarden) of naar resourcenamen, zoals backend-id in het beleid set-backend-service.

  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. Er kunnen geen resources van hetzelfde type zijn en met dezelfde Azure-resourcenaam in dezelfde werkruimte, in andere werkruimten of op serviceniveau.

• 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. API's en producten binnen een werkruimte kunnen worden gepubliceerd naar de ontwikkelaarsportal, net als 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

Als u een werkruimte verwijdert, worden alle onderliggende resources (API's, producten enzovoort) en de bijbehorende gateway verwijderd, als u de werkruimte verwijdert met behulp van de Interface van Azure Portal. 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