Procedure consigliate di Azure per la sicurezza di rete

Articolo
09/27/2024

Questo articolo illustra un insieme di procedure consigliate di Azure per migliorare la sicurezza della rete, derivate dalla nostra esperienza con la rete di Azure e dalle esperienze di altri clienti.

Per ogni procedura consigliata questo articolo spiega:

Qual è la procedura consigliata
Il motivo per cui si vuole abilitare tale procedura consigliata
Quale potrebbe essere il risultato se non fosse possibile abilitare la procedura consigliata
Alternative possibili alla procedura consigliata
Come imparare ad abilitare la procedura consigliata

Le procedure consigliate si basano su un parere condiviso, nonché sulle capacità e sui set di funzionalità della piattaforma di Azure esistenti al momento della presente redazione. Le opinioni e le tecnologie cambiano nel tempo e questo articolo verrà aggiornato regolarmente per riflettere tali modifiche.

Usare controlli di rete avanzati

È possibile connettere i dispositivi e le macchine virtuali di Azure ad altri dispositivi di rete inserendoli in reti virtuali di Azure. Vale a dire che si possono connettere le schede di interfaccia di rete virtuale a una rete virtuale per consentire le comunicazioni basate su TCP/IP tra dispositivi di rete abilitati. Le macchine virtuali connesse a una rete virtuale di Azure possono connettersi ai dispositivi nella stessa rete virtuale, in reti virtuali diverse, su Internet o persino in reti locali.

Quando si pianifica la rete e la sicurezza della rete, è consigliabile centralizzare gli elementi seguenti:

Gestione delle funzioni di rete core, come ExpressRoute, provisioning di rete virtuale e subnet e indirizzi IP.
Governance degli elementi di sicurezza di rete, ad esempio funzioni di appliance virtuali di rete come ExpressRoute, provisioning della rete virtuale e delle subnet e indirizzamento IP.

Se si usa un insieme comune di strumenti di gestione per monitorare la rete e la sicurezza della rete, si ottiene una visibilità ottimale su entrambe. Una strategia di sicurezza semplice e unificata riduce gli errori, perché aumenta il riconoscimento umano e l'affidabilità dell'automazione.

Segmentare logicamente le subnet

Le reti virtuali di Azure sono simili a reti LAN nella rete locale. Una rete virtuale di Azure prevede la creazione di una rete basata su un singolo spazio indirizzi IP privato, in cui è possibile inserire tutte le macchine virtuali di Azure. Gli spazi indirizzi IP privati disponibili sono negli intervalli di Classe A (10.0.0.0/8), Classe B (172.16.0.0/12) e Classe C (192.168.0.0/16).

Le procedure consigliate per suddividere logicamente le subnet includono:

Procedura consigliata: non assegnare regole di assenso con intervalli ampi (ad esempio, da 0.0.0.0 a 255.255.255.255).
Dettagli: assicurarsi che le procedure di risoluzione dei problemi impediscano o vietino la configurazione di questi tipi di regole. Queste regole di assenso trasmettono un falso senso di sicurezza e vengono spesso trovate e sfruttate dai Red Team.

Procedura consigliata: segmentare lo spazio di indirizzi più ampio in subnet.
Dettagli: usare i principi di suddivisione in subnet basati su CIDR per creare le subnet.

Procedura consigliata: creare controlli di accesso di rete tra subnet. Il routing tra le subnet viene eseguito automaticamente e non è necessario configurare manualmente le tabelle di routing. Per impostazione predefinita, non sono presenti controlli di accesso di rete tra le subnet create in una rete virtuale di Azure.
Dettagli: usare un gruppo di sicurezza di rete per proteggersi da traffico non richiesto in entrata nelle subnet di Azure. I gruppi di sicurezza di rete (NSG) sono dispositivi di ispezione pacchetti semplici e con stato. I gruppi di sicurezza di rete usano l'approccio a 5 tuple (IP di origine, porta di origine, IP di destinazione, porta di destinazione e protocollo) per creare regole di autorizzazione/negazione per il traffico di rete. È possibile consentire o negare il traffico da e verso un singolo indirizzo IP, da e verso più indirizzi IP o da e verso intere subnet.

L'uso di gruppi di sicurezza di rete per il controllo di accesso di rete tra subnet consente di inserire nelle proprie subnet risorse che appartengono alla stessa area di protezione o allo stesso ruolo.

