Ten artykuł jest trzecim w serii artykułów "Jak przejąć kontrolę nad infrastrukturą sieciową". Spis treści wszystkich artykułów oraz linki można znaleźć tutaj.

Nie ma sensu mówić o całkowitym wyeliminowaniu ryzyk związanych z bezpieczeństwem. W zasadzie nie możemy ich zredukować do zera. Należy również rozumieć, że dążąc do uczynienia sieci coraz bardziej bezpieczną, nasze rozwiązania stają się coraz droższe. Konieczne jest znalezienie rozsądnego kompromisu między ceną, złożonością i bezpieczeństwem dla Twojej sieci.

Oczywiście, projekt bezpieczeństwa jest organicznie wbudowany w ogólną architekturę, a stosowane rozwiązania dotyczące bezpieczeństwa wpływają na skalowalność, niezawodność, zarządzalność … infrastruktury sieciowej, co także powinno być uwzględnione.

Ale przypominam, że teraz nie mówimy o tworzeniu sieci. Zgodnie z naszymi początkowymi założeniami mamy już wybrany projekt, wybrane urządzenia i stworzoną infrastrukturę, i na tym etapie musimy, jeśli to możliwe, "żyć" i znajdować rozwiązania w kontekście wcześniej wybranego podejścia.

Naszym zadaniem teraz jest zidentyfikowanie ryzyk związanych z bezpieczeństwem na poziomie sieci i ich ograniczenie do rozsądnego poziomu.

Audyt bezpieczeństwa sieci

Jeśli w Twojej organizacji wdrożono procesy ISO 27k, audyt bezpieczeństwa i zmiany w sieci powinny być organicznie wplecione w ogólne procesy w ramach tego podejścia. Jednak te standardy nie dotyczą konkretnych rozwiązań, konfiguracji, ani projektu… Brak jednoznacznych wskazówek, brak standardów szczegółowo określających, jaka powinna być Twoja sieć, to złożoność i piękno tego zadania.

Wyróżniłbym kilka możliwych audytów bezpieczeństwa sieci:

audyt konfiguracji sprzętu (hardening)
audyt projektu bezpieczeństwa
audyt dostępu
audyt procesów

Audyt konfiguracji sprzętu (hardening)

Wygląda na to, że w większości przypadków to najlepszy punkt wyjścia do audytu i poprawy bezpieczeństwa Twojej sieci. IMHO, to dobra demonstracja zasady Pareto (20% wysiłków przynosi 80% rezultatów, a pozostałe 80% wysiłków to tylko 20% wyników).

Sedno sprawy jest takie, że zazwyczaj mamy zalecenia od dostawców dotyczące "najlepszych praktyk" w zakresie bezpieczeństwa przy konfiguracji sprzętu. Nazywa się to "hardening".

Często można również spotkać lub stworzyć samodzielnie ankietę na podstawie tych zaleceń, która pomoże określić, w jakim stopniu konfiguracja Twojego sprzętu odpowiada tym „najlepszym praktykom” i na podstawie wyników wprowadzić zmiany w Twojej sieci. To pozwoli Ci w łatwy sposób, praktycznie bez kosztów, znacznie zmniejszyć ryzyko bezpieczeństwa.

Kilka przykładów dla niektórych systemów operacyjnych Cisco.
Zabezpieczanie konfiguracji Cisco IOS
Zabezpieczanie konfiguracji Cisco IOS-XR
Zabezpieczanie konfiguracji Cisco NX-OS
Lista kontrolna bezpieczeństwa Cisco
Na podstawie tych dokumentów można stworzyć listę wymagań dotyczących konfiguracji dla każdego typu sprzętu. Na przykład dla Cisco N7K VDC te wymagania mogą wyglądać tak.

W ten sposób mogą zostać utworzone pliki konfiguracyjne dla różnych typów aktywnego sprzętu w Twojej infrastrukturze sieciowej. Następnie, ręcznie lub przy użyciu automatyzacji, możesz 'przesłać' te pliki konfiguracyjne. Jak zautomatyzować ten proces, zostanie szczegółowo omówione w innej serii artykułów poświęconych orkiestracji i automatyzacji.

Audyt bezpieczeństwa designu

Zazwyczaj w sieci przedsiębiorstwa (enterprise network) w mniejszym lub większym zakresie występują następujące segmenty:

DC (Public services DMZ and Intranet data center)
Dostęp do internetu
Zdalny dostęp VPN
Krawędź WAN
Oddział
Kampus (biuro)
Rdzeń

