Questi servizi nascono raggiungibili da Internet. Il punto è capire quale controllo è un confine di autenticazione e quale è solo un ostacolo.
Azure Functions: le chiavi non sono autenticazione
Una funzione con trigger HTTP ha un livello di autorizzazione. Se non è anonymous, la richiesta deve portare una chiave, nella query ?code= o nell’intestazione x-functions-key. I tipi sono quattro: function (una sola funzione), host (tutte le funzioni dell’app), master — si chiama _master, ha livello admin, apre le API REST del runtime sotto /admin ed è una credenziale amministrativa — e system, create da alcune estensioni.
Le chiavi «provide some protection against unwanted access», dice la documentazione, ma per la produzione indica altro. Una chiave non porta identità: non puoi decidere nulla in base a chi chiama. E vive nello store dei segreti dell’app con un ciclo di vita indipendente dalle funzioni: cancellare una funzione non ruota niente, e ricrearla con lo stesso nome riusa le chiavi vecchie. Per revocare devi ruotare o eliminare la chiave. Gli endpoint /admin si spengono con la proprietà di sito functionsRuntimeAdminIsolationEnabled a true.
Sulla rete comanda il piano: le restrizioni in ingresso valgono ovunque, ma i private endpoint richiedono Flex Consumption, Elastic Premium o Dedicated. Consumption non li supporta, né l’integrazione con la rete virtuale in uscita.
App Service: Easy Auth, restrizioni di accesso, Key Vault
Easy Auth intercetta ogni richiesta prima del tuo codice: modulo IIS nella stessa sandbox su Windows, container separato su Linux. La riga da ricordare è «By default, this feature provides only authentication, not authorization». Scegli fra Allow unauthenticated requests, dove l’autorizzazione la fa il tuo codice leggendo le identità dalle intestazioni, e Require authentication, che respinge tutto rispondendo 302 verso il provider (siti) o 401 (API). Con Front Door davanti metti forwardProxy su Standard, o il redirect di login rimanda all’FQDN dell’App Service scavalcando il CDN.
Le restrizioni di accesso sono ACL nei front-end, a monte dei worker. Si valutano per priorità crescente e appena esiste una regola scatta un deny all implicito in fondo, salvo cambiare Unmatched rule action; il limite è 512 regole. Il sito SCM (Kudu, web deploy) ha una lista sua o eredita quella del sito principale. Per accettare solo la tua istanza di Front Door il service tag AzureFrontDoor.Backend non basta — vale per tutti i clienti — e va combinato col filtro sull’intestazione X-Azure-FDID.
I riferimenti a Key Vault tolgono il segreto dall’impostazione applicativa: servono un’identità gestita e, sul vault, il ruolo Key Vault Secrets User (RBAC) o il permesso Get (criteri di accesso). Il valore resta in cache e si aggiorna entro 24 ore; solo un cambio di configurazione forza il refresh.
Logic Apps: l’URL del trigger è la credenziale
Nei flussi con trigger a richiesta la firma di accesso condiviso sta dentro l’URL di callback (parametri sp, sv, sig): chi ha quell’URL fa partire il flusso. Rigenerare la chiave in Access keys invalida tutti gli URL già distribuiti. Puoi generare URL a scadenza passando NotAfter a listCallbackUrl e, nelle Consumption, disattivare la firma con sasAuthenticationPolicy su Disabled — nelle Standard non si disattiva, si affianca. L’alternativa forte è il criterio OAuth con Microsoft Entra ID, che valida almeno iss e aud.
La cronologia delle esecuzioni contiene spesso più dati sensibili del flusso: secureInputs e secureOutputs oscurano ingressi e uscite di una singola azione, e i dati protetti non vengono inviati a Log Analytics (alcune operazioni predefinite non li supportano). Sull’identità: la risorsa ha una sola identità assegnata dal sistema (attiva d’ufficio nelle Standard) e può averne più assegnate dall’utente, ma ne usa una sola alla volta.
WAF: Application Gateway e Front Door non sono equivalenti
Su Application Gateway i criteri WAF esistono solo per WAF_v2 e si associano a livello globale, per sito o per URI. In Detection il WAF registra e basta; in Prevention blocca con un 403. Con CRS 3.x l’azione predefinita è l’anomaly score: una regola Critical vale 5, una Warning 3, la soglia di blocco è 5 — una sola Critical blocca, due Warning no. Le regole personalizzate si valutano prima di quelle gestite. Tieni un WAF nuovo in Detection, raccogli i log e costruisci le esclusioni prima di passare a Prevention.
Su Front Door conta il livello: con Standard sono supportate solo le regole personalizzate, i set gestiti richiedono Premium. Front Door ha in più l’azione Redirect e le regole di limitazione della frequenza, ma ammette un solo criterio WAF per dominio.
API Management: la subscription key non è un’autenticazione
La chiave di sottoscrizione traccia i consumi e lega un chiamante a un prodotto. La documentazione la declassa: «On its own, a subscription key isn’t a strong form of authentication». Il controllo vero al gateway è validate-jwt, o validate-azure-ad-token se l’emittente è Entra. Sta in sezione inbound e i default sono ragionevoli: failed-validation-httpcode 401, require-expiration-time e require-signed-tokens a true, clock-skew a 0 secondi. Dichiara sempre audiences e issuers: un token valido per un’altra applicazione resta valido.
Per il mutual TLS c’è un prerequisito nascosto: context.Request.Certificate restituisce il certificato solo se negotiateClientCertificate è attivo sul dominio personalizzato, e il valore predefinito è False. Nei livelli Developer, Basic, Standard e Premium l’opzione è Negotiate client certificate; in Consumption e nei livelli v2 è Request client certificate. In Consumption i certificati CA non sono supportati, quindi gli autofirmati non si validano. Preferisci il criterio validate-client-certificate, con validate-revocation, validate-trust, validate-not-before e validate-not-after a true.
Completano il kit rate-limit-by-key e quota-by-key, validate-content con max-size, ip-filter in allowlist e i segreti in named values legati a Key Vault.