Procedura consigliata: evitare reti virtuali e subnet di piccole dimensioni per garantire semplicità e flessibilità. Dettagli: la maggior parte delle organizzazioni aggiunge più risorse rispetto a quelle inizialmente pianificate e la riallocazione degli indirizzi richiede un notevole lavoro. L'uso di subnet di piccole dimensioni aggiunge un valore di sicurezza limitato e il mapping di un gruppo di sicurezza di rete a ogni subnet comporta un sovraccarico di lavoro. Definire subnet di grandi dimensioni per garantire la flessibilità necessaria per la crescita.

Procedura consigliata: semplificare la gestione delle regole del gruppo di sicurezza di rete definendo i gruppi di sicurezza delle applicazioni.
Dettagli: definire un gruppo di sicurezza delle applicazioni per elenchi di indirizzi IP che si ritiene potrebbero cambiare in futuro o essere usati in molti gruppi di sicurezza di rete. Assicurarsi di assegnare nomi espliciti ai gruppi di sicurezza delle applicazioni, in modo che gli altri utenti possano comprenderne il contenuto e lo scopo.

Adottare un approccio Zero Trust

Le reti basate sul perimetro si basano sul presupposto che tutti i sistemi all'interno di una rete possano essere considerati attendibili. Tuttavia, nelle organizzazioni moderne i dipendenti accedono alle risorse da qualsiasi posizione su una vasta gamma di dispositivi e app, rendendo irrilevanti i controlli di sicurezza perimetrali. I criteri di controllo di accesso che si concentrano solo su chi può accedere a una risorsa non sono sufficienti. Per gestire in modo ottimale l'equilibrio tra sicurezza e produttività, gli amministratori della sicurezza devono anche considerare come si accede a una risorsa.

Le reti devono aggiungere nuove soluzioni alle difese tradizionali, perché possono diventare vulnerabili alle violazioni: un utente malintenzionato può compromettere un singolo endpoint entro il perimetro attendibile e quindi espandere il controllo all'intera rete. Le reti Zero Trust eliminano il concetto di attendibilità basato sul percorso di rete all'interno di un perimetro. Al contrario, le architetture Zero Trust usano attestazioni di attendibilità di dispositivi e utenti per controllare l'accesso ai dati e alle risorse dell'organizzazione. Per le nuove iniziative è consigliabile adottare approcci Zero Trust che convalidano l'attendibilità al momento dell'accesso.

Procedure consigliate:

Procedura consigliata: offrire l'accesso condizionale alle risorse in base a dispositivo, identità, garanzia, percorso di rete e altro ancora.
Dettagli: l’accesso condizionale di Azure AD consente di applicare i controlli di accesso appropriati implementando decisioni di controllo di accesso automatiche sulla base delle condizioni richieste. Per altre informazioni, vedere Gestire l'accesso alla gestione di Azure con accesso condizionale.

Procedura consigliata: abilitare l'accesso alla porta solo dopo l'approvazione del flusso di lavoro.
Dettagli: è possibile usare accesso alle macchine virtuali just-in-time in Microsoft Defender for Cloud per bloccare il traffico in ingresso alle macchine virtuali di Azure, riducendo l'esposizione agli attacchi, consentendo al contempo di accedere facilmente alle macchine virtuali quando necessario.

Procedura consigliata: concedere autorizzazioni temporanee per l'esecuzione di attività con privilegi, per impedire a utenti non autorizzati o malintenzionati di ottenere l'accesso dopo la scadenza delle autorizzazioni. L'accesso viene concesso solo quando l'utente ne ha necessità.
Dettagli: usare l'accesso JIT in Microsoft Entra Privileged Identity Management o in una soluzione di terze parti per concedere le autorizzazioni per eseguire attività con privilegi.

Zero Trust è la prossima evoluzione della sicurezza di rete. Lo stato degli attacchi cibernetici spinge le organizzazioni ad adottare la mentalità "presunta violazione", ma questo approccio non dovrebbe essere limitante. Le reti Zero Trust proteggono i dati e le risorse aziendali, garantendo nel contempo alle organizzazioni la possibilità di creare uno spazio di lavoro moderno tramite tecnologie che consentono ai dipendenti di essere produttivi in qualsiasi momento, ovunque e con qualsiasi modalità.

Controllare il comportamento di routing