Nazwy pochodzą z modelu Cisco SAFE , ale nie ma konieczności, aby trzymać się konkretnych nazw ani tego modelu. Chodzi o istotę i chęć uniknięcia formalności.

Dla każdego z tych segmentów wymagania dotyczące poziomu bezpieczeństwa, ryzyka oraz odpowiednio rozwiązania będą się różniły.

Rozważmy każdy z nich z osobna pod kątem problemów, z którymi możesz się zmierzyć z punktu widzenia bezpieczeństwa designu. Oczywiście, jak już wspomniałem, ten artykuł nie rości sobie pretensji do wyczerpanie tematu, który jest naprawdę głęboki i wieloaspektowy (jeśli w ogóle możliwe to), ale odzwierciedla moje osobiste doświadczenie.

Nie istnieje idealne rozwiązanie (przynajmniej obecnie). Zawsze jest to kompromis. Ważne jest, aby decyzja o zastosowaniu danego podejścia była podjęta świadomie, z pełnym zrozumieniem zarówno jego zalet, jak i wad.

Data Center

Najbardziej krytyczny z punktu widzenia bezpieczeństwa segment.
I, jak zwykle, tutaj także nie ma uniwersalnego rozwiązania. Wszystko bardzo zależy od wymagań dotyczących sieci.

Czy potrzebny jest firewall?

Pozornie odpowiedź wydaje się oczywista, ale sprawa nie jest tak jednoznaczna, jak może się wydawać. Na Twój wybór może wpłynąć nie tylko cena.

Przykład 1. Opóźnienia.
Jeśli pomiędzy jakimikolwiek segmentami sieci niskie opóźnienie jest istotnym wymogiem, co ma miejsce na przykład w przypadku giełdy, to pomiędzy tymi segmentami nie będziemy mogli używać firewalli. Trudno znaleźć badania dotyczące opóźnień w firewallach, ale tylko nieliczne modele przełączników mogą zapewnić opóźnienia poniżej lub w granicach 1 μs, dlatego sądzę, że jeśli mikrosekundy mają dla Ciebie znaczenie, firewalle to nie dla Ciebie.

Przykład 2. Wydajność.
Przepustowość najlepszych przełączników L3 zazwyczaj jest rzędu wyższa niż przepustowość najwydajniejszych firewalli. Dlatego w przypadku intensywnego ruchu, będziesz musiał prawdopodobnie skierować ten ruch omijając firewalle.

Przykład 3. Niezawodność.
Firewalle, zwłaszcza nowoczesne NGFW (Next-Generation FW) – to złożone urządzenia. Są one znacznie bardziej skomplikowane niż przełączniki L3/L2. Oferują wiele usług i możliwości konfiguracji, dlatego nic dziwnego, że ich niezawodność jest znacznie niższa. Jeśli ciągłość usługi jest krytyczna dla sieci, być może będziesz musiał wybrać, co zapewni lepszą dostępność — zabezpieczenie za pomocą firewalla czy prostota sieci zbudowanej na przełącznikach (lub różnego rodzaju fabrykach) z użyciem standardowych ACL.

W przypadku wymienionych powyżej przykładów, prawdopodobnie (jak zwykle) będziesz musiał znaleźć kompromis. Zastanów się nad następującymi rozwiązaniami:

jeśli zdecydowałeś się nie używać firewalli wewnątrz centrum danych, musisz przemyśleć, jak maksymalnie ograniczyć dostęp na peryferiach. Na przykład, możesz otworzyć tylko niezbędne porty z Internetu (dla ruchu klientów) i dostęp administracyjny do centrum danych tylko z hostów skokowych. Na hostach skokowych wykonaj wszelką potrzebną weryfikację (uwierzytelnienie/ autoryzacja, antywirus, logowanie, ...)
możesz użyć logicznego podziału sieci centrum danych na segmenty, w sposób podobny do schematu opisanego w PSEFABRIC przykład p002Routing should be configured in such a way that latency-sensitive or high-intensity traffic stays 'within' a single segment (in the case of p002, VRF) and does not pass through the firewall. Traffic between different segments will still go through the firewall. Route leaking between VRFs can also be used to avoid routing traffic through the firewall.
You can also use the firewall in transparent mode and only for those VLANs where these factors (latency/performance) are not significant. However, it is important to carefully study the limitations related to using this mode for each vendor.
You might consider implementing a service chain architecture. This will allow you to route only necessary traffic through the firewall. In theory, it looks good, but I have never seen this solution in production. We tested the service chain for Cisco ACI/Juniper SRX/F5 LTM about 3 years ago, but at that time, we found this solution to be 'immature'.

