Gestione API federata con aree di lavoro

VALIDO PER: Basic v2 | Standard v2 | Premium | Premium v2

Questo articolo offre una panoramica delle aree di lavoro di Gestione API e del modo in cui consentono ai team di sviluppo decentralizzato di API di gestire e prodotto le API in un'infrastruttura di servizi comune.

Perché le organizzazioni devono eseguire la federazione della gestione API?

Oggi, le organizzazioni affrontano sempre più sfide nella gestione di una proliferazione di API. Man mano che aumenta il numero di API e di team di sviluppo API, cresce anche la complessità della loro gestione. Questa complessità può comportare un aumento del sovraccarico operativo, dei rischi per la sicurezza e una riduzione dell'agilità. Da un lato, le organizzazioni vogliono stabilire un'infrastruttura API centralizzata per garantire la governance, la sicurezza e la conformità delle API. D'altra parte, vogliono che i team API possano innovare e rispondere rapidamente alle esigenze aziendali, senza il sovraccarico della gestione di una piattaforma API.

Un modello federato di Gestione API soddisfa queste esigenze. La gestione API federata consente la gestione decentralizzata delle API da parte dei team di sviluppo con l'isolamento appropriato dei piani di controllo e dati, mantenendo al contempo governance centralizzata, monitoraggio e individuazione API gestita da un team della piattaforma API. Questo modello supera le limitazioni degli approcci alternativi, ad esempio la gestione API completamente centralizzata dal team della piattaforma o dalla gestione API siloed da ogni team di sviluppo.

Gestione API federata offre:

• Governance centralizzata delle API e osservabilità
• Portale per sviluppatori unificato per l'individuazione e l'onboarding efficaci delle API
• Autorizzazioni amministrative separate tra i team API, migliorando la produttività e la sicurezza
• Runtime API segregato tra team API, migliorando affidabilità, resilienza e sicurezza

Come le aree di lavoro abilitano la gestione API federata

In Azure Gestione delle API, usare aree di lavoro per implementare la gestione delle API federata. Le aree di lavoro funzionano come "cartelle" all'interno di un servizio Gestione API:

• Ogni area di lavoro contiene API, prodotti, sottoscrizioni, valori denominati e risorse correlate. Per un elenco completo delle risorse e delle operazioni supportate nelle aree di lavoro, vedere le informazioni di riferimento sull'API REST di Gestione API.
• L'accesso alle risorse all'interno di un'area di lavoro viene gestito tramite il controllo degli accessi in base al ruolo di Azure con ruoli predefiniti o personalizzati assegnabili agli account Microsoft Entra e con ambito a un'area di lavoro.
• Ogni area di lavoro è associata a uno o più gateway per il routing del traffico API ai servizi back-end delle API nell'area di lavoro. A seconda del livello di servizio e dei requisiti, un'area di lavoro può usare il gateway gestito predefinito del servizio o uno o più gateway dell'area di lavoro.
• Il team dedicato alla piattaforma può applicare criteri che spaziano dalle API ai prodotti nelle aree di lavoro per gestire il runtime API in tutta l'organizzazione. Una definizione predefinita di Criteri di Azure (API Management policies should inherit parent scope policies using <base/>) consente di controllare o imporre che questi criteri vengano applicati in tutte le risorse dell'area di lavoro.
• Il team dedicato alla piattaforma può implementare un'esperienza centralizzata di individuazione API con un portale per sviluppatori.
• Ogni team dell'area di lavoro può raccogliere e analizzare i log delle risorse del gateway per monitorare le proprie API dell'area di lavoro, mentre il team della piattaforma ha federato l'accesso ai log in tutte le aree di lavoro nel servizio Gestione API, fornendo supervisione, sicurezza e conformità nell'ecosistema API.

Anche se le aree di lavoro vengono gestite in modo indipendente dal servizio Gestione API e da altre aree di lavoro, è possibile fare riferimento alle risorse a livello di servizio selezionate. Vedere Aree di lavoro e altre funzionalità di Gestione API più avanti in questo articolo.

Panoramica degli scenari di esempio

Un'organizzazione che gestisce le API usando Gestione API di Azure potrebbe avere più team di sviluppo che sviluppano, definiscono, gestiscono e prodotto set diversi di API. Usando le aree di lavoro, questi team possono usare Gestione API per gestire, accedere e proteggere le API separatamente e indipendentemente dalla gestione dell'infrastruttura del servizio.

Il flusso di lavoro seguente illustra un processo di esempio per la creazione e l'uso di un'area di lavoro.

