Componenti e tier di API Management

Azure API Management (APIM) è la facciata unificata che espone le tue API a client interni ed esterni, disaccoppiandoli dai backend. I componenti principali sono:

  • Gateway: il runtime che riceve ogni chiamata, applica le policy e la instrada al backend. Può essere managed (nel cloud) o self-hosted (container in on-premises o altri cloud per scenari ibridi).
  • Management plane: configurazione via portale, ARM/Bicep, Azure CLI.
  • Developer portal: sito personalizzabile dove gli sviluppatori scoprono le API, leggono la documentazione e ottengono le key.

Scelta del tier

  • Consumption: serverless, pay-per-call, scala automaticamente fino a zero. Ideale per carichi variabili o event-driven, ma NON supporta tutte le feature (niente self-hosted gateway, cache interna assente → serve una cache esterna).
  • Tier dedicati (Developer, Basic, Standard, Premium): capacità riservata per unità. Premium aggiunge multi-region, VNet injection, self-hosted gateway e SLA più alto; Developer è solo per non-produzione.

Regola d’esame: carico intermittente e imprevedibile → Consumption; isolamento di rete, multi-region o ibrido → Premium.

Prodotti e subscription

Un’API non viene consumata direttamente: viene raggruppata in un product, che definisce i termini d’uso (policy, quota) e può essere published o meno, aperto oppure con approvazione. Il client ottiene una subscription al product, che genera le subscription key (primary/secondary, per consentire la rotazione senza downtime). La key viaggia di default nell’header Ocp-Apim-Subscription-Key.

Le policy: inbound, backend, outbound

Le policy sono il cuore di APIM: documenti XML applicati per scope (all APIs → product → API → operation) e organizzati in fasi. Le tre principali:

  • inbound: prima di inoltrare al backend — autenticazione, rate-limit/quota, validate-jwt, rewrite-uri, set-header, IP filter.
  • backend: attorno alla chiamata al servizio a valle (es. iniezione della managed identity).
  • outbound: prima di restituire la risposta — set-header per rimuovere header interni, trasformazioni, caching.

Policy chiave da conoscere:

  • rate-limit vs quota: throttling a breve termine (es. 10 chiamate/60s) contro limite di volume nel tempo (es. 10.000/mese). Le varianti rate-limit-by-key e quota-by-key applicano il limite per subscription, IP o claim del token.
  • cache-lookup / cache-store: response caching per ridurre i round-trip al backend (in Consumption richiede una cache esterna come Azure Cache for Redis).
  • set-header / rewrite-uri: manipolazione di header e path.

Modelli di sicurezza

Il principio è difesa a più livelli: mai affidarsi a un solo controllo.

  • Subscription key: identifica il chiamante ai fini di tracking e quota, ma NON è autenticazione forte — è un segreto condiviso facilmente esfiltrabile.
  • validate-jwt (OAuth2/OIDC): il vero controllo di autorizzazione. Valida firma, iss, aud, scadenza e i claim/scope del token emesso da Microsoft Entra ID:
<validate-jwt header-name="Authorization" failed-validation-httpcode="401">
  <openid-config url="https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration" />
  <required-claims>
    <claim name="roles" match="any"><value>API.Read</value></claim>
  </required-claims>
</validate-jwt>
  • Client certificate / mutual TLS: validate-client-certificate (o controllo di thumbprint/issuer) garantisce che solo client con certificato valido raggiungano il gateway.
  • Managed identity verso il backend: il gateway usa la propria system/user-assigned managed identity per ottenere un token (policy authentication-managed-identity) e chiamare backend protetti da Entra ID, Key Vault o Storage, eliminando i segreti hard-coded.

Trappole tipiche d’esame

  • Sicurezza affidata solo alla subscription key → sbagliato: la key non autentica l’utente. Aggiungi validate-jwt in inbound per validare i token OAuth2 in ingresso; la key resta utile solo per quota/tracking.
  • Serve limitare 5 chiamate ogni 60 secondi per singolo client → usa rate-limit-by-key con la subscription/claim come chiave, NON quota (che governa il volume aggregato di lungo periodo).
  • Il backend richiede autenticazione Entra ID senza gestire segreti → configura la managed identity di APIM con authentication-managed-identity, non credenziali in una named value.
  • Carico serverless a picchi imprevedibili con costi a chiamata → tier Consumption; se serve VNet injection o self-hosted gateway, allora Premium.
  • Rimuovere header interni dalla risposta → set-header con exists-action="delete" nella fase outbound, non inbound.
  • Response caching in Consumption → serve una cache esterna (Redis): la cache interna esiste solo nei tier dedicati.