Level of protection

Now you need to answer the question of which tools you want to apply for traffic filtering. Here are some of the capabilities that are typically present in NGFW (for example, tutaj):

stateful firewalling (by default)
application firewalling
threat prevention (antivirus, anti-spyware, and vulnerability)
URL filtering
data filtering (content filtering)
file blocking (file types blocking)
dos protection

And it's not all straightforward. It might seem that the higher the level of protection, the better. But you also need to consider that

the more of the above-mentioned firewall features you use, the more expensive it will naturally be (licenses, additional modules).
The use of certain algorithms can significantly reduce the firewall's throughput and increase latency, see for example. tutaj
Like any complex solution, using advanced protection methods can reduce the reliability of your solution; for instance, when using application firewalling, I have encountered blocking of some perfectly standard applications (DNS, SMB).

As usual, you need to find the optimal solution for your network.

Nie ma jednoznacznej odpowiedzi na pytanie, jakie funkcje zabezpieczeń mogą być potrzebne. Po pierwsze, zależy to oczywiście od danych, które przesyłasz lub przechowujesz i które próbujesz zabezpieczyć. Po drugie, w rzeczywistości wybór środków ochrony jest często kwestią zaufania do dostawcy. Nie znasz algorytmów, nie wiesz, jak skuteczne są i nie możesz ich w pełni przetestować.

Dlatego w krytycznych segmentach dobrym rozwiązaniem może być korzystanie z ofert różnych firm. Na przykład, możesz włączyć oprogramowanie antywirusowe na zaporze, ale także używać lokalnej ochrony antywirusowej (innego producenta) na hostach.

Segmentacja

Mowa o logicznej segmentacji sieci centrum danych. Na przykład podział na VLAN-y i podsieci to także logiczna segmentacja, ale nie będziemy jej rozważać ze względu na jej oczywistość. Interesująca jest segmentacja z uwzględnieniem takich bytów jak strefy bezpieczeństwa zapory, VRF (oraz ich odpowiedników w różnych dostawcach), urządzenia logiczne (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, …), …

Przykład takiej logicznej segmentacji i aktualnie poszukiwanego designu centrum danych przedstawiony jest w p002 projektu PSEFABRIC.

Określając logiczne części swojej sieci, możesz następnie opisać, jak porusza się ruch między różnymi segmentami, na jakich urządzeniach będzie przeprowadzana filtracja i jakimi środkami.

Jeśli w Twojej sieci brakuje wyraźnego podziału logicznego i nie sformalizowane są zasady stosowania polityki bezpieczeństwa dla różnych przepływów danych (flow), oznacza to, że przy otwieraniu dostępu do różnych zasobów musisz rozwiązywać ten problem i z dużym prawdopodobieństwem za każdym razem rozwiążesz go inaczej.

Często segmentacja opiera się tylko na strefach bezpieczeństwa zapory. W takim przypadku musisz odpowiedzieć na następujące pytania:

jakie strefy bezpieczeństwa są potrzebne
jaki poziom ochrony chcesz zastosować w każdej z tych stref
czy ruch intra-zone będzie domyślnie dozwolony
jeśli nie, to jakie zasady filtracji ruchu będą stosowane w każdej ze stref
jakie zasady filtracji ruchu będą stosowane dla każdej pary stref (źródło/docelowa)

TCAM

Często występuje problem niedostatecznej pamięci TCAM (Ternary Content Addressable Memory), zarówno w przypadku routingu, jak i dostępu. IMHO, to jedno z najważniejszych zagadnień przy wyborze sprzętu, dlatego warto podejść do tego tematu z właściwą starannością.

Przykład 1. Tablica przekazywania TCAM.
Przyjrzyjmy się Palo Alto 7k zapora ogniowa.
Widzimy, że rozmiar tablicy przekazywania IPv4* = 32K
Jednocześnie ta liczba tras jest ogólna dla wszystkich VSYS-ów.
Załóżmy, że zgodnie z Twoim projektem zdecydowałeś się wykorzystać 4 VSYS-y.
Każdy z tych VSYS-ów jest połączony z dwoma PE MPLS w chmurze, które wykorzystujesz jako BB przez BGP. W ten sposób 4 VSYS-y wymieniają się wszystkimi specyficznymi trasami i mają tablicę przekazywania z mniej więcej tymi samymi zestawami tras (ale różnymi NH). Ponieważ każdy VSYS ma 2 sesje BGP (z identycznymi ustawieniami), każda trasa uzyskana przez MPLS ma 2 NH i odpowiednio 2 wpisy FIB w Tablicy Przekazywania. Jeśli założymy, że jest to jedyna zapora w centrum danych i musi znać wszystkie trasy, to oznacza, że łączna liczba tras w naszym centrum danych nie może przekroczyć 32K/(4 * 2) = 4K.
Teraz, jeśli założymy, że mamy 2 centra danych (z identycznym projektem), i chcemy użyć VLAN-ów „rozciągniętych” między centrami danych (na przykład dla vMotion), to aby rozwiązać problem routingu, musimy wykorzystać trasy hosta. Ale to oznacza, że w 2 centrach danych nie będziemy mieli więcej niż 4096 możliwych hostów i oczywiście może to być niewystarczające.

