Sicurezza di rete

La sicurezza di rete protegge i carichi di lavoro cloud da minacce come l'accesso non autorizzato, le violazioni dei dati e l'interruzione del servizio controllando il traffico a più limiti. A differenza delle difese tradizionali incentrate sul perimetro, gli ambienti cloud moderni richiedono strategie di difesa avanzata con segmentazione, connettività privata e protezione perimetrale per affrontare le superfici di attacco dinamiche, inclusi i servizi esposti, i percorsi di spostamento laterale e i canali di comando e controllo. Le organizzazioni che implementano controlli di rete completi mantengono ambienti protetti per impostazione predefinita, mentre quelli che ignorano questi controlli devono affrontare spostamenti laterali senza restrizioni e esposizione prolungata alle minacce.

Ecco i tre pilastri principali del dominio di sicurezza di rete.

Limiti di rete sicuri: Applicare controlli rigorosi ai bordi della rete e tra segmenti tramite difesa a più livelli che incorporano firewall, protezione DDoS, firewall applicazione Web e connettività privata, seguendo il principio dei privilegi minimi per negare il traffico non autorizzato per impostazione predefinita.

Controlli correlati:

• NS-2: Proteggere i servizi cloud con controlli di rete
• NS-3: Distribuire il firewall nella rete perimetrale della rete aziendale
• NS-5: Implementare la protezione DDoS
• NS-6: Distribuire il firewall per applicazioni web
• NS-9: Connettersi privatamente alla rete locale o cloud

Applicare l'isolamento di rete: Dividere le reti in segmenti isolati allineati alla strategia di segmentazione aziendale e ai livelli di rischio per limitare la diffusione delle minacce, ridurre la superficie di attacco e impedire spostamenti laterali non autorizzati.

Controlli correlati:

• NS-1: Stabilire limiti di segmentazione di rete

Monitorare e rispondere: Mantenere visibilità continua sulle attività di rete tramite monitoraggio completo, rilevamento delle intrusioni e sicurezza del protocollo per identificare rapidamente comportamenti sospetti, violazioni dei criteri e minacce attive.

Controlli correlati:

• NS-4: Distribuire sistemi di rilevamento/prevenzione delle intrusioni (IDS/IPS)
• NS-8: rilevare e disabilitare i servizi e i protocolli non sicuri
• NS-10: Assicurare la sicurezza del DNS (Domain Name System)

NS-1: Stabilire limiti di segmentazione di rete

Criteri di Azure: Vedere Definizioni di criteri predefiniti di Azure: NS-1.

Principio di sicurezza

La segmentazione di rete comporta la divisione di una rete in segmenti più piccoli e isolati per controllare e limitare il flusso di traffico tra le risorse cloud per ridurre il raggio di esplosione.

Progettare la segmentazione di rete per garantire che la distribuzione della rete virtuale sia allineata alla strategia di segmentazione aziendale e ai diversi livelli di rischio. La strategia di segmentazione comune include:

• Separare Corpnet con le reti dell'applicazione
• Reti di applicazioni separate
• Separare le reti di ambiente di produzione e test

Per altre informazioni sulle strategie chiave per la segmentazione di rete, vedere Azure Well-Architected Framework:

• Strategia di segmentazione di Azure

Rischio da mitigare

Senza limiti di segmentazione di rete, le organizzazioni devono affrontare uno spostamento laterale senza restrizioni, consentendo agli utenti malintenzionati di attraversare le infrastrutture di rete e compromettere gli asset di alto valore.

• Esposizione alla rete flat: L'assenza di segmentazione consente lo spostamento laterale senza restrizioni, consentendo agli avversari di compromettere asset di valore elevato attraversando una topologia di rete non partizionata.
• Percorsi di escalation dei privilegi: Limiti inadeguati consentono vettori di accesso non autorizzati, facilitando l'escalation dei privilegi utente tramite l'accesso a sottoreti e carichi di lavoro sensibili.
• Propagazione malware: La segmentazione insufficiente consente una rapida diffusione di codice dannoso, ad esempio ransomware tra nodi interconnessi, amplificando la superficie di attacco e l'impatto operativo.
• Cecità del traffico est-ovest: Il traffico inter segmento senza restrizioni ostacola il rilevamento delle anomalie e la risposta agli eventi imprevisti, riducendo la visibilità dei movimenti interni delle minacce e complicando l'analisi forense.

MITRE ATT&CK

• Accesso iniziale (TA0001): accesso non autorizzato alle reti e ai servizi esposti (ad esempio, T1190 - Exploit Public-Facing Application).
• Spostamento laterale (TA0008): attacco tramite pivot da reti virtuali e traffico tra subnet non limitato (ad esempio, T1021 - Servizi remoti).
• Esfiltrazione (TA0010): esfiltrazione di dati da traffico in uscita non limitato per trasferimenti di dati non autorizzati a server esterni (ad esempio T1041 - Esfiltrazione su canale C2).
• Comando e controllo (TA0011): propagazione di malware tramite comunicazioni con indirizzi IP o domini dannosi tramite regole del firewall e intelligence sulle minacce (ad esempio, T1071 - Protocollo livello applicazione).

NS-1.1: Creare la segmentazione usando la rete virtuale e le subnet

L'isolamento della rete virtuale stabilisce limiti di sicurezza fondamentali all'interno degli ambienti cloud, consentendo alle organizzazioni di separare i carichi di lavoro in base al livello di attendibilità, all'unità organizzativa o al raggruppamento di applicazioni. Questo approccio impedisce lo spostamento laterale senza restrizioni e riduce il raggio di esplosione quando si verificano violazioni, allineando l'architettura di rete alle strategie di segmentazione aziendale e ai principi zero-trust.

Implementare la segmentazione della rete virtuale creando limiti di rete isolati e suddivisioni:

• Progettare la topologia della rete virtuale in base alla strategia di segmentazione: Creare reti virtuali allineate con zone di attendibilità, unità organizzative o raggruppamenti di applicazioni definiti nella strategia di segmentazione aziendale, assicurandosi che ogni rete virtuale rappresenti un limite di sicurezza distinto.

• Isolare i carichi di lavoro ad alto rischio: Identificare i carichi di lavoro che richiedono un isolamento rigoroso (ad esempio, database di produzione, sistemi di elaborazione dei pagamenti) e distribuirli in reti virtuali dedicate isolate per ridurre al minimo l'esposizione e prevenire la contaminazione incrociata.

• Creare subnet per la segmentazione granulare: All'interno di ogni rete virtuale creare subnet distinte non sovrapposte per segmentare ulteriormente la rete in base ai livelli applicazione (ad esempio, livello Web, livello applicazione, livello di database) o requisiti funzionali, consentendo un controllo del traffico più preciso e la micro-segmentazione.

NS-1.2: Limitare il traffico di rete tramite il gruppo di sicurezza di rete

I gruppi di sicurezza di rete applicano il filtro del traffico a livello di subnet e interfaccia di rete, consentendo un controllo preciso sui flussi di comunicazione tra segmenti di rete e reti esterne. Implementando criteri di negazione per impostazione predefinita con regole di autorizzazione esplicite, le organizzazioni garantiscono solo il traffico autorizzato attraversa i limiti di rete, impedendo l'accesso non autorizzato e riducendo la superficie di attacco.

Implementare la restrizione del traffico di rete usando le regole del gruppo di sicurezza di rete:

• Identificare i requisiti di comunicazione: Analizzare le risorse in ogni rete virtuale per comprendere le esigenze di comunicazione del traffico nord-sud (esterno) e est-ovest (interno), documentando porte, protocolli, indirizzi di origine e indirizzi di destinazione necessari per le funzioni aziendali legittime.

• Definire regole di autorizzazione e negazione esplicite: Per le applicazioni ben definite (ad esempio, architetture a tre livelli), usare l'approccio "Nega per impostazione predefinita, consentire l'eccezione" per creare regole del gruppo di sicurezza di rete basate su porta, protocollo, indirizzo IP di origine e indirizzo IP di destinazione, consentendo in modo esplicito solo il traffico necessario negando tutte le altre comunicazioni.

• Usare i gruppi di sicurezza delle applicazioni per scenari complessi: Quando molti endpoint e applicazioni interagiscono, semplificare la gestione delle regole del gruppo di sicurezza di rete usando i gruppi di sicurezza delle applicazioni per raggruppare le risorse in modo logico (ad esempio, server Web, server di database), quindi definire regole del gruppo di sicurezza di rete in base a questi gruppi anziché indirizzi IP espliciti, migliorando la gestibilità e riducendo la complessità della configurazione.

• Monitorare e ottimizzare i log dei flussi: Abilitare la registrazione del flusso di rete virtuale per monitorare il traffico consentito o negato dalle regole del gruppo di sicurezza di rete, identificando spesso il traffico negato che può indicare errori di configurazione o traffico spesso consentito che potrebbe informare l'ottimizzazione delle regole e ridurre il disturbo della registrazione.

Esempio di implementazione

Un'organizzazione doveva proteggere un'applicazione multilivello con ambienti di produzione, sviluppo e test separati, impedendo allo spostamento laterale non autorizzato e all'accesso esterno.

Sfida: L'organizzazione aveva un'applicazione a tre livelli (Web, applicazione, database) con tutte le risorse in un singolo segmento di rete di grandi dimensioni, consentendo la comunicazione senza restrizioni tra tutti i livelli e gli ambienti. Ciò ha creato rischi significativi per la sicurezza, tra cui il potenziale spostamento laterale tra produzione e non di produzione, l'accesso a Internet senza restrizioni dai server di database e l'impossibilità di isolare carichi di lavoro ad alto rischio.

Approccio alla soluzione:

• Segmentazione della rete virtuale per ambiente: Sono state create reti virtuali separate per la produzione (10.0.0.0/16), lo sviluppo (10.1.0.0/16) e i test (10.2.0.0/16), stabilendo i limiti di isolamento della rete che impediscono l'accesso incrociato all'ambiente e limitano il raggio di esplosione di potenziali violazioni.
• Segmentazione della subnet per livello: All'interno della rete virtuale di produzione, sono state create subnet distinte non sovrapposte per ogni livello applicazione, il livello Web (10.0.1.0/24), il livello applicazione (10.0.2.0/24) e il livello di database (10.0.3.0/24), abilitando il controllo granulare del traffico tra i livelli.
• Regole del gruppo di sicurezza di rete per il controllo del traffico nord-sud: Regole del gruppo di sicurezza di rete configurate per negare tutto il traffico in ingresso da Internet (0.0.0.0/0) alle subnet interne e limitare l'accesso Internet in uscita solo a destinazioni attendibili, con regole specifiche che consentono solo le connessioni esterne necessarie per il livello Web, bloccando l'accesso a Internet dal livello di database.
• Regole NSG per il controllo del traffico est-ovest: Implementati criteri di negazione per impostazione predefinita con regole di autorizzazione esplicite tra gli strati: lo strato web consente il traffico esterno verso lo strato applicazione solo sulle porte richieste, lo strato applicazione consente il traffico esterno verso lo strato database solo sulla porta 1433 (SQL), e lo strato database nega tutto il traffico in ingresso tranne quello proveniente dalla subnet dello strato applicazione.
• Accesso alla gestione remota: Porte di gestione remota limitate (RDP 3389/TCP, SSH 22/TCP) per accettare connessioni solo dalla subnet host bastion attendibile (10.0.0.0/26), eliminando l'accesso diretto a Internet alle interfacce di gestione.

Risultato: L'organizzazione ha eliminato lo spostamento laterale senza restrizioni tra i livelli applicazione e gli ambienti, riducendo significativamente la superficie di attacco rimuovendo l'accesso diretto a Internet dai sistemi back-end e stabilito limiti di rete applicabili allineati ai principi zero-trust. I log dei flussi hanno abilitato il monitoraggio continuo del traffico consentito e negato per l'ottimizzazione continua e la convalida del comportamento di sicurezza.

Livello di criticità

Indispensabile.

Mapping controlli

• NIST SP 800-53 Rev.5: SC-7, SC-32, AC-4, CM-7
• PCI-DSS v4: 1.2.1, 1.3.1, 1.4.1
• Controlli CIS v8.1: 12.1, 12.2, 12.6
• NIST CSF v2.0: PR.IR-01, PR.AC-05
• ISO 27001:2022: A.8.20, A.8.21
• SOC 2: CC6.1, CC6.6

NS-2: Proteggere i servizi nativi del cloud con controlli di rete

Criteri di Azure: Vedere Definizioni di criteri predefiniti di Azure: NS-2.

Principio di sicurezza

Usare le funzionalità native del servizio per proteggere l'accesso di rete alle risorse per evitare e ridurre l'esposizione delle risorse alla rete non attendibile. Queste funzionalità includono:

• Stabilire punti di accesso privati per le risorse per evitare l'esposizione del traffico di rete attraverso la rete pubblica.
• Distribuire la risorsa nelle reti virtuali in cui è possibile limitare la rete virtuale per stabilire un punto di accesso privato per il servizio.
• Configurare firewall nativi del servizio per limitare il traffico in ingresso o disabilitare l'accesso alla rete pubblica.