Quando si inserisce una macchina virtuale in una rete virtuale di Azure, la macchina virtuale può connettersi a qualsiasi altra macchina virtuale nella stessa rete virtuale e ad altre macchine virtuali in subnet diverse. Questo è possibile perché un insieme di route di sistema, abilitate per impostazione predefinita, consente questo tipo di comunicazione. Queste route predefinite consentono alle macchine virtuali nella stessa rete virtuale di avviare le connessioni tra loro e con Internet (per le comunicazioni in uscita solo con Internet).

Nonostante le route di sistema predefinite siano utili per molti scenari di distribuzione, in alcuni casi si vuole personalizzare la configurazione del routing per le distribuzioni. È consentito configurare l'indirizzo hop successivo in modo da raggiungere destinazioni specifiche.

È consigliabile configurare route definite dall'utente quando si distribuisce un dispositivo di sicurezza per una rete virtuale. Questa raccomandazione viene descritta in una sezione successiva intitolata proteggere le risorse critiche del servizio di Azure solo per le reti virtuali.

Nota

Le route definite dall'utente non sono necessarie e le route di sistema predefinite generalmente funzionano.

Usare i dispositivi di rete virtuale

I gruppi di sicurezza di rete e il routing definito dall'utente possono garantire un certo grado di sicurezza della rete nei livelli di rete e trasporto del modello OSI. Ma in alcune situazioni, è preferibile o necessario abilitare la sicurezza ai livelli alti dello stack. In tali situazioni, è consigliabile distribuire i dispositivi di sicurezza di rete virtuale forniti dai partner di Azure.

I dispositivi di sicurezza di rete di Azure possono offrire livelli di sicurezza migliori rispetto a quanto offerto dai controlli a livello di rete. Le funzionalità di sicurezza di rete fornite da dispositivi di sicurezza di rete virtuale includono:

Funzionalità di firewall
Rilevamento intrusioni/Prevenzione intrusioni
Gestione vulnerabilità
Controllo delle applicazioni
Rilevamento anomalie basato su rete
Filtro Web
Antivirus
Protezione botnet

Per trovare i dispositivi di sicurezza di rete virtuale di Azure, visitare Azure Marketplace e cercare "sicurezza" e "sicurezza di rete".

Distribuire reti perimetrali per le aree di sicurezza

Una rete perimetrale (nota anche come DMZ) è un segmento di rete fisica o logica che fornisce un ulteriore livello di sicurezza tra le risorse e Internet. I dispositivi specializzati per il controllo di accesso alla rete dislocati al margine di una rete perimetrale lasciano entrare nella rete virtuale solo il traffico desiderato.

Le reti perimetrali sono utili perché permettono di concentrare le operazioni di gestione, monitoraggio, registrazione e creazione di report del controllo di accesso alla rete sui dispositivi della rete virtuale di Azure. Una rete perimetrale è lo scenario in cui sono in genere abilitati la prevenzione DDoS (Distributed Denial of Service), i sistemi di rilevamento intrusione/prevenzione intrusioni (IDS/IPS), le regole e i criteri dei firewall, il filtro Web, il software antimalware per la rete e molto altro. I dispositivi di sicurezza di rete sono posizionati tra Internet e la rete virtuale di Azure e hanno un'interfaccia su entrambe le reti.

Questo è un modello di rete perimetrale base, ma esistono molti modelli diversi di rete perimetrale, ad esempio le reti back to back, tri-homed e multihomed.

In base al concetto Zero Trust indicato in precedenza, è consigliabile usare una rete perimetrale per tutte le implementazioni con sicurezza elevata, per migliorare il livello di sicurezza di rete e il controllo di accesso per le risorse di Azure. È possibile usare Azure o una soluzione di terze parti per offrire un ulteriore livello di sicurezza tra gli asset e Internet:

Controlli nativi di Azure. Firewall di Azure e Web application firewall di Azure offrono vantaggi di sicurezza di base. I vantaggi sono un firewall con stato completo come servizio, disponibilità elevata predefinita, scalabilità cloud senza restrizioni, filtro FQDN, supporto per set di regole di base OWASP e configurazione semplice.
Offerte di terzi. Cercare in Azure Marketplace per un firewall di nuova generazione (NGFW) e altre offerte di terze parti che includono strumenti di sicurezza noti e livelli di sicurezza di rete notevolmente migliorati. La configurazione può essere più complessa, ma un'offerta di terze parti potrebbe consentire l'uso di funzionalità e set di competenze esistenti.

