Wirtualne firewalle

Zasady działania tego typu zapór sieciowych są analogiczne, jak ich fizycznych odpowiedników. Z tą różnicę, że te są dostarczane w formie maszyn wirtualnych. Z punktu widzenia automatyzacji to istotna zaleta. Można przyjąć, że każda aplikacja otrzymuje własny firewall, a skoro zapora sieciowa jest maszyną wirtualną, to można ją wdrożyć automatycznie.

Jeśli chodzi o instalowanie aplikacji w zautomatyzowanym, wirtualnym środowisku, wirtualne firewall ułatwią ten proces. Należy poinformować właściciela aplikacji, że jest odpowiedzialny również za jej bezpieczeństwo oraz przekazać informację, skąd można pobrać maszynę wirtualną z firewallem (przyda się również instrukcja użytkownika). Jeśli jeden wirtualny firewall okażę się nie wystarczający, aby wydajnie obsłużyć aplikację, jej właściciel może wdrożyć kolejne przypisane do niej zapory sieciowe. Jeśli w przyszłości aplikacja zostanie usunięta, również obsługujące ją zapory sieciowe i reguły zostaną skasowane.

Zobacz również:

• Palo Alto wzywa pilnie użytkowników jej zapór sieciowych, aby jak najszybciej zaktualizowali zarządzające nimi oprogramowanie
• W tych krajach TikTok jest zakazany częściowo lub całkowicie

Obawy pojawią się, jeśli infrastruktura informatyczna firmy podlega audytom. W wirtualnym środowisku mogą działać setki aplikacji i adekwatna do nich liczba wirtualnych firewalli. Pozostaje mieć nadzieję, że właściciele aplikacji prawidłowo zainstalowali zapory sieciowe. W takim otoczeniu bowiem wyszukanie firewalli, które wymagają modyfikacji, może zająć sporo czasu.

Poza tym wirtualna zapora sieciowa, podobnie jak fizyczna, jest wąskim gardłem, przechwytującym pakiety. Z tą różnicą, że tym razem wąskie gardło znajduje się w innym miejscu. Nadal trzeba do niego przekazywać ruch sieciowy, a każdy z takich obiektów wymaga oddzielnego zarządzania przez administratorów. Poza tym reguły filtrowania można tworzyć, wykorzystując tylko podstawowe parametry protokołów TCP/IP. Z tych względów firewalle wirtualne dobrze sprawdzają się przy filtrowaniu ruchu północ-południe (między serwerami i urządzeniami klienckimi). Są łatwe do wdrażania, a każdy liczący się producent zapór sieciowych przygotował również wirtualne modele swoich produktów. Natomiast wirtualne zapory nie są najlepszym rozwiązaniem w przypadku komunikacji typu wschód-zachód z uwagi na ograniczoną przepustowość. Z tym zadaniem najlepiej upora się rozproszony firewall.

Rozproszona zapora sieciowa (distributed firewall)

Firewalle fizyczne i wirtualne działają w tym samym, starym modelu, a różnią się między sobą głównie formą. Natomiast w przypadku rozproszonej zapory sieciowej firewall mamy do czynienia z programową usługą wbudowaną w stos sieciowy hypervisora. Wszystkie hypervisory włączone do rozproszonej struktury stają się jednym firewallem. Jest to ta sama koncepcja, według której działają wirtualne przełączniki. Jeśli zwrócimy uwagę na fakt, że każda maszyna wirtualna jest podłączona do hypervisora, to okaże się, że jest to realizacja naszej utopijnej wizji - serwery komunikują się bezpośrednio z firewallem.

Każdy pakiet wysłany z maszyny wirtualnej może zostać sprawdzony przez usługę zapory sieciowej działającą w rdzeniu hypervisora, zanim jeszcze taki pakiet w ogóle dotrze do interfejsu sieciowego. Dopiero po pozytywnym zweryfikowaniu przez reguły filtrowania zostanie przekazany do interfejsu sieciowego i dalej do tradycyjnej sieci pracującej w dowolnej architekturze. Nie ma potrzeby sterowania ruchem do firewalla. Nie ma też konieczności szukania kompromisowych rozwiązań w projektowaniu sieci. Poza tym każdy pakiet dostarczony do maszyny wirtualnej może zostać sprawdzony w lokalizacji docelowej przez tę samą usługę rozproszonego firewalla, zanim zostanie przekazany do wirtualnego interfejsu sieciowego. Możliwe jest również filtrowanie ruchu nawet pomiędzy serwerami znajdującymi się w tym samym segmencie sieci.

Reguły stosowane w rozproszonym firewallu definiuje się centralnie, tworząc pewne logiczne konstrukcje zwane kontenerami. Następnie do tych kontenerów programowo przypisuje się aplikacje, a za wymuszanie przynależnych do nich reguł odpowiada rdzeń hypervisora. Reguły bezpieczeństwa nie są tworzone z wykorzystaniem takich parametrów, jak adres IP, lecz na bazie właściwości kontenera (przypisanych do niego aplikacji). Przykładowo, administrator może określić, że obiekty przypisane do kontenera „Internet” mogą komunikować się z kontenerem „Aplikacje”, używając portu TCP o numerze x. To oznacza, że adres IP maszyny wirtualnej może się zmienić i nie wymusi to zmiany w regułach filtrowania. Obiekty mogą być przypisane do kontenerów statycznie lub dynamicznie, gdy wystąpi określone zdarzenie, np. na podstawie danych użytkownika, wykrycia wirusa czy różnych parametrów systemu operacyjnego. Trzeba podkreślić, że reguły filtrowania działają w oderwaniu od adresów IP.

Rozproszony firewall ma bezpośrednie połączenie z maszynami wirtualnymi i pracującymi w nich aplikacjami. Co więcej, cały czas podąża za maszyną wirtualną. Wystarczy tylko przypisać aplikację do danego kontenera. Każdy odebrany lub wysłany pakiet jest przepuszczany przez zaporę sieciową, a reguły filtrowania podążają za maszyną wirtualną, nawet jeśli ta zostanie przeniesiona na inny serwer fizyczny.