Nota: oltre al controllo di base dell'accesso alla rete e al filtro del traffico, è consigliabile usare anche le funzionalità di rilevamento delle minacce per monitorare i servizi come DNS (NS-10) per rilevare la possibile esfiltrazione dei dati.

Rischio da mitigare

Gli attori delle minacce sfruttano i servizi cloud esposti pubblicamente per eseguire l'esfiltrazione dei dati, gli attacchi a livello di applicazione e l'intercettazione del traffico.

• Esfiltrazione di dati tramite endpoint pubblici: Gli utenti malintenzionati sfruttano account di archiviazione, database o API accessibili pubblicamente per esfiltrare i dati sensibili stabilendo connessioni non autorizzate agli endpoint esposti, ignorando i controlli di segmentazione di rete e abilitando il furto di dati su larga scala.
• Attacchi a livello di applicazione contro gli endpoint pubblici: Attacchi DDoS (Distributed Denial of Service), SQL injection e altri exploit dell'applicazione destinati a servizi Web, API e database esposti pubblicamente, risorse sovraccariche o exploit di vulnerabilità per causare interruzioni del servizio o compromissione dei dati.
• Attacchi man-in-the-middle: Gli utenti malintenzionati intercettano il traffico in reti pubbliche verso servizi esposti pubblicamente, acquisendo credenziali, token di sessione o dati sensibili trasmessi senza una crittografia adeguata o connettività privata, abilitando l'acquisizione di account o il furto di dati.

MITRE ATT&CK

• Accesso iniziale (TA0001): accesso non autorizzato dovuto all'esposizione pubblica su Internet dei servizi cloud (e.g., servizi di archiviazione, servizi di database), sfruttamento che prende di mira gli endpoint pubblici (e.g., T1190 - Exploit Public-Facing Application).
• Esfiltrazione (TA0010): esfiltrazione dei dati instradando il traffico su connessioni di rete virtuale private, riducendo il rischio di perdita di dati a server esterni ,ad esempio T1041 - Esfiltrazione su canale C2.
• Spostamento laterale (TA0008): i servizi di pivot degli utenti malintenzionati all'interno di reti virtuali, l'accesso non autorizzato tra le risorse cloud (ad esempio, T1021 - Servizi remoti).

NS-2.1 Usare il collegamento privato per la connessione al servizio

La connettività privata elimina l'esposizione a Internet pubblico per i servizi cloud stabilendo percorsi di rete diretti all'interno dell'infrastruttura virtuale. Il collegamento privato crea endpoint privati con indirizzi IP dedicati all'interno delle reti virtuali, assicurando che il traffico verso i servizi cloud non attraversi mai la rete Internet pubblica mantenendo al tempo stesso modelli di accesso basati su DNS. Questo approccio riduce significativamente la superficie di attacco e impedisce l'esfiltrazione dei dati tramite endpoint accessibili pubblicamente.

Implementare la connettività privata per i servizi cloud tramite questa procedura:

• Distribuire endpoint privati per i servizi supportati: Creare endpoint privati all'interno della rete virtuale per le risorse di Azure che supportano il collegamento privato (ad esempio, Archiviazione di Azure, database SQL di Azure, Azure Key Vault), stabilire indirizzi IP privati (ad esempio, 10.0.2.4) accessibili solo dalla rete virtuale.

• Configurare le zone DNS private: Creare zone DNS private di Azure per eseguire l'override della risoluzione DNS pubblica, assicurando che nomi di dominio completi (FQDN) come mystorageaccount1.blob.core.windows.net venga risolto in indirizzi IP privati, all'interno della rete virtuale anziché endpoint pubblici, mantenendo una connettività senza interruzioni per le applicazioni utilizzando l'accesso basato su FQDN.

• Disabilitare l'accesso pubblico: Configurare le impostazioni a livello di servizio per disabilitare completamente l'accesso alla rete pubblica una volta distribuiti gli endpoint privati, assicurando che tutti i flussi di traffico vengano trasmessi esclusivamente attraverso la connettività privata senza fallback agli endpoint pubblici.

Nota: Alcuni servizi di Azure possono anche consentire la comunicazione privata tramite la funzionalità endpoint di servizio , anche se il collegamento privato di Azure è consigliato per l'accesso sicuro e privato ai servizi ospitati nella piattaforma Azure. Per le distribuzioni come i servizi Web ospitati in macchine virtuali di Azure, evitare di assegnare indirizzi IP pubblici direttamente alle macchine virtuali, a meno che non siano fortemente giustificati; Usare invece il gateway applicazione di Azure o Azure Load Balancer come front-end per l'accesso al servizio.

NS-2.2 Distribuire il servizio nella rete virtuale

L'integrazione della rete virtuale consente ai servizi cloud di operare entro i limiti di rete privata, stabilendo la connettività diretta alle risorse ospitate dalla rete virtuale senza esposizione a Internet pubblico. Distribuendo i servizi nelle reti virtuali, le organizzazioni ottengono un controllo granulare sul traffico di rete attraverso gruppi di sicurezza e tabelle di route mantenendo al tempo l'isolamento del servizio dalle minacce esterne.

Distribuire i servizi con integrazione VNet laddove supportato:

• Distribuire i servizi nelle reti virtuali: Per i servizi che supportano l'integrazione della rete virtuale (ad esempio, Servizio app di Azure, Funzioni di Azure, Istanze di Azure Container), configurare la distribuzione in reti virtuali nuove o esistenti, specificando subnet appropriate allineate alla strategia di segmentazione e abilitando la comunicazione privata con altre risorse di rete virtuale.

• Configurare i controlli di sicurezza di rete: Applicare regole del gruppo di sicurezza di rete (NSG) alla subnet del servizio per limitare il traffico in ingresso e in uscita, implementando l'accesso con privilegi minimi consentendo solo la comunicazione necessaria a destinazioni specifiche (ad esempio, subnet del database, endpoint di archiviazione) negando tutto il traffico.

NS-2.3 Configurare il firewall nativo del servizio

I firewall a livello di servizio forniscono una protezione avanzata della difesa limitando l'accesso alla rete a livello di risorsa, integrando i controlli a livello di rete con limiti di sicurezza specifici dell'applicazione. Queste funzionalità firewall native consentono alle organizzazioni di limitare l'esposizione a intervalli IP o reti virtuali specifici, disabilitando completamente l'accesso pubblico quando appropriato, riducendo la superficie di attacco senza richiedere modifiche complesse alla topologia di rete.

Configurare i firewall del servizio per limitare l'accesso:

• Abilitare le funzionalità del firewall del servizio: Per i servizi che supportano firewall nativi ,ad esempio Archiviazione di Azure, database SQL di Azure, Azure Key Vault, abilitare la funzionalità del firewall durante la creazione di risorse o sulle risorse esistenti per controllare quali reti possono accedere al servizio.

• Definire regole basate su IP o basate su rete virtuale: Configurare le regole del firewall per consentire l'accesso solo da intervalli IP pubblici specifici (ad esempio, reti aziendali) o subnet di rete virtuale di Azure specifiche, implementando l'accesso con privilegi minimi negando tutte le altre origini.

• Disabilitare l'accesso pubblico quando possibile: Quando i servizi richiedono l'accesso solo da reti private, usare l'opzione toggle per disabilitare completamente l'accesso alla rete pubblica, assicurandosi che il servizio non sia raggiungibile da Internet indipendentemente dalle regole basate su IP.

NS-2.4 Usare il perimetro di sicurezza di rete per l'isolamento delle risorse PaaS

Il perimetro di sicurezza di rete stabilisce un limite di rete logica intorno a più risorse PaaS, consentendo la comunicazione sicura da servizio a servizio all'interno di un perimetro attendibile esplicito, impedendo al tempo stesso l'esfiltrazione di dati non autorizzata. A differenza dei controlli per risorsa, il perimetro di sicurezza di rete fornisce un limite di sicurezza unificato che consente la comunicazione all'interno del perimetro senza regole di accesso individuali, bloccando l'accesso esterno per impostazione predefinita.

Implementare il perimetro di sicurezza di rete per proteggere le risorse PaaS:

• Creare e associare risorse: Stabilire un perimetro di sicurezza di rete e aggiungere risorse PaaS supportate (Archiviazione di Azure, database SQL, Key Vault, Hub eventi, Cosmos DB) tramite associazioni di risorse, abilitando la comunicazione all'interno del perimetro in cui le risorse associate possono comunicare liberamente.

• Configurare le modalità di accesso e le regole: Iniziare con la modalità transizione per comprendere i modelli di accesso prima di passare alla modalità applicata per la massima protezione. Definire regole di accesso esplicite in ingresso e in uscita usando indirizzi IP, sottoscrizioni o FQDN per controllare il traffico all'esterno del perimetro mantenendo il comportamento di negazione predefinito.

• Abilitare il monitoraggio e l'integrazione del collegamento privato: Configurare i log di diagnostica per acquisire i tentativi di accesso e le violazioni dei criteri. Il traffico dell'endpoint privato viene automaticamente consentito nel perimetro, completando la connettività da rete virtuale a PaaS con controlli di esfiltrazione dei dati a livello di perimetro.

Esempio di implementazione

Un'organizzazione doveva proteggere le risorse di archiviazione e database back-end, abilitando l'accesso dai servizi dell'applicazione senza esporre le risorse a Internet pubblico.

Sfida: L'organizzazione aveva un database SQL di Azure e account di archiviazione di Azure con endpoint pubblici predefiniti, rendendoli accessibili da Internet e creando rischi significativi per l'esfiltrazione dei dati. I servizi dell'applicazione sono stati distribuiti con indirizzi IP pubblici e non dispongono dell'integrazione della rete virtuale, impedendo i controlli di accesso basati sulla rete privata. I firewall a livello di servizio non sono stati configurati, consentendo l'accesso senza restrizioni da qualsiasi origine al termine dell'autenticazione.

Approccio alla soluzione:

• Endpoint collegamento privato per i servizi PaaS: Gli endpoint privati distribuiti per il database SQL di Azure (ip privato assegnato 10.0.2.4) e l'account di archiviazione di Azure (ip privato assegnato 10.0.2.5) all'interno di una subnet dell'endpoint privato dedicata (10.0.2.0/24), stabilendo la connettività privata che instrada il traffico sulla rete backbone di Azure senza esposizione a Internet.
• Zone DNS private per la risoluzione dei nomi: Sono state create zone DNS private di Azure per eseguire l'override della risoluzione DNS pubblica, assicurandosi che gli FQDN dell'applicazione (ad esempio, mysqldb.database.windows.net, mystorageaccount.blob.core.windows.net) vengano risolti in indirizzi IP privati all'interno della rete virtuale anziché negli endpoint pubblici, mantenendo la connettività senza problemi per le applicazioni che usano l'accesso basato su FQDN.
• Integrazione della rete virtuale per i servizi dell'applicazione: Integrazione della rete virtuale configurata per il servizio app di Azure, distribuzione dell'applicazione in una subnet dell'applicazione (10.0.1.0/24) per abilitare la comunicazione diretta con endpoint privati senza richiedere indirizzi IP pubblici o routing Internet.
• Firewall nativi del servizio: Sono stati abilitati firewall a livello di servizio in Archiviazione di Azure per limitare l'accesso a subnet di rete virtuale specifiche (subnet dell'applicazione 10.0.1.0/24) e ai servizi Microsoft attendibili, disabilitando completamente l'accesso alla rete pubblica a livello di servizio per il database SQL di Azure per applicare la connettività solo privata.
• Regole del gruppo di sicurezza di rete per la difesa avanzata: Le regole del gruppo di sicurezza di rete applicate alla subnet dell'applicazione consentono il traffico in uscita solo alla subnet dell'endpoint privato (10.0.2.0/24) sulle porte richieste (443 per Archiviazione, 1433 per SQL), implementando il controllo di accesso con privilegi minimi che integra le protezioni a livello di servizio.

Risultato: L'organizzazione ha eliminato l'esposizione a Internet pubblico per le risorse back-end, riducendo significativamente i rischi di esfiltrazione dei dati e la superficie di attacco. La connettività privata garantisce che tutto il traffico tra le applicazioni e i servizi dati rimanga nella rete backbone di Azure senza attraversare la rete Internet pubblica, mentre i controlli a più livelli (collegamento privato, zone DNS, firewall del servizio, gruppi di sicurezza di rete) hanno fornito protezione avanzata della difesa allineata ai principi senza attendibilità.

Livello di criticità

Indispensabile.

Mapping controlli

• NIST SP 800-53 Rev.5: SC-7(4), SC-7(5), AC-4(21)
• PCI-DSS v4: 1.3.1, 1.3.2, 1.4.2
• Controlli CIS v8.1: 12.4, 12.7
• NIST CSF v2.0: PR.AC-05, PR.DS-05
• ISO 27001:2022: A.8.20, A.8.22
• SOC 2: CC6.1, CC6.6

NS-3: Implementare il firewall ai bordi della rete aziendale

Criteri di Azure: Vedere Definizioni di criteri predefiniti di Azure: NS-3.

Principio di sicurezza

Usare il firewall nella rete perimetrale per eseguire filtri avanzati sul traffico di rete da e verso reti esterne, ad esempio Internet e tra segmenti di rete interni.

Come minimo, i criteri firewall devono includere:

• Blocca indirizzi IP e siti non noti.
• Limitare i protocolli ad alto rischio, ad esempio protocolli di gestione remota e protocolli Intranet nelle reti perimetrali per impedire l'accesso non autorizzato o lo spostamento laterale.
• Applicare le regole dell'applicazione per consentire solo destinazioni esterne approvate e bloccare siti non autorizzati o rischiosi.

Rischio da mitigare

Gli avversari sfruttano le vulnerabilità esposte a reti pubbliche o non attendibili tramite protocolli accessibili, domini dannosi e controlli di rete deboli.

• Accesso non autorizzato tramite protocolli esposti: I protocolli accessibili pubblicamente come RDP (TCP 3389) o SMB (TCP 445) consentono agli utenti malintenzionati di ottenere accessi non autorizzati, compromettendo l'integrità del sistema tramite exploit come attacchi di forza bruta o CVE.
• Malware e phishing tramite domini dannosi/INDIRIZZI IP: Domini dannosi e indirizzi IP facilitano la distribuzione di malware o le campagne di phishing, mettendo in pericolo gli endpoint e i dati sensibili tramite attacchi di ingegneria sociale o di comando e controllo.
• Esfiltrazione di dati tramite traffico in uscita senza restrizioni: Il traffico in uscita non controllato verso destinazioni non approvati consente agli avversari di esfiltrare dati sensibili, rischiare violazioni e violazioni della conformità tramite canali coperti come i POST HTTPS.
• Spostamento laterale a causa della segmentazione scarsa: La segmentazione di rete insufficiente consente agli utenti malintenzionati di eseguire pivot internamente, sfruttando il traffico tra segmenti (ad esempio, SMB, Kerberos) per propagarsi da sistemi compromessi.
• Vulnerabilità da applicazioni/URL non attendibili: L'accesso a URL e applicazioni rischiosi o non attendibili aumenta l'esposizione a exploit, elevando i rischi degli eventi imprevisti e non conformità con gli standard normativi.

MITRE ATT&CK

• Accesso iniziale (TA0001): accesso non autorizzato a protocolli ad alto rischio (ad esempio, RDP/TCP 3389, SSH/TCP 22) o domini dannosi (ad esempio T1190 - Exploit Public-Facing Application).
• Comando e controllo (TA0011): malware che si connette a indirizzi IP/domini dannosi (ad esempio, T1071 - Protocollo del livello applicativo).
• Esfiltrazione (TA0010): trasferimenti di dati non autorizzati tramite traffico in uscita verso destinazioni non approvati (ad esempio, T1041 - Esfiltrazione su canale C2).
• Spostamento laterale (TA0008): impedisce il pivot interno tramite traffico tra segmenti non filtrati (ad esempio, SMB/TCP 445, Kerberos/TCP 88) (ad esempio T1021 - Servizi remoti).

NS-3.1 Preparare la distribuzione di Firewall di Azure

La distribuzione di Firewall di Azure richiede una topologia di rete appropriata che consenta l'ispezione centralizzata del traffico tra i limiti di rete. Le architetture hub-and-spoke posizionano il firewall al centro della rete, e instradano tutto il traffico dei nodi spoke attraverso un punto di ispezione centrale. Nel contempo, le route definite dall'utente assicurano che il flusso del traffico segua i percorsi previsti. Questa preparazione stabilisce le basi per la protezione perimetrale completa e il filtro inter segmento.

Preparare l'infrastruttura di rete per la distribuzione di Firewall di Azure:

• Configurare la topologia di rete virtuale hub/spoke: Distribuire Firewall di Azure in una rete virtuale hub per gestire e proteggere centralmente il traffico tra più reti virtuali spoke che ospitano carichi di lavoro dell'applicazione, stabilendo un singolo punto di imposizione per i criteri di sicurezza di rete.

• Aggiungere reti virtuali spoke: Usare il peering VNet per connettere ogni rete virtuale spoke alla rete virtuale dell'hub in cui viene distribuito il Firewall di Azure, consentendo la comunicazione tra gli spoke tramite l'hub mantenendo l'isolamento delle reti.

• Configurare route definite dall'utente (UDR): Creare tabelle di route che indirizzano il traffico di rete da reti virtuali spoke tramite il Firewall di Azure nella rete hub, incluse le route per l'uscita Internet (0.0.0.0/0) e, facoltativamente, il traffico tra spoke, se la comunicazione spoke-to-spoke richiede ispezione.

NS-3.2 Distribuire Firewall di Azure con criteri appropriati

Firewall di Azure offre filtri del traffico a livello di applicazione con stato con gestione centralizzata dei criteri nei segmenti di rete aziendali. Combinando regole di rete, regole dell'applicazione e intelligence sulle minacce, i firewall controllano i flussi di traffico a più livelli, mentre il filtro url e l'ispezione TLS consentono un controllo granulare sulle comunicazioni HTTP/HTTPS. La progettazione corretta dei criteri bilancia i requisiti di sicurezza con le esigenze operative tramite gerarchie di regole strutturate e filtri basati su categorie.

Distribuire e configurare Firewall di Azure con criteri completi:

• Distribuire Firewall di Azure nella rete virtuale dell'hub: Distribuire Firewall di Azure (livello Standard o Premium in base alle funzionalità necessarie) nella rete virtuale dell'hub, assegnando sia indirizzi IP pubblici per il traffico associato a Internet che gli indirizzi IP privati per il routing interno da reti virtuali spoke.

• Creare criteri firewall con regole di filtro: Definire criteri di Firewall di Azure contenenti regole di rete (filtro basato su IP/porta), regole dell'applicazione (filtro basato su FQDN) e regole di intelligence sulle minacce, organizzare regole in raccolte in base ai requisiti di sicurezza (ad esempio, consentire servizi critici per l'azienda, bloccare indirizzi IP dannosi, negare le categorie rischiose).

• Configurare il filtro URL per il traffico HTTP/HTTPS: Implementare regole dell'applicazione basate su FQDN per consentire o negare domini specifici (ad esempio, consentire *.microsoft.com, negare *.torrent) e configurare il filtro basato su categorie per bloccare intere categorie di siti Web (ad esempio Hacking, Social Media) consentendo al contempo categorie correlate al lavoro.

• Abilitare l'ispezione TLS per il filtro avanzato: Per le distribuzioni di livello Premium, abilitare l'ispezione TLS caricando i certificati in Azure Key Vault, consentendo al firewall di decrittografare, controllare e crittografare nuovamente il traffico HTTPS per il filtro url più approfondito e il rilevamento delle minacce oltre l'ispezione basata su SNI.

Esempio di implementazione

Un'organizzazione con più carichi di lavoro delle applicazioni in esecuzione in reti virtuali spoke diverse richiedeva un'ispezione centralizzata della sicurezza di rete per tutto il traffico destinato a Internet e le comunicazioni tra gli spoke, impedendo al contempo l'accesso a domini dannosi e categorie di siti Web non conformi.

Sfida: L'organizzazione aveva carichi di lavoro distribuiti in reti virtuali spoke separate con accesso diretto a Internet, creando criteri di sicurezza incoerenti e impossibilità di controllare centralmente il traffico. Ogni spoke aveva le proprie regole NSG, causando la deriva dei criteri e le vulnerabilità di sicurezza. Non c'era visibilità su connessioni in uscita a domini potenzialmente dannosi, nessuna possibilità di bloccare categorie di siti Web rischiosi (social media, condivisione di file) e nessuna ispezione del contenuto del traffico HTTPS. Il traffico inter-spoke scorre liberamente senza ispezione, consentendo il potenziale movimento laterale dopo la compromissione.

Approccio alla soluzione:

• Topologia hub-and-spoke con firewall centralizzato: Distribuito Azure Firewall Premium in una rete virtuale hub (10.0.0.0/16) con AzureFirewallSubnet dedicata (10.0.1.0/26, IP privato del firewall 10.0.1.4), stabilendo un unico punto di controllo per tutte le operazioni di ispezione del traffico di rete e gestione delle politiche.
• Peering VNet per la connettività degli spoke: Il peering VNet è stato utilizzato per connettere la rete virtuale spoke dell'applicazione (10.1.0.0/16) e la rete virtuale spoke del database (10.2.0.0/16) alla rete virtuale hub, abilitando il routing centralizzato del traffico attraverso il firewall.
• Route definite dall'utente per lo sterzamento del traffico: Tabelle di route create in ciascuna rete virtuale spoke che reindirizza tutto il traffico destinato a Internet (0.0.0.0/0) e il traffico inter-spoke verso l'IP privato del Firewall di Azure (10.0.1.4), forzando tutto il traffico in uscita attraverso il punto di ispezione centrale.
• Criteri firewall con filtro a più livelli: Sono stati definiti criteri completi di Firewall di Azure , incluse le regole di rete (consentire il DNS UDP/53 al DNS di Azure, negare tutti gli altri protocolli per impostazione predefinita), le regole dell'applicazione (consentire FQDN critici aziendali come *.microsoft.com, negare i domini di condivisione file come *.torrent) e le regole di intelligence sulle minacce (bloccano indirizzi IP dannosi noti dai feed di minacce di Microsoft Defender).
• Filtro URL e blocco basato su categoria: Implementazione delle regole dell'applicazione basate su FQDN per un controllo di dominio preciso e un filtro basato su categorie per bloccare intere categorie di siti Web (Hacking, Social Media, Gioco d'azzardo) consentendo al tempo stesso categorie correlate al lavoro (Business/Economy, Technology/Internet), applicando criteri di utilizzo accettabili al perimetro della rete.
• Ispezione TLS per il traffico HTTPS: È stata abilitata l'ispezione TLS con certificati archiviati in Azure Key Vault, consentendo al firewall di decrittografare, controllare e crittografare nuovamente il traffico HTTPS per il filtro e il rilevamento delle minacce più approfonditi oltre all'ispezione basata su SNI, escludendo i domini bancari sensibili dalla decrittografia in base ai requisiti di conformità.

Risultato: L'organizzazione ha stabilito visibilità centralizzata e controllo su tutto il traffico diretto a Internet e inter-spoke, eliminando la deriva delle politiche e i punti ciechi per la sicurezza. L'ispezione TLS ha abilitato il rilevamento delle minacce nascoste nel traffico HTTPS crittografato, mentre il filtro basato su categorie riduce notevolmente l'esposizione al contenuto Web rischioso. L'architettura hub-spoke offre un comportamento di sicurezza scalabile e coerente in tutti i carichi di lavoro con la gestione unificata dei criteri e la protezione completa delle minacce.

Livello di criticità

Indispensabile.

Mapping controlli

• NIST SP 800-53 Rev.5: SC-7, SC-7(5), AC-4, SI-4(4)
• PCI-DSS v4: 1.2.1, 1.3.1, 1.4.1, 1.4.2
• Controlli CIS v8.1: 9.2 , 9.3, 13.1
• NIST CSF v2.0: PR.AC-05, PR.PT-04, DE.CM-01
• ISO 27001:2022: A.8.20, A.8.22
• SOC 2: CC6.1, CC6.6, CC7.2

Sicurezza di rete 4: Distribuire sistemi di rilevamento/prevenzione intrusioni (IDS/IPS)

Principio di sicurezza

Usare i sistemi di rilevamento e prevenzione delle intrusioni di rete (IDS/IPS) per controllare il traffico di rete e payload da e verso il carico di lavoro o le reti virtuali. Assicurarsi che IDS/IPS sia sempre ottimizzato per fornire avvisi di alta qualità alla soluzione SIEM.

Nota: per funzionalità di rilevamento e prevenzione a livello di host più approfondite, usare IDS/IPS basato su host o una soluzione di rilevamento e risposta degli endpoint (EDR) basata su host insieme all'IDS/IPS di rete.

Rischio da mitigare

Gli avversari sfruttano le vulnerabilità nei protocolli, nelle applicazioni e nel traffico interno per eseguire attività dannose.

• Exploit del protocollo: Le vulnerabilità nei protocolli come RDP (TCP 3389) o HTTP/HTTPS (TCP 80/443) consentono l'accesso non autorizzato o la compromissione del sistema tramite exploit come attacchi mirati ai CVE.
• Comunicazioni da comando e controllo (C2): I server dannosi stabiliscono il controllo sui dispositivi compromessi tramite query DNS o callback basati su IP, semplificando lo sfruttamento permanente o la propagazione di malware.
• Exploit delle applicazioni: Attacchi come SQL injection, scripting intersito (XSS) o overflow del buffer prendono di mira le vulnerabilità delle applicazioni per rubare i dati o eseguire codice arbitrario.
• Spostamento laterale: Traffico interno anomalo, ad esempio l'enumerazione SMB (TCP 445) o l'abuso di ticket Kerberos (TCP 88), segnala lo spostamento degli attaccanti all'interno della rete.
• Esfiltrazione dei dati: I trasferimenti di dati non autorizzati vengono eseguiti su canali crittografati (ad esempio, POST HTTPS) o in uscita con volumi elevati, usando l'offuscamento per eludere il rilevamento.

MITRE ATT&CK

