Dużo zapór w jednej sieci
-
- 04.03.2015
Zarządzanie licznymi zaporami sieciowymi w wielooddziałowej organizacji to wyzwanie. Przedstawiamy najważniejsze problemy, z którymi musi się zmierzyć dział informatyki.
Zapora sieciowa jest jednym z podstawowych narzędzi obrony firmowego środowiska IT i musi być właściwie skonfigurowana, by jej działanie odniosło oczekiwany skutek. Organizacje radzą sobie z tym w różny sposób, niekiedy za pomocą narzędzi tak prostych jak zestaw skryptów i arkusze lub repozytoria. Jednak w miarę wzrostu skomplikowania środowiska staje się to coraz bardziej pracochłonne.
Robert Dąbrowski, starszy inżynier systemowy Fortinet Polska, mówi: „Jeśli firma nie ma systemu, który może utrzymywać pakiety zależnie od założeń polityki na konkretnych urządzeniach, to musi prowadzić dokumentację i wielokrotnie powielać podobne czynności. Administrator musi się zalogować na wiele urządzeń, wprowadzić podobne zmiany, które skrupulatnie odnotowuje w dokumentacji. Zajęcie to jest pracochłonne, wdrażanie nowych założeń postępuje powoli i prawdopodobieństwo popełnienia błędów jest dość wysokie”.
Zobacz również:
Podstawowy problem dotyczy nie tylko błędów i pracy administratorów, ale także czasu reakcji. Gdy mamy do czynienia z nowym zagrożeniem, które firma powinna zablokować na zaporach sieciowych, istotny staje się czas reakcji. Logowanie i ręczne wprowadzanie zmian na wielu urządzeniach kolejno jest nieefektywne w większej skali – takie czynności muszą być zautomatyzowane, jeśli organizacja poważnie myśli o sprawnej odpowiedzi na nowe zagrożenia.
Dużo urządzeń – duży problem
Przy zarządzaniu zasobami, w szczególności zaporami sieciowymi, dział IT powinien utrzymywać dziennik zmian, zawierający zapisaną konfigurację przed i po zmianie, opisy każdej ze zmian oraz listę urządzeń, do których zmiany zostały zastosowane.
Gdy liczba urządzeń przekracza kilkadziesiąt, ręczne zarządzanie wykracza poza możliwości pojedynczego administratora, który musiałby ręcznie zastosować każdą z zmian. Administratorzy radzą sobie za pomocą skryptów lub innych nieoficjalnych narzędzi, ale nadal muszą sporo czynności wykonywać ręcznie. Pojawiają się także problemy z audytem oraz poprawkami, gdy narzędzie z jakiegoś powodu tych zmian nie wprowadzi – administratorzy muszą to uczynić ręcznie i odnotować w dokumentacji. Skuteczne wprowadzanie zmian musi się zatem wiązać z wdrożeniem repozytorium konfiguracji dla każdego urządzenia, a tego nie da się zrobić w prostym arkuszu Excela.
Niezależnie od sposobu zarządzania urządzeniami takie repozytorium warto prowadzić. Dzięki niemu można szybko wrócić do sprawdzonej konfiguracji w razie awarii, da się także odnotować stan po każdej z zaplanowanych i wdrożonych zmian (istotne przy analizie powłamaniowej).
Administratorzy, którzy muszą wprowadzać zmiany na wielu urządzeniach i nie mają do tego celu specjalizowanych narzędzi, często budują samodzielnie skrypty, które usprawniają pracę. Metoda ta ma jednak kilka wad. Robert Dąbrowski wyjaśnia: „Zbudowane samodzielnie skrypty upraszczają życie administratorom, ale problemem w skali firmy może być rotacja personelu i brak dokumentacji. Nieoficjalne narzędzia często są źle udokumentowane i gdy ich autor zmieni pracę, często skrypt staje się bezużyteczny – bo tylko ta osoba potrafiła go obsługiwać lub wprowadzać w nim niezbędne zmiany”.
Problem braku dokumentacji dotyczy nie tylko skryptów. Gdy w sieci danej organizacji mamy do czynienia z wieloma urządzeniami, pojawia się problem nieudokumentowanych detali. Administratorzy, którzy w polskich warunkach często są przeciążeni pracą, nie dokumentują więcej, niż jest to wymagane przez procedury i przełożonych. Przy sporej rotacji personelu i dużej liczbie zmian w wielu zarządzanych ręcznie urządzeniach powstają braki w dokumentacji. W miarę upływu czasu takie braki staną się przyczyną problemów, zwłaszcza gdy organizacja ma do czynienia z wieloma zaporami. W niektórych organizacjach liczba takich urządzeń może sięgać nawet tysięcy (Polska nie jest wyjątkiem – w Urzędzie Marszałkowskim Województwa Warmińsko-Mazurskiego zarządza się siecią rzędu 1000 firewalli), co stawia pod znakiem zapytania możliwość ręcznego zarządzania rozległym środowiskiem wielu zapór.
Jak utworzyć reguły
Dla kilku lub kilkunastu urządzeń reguły można utworzyć bardzo prosto – wystarczy spisać usługi, które są udostępniane między oddziałami, zaplanować ruch i przygotować proste zasady. Powstałe w ten sposób grupy reguł uzupełnia się o adresację i wdraża na każdym z tych urządzeń, a następnie testuje gotową konfigurację. Sposób ten nie nadaje się jednak do projektowania reguł dla środowiska wielu oddziałów, gdyż proste planowanie z zapisaniem reguł (oraz adresów IP) jest zbyt pracochłonne i podatne na błędy. O metodzie projektowania reguł w złożonych środowiskach mówi Robert Dąbrowski: „Najpierw należy podzielić oddziały na reprezentatywne grupy, które później będą odzwierciedlone przez pakiety założeń. Grupuje się oddziały pod kątem chronionych zasobów i grup użytkowników. Zazwyczaj występują tu dwa najważniejsze kierunki komunikacji: do centrali oraz do internetu. Oba zazwyczaj zawierają pewne obostrzenia, które również należy podzielić na reprezentatywne grupy. W następnym kroku przygotowuje się pakiety polityk, które przypisywane będą do konkretnych urządzeń. Późniejsze zmiany, związane np. z nową usługą, można przeprowadzić w pakiecie polityk. Centralne wdrożenie zapewnia, że zaplanowane operacje zostaną wykonane na wszystkich urządzeniach – a są przedsiębiorstwa, które mają dosłownie tysiąc małych firewalli. Nawet przy prostej polityce filtrowania ruchu to nietrywialne zadanie”.
Zazwyczaj w skomplikowanej sieci mamy do czynienia z wieloma urządzeniami, różni się także adresacja każdej z podsieci. Aby przygotować wspólny pakiet założeń ruchu, niezbędna jest dynamizacja obiektów. Robert Dąbrowski wyjaśnia: „Dynamizacja obiektów polega na tym, że obiekt w skrypcie taki jak LOCAL LAN ADDRESS będzie tłumaczony na rzeczywiste podsieci IP dla każdego z oddziałów z osobna. Jeśli zdefiniujemy wirtualny interfejs LAN, to w jednej lokalizacji będzie odpowiadał fizycznemu portowi 1, w innej może to być wirtualna podsieć VLAN wykreowana na innym interfejsie – zależnie od potrzeb. Obiekt taki będzie ostatecznie przetłumaczony na lokalne porty i adresy. Tylko w ten sposób można prosto zbudować założenia reguł na zaporach dla całej skomplikowanej sieci”.
