Un endpoint privato non è un controllo di accesso: è una scheda di rete. Confondere le due cose produce architetture che sembrano chiuse e non lo sono.

L’endpoint privato è una NIC, non un firewall

Azure crea una NIC in sola lettura nella subnet che indichi e le assegna un IP dinamico dallo spazio della VNet, che poi non cambia per tutta la vita dell’endpoint. L’endpoint sta nella stessa regione e sottoscrizione della VNet; la risorsa di destinazione può stare altrove. Le connessioni sono monodirezionali: le apre solo il client, il fornitore non ha un percorso di ritorno.

La frase da portarsi all’esame, dalla documentazione dello storage: creare un private link non blocca le connessioni sull’endpoint pubblico. Apre una porta privata, non chiude quella pubblica: il firewall dell’account e il flag di accesso alla rete pubblica sono configurazioni separate. Il rovescio è utile: dove un endpoint privato esiste, il traffico dalla VNet associata è sempre ammesso anche con l’accesso pubblico disabilitato, e non serve una regola di firewall per quella VNet, perché il firewall governa solo l’endpoint pubblico.

Un endpoint privato punta a una sotto-risorsa, non a un servizio: su uno storage account serve un endpoint per blob, uno per file, queue, table, web e dfs. Se pubblichi solo dfs, alcune operazioni vengono redirette al blob e falliscono; se pubblichi solo blob, Manage ACL o Create Directory falliscono perché richiedono l’endpoint DFS. Servono entrambi. E sugli account general-purpose v1 gli endpoint privati non esistono affatto.

Approvazione e criteri di rete sulla subnet

L’approvazione dipende dai permessi: se hai l’azione di approvazione sul tipo di risorsa è automatica, altrimenti parte una richiesta manuale e la connessione nasce Pending.

Microsoft.<Provider>/<resource_type>/privateEndpointConnectionsApproval/action

Gli stati sono quattro: Approved, Pending, Rejected, Disconnected, e solo Approved trasporta traffico. Disconnected significa che il proprietario l’ha rimossa dal suo lato: l’endpoint resta lì, ormai informativo, e va cancellato a mano.

Sulla subnet, NSG, route table e ASG sono una scelta esplicita: nel portale è la voce «Network policy for private endpoints», dove abiliti «Network security groups» e «Route tables». Attivarli però porta limiti noti: per la NIC di un endpoint privato il portale non mostra né route né regole di sicurezza efficaci, i flow log NSG non coprono il traffico in ingresso verso l’endpoint, un ASG collegato non può superare i 50 membri. Se il traffico attraversa un’appliance virtuale, Microsoft raccomanda di fare SNAT: altrimenti il ritorno non è garantito.

Senza DNS l’endpoint privato non serve a niente

Il nome pubblico continua a risolvere all’IP pubblico: il lavoro vero è il DNS. Alla creazione dell’endpoint il record pubblico diventa un CNAME verso il sottodominio privatelink, che dentro la VNet una zona DNS privata risolve con un record A sull’IP privato.

account.blob.core.windows.net              CNAME  account.privatelink.blob.core.windows.net
account.privatelink.blob.core.windows.net  A      10.1.1.5

Da fuori la stessa catena finisce sull’endpoint pubblico: per questo l’applicazione usa la stessa stringa di connessione dentro e fuori, e non devi mai puntare al sottodominio privatelink a mano.

Le regole che fanno male quando le ignori. Il private DNS zone group tiene insieme endpoint e zona e mantiene i record da solo, ma ne associ uno solo per endpoint, con al massimo cinque zone e una zona per nome. In hub-and-spoke serve una zona sola, collegata con virtual network link a tutte le VNet: due zone omonime in VNet diverse si riconciliano a mano. Non mettere record di servizi diversi nella stessa zona e non riusare una zona già associata a un altro servizio, perché il record A iniziale viene cancellato. Per i client on-premises serve un forwarder DNS nella VNet collegata alla zona, oppure Azure Private Resolver, e il conditional forwarder deve puntare alla zona pubblica, cioè database.windows.net, non a privatelink.database.windows.net.

Effetto collaterale: se la tua VNet ha già un endpoint privato per il blob e un secondo account ne ha uno altrove, i tuoi client dovranno raggiungere via endpoint privato anche quel secondo account. È il DNS, non una policy.

Il Private Link service è il lato opposto: pubblichi un tuo servizio perché altri lo consumino con un endpoint privato, anche da tenant Microsoft Entra diversi. Il vincolo è secco: solo Standard Load Balancer, e solo con backend pool configurato per NIC, non per indirizzo IP. Servizio, VNet e load balancer stanno nella stessa regione.

Scegli una subnet per gli indirizzi NAT: Microsoft ne raccomanda almeno otto disponibili, e puoi arrivare a otto configurazioni NAT IP per servizio, ma l’ultima non si rimuove. Il NAT è la cosa che sorprende: il servizio vede come IP sorgente l’indirizzo NAT, non quello del consumatore, quindi ogni ACL basata sull’IP del client smette di funzionare. Per recuperare IP sorgente e LinkID esiste TCP Proxy v2, da abilitare con attenzione: vale per tutti i load balancer e le VM di backend coinvolti e, se il backend non sa interpretare l’header, falliscono anche le probe di integrità.

Azure genera un alias unico nella forma prefisso.GUID.regione.azure.privatelinkservice, che condividi con i consumatori. La visibilità ha tre livelli, dal più chiuso al più aperto: solo controllo degli accessi in base al ruolo, che comunque consente la visibilità cross-tenant; un elenco di sottoscrizioni; chiunque abbia l’alias. Visibilità e approvazione sono cose diverse: la prima decide chi può chiedere, l’elenco di auto-approvazione decide chi entra senza che tu clicchi. I limiti duri: solo IPv4, solo TCP e UDP, idle timeout di circa cinque minuti, quindi i keepalive TCP dell’applicazione devono essere più corti.