Evitare l'esposizione a Internet con collegamenti WAN dedicati

Molte organizzazioni hanno scelto la strada dell'IT ibrido. Nell'ambiente IT ibrido, alcuni asset di informazioni dell'organizzazione si trovano in Azure e altri rimangono in locale. In molti casi alcuni componenti di un servizio sono eseguiti in Azure mentre altri componenti restano in locale.

In uno scenario IT ibrido è in genere presente un certo grado di connettività cross-premise. che consente alla società di connettere le proprie reti locali alle reti virtuali di Azure. Sono disponibili due soluzioni di connettività cross-premise:

VPN da sito a sito. È una tecnologia attendibile, affidabile e consolidata, ma la connessione avviene tramite Internet. La larghezza di banda è vincolata a un massimo di circa 1,25 Gbps. La VPN da sito a sito è un'opzione ottimale in determinati scenari.
Azure ExpressRoute. per la connettività cross-premise, ExpressRoute è la scelta consigliata. ExpressRoute consente di estendere le reti locali nel cloud Microsoft tramite una connessione privata fornita da un provider di connettività. Con ExpressRoute è possibile stabilire connessioni ai servizi cloud Microsoft, ad esempio Azure, Microsoft 365 e Dynamics 365. ExpressRoute è un collegamento WAN dedicato tra il percorso locale e un provider di hosting di Microsoft Exchange. Dal momento che si tratta di una connessione di telecomunicazioni, i dati non vengono trasmessi via Internet e quindi non sono esposti a potenziali rischi legati alle comunicazioni Internet.

Il percorso della connessione ExpressRoute può influire sulla capacità del firewall, la scalabilità, l'affidabilità e la visibilità del traffico di rete. È necessario identificare la posizione in cui terminare ExpressRoute nelle reti esistenti (locali). È possibile:

Terminare all'esterno del firewall (paradigma della rete perimetrale). Usare questa raccomandazione se è necessaria visibilità sul traffico, se è necessario continuare una pratica esistente per isolare i data center o se si inseriscono esclusivamente risorse extranet in Azure.
Terminare all'interno del firewall (il paradigma dell'estensione di rete). Questa è la raccomandazione predefinita. In tutti gli altri casi, è consigliabile considerare Azure come un altro data center.

Ottimizzare il tempo di attività e le prestazioni

Se un servizio non è attivo, non è possibile accedere alle informazioni. Se le prestazioni sono talmente insufficienti da rendere i dati inutilizzabili, è possibile considerare che i dati siano inaccessibili. Dal punto di vista della sicurezza, è necessario fare del proprio meglio per assicurarsi che i servizi offrano sempre prestazioni e tempi di attività ottimali.

Uno dei metodi più diffusi ed efficaci per migliorare le prestazioni e la disponibilità consiste nel ricorrere al bilanciamento del carico. Il bilanciamento del carico è un metodo di distribuzione del traffico di rete tra server che fanno parte di un servizio. Ad esempio, se dei server Web front-end fanno parte del servizio, è possibile usare il bilanciamento del carico per distribuire il traffico tra più server Web front-end.

Questa distribuzione del traffico aumenta la disponibilità perché se uno dei server Web non è più disponibile, il servizio di bilanciamento del carico interrompe l'invio di traffico a tale server, reindirizzandolo verso i server che sono ancora online. Il bilanciamento del carico favorisce anche le prestazioni, perché il sovraccarico di processore, rete e memoria per l'elaborazione delle richieste viene distribuito tra tutti server con carico bilanciato.

È consigliabile impiegare il bilanciamento del carico ogni volta possibile e quando adeguato ai servizi. Di seguito sono descritti degli scenari a livello di rete virtuale di Azure e altri a livello globale, con le opzioni di bilanciamento del carico per ognuno.

Scenario: è presente un'applicazione che:

Necessita che le richieste provengano dalla stessa sessione utente/client per raggiungere la stessa macchina virtuale back-end. Esempi di queste applicazioni sono i carrelli dei siti di acquisti e i server di posta Web.
Accetta solo connessioni protette, pertanto le comunicazioni non crittografate verso il server non rappresentano un'opzione accettabile.
Necessita che più richieste HTTP nella stessa connessione TCP con esecuzione prolungata vengano instradate/bilanciate in server back-end diversi.

