Nie wszystkie zapory sieciowe nowej generacji są takie same

Godzenie rozbieżności między rzeczywistymi potrzebami klientów a standardową ofertą zapór sieciowych jest trudne. W jaki zatem sposób zbudować własne, bezpieczne rozwiązanie typu Application Delivery Network?

W ostatnim czasie można było zauważyć, że ucichły typowe niegdyś rozmowy o zaporach sieciowych nowej generacji. Odkąd funkcje, takie jak kontrola aplikacji i rozpoznawanie użytkowników, stały się powszechne, firmy oferujące zapory sieciowe próbują wyróżnić się oferując mechanizmy ochrony przed zaawansowanymi zagrożeniami. Zagrożenia te stanowią faktycznie naglący problem, jednak istnieje cała gama innych, nowych wyzwań na szczeblach operacyjnych i ekonomicznych, z którymi firmy z branży IT muszą zmagać się w świecie, w którym aplikacje coraz częściej trafiają do użytku w formie usług.

Czym tak właściwie jest zapora sieciowa? Z jednej strony to rozwiązanie do realizacji strategi zabezpieczeń, ale z drugiej – zapora działa jak router do komunikacji sieciowej, a to oznacza, że istotnym aspektem w działaniu takich urządzeń jest dostarczanie dostępu do aplikacji. W kwestii tej firewall przypomina nieco ludzki mózg, w którym znajdują się dwie, równie ważne półkule mózgu. Każda z nich posiada odmienne zdolności i wykonuje inne zadania, ale skutecznie możemy funkcjonować tylko wówczas, gdy nasze półkule ściśle ze sobą współpracują.

Niestety, jedyną rzeczą, jaką można teraz usłyszeć na temat odnowy koncepcji zapory sieciowej są rozmowy dotyczące głębokiej inspekcji pakietów oraz wymuszania reguł bezpieczeństwa. Co jednak z nieszkodliwym ruchem sieciowym, na którym opierają się firmy? Ruch sieciowy dotyczący aplikacji musi przebiegać bezpiecznie i zapewniać przewidywalną jakość usług – zarówno w sieci firmowej, jak i coraz częściej, między chmurą a siecią firmową. Koncentrowanie się wyłącznie na zabezpieczeniach i zaniedbywanie kwestii dostarczania aplikacji na poziomie firewalla przypomina nieco mózg, którego jedna półkula jest w pełni używana, podczas gdy druga pozostaje uśpiona. I choć takie mózgi powszechnie uważa się dysfunkcyjne, to – stosując z powrotem analogię do technologii bezpieczeństwa – brak tego rodzaju synchronizacji wydaje się nie przeszkadzać wielu osobom w przypadku zapór sieciowych.

Kiedyś dwiema głównymi składowymi infrastruktur korporacyjnych były sieci LAN, w których znajdowali się użytkownicy oraz sieci WAN, tzn. łącza sieciowe łączące ze sobą oddziały satelickie z głównymi lokalizacjami korporacji. Centralizacja biurowej infrastruktury oraz wdrażanie aplikacji, które nie zostały zaprojektowane do środowiska sieci WAN, z jej wysoką latencją, doprowadziły szybko do problemów z wydajnością i zmniejszenia produktywności. Odpowiedzią na to było nadejście produktów do optymalizacji sieci WAN, z pomocą których organizacje rozwiązują opisane problemy. Rozwiązania te zapewniają zarówno standardową optymalizację, przez techniki usuwania powtarzających się danych oraz kompresji, jak również specjalne ulepszenia protokołów dla niektórych popularnych aplikacji. Produkty te nie były jednak zwykle w stanie zapewnić odpowiednich funkcji sieci VPN czy głębokiej inspekcji. Ponadto klienci często wzbraniali się przed wzrostem komplikacji, wynikającym z jednoczesnego użycia zapory sieciowej i środków optymalizacji sieci WAN, co wiązało się z bardziej skomplikowanymi wzorami przepływu danych. Skłaniało ich to do stosowania struktur WAN opartych na protokole MPLS, gdzie cały ruch sieciowy, w tym surfowanie po Internecie, obciąża centrum danych.

W tamtych czasach nie polegano na dostępności ofert SaaS (oprogramowania jako usługi) ani usług sieciowych istniejących poza obrębem firmowych sieci LAN. Współcześnie, przy ogromnej dostępności takich aplikacji, które w coraz większym stopniu dotyczą zastosowań o charakterze masowym (przykładem może być Microsoft Offfce365), podejście obciążające centrum danych nie sprawdza się, ponieważ szkielet protokołu MPLS nie jest w stanie rozróżnić poszczególnych aplikacji, które korzystają tej samej fizycznej linii. Może więc zdarzyć się tak, że wewnętrzna aplikacja do tworzenia kopii zapasowej lub agent aktualizacji całkowicie zajmie taką linię i trudno będzie korzystać z aplikacji online mających krytyczne znaczenie dla działalności biznesowej. Najdalej posuniętym rozwiązaniem tego problemu jest oddzielenie od siebie różnego rodzaju ruchu sieciowego pochodzącego od aplikacji, albo fizycznie albo logicznie, poprzez podział przewodu na segmenty o różnej jakości. Jeśli wróci się do analogii półkul mózgowych, oznaczałoby to, że półkula zajmująca się inspekcją musi rozpoznać rodzaj przepływających danych, a druga półkula musi wtedy zachować się sprytnie i sprawić, że ważniejsze przepływy będą dostarczane inaczej niż te o niższym priorytecie.

Biorąc pod uwagę mnogość dostępnych rozwiązań SaaS, najlepszą opcją jest dokonanie w różnych lokalizacjach bezpośrednich połączeń internetowych. Każde z nich musi być oczywiście chronione przez odpowiednią zaporę sieciową nowej generacji. Nie brzmi to zachęcająco, biorąc pod uwagę, że wymusza synchronizację różnych strategii stosowanych w wielu zaporach sieciowych. Problem ten nie występuje jednak, jeśli zapora sieciowa dostarczana jest wraz z potężną architekturą zarządzania centralnego, w której utrzymywana może być jedna lub maksymalnie kilka strategii, które zostaną następnie wdrożone w wąskich przejściach i będą tam realizowane w sposób zdecentralizowany. Innymi słowy, zastosowany zostanie klasyczny paradygmat „podejmij decyzję raz i zastosuj ją wszędzie”.

Używanie takich zapór i tworzenie redundancji sieciowych zapewnia organizacji to, czego naprawdę potrzebuje. Posiadają one bezpieczny szkielet komunikacyjny, zapewniający głęboką inspekcję pakietów oraz minimalizowanie zagrożeń, jak również elastyczne i wydajne dostarczanie aplikacji biznesowych do użytkowników korporacyjnych.

Klaus Gheri

Wiceprezes działu Network Security

Barracuda Networks