Worker LiveShield jest wymagany osobno w każdej lokalizacji, w której odbierany jest ruch od upstreamu, ponieważ analizuje lokalną kopię ruchu pobraną przez mirror portu (SPAN) lub optyczny TAP. Analyser i manager - moduły odpowiedzialne za decyzje o mitygacji i konfigurację - mogą być natomiast scentralizowane.

To pytanie pojawia się w każdej sieci, która ma więcej niż jedną lokalizację brzegową z niezależnymi sesjami do operatorów tranzytowych - i architektura LiveShield ma na nie jednoznaczną odpowiedź, wynikającą wprost z tego, jak działa detekcja ataków.

Worker LiveShield analizuje ruch, który fizycznie do niego dociera - a więc kopię ruchu z lokalnego mirrora portu lub linku TAP podłączonego do routera brzegowego lub przełącznika w danej lokalizacji. Jeśli sieć ma dwie niezależne lokalizacje z osobnymi sesjami BGP do upstreamów, każda z nich potrzebuje własnego workera podłączonego do lokalnego źródła ruchu - workera nie da się "wysłać" do zdalnej lokalizacji przez sieć, bo musiałby wtedy odbierać surowy ruch przez łącze WAN, co jest nieefektywne i w praktyce niewykonalne przy większych przepływnościach.

Worker po analizie przesyła do analysera już tylko zagregowane dane statystyczne - nie surowy ruch - przez zwykłe połączenie TCP po interfejsie zarządzającym serwera. Ten kanał wymaga rzędu pojedynczych megabitów na sekundę, więc może być prowadzony nawet między lokalizacjami bez obciążania łączy produkcyjnych.

Jeśli w każdej lokalizacji postawiony zostanie osobny, w pełni niezależny zestaw worker-analyser-manager, każda z tych instancji liczy progi detekcji wyłącznie na podstawie ruchu, który widzi lokalnie. To otwiera lukę w detekcji: atakujący może rozdzielić wolumen ataku między dwie lokalizacje tak, żeby żadna z nich osobno nie przekroczyła ustawionego progu, mimo że łączny ruch na oba punkty wejścia do sieci jest już atakiem.

Przykład: jeśli próg detekcji UDP jest ustawiony na 5 Gb/s w obu lokalizacjach osobno, atakujący wysyłający po 3 Gb/s przez każdą z nich (łącznie 6 Gb/s) nie zostanie wykryty w żadnej z nich, mimo że rzeczywisty atak przekracza założony próg.

Wysyłanie zagregowanych danych z wszystkich workerów do jednego, wspólnego analysera rozwiązuje ten problem - analyser widzi pełny obraz ruchu ze wszystkich lokalizacji jednocześnie i podejmuje decyzje na podstawie rzeczywistej sumy ruchu, a nie jego lokalnego wycinka. Dodatkową korzyścią jest to, że operator prowadzi jedną konfigurację progów zamiast utrzymywać kilka równoległych, które trzeba synchronizować ręcznie przy każdej zmianie.

LiveShield działa w architekturze poza ścieżką ruchu produkcyjnego (off-path) - worker analizuje kopię ruchu pobraną z mirrora, a nie ruch przechodzący fizycznie przez urządzenie. W efekcie awaria workera nie przerywa ruchu produkcyjnego w danej lokalizacji - traci się jedynie zdolność wykrywania nowych ataków i reagowania na nie, dopóki worker nie zostanie przywrócony.

To zasadnicza różnica względem rozwiązań pracujących inline, gdzie awaria urządzenia filtrującego może bezpośrednio przełożyć się na przerwę w ruchu klientów.

Redundancja LiveShield w sieci wielolokalizacyjnej opiera się na dwóch zasadach: worker musi działać osobno w każdej lokalizacji, ponieważ potrzebuje lokalnego źródła ruchu, natomiast analyser i manager powinny być scentralizowane, żeby detekcja opierała się na pełnym obrazie ruchu z wszystkich lokalizacji naraz. Dzięki architekturze off-path awaria workera nie przerywa ruchu produkcyjnego - ogranicza jedynie zdolność wykrywania nowych ataków do czasu jego przywrócenia.

Czy jeden worker LiveShield wystarczy dla sieci z dwiema lokalizacjami? Nie, jeśli obie lokalizacje mają niezależne sesje BGP do upstreamów i odbierają ruch osobno - każda z nich wymaga własnego workera podłączonego do lokalnego mirrora ruchu.

Czy analyser i manager trzeba instalować osobno w każdej lokalizacji? Nie jest to zalecane. Jeden, wspólny analyser dla wszystkich lokalizacji daje pełny obraz ruchu i poprawia dokładność detekcji w porównaniu do osobnych, niezależnych konfiguracji.

Czy awaria workera przerywa ruch klientów? Nie. LiveShield pracuje w architekturze off-path, analizując kopię ruchu z mirrora portu lub linku TAP - awaria workera ogranicza zdolność wykrywania nowych ataków, ale nie wpływa na ruch produkcyjny przechodzący przez sieć.