Raccomandazioni per la rete e la connettività

Articolo
11/15/2023

Si applica a questa raccomandazione dell'elenco di controllo per la sicurezza di Azure Well-Architected Framework:

SE:06	Isolare, filtrare e controllare il traffico di rete tra flussi in ingresso e in uscita. Applicare principi di difesa avanzata usando controlli di rete localizzati in tutti i limiti di rete disponibili sia attraverso il traffico est-ovest che nord-sud.

Questa guida descrive le raccomandazioni per la progettazione di rete. L'attenzione è rivolta ai controlli di sicurezza che possono filtrare, bloccare e rilevare avversari che superano i limiti di rete a varie profondità dell'architettura.

È possibile rafforzare i controlli delle identità implementando misure di controllo degli accessi in base alla rete. Oltre al controllo degli accessi in base alle identità, la sicurezza di rete è una priorità elevata per la protezione degli asset. I controlli di sicurezza di rete appropriati possono fornire un elemento di difesa approfondito che consente di rilevare e contenere minacce e impedire agli utenti malintenzionati di accedere al carico di lavoro.

Definizioni

Termine	Definizione
Traffico orizzontale destra-sinistra	Traffico di rete che si sposta all'interno di un limite attendibile.
Flusso in uscita	Traffico del carico di lavoro in uscita.
Rete ostile	Una rete non distribuita come parte del carico di lavoro. Una rete ostile è considerata un vettore di minaccia.
Flusso di ingresso	Traffico del carico di lavoro in ingresso.
Filtro di rete	Meccanismo che consente o blocca il traffico di rete in base alle regole specificate.
Segmentazione o isolamento della rete	Strategia che divide una rete in segmenti piccoli e isolati, con controlli di sicurezza applicati ai limiti. Questa tecnica consente di proteggere le risorse da reti ostili, ad esempio Internet.
Trasformazione rete	Meccanismo che modifica i pacchetti di rete per nasconderli.
Traffico verticale alto-basso	Traffico di rete che passa da un limite attendibile a reti esterne potenzialmente ostili e viceversa.

Strategie di progettazione chiave

La sicurezza di rete usa l'oscurità per proteggere gli asset del carico di lavoro da reti ostili. Le risorse che si trovano dietro un limite di rete vengono nascoste fino a quando i controlli limite contrassegnano il traffico come sicuro per spostarsi in avanti. La progettazione della sicurezza di rete si basa su tre strategie principali:

Segmento. Questa tecnica isola il traffico su reti separate aggiungendo limiti. Ad esempio, il traffico da e verso un livello applicazione supera un limite per comunicare con altri livelli, che hanno requisiti di sicurezza diversi. I livelli di segmentazione effettivizzano l'approccio di difesa avanzata.

Il limite di sicurezza principale è il limite di rete tra l'applicazione e le reti pubbliche. È importante definire chiaramente questo perimetro in modo da stabilire un limite per isolare le reti ostili. I controlli su questo arco devono essere altamente efficaci, perché questo limite è la prima linea di difesa.

Le reti virtuali forniscono un limite logico. Per impostazione predefinita, una rete virtuale non può comunicare con un'altra rete virtuale a meno che il limite non sia stato intenzionalmente interrotto tramite peering. L'architettura dovrebbe sfruttare questa misura di sicurezza avanzata fornita dalla piattaforma.

È anche possibile usare altri limiti logici, ad esempio subnet ritagliate all'interno di una rete virtuale. Un vantaggio delle subnet è che è possibile usarle per raggruppare le risorse che si trovano all'interno di un limite di isolamento e avere garanzie di sicurezza simili. È quindi possibile configurare i controlli sul limite per filtrare il traffico.
Filtro. Questa strategia consente di garantire che il traffico che entra in un limite sia previsto, consentito e sicuro. Dal punto di vista Zero-Trust, il filtro verifica in modo esplicito tutti i punti dati disponibili a livello di rete. È possibile inserire regole sul limite per verificare la presenza di condizioni specifiche.

Ad esempio, a livello di intestazione, le regole possono verificare che il traffico provenga da una posizione prevista o abbia un volume previsto. Ma questi controlli non sono sufficienti. Anche se il traffico presenta caratteristiche previste, il payload potrebbe non essere sicuro. I controlli di convalida potrebbero rivelare un attacco SQL injection.
Trasforma. Modifica pacchetti al limite come misura di sicurezza. Ad esempio, è possibile rimuovere le intestazioni HTTP per eliminare il rischio di esposizione. In alternativa, è possibile disattivare Transport Layer Security (TLS) a un punto e ristabilire l'hop in un altro hop con un certificato gestito più rigorosamente.

Classificare i flussi di traffico

Il primo passaggio per classificare i flussi consiste nello studio di uno schema dell'architettura del carico di lavoro. Dallo schema, determinare la finalità e le caratteristiche del flusso rispetto all'utilità funzionale e agli aspetti operativi del carico di lavoro. Usare le domande seguenti per classificare il flusso:

