Raccomandazioni per la rete e la connettività

Articolo
11/15/2023

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

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

Questa guida descrive i consigli per la progettazione di rete. Lo stato attivo è sui controlli di sicurezza che possono filtrare, bloccare e rilevare gli avversari che superano i limiti di rete a varie profondità dell'architettura.

È possibile rafforzare i controlli delle identità implementando misure di controllo degli accessi basate sulla rete. Oltre al controllo degli accessi in base all'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	Rete non distribuita come parte del carico di lavoro. Una rete ostile è considerata un vettore di minacce.
Flusso in ingresso	Traffico del carico di lavoro in ingresso.
Filtri di rete	Meccanismo che consente o blocca il traffico di rete in base alle regole specificate.
Segmentazione o isolamento di rete	Strategia che divide una rete in segmenti piccoli, isolati, con controlli di sicurezza applicati ai limiti. Questa tecnica consente di proteggere le risorse da reti ostili, ad esempio Internet.
Trasformazione di 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'offuscamento per proteggere gli asset del carico di lavoro dalle reti ostili. Le risorse che si trovano dietro un limite di rete sono 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 in reti separate aggiungendo limiti. Ad esempio, il traffico verso e da un livello applicazione supera un limite per comunicare con altri livelli, che hanno requisiti di sicurezza diversi. Livelli di segmentazione effettivezza l'approccio approfondito per la difesa.

Il limite di sicurezza principale è il margine 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 bordo devono essere altamente efficaci, perché questo limite è la prima linea di difesa.

Le reti virtuali forniscono un limite logico. Per progettazione, una rete virtuale non può comunicare con un'altra rete virtuale a meno che il limite non sia stato intenzionalmente interrotto attraverso il peering. L'architettura deve sfruttare questa misura di sicurezza avanzata e 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 usarli 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 le 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.
Trasformare. Modifica i 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 riestablizzarlo in un altro hop con un certificato gestito più rigorosamente.

Classificare i flussi di traffico

Il primo passaggio della classificazione dei 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 necessario di prossimità a tali reti?
Quali sono le caratteristiche di rete del flusso, ad esempio il protocollo previsto e la forma e l'origine 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 comunemente usati.

Visibilità dalle reti esterne

Pubblico. Un carico di lavoro è pubblico se l'applicazione e altri componenti sono raggiungibili da Internet pubblico. 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 può essere 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 da 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 maggior numero possibile di carichi di lavoro privati. Questo approccio impone ai pacchetti di 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

Ingresso. L'ingresso è traffico in ingresso che scorre 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 è previsto, consentito e sicuro. Gli utenti malintenzionati che analizzano gli intervalli di indirizzi IP del provider cloud pubblico possono penetrare correttamente le difese se non si controllano gli accessi o 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 la posizione in cui il traffico è diretto e se la destinazione è prevista, consentita e sicura. La destinazione potrebbe essere dannosa o associata ai rischi di esfiltrazione dei dati.

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

Ambito di influenza

Nord-sud. Il traffico che passa 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 il perimetro di rete 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 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 genera quando i componenti nel 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 in modo approfondito la difesa di rete 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 attenuare il maggior numero possibile di attacchi da e verso Internet.

Per l'uscita, inviare tutto il traffico associato a Internet attraverso un unico 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 offrono spesso 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 considerate 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 della 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 reti virtuali. Ridurre al minimo la linea di rete anche all'interno delle proprie reti private.
Ridurre al minimo il numero di voci DNS pubbliche usate per esporre meno del 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 siano visibili tra loro.

È possibile basare la segmentazione su molti fattori. Ad esempio, è possibile inserire livelli di 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 controllare 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, sull'origine e sulla 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 si 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. A un endpoint privato viene assegnato un indirizzo IP privato dalla rete virtuale. L'endpoint consente ad altre risorse della 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 comunica quindi con il servizio PaaS.

In questo esempio l'immagine a sinistra mostra il flusso per gli endpoint esposti pubblicamente. A destra, il flusso viene 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 nel firewall per il traffico in uscita. Gli endpoint privati bloccano tutto il traffico in uscita sulla porta per internet pubblico. 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 indirizzare 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à avanzate di difesa 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. Tuttavia, la comunicazione in ingresso è 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 firewall. A livello di subnet, è possibile filtrare il traffico usando i gruppi di sicurezza di rete.

Sicurezza dei dispositivi perimetrali

Per impostazione predefinita, l'ingresso e l'uscita passano entrambi agli 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). Ma 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 vada a Internet. Firewall di Azure può instradare il traffico che usa protocolli non HTTP e non HTTPS, ad esempio RDP (Remote Desktop Protocol), Secure Shell Protocol (SSH) e FTP (File Transfer Protocol). Il set di funzionalità di Firewall di Azure include:
- DnaT (Destination Network Address Translation) o port forwarding.
- Rilevamento delle firme del sistema di rilevamento e prevenzione delle intrusioni (IDPS).
- Regole di rete di livello 3, livello 4 e nome di dominio completo (FQDN).
Nota

La maggior parte delle organizzazioni dispone di 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 NextHopType di Internet nell'indirizzo 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 log del flusso di traffico, log IDPS e 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 a livello di area, 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 tutta 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 l'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 controllo di sicurezza esterno.
Azure Web application firewall. 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 gli attacchi comuni, ad esempio minacce identificate dal progetto OWASP (Open Worldwide Application Security Project) nel documento OWASP Top 10. Azure Web application firewall 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 Azure Web application firewall, è necessaria la terminazione TLS, perché la maggior parte dei controlli si basa sui payload.

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