Opzione di bilanciamento del carico: usare il gateway applicazione di Azure, un servizio di bilanciamento del carico legato al traffico Web HTTP. Il gateway applicazione supporta la crittografia TLS e la terminazione TLS sul gateway. I server Web possono quindi essere liberati dal sovraccarico prodotto dai processi di crittografia e decrittografia e il traffico può essere trasmesso in formato non crittografato ai server back-end.

Scenario: è necessario applicare il bilanciamento del carico alle connessioni in ingresso da Internet tra i server che si trovano in una rete virtuale di Azure. Scenari in cui:

Sono presenti applicazioni senza stato che accettano le richieste in ingresso da Internet.
Non sono richieste sessioni permanenti o l'offload TLS. La combinazione di sessioni permanenti e del bilanciamento del carico delle applicazioni è un metodo per ottenere l'affinità dei server.

Opzione di bilanciamento del carico: usare il portale di Azure per creare un servizio di bilanciamento del carico esterno che distribuisca le richieste in ingresso tra più macchine virtuali per offrire un livello superiore di disponibilità.

Scenario: è necessario applicare il bilanciamento del carico alle connessioni provenienti da macchine virtuali che non si trovano su Internet. Nella maggior parte dei casi, le connessioni che sono accettate per il bilanciamento del carico possono essere avviate da dispositivi nella rete virtuale di Azure, quali le istanze SQL Server o i server Web interni.
Opzione di bilanciamento del carico: usare il portale di Azure per creare un servizio di bilanciamento del carico interno che distribuisca le richieste in ingresso tra più macchine virtuali per offrire un livello superiore di disponibilità.

Scenario: è necessario il bilanciamento del carico globale quando:

Si dispone di una soluzione cloud ampiamente distribuita tra più aree e che richiede il livello massimo di tempo di attività (disponibilità) possibile.
Si necessita del massimo livello di tempo di attività possibile per assicurarsi che il servizio sia disponibile anche se un intero data center diventa non disponibile.

Opzione di bilanciamento del carico: usare Gestione traffico di Azure. Gestione traffico rende possibile bilanciare il carico delle connessioni ai servizi in base alla posizione dell'utente.

Ad esempio, se l'utente effettua una richiesta al servizio dall'Unione europea, la connessione viene indirizzata ai servizi che si trovano in un data center dell'Unione europea. Questa parte bilanciamento del carico globale di Gestione traffico consente di migliorare le prestazioni perché la connessione al data center più vicino è più veloce rispetto alla connessione ai data center più lontani.

Disabilitare l'accesso RDP/SSH alle macchine virtuali

È possibile raggiungere le macchine virtuali di Azure usando i protocolli Remote Desktop Protocol (RDP) e Secure Shell (SSH). Questi protocolli consentono di gestire le macchine virtuali da postazioni remote e sono standard nel computing dei data center.

L'uso di questi protocolli in Internet può provocare tuttavia un potenziale problema di sicurezza perché gli utenti malintenzionati possono usare tecniche di attacco di forza bruta per ottenere l'accesso alle macchine virtuali di Azure. Una volta che gli utenti malintenzionati avranno ottenuto l'accesso, potranno usare la macchina virtuale come punto di partenza per compromettere gli altri computer nella rete virtuale o persino per attaccare i dispositivi di rete all'esterno di Azure.

È consigliabile disabilitare l'accesso diretto RDP e SSH alle macchine virtuali di Azure da Internet. Dopo aver disabilitato l'accesso diretto RDP e SSH da Internet, sono disponibili altre opzioni per accedere a queste macchine virtuali per la gestione remota.

Scenario: consentire a un singolo utente di connettersi a una rete virtuale di Azure via Internet.
Opzione: VPN da punto a sito è un altro termine per indicare una connessione client/server VPN con accesso remoto. Dopo aver stabilito la connessione da punto a sito, l'utente può usare RDP o SSH per connettersi a qualsiasi macchina virtuale presente nella rete virtuale Azure e a cui l'utente si è connesso con VPN da punto a sito. Ciò presuppone che l'utente sia autorizzato a raggiungere tali macchine virtuali.

La VPN da punto a sito è più sicura delle connessioni dirette RDP o SSH perché l'utente deve autenticarsi due volte prima di potersi connettere a una macchina virtuale. In primo luogo, l'utente deve eseguire l'autenticazione, e ottenere l'autorizzazione, per stabilire la connessione VPN da punto a sito. In secondo luogo, l'utente deve eseguire l'autenticazione, e ottenere l'autorizzazione, per stabilire la connessione RDP o SSH.