• Accesso iniziale (TA0001): intrusioni non autorizzate tramite exploit destinati a vulnerabilità di rete (ad esempio T1190 - Exploit Public-Facing Application).
• Esecuzione (TA0002): esecuzione di codice dannoso da exploit di vulnerabilità o payload C2 (ad esempio T1059 - Interprete di comandi e scripting).
• Comando e controllo (TA0011): comunicazioni C2 malware usando query DNS o callback basati su IP (ad esempio, T1071 - Protocollo livello applicazione).
• Spostamento laterale (TA0008): traffico interno anomalo (come l'enumerazione SMB) indicativo di attività di riposizionamento (come T1021 - Servizi remoti).
• Esfiltrazione (TA0010): trasferimenti di dati non autorizzati su canali crittografati o offuscati (ad esempio, T1041 - Esfiltrazione su canale C2).

NS-4.1 Implementare Azure Firewall Premium per IDPS

I sistemi di rilevamento e prevenzione delle intrusioni forniscono l'identificazione delle minacce basata sulla firma di firma associando i modelli di traffico di rete contro le firme di attacco note, consentendo il blocco in tempo reale dei tentativi di exploit e delle comunicazioni dannose. La funzionalità IDPS di Firewall di Azure Premium offre librerie di firme aggiornate continuamente che coprono exploit, malware, comandi e controlli e categorie di phishing, supportando sia le modalità di avviso che di prevenzione. La selezione e l'ottimizzazione corrette delle firme garantiscono un rilevamento ad alta fedeltà riducendo al minimo i falsi positivi.

Distribuire e configurare IDPS tramite Firewall di Azure Premium:

• Distribuire Firewall di Azure Premium: Distribuire Firewall di Azure Premium con Criteri Premium nella rete virtuale dell'hub per abilitare le funzionalità IDPS insieme ad altre funzionalità avanzate, ad esempio l'ispezione TLS e il filtro URL.

• Selezionare le regole di firma IDPS: Scegliere le regole di firma IDPS dalla libreria delle firme in base alle priorità delle minacce, a partire da firme con gravità elevata in categorie critiche come "Malware", "Exploit" e "Phishing" allineati al profilo di minaccia e alla tolleranza ai rischi dell'organizzazione.

• Configurare la modalità IDPS: Impostare la modalità IDPS su Modalità avviso inizialmente per il test e l'ottimizzazione per osservare le corrispondenze di firma senza bloccare il traffico, quindi passare alla modalità Avviso e Nega per gli ambienti di produzione per evitare attivamente le minacce rilevate mantenendo gli avvisi per il monitoraggio della sicurezza.

• Ottimizzare le firme: Modificare le singole regole di firma in base all'esperienza operativa, disabilitando o riducendo la priorità delle firme che generano falsi positivi eccessivi, garantendo al tempo stesso che le firme con priorità elevata rimangano attive, ottimizzando il rapporto segnale-rumore per i team delle operazioni di sicurezza.

Esempio di implementazione

Un'organizzazione ha bisogno di proteggere l'infrastruttura critica da exploit noti e attacchi zero-day mantenendo al contempo visibilità sulle attività delle minacce senza interrompere le operazioni aziendali legittime.

Sfida: L'organizzazione ha gestito un'applicazione Web multilivello che elabora transazioni finanziarie senza rilevamento delle minacce basato sulla firma oltre alle regole del firewall di base. I team di sicurezza non avevano visibilità nei tentativi di exploit destinati ai server applicazioni, non erano in grado di rilevare le comunicazioni di comando e controllo e riscontravano avvisi falsi positivi provenienti da soluzioni IDS generiche che richiedono un'ampia ottimizzazione.

Soluzione:

• Firewall di Azure Premium con IDPS: Distribuzione di Firewall di Azure Premium nella rete virtuale hub che abilita le funzionalità IDPS insieme all'ispezione TLS e al filtro URL, stabilendo il rilevamento centralizzato delle minacce basato sulla firma per tutto il traffico della rete virtuale spoke.

• Selezione della regola di firma: Firme IDPS con gravità elevata selezionate da categorie critiche, tra cui Malware (Cobalt Strike, Metasploit, ransomware C2), Exploit (PaperCut CVE-2023-27350, Log4Shell, ProxyShell), Phishing (raccolta di credenziali) e Modelli di comando e controllo.

• Modalità di avviso e ottimizzazione: IDPS configurato in modalità avviso per il test iniziale per osservare le corrispondenze di firma senza bloccare il traffico, analizzando gli avvisi per identificare i falsi positivi dagli strumenti DevOps legittimi e dalle chiamate API partner, quindi sono state create eccezioni di firma per scenari validi noti mantenendo attive le firme CVE con priorità elevata.

• Transizione della modalità di prevenzione: L'IDPS è stato passato alla modalità avviso e nega per la produzione dopo la convalida, bloccando attivamente le minacce rilevate, inclusi i tentativi di sfruttamento di PaperCut, gli attacchi Log4Shell e le comunicazioni C2.

• Integrazione di Sentinel: Configurare i log di diagnostica in Log Analytics, creare regole di analisi di Sentinel che correlano i rilevamenti IDPS con gli eventi di autenticazione e stabilire la creazione automatica degli eventi imprevisti per gli avvisi con gravità elevata.

Risultato: I tentativi di sfruttamento sono stati bloccati correttamente impedendo l'esecuzione di codice remoto. Lo sfruttamento critico delle vulnerabilità è stato eliminato prima che si sia verificata una compromissione. I tassi di falsi positivi sono diminuiti notevolmente mantenendo una copertura CVE completa. I team di sicurezza hanno ottenuto una rapida revisione degli avvisi e una risposta agli eventi imprevisti, stabilendo una visibilità continua delle minacce con intelligenza pratica per la difesa proattiva.

Livello di criticità

Indispensabile.

Mapping controlli

• NIST SP 800-53 Rev.5: SI-4, SI-4(4), SI-4(5), SC-7(5)
• PCI-DSS v4: 11.4.1, 11.4.2, 1.4.1
• Controlli CIS v8.1: 13.2, 13.6, 13.7
• NIST CSF v2.0: DE. CM-01, DE. CM-04, DE. CM-07
• ISO 27001:2022: A.8.16, A.8.22, A.5.24
• SOC 2: CC6.1, CC7.2

NS-5: Distribuire la protezione DDoS

Criteri di Azure: Vedere Definizioni di criteri predefiniti di Azure: NS-5.

Principio di sicurezza

Distribuire la protezione DDoS tra vari livelli per attenuare efficacemente gli attacchi destinati a servizi e protocolli diversi a livello di rete e applicazione.

Rischio da mitigare

Gli attori delle minacce attaccano reti, server o applicazioni che usano traffico dannoso eccessivo per causare interruzioni del servizio.

• Attacchi volumetrici (inondazione della rete): Gli aggressori inondano le interfacce di rete con volumi di traffico elevati (ad esempio milioni di pacchetti al secondo) per esaurire la larghezza di banda, la capacità di elaborazione del router o le risorse del servizio di bilanciamento del carico, causando l'indisponibilità del servizio. Gli esempi includono inondazioni UDP, inondazioni ICMP o attacchi di reflection DNS amplificati sfruttando protocolli come NTP o SSDP.
• Attacchi al protocollo (esaurimento dello stato): Gli utenti malintenzionati sfruttano le vulnerabilità del protocollo di livello 3/4 per esaurire le risorse con stato, ad esempio tabelle di connessione TCP o stati di sessione del firewall. Le tecniche comuni includono gli attacchi SYN TCP, che sovraccaricano i server con connessioni semi-aperte, oppure gli attacchi ACK destinati a dispositivi stateful.
• Attacchi a livello di risorsa (overload dell'applicazione): Attacchi di livello 7 limitati, ad esempio inondazioni HTTP GET/POST, risorse dell'applicazione di destinazione (ad esempio CPU, memoria o connessioni di database) per sovraccaricare server Web o API. Questi attacchi mirano a esaurire le risorse di calcolo, causando picchi di latenza o interruzioni.
• Attacchi di amplificazione: Gli utenti malintenzionati sfruttano i server configurati in modo errato (ad esempio, DNS, NTP o Plex Media server in UDP 32414) per amplificare il traffico, inviando query di piccole dimensioni che generano risposte di grandi dimensioni dirette alla destinazione, sovraccaricare la capacità di rete. Gli esempi includono attacchi di amplificazione DNS o attacchi di riflessione SSDP.

MITRE ATT&CK

• Impatto (TA0040): interrompe la disponibilità del servizio attraverso inondazioni volumetriche (ad esempio UDP/ICMP) o sovraccarico delle risorse (ad esempio, inondazioni HTTP) per negare l'accesso (ad esempio, T1498 - negazione del servizio di rete).
• Sviluppo di risorse (TA0042): sfrutta i sistemi compromessi per attacchi di amplificazione (ad esempio, reflection DNS/NTP) per ampliare l'impatto degli attacchi (ad esempio, T1584 - Compromettere l'infrastruttura).

NS-5.1 Implementare la protezione DDOS nel livello di rete appropriato

Distribuire la protezione DDoS sia a livello di rete che di applicazione per difendersi da attacchimetrici e specifici dell'applicazione.Deploy DDoS protection at both network and application layer to defend againstmetric and application-specific attacks. Azure offre più livelli di protezione: Protezione di rete DDoS per una copertura completa della rete virtuale con supporto rapido per le risposte, protezione IP DDoS per la protezione conveniente dei singoli indirizzi IP e protezione a livello di applicazione tramite WAF. Configurare il monitoraggio e gli avvisi per convalidare l'efficacia della protezione e garantire la resilienza delle applicazioni durante gli attacchi:

• Distribuire la protezione DDoS del livello di rete: Scegliere tra Protezione di rete DDoS per le distribuzioni dei carichi di lavoro che richiedono copertura completa della rete virtuale e supporto rapido per l'analisi degli attacchi e l'analisi post-attacco o protezione IP DDoS per una protezione conveniente di un numero limitato di indirizzi IP senza supporto rapido per le risposte rapide.

• Distribuire la protezione DDoS a livello di applicazione: Abilitare la protezione DDoS in Azure Web Application Firewall (WAF), gateway applicazione o Frontdoor di Azure per difendersi dagli attacchi di livello applicazione (livello 7).

• Configurare il monitoraggio e gli avvisi: Configurare avvisi e monitorare metriche e log dal servizio protezione DDoS e dalle applicazioni per garantire l'efficacia della protezione, la resilienza delle applicazioni e le prestazioni desiderate durante e dopo gli attacchi.

Annotazioni

Anche senza usare il servizio di protezione DDoS precedente, Azure offre protezione dell'infrastruttura DDoS, una protezione a livello di piattaforma predefinita a livello di infrastruttura di rete. Questa protezione viene fornita gratuitamente e non richiede alcuna configurazione o attivazione.

Esempio di implementazione

Un'organizzazione di e-commerce aveva bisogno di una protezione completa contro i DDoS per le applicazioni rivolte ai clienti che subiscono un aumento dei tentativi di attacco volumetrici e a livello di applicazione durante le stagioni di picco degli acquisti.

Sfida: L'organizzazione ha gestito una piattaforma di e-commerce globale con applicazioni Web, API e infrastruttura di distribuzione di contenuti esposti a Internet. Durante gli eventi di picco, la piattaforma ha riscontrato più attacchi DDoS, tra cui inondazioni UDP, inondazioni TCP SYN che esauriscono le tabelle di connessione del servizio di bilanciamento del carico, inondazioni HTTP destinate alle API di estrazione e attacchi di amplificazione DNS. Senza una protezione DDoS dedicata, questi attacchi hanno causato interruzioni del servizio, causando la perdita di ricavi e l'insoddisfazione dei clienti.

Soluzione:

• Protezione di rete DDoS: Abilitata protezione di rete DDoS di Azure nelle reti virtuali di produzione che ospitano applicazioni rivolte ai clienti, offrendo una protezione completa a livello di rete virtuale con ottimizzazione adattiva, rilevamento automatico degli attacchi ai livelli 3 e 4 e mitigazione in tempo reale.

• Protezione del livello di applicazione:Azure Application Gateway con WAF distribuito per applicazioni regionali e Azure Front Door con WAF per la consegna globale ai margini, abilitando la protezione DDoS di livello 7 con limitazione della velocità, rilevamento di inondazioni HTTP e regole di protezione dei bot.

• Configurazione dei criteri di protezione: È stato creato un piano di protezione DDoS che associa tutte le reti virtuali di produzione, sono stati configurati modelli di base di apprendimento adattivo, il monitoraggio del traffico always-on e i criteri di protezione definiti per le inondazioni UDP, le inondazioni TCP SYN, le inondazioni ICMP e gli attacchi ai protocolli.

• Monitoraggio e avvisi: I log di diagnostica DDoS configurati inviano dati di telemetria degli attacchi all'area di lavoro Log Analytics, hanno creato avvisi di Monitoraggio di Azure che attivano notifiche immediate quando vengono rilevati attacchi, la cartella di lavoro di Sentinel correla gli attacchi DDoS con le metriche delle prestazioni dell'applicazione e ha configurato Application Insights monitorando l'integrità delle applicazioni durante la mitigazione.

• Intervento rapido di risposta: La risposta rapida DDoS attivata consente l'accesso diretto agli esperti di protezione DDoS durante gli attacchi attivi per l'analisi degli attacchi in tempo reale, lo sviluppo di strategie di mitigazione personalizzate e le analisi forensi post-attacco.

Risultato: Gli attacchi DDoS durante la stagione di punta dello shopping sono stati mitigati con zero interruzioni del servizio. Le inondazioni volumetriche, SYN e HTTP sono state bloccate automaticamente, mantenendo la disponibilità della piattaforma. Risposta rapida ha fornito analisi di esperti per attacchi sofisticati. I periodi critici di acquisto hanno mantenuto un'elevata disponibilità senza latenza nelle transazioni dei clienti, anche durante le misure di mitigazione.

Livello di criticità

Indispensabile.

Mapping controlli

• NIST SP 800-53 Rev.5: SC-5, SC-5(1), SC-5(2), SI-4(4)
• PCI-DSS v4: 6.4.2, 11.4.7
• Controlli CIS v8.1: 13.3
• NIST CSF v2.0: PR. PT-05, DE. CM-01
• ISO 27001:2022: A.8.13, A.8.24
• SOC 2: CC6.1, CC7.2

NS-6: Distribuire firewall per applicazioni web

Criteri di Azure: Vedere Definizioni di criteri predefiniti di Azure: NS-6.

Principio di sicurezza

Distribuire un web application firewall (WAF) e configurare regole per proteggere le applicazioni Web e le API da attacchi specifici dell'applicazione controllando, rilevare e filtrare il traffico HTTP/HTTPS dannoso.

Rischio da mitigare

Gli utenti malintenzionati sfruttano le vulnerabilità dell'applicazione Web per ottenere accesso non autorizzato, eseguire codice dannoso, rubare credenziali o esfiltrare i dati.

• Attacchi di injection (ad esempio, SQL injection, command injection): Gli hacker sfruttano le vulnerabilità di convalida dell'input per inserire codice dannoso in query o comandi dell'applicazione web, per consentire l'accesso non autorizzato al database, l'esfiltrazione dei dati o la compromissione del sistema. SQL injection (SQLi) modifica le query back-end (ad esempio, aggiungendo " OR '1'='1 a un modulo di accesso), mentre l'iniezione di comandi esegue comandi arbitrari del sistema operativo (ad esempio, ; rm -rf / tramite un campo modulo).
• Violazioni del protocollo HTTP e richieste in formato non valido: Gli utenti malintenzionati inviano richieste HTTP non valide (ad esempio, intestazioni non valide, payload sovradimensionati o metodi non standard come TRACE) per sfruttare le vulnerabilità nei server Web o nelle applicazioni, causando potenzialmente arresti anomali o accessi non autorizzati. Questi attacchi sono destinati a server non configurati correttamente o framework senza patch.
• Attacchi basati su bot (ad esempio, stuffing delle credenziali, scraping): i bot automatizzati avviano attacchi di stuffing delle credenziali (ad esempio, forzare gli endpoint di accesso con credenziali rubate) oppure estraggono contenuto sensibile (ad esempio, dati sui prezzi), sovraccarico i server o compromettere gli account utente. Questi attacchi sfruttano l'autenticazione debole o le API non protette.
• Exploit specifici dell'applicazione (ad esempio, inclusione di file remoti, inclusione di file locali): Gli utenti malintenzionati sfruttano le vulnerabilità per includere file dannosi (ad esempio, includere "http://evil.com/shell.php") o accedere ai file del server locale (ad esempio. /.. /etc/passwd) tramite parametri URL modificati o input di modulo, abilitando l'esecuzione del codice o l'esposizione dei dati.

MITRE ATT&CK

• Accesso iniziale (TA0001): Sfrutta l'iniezione SQL, XSS o l'inclusione di file remoti per ottenere l'accesso (ad esempio, T1190 - Sfruttamento di applicazioni esposte al pubblico).
• Esecuzione (TA0002): Esegue codice dannoso tramite l'inserimento di comandi, RFI o XSS (ad esempio T1059 - Interprete di script e comando).
• Accesso alle credenziali (TA0006): Ruba le credenziali tramite XSS o stuffing delle credenziali (ad esempio, T1539 - Ruba i cookie di sessione web, T1110 - Attacco di forza bruta).
• Raccolta (TA0009): Raccoglie i dati tramite sql injection o scraping (ad esempio, T1213 - Dati dai repository di informazioni).

NS-6.1 Configurare Azure WAF con le regole appropriate

Abilitare le funzionalità web application firewall (WAF) nel gateway applicazione di Azure, in Frontdoor di Azure o nella rete CDN (Content Delivery Network) di Azure per proteggere applicazioni e API da attacchi basati sul Web. Selezionare il servizio appropriato in base ai requisiti dell'applicazione, configurare i criteri WAF con regole predefinite e personalizzate, impostare la modalità dei criteri in base al comportamento di sicurezza e associare i criteri all'endpoint di servizio:

• Selezionare il servizio WAF appropriato: Scegliere Azure Application Gateway per le applicazioni ospitate nella rete virtuale, Azure Front Door per la distribuzione perimetrale globale, o la rete CDN di Azure per carichi di lavoro con contenuti pesanti, in base ai requisiti e all'architettura delle applicazioni.

• Configurare i criteri WAF con regole predefinite e personalizzate: Iniziare con i set di regole predefiniti comuni, ad esempio regole OWASP Core Rule Set (CRS 3.2) e protezione bot (Microsoft Bot Manager). Aggiungere regole personalizzate (ad esempio, limitazione della frequenza per >100 richieste/min) ed esclusioni per ridurre i falsi positivi in base al panorama delle minacce e al profilo di sicurezza delle applicazioni.

• Impostare la modalità dei criteri WAF: Usare la modalità di rilevamento inizialmente o per le applicazioni non critiche per evitare di interrompere il traffico legittimo durante l'installazione e l'ottimizzazione delle regole. Passare alla modalità di prevenzione per le applicazioni critiche dopo che le regole vengono convalidate per bloccare le richieste dannose.

• Associare i criteri WAF all'endpoint di servizio: Associare i criteri WAF all'Application Gateway, Front Door o endpoint CDN per assicurarsi che tutto il traffico HTTP/HTTPS venga instradato tramite WAF per l'ispezione.

Esempio di implementazione

Un'organizzazione doveva proteggere le applicazioni Web e le API rivolte ai clienti da attacchi SQL injection, XSS e stuffing delle credenziali basate su bot mantenendo al contempo le prestazioni per gli utenti legittimi.

Sfida: L'organizzazione aveva distribuito applicazioni Web a livello globale senza protezione dalle vulnerabilità OWASP Top 10, causando più tentativi di inserimento SQL, attacchi basati su bot che sovraccaricano gli endpoint di accesso e nessuna visibilità sui modelli di traffico dannosi. Le applicazioni non disponevano di controlli di limitazione della frequenza, consentendo attacchi di uso improprio delle API e di inserimento delle credenziali e non c'era alcun meccanismo per distinguere gli utenti legittimi da bot dannosi.

Approccio alla soluzione:

• Selezione del servizio WAF: Gateway applicazione di Azure distribuito con WAF per applicazioni ospitate nella rete virtuale e Frontdoor di Azure con WAF per applicazioni distribuite a livello globale che richiedono protezione perimetrale e accesso a bassa latenza.
• Set di regole di protezione predefiniti: Abilitazione del set di regole di base OWASP (CRS) 3.2 per la protezione da attacchi SQL injection, scripting tra siti (XSS), inclusione di file remoti e altre vulnerabilità Web comuni e attivazione di regole di Microsoft Bot Manager per identificare e bloccare bot dannosi, consentendo al contempo di eseguire ricerche per indicizzazione e servizi di monitoraggio legittimi del motore di ricerca.
• Regole personalizzate per minacce specifiche: Implementate regole di limitazione della frequenza che bloccano i client che superano 100 richieste al minuto per impedire l'uso improprio delle API e il contenuto delle credenziali, regole di filtro geografico che bloccano il traffico da aree a rischio elevato in cui i servizi non sono disponibili e le regole basate sulla reputazione IP che bloccano le richieste da intervalli IP dannosi noti identificati tramite feed di intelligence sulle minacce.
• Gestione delle esclusioni: Sono state create esclusioni mirate per scenari aziendali legittimi, ad esempio gli endpoint /checkout con input di modulo complessi che hanno attivato falsi positivi nelle regole OWASP, /upload endpoint che gestiscono invii di file di grandi dimensioni e /api con modelli di intestazione insoliti ma validi dalle applicazioni per dispositivi mobili.
• Transizione da rilevamento a prevenzione: Si è avviato WAF in modalità di rilevamento per due settimane per identificare falsi positivi, ottimizzando regole ed esclusioni in base a pattern di traffico legittimi, quindi è passato alla modalità di prevenzione per le applicazioni di produzione, per bloccare attivamente le minacce e contemporaneamente mantenere la continuità aziendale.

Risultato: L'organizzazione ha eliminato i tentativi di attacco SQL injection e XSS, riducendo notevolmente gli attacchi basati su bot tramite regole di gestione bot e ha stabilito una visibilità completa sulle minacce delle applicazioni Web. I controlli di limitazione della frequenza impedivano l'uso improprio delle API e il contenuto delle credenziali, mentre la transizione graduale dal rilevamento alla modalità di prevenzione assicurava che gli utenti legittimi non riscontrassero interruzioni del servizio.

Livello di criticità

Indispensabile.

Mapping controlli

• NIST SP 800-53 Rev.5: SC-7, SC-7(5), SI-10, SI-10(1), SI-11
• PCI-DSS v4: 6.4.1, 6.4.2, 11.4.7
• Controlli CIS v8.1: 13.2, 13.9
• NIST CSF v2.0: PR.AC-05, PR.PT-05, DE.CM-04
• ISO 27001:2022: A.8.20, A.8.22, A.8.25
• SOC 2: CC6.1, CC6.6, CC7.2

NS-7: Gestire la sicurezza di rete in modo centralizzato ed efficace

Principio di sicurezza

Per ridurre i rischi operativi e la configurazione errata in un ambiente di rete complesso e frammentato, usare le funzionalità di gestione della rete nativa del cloud per centralizzare, semplificare e applicare configurazioni coerenti di sicurezza di rete.

Rischio da mitigare

La mancanza di controllo centralizzato comporta impostazioni di sicurezza trascurate o obsolete, aumentando il rischio di sfruttamento.

• Applicazione dei criteri incoerente e configurazioni non coerenti: La gestione decentralizzata spesso comporta set di regole frammentati e lacune dei criteri, rendendo più semplice per gli utenti malintenzionati individuare e sfruttare i punti deboli. Le configurazioni errate sono più probabili, aumentando le probabilità di esposizione accidentale o di accesso imprevisto.
• Riduzione della visibilità e della risposta ritardata: Senza un approccio di gestione unificato, il monitoraggio e la risposta agli eventi imprevisti diventano più lenti e meno efficaci. Ciò può ritardare il rilevamento di attività dannose, consentendo agli utenti malintenzionati più tempo di inoltrare gli attacchi o esfiltrare i dati.
• Difficoltà a mantenere la conformità: Una gestione centrale inadeguata complica gli sforzi per soddisfare costantemente gli standard normativi e del settore, rischiando la mancata conformità e le potenziali sanzioni.

MITRE ATT&CK

• Accesso iniziale (TA0001): Sfruttamento di configurazioni errate o impostazioni di sicurezza obsolete per ottenere l'accesso non autorizzato (ad esempio, T1190 - Exploit Public-Facing Application, T1133 - External Remote Services).
• Evasione della difesa (TA0005): Sfruttando i set di regole frammentati e la mancanza di monitoraggio centralizzato per evitare il rilevamento (ad esempio, T1562 - Compromissione delle difese).
• Spostamento laterale (TA0008): Muoversi lateralmente attraverso la rete sfruttando le lacune nelle politiche o la segmentazione obsoleta (ad esempio, T1021 - Servizi Remoti).
• Comando e controllo (TA0011): Uso di percorsi di rete non monitorati o non configurati correttamente per stabilire e gestire i canali C2 ,ad esempio T1071 - Protocollo livello applicazione.

NS-7.1 Gestire la sicurezza di rete in modo centralizzato ed efficace

Usare gli strumenti centralizzati e le procedure standardizzate di Azure per semplificare e ridimensionare la gestione della sicurezza di rete, garantire un'imposizione coerente, ridurre la configurazione errata e migliorare il monitoraggio. Implementare l'imposizione centralizzata dei criteri, standardizzare la gestione del firewall e del routing, abilitare il monitoraggio e l'analisi complete e mantenere la coerenza delle risorse tramite le procedure di governance:

• Implementare l'applicazione centralizzata dei criteri: Usare Azure Virtual Network Manager (AVNM) per definire le regole di amministrazione della sicurezza che si applicano in modo coerente tra sottoscrizioni e aree. Mantenere i gruppi di sicurezza di rete per la micro-segmentazione a livello di workload. Applicare criteri tramite gruppi di rete (ad esempio, per ambiente: produzione, non-produzione).

• Standardizzare la gestione del firewall e del routing: Gestire le regole di Firewall di Azure tramite Gestione firewall con oggetti Criteri firewall. Standardizzare in gruppi IP e tag di servizio anziché indirizzi IP non elaborati. Usare Firewall di Azure Premium in cui sono necessari i filtri TLS, IDPS e URL. Preferisce hub sicuri della rete WAN virtuale o una topologia hub-spoke condivisa per applicare in modo coerente la finalità di routing.

• Abilitare il monitoraggio e l'analisi completi: Usare i log del flusso di rete virtuale v2 (per sostituire i log dei flussi NSG). Abilitare i log di diagnostica di Firewall di Azure e integrarsi con Analisi del traffico, Log Analytics e Microsoft Sentinel. Usare l'analisi dei criteri firewall e i conteggi dei riscontri delle regole per eliminare le regole inutilizzate o duplicate.

• Mantenere la coerenza e la governance delle risorse: Applicare le convenzioni di denominazione del Cloud Adoption Framework (CAF) e i tag di risorse obbligatori a tutte le reti virtuali, i gruppi di sicurezza di rete, le regole del firewall e i gruppi. Usare Indurimento adattivo della rete di Defender per il Cloud per perfezionare le regole eccessivamente permissive.

Esempio di implementazione

Caso d'uso: La piattaforma di pagamento in più aree consolida la sicurezza di rete su larga scala

Contesto: Un processore di pagamento di medie dimensioni che opera negli Stati Uniti orientali e nell'Europa occidentale con 4 sottoscrizioni (Prod, Non-Prod, Shared Services, SecOps) in un tenant necessita di PCI-DSS segmentazione, meno incidenti dalla deriva delle regole e monitoraggio centralizzato.

Applicazione centralizzata dei criteri con Gestione rete virtuale di Azure:

• Disegno: Creare AVNM a livello di gruppo di gestione. Definire due gruppi di rete: ng-prod e ng-nonprod con appartenenza dinamica in base al tag subscriptionId. Creare regole di sicurezza amministrativa (SAR) per applicare protezioni organizzative che vengono valutate prima dei gruppi di sicurezza di rete: Deny-Inbound-Internet-to-Spokes (blocca le connessioni in ingresso non richieste da Internet a tutte le subnet spoke), Consenti-Hub-Infra (consente i servizi hub, come Firewall/Bastion, nello spoke), Consenti-Platform-DNS (consente il DNS dai resolver dell'hub agli spoke).
• Limiti del team dell'app: I carichi di lavoro mantengono i gruppi di sicurezza di rete per la micro-segmentazione (ad esempio, da Web a api :443, api a db :1433) all'interno di ogni spoke. Le modifiche del NSG sono gestite dai team dell'app; le SAR sono gestite dal team di sicurezza della piattaforma.
• Risultato: I guardrail sono coerenti in entrambe le aree; i team di sviluppo delle app non possono creare accidentalmente accesso a Internet anche se un gruppo di sicurezza di rete non è configurato correttamente.

Gestione di firewall e routing con Firewall Manager e Virtual WAN:

• Disegno: Distribuire hub sicuri della rete WAN virtuale in ogni area (Stati Uniti orientali, Europa occidentale). Collegare i raggi all'hub più vicino e abilitare l'intento di routing in modo che tutta l'uscita Internet venga ispezionata. Usare Gestione firewall con criteri firewall globali (livello: Premium) e due criteri figlio (Prod/Non-Prod) per gli override dell'ambiente.
• Struttura dei criteri: I criteri di base (globali) includono Intelligence per le minacce impostata su Avviso e negazione, ispezione TLS abilitata per HTTPS in uscita, IDPS in modalità bilanciata e regole di autorizzazione in uscita tramite tag di servizio (archiviazione, KeyVault, AzureMonitor) e gruppi IP per gli endpoint partner. La politica figlio di Prod ha un filtro più rigoroso degli URL (blocco di URL non classificati) e l'elenco consentito per i gateway di pagamento tramite Gruppi di IP. Le politiche per i figli Non-Prod dispongono di un accesso esteso agli strumenti di sviluppo tramite Service Tags (AzureDevOps, AzureContainerRegistry).
• Risultato: Riquadro singolo per gestire le regole con modifiche propagate a entrambi gli hub. Il routing è coerente e tutti i dati in uscita vengono controllati con la decrittografia TLS, se consentito.

Monitoraggio e analisi con i log di flusso v2 e Sentinel:

• Configurazione dei dati di telemetria: Abilitare i log del flusso di rete virtuale v2 in tutte le reti virtuali e inviare a un'area di lavoro Log Analytics centrale nella sottoscrizione SecOps. Configurare i log di diagnostica di Firewall di Azure (applicazione, rete, DNS, ThreatIntel, IDPS) nella stessa area di lavoro. Attivare Analisi del traffico nell'area di lavoro.
• Ciclo di ottimizzazione: Abilitare l'analisi delle policy del firewall e rivedere i conteggi dei colpi delle regole ogni mese. Creare una cartella di lavoro di Sentinel che correla i log dei flussi (nord-sud e est-ovest), i riscontri consentiti/negati del firewall e le firme IDPS attivate. Automatizzare una richiesta di modifica se una regola ha 0 occurrenze per 45 giorni (candidato per la rimozione) o se una regola di rifiuto viene raggiunta da una subnet di produzione (possibile instradamento errato).
• Risultato: Dopo due cicli di revisione, vengono rimossi 18% delle regole del firewall e 22 regole del gruppo di sicurezza di rete non aggiornate, riducendo la latenza di valutazione delle regole e il rischio di modifica.

Coerenza e governance delle risorse con CAF e Defender for Cloud:

• Standard: Applicare la denominazione CAF (ad esempio, vnet-prd-eus-01, nsg-prd-eus-web-01, azfw-policy-global-01) e tag obbligatori: env, owner, dataClass, costCenter.
• Rinforzo: Usare le iniziative di Criteri di Azure per richiedere il gruppo di sicurezza di rete in ogni subnet, richiedere le impostazioni di diagnostica nelle reti virtuali e il firewall per l'area di lavoro la centrale e negare la creazione senza tag obbligatori. Abilitare Defender for Cloud - Protezione avanzata adattiva della rete in tutti gli spoke con elementi di azione settimanali esaminati in SecOps CAB.
• Risultato: La deriva della piattaforma viene rilevata rapidamente; Le regole eccessivamente permissive vengono rafforzate usando le raccomandazioni basate sui dati di Defender.

Sequenza di implementazione e criteri di accettazione:

• Configurare hub sicuri vWAN, collegare spoke, abilitare la finalità di routing (solo spoke pilota). Criteri di accettazione: uscita di dati dello spoke pilota attraverso il firewall; nessun IP pubblico raggiungibile direttamente.
• Distribuire le SAR di AVNM in ng-nonprod, verificare che non ci siano interruzioni, quindi in ng-prod. Criteri di accettazione: le sonde sintetiche confermano che i servizi hub (DNS/Bastion) raggiungono ancora gli spoke; Internet in entrata ancora negato.
• Abilitare i log dei flussi di rete virtuale v2 e tutta la diagnostica del firewall; caricare la cartella di lavoro di Sentinel. Criteri di accettazione: i dashboard mostrano flussi, negazioni, riscontri IDPS per regione.
• Applicare iniziative politiche; correggere gli elementi non conformi; abilitare la protezione avanzata adattiva. Criteri di accettazione: la conformità raggiunge 95%, backlog di elementi di sicurezza di rete/firewall creati.
• Prima revisione di Analisi dei criteri; rimuovere le regole inutilizzate tramite la finestra delle modifiche. Criteri di accettazione: numero di regole ridotto di 15% con impatto zero sul cliente.

Esempi di runbook operativi:

• Gestione della Rete Virtuale di Azure - SAR: Nega Internet in ingresso ai nodi periferici (Priorità 100), Permette l'infrastruttura dell'hub ai nodi periferici (Priorità 200: src 10.0.0.0/16 intervalli dell'hub)
• Struttura della politica del firewall: azfw-policy-global-01 (Premium) con raccolte di regole Allow-Azure-Platform-ST (Tag di Servizio) e Allow-Partners-IPs (Gruppi IP: ipg-payment-gws), oltre alle politiche figlio azfw-policy-prd-01 e azfw-policy-npd-01
• Diagnostica: Destinazione: law-secops-01, Categories: AZFWApplicationRule, AZFWNetworkRule, AZFWIDPS, AZFWThreatIntel, AZFWDnsProxy, FlowLogV2

Livello di criticità

Indispensabile.

Mapping controlli

• NIST SP 800-53 Rev.5: CM-2, CM-3, CM-6, CA-7, SI-4
• PCI-DSS v4: 1.4.5, 11.5.1, 12.4.1
• Controlli CIS v8.1: 4.1, 4.2, 12.4, 13.6
• NIST CSF v2.0: PR.IP-01, DE.CM-01, DE.CM-07
• ISO 27001:2022: A.8.9, A.8.32, A.5.37
• SOC 2: CC6.6, CC7.2, CC8.1

NS-8: rilevare e disabilitare i servizi e i protocolli non sicuri

Criteri di Azure: Vedere Definizioni di criteri predefiniti di Azure: NS-8.

Principio di sicurezza

Individuare e disabilitare i servizi e i protocolli non sicuri a livello di sistema operativo, applicazione o pacchetto software. Distribuire controlli di compensazione se non è possibile disabilitare i servizi e i protocolli non sicuri.

Rischio da mitigare

Gli attori delle minacce sfruttano servizi e protocolli non sicuri e vulnerabili per compromettere sistemi e dati.

• Sfruttamento della debolezza crittografica: SSL/TLSv1 e crittografie deboli (ad esempio, RC4, DES) sono vulnerabili agli attacchi MITM (ad esempio, POODLE, BEAST), consentendo agli avversari di decrittografare dati sensibili come i token di sessione tramite attacchi oracle di riempimento o di testo crittografato scelto.
• Accesso non autorizzato tramite exploit del protocollo: Le vulnerabilità di SSHv1 e SMBv1 (ad esempio CVE-2001-1473, CVE-2017-0144/EternalBlue) consentono l'esecuzione remota di codice o l'accesso non autenticato, abilitando i primi accessi.
• Furto di credenziali: LM/NTLMv1 e wDigest archiviano hash deboli o credenziali di testo non crittografato, vulnerabili al passaggio dell'hash o dello scraping della memoria (ad esempio, Mimikatz che estrae i dati LSASS).
• Spostamento laterale: Le sessioni e gli exploit non crittografati di SMBv1 (ad esempio, EternalBlue) consentono la propagazione di malware o l'inoltro delle credenziali tra reti.

MITRE ATT&CK

• Accesso iniziale (TA0001): Sfruttamento di protocolli non sicuri come SSL/TLSv1 o SSHv1, vulnerabili agli attacchi di downgrade del protocollo o exploit noti, bloccando l'ingresso non autorizzato (ad esempio, T1190 - Exploit Public-Facing Application).
• Accesso alle credenziali (TA0006): Furto di credenziali sfruttando LM/NTLMv1 e wDigest, che archiviano le credenziali in formati reversibili o hash deboli, contrastando il pass-the-hash o lo scraping della memoria (ad esempio, T1003 - Dump delle credenziali del sistema operativo).
• Spostamento laterale (TA0008): Impedisce agli utenti malintenzionati di eseguire ilpivot SMBv1, che è vulnerabile a exploit come EternalBlue, impedendo la propagazione tra reti (ad esempio, T1021 - Servizi remoti).

NS-8.1 Rilevare e disabilitare i protocolli e i servizi non sicuri

Usare la cartella di lavoro predefinita del protocollo non sicuro di Microsoft Sentinel per individuare e ridurre i servizi e i protocolli non sicuri nell'ambiente Azure. Questa cartella di lavoro identifica l'utilizzo di protocolli e servizi che non soddisfano gli standard di sicurezza appropriati, ad esempio SSL/TLSv1, SSHv1, SMBv1, LM/NTLMv1, wDigest, crittografie deboli in Kerberos e associazioni LDAP non firmate. Dopo l'identificazione, disabilitare questi protocolli e servizi non sicuri. Quando la disabilitazione non è fattibile, implementare controlli di compensazione per ridurre la superficie di attacco.

Individuare i protocolli non sicuri: Usare la cartella di lavoro del protocollo non sicuro di Microsoft Sentinel per identificare l'utilizzo delle associazioni SSL/TLSv1, SSHv1, SMBv1, LM/NTLMv1, wDigest, crittografie Kerberos deboli e binding LDAP non firmati nell'ambiente.

Disabilitare i servizi e i protocolli non sicuri: Disabilitare i servizi e i protocolli non sicuri identificati che non soddisfano gli standard di sicurezza appropriati per eliminare le vulnerabilità.

Implementare controlli di compensazione: Se la disabilitazione di servizi o protocolli non sicuri non è possibile a causa di requisiti aziendali o vincoli tecnici, usare controlli di compensazione come bloccare l'accesso alle risorse tramite gruppi di sicurezza di rete, Firewall di Azure o Web Application Firewall di Azure per ridurre la superficie di attacco.

Esempio di implementazione

Un'organizzazione sanitaria doveva eliminare i protocolli non sicuri nell'ambiente Di Azure per soddisfare i requisiti di conformità HIPAA e ridurre la superficie di attacco per le informazioni sanitarie protette.

Sfida: L'organizzazione ha gestito un'infrastruttura ibrida con applicazioni legacy che richiedono la connettività alle risorse ospitate in Azure. La valutazione della sicurezza ha rivelato un uso diffuso di protocolli non sicuri, tra cui SSL/TLSv1.0 nei server Web che servono i portali dei pazienti, SMBv1 abilitato nei file server per software di imaging medico legacy, autenticazione LM/NTLMv1 nei controller di dominio e nei server applicazioni, autenticazione wDigest che archivia le credenziali in formato reversibile, associazioni LDAP non firmate nei controller di Active Directory e crittografia Kerberos debole negli account del servizio. L'organizzazione non ha avuto visibilità sull'utilizzo del protocollo e ha affrontato potenziali violazioni della conformità HIPAA.

Soluzione:

• Distribuzione della cartella di lavoro del protocollo non sicura di Sentinel: Distribuzione di Microsoft Sentinel e cartella di lavoro del protocollo non sicuro dall'hub del contenuto, origini dati connesse, inclusi i log degli eventi di sicurezza di Windows, i log di Monitoraggio di Azure, i log di Active Directory e i log dei flussi di rete, stabilendo una baseline completa dell'utilizzo di protocolli non sicuri nell'ambiente ibrido.

• Individuazione del protocollo: Strumento per protocolli non sicuri per identificare l'utilizzo di SSL/TLSv1.0 sui server web, il traffico SMBv1 proveniente da workstation di imaging mediche legacy, modelli di autenticazione LM/NTLMv1, wDigest abilitato sui server Windows, collegamenti LDAP non firmati dalle applicazioni legacy e crittografia Kerberos RC4 debole negli account di servizio.

• Disabilitazione sistematica del protocollo: Piano di correzione in più fasi convalidato tramite il comitato consultivo dei cambiamenti, disabilitato TLSv1.0/1.1 nei server web dopo aver confermato che gli utenti del portale dei pazienti utilizzavano browser moderni che supportano TLS 1.2+, disabilitato SMBv1 dopo aver coordinato con gli aggiornamenti software del fornitore di immagini mediche, i controller di dominio sono stati aggiornati da NTLMv1 all'autenticazione NTLMv2, disabilitato wDigest tramite Criteri di gruppo, imposta la firma LDAP sui controller di dominio e la crittografia Kerberos dell'account del servizio aggiornata ad AES256.

• Controlli di compensazione per le eccezioni: Implementati controlli di compensazione basati sulla rete per il supporto temporaneo di protocolli non sicuri, tra cui VLAN isolata per stazioni di lavoro di imaging mediche legacy che richiedono SMBv1, regole del NSG che limitano il traffico SMBv1 esclusivamente a VLAN isolata, Firewall di Azure che nega l'SMBv1 in uscita dalle sottoreti di produzione, host jump dedicato per le applicazioni HR legacy e monitoraggio avanzato tramite Defender per la segnalazione dell'uso del protocollo al di fuori delle sottoreti eccezioni approvate.

• Monitoraggio continuo: È stato stabilito un protocollo igienico continuativo tramite le regole di analisi di Microsoft Sentinel che attivano avvisi per le nuove connessioni di protocollo non sicure al di fuori delle eccezioni approvate, i criteri di Azure che negano la distribuzione senza il requisito minimo di TLS 1.2, e la cartella di lavoro settimanale sui protocolli non sicuri traccia il progresso delle correzioni.

Risultato: Le connessioni TLS deboli sono state eliminate dai portali dei pazienti. SMBv1 è stato disabilitato dopo gli aggiornamenti dell'imaging medico, eliminando la vulnerabilità EternalBlue e ottenendo la conformità HIPAA. NTLMv1 ha eseguito la transizione a NTLMv2, impedendo attacchi pass-the-hash. La disabilitazione di wDigest ha mitigato il furto di credenziali. La firma LDAP ha bloccato le query non firmate. Kerberos aggiornato al protocollo AES256, riducendo il rischio di Kerberoasting. I controlli di compensazione contengono sistemi legacy con spostamento laterale zero. Conformità HIPAA completa ottenuta.

Livello di criticità

Indispensabile.

Mapping controlli

• NIST SP 800-53 Rev.5: SC-8, SC-8(1), SC-13, IA-5(1)
• PCI-DSS v4: 2.2.4, 4.2.1, 6.2.4
• Controlli CIS v8.1: 4.8, 9.3, 13.4
• NIST CSF v2.0: PR.DS-02, PR.IP-01, DE.CM-04
• ISO 27001:2022: A.8.24, A.8.26, A.5.14
• SOC 2: CC6.1, CC6.7, CC7.1

NS-9: Connettere la rete locale o cloud privatamente

Principio di sicurezza

Usare connessioni private per la comunicazione sicura tra reti diverse, ad esempio data center del provider di servizi cloud e infrastruttura locale in un ambiente di condivisione.

Rischio da mitigare

Quando i dati passano attraverso reti pubbliche, sono vulnerabili all'intercettazione, all'accesso non autorizzato e alla manomissione.

• Intercettazione dei dati: Quando i dati passano attraverso reti pubbliche come Internet, passano attraverso più router, commutatori e provider di servizi, qualsiasi dei quali potrebbe essere compromesso o monitorato da attori malintenzionati. Gli utenti malintenzionati possono distribuire strumenti di analisi dei pacchetti (ad esempio, Wireshark) per acquisire pacchetti di dati. Se i dati non sono crittografati o crittografati in modo debole, è possibile esporre informazioni riservate, ad esempio credenziali di accesso, dettagli finanziari o dati aziendali proprietari.
• Attacchi Man-in-the-Middle (MitM): In un attacco MitM, un utente malintenzionato intercetta segretamente e, eventualmente, modifica la comunicazione tra due parti che ritengono di comunicare direttamente tra loro. Ciò rappresenta una grave minaccia per operazioni sensibili, ad esempio transazioni finanziarie o processi di autenticazione.
• Accesso non autorizzato: Le reti pubbliche o protette in modo inadeguato aumentano la probabilità che gli utenti non autorizzati ottengano accesso o manomissione di sistemi o risorse private. Gli utenti malintenzionati possono sfruttare i punti deboli della rete per raggiungere un'infrastruttura interna che deve rimanere inaccessibile dall'esterno.

MITRE ATT&CK

• Accesso iniziale (TA0001): Sfruttamento di protocolli non crittografati o con crittografia debole (ad esempio, versioni HTTP o TLS obsolete) vulnerabili agli attacchi di analisi dei pacchetti o MitM, abilitando l'ingresso non autorizzato nei sistemi (ad esempio T1190 - Exploit Public-Facing Application).
• Accesso alle credenziali (TA0006): Furto di credenziali tramite traffico di rete intercettato, exploit di protocolli di testo non crittografato (ad esempio, Telnet o FTP) o crittografia debole vulnerabile alla decrittografia, facilitando l'accesso non autorizzato (ad esempio, T1040 - Sniffing di rete).
• Spostamento laterale (TA0008): Propagazione all'interno delle reti sfruttando servizi non configurati o esposti in modo errato (ad esempio, RDP o SMB senza patch), consentendo agli utenti malintenzionati di eseguire il pivot usando credenziali o vulnerabilità rubate (ad esempio, T1021 - Servizi remoti).

NS-9.1 Usare la rete privata virtuale di Azure (VPN) per la connettività da sito a sito o da punto a sito leggera

Usare la rete privata virtuale di Azure (VPN) per creare connessioni sicure e crittografate tra siti locali o dispositivi degli utenti finali e reti virtuali di Azure per scenari di connettività leggeri. Vpn di Azure offre una soluzione conveniente per la connettività da sito a sito (connessione di intere reti) o connettività da punto a sito (connessione di singoli dispositivi) senza richiedere un'infrastruttura dedicata:

• Distribuire una VPN da sito a sito: Usare la VPN da sito a sito per connettere in modo sicuro la rete locale alla rete virtuale di Azure, consentendo una comunicazione senza problemi tra le risorse locali e i carichi di lavoro di Azure.

• Distribuire una VPN da punto a sito: Usare la VPN da punto a sito per consentire ai singoli dispositivi utente finale (portatili, workstation) di connettersi in modo sicuro alla rete virtuale di Azure da posizioni remote.

NS-9.2 Usare Azure ExpressRoute (o rete WAN virtuale) per connessioni a prestazioni elevate di livello aziendale

Usare Azure ExpressRoute o la rete WAN virtuale di Azure per stabilire connessioni private, ad alte prestazioni e a bassa latenza tra i data center di Azure e l'infrastruttura locale in ambienti di condivisione. Queste soluzioni di livello aziendale ignorano la rete Internet pubblica, offrendo larghezza di banda dedicata, prestazioni prevedibili e sicurezza avanzata per carichi di lavoro cruciali che richiedono connettività coerente:

• Distribuire ExpressRoute per la connettività privata dedicata: Usare Azure ExpressRoute per creare una connessione privata tra l'infrastruttura locale e i data center di Azure tramite un provider di connettività, garantendo una larghezza di banda dedicata e una latenza prevedibile per i carichi di lavoro aziendali.

• Distribuire la rete WAN virtuale per la connettività globale: Usare la rete WAN virtuale di Azure per creare una rete globale che connette più siti, rami e aree di Azure tramite un'architettura hub-spoke unificata con funzionalità di sicurezza e routing integrate.

NS-9.3 Usare il peering a livello di reti virtuali o subnet per collegare le reti virtuali

Usare il peering di rete virtuale o il peering di subnet per stabilire la connettività privata tra reti virtuali di Azure senza instradare il traffico su Internet pubblico. Il traffico di rete tra reti virtuali con peering rimane nella rete backbone di Azure, fornendo connessioni a bassa latenza e larghezza di banda elevata senza sovraccarico di crittografia. Scegli il peering tra subnet quando la connettività completa nella rete virtuale non è necessaria, limitando l'esposizione alle sole subnet specifiche.

• Distribuire il peering di rete virtuale: Usare il peering di rete virtuale per connettere intere reti virtuali di Azure, consentendo alle risorse in reti virtuali diverse di comunicare privatamente come se fossero nella stessa rete.

Esempio di implementazione

Un'organizzazione multinazionale dei servizi finanziari ha bisogno di connettività sicura e ad alte prestazioni tra data center locali, succursali e risorse cloud di Azure, eliminando al contempo l'esposizione a Internet pubblica per transazioni finanziarie sensibili.

Sfida: L'organizzazione ha gestito più data center locali con succursali a livello globale, richiedendo la connettività alle applicazioni ospitate in Azure che elaborano transazioni finanziarie e dati dei clienti. L'architettura iniziale usa la VPN da sito a sito su Internet, riscontrando una latenza imprevedibile, limitazioni della larghezza di banda durante le ore di trading di punta, problemi di sicurezza relativi ai dati finanziari che attraversano Internet pubblico nonostante la crittografia e requisiti di conformità che obbligano la connettività privata per PCI-DSS e GDPR. I dipendenti remoti che si connettono tramite VPN da punto a sito hanno riscontrato problemi di prestazioni e autenticazione incoerenti. Le applicazioni in aree di Azure diverse richiedono la comunicazione tra aree a bassa latenza senza routing tramite hub locali.

Soluzione:

• ExpressRoute per la connettività del data center primario: I circuiti Azure ExpressRoute distribuiti nei data center primari tramite strutture di co-locazione con provider di connettività ExpressRoute, stabiliscono la connettività privata Layer 3 alla rete backbone di Azure con latenza costante e ridotta, configurato ExpressRoute con peering Microsoft per i servizi PaaS di Azure e peering privato per le risorse ospitate dalla rete virtuale, implementato il routing BGP con configurazione attiva-attiva per l'elevata disponibilità e il failover automatico.

• VPN da sito a sito per la connettività della succursale: VPN da sito a sito distribuita per le succursali senza accesso alla struttura di condivisione della posizione, con creazione di un gateway VPN nella rete virtuale hub con configurazione attiva-attiva per un'elevata disponibilità, tunnel IPsec/IKE configurati con crittografia robusta che soddisfa gli standard di sicurezza del settore finanziario, implementazione del routing BGP per la selezione dinamica del percorso che consente alle succursali di connettersi all'hub regionale più vicino, stabiliti tunnel ridondanti per garantire la connettività durante le finestre di manutenzione.

• VPN da punto a sito per i dipendenti remoti: Vpn da punto a sito configurata con l'autenticazione di Azure Active Directory per i dipendenti remoti che richiedono l'accesso sicuro alle applicazioni ospitate in Azure, autenticazione basata su certificati abilitata come fallback per scenari senza accesso a Internet ad Azure AD, indirizzi IP client assegnati dal pool dedicato instradati alle risorse della rete virtuale di Azure tramite route definite dall'utente, implementato il protocollo OpenVPN per i client macOS/Linux e IKEv2/SSTP per i client Windows che offrono un'ampia compatibilità dei dispositivi, configurato split tunneling che consente l'accesso a Internet diretto per il traffico non aziendale durante il routing del traffico associato ad Azure tramite tunnel VPN che ottimizza la larghezza di banda.

• Rete WAN virtuale per la connettività mesh globale: Implementata la rete WAN virtuale di Azure con hub sicuri in più regioni che forniscono un'architettura di transito globale, connessione dei circuiti ExpressRoute agli hub della rete WAN virtuale che consente la connettività any-to-any tra data center e regioni di Azure senza instradare tramite hub locali, connessioni VPN integrate da sito a sito dalle filiali all'hub della rete WAN virtuale più vicina con ottimizzazione del routing automatico, abilitato Firewall di Azure in ogni hub della rete WAN virtuale che fornisce un'ispezione centralizzata della sicurezza per il traffico tra filiali, data center e reti virtuali di Azure, criteri di routing configurati che implementano il routing di transito globale che consente alle filiali di comunicare con i data center locali tramite backbone di Azure.

• Peering delle VNets per la connettività interregionale di Azure: Implementato il peering di reti virtuali collegando le VNets spoke agli hub di Virtual WAN di ciascuna area, abilitato il peering globale delle VNets per la connettività tra applicazioni interregionali che fornisce bassa latenza sul backbone di Azure, configurato il transito del gateway che consente alle VNets spoke di utilizzare i gateway VPN/ExpressRoute dell'hub di Virtual WAN senza implementare gateway aggiuntivi, riducendo costi e complessità, implementati gruppi di sicurezza di rete sulle subnet spoke per controllare il flusso di traffico tra VNets collegate in peering con accesso a privilegi minimi.

• Ottimizzazione e monitoraggio del traffico: Configurati circuiti ExpressRoute con contrassegni QoS che assegnano priorità al traffico delle transazioni finanziarie sui trasferimenti di dati in blocco , abilitazione del rilevamento della latenza, perdita di pacchetti e disponibilità per circuiti ExpressRoute e connessioni VPN con avvisi per la riduzione delle prestazioni, implementazione delle cartelle di lavoro di Monitoraggio di Azure che visualizzano la topologia di connettività globale che mostra connessioni attive, utilizzo della larghezza di banda ed eventi di failover, linee di base stabilite per prestazioni accettabili con avvisi automatici per le violazioni delle soglie.

Risultato: La connettività privata è stata ottenuta per tutte le transazioni finanziarie, soddisfando PCI-DSS requisiti. ExpressRoute ha fornito una bassa latenza coerente per il trading in tempo reale. La latenza da ramo a data center della rete WAN virtuale è notevolmente ridotta. I dipendenti remoti sono connessi correttamente tramite VPN da punto a sito con un'autenticazione migliorata. Il peering globale delle reti virtuali ha abilitato un ripristino d'emergenza efficiente tra regioni. Ottimizzazione dei costi ottenuta tramite il consolidamento della rete WAN virtuale.

Livello di criticità

Indispensabile.

Mapping controlli

• NIST SP 800-53 Rev.5: SC-7, SC-7(4), SC-8
• PCI-DSS v4: 1.2.1, 2.2.7, 4.2.1
• Controlli CIS v8.1: 12.8, 13.8
• NIST CSF v2.0: PR.AC-05, PR.DS-02
• ISO 27001:2022: A.8.21, A.8.22, A.5.14
• SOC 2: CC6.6, CC6.7

NS-10: Garantire la sicurezza del DNS (Domain Name System)

Principio di sicurezza

Assicurarsi che la configurazione di sicurezza DNS (Domain Name System) protegge da rischi noti:

• Usare servizi DNS autorevoli e ricorsivi attendibili nell'ambiente cloud per garantire che il client (ad esempio sistemi operativi e applicazioni) riceva il risultato di risoluzione corretto.
• Separare la risoluzione DNS pubblica e privata in modo che il processo di risoluzione DNS per la rete privata possa essere isolato dalla rete pubblica.
• Assicurarsi che la strategia di sicurezza DNS comprenda anche misure di mitigazione contro gli attacchi comuni, come il dangling DNS, gli attacchi di amplificazione DNS, l'avvelenamento e lo spoofing DNS, e così via.

Rischio da mitigare

Gli attori delle minacce attaccano i servizi DNS o sfruttano i servizi DNS vulnerabili per compromettere le applicazioni e reindirizzare il traffico.

• Spoofing/avvelenamento DNS: Gli avversari forgiano risposte DNS o corrompono la cache del resolver (ad esempio, attacco Kaminsky) per reindirizzare i client a server dannosi, per consentire il phishing o l'intercettazione di dati.
• Attacchi di amplificazione DNS: Gli utenti malintenzionati sfruttano i server DNS configurati in modo errato per amplificare il traffico DDoS (ad esempio, una query a 60 byte che produce una risposta di 4.000 byte), sovraccaricando le reti di destinazione.
• Sfruttamento del DNS sospeso: I record sospesi (ad esempio, CNAME obsoleti) consentono agli attaccanti di dirottare le risorse rimosse, reindirizzando il traffico verso endpoint dannosi per phishing o malware.
• Esfiltrazione di dati tramite tunneling DNS: Gli attori malintenzionati codificano i dati nelle query DNS (ad esempio, data.exfil.evil.com) per esfiltrare in modo nascoste le informazioni riservate, ignorando i firewall.
• Phishing/recapito malware: I resolver compromessi reindirizzano domini legittimi a indirizzi IP controllati da utenti malintenzionati, fornendo pagine di phishing o malware ai client insospettabili.

MITRE ATT&CK

• Comando e controllo (TA0011): Usare il tunneling DNS per codificare i comandi C2 nelle query (ad esempio, data.exfil.evil.com) o le risoluzioni di spoofing per connettersi a server dannosi (ad esempio, T1071.004 - Protocollo livello applicazione: DNS).
• Raccolta (TA0009): Raccogliere dati tramite spoofing DNS per reindirizzare gli utenti a siti di phishing o esfiltrare dati tramite tunneling (ad esempio T1040 - Sniffing di rete).
• Impatto (TA0040): Attacchi di amplificazione DNS, invio di query di piccole dimensioni per generare risposte di grandi dimensioni, interrompendo la disponibilità del servizio (ad esempio, T1498.002 - Network Denial of Service: Reflection Amplification).
• Accesso iniziale (TA0001): Exploit di record DNS pendenti o risoluzioni falsificate per distribuire malware/phishing, per ottenere accesso ai sistemi (ad esempio, T1190 - sfruttare applicazioni esposte al pubblico).

NS-10.1 Usare il servizio DNS attendibile

Usare i servizi DNS attendibili per garantire che i client ricevano risultati di risoluzione corretti e proteggono dagli attacchi basati su DNS. Azure fornisce il servizio DNS ricorsivo a 168.63.129.16 (in genere assegnato tramite DHCP o preconfigurato) per la risoluzione DNS del carico di lavoro a livello di sistema operativo o applicazione. In alternativa, usare server DNS esterni attendibili. Per le organizzazioni che ospitano i propri domini, DNS di Azure offre un hosting DNS autorevole affidabile. Le organizzazioni che creano server DNS personalizzati devono seguire le linee guida per la distribuzione sicura NIST SP 800-81 Rev. 3:

• Usare DNS ricorsivo di Azure o DNS esterno attendibile: Configurare i carichi di lavoro per l'uso di DNS ricorsivo di Azure (168.63.129.16) o server DNS esterni attendibili nei sistemi operativi delle macchine virtuali o nelle impostazioni DNS dell'applicazione per garantire una risoluzione affidabile dei nomi.

• Consenti DNS di Azure nelle regole del firewall: Aggiungere l'indirizzo 168.63.129.16 all'elenco degli indirizzi consentiti del firewall e ai gruppi di sicurezza della rete per garantire una corretta funzionalità DNS delle risorse di Azure.

• Ospita domini su Azure DNS: Usa Azure DNS per gestire la risoluzione dei domini per le esigenze DNS autoritative, offrendo un hosting DNS scalabile e affidabile (nota: Azure DNS non fornisce il servizio di registrazione del dominio).

• Seguire le linee guida per la distribuzione DNS sicura: Se si compilano server DNS personalizzati, seguire NIST SP 800-81 Rev. 3 Secure Domain Name System (DNS) Deployment Guide (Guida alla distribuzione di NIST SP 800-81 Rev. 3 Secure Domain Name System) per implementare le procedure consigliate per la sicurezza.

NS-10.2 Usare DNS privato nella rete virtuale

Usare DNS privato di Azure per stabilire zone DNS private in cui la risoluzione DNS rimane all'interno della rete virtuale, impedendo alle query DNS di attraversare le reti pubbliche. Questo è essenziale per le configurazioni degli endpoint privati, in cui le zone DNS private eseguono l'override della risoluzione DNS pubblica per instradare il traffico privatamente ai servizi di Azure. Le soluzioni DNS personalizzate possono limitare ulteriormente la risoluzione solo a origini attendibili, migliorando la sicurezza per i carichi di lavoro privati:

• Distribuire DNS privato di Azure per la risoluzione privata: Usare DNS privato di Azure per creare zone DNS private che mantengono la risoluzione DNS all'interno della rete virtuale, assicurandosi che le query non lascino mai il limite di rete.

• Configurare il DNS privato per gli endpoint privati: Configurare le zone DNS private per gli endpoint privati per eseguire l'override della risoluzione DNS pubblica e assicurarsi che i client risolvono gli FQDN dell'endpoint privato in indirizzi IP privati all'interno della rete virtuale.

• Implementare il DNS personalizzato per la risoluzione con restrizioni: Utilizzare server DNS personalizzati per limitare la risoluzione DNS, consentendo la risoluzione solo tramite fonti affidabili per i client, fornendo un controllo aggiuntivo sulla sicurezza della risoluzione dei nomi.

NS-10.3 Usare Defender per DNS per la protezione avanzata

Usare Microsoft Defender per DNS per rilevare e avvisare le minacce avanzate per la sicurezza basata su DNS, tra cui l'esfiltrazione dei dati tramite tunneling DNS, la comunicazione da comando e controllo, le interazioni di dominio dannose (phishing, crypto mining) e gli attacchi DNS che coinvolgono resolver dannosi. Defender per la protezione DNS è ora incluso nel piano defender per server. Inoltre, usa Microsoft Defender per App Service per rilevare i record DNS orfani che potrebbero consentire attacchi di acquisizione del sottodominio durante la disattivazione dei siti web.

• Abilitare Defender per la protezione DNS: Usare Microsoft Defender per DNS (incluso nel piano defender per server) per monitorare e avvisare l'attività DNS sospetta, tra cui l'esfiltrazione di dati tramite tunneling DNS, la comunicazione di comando e controllo malware e le interazioni con domini dannosi.

• Monitorare l'attività DNS dannosa: Configurare gli avvisi per rilevare la comunicazione con resolver DNS dannosi e attacchi DNS che potrebbero compromettere la sicurezza del carico di lavoro o la disponibilità del servizio DNS.

• Rilevare record DNS in sospeso: Usare Microsoft Defender per App Service per identificare i record DNS in sospeso durante la dismissione dei siti Web del servizio App, impedendo attacchi di acquisizione del sottodominio garantendo che i domini personalizzati vengano rimossi dai registrar DNS.

Esempio di implementazione

Sfida: Un'azienda ha bisogno di una sicurezza DNS completa che riguarda i servizi di risoluzione attendibili, il DNS della rete privata per le risorse interne e il rilevamento avanzato delle minacce nell'infrastruttura cloud ibrida.

Approccio alla soluzione:

• Distribuito DNS ricorsivo di Azure (168.63.129.16) per tutti i carichi di lavoro delle macchine virtuali di Azure, con regole del gruppo di sicurezza di rete che permettono il traffico DNS.
• Zone autorevoli ospitate in DNS di Azure per la risoluzione del dominio pubblico con distribuzione geografica
• Implementazione delle zone DNS private di Azure per la risoluzione degli endpoint privati (privatelink.database.windows.net, privatelink.blob.core.windows.net) collegata alle reti virtuali di produzione
• Integrazione DNS privata configurata per garantire la risoluzione degli FQDN dell'endpoint privato in indirizzi IP privati (ad esempio, sqlserver.database.windows.net → 10.0.2.4)
• Abilitato Microsoft Defender per DNS tramite il piano Defender per server per monitorare il tunneling DNS, la comunicazione C2 e le interazioni con domini dannosi.
• Distribuito Defender per App Service per rilevare i record DNS sospesi durante il decommissionamento del sito Web

Risultato: L'implementazione della sicurezza DNS garantisce una risoluzione dei nomi affidabile per i carichi di lavoro cloud mantenendo al tempo stesso la privacy per le risorse interne. Le zone DNS private hanno impedito alle query sensibili di attraversare le reti pubbliche, mentre Defender per DNS ha fornito visibilità sulle minacce basate su DNS, inclusi i tentativi di esfiltrazione dei dati e l'attività di comando e controllo. La soluzione ha eliminato i rischi di takeover del sottodominio attraverso il rilevamento automatico del DNS pendente durante le modifiche al ciclo di vita delle risorse.

Livello di criticità

Indispensabile.

Mapping controlli

• NIST SP 800-53 Rev.5: SC-7, SI-4, SI-4(4), SI-4(5)
• PCI-DSS v4: 11.5.1, 12.10.1
• Controlli CIS v8.1: 8.5, 13.6, 13.8
• NIST CSF v2.0: DE. CM-01, DE. CM-04, DE. AE-02
• ISO 27001:2022: A.8.16, A.8.22, A.5.24
• SOC 2: CC6.1, CC7.2, CC7.3