Przykład 2. ACL TCAM.
Jeśli planujesz filtrować ruch na przełącznikach L3 (lub innych rozwiązaniach wykorzystujących przełączniki L3, na przykład Cisco ACI), to przy wyborze sprzętu musisz zwrócić uwagę na ACL TCAM.
Załóżmy, że chcesz kontrolować dostęp na interfejsach SVI przełączników Cisco Catalyst 4500. Wtedy, jak pokazano na tego artykułu, aby kontrolować ruch wychodzący (tak samo jak i przychodzący) na interfejsach, możesz wykorzystać tylko 4096 linii TCAM. Co przy użyciu TCAM3 daje około 4000 ACE (linii ACL).

W przypadku, gdy napotkasz problem niedostatecznej pamięci TCAM, należy najpierw rozważyć możliwość jej optymalizacji. W przypadku problemu z rozmiarem tabeli przesyłania warto rozważyć agregację tras. W przypadku problemu z rozmiarem TCAM dla dostępu — audyt dostępu, usunięcie nieaktualnych i pokrywających się wpisów oraz być może przemyślenie procedury przyznawania dostępu (będzie to szczegółowo omówione w rozdziale poświęconym audytowi dostępu).

Wysoka dostępność

Pytanie brzmi, czy używać HA dla zapór ogniowych, czy postawić „równolegle” dwie niezależne skrzynki i w przypadku awarii jednej z nich kierować ruch przez drugą?

Odpowiedź wydaje się oczywista – używać HA. Powód, dla którego to pytanie wciąż się pojawia, polega na tym, że niestety teoretyczne i reklamowe 99 i kilka dziewiątek po przecinku dostępności w praktyce okazują się nieco mniej różowe. HA jest logicznie dosyć skomplikowanym rozwiązaniem i na różnych urządzeniach oraz z różnymi dostawcami (nie było wyjątków) napotykaliśmy problemy, błędy i zatrzymania usług.

W przypadku używania HA zyskujesz możliwość wyłączania poszczególnych węzłów, przełączania się między nimi bez przerywania usługi, co jest istotne, na przykład podczas aktualizacji, jednak masz znaczną, choć nie zerową, szansę, że obie węzły mogą ulec awarii jednocześnie, a także że kolejna aktualizacja nie przebiegnie tak gładko, jak obiecuje dostawca (problem ten można uniknąć, jeśli masz możliwość przetestowania aktualizacji na sprzęcie laboratoryjnym).

Jeżeli nie używasz HA, to z punktu widzenia podwójnej awarii twoje ryzyko jest znacznie niższe (ponieważ masz 2 niezależne zapory ogniowe), ale ponieważ sesje nie są synchronizowane, za każdym razem, gdy następuje przełączenie między tymi zaporami ogniowymi, tracisz ruch. Oczywiście można używać zapory bezstanowej, ale wtedy sens używania zapory w dużej mierze się zatraca.

Zatem, jeśli w wyniku audytu odkryłeś oddzielnie stojące zapory sieciowe i zastanawiasz się nad zwiększeniem niezawodności swojej sieci, to HA z pewnością jest jednym z zalecanych rozwiązań, ale powinieneś również uwzględnić wady związane z tym podejściem, a być może dla twojej sieci lepszym rozwiązaniem będzie coś innego.

Wygoda w zarządzaniu (manageability)

W zasadzie HA to także o zarządzalności. Zamiast konfigurować dwa urządzenia osobno i rozwiązywać problem synchronizacji konfiguracji, zarządzasz nimi w wielkiej mierze tak, jakbyś miał jedno urządzenie.

Ale być może masz wiele centrów danych i wiele zapór sieciowych, wtedy ten problem staje na nowym poziomie. I pytanie dotyczy nie tylko konfiguracji, ale również