Scenario: abilitare gli utenti della rete locale per connettersi alle macchine virtuali nella rete virtuale di Azure.
Opzione: VPN da sito a sito connette un'intera rete a un'altra rete via Internet. È possibile usare una VPN da sito a sito per connettere la rete locale a una rete virtuale di Azure. Gli utenti della rete locale si connettono usando il protocollo RDP o SSH tramite la connessione VPN da sito a sito. Non è necessario consentire l'accesso diretto RDP o SSH via Internet.

Scenario: usare un collegamento WAN dedicato per fornire funzionalità simili alla VPN da sito a sito.
Opzione: usare ExpressRoute. Offre funzionalità simili a quelle della VPN da sito a sito. Le differenze principali sono:

Il collegamento WAN dedicato non attraversa Internet.
I collegamenti WAN dedicati sono in genere più stabili e più efficienti.

Associare le risorse critiche dei servizi di Azure solo alle proprie reti virtuali

Collegamento privato di Azure consente di accedere ai servizi PaaS di Azure, ad esempio Database SQL e Archiviazione di Azure, e tramite un endpoint privato nella rete virtuale. Gli endpoint privati consentono di associare le risorse critiche dei servizi di Azure solo alle proprie reti virtuali. Il traffico che transita dalla rete virtuale al servizio di Azure rimane sempre nella rete backbone di Microsoft Azure. L'esposizione della rete virtuale alla rete Internet pubblica non è più necessaria per usare i servizi PaaS di Azure.

Collegamento privato di Azure offre i vantaggi descritti di seguito.

Maggiore sicurezza per le risorse del servizio di Azure: con collegamento privato di Azure, le risorse del servizio di Azure possono essere protette nella rete virtuale usando l'endpoint privato. La protezione delle risorse del servizio in un endpoint privato nella rete virtuale offre una maggiore sicurezza rimuovendo completamente l'accesso a Internet pubblico alle risorse e consentendo il traffico solo dall'endpoint privato nella rete virtuale.
Accedere privatamente alle risorse del servizio di Azure nella piattaforma Azure: connettere la rete virtuale ai servizi in Azure usando endpoint privati. Non è necessario un indirizzo IP pubblico. La piattaforma di Collegamento privato gestirà la connettività tra l'utente e i servizi tramite la rete backbone di Azure.
L'accesso da reti locali e con peering: accedere ai servizi in esecuzione in Azure dall'ambiente locale tramite peering privato ExpressRoute, tunnel VPN e reti virtuali con peering usando endpoint privati. Non è necessario configurare il peering Microsoft ExpressRoute o attraversare Internet per raggiungere il servizio. Collegamento privato offre un modo sicuro per eseguire la migrazione dei carichi di lavoro ad Azure.
Protezione contro la perdita di dati: nel diagramma seguente viene eseguito il mapping di un endpoint privato a un'istanza di una risorsa PaaS anziché all'intero servizio. Gli utenti possono connettersi solo alla risorsa specifica. L'accesso a qualsiasi altra risorsa del servizio è bloccato. Questo meccanismo offre protezione dai rischi di perdita dei dati.
Copertura globale: è possibile connettersi privatamente a servizi in esecuzione in altre aree. La rete virtuale dell’utente potrebbe trovarsi nell'area A e può connettersi ai servizi nell'area B.
Semplice da configurare e gestire: non sono più necessari indirizzi IP pubblici riservati nelle reti virtuali per proteggere le risorse di Azure tramite un firewall IP. Non sono necessari dispositivi NAT o gateway per configurare gli endpoint privati. Gli endpoint privati vengono configurati tramite un flusso di lavoro semplice. Sul lato servizio è anche possibile gestire le richieste di connessione nella risorsa del servizio di Azure con facilità. Collegamento privato di Azure funziona anche per i consumer e i servizi appartenenti a tenant Microsoft Entra diversi.

Per altre informazioni sugli endpoint privati e sui servizi e le aree di Azure disponibili per gli endpoint privati, vedere Collegamento privato di Azure.

Passaggi successivi

Per altre procedure di sicurezza consigliate da usare nella progettazione, distribuzione e gestione di soluzioni cloud tramite Azure, vedere Procedure consigliate e modelli per la sicurezza di Azure.

Condividi tramite