Firewall di Azure e azure Web application firewall non si escludono a vicenda. Per la soluzione di sicurezza perimetrale sono disponibili varie 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.
- Azure Load Balancer sono consentiti probe di integrità.
- 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 di sicurezza dei tag di servizio è che sono opachi all'utente e la responsabilità viene disattivata in Azure. È anche possibile assegnare un gruppo di sicurezza dell'applicazione 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 soddisfare l'ampia gamma possibile di clienti. Aggiornamenti ai tag di servizio lag dietro le modifiche nel 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. Quindi, in questo caso, le subnet delle reti peered hanno una linea diretta di vista. La definizione generale del tag può avere un impatto significativo sulla VirtualNetwork sicurezza.

Quando si usano i tag di servizio, usare versioni regionali quando possibile, ad esempio Storage.WestUS anziché Storage. Prendendo 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 , o da Azure per supportare i runtime del servizio, ad esempio AzureFrontDoor.BackendLogicAppsManagement. 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.

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

Informazioni	Esempio
Protocollo	Protocollo di controllo di trasmissione (TCP), UDP
Indirizzo IP di origine	Consenti ingresso alla subnet dall'intervallo <>di indirizzi IP di origine: 4575/UDP
Porta di origine	Consenti ingresso alla subnet dal <tag> di servizio: 443/TCP
Indirizzo IP di destinazione	Consenti l'uscita dalla subnet all'intervallo <>di indirizzi IP di destinazione: 443/TCP
Porta di destinazione	Consenti l'uscita dalla subnet al <tag> del servizio: 443/TCP

Per concludere:

Essere precisi quando si creano regole. Consenti solo il traffico necessario per la funzione dell'applicazione. Nega tutto il resto. Questo approccio limita la linea di rete a flussi di rete necessari per supportare l'operazione del carico di lavoro. Il supporto di più flussi di rete rispetto alle esigenze porta a vettori di attacco non necessari e estende l'area di superficie.

La limitazione del traffico non implica che i flussi consentiti si trovino oltre l'ambito di un attacco. Poiché i gruppi di sicurezza di rete lavorano a livelli 3 e 4 nello stack Open Systems Interconnect (OSI), contengono solo informazioni sulla forma e sulla direzione. Ad esempio, se il carico di lavoro deve consentire il traffico DNS a Internet, usare 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 a un altro servizio.
Comprendere che i gruppi di sicurezza di rete possono essere leggermente diversi tra loro. È facile ignorare la finalità delle differenze. Per avere filtri granulari, è 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 di flusso 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 al servizio da intervalli di routing interdomini (CIDR) specificati. Questi firewall offrono vantaggi:

Forniscono un livello di sicurezza di base.
C'è 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 analizzare i modelli di accesso.

Esistono tuttavia anche problemi di sicurezza associati a questi firewall e sono presenti limitazioni associate all'offerta 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 sono disponibili 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 tutti i servizi dipendenti che si trovano nell'ambito delle regole.

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

Endpoint privati

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

Tenere presente quanto segue quando si usano endpoint privati:

Configurare i servizi associati alle reti virtuali per contattare i servizi PaaS tramite endpoint privati, anche se tali servizi PaaS devono anche 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 firewall di servizio quando si usano endpoint privati.
Quando possibile, se si dispone di un servizio accessibile solo tramite endpoint privati, rimuovere la configurazione DNS per l'endpoint pubblico.
Prendere in considerazione i problemi relativi alla riga di esecuzione quando si implementano endpoint privati. Ma prendere in considerazione anche i problemi di devOps e 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'offuscamento della rete. È necessario aggiungere agenti self-hosted, jump box, UNA VPN e altri componenti all'architettura.

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

Inserimento di rete virtuale

È possibile usare il processo di inserimento della rete virtuale per distribuire alcuni servizi di Azure nella rete. Alcuni esempi di tali servizi includono Servizio app di Azure, Funzioni, Gestione API di Azure e Azure Spring Apps. Questo processo isola l'applicazione da Internet, sistemi in reti private e 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 l'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 a una rete virtuale con peering. L'uso di Azure Bastion rimuove la necessità che la macchina virtuale disponga di un indirizzo IP pubblico.

Protezione DDoS di Azure

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 è l'agnostico del carico di lavoro.

Gli SKU a più livelli di 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. Le 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 perimetrali 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 può 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. Avere un web application firewall (WAF) davanti all'applicazione per proteggerlo nel livello 7 della rete OSI.
Accesso dell'operatore. L'accesso remoto tramite il livello 4 dei livelli OSI di rete deve essere protetto. È consigliabile usare Firewall di Azure con 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 offre protezione centralizzata del firewall a tutti gli spoke peered.
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 (NSG): proteggere i segmenti all'interno di una rete virtuale con NSG, una risorsa gratuita che filtra le comunicazioni in ingresso e UDP TCP/UDP considerando gli intervalli ip e porte. Parte del gruppo di sicurezza di rete è il gruppo di sicurezza 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, 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 Cloud.
Microsoft Defender per Cloud. Microsoft Defender per Cloud offre molte soluzioni di protezione del carico di lavoro, tra cui 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 aggregazioni 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 alle applicazioni Web. È possibile distribuire gateway applicazione in una subnet dedicata con controlli del gruppo di sicurezza di rete e controlli web application firewall sul posto.

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 una 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 dall'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 migliora 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 migliora la protezione per i dati e le applicazioni.

Elenco di controllo relativo alla sicurezza

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo della sicurezza

Raccomandazioni per la rete e la connettività