1. Un team centrale della piattaforma API che gestisce l'istanza di API Management crea un'area di lavoro e assegna ai collaboratori dell'area di lavoro le autorizzazioni tramite i ruoli RBAC. Ad esempio, assegnare le autorizzazioni per creare o leggere risorse nell'area di lavoro. Il team crea o associa un gateway API all'area di lavoro per instradare il traffico dell'API.

2. Un team centrale della piattaforma API usa gli strumenti DevOps per creare una pipeline DevOps per le API in tale area di lavoro.

3. I membri dell'area di lavoro sviluppano, pubblicano, generano e mantengono le API nell'area di lavoro.

4. Il team centrale della piattaforma API gestisce l'infrastruttura del servizio, ad esempio il monitoraggio, la resilienza e l'applicazione dei criteri di tutte le API.

Gateway dell'area di lavoro

Ogni area di lavoro è configurata con uno o più gateway per abilitare il runtime di API gestite all'interno dell'area di lavoro. A seconda del livello di servizio e dei requisiti, è possibile usare il gateway gestito predefinito del servizio e/o uno o più gateway dell'area di lavoro (risorse gateway separate).

Gateway gestito predefinito

Nei livelli v2 è possibile configurare un'area di lavoro per instradare il traffico API attraverso il gateway gestito predefinito del servizio, oltre a una o più risorse gateway dell'area di lavoro separate. Quando un'area di lavoro usa il gateway gestito predefinito:

• Il traffico DELL'API viene instradato attraverso il nome host predefinito del servizio , ad esempio <service-name>.azure-api.net.
• L'area di lavoro condivide la capacità e la configurazione del gateway con altre aree di lavoro e API a livello di servizio.

Gateway dell'area di lavoro

Un gateway dell'area di lavoro è una risorsa Azure autonoma (workspace gateway Premium) con le stesse funzionalità principali del gateway gestito predefinito.

I gateway dell'area di lavoro vengono gestiti in modo indipendente dal servizio Gestione API e l'uno dall'altro. Consentono l'isolamento del runtime tra aree di lavoro o casi d'uso, che aumentano l'affidabilità, la resilienza e la sicurezza delle API. Consentono anche l'attribuzione dei problemi di runtime alle aree di lavoro.

• Per informazioni sul costo dei gateway dell'area di lavoro, vedere Prezzi di Gestione API.
• Per un confronto dettagliato dei gateway di Gestione API, vedere Panoramica dei gateway di Gestione API.

Associare aree di lavoro a un gateway dell'area di lavoro

A seconda delle esigenze dell'organizzazione, è possibile associare un'area di lavoro o più aree di lavoro a un gateway dell'area di lavoro.

• Un gateway dell'area di lavoro ha determinate impostazioni di configurazione, ad esempio rete virtuale, scalabilità e nome host e risorse di calcolo allocate, tra cui CPU, memoria e risorse di rete.
• Tutte le aree di lavoro distribuite in un gateway condividono la configurazione e le risorse di calcolo.
• I bug in un'API o un traffico anomalo possono causare l'esaurimento di queste risorse, che influisce su tutte le aree di lavoro nel gateway. In altre parole, più aree di lavoro distribuite in un gateway, maggiore è il rischio che un'API di un'area di lavoro riscontra problemi di affidabilità causati da un'API da un'altra area di lavoro.
• Monitorare le prestazioni del gateway dell'area di lavoro usando le metriche predefinite per l'utilizzo della CPU e della memoria.

Prendere in considerazione affidabilità, sicurezza e costi quando si sceglie un modello di distribuzione per le aree di lavoro.

• Assegnare un'area di lavoro al proprio gateway dell'area di lavoro dedicato per carichi di lavoro cruciali : per ottimizzare l'affidabilità e la sicurezza delle API, assegnare ogni area di lavoro cruciale al proprio gateway, evitando l'uso condiviso con altre aree di lavoro.
• Bilanciare l'affidabilità, la sicurezza e i costi : associare più aree di lavoro a un gateway dell'area di lavoro (o, se applicabile, il gateway gestito predefinito) per bilanciare affidabilità, sicurezza e costi per carichi di lavoro non critici. Distribuire le aree di lavoro tra almeno due gateway per evitare problemi, ad esempio l'esaurimento delle risorse o gli errori di configurazione, che influiscono su tutte le API all'interno dell'organizzazione.
• Usare gateway distinti per casi d'uso diversi : raggruppare le aree di lavoro in un gateway dell'area di lavoro in base a un caso d'uso o a requisiti di rete. Ad esempio, è possibile distinguere tra LE API interne ed esterne assegnandole a gateway separati, ognuna con la propria configurazione di rete.
• Prepare per mettere in quarantena le aree di lavoro con problemi: usare un proxy, ad esempio gateway applicazione di Azure o Frontdoor di Azure, davanti ai gateway dell'area di lavoro condivisa per semplificare lo spostamento di un'area di lavoro che causa l'esaurimento delle risorse in un gateway diverso. Questo approccio impedisce l'impatto su altre aree di lavoro che condividono il gateway.

