Spis treści
Wdrożenie architektury Zero Trust nie powinno kończyć się na kontroli dostępu do aplikacji, sieci czy kont użytkowników. W przypadku serwera fizycznego, zabezpieczenia trzeba budować od najniższej warstwy, a więc poczynając od firmware’u, BIOS/UEFI i procesu uruchamiania, przez TPM i Secure Boot, aż po system operacyjny oraz konta administratorów. Takie podejście ogranicza ryzyko wystąpienia problemu kompromitacji urządzenia i pozwala wykrywać nieautoryzowane zmiany również wtedy, gdy problem leży w warstwie poniżej systemu operacyjnego. Z tego artykułu dowiesz się, jak krok po kroku wdrożyć zasady Zero Trust na serwerze dedykowanym lub kolokowanym np. w naszym sprawdzonym polskim centrum danych Sprint Data Center. Dowiesz się z niego także, jak zabezpieczyć BIOS/UEFI, BMC i system oraz jak później zweryfikować stan całej platformy.
O co chodzi w architekturze Zero Trust na poziomie sprzętowym?
Architektura Zero Trust opiera się na trzech podstawowych zasadach – weryfikowaniu dostępu w sposób jawny, stosowaniu minimalnych uprawnień i zakładaniu, że zabezpieczenia zawsze mogą zostać przełamane. Nie jest to więc gotowe rozwiązanie, a standard projektowania całego środowiska IT.
W przypadku fizycznego serwera dedykowanego oznacza to między innymi, że nie można automatycznie uznać sprzętu za zaufany tylko dlatego, że znajduje się w chronionej serwerowni. Trzeba kontrolować konfigurację BIOS/UEFI, aktualność i pochodzenie firmware’u oraz proces uruchamiania systemu. Równie ważne są klucze wykorzystywane przez Secure Boot, stan TPM, dostęp do BMC/IPMI, konta administracyjne oraz fizyczny dostęp do urządzenia. Celem nie jest wyeliminowanie każdego potencjalnego zagrożenia, lecz stworzenie kilku niezależnych punktów kontroli, które utrudniają przejęcie serwera i ograniczają skutki ewentualnego ataku.
Łańcuch zaufania dla procesu startu systemu
Serwer powinien być uruchamiany według określonej sekwencji. Najpierw inicjalizowany jest sprzęt i firmware, następnie UEFI oraz program rozruchowy, a później system operacyjny. Jeżeli któryś z wcześniejszych elementów zostanie zmodyfikowany, może wpłynąć na bezpieczeństwo kolejnych warstw. Dlatego warto budować łańcuch zaufania, w którym każdy kolejny etap jest weryfikowany przez poprzedni. Secure Boot sprawdza podpis cyfrowy programu rozruchowego i pozwala uruchomić tylko oprogramowanie spełniające określone kryteria zaufania.
W praktyce administrator powinien więc przeprowadzić kilka poniższych kroków.
- Ustalić, jaki tryb uruchamiania obsługuje serwer.
- Skonfigurować UEFI i wyłączyć niepotrzebną zgodność ze starszym trybem uruchamiania.
- Aktywować Secure Boot.
- Zweryfikować bazę zaufanych kluczy.
- Sprawdzić, czy system uruchamia się wyłącznie z zatwierdzonych nośników.
- Udokumentować konfigurację przed przekazaniem serwera do eksploatacji.
Model zagrożeń dla serwera – czym jest i co powinien uwzględniać?
Bez dobrze opracowanego modelu zagrożeń trudno określić, które zabezpieczenia są rzeczywiście potrzebne. W przypadku serwera dedykowanego lub kolokowanego trzeba uwzględnić w nim ataki na kilka różnych warstw.
Pierwsza z nich to BIOS/UEFI i firmware. Nieautoryzowana modyfikacja firmware’u jest szczególnie niebezpieczna, ponieważ kod działa na bardzo uprzywilejowanym poziomie. Dlatego często wskazuje się trzy podstawowe obszary odporności platformy – ochronę przed zmianami, wykrywanie naruszeń oraz bezpieczne odtworzenie prawidłowego stanu.
Kolejna warstwa to łańcuch dostaw. Zagrożenie może pojawić się jeszcze przed instalacją serwera. Dlatego przy zakupie serwera dedykowanego warto znać producenta, dokładny model platformy, wersję firmware’u oraz źródło aktualizacji.
Ostatnim elementem, który należy brać pod uwagę w modelu zagrożeń, jest BMC/IPMI. Kontroler zarządzania poza systemem operacyjnym zapewnia szerokie możliwości administracyjne. Jego przejęcie może dać atakującemu dostęp do konsoli, zasilania czy konfiguracji urządzenia niezależnie od stanu systemu operacyjnego.
Ryzyka fizyczne pojawiające się w kolokacji serwerów
W przypadku infrastruktury umieszczonej poza własną siedzibą trzeba uwzględnić również dostęp fizyczny. Związane z tym ryzyka to m.in. możliwość manipulacji przy przewodach, nośnikach, urządzeniach peryferyjnych czy samym serwerze. Dlatego kolokacja serwerów powinna być realizowana w sprawdzonych centrach danych, cieszących się doskonałą opinią. Zyskasz najwyższy poziom bezpieczeństwa w tym zakresie, jeśli zdecydujesz się na współpracę z naszą firmą Sprint Data Center. Mamy ogromne doświadczenia w branży i stosujemy najnowocześniejsze rozwiązania gwarantujące wysoki poziom ochrony kolokowanych maszyn.
Zabezpieczenie BIOS/UEFI – instrukcja krok po kroku
Konfigurację najlepiej rozpocząć od zapisania aktualnych ustawień. Dzięki temu można później porównać stan urządzenia i zwiększyć swoje możliwości na wykrycie nieoczekiwanych zmian.
Następnie należy zrealizować następujące kroki.
- Zaktualizować BIOS/UEFI do najnowszej zatwierdzonej wersji.
- Ustawić hasło administratora firmware’u.
- Ograniczyć możliwość uruchamiania z urządzeń zewnętrznych.
- Wyłączyć nieużywane interfejsy i funkcje.
- Ograniczyć możliwość zmiany ustawień przez nieuprawnionych użytkowników.
- Włączyć Secure Boot.
- Zweryfikować kolejność urządzeń startowych.
- Zapisać konfigurację jako wzorzec dla kolejnych serwerów.
Nie należy jednak wyłączać funkcji sprzętowych bez sprawdzenia ich wpływu na środowisko. Przykładowo opcja potrzebna do zdalnego zarządzania, wirtualizacji lub monitorowania może być wymagana przez konkretną platformę. Aktualizacje firmware’u powinny pochodzić ze sprawdzonego źródła i być weryfikowane pod względem autentyczności.
Secure Boot i zarządzanie kluczami
Secure Boot chroni proces uruchamiania przed wykonaniem niezatwierdzonego programu rozruchowego. Samo włączenie tej funkcji nie kończy jednak konfiguracji. Administrator powinien sprawdzić, czy Secure Boot jest rzeczywiście aktywny, jakie certyfikaty znajdują się w bazie zaufania, czy klucze odpowiadają przyjętemu modelowi zarządzania, kto może zmieniać ustawienia Secure Boot oraz jak wygląda procedura wymiany lub unieważnienia kluczy.
Szczególnej uwagi wymagają serwery z niestandardowym systemem operacyjnym lub własnym programem rozruchowym. Przed aktywacją Secure Boot trzeba potwierdzić zgodność całego procesu startowego, aby zabezpieczenie nie uniemożliwiło uruchomienia wymaganych komponentów.
TPM, Measured Boot oraz zabezpieczenie BMC i OOB
TPM może przechowywać klucze kryptograficzne i rejestrować pomiary elementów procesu uruchamiania. Mechanizm Measured Boot wykorzystuje to do zapisywania pomiarów firmware’u, programu rozruchowego i kolejnych elementów startowych. Dane te mogą następnie służyć do oceny, czy proces uruchamiania odpowiada oczekiwanemu stanowi. W praktyce warto aktywować TPM, jeśli platforma i system go obsługują, a następnie zabezpieczyć jego ustawienia przed nieautoryzowaną zmianą.
Osobnej ochrony wymaga BMC, czyli kontroler zarządzania płytą główną. Dostęp do niego powinien być ograniczony do wydzielonej sieci administracyjnej, najlepiej bez bezpośredniej ekspozycji na połączenie internetowe. Należy również wyłączyć nieużywane protokoły, usunąć domyślne konta i stosować silne uwierzytelnianie.
Z kolei interfejs OOB (Out-of-Band) powinien być traktowany jako niezależna ścieżka administracyjna, a nie zwykły element sieci serwerowej. Jeżeli jego przejęcie pozwala na zdalne sterowanie sprzętem, musi podlegać co najmniej takim samym zasadom kontroli jak dostęp do systemu operacyjnego.
Zabezpieczenie systemu i dostępów administratora
Zabezpieczenie firmware’u nie ma większego sensu, jeśli system operacyjny pozostaje otwarty dla niekontrolowanych kont administracyjnych. Po jego instalacji należy więc wgrać wszystkie aktualizacje bezpieczeństwa, usunąć niepotrzebne usługi i ograniczyć otwarte porty. Nieużywane konta muszą zostać wyłączone, a administratorzy powinni korzystać z indywidualnych kont. Tam, gdzie jest to dostępne, warto wymagać wieloskładnikowego uwierzytelniania, ograniczyć uprawnienia zgodnie z zasadą najmniejszych przywilejów oraz rejestrować działania administracyjne.
Dostęp uprzywilejowany powinien być przyznawany tylko na czas potrzebny do wykonania konkretnego zadania. W przypadku administracji zdalnej warto dodatkowo wymagać dostępu przez kontrolowaną sieć zarządzającą i ograniczać źródłowe adresy administracyjne. Zasada minimalnych uprawnień jest jednym z podstawowych założeń architektury Zero Trust, gdyż ma ograniczać skutki przejęcia konta.
Weryfikacja i audyt konfiguracji po wdrożeniu – o czym należy pamiętać?
Po wdrożeniu zabezpieczeń trzeba sprawdzić, czy faktycznie spełniają one swoje funkcje. Sama obecność odpowiednich ustawień w dokumentacji nie jest bowiem dowodem ich skuteczności.
Audyt wdrożonych zabezpieczeń powinien obejmować przede wszystkim:
- sprawdzenie stanu Secure Boot,
- porównanie wersji BIOS/UEFI i firmware’u z zatwierdzonym wzorcem,
- weryfikację konfiguracji TPM,
- przegląd kont użytkowników,
- sprawdzenie reguł dostępu administracyjnego,
- testy reakcji systemu na korzystanie z niedozwolonych nośników pamięci,
- kontrolę aktywnych usług i portów,
- porównanie konfiguracji z ustalonym standardem.
Warto stworzyć wzorzec konfiguracji serwera, który będzie punktem odniesienia dla kolejnych urządzeń. Pozwala to automatyzować część kontroli i szybciej wykrywać odstępstwa.
Atestacja serwera dedykowanego – praktyczne wskazówki
Atestacja ma potwierdzić, że urządzenie znajduje się w stanie zgodnym z przyjętą polityką bezpieczeństwa. W najprostszym wariancie może obejmować ręczne porównanie konfiguracji z zatwierdzonym wzorcem. Bardziej zaawansowane środowiska często wykorzystują pomiary rozruchu i zdalną ocenę stanu urządzenia.
Ważne jest jednak rozróżnienie między sprawdzeniem konfiguracji a dowodem integralności całej platformy. Odczyt ustawień BIOS/UEFI nie potwierdza automatycznie, że każdy element firmware’u jest autentyczny. Dlatego kontrola powinna obejmować również wersje oprogramowania układowego, źródło aktualizacji oraz wyniki pomiarów związanych z procesem startowym.
Dla środowiska produkcyjnego warto utrzymywać dokumentację zawierającą między innymi model i numer seryjny serwera, wersje BIOS/UEFI i firmware’u, konfigurację Secure Boot, stan TPM, ustawienia BMC, listę kont uprzywilejowanych, zatwierdzony obraz systemu, datę ostatniej kontroli oraz wyniki testów i odchyleń.
Oczywiście we wszystkim tym najważniejsze jest to, aby serwery dedykowane umieścić w sprawdzonym Data Center, które stosuje najnowsze rozwiązania z zakresu bezpieczeństwa i nieustannie je rozwija. To jedna z korzyści współpracy z naszą firmą Sprint Data Center – skontaktuj się z nami i poznaj szczegóły oferty. Zajmujemy się nie tylko kolokacją, dysponując nowoczesną infrastrukturą IT, ale także sprzedażą profesjonalnych serwerów dedykowanych w wielu konfiguracjach.
FAQ – odpowiedzi na często zadawane pytania
1. Czy architekturę Zero Trust można wdrożyć na pojedynczym serwerze?
Tak, można przygotować wzorcową konfigurację jednego serwera, zabezpieczyć jego firmware, proces uruchamiania, system i dostęp administracyjny. Oczywiście można następnie wykorzystać ją jako standard dla konfiguracji kolejnych urządzeń.
2. Czy Secure Boot chroni przed wszystkimi atakami na firmware?
Nie. Secure Boot przede wszystkim kontroluje możliwość uruchomienia zatwierdzonego oprogramowania w procesie startowym. Nie zastępuje ochrony BIOS/UEFI, aktualizacji firmware’u, zabezpieczenia BMC ani monitorowania zmian w platformie.
3. Czy TPM jest konieczny do wdrożenia standardów Zero Trust?
Nie w każdym przypadku. TPM jest jednak bardzo przydatny do przechowywania kluczy i pomiarów związanych z procesem uruchamiania. Jego wykorzystanie zwiększa możliwości weryfikacji stanu platformy, szczególnie w połączeniu z Measured Boot.
4. Jak często należy przeprowadzać audyt konfiguracji serwera?
Częstotliwość powinna wynikać z poziomu ryzyka i wymagań organizacji. Kontrolę warto wykonywać po zmianach firmware’u, BIOS/UEFI, systemu lub konfiguracji BMC, a także cyklicznie w ramach utrzymania zgodności ze wzorcem bezpieczeństwa.