Progetta la protezione DDoS per Oracle Cloud Infrastructure
Sebbene ci siano molte opzioni di progettazione da cui selezionare, i fattori comuni per la maggior parte dei disegni sono che devono essere:
- In linea con gli standard di sicurezza aziendali
- end-to-end protetto
- Seguire un modello di difesa approfondita
- Facilità di gestione
- Scalabilità
L'obiettivo principale del servizio di protezione OCI DDoS è fornire una soluzione sicura e scalabile che soddisfi i requisiti DDoS di un'organizzazione e, al contempo, supporti più livelli di ambiente, tra cui produzione, staging, sviluppo, controllo qualità e disaster recovery. I servizi di protezione DDoS OCI aiutano un'azienda a sostenere un'architettura altamente disponibile e scalabile con un modello di sicurezza approfondito per la difesa, sfruttando i componenti cloud nativi OCI, come i Web Application Firewall (WAF), Load balancer di rete (NLB), load balancer flessibili (FLB), firewall di nuova generazione (NGFW) di terze parti con abilitato per DDoS e certificati TLS/SSL, insieme ai vantaggi e alle considerazioni associate per ogni progettazione.
Valuta e scegli un'opzione di progettazione dell'architettura per la prevenzione DDoS su OCI
Esistono diverse opzioni di progettazione dell'architettura che è possibile scegliere, a seconda di come si desidera scalare la prevenzione DDoS.
Opzione di progettazione 1: firewall applicazione Web e load balancer di rete singola
In questa progettazione, i certificati TLS vengono utilizzati in WAF, NGFW, i FLB privati e i server backend per i flussi HTTP/S. Il flusso HTTP/S passerà sempre dall'asse WAF di OCI e gradualmente lavorerà attraverso un NLB, seguito da NGFW e infine dal FLB privato. Questo approccio richiede più criteri WAF per ogni livello di ambiente (ad esempio, produzione, QA e DR) e l'inoltro del traffico HTTP/S a un singolo NLB, un singolo FLB e i relativi set backend.
Nota:
Per tutti i flussi non HTTP/S, il flusso verrà sempre incluso tramite NLB, ignorando il WAF OCI, dai NGFW e, infine, dal NLB privato. Ciò consente di implementare il firewall DDoS su un livello basato su zona o su un livello globale per concentrarsi sugli attacchi di livello 3 e di livello 4.Il diagramma seguente descrive questa architettura.
rete singola-lb-ngfw-architecture.zip
Quando il traffico viene inserito attraverso il perimetro OCI, i criteri perimetrali WAF OCI eseguono l'interruzione TLS/SSL. Il pacchetto viene quindi decifrato in modo che possa essere ispezionato per qualsiasi payload WAF di livello 7 dannoso prima di inviare il traffico all'origine su una porta specifica. Per impostazione predefinita, è 443/TCP, che può essere configurato per l'inoltro su porte specifiche.
L'origine del framework WAF OCI è configurata in modo da inoltrare il traffico a un singolo NLB, che quindi inoltra il traffico verso le istanze di computazione NGFW di terze parti per una determinata porta TCP. Nel diagramma riportato sopra, ad esempio, i flussi di traffico verde e blu provenienti dal perimetro WAF OCI vengono inviati all'origine (indirizzo IP del listener NLB) su porte specifiche, rispettivamente 4443/TCP e 4444/TCP. A sua volta, NLB è configurato per inoltrare il traffico ai set backend (NGFW) sulle stesse porte TCP.
NLB opera nei livelli 3 e 4 ed è inserito in una subnet pubblica. NLB verrà in genere configurato per conservare l'indirizzo IP di origine del client. L'ingresso del traffico tramite il framework WAF OCI verrà associato a un proxy, mediante i CIDR WAF OCI documentati dedicati al servizio WAF OCI. Poiché il traffico proviene da una lista di CIDR WAF OCI documentati, è possibile aggiungere un ulteriore livello di sicurezza sfruttando le liste di sicurezza e/o i gruppi NSG per limitare la connettività a una lista di CIDR WAF OCI validi e affidabili. Ciò implica anche che i log del flusso della subnet NLB e i log del traffico NGFW di terze parti vedranno solo gli indirizzi IP degli intervalli CIDR WAF OCI come IP di origine.
Poiché questo progetto utilizza firewall attivi/attivi utilizzando un NLB, il firewall di terze parti deve eseguire il NAT di origine prima di inoltrare il traffico al FLB privato per mantenere un percorso simmetrico per il traffico di ritorno. Il NGFW dovrà anche eseguire la destinazione-NAT poiché la destinazione è un FLB privato.
Supponendo che NGFW supporti la decifrazione e l'ispezione, possiamo decifrare il traffico per eseguire IDS/IPS su payload non cifrati sul NGFW, prima di inoltrare il traffico a un determinato FLB.
Considerando i requisiti forniti e l'opzione di progettazione descritta in precedenza, è possibile concludere le procedure ottimali riportate di seguito per questa distribuzione.
- Separare i criteri WAF per ogni livello di ambiente (produzione, sviluppo e controllo qualità).
- Usare un singolo load balancer di rete (NLB).
- Riutilizzare gli stessi NGFW backend per più livelli di ambiente.
- Progettare un'architettura approfondita della difesa.
- Proteggere l'ambiente end-to-end.
- Mitiga e controlla gli attacchi da soluzioni on premise in Oracle Cloud.
- Ottieni protezione ai livelli 3 e 4 DDoS con il controllo organizzativo.
- Configurare DDoS nel livello firewall con il controllo utente per complimentarsi con le offerte di Oracle.
Opzione di progettazione 2: Web Application Firewall e più load balancer di rete
In questo progetto, la tecnologia, i componenti e il flusso di dati rimangono gli stessi del nostro design precedente. Dopo che il traffico viene incluso tramite il perimetro OCI, viene elaborato e ispezionato dai criteri perimetrali WAF OCI per qualsiasi payload WAF di livello 7 dannoso prima di essere inviato a NLB, NGFW e, infine, a un ALB privato. Analogamente, tutti i flussi non HTTPS/S saranno sempre in entrata tramite NLB, ignorando la soluzione WAF e NGFW OCI e, infine, la soluzione NLB privata. Ciò consente di implementare il firewall DDoS su un livello basato su zona o su un livello globale per concentrarsi sugli attacchi di livello 3 e di livello 4.
La differenza principale nella progettazione dell'opzione 2 consiste nell'utilizzare più NLB in base a un livello di ambiente (produzione, sviluppo e controllo qualità) per separare il traffico di ambiente. Nell'opzione 2, ogni NLB utilizza un indirizzo IP secondario univoco sul NGFW come set backend per inoltrare il traffico. In ultima analisi, il traffico passa al FLB designato per l'applicazione o il servizio specificato. Questo design introduce anche la capacità di superare la limitazione di 50 ascoltatori utilizzando un singolo NLB. Questa struttura consentirà inoltre il riutilizzo delle porte del listener NLB per standardizzare i flussi di traffico per ogni livello di ambiente (produzione, sviluppo e garanzia della qualità).
Il diagramma seguente descrive questa architettura.
