Condividi tramite

Gestione API federata con aree di lavoro

SI APPLICA A: Premium

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 dell'area di lavoro per il routing del traffico API ai servizi back-end delle API nell'area di lavoro.
  • Il team della piattaforma può applicare politiche API per le API all'interno delle aree di lavoro e implementare un'esperienza centralizzata di scoperta delle 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.

Diagramma concettuale del servizio Gestione API con aree di lavoro.

Nota

  • Le funzionalità più recenti dell'area di lavoro sono supportate nell'API REST di Gestione API versione 2023-09-01-preview o successiva.
  • Per considerazioni sui prezzi, vedere Prezzi di API Management.

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 che usano API Management di Azure può avere più team di sviluppo che sviluppano, definiscono, gestiscono e producono diversi set di API. Le aree di lavoro consentono a questi team di usare Gestione API per gestire, accedere e proteggere le API separatamente e indipendentemente dalla gestione dell'infrastruttura del servizio.

Di seguito è riportato un flusso di lavoro di esempio per la creazione e l'uso di un'area di lavoro.

  1. Il team centrale della piattaforma API che gestisce l'istanza di API Management crea un'area di lavoro e assegna le autorizzazioni ai collaboratori dell'area di lavoro utilizzando i ruoli di controllo degli accessi basati su ruolo (RBAC) - ad esempio, autorizzazioni per creare o leggere risorse nell'area di lavoro. Per l'area di lavoro viene creato anche un gateway API con ambito dell'area di lavoro.

  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 dell'area di lavoro per abilitare il runtime di API gestite all'interno dell'area di lavoro. Un gateway dell'area di lavoro è una risorsa di Azure autonoma (gateway dell'area di lavoro Premium) con le stesse funzionalità di base del gateway integrato nel servizio Gestione API.

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, aumentando l'affidabilità dell'API, la resilienza e la sicurezza e abilitando l'attribuzione dei problemi di runtime alle aree di lavoro.

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.

Nota

L'associazione di più aree di lavoro a un gateway dell'area di lavoro è disponibile solo per i gateway dell'area di lavoro creati dopo il 15 aprile 2025.

  • Un gateway dell'area di lavoro dispone di una determinata configurazione, ad esempio rete virtuale, scalabilità, nome host, e risorse di calcolo allocate (CPU, memoria, risorse di rete).
  • Le risorse di configurazione e calcolo sono condivise da tutte le aree di lavoro distribuite in un gateway.
  • I bug in un'API o un traffico anomalo possono causare l'esaurimento di queste risorse, che influiscono su tutte le aree di lavoro nel gateway. In altre parole, più aree di lavoro vengono distribuite in un gateway, maggiore è il rischio che un'API di un'area di lavoro verifichi problemi di affidabilità causati da un'API da un'altra area di lavoro.
  • Monitorare le prestazioni del gateway 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.

  • Usare gateway dedicati 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 per bilanciare affidabilità, sicurezza e costi per carichi di lavoro non critici. La distribuzione di aree di lavoro tra almeno due gateway consente di evitare problemi, ad esempio l'esaurimento delle risorse o gli errori di configurazione, dall'impatto su tutte le API all'interno dell'organizzazione.
  • Usare gateway distinti per casi d'uso diversi : raggruppare le aree di lavoro in un gateway in base a un caso d'uso o a requisiti di rete. Ad esempio, è possibile distinguere tra API interne ed esterne assegnandole a gateway separati, ognuna con la propria configurazione di rete.
  • Prepararsi a mettere in quarantena le aree di lavoro problematiche - Usare un proxy, ad esempio Azure Application Gateway o Azure Front Door, davanti ai gateway delle aree di lavoro condivise per semplificare lo spostamento di un'area di lavoro che causa l'esaurimento delle risorse a un altro gateway, impedendo l'impatto su altre aree di lavoro che condividono il gateway.

Nota

  • Un gateway dell'area di lavoro deve trovarsi nella stessa area dell'area di Azure primaria dell'istanza di Gestione API e nella stessa sottoscrizione
  • Tutte le aree di lavoro associate a un gateway dell'area di lavoro devono trovarsi nella stessa istanza di Gestione API
  • Un gateway dell'area di lavoro può essere associato a un massimo di 30 aree di lavoro (contattare il supporto tecnico per aumentare questo limite)

Nome host del gateway

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 nomi host personalizzati non sono supportati per i gateway dell'area di lavoro. È possibile configurare Azure Application Gateway o Azure Front Door con un nome host personalizzato per un gateway dell'area di lavoro.

Isolamento della rete

Un gateway dell'area di lavoro può essere configurato facoltativamente in una rete virtuale privata per isolare il traffico in ingresso e/o in uscita. Se configurato, 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.

Nota

  • La configurazione di rete di un gateway dell'area di lavoro è indipendente dalla configurazione di rete dell'istanza di Gestione API.
  • Attualmente, un gateway dell'area di lavoro può essere configurato in una rete virtuale solo quando viene creato. Non è possibile modificare la configurazione di rete o le impostazioni del gateway in un secondo momento.

Ridimensionare la capacità

Gestire la capacità del gateway aggiungendo o rimuovendo unità di scala, simili alle unità che possono essere aggiunte 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

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 del gateway

I vincoli seguenti si applicano attualmente ai gateway dell'area di lavoro:

  • Un'area di lavoro non può essere associata a un gateway self-hosted
  • I gateway dell'area di lavoro non supportano endpoint privati in ingresso
  • Le API nei gateway dell'area di lavoro non possono essere assegnate a nomi host personalizzati
  • Le API nelle aree di lavoro non sono coperte da Defender per le API
  • I gateway dell'area di lavoro non supportano la gestione credenziali del servizio Gestione API
  • I gateway dell'area di lavoro supportano solo la cache interna; la cache esterna non è supportata
  • I gateway dell'area di lavoro non supportano le API GraphQL sintetiche
  • I gateway dell'area di lavoro non supportano la creazione di API direttamente dalle risorse di Azure, ad esempio il servizio OpenAI di Azure, le servizio app, le app per le funzioni e così via
  • 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
  • I gateway dell'area di lavoro non supportano i certificati CA
  • I gateway di Workspace non supportano le identità gestite, incluse le funzionalità correlate come l'archiviazione di segreti in Azure Key Vault e l'uso della politica authentication-managed-identity.
  • I gateway dell'area di lavoro possono essere creati solo nell'area di Azure primaria dell'istanza di Gestione API

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 le API e altre risorse nell'area di lavoro, ai membri dell'area di lavoro devono essere assegnati ruoli (o autorizzazioni equivalenti usando ruoli personalizzati) con ambito per il servizio Gestione API, l'area di lavoro e il gateway dell'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.

Nota

Per semplificare la gestione, configurare i gruppi di Microsoft Entra per assegnare le autorizzazioni dell'area di lavoro a più utenti.

Aree di lavoro e altre funzionalità di API Management

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

  • 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 a risorse a livello di servizio da criteri a livello di area di lavoro (ad esempio, valori denominati) o da nomi di risorse, ad esempio backend-id nei criteri set-back-end-service.

    Importante

    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 possono esistere risorse dello stesso tipo e con lo stesso nome di risorsa di 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. Le API e i prodotti all'interno di un'area di lavoro possono essere pubblicati nel portale per sviluppatori, proprio come le API e i prodotti a livello di servizio.

    Nota

    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

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

Contenuto correlato