Se il carico di lavoro deve comunicare con reti esterne, qual è il livello di prossimità richiesto a tali reti?
Quali sono le caratteristiche di rete del flusso, ad esempio il protocollo previsto e l'origine e la forma dei pacchetti? Esistono requisiti di conformità a livello di rete?

Esistono molti modi per classificare i flussi di traffico. Le sezioni seguenti illustrano i criteri di uso comune.

Visibilità da reti esterne

Pubblico. Un carico di lavoro è pubblico se l'applicazione e altri componenti sono raggiungibili dalla rete Internet pubblica. L'applicazione viene esposta tramite uno o più indirizzi IP pubblici e server DNS (Public Domain Name System).
Privato. Un carico di lavoro è privato se è accessibile solo tramite una rete privata, ad esempio una rete privata virtuale (VPN). Viene esposto solo tramite uno o più indirizzi IP privati e potenzialmente tramite un server DNS privato.

In una rete privata non è presente alcuna linea di vista dalla rete Internet pubblica al carico di lavoro. Per il gateway, è possibile usare un servizio di bilanciamento del carico o un firewall. Queste opzioni possono fornire garanzie di sicurezza.

Anche con carichi di lavoro pubblici, cercare di mantenere il più possibile privato del carico di lavoro. Questo approccio forza i pacchetti a attraversare un limite privato quando arrivano da una rete pubblica. Un gateway in tale percorso può funzionare come punto di transizione fungendo da proxy inverso.

Direzione del traffico

Dati in ingresso. Il traffico in ingresso passa verso un carico di lavoro o i relativi componenti. Per proteggere l'ingresso, applicare il set precedente di strategie chiave. Determinare qual è l'origine del traffico e se è prevista, consentita e sicura. Gli utenti malintenzionati che analizzano gli intervalli di indirizzi IP del provider di cloud pubblico possono penetrare correttamente nelle difese se non si controlla l'ingresso o si implementano misure di sicurezza di rete di base.
Uscita. L'uscita è il traffico in uscita che passa da un carico di lavoro o dai relativi componenti. Per controllare l'uscita, determinare dove si trova il traffico e se la destinazione è prevista, consentita e sicura. La destinazione potrebbe essere dannosa o associata a rischi di esfiltrazione dei dati.

È anche possibile determinare il livello di esposizione considerando la prossimità del carico di lavoro alla rete Internet pubblica. Ad esempio, la piattaforma dell'applicazione serve in genere indirizzi IP pubblici. Il componente del carico di lavoro è il volto della soluzione.

Ambito dell'influenza

Nord-sud. Il traffico che scorre tra una rete del carico di lavoro e le reti esterne è il traffico nord-sud. Questo traffico attraversa il bordo della rete. Le reti esterne possono essere la rete Internet pubblica, una rete aziendale o qualsiasi altra rete esterna all'ambito di controllo.

L'ingresso e l'uscita possono essere entrambi traffico nord-sud.

Si consideri ad esempio il flusso in uscita di una topologia di rete hub-spoke. È possibile definire la rete perimetrale del carico di lavoro in modo che l'hub sia una rete esterna. In tal caso, il traffico in uscita dalla rete virtuale dello spoke è il traffico nord-sud. Tuttavia, se si considera la rete hub all'interno del proprio ambito di controllo, il traffico nord-sud viene esteso al firewall nell'hub, perché l'hop successivo è Internet, che è potenzialmente ostile.
Est-ovest. Il traffico che scorre all'interno di una rete del carico di lavoro è il traffico est-ovest. Questo tipo di traffico risulta quando i componenti del carico di lavoro comunicano tra loro. Un esempio è il traffico tra i livelli di un'applicazione a più livelli. Nei microservizi la comunicazione da servizio a servizio è il traffico est-ovest.

Per garantire una difesa approfondita, mantenere il controllo end-to-end degli inviti di sicurezza inclusi in ogni hop o usati quando i pacchetti intersecano segmenti interni. Diversi livelli di rischio richiedono metodi di correzione dei rischi diversi.

Il diagramma precedente illustra la difesa di rete in profondità nel cloud privato. In questo diagramma il bordo tra gli spazi di indirizzi IP pubblici e privati è notevolmente più lontano dal carico di lavoro rispetto al diagramma del cloud pubblico. Più livelli separano le distribuzioni di Azure dallo spazio indirizzi IP pubblico.

Nota

L'identità è sempre il perimetro primario. La gestione degli accessi deve essere applicata ai flussi di rete. Usare le identità gestite quando si usa il controllo degli accessi in base al ruolo di Azure tra i componenti della rete.