Nome host del gateway dello spazio di lavoro

Ogni gateway dell'area di lavoro fornisce un nome host univoco per le API gestite in un'area di lavoro associata. I nomi host predefiniti seguono il modello <gateway-name>-<hash>.gateway.<region>.azure-api.net. Usare il nome host del gateway per instradare le richieste API alle API dell'area di lavoro.

Attualmente, i gateway dell'area di lavoro non supportano nomi host personalizzati. È possibile configurare gateway applicazione di Azure o Frontdoor di Azure con un nome host personalizzato per un gateway dell'area di lavoro.

Isolamento di rete per i gateway dell'area di lavoro

Facoltativamente, è possibile configurare una risorsa gateway dell'area di lavoro in una rete virtuale privata per isolare il traffico in ingresso e in uscita. Se si configura questo isolamento, il gateway dell'area di lavoro deve usare una subnet dedicata nella rete virtuale.

Per i requisiti dettagliati, vedere Requisiti delle risorse di rete per i gateway dell'area di lavoro.

Aumentare la capacità per i gateway dell'area di lavoro

Gestire la capacità di un gateway dell'area di lavoro aggiungendo o rimuovendo unità di scala, analogamente alle unità che è possibile aggiungere all'istanza di Gestione API in determinati livelli di servizio. I costi di un gateway dell'area di lavoro si basano sul numero di unità selezionate.

Disponibilità regionale dei gateway dell'area di lavoro

Per un elenco corrente delle aree in cui sono disponibili i gateway dell'area di lavoro, vedere Disponibilità di livelli v2 e gateway dell'area di lavoro.

Vincoli dell'area di lavoro e del gateway dell'area di lavoro

Vincoli delle aree di lavoro

• Un'area di lavoro non può essere associata a un gateway self-hosted
• Le API nelle aree di lavoro non sono coperte da Defender per le API
• Le aree di lavoro non supportano gestione credenziali
• Le aree di lavoro supportano solo la cache interna; la cache esterna non è supportata
• Le aree di lavoro non supportano le API GraphQL sintetiche
• Le aree di lavoro non supportano la creazione di API direttamente da risorse Azure, ad esempio Servizio Azure OpenAI, servizio app, app per le funzioni e così via nel portale di Azure
• Le aree di lavoro non supportano i server MCP
• Le metriche delle richieste non possono essere suddivise per area di lavoro in Monitoraggio di Azure; tutte le metriche dell'area di lavoro vengono aggregate a livello di servizio
• Le aree di lavoro non supportano i certificati CA
• Le aree di lavoro non supportano le identità gestite, incluse le funzionalità correlate, ad esempio l'archiviazione di segreti in Azure Key Vault e l'uso dei criteri authentication-managed-identity

Vincoli del gateway dell'area di lavoro

I vincoli seguenti si applicano alla risorsa gateway dell'area di lavoro gestita. Non si applicano quando si usano aree di lavoro nel gateway gestito predefinito del servizio.

• I gateway dell'area di lavoro non supportano endpoint privati in ingresso
• I gateway dell'area di lavoro non supportano nomi host personalizzati
• Gli spazi di lavoro possono essere associati solo ai gateway dello spazio di lavoro che si trovano nella stessa area geografica e nella stessa sottoscrizione della risorsa di Gestione API

Ereditarietà dei criteri globali nei gateway dello spazio di lavoro

I gateway dell'area di lavoro eseguono l'intera catena di criteri, compresi i criteri globali a livello di servizio (global.policy.xml). Questo comportamento significa che tutti i criteri definiti nell'ambito globale vengono valutati ed eseguiti per le chiamate API elaborate dai gateway dell'area di lavoro, proprio come per il gateway predefinito. Questo comportamento è progettato e coerente con il modello di valutazione dei criteri di Gestione API, in cui si applicano i criteri gerarchicamente agli ambiti seguenti: operazione dell'API > del prodotto > globale (servizio) > dell'area di lavoro>.

Raccomandazioni per le politiche globali con i gateway degli spazi di lavoro

