Zaatakowany serwer rzadko oznacza koniec ataku. Jeśli taki serwer może łączyć się z każdą inną maszyną w sieci, intruz może wykorzystać go jako punkt startowy do kradzieży danych uwierzytelniających, wdrożenia ransomware, modyfikowania aplikacji lub atakowania systemów kopii zapasowych. Segmentacja sieci ogranicza zasięg ataku, kontrolując, które systemy mogą się komunikować i z jakiego powodu.
Segmentacja nie jest jednym produktem ani pojedynczym ustawieniem. To dyscyplina projektowa, która łączy sieci VLAN, podsieci, strefy bezpieczeństwa, routing, zasady zapory, mechanizmy kontroli tożsamości i monitoring. Cel jest prosty: serwer WWW nie powinien móc inicjować dowolnych połączeń z laptopami pracowników, baza danych nie powinna być dostępna z publicznego internetu, a serwer produkcyjny nie powinien automatycznie otrzymywać dostępu administracyjnego do infrastruktury kopii zapasowych.
W przypadku agencji i małych firm rozsądny projekt nie musi być skomplikowany. Powinien jednak odzwierciedlać rzeczywiste działanie systemów, wszędzie tam, gdzie to praktyczne stosować dostęp domyślnie blokowany oraz być regularnie testowany. Segmentacja powinna również uzupełniać odizolowaną i możliwą do odtworzenia strategię tworzenia kopii zapasowych. Nie gwarantuje ona, że włamanie zostanie powstrzymane, ani nie przywróci danych zaszyfrowanych lub usuniętych przez atakującego.
Przed czym chroni segmentacja sieci
Segmentacja sieci dzieli infrastrukturę na odrębne obszary i umieszcza między nimi kontrolowane granice. Granice te mogą być wdrażane za pomocą sieci fizycznych, sieci VLAN, routowanych podsieci, wirtualnych zapór, zapór na hostach lub połączenia tych mechanizmów.
Najważniejszą korzyścią z punktu widzenia bezpieczeństwa jest ograniczenie ruchu bocznego. Ruch boczny to proces, za pomocą którego atakujący przemieszcza się z początkowo zaatakowanego systemu do innych systemów wewnątrz środowiska. Publicznie dostępny serwer WWW może zostać przejęty za pośrednictwem niezałatanej platformy. Następnie atakujący szuka danych uwierzytelniających do baz danych, interfejsów zarządzania, udziałów plików, usług domenowych, hipernadzorców i konsol kopii zapasowych. Każda dostępna usługa tworzy kolejną możliwość ataku.
Płaska sieć ułatwia ten proces. W płaskim projekcie serwery, stacje robocze, drukarki, hipernadzorcy i narzędzia zarządzania mogą znajdować się w jednym szerokim zakresie adresów IP. Dostępność sieciowa jest często traktowana jako uprawnienie. Gdy atakujący znajdzie się wewnątrz, może skanować środowisko, łączyć się z usługami, które nigdy nie miały być publiczne, oraz wykorzystywać słabe wewnętrzne mechanizmy kontroli.
Segmentacja zmienia to domyślne założenie. Systemy są umieszczane w strefach zgodnie z ich rolą i poziomem ekspozycji, a ruch między strefami jest jawnie kontrolowany. Przejęty serwer WWW nadal może być niebezpieczny, ale powinien mieć wyłącznie połączenia niezbędne do obsługi aplikacji. Nie powinien móc skanować sieci zarządzania ani łączyć się ze wszystkimi serwerami przez zdalny pulpit i SSH.
Zespoły szukające informacji o segmentacji sieci i bezpieczeństwie serwerów w kontekście ograniczania ruchu bocznego znajdą wiele możliwych architektur. Najważniejsze jest, aby nie kopiować bezkrytycznie żadnego schematu. Projekt musi wynikać z rzeczywistych zależności aplikacji, procesów administracyjnych i wymagań dotyczących odtwarzania.
VLAN-y, podsieci i strefy bezpieczeństwa są powiązane, ale różne
VLAN-y zapewniają logiczną separację
Wirtualna sieć LAN, czyli VLAN, oddziela urządzenia na warstwie 2, nawet gdy korzystają one z tego samego fizycznego sprzętu przełączającego. Firma może na przykład umieścić stacje robocze w biurze w jednym VLAN-ie, serwery produkcyjne w innym, a interfejsy zarządzania w trzecim. Sieci VLAN ograniczają zasięg rozgłaszania i tworzą wyraźne punkty, w których ruch musi być routowany.
Same sieci VLAN nie stanowią granicy bezpieczeństwa. Jeśli router, przełącznik warstwy 3 lub zapora zezwala na cały ruch między VLAN-ami, separacja ma głównie charakter administracyjny. Wartość bezpieczeństwa wynika z inspekcji i kontroli ruchu przekraczającego tę granicę.
Podsieci definiują sieci routowane
Każdy VLAN ma zazwyczaj własną podsieć IP. Podsieć serwerów może używać jednego prywatnego zakresu adresów, podczas gdy podsieć zarządzania korzysta z innego. Podsieci ułatwiają zrozumienie tras i zasad zapory, ale oddzielne zakresy IP nie blokują automatycznie komunikacji. O tym, co jest dozwolone, nadal decydują routing i listy kontroli dostępu.
Strefy bezpieczeństwa opisują poziom zaufania i ekspozycji
Strefa bezpieczeństwa to pojęcie związane z zasadami. Grupuje systemy o podobnym poziomie ekspozycji lub podobnym celu bezpieczeństwa. Typowe małe środowisko może obejmować:
- Strefę internetową lub brzegową: zapory, odwrotne serwery proxy, moduły równoważenia obciążenia i inne systemy bezpośrednio wystawione na sieci zewnętrzne.
- Strefę WWW: publicznie dostępne serwery WWW przyjmujące żądania z internetu lub od serwera proxy na brzegu sieci.
- Strefę aplikacji: usługi aplikacyjne, które powinny przyjmować żądania wyłącznie od zatwierdzonych systemów WWW lub integracyjnych.
- Strefę baz danych: serwery baz danych, które powinny być dostępne wyłącznie dla określonych usług aplikacyjnych i zatwierdzonych ścieżek administracyjnych.
- Strefę zarządzania: serwery przesiadkowe, konsole monitoringu, systemy konfiguracji, zarządzanie hipernadzorcami i inne interfejsy administracyjne.
- Strefę kopii zapasowych: agentów kopii zapasowych, repozytoria, systemy zarządzania i infrastrukturę odtwarzania oddzielone od obciążeń produkcyjnych.
- Strefę użytkowników: urządzenia pracowników, drukarki i inne wyposażenie biurowe, które zazwyczaj wymagają innej polityki dostępu niż serwery.
Strefy te mogą być fizyczne, wirtualne lub hostowane przez dostawcę. Najważniejsze jest, aby ruch między nimi przechodził przez punkt egzekwowania zasad i był rejestrowany w stopniu wystarczającym do zbadania nieoczekiwanego zachowania.
Projektuj rozwiązanie wokół wymagań komunikacyjnych
Najlepszym punktem wyjścia nie jest lista numerów VLAN. Należy rozpocząć od spisu usług i ich wymagań komunikacyjnych. Dla każdego serwera zapisz, co zapewnia, kto z niego korzysta, które porty są wymagane, czy komunikacja jest inicjowana w jednym kierunku czy w obu oraz co się dzieje, gdy zależność jest niedostępna.
Zadaj pytania takie jak:
- Czy warstwa WWW musi łączyć się z warstwą aplikacji, czy tę funkcję może pełnić wewnętrzny odwrotny serwer proxy?
- Czy serwer aplikacji potrzebuje bezpośredniego dostępu do bazy danych i przez który port bazy?
- Które systemy potrzebują DNS, synchronizacji czasu, usług tożsamości lub certyfikatów?
- Czy monitoring odpytuje serwery, czy agenci wysyłają dane do kolektora monitoringu?
- Którzy administratorzy potrzebują dostępu przez SSH, zdalny pulpit, konsolę lub hipernadzorcę?
- Czy serwer w ogóle potrzebuje dostępu do internetu, a jeśli tak, to do jakich miejsc docelowych?
- Które połączenia kopii zapasowych są inicjowane przez serwer produkcyjny, serwer kopii zapasowych lub oba te systemy?
Udokumentuj odpowiedzi w postaci macierzy komunikacji. Prosta macierz może zawierać strefę źródłową, strefę docelową, protokół, port, cel, kierunek, właściciela i datę przeglądu. Zapobiega to częstemu błędowi: zezwalaniu na cały zakres podsieci, ponieważ jedna aplikacja potrzebuje jednego połączenia.
Zależności aplikacji należy weryfikować, a nie zakładać. Dokumentacja dostawcy może informować, że usługa korzysta z jednego portu, podczas gdy rzeczywiste wdrożenie wymaga również DNS, dostawcy tożsamości, usługi licencjonowania, przekaźnika SMTP lub interfejsu API chmury. Zacznij od ostrożnej polityki, obserwuj prawidłowy ruch i dodawaj wąsko zdefiniowane reguły z przypisanym właścicielem.
Praktyczny projekt warstwowy dla agencji i małych firm
Mała agencja może hostować witryny klientów, aplikacje wewnętrzne, bazy danych i narzędzia zarządzania na niewielkiej liczbie serwerów fizycznych lub wirtualnych. Może nie mieć dedykowanego zespołu bezpieczeństwa sieci. Mimo to odpowiedni projekt może rozdzielić najważniejsze zagrożenia bez tworzenia niemożliwego do zarządzania labiryntu.
Warstwa WWW
Warstwa WWW obejmuje systemy obsługujące niezaufane żądania. Serwery te należy traktować jako bardziej ryzykowne, ponieważ wystawiają usługi na internet. Zezwalaj na ruch przychodzący wyłącznie dla wymaganych protokołów internetowych, zazwyczaj za pośrednictwem zapory, odwrotnego serwera proxy lub warstwy równoważenia obciążenia. Dostęp administracyjny powinien odbywać się ścieżką zarządzania, a nie przez interfejs publiczny.
Serwer WWW zwykle musi inicjować połączenia z warstwą aplikacji, pobierać zatwierdzone aktualizacje lub łączyć się z wybranymi usługami zewnętrznymi. Nie powinien mieć nieograniczonego dostępu do sieci baz danych, wewnętrznych udziałów plików, urządzeń pracowników ani interfejsów hipernadzorców. Jeśli serwer udostępnia wyłącznie treści statyczne, lista dozwolonych miejsc docelowych może być jeszcze węższa.
Warstwa aplikacji
Warstwa aplikacji obsługuje logikę biznesową, interfejsy API, zadania działające w tle i usługi integracyjne. Powinna przyjmować ruch wyłącznie od określonych serwerów WWW, zaufanych integracji lub użytkowników wewnętrznych, jeśli jest to wymagane. Ruch wychodzący należy ograniczyć do baz danych, kolejek, usług tożsamości i zewnętrznych interfejsów API faktycznie używanych przez aplikację.
Nie zakładaj, że umieszczenie serwerów aplikacji i baz danych w oddzielnych VLAN-ach jest wystarczające. Zapora powinna zezwalać wyłącznie na protokół i port bazy danych wymagane przez aplikację oraz tylko z określonych adresów aplikacji. Administracyjny dostęp do bazy danych powinien korzystać z oddzielnej trasy zarządzania i silniejszego uwierzytelniania.
Warstwa baz danych
Bazy danych zawierają skoncentrowaną wartość i powinny mieć możliwie najmniejszą ekspozycję sieciową. Nie powinny przyjmować połączeń z internetu ani z ogólnych sieci użytkowników. W wielu środowiskach tylko niewielki zestaw serwerów aplikacyjnych powinien mieć możliwość łączenia się z usługą bazy danych.
Serwery baz danych mogą potrzebować DNS, synchronizacji czasu, monitoringu i połączenia z kopiami zapasowymi. Wymagania te należy obsługiwać za pomocą oddzielnych reguł, a nie łączyć w szeroką politykę zezwalającą. Jeśli silnik bazy danych obsługuje szyfrowanie podczas przesyłania i silne uwierzytelnianie, użyj tych mechanizmów jako dodatkowej warstwy. Segmentacja sieci ogranicza dostępność; sama w sobie nie sprawia, że dozwolone połączenie jest godne zaufania.
Warstwa monitoringu i rejestrowania
Systemy monitoringu potrzebują widoczności, ale widoczność nie oznacza nieograniczonego dostępu. Jeśli agenci monitoringu wysyłają dane do kolektora, zezwól na wychodzące połączenie agenta z tym kolektorem. Jeśli kolektor odpytuje systemy, zezwól wyłącznie na wymagane protokoły odpytywania z podsieci monitoringu.
Logi powinny być wysyłane do lokalizacji, którą atakujący nie może łatwo zmienić po przejęciu jednego serwera produkcyjnego. Ogranicz liczbę osób mogących administrować platformą monitoringu, chroń jej dane uwierzytelniające oddzielnie i generuj alerty dotyczące zmian reguł zapory, kont uprzywilejowanych i konfiguracji kopii zapasowych. Monitoring powinien pomagać wykrywać zarówno ataki, jak i awarie segmentacji.
Warstwa zarządzania
Warstwa zarządzania jest jednym z najbardziej wrażliwych obszarów środowiska. Może zawierać serwery przesiadkowe, narzędzia zdalnej administracji, konsole hipernadzorców, systemy zarządzania konfiguracją, usługi katalogowe, zarządzanie urządzeniami sieciowymi i platformy bezpieczeństwa.
Interfejsy zarządzania nie powinny być bezpośrednio wystawione na internet. Administratorzy powinni łączyć się przez kontrolowaną usługę zdalnego dostępu oraz, w razie potrzeby, przez odpowiednio zabezpieczony serwer przesiadkowy. Serwer przesiadkowy powinien mieć ograniczony zestaw dozwolonych miejsc docelowych i nie powinien służyć do zwykłego przeglądania internetu ani obsługi poczty elektronicznej.
Stosuj reguły zapory domyślnie blokujące ruch
Domyślne blokowanie oznacza, że ruch jest blokowany, chyba że konkretna reguła na niego zezwala. Jest to bezpieczniejsze niż dopuszczanie szerokiego dostępu wewnętrznego i późniejsze próby usuwania niebezpiecznych wyjątków. Dzięki temu zamierzona architektura jest również widoczna w zestawie reguł.
Przydatna reguła zapory powinna odpowiadać na pięć pytań:
- Jakie adresy źródłowe, tożsamości lub strefy są objęte regułą?
- Jaki system lub usługa docelowa są wymagane?
- Jaki protokół i port są dozwolone?
- Czy połączenie jest przychodzące, wychodzące czy dwukierunkowe?
- Kto jest właścicielem reguły, dlaczego istnieje i kiedy należy ją zweryfikować?
Preferuj konkretne adresy serwerów lub ściśle ograniczone grupy adresów zamiast całych podsieci. Korzystaj z nazwanych obiektów usług zamiast szerokich zakresów portów. Unikaj reguł takich jak „dowolne źródło do dowolnego celu”, chyba że istnieje jasno udokumentowany, tymczasowy powód oraz data wygaśnięcia.
Kolejność reguł ma znaczenie. Szeroka reguła zezwalająca umieszczona przed regułą restrykcyjną może po cichu zniweczyć zamierzony projekt. Stosuj jawne reguły blokujące tam, gdzie poprawiają widoczność, i selektywnie rejestruj blokowany ruch. Rejestrowanie każdego pakietu może przeciążyć mały zespół, ale logowanie powtarzających się prób połączeń między wrażliwymi strefami może ujawnić skanowanie, złośliwe oprogramowanie lub niesprawną zależność aplikacji.
Regułami zapory należy zarządzać jak infrastrukturą, a nie edytować je nieformalnie pod presją. Prowadź rejestr zmian, stosuj wzajemne przeglądy w przypadku wrażliwych zasad i usuwaj tymczasowy dostęp po zakończeniu prac. Jeśli platforma to obsługuje, integruj zmiany reguł z zarządzaniem konfiguracją i zachowuj poprzednie wersje na potrzeby wycofania zmian.
Kontroluj ruch wschód–zachód, nie tylko ruch internetowy
Ruch północ–południe przepływa między środowiskiem wewnętrznym a internetem. Ruch wschód–zachód przepływa między systemami wewnętrznymi. Tradycyjne bezpieczeństwo perymetryczne często koncentruje się na ruchu północ–południe i zakłada, że sieć wewnętrzna jest zaufana. To założenie zawodzi, gdy atakujący przejmuje serwer, kradnie dane uwierzytelniające administratora lub podłącza zainfekowane urządzenie do sieci biurowej.
Kontrole ruchu wschód–zachód powinny obejmować ruch między:
- serwerami WWW i serwerami aplikacji,
- serwerami aplikacji i bazami danych,
- serwerami produkcyjnymi i interfejsami zarządzania,
- serwerami i stacjami roboczymi użytkowników,
- maszynami wirtualnymi na tym samym hoście lub w tym samym klastrze,
- systemami produkcyjnymi i repozytoriami kopii zapasowych,
- kolektorami monitoringu i monitorowanymi urządzeniami.
Zapory na hostach dodają kolejną warstwę. Są szczególnie przydatne, gdy obciążenia współdzielą wirtualny przełącznik lub gdy ruch nie przechodzi przez centralną fizyczną zaporę. Zapora hosta może ograniczać lokalne usługi i blokować połączenia, które nigdy nie powinny być wymagane, nawet jeśli polityka sieciowa jest przypadkowo zbyt szeroka.
Mikrosegmentacja może posunąć tę koncepcję dalej, stosując zasady do poszczególnych obciążeń lub tożsamości, a nie tylko do sieci VLAN. Małe organizacje nie zawsze potrzebują wyspecjalizowanej platformy mikrosegmentacji. Starannie zarządzane zapory hostów, grupy bezpieczeństwa, tożsamości usług i lokalne zasady mogą zapewnić znaczącą separację, jeśli są udokumentowane i utrzymywane.
Oddziel administrację od ruchu produkcyjnego
Dostęp administracyjny zasługuje na osobną ścieżkę, ponieważ dane uwierzytelniające administratora mogą jednocześnie odblokować wiele systemów. Łączenie ruchu użytkowników, aplikacji i zarządzania w jednej sieci utrudnia odróżnienie prawidłowej administracji od aktywności atakującego.
Bezpieczniejszy model zakłada, że administratorzy łączą się z bramą zdalnego dostępu lub VPN-em, uwierzytelniają się za pomocą indywidualnych kont i, jeśli to możliwe, korzystają z uwierzytelniania wieloskładnikowego. Następnie uzyskują dostęp do odpowiednio zabezpieczonego serwera przesiadkowego lub strefy zarządzania. Serwer przesiadkowy łączy się potem z zatwierdzonymi interfejsami serwerów. Należy unikać bezpośredniego dostępu z niezarządzanego laptopa do każdego serwera.
Kontrole administracyjne powinny obejmować:
- oddzielne nazwane konta administratorów zamiast współdzielonych danych uprzywilejowanych,
- uwierzytelnianie wieloskładnikowe przy zdalnym dostępie i w systemach uprzywilejowanych,
- uprawnienia zgodne z zasadą najmniejszych uprawnień i rolą zawodową,
- krótkotrwały lub przyznawany na żądanie dostęp do wrażliwych zadań, jeśli jest obsługiwany,
- ograniczenia dotyczące sieci źródłowych, z których można łączyć się z SSH, zdalnym pulpitem i interfejsami API zarządzania,
- centralne rejestrowanie uwierzytelniania i aktywności uprzywilejowanej,
- bezpieczne przechowywanie i rotację danych uwierzytelniających usług.
Nie pomijaj zarządzania poza pasmem. Zarządzanie hipernadzorcami, kontrolery zdalnych konsol, systemy pamięci masowej i urządzenia sieciowe powinny znajdować się w strefie zarządzania, a nie w tym samym segmencie co zwykłe obciążenia. Jeśli serwer produkcyjny zostanie przejęty, atakujący nie powinien automatycznie uzyskać dostępu do platformy kontrolującej wszystkie maszyny wirtualne.
Utrzymuj niezależną sieć kopii zapasowych
Kopie zapasowe są często atakowane po uzyskaniu przez atakującego dostępu do środowiska produkcyjnego. Jeśli konsola kopii zapasowych, repozytorium i serwery produkcyjne współdzielą te same dane uwierzytelniające oraz nieograniczony dostęp sieciowy, ransomware może usunąć punkty odzyskiwania przed zaszyfrowaniem działających systemów.
Wszędzie tam, gdzie pozwala na to architektura, oddziel ruch kopii zapasowych i zarządzanie nimi od zwykłego ruchu produkcyjnego. Sieć kopii zapasowych może obejmować dedykowane sieci VLAN, reguły zapory, ograniczone trasy, oddzielne konta usług oraz dostęp do repozytorium niedostępny ze stref użytkowników lub WWW.
Segmentacja powinna odpowiadać na dwa różne pytania. Po pierwsze, czy system kopii zapasowych może zebrać lub otrzymać potrzebne dane? Po drugie, czy przejęty serwer produkcyjny może modyfikować, usuwać lub administrować zapisanymi punktami odzyskiwania? Pierwsze połączenie może być konieczne; drugie powinno być ściśle ograniczone.
Kontrole sieciowe to tylko jeden z elementów odporności kopii zapasowych. Kopie zapasowe powinny być szyfrowane przed opuszczeniem środowiska kontrolowanego przez klienta, a klucz szyfrowania powinien znajdować się u klienta, a nie u dostawcy kopii zapasowych. Należy przechowywać je poza środowiskiem produkcyjnym i chronić przed usunięciem lub modyfikacją przez cały okres retencji.
Jeśli przejęty serwer uzyska dostęp do systemów produkcyjnych i spróbuje zniszczyć możliwości odzyskiwania, odizolowana, szyfrowana i niezmienna usługa, taka jak zewnętrzna kopia zapasowa Safenix dla serwerów firmowych, zapewnia dodatkową granicę odzyskiwania. Safenix chroni serwery kontrolowane przez klienta; nie jest planem tworzenia kopii zapasowych dla witryn działających na hostingu współdzielonym.
Ostrożnie podchodź do VPS-ów i hostowanej infrastruktury WWW
Segmentacja jest bardziej skomplikowana, gdy infrastruktura jest hostowana przez dostawcę, ponieważ klient może nie kontrolować fizycznych przełączników ani sieci nadrzędnej. Projekt powinien rozróżniać mechanizmy, które klient może skonfigurować wewnątrz VPS-a lub środowiska chmurowego, od tych, które musi zapewnić platforma hostingowa.
Na poziomie klienta korzystaj z oddzielnych sieci wirtualnych, grup bezpieczeństwa, zapór hostów i prywatnych interfejsów, jeśli są dostępne. Ogranicz interfejsy publiczne do wymaganych usług. Umieszczaj bazy danych i punkty końcowe zarządzania w sieciach prywatnych i nie wystawiaj ich za pomocą publicznych adresów IP tylko dlatego, że jest to wygodne.
Zapytaj dostawcę, jak działa izolacja sieci, czy ruch prywatny jest filtrowany, jak stosowane są zasady zapory i czy dostęp do zarządzania jest oddzielony od obciążeń klienta. Sprawdź także sposób obsługi migawek, obrazów i kopii zapasowych przez dostawcę. Migawka dostępna za pośrednictwem tej samej przejętej płaszczyzny sterowania może nie być niezależną kopią odzyskiwania.
W przypadku organizacji korzystających z VPS-ów i hostowanej infrastruktury WWW z oddzielnymi strefami bezpieczeństwa praktyczne pytania są takie same jak w serwerowni: który system może inicjować połączenie, która usługa jest wystawiona, kto może nią administrować i jak dostęp zostałby odebrany podczas incydentu? Lokalizacja hostowana nie eliminuje potrzeby segmentacji. Zmienia jedynie dostępne mechanizmy kontroli i podmiot, który nimi zarządza.
Hosting współdzielony wymaga szczególnej ostrożności w opisywaniu odpowiedzialności. Klient może mieć możliwość konfigurowania ustawień aplikacji lub zapory na poziomie konta, ale nie oznacza to kontroli nad siecią serwerów dostawcy ani sąsiednimi kontami. Safenix chroni kontrolowane przez klienta serwery firmowe i nie powinien być przedstawiany jako usługa kopii zapasowych dla witryny na hostingu współdzielonym.
Najczęstsze błędy w segmentacji
Tworzenie VLAN-ów bez egzekwowania zasad
Oddzielne sieci VLAN z nieograniczonym routingiem między VLAN-ami tworzą pozory segmentacji bez zapewnienia zamierzonej ochrony. Sprawdź rzeczywistą ścieżkę przekazywania ruchu i politykę zapory. Potwierdź, że ruch nie może ominąć punktu inspekcji przez alternatywny interfejs, most lub niezarządzany przełącznik.
Zezwalanie dla całej podsieci dla wygody
Gdy aplikacja musi połączyć się z jedną bazą danych, zezwolenie na dostęp całej podsieci WWW jest szybsze niż wskazanie dokładnego źródła. Umożliwia jednak każdemu przejętemu lub błędnie skonfigurowanemu hostowi w tej podsieci dostęp do bazy. Zamiast tego używaj grup adresów i reguł właściwych dla konkretnych usług.
Pozostawianie tymczasowych wyjątków
Awaryjny dostęp często staje się stały. Każda tymczasowa reguła powinna mieć właściciela, uzasadnienie, datę utworzenia i datę wygaśnięcia. Wygasłe reguły przeglądaj podczas normalnej pracy, a nie dopiero po incydencie.
Używanie współdzielonych danych uwierzytelniających
Współdzielone dane administratorów i usług utrudniają przypisanie aktywności do konkretnej osoby i ułatwiają atakującemu przemieszczanie się między systemami. Używaj indywidualnych kont dla ludzi, oddzielnych tożsamości usług dla aplikacji oraz unikalnych danych uwierzytelniających dla systemów kopii zapasowych i zarządzania.
Umieszczanie interfejsów zarządzania w sieciach produkcyjnych
Porty zarządzania serwerami, konsole hipernadzorców i administracja pamięcią masową nie powinny być dostępne ze zwykłych urządzeń użytkowników ani z obciążeń wystawionych publicznie. Sieć zarządzania jest przydatna tylko wtedy, gdy dostęp do niej również jest ograniczony.
Pomijanie urządzeń innych niż serwery
Drukarki, kamery, systemy budynkowe i niedrogie urządzenia sieciowe są często utrzymywane gorzej niż serwery. Nie powinny mieć nieograniczonego dostępu do wrażliwej infrastruktury. Umieść je w odpowiedniej strefie urządzeń i zezwól wyłącznie na wymagane przez nie usługi.
Brak dokumentacji wyjątków
Nieudokumentowane reguły stają się trwałymi założeniami. Gdy inżynier odchodzi z firmy lub aplikacja się zmienia, nikt nie wie, dlaczego dane połączenie istnieje ani czy można je usunąć. Dokumentacja jest częścią kontroli, a nie administracyjną dekoracją.
Jak sprawdzić, czy segmentacja działa
Projektu nie potwierdza sam schemat sieci. Testuj punkty egzekwowania zasad z tych samych lokalizacji, które mógłby wykorzystać atakujący. Utrzymuj zatwierdzony plan testów, aby skanowanie i próby połączeń nie zakłócały działania produkcji.
Testuj dozwolone ścieżki
Z każdej strefy źródłowej sprawdź dostępność wymaganych usług. Testuj dokładny protokół i port, a nie tylko to, czy miejsce docelowe odpowiada na ping. Potwierdź, że transakcje aplikacji, monitoring, administracja i zadania kopii zapasowych działają zamierzonymi ścieżkami.
Testuj zabronione ścieżki
Próbuj nawiązywać połączenia z serwerów WWW do interfejsów zarządzania, z sieci użytkowników do baz danych, z serwerów aplikacji do niezwiązanych systemów produkcyjnych oraz ze zwykłych serwerów do portów administracyjnych kopii zapasowych. Próby te powinny kończyć się niepowodzeniem. Udane połączenie wymaga zbadania, nawet jeśli usługa nie ujawnia danych.
Testuj z perspektywy przejętego hosta
Użyj kontrolowanego konta testowego lub zatwierdzonej oceny bezpieczeństwa, aby zasymulować atakującego, który uzyskał dostęp do jednego serwera. Sprawdź, czy z tej pozycji możliwe jest wykrywanie sieci, dostęp do usług uwierzytelniania, zdalna administracja, udostępnianie plików lub dostęp do innych stref. Szukaj tras pominiętych dlatego, że pierwotna dokumentacja opisywała zamierzony, a nie rzeczywisty ruch.
Przeglądaj logi i alerty
Potwierdź, że blokowane połączenia są widoczne na użytecznym poziomie szczegółowości. Alerty powinny wskazywać nietypowe skanowanie, powtarzające się próby dostępu do wrażliwych stref oraz zmiany polityki bezpieczeństwa. Upewnij się, że logi są przechowywane w miejscu, którego przejęty serwer nie może wyczyścić.
Testuj awarie i odzyskiwanie
Zapory, przełączniki i bramy VPN mogą ulec awarii lub zostać błędnie skonfigurowane. Sprawdź, jak środowisko zachowuje się podczas awarii urządzenia, wdrażania zasad lub utraty głównej ścieżki zarządzania. Potwierdź, że dostęp awaryjny jest kontrolowany i udokumentowany, zamiast polegać na nieudokumentowanym obejściu.
Powtarzaj testy po dużych zmianach: nowe aplikacje, migracje serwerów, przeprojektowanie VLAN-ów, zmiany dostawcy i aktualizacje zapory mogą zmienić dostępność systemów. Automatyczna walidacja zasad i zaplanowane skanowanie podatności mogą pomóc, ale powinny wspierać ręczną analizę zależności biznesowych, a nie ją zastępować.
Segmentacja i reagowanie na incydenty
Podczas incydentu segmentacja powinna pomóc zespołowi szybko odizolować serwer bez wyłączania całej firmy. Utrzymuj wcześniej zdefiniowane działania ograniczające dla typowych sytuacji. Mogą one obejmować wyłączenie portu przełącznika hosta, usunięcie serwera z produkcyjnego VLAN-u, zablokowanie konta usługi, ograniczenie ruchu wychodzącego strefy lub przeniesienie administracji na ścieżkę awaryjną.
Utrzymuj aktualny spis zasobów i zależności. Jeśli osoby reagujące na incydent nie wiedzą, które usługi zależą od danego serwera, mogą zbyt wolno go odizolować albo spowodować niepotrzebne zakłócenia. Dla ważnych systemów zapisz właściciela biznesowego, właściciela technicznego, strefę, kluczowe zależności, politykę kopii zapasowych i priorytet odzyskiwania.
Procedury reagowania na incydenty powinny określać, kto może zatwierdzać awaryjne zmiany zapory, jak zmiany są rejestrowane i jak później przywracana jest normalna polityka. Testuj procedury. Mechanizm, który istnieje wyłącznie w dokumencie, ale nie może być użyty pod presją, zapewnia ograniczoną ochronę.
Dlaczego segmentacja nie może zastąpić odizolowanych kopii zapasowych
Segmentacja ogranicza dostępność; nie sprawia, że przejęty system staje się bezpieczny. Atakujący może wykorzystać dozwolone połączenie aplikacyjne, przejąć stację roboczą administratora, ukraść dane uwierzytelniające, nadużyć wyjątku w zaporze lub zaatakować system kopii zapasowych przez prawidłowe ścieżki zarządzania. Złośliwe oprogramowanie może również uszkodzić dane, zanim zadanie kopii zapasowej się uruchomi.
Możliwość odtworzenia wymaga czegoś więcej niż posiadania kopii w dowolnym miejscu. Kopia musi być dostępna po przejęciu środowiska produkcyjnego, chroniona przed nieuprawnionym usunięciem, odpowiednio zaszyfrowana, przechowywana przez wymagany okres i możliwa do przywrócenia w ramach celów odtwarzania firmy.
Safenix zapewnia zewnętrzne kopie zapasowe dla serwerów firmowych kontrolowanych przez klienta. Dane są szyfrowane kluczem, którego Safenix nigdy nie posiada, przechowywane w Niemczech i utrzymywane w niezmiennej postaci przez cały okres retencji. Taki model uzupełnia segmentację: kontrole sieciowe zmniejszają ryzyko rozprzestrzenienia się incydentu, a niezależna kopia odzyskiwania pomaga firmie powrócić do znanego, prawidłowego stanu, jeśli systemy lub lokalne kopie zapasowe zostaną uszkodzone.
Planuj połączenie kopii zapasowych jako część architektury. Ogranicz liczbę hostów mogących wysyłać dane kopii zapasowych, trzymaj administrację kopią z dala od zwykłych kont produkcyjnych i testuj odtwarzanie, zamiast sprawdzać wyłącznie, czy zadania zgłaszają powodzenie. Pomyślne wykonanie zadania kopii zapasowej jest dowodem skopiowania danych; pomyślne odtworzenie pokazuje, że dane rzeczywiście mogą wesprzeć odzyskiwanie.
Plan wdrożenia możliwy do zarządzania
Małe zespoły mogą poprawiać segmentację etapami. Zacznij od systemów, które generują największe ryzyko i mają największą wartość, zamiast próbować od razu przeprowadzić idealne przeprojektowanie.
- Zmapuj środowisko. Zidentyfikuj serwery, maszyny wirtualne, użytkowników, urządzenia sieciowe, interfejsy zarządzania, bazy danych, systemy kopii zapasowych i zależności zewnętrzne.
- Skategoryzuj ekspozycję. Oznacz systemy wystawione na internet, wewnętrzne, wrażliwe, administracyjne i służące do odzyskiwania. Wskaż miejsca, w których jedno przejęcie miałoby największy wpływ.
- Zdefiniuj strefy. Zacznij od praktycznych grup, takich jak brzeg, WWW, aplikacje, bazy danych, zarządzanie, użytkownicy i kopie zapasowe. Dziel strefy dalej tylko wtedy, gdy różnica w polityce uzasadnia koszt operacyjny.
- Zbuduj macierz komunikacji. Zapisz wymagane źródło, miejsce docelowe, protokół, port, kierunek, właściciela i cel.
- Najpierw egzekwuj najważniejsze granice. Oddziel serwery publiczne od baz danych, użytkowników od systemów zarządzania oraz produkcję od administracji kopiami zapasowymi.
- Zastosuj reguły domyślnie blokujące. Dodawaj konkretne wyjątki dla zweryfikowanych zależności i rejestruj istotne próby blokowanego dostępu.
- Wzmocnij tożsamości. Usuń współdzielone dane uwierzytelniające, włącz uwierzytelnianie wieloskładnikowe przy zdalnej administracji i ogranicz dostęp uprzywilejowany do ścieżki zarządzania.
- Testuj i dokumentuj. Weryfikuj zarówno dozwolone, jak i blokowane ścieżki, zapisuj wyniki oraz aktualizuj spis zasobów i reguł.
- Przeglądaj stale. Ponownie analizuj zasady po zmianach aplikacji, zmianach personelu, migracjach do innego dostawcy i incydentach bezpieczeństwa.
Celem nie jest stworzenie środowiska, w którym nic nie może się komunikować. Chodzi o to, aby każde ważne połączenie było celowe, ograniczone i możliwe do uzasadnienia. Gdy serwer zostanie przejęty, te decyzje rozstrzygają, czy incydent pozostanie ograniczony, czy przerodzi się w awarię obejmującą całą infrastrukturę.