Dopo aver classificato i flussi, eseguire un esercizio di segmentazione per identificare i punti di inserimento del firewall nei percorsi di comunicazione dei segmenti di rete. Quando si progetta la difesa di rete in profondità in tutti i segmenti e in tutti i tipi di traffico, si presuppone una violazione in tutti i punti. Usare una combinazione di vari controlli di rete localizzati in tutti i limiti disponibili. Per altre informazioni, vedere Strategie di segmentazione.

Applicare firewall al perimetro

Il traffico perimetrale Internet è il traffico nord-sud e include ingresso e uscita. Per rilevare o bloccare le minacce, una strategia perimetrale deve mitigare il maggior numero possibile di attacchi da e verso Internet.

Per l'uscita, inviare tutto il traffico associato a Internet attraverso un singolo firewall che offre una supervisione, una governance e un controllo avanzati del traffico. Per l'ingresso, forzare tutto il traffico da Internet a passare attraverso un'appliance virtuale di rete o un web application firewall.

I firewall sono in genere singleton distribuiti per area in un'organizzazione. Di conseguenza, vengono condivisi tra carichi di lavoro e di proprietà di un team centrale. Assicurarsi che tutte le appliance virtuali di rete usate siano configurate per supportare le esigenze del carico di lavoro.
È consigliabile usare i controlli nativi di Azure il più possibile.

Oltre ai controlli nativi, è anche possibile prendere in considerazione le appliance virtuali di rete partner che forniscono funzionalità avanzate o specializzate. I prodotti del firewall per i partner e del web application firewall sono disponibili in Azure Marketplace.

La decisione di usare le funzionalità native anziché le soluzioni dei partner deve essere basata sull'esperienza e sui requisiti dell'organizzazione.

Compromesso: le funzionalità dei partner spesso forniscono funzionalità avanzate che possono proteggersi da attacchi sofisticati, ma in genere non comuni. La configurazione delle soluzioni partner può essere complessa e fragile, perché queste soluzioni non si integrano con i controller di infrastruttura del cloud. Dal punto di vista dei costi, il controllo nativo è preferibile perché è più economico rispetto alle soluzioni partner.

Tutte le opzioni tecnologiche che si prendono in considerazione devono fornire controlli di sicurezza e monitoraggio sia per i flussi in ingresso che per i flussi in uscita. Per visualizzare le opzioni disponibili per Azure, vedere la sezione Sicurezza edge in questo articolo.

Progettare la rete virtuale e la sicurezza delle subnet

L'obiettivo principale di un cloud privato è nascondere le risorse dalla rete Internet pubblica. Esistono diversi modi per raggiungere questo obiettivo:

Passare a spazi di indirizzi IP privati, che è possibile eseguire usando le reti virtuali. Ridurre al minimo la linea di vista della rete anche all'interno delle proprie reti private.
Ridurre al minimo il numero di voci DNS pubbliche usate per esporre meno carico di lavoro.
Aggiungere il controllo del flusso di rete in ingresso e in uscita. Non consentire il traffico non attendibile.

Strategia di segmentazione

Per ridurre al minimo la visibilità della rete, segmentare la rete e iniziare con i controlli di rete con privilegi minimi. Se un segmento non è instradabile, non è possibile accedervi. Ampliare l'ambito in modo da includere solo i segmenti che devono comunicare tra loro tramite l'accesso alla rete.

È possibile segmentare le reti virtuali creando subnet. I criteri per la divisione devono essere intenzionali. Quando si collocano i servizi all'interno di una subnet, assicurarsi che tali servizi possano visualizzarsi tra loro.

È possibile basare la segmentazione su molti fattori. Ad esempio, è possibile inserire livelli applicazione diversi in segmenti dedicati. Un altro approccio consiste nel pianificare le subnet in base a ruoli e funzioni comuni che usano protocolli noti.

Per altre informazioni, vedere Strategie di segmentazione.

Firewall subnet

È importante esaminare il traffico in ingresso e in uscita di ogni subnet. Usare le tre strategie principali descritte in precedenza in questo articolo, in Strategie di progettazione chiave. Controllare se il flusso è previsto, consentito e sicuro. Per verificare queste informazioni, definire le regole del firewall basate sul protocollo, l'origine e la destinazione del traffico.

In Azure si impostano le regole del firewall nei gruppi di sicurezza di rete. Per altre informazioni, vedere la sezione Gruppi di sicurezza di rete in questo articolo.

Per un esempio di progettazione di subnet, vedere Subnet di Azure Rete virtuale.

Usare i controlli a livello di componente

Dopo aver ridotto al minimo la visibilità della rete, eseguire il mapping delle risorse di Azure dal punto di vista della rete e valutare i flussi. Sono possibili i tipi di flussi seguenti:

Traffico pianificato o comunicazione intenzionale tra servizi in base alla progettazione dell'architettura. Ad esempio, è stato pianificato il traffico quando l'architettura consiglia che Funzioni di Azure estrae i messaggi da bus di servizio di Azure.
Traffico di gestione o comunicazione che avviene come parte della funzionalità del servizio. Questo traffico non fa parte della progettazione e non ha alcun controllo su di esso. Un esempio di traffico gestito è la comunicazione tra i servizi di Azure nell'architettura e il piano di gestione di Azure.

La distinzione tra il traffico pianificato e quello di gestione consente di creare controlli localizzati o a livello di servizio. Avere una buona conoscenza dell'origine e della destinazione in ogni hop. In particolare, comprendere come viene esposto il piano dati.

Come punto di partenza, determinare se ogni servizio è esposto a Internet. In caso affermativo, pianificare come limitare l'accesso. In caso contrario, inserirlo in una rete virtuale.

Firewall del servizio

Se si prevede che un servizio venga esposto a Internet, sfruttare il firewall a livello di servizio disponibile per la maggior parte delle risorse di Azure. Quando si usa questo firewall, è possibile impostare regole in base ai modelli di accesso. Per altre informazioni, vedere la sezione Firewall del servizio di Azure in questo articolo.

Nota

Quando il componente non è un servizio, usare un firewall basato su host oltre ai firewall a livello di rete. Una macchina virtuale (VM) è un esempio di componente che non è un servizio.

Connettività ai servizi PaaS (Platform as a Service)

Prendere in considerazione l'uso di endpoint privati per proteggere l'accesso ai servizi PaaS. All'endpoint privato viene assegnato un indirizzo IP privato dalla rete virtuale. L'endpoint consente ad altre risorse nella rete di comunicare con il servizio PaaS tramite l'indirizzo IP privato.

La comunicazione con un servizio PaaS viene ottenuta usando l'indirizzo IP pubblico e il record DNS del servizio. Tale comunicazione avviene tramite Internet. È possibile rendere privata la comunicazione.

Un tunnel dal servizio PaaS in una delle subnet crea un canale privato. Tutte le comunicazioni avvengono dall'indirizzo IP privato del componente a un endpoint privato in tale subnet, che quindi comunica con il servizio PaaS.

In questo esempio l'immagine a sinistra mostra il flusso per gli endpoint esposti pubblicamente. A destra, tale flusso è protetto tramite endpoint privati.

Per altre informazioni, vedere la sezione Endpoint privati in questo articolo.

Nota

È consigliabile usare endpoint privati insieme ai firewall del servizio. Un firewall del servizio blocca il traffico Internet in ingresso e quindi espone il servizio privatamente agli utenti interni che usano l'endpoint privato.

Un altro vantaggio dell'uso di endpoint privati è che non è necessario aprire le porte sul firewall per il traffico in uscita. Gli endpoint privati bloccano tutto il traffico in uscita sulla porta per la rete Internet pubblica. La connettività è limitata alle risorse all'interno della rete.

Compromesso: collegamento privato di Azure è un servizio a pagamento con contatori per i dati in ingresso e in uscita elaborati. Vengono addebitati anche gli endpoint privati.

Protezione da attacchi DDoS (Distributed Denial of Service)

Un attacco DDoS tenta di esaurire le risorse di un'applicazione per rendere l'applicazione non disponibile per gli utenti legittimi. Gli attacchi DDoS possono colpire qualsiasi endpoint raggiungibile pubblicamente tramite Internet.

Un attacco DDoS è in genere un abuso massiccio, diffuso e geograficamente disperso delle risorse del sistema che rende difficile individuare e bloccare l'origine.

Per supporto tecnico di Azure per proteggere questi attacchi, vedere la sezione Protezione DDoS di Azure in questo articolo.

Facilitazione di Azure

È possibile usare i servizi di Azure seguenti per aggiungere funzionalità di difesa avanzate alla rete.

Rete virtuale di Azure

Rete virtuale consente alle risorse di Azure di comunicare in modo sicuro tra loro, internet e reti locali.

Per impostazione predefinita, tutte le risorse in una rete virtuale possono interagire con la comunicazione in uscita con Internet. La comunicazione in ingresso è tuttavia limitata per impostazione predefinita.

Rete virtuale offre funzionalità per filtrare il traffico. È possibile limitare l'accesso a livello di rete virtuale usando una route definita dall'utente e un componente del firewall. A livello di subnet, è possibile filtrare il traffico usando i gruppi di sicurezza di rete.

Sicurezza perimetrale

Per impostazione predefinita, i dati in ingresso e in uscita passano entrambi sugli indirizzi IP pubblici. A seconda del servizio o della topologia, questi indirizzi vengono impostati o assegnati da Azure. Altre possibilità di ingresso e uscita includono il passaggio del traffico attraverso un servizio di bilanciamento del carico o un gateway NAT (Network Address Translation). Tuttavia, questi servizi sono destinati alla distribuzione del traffico e non necessariamente per la sicurezza.

Sono consigliate le seguenti opzioni tecnologiche:

Firewall di Azure. È possibile usare Firewall di Azure nella rete perimetrale e nelle topologie di rete più diffuse, ad esempio reti hub-spoke e reti WAN virtuali. In genere si distribuisce Firewall di Azure come firewall in uscita che funge da gate di sicurezza finale prima che il traffico passa a Internet. Firewall di Azure può instradare il traffico che usa protocolli non HTTP e non HTTPS, ad esempio Remote Desktop Protocol (RDP), Secure Shell Protocol (SSH) e FTP (File Transfer Protocol). Il set di funzionalità di Firewall di Azure include:
- Network Address Translation (DNAT) di destinazione o port forwarding.
- Rilevamento delle firme del sistema di rilevamento e prevenzione delle intrusioni (IDPS).
- Regole di rete del livello 3, del livello 4 e del nome di dominio completo (FQDN).
Nota

La maggior parte delle organizzazioni ha un criterio di tunneling forzato che forza il flusso del traffico attraverso un'appliance virtuale di rete.

Se non si usa una topologia WAN virtuale, è necessario distribuire una route definita dall'utente con un oggetto NextHopType nell'indirizzo Internet IP privato dell'appliance virtuale di rete. Le route definite dall'utente vengono applicate a livello di subnet. Per impostazione predefinita, il traffico da subnet a subnet non passa attraverso l'appliance virtuale di rete.

È anche possibile usare Firewall di Azure simultaneamente per l'ingresso. Può instradare il traffico HTTP e HTTPS. Negli SKU a più livelli, Firewall di Azure offre la terminazione TLS in modo da poter implementare ispezioni a livello di payload.

Sono consigliate le procedure seguenti:
- Abilitare le impostazioni di diagnostica in Firewall di Azure per raccogliere i log del flusso di traffico, i log IDPS e i log delle richieste DNS.
- Essere il più specifico possibile nelle regole.
- Dove è pratico, evitare tag di servizio FQDN. Tuttavia, quando vengono usati, usare la variante regionale, che consente la comunicazione con tutti gli endpoint del servizio.
- Usare i gruppi IP per definire le origini che devono condividere le stesse regole per la durata del gruppo IP. I gruppi IP devono riflettere la strategia di segmentazione.
- Eseguire l'override della regola di autorizzazione FQDN dell'infrastruttura solo se il carico di lavoro richiede un controllo in uscita assoluto. L'override di questa regola comporta un compromesso sull'affidabilità, perché i requisiti della piattaforma Azure cambiano nei servizi.
Compromesso: Firewall di Azure può influire sulle prestazioni. L'ordine delle regole, la quantità, l'ispezione TLS e altri fattori possono causare una latenza significativa.

Può anche verificarsi un impatto sull'affidabilità del carico di lavoro. Potrebbe verificarsi un esaurimento delle porte SNAT (Network Address Translation) di origine. Per risolvere questo problema, aggiungere indirizzi IP pubblici in base alle esigenze.

Rischio: per il traffico in uscita, Azure assegna un indirizzo IP pubblico. Questa assegnazione può avere un impatto downstream sul gate di sicurezza esterno.
Web application firewall di Azure. Questo servizio supporta il filtro in ingresso e il traffico HTTP e HTTPS è destinato solo al traffico HTTP e HTTPS.

Offre sicurezza di base per attacchi comuni, ad esempio minacce identificate dal progetto OWASP (Open Worldwide Application Security Project) nel documento OWASP Top 10. Web application firewall di Azure offre anche altre funzionalità di sicurezza incentrate sul livello 7, ad esempio la limitazione della frequenza, le regole sql injection e lo scripting tra siti.

Con Web application firewall di Azure, è necessaria la terminazione TLS, perché la maggior parte dei controlli si basa sui payload.

È possibile integrare Web application firewall di Azure con router, ad esempio app Azure lication Gateway o Frontdoor di Azure. Le implementazioni di Web application firewall di Azure per questi tipi di router possono variare.

Firewall di Azure e Web application firewall di Azure non sono scelte che si escludono a vicenda. Per la soluzione di sicurezza perimetrale sono disponibili diverse opzioni. Per esempi, vedere Firewall e gateway applicazione per le reti virtuali.

Gruppi di sicurezza di rete

Un gruppo di sicurezza di rete è un firewall di livello 3 e 4 applicato a livello di subnet o scheda di interfaccia di rete. I gruppi di sicurezza di rete non vengono creati o applicati per impostazione predefinita.

Le regole del gruppo di sicurezza di rete fungono da firewall per arrestare il traffico in ingresso e in uscita nel perimetro di una subnet. Un gruppo di sicurezza di rete ha un set di regole predefinito eccessivamente permissivo. Ad esempio, le regole predefinite non impostano un firewall dal punto di vista in uscita. Per l'ingresso, non è consentito alcun traffico Internet in ingresso.

Per creare regole, iniziare con il set di regole predefinito:

Per il traffico in ingresso o in ingresso :
- Il traffico di rete virtuale da origini dirette, con peering e gateway VPN è consentito.
- Sono consentiti probe di integrità di Azure Load Balancer.
- Tutto l'altro traffico viene bloccato.
Per il traffico in uscita o in uscita:
- Il traffico di rete virtuale verso destinazioni dirette, con peering e gateway VPN è consentito.
- Il traffico verso Internet è consentito.
- Tutto l'altro traffico viene bloccato.

Considerare quindi i cinque fattori seguenti:

Protocollo
Indirizzo IP di origine
Porta di origine
Indirizzo IP di destinazione
Porta di destinazione

La mancanza di supporto per FQDN limita la funzionalità del gruppo di sicurezza di rete. È necessario fornire intervalli di indirizzi IP specifici per il carico di lavoro e sono difficili da gestire.

Per i servizi di Azure, tuttavia, è possibile usare i tag del servizio per riepilogare gli intervalli di indirizzi IP di origine e di destinazione. Un vantaggio per la sicurezza dei tag di servizio è che sono opachi per l'utente e che la responsabilità viene scaricata in Azure. È anche possibile assegnare un gruppo di sicurezza delle applicazioni come tipo di destinazione per instradare il traffico a. Questo tipo di gruppo denominato contiene risorse con esigenze di accesso in ingresso o in uscita simili.

Rischio: gli intervalli di tag di servizio sono molto ampi in modo da supportare la più ampia gamma possibile di clienti. Gli aggiornamenti ai tag di servizio ritardo rispetto alle modifiche apportate al servizio.

Nell'immagine precedente i gruppi di sicurezza di rete vengono applicati alla scheda di interfaccia di rete. Il traffico Internet e il traffico da subnet a subnet vengono negati. I gruppi di sicurezza di rete vengono applicati con il VirtualNetwork tag . In questo caso, quindi, le subnet delle reti con peering hanno una linea di vista diretta. L'ampia definizione del VirtualNetwork tag può avere un impatto significativo sulla sicurezza.

Quando si usano tag di servizio, usare le versioni internazionali quando possibile, ad esempio Storage.WestUS anziché Storage. Adottando questo approccio, si limita l'ambito a tutti gli endpoint in una determinata area.

Alcuni tag sono esclusivamente per il traffico in ingresso o in uscita . Altri sono per entrambi i tipi. I tag in ingresso in genere consentono il traffico da tutti i carichi di lavoro di hosting, ad esempio AzureFrontDoor.Backend, o da Azure per supportare i runtime del servizio, ad esempio LogicAppsManagement. Analogamente, i tag in uscita consentono il traffico a tutti i carichi di lavoro di hosting o da Azure per supportare i runtime del servizio.

Definire l'ambito delle regole il più possibile. Nell'esempio seguente la regola viene impostata su valori specifici. Viene negato qualsiasi altro tipo di traffico.

Informazioni	Esempio
Protocollo	Transmission Control Protocol (TCP), UDP
Indirizzo IP di origine	Consentire l'ingresso alla subnet dall'intervallo <di> indirizzi IP di origine: 4575/UDP
Porta di origine	Consenti ingresso alla subnet da <service-tag>: 443/TCP
Indirizzo IP di destinazione	Consentire l'uscita dalla subnet all'intervallo <>di indirizzi IP di destinazione: 443/TCP
Porta di destinazione	Consenti uscita dalla subnet al <tag> del servizio: 443/TCP

Per concludere:

Essere precisi quando si creano regole. Consentire solo il funzionamento del traffico necessario per l'applicazione. Nega tutto il resto. Questo approccio limita la linea di rete ai flussi di rete necessari per supportare il funzionamento del carico di lavoro. Il supporto di più flussi di rete del necessario comporta vettori di attacco non necessari ed estende la superficie di attacco.

La limitazione del traffico non implica che i flussi consentiti non rientrano nell'ambito di un attacco. Poiché i gruppi di sicurezza di rete funzionano ai livelli 3 e 4 nello stack OSI (Open Systems Interconnect), contengono solo informazioni sulla forma e sulla direzione. Ad esempio, se il carico di lavoro deve consentire il traffico DNS verso Internet, si userà un gruppo di sicurezza di rete di Internet:53:UDP. In questo caso, un utente malintenzionato potrebbe essere in grado di esfiltrare i dati tramite UDP sulla porta 53 ad altri servizi.
Comprendere che i gruppi di sicurezza di rete possono differire leggermente l'uno dall'altro. È facile trascurare l'intento delle differenze. Per avere un filtro granulare, è più sicuro creare gruppi di sicurezza di rete aggiuntivi. Configurare almeno un gruppo di sicurezza di rete.
- L'aggiunta di un gruppo di sicurezza di rete sblocca molti strumenti di diagnostica, ad esempio i log dei flussi e l'analisi del traffico di rete.
- Usare Criteri di Azure per controllare il traffico nelle subnet che non dispongono di gruppi di sicurezza di rete.
Se una subnet supporta i gruppi di sicurezza di rete, aggiungere un gruppo, anche se ha un impatto minimo.