• Esaminare i criteri globali per assicurarsi che contenga solo i criteri da applicare in tutti i gateway, inclusi i gateway dell'area di lavoro.

• Se è necessario un comportamento diverso per ogni gateway, usare il criterio choose con context.Deployment.Gateway.Id per eseguire criteri in modo condizionale in base all'elaborazione della richiesta da parte del gateway.

• Se si definisce un authentication-managed-identity a livello globale, ma il token non deve essere disponibile per le API con ambito workspace, spostare il criterio in un ambito più ristretto (ad esempio, a livello di prodotto o di API) anziché nel criterio globale.

Ruoli controllo degli accessi in base al ruolo per le aree di lavoro

Azure RBAC viene usato per configurare i permessi dei collaboratori dell'area di lavoro per leggere e modificare le entità nell'area di lavoro. Per un elenco dei ruoli, vedere Come usare il controllo degli accessi in base al ruolo in API Management.

Per gestire API e altre risorse nell'area di lavoro, assegnare ruoli ai membri dell'area di lavoro (o autorizzazioni equivalenti tramite ruoli personalizzati) con ambito per il servizio Gestione API e l'area di lavoro. Il ruolo con ambito servizio consente di fare riferimento a determinate risorse a livello di servizio dalle risorse a livello di area di lavoro. Ad esempio, organizzare un utente in un gruppo a livello di area di lavoro per controllare la visibilità dell'API e del prodotto.

Se l'area di lavoro usa un gateway dedicato dell'area di lavoro, ai membri che gestiscono il gateway deve essere assegnato anche un ruolo limitato alla risorsa del gateway dell'area di lavoro.

Aree di lavoro e altre funzionalità di API Management

Le aree di lavoro sono autonome per ottimizzare la separazione dell'accesso amministrativo e del runtime dell'API. Per garantire una maggiore produttività e abilitare la governance a livello di piattaforma, l'osservabilità, la riutilizzabilità e l'individuazione delle API, esistono diverse eccezioni.

• Riferimenti alle risorse: le risorse in un'area di lavoro possono fare riferimento ad altre risorse nell'area e alle risorse selezionate dal livello di servizio, ad esempio utenti, server di autorizzazione o gruppi di utenti predefiniti. Non possono fare riferimento a risorse da un'altra area di lavoro.

  Per motivi di sicurezza, non è possibile fare riferimento, da criteri a livello di area di lavoro, a risorse a livello di servizio (ad esempio, valori denominati) o tramite nomi di risorse, ad esempio backend-id nel criterio set-backend-service.

  Important

  Tutte le risorse in un servizio di Gestione API (ad esempio, API, prodotti, tag o sottoscrizioni) devono avere nomi univoci, anche se si trovano in aree di lavoro diverse. Non è possibile avere risorse dello stesso tipo e con lo stesso nome di risorsa Azure nella stessa area di lavoro, in altre aree di lavoro o a livello di servizio.

• Portale per sviluppatori: le aree di lavoro sono un concetto amministrativo e non vengono visualizzate come tali per i consumer del portale per sviluppatori, tra cui tramite l'interfaccia utente del portale per sviluppatori e l'API sottostante. È possibile pubblicare API e prodotti all'interno di un'area di lavoro nel portale per sviluppatori, proprio come le API e i prodotti a livello di servizio.

  Note

  Gestione API supporta l'assegnazione di server di autorizzazione definiti a livello di servizio alle API all'interno delle aree di lavoro.

Eseguire la migrazione dalle aree di lavoro di anteprima

Se sono state create aree di lavoro in anteprima in Gestione API di Azure e si vuole continuare a usarle, eseguire la migrazione delle aree alla versione disponibile a livello generale associando un gateway del workspace a ogni area di lavoro.

Per informazioni dettagliate e per saperne di più su altre modifiche che potrebbero influire sulle aree di lavoro di anteprima, vedere Modifiche significative delle aree di lavoro (marzo 2025).

Eliminazione di un'area di lavoro

Quando si elimina un'area di lavoro usando l'interfaccia del portale di Azure, si eliminano anche tutte le relative risorse figlio (API, prodotti e così via) e un gateway dell'area di lavoro dedicato, se associato. Non elimina l'istanza di Gestione API o altre aree di lavoro.

Contenuti correlati

• Creare un'area di lavoro
• Modifiche che causano un'interruzione delle aree di lavoro - Giugno 2024
• Modifiche che causano un'interruzione delle aree di lavoro - Marzo 2025
• Limiti - Aree di lavoro di Gestione API