Firewall del servizio di Azure

La maggior parte dei servizi di Azure offre un firewall a livello di servizio. Questa funzionalità controlla il traffico in ingresso verso il servizio da intervalli CIDR (Classless Inter-Domain Routing) specificati. Questi firewall offrono vantaggi:

Forniscono un livello di sicurezza di base.
Si verifica un impatto sulle prestazioni tollerabile.
La maggior parte dei servizi offre questi firewall senza costi aggiuntivi.
I firewall generano log tramite la diagnostica di Azure, che può essere utile per l'analisi dei modelli di accesso.

Esistono tuttavia anche problemi di sicurezza associati a questi firewall e esistono limitazioni associate alla fornitura di parametri. Ad esempio, se si usano agenti di compilazione ospitati da Microsoft, è necessario aprire l'intervallo di indirizzi IP per tutti gli agenti di compilazione ospitati da Microsoft. L'intervallo è quindi aperto all'agente di compilazione, ad altri tenant e agli avversari che potrebbero abusare del servizio.

Se si dispone di modelli di accesso per il servizio, che può essere configurato come set di regole del firewall del servizio, è necessario abilitare il servizio. È possibile usare Criteri di Azure per abilitarlo. Assicurarsi di non abilitare l'opzione Servizi di Azure attendibili se non è abilitata per impostazione predefinita. In questo modo vengono inseriti tutti i servizi dipendenti inclusi nell'ambito delle regole.

Per altre informazioni, vedere la documentazione del prodotto dei singoli servizi di Azure.

Endpoint privati

collegamento privato consente di assegnare a un'istanza PaaS un indirizzo IP privato. Il servizio non è quindi raggiungibile tramite Internet. Gli endpoint privati non sono supportati per tutti gli SKU.

Quando si usano endpoint privati, tenere presenti le raccomandazioni seguenti:

Configurare i servizi associati alle reti virtuali per contattare i servizi PaaS tramite endpoint privati, anche se tali servizi PaaS devono offrire l'accesso pubblico.
Promuovere l'uso dei gruppi di sicurezza di rete per gli endpoint privati per limitare l'accesso agli indirizzi IP dell'endpoint privato.
Usare sempre i firewall del servizio quando si usano endpoint privati.
Se possibile, se si dispone di un servizio accessibile solo tramite endpoint privati, rimuovere la configurazione DNS per l'endpoint pubblico.
Quando si implementano endpoint privati, prendere in considerazione i problemi di runtime line-of-sight. Si considerino anche i problemi di DevOps e di monitoraggio.
Usare Criteri di Azure per applicare la configurazione delle risorse.

Compromesso: gli SKU del servizio con endpoint privati sono costosi. Gli endpoint privati possono complicare le operazioni a causa dell'oscurità di rete. È necessario aggiungere agenti self-hosted, jump box, vpn e altri componenti all'architettura.

La gestione DNS può essere complessa nelle topologie di rete comuni. Potrebbe essere necessario introdurre server d'inoltro DNS e altri componenti.

Inserimento della rete virtuale

È possibile usare il processo di inserimento della rete virtuale per distribuire alcuni servizi di Azure nella rete. Esempi di tali servizi includono app Azure Servizio, Funzioni, Azure Gestione API e App Azure Spring. Questo processo isola l'applicazione da Internet, dai sistemi nelle reti private e da altri servizi di Azure. Il traffico in ingresso e in uscita dall'applicazione è consentito o negato in base alle regole di rete.

Azure Bastion

È possibile usare Azure Bastion per connettersi a una macchina virtuale usando il browser e il portale di Azure. Azure Bastion migliora la sicurezza delle connessioni RDP e SSH. Un caso d'uso tipico include la connessione a una jump box nella stessa rete virtuale o in una rete virtuale con peering. L'uso di Azure Bastion elimina la necessità che la macchina virtuale disponga di un indirizzo IP pubblico.

Protezione di Azure dagli attacchi DDoS

Ogni proprietà in Azure è protetta dalla protezione dell'infrastruttura DDoS di Azure senza costi aggiuntivi e senza alcuna configurazione aggiunta. Il livello di protezione è di base, ma la protezione ha soglie elevate. Non fornisce anche dati di telemetria o avvisi ed è indipendente dal carico di lavoro.

Gli SKU a livelli più elevati della protezione DDoS sono disponibili ma non sono gratuiti. La scalabilità e la capacità della rete di Azure distribuita a livello globale offre protezione dagli attacchi comuni a livello di rete. Tecnologie come il monitoraggio del traffico always-on e la mitigazione in tempo reale offrono questa funzionalità.

Per altre informazioni, vedere Panoramica di Protezione DDoS di Azure Standard.

Esempio

Ecco alcuni esempi che illustrano l'uso dei controlli di rete consigliati in questo articolo.

Ambiente IT

Questo esempio si basa sull'ambiente IT (Information Technology) stabilito nella baseline di sicurezza (SE:01). Questo approccio offre un'ampia comprensione dei controlli di rete applicati a vari perimetri per limitare il traffico.

Personas di attacco di rete. Diversi utenti possono essere considerati in un attacco di rete, tra cui Amministratori, dipendenti, client del cliente e utenti malintenzionati anonimi.
Accesso VPN. Un attore non valido potrebbe accedere all'ambiente locale tramite una VPN o un ambiente di Azure connesso all'ambiente locale tramite una VPN. Configurare con il protocollo IPSec per abilitare la comunicazione sicura.
Accesso pubblico all'applicazione. Disporre di un web application firewall (WAF) davanti all'applicazione per proteggerlo al livello 7 del livello OSI di rete.
Accesso dell'operatore. L'accesso remoto tramite il livello 4 dei livelli OSI di rete deve essere protetto. È consigliabile usare Firewall di Azure con le funzionalità IDP/IDS.
Protezione DDoS. Disporre della protezione DDoS per l'intera rete virtuale.
Topologia di rete. Una topologia di rete, ad esempio hub-spoke, è più sicura e ottimizza i costi. La rete hub fornisce una protezione centralizzata del firewall a tutti gli spoke con peering.
Endpoint privati: è consigliabile aggiungere servizi esposti pubblicamente nella rete privata usando endpoint privati. Questi creano una scheda di rete (NIC) nella rete virtuale privata e si associano al servizio di Azure.
Comunicazione TLS. Proteggere i dati in transito comunicando tramite TLS.
Gruppo di sicurezza di rete : proteggere i segmenti all'interno di una rete virtuale con gruppo di sicurezza di rete, una risorsa gratuita che filtra le comunicazioni in ingresso e in uscita TCP/UDP considerando gli intervalli di porte e IP. Parte del gruppo di sicurezza di rete è il gruppo di sicurezza delle applicazioni (ASG) che consente di creare tag per le regole di traffico per semplificare la gestione.
Log Analytics. Le risorse di Azure generano dati di telemetria inseriti in Log Analytics e quindi usati con una soluzione SIEM come Microsoft Sentinel per l'analisi.
Integrazione di Microsoft Sentinel. Log Analytics è integrato con Microsoft Sentinel e altre soluzioni come Microsoft Defender per il cloud.
Microsoft Defender per il cloud. Microsoft Defender per il cloud offre molte soluzioni di protezione del carico di lavoro, incluse le raccomandazioni di rete per l'ambiente.
Analisi del traffico: monitorare i controlli di rete con Analisi del traffico. Questa operazione viene configurata tramite Network Watcher, parte di Monitoraggio di Azure e aggrega i riscontri in ingresso e in uscita nelle subnet raccolte dal gruppo di sicurezza di rete.

Architettura per un carico di lavoro in contenitori

Questa architettura di esempio combina i controlli di rete descritti in questo articolo. L'esempio non mostra l'architettura completa. Si concentra invece sui controlli in ingresso nel cloud privato.

gateway applicazione è un servizio di bilanciamento del carico del traffico Web che è possibile usare per gestire il traffico verso le applicazioni Web. È possibile distribuire gateway applicazione in una subnet dedicata con controlli del gruppo di sicurezza di rete e controlli web application firewall.

La comunicazione con tutti i servizi PaaS viene eseguita tramite endpoint privati. Tutti gli endpoint vengono inseriti in una subnet dedicata. Protezione DDoS consente di proteggere tutti gli indirizzi IP pubblici configurati per un livello di protezione firewall di base o superiore.

Il traffico di gestione è limitato tramite Azure Bastion, che consente di fornire connettività RDP e SSH sicura e facile alle macchine virtuali direttamente dalla portale di Azure tramite TLS. Gli agenti di compilazione vengono inseriti nella rete virtuale in modo che abbiano una visualizzazione di rete per le risorse del carico di lavoro, ad esempio risorse di calcolo, registri contenitori e database. Questo approccio consente di fornire un ambiente sicuro e isolato per gli agenti di compilazione, che aumenta la protezione per il codice e gli artefatti.

I gruppi di sicurezza di rete a livello di subnet delle risorse di calcolo limitano il traffico in uscita. Il tunneling forzato viene usato per instradare tutto il traffico attraverso Firewall di Azure. Questo approccio consente di fornire un ambiente sicuro e isolato per le risorse di calcolo, che aumenta la protezione per i dati e le applicazioni.

Elenco di controllo relativo alla sicurezza

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo relativo alla sicurezza

Condividi tramite

Raccomandazioni per la rete e la connettività