Bezpieczne stosowanie SLES 15 STIG z OpenSCAP

Użyj obsługiwanego przez SUSE profilu DISA STIG dla SLES 15, przeskanuj serwer za pomocą OpenSCAP i podejmij działania naprawcze dopiero po sprawdzeniu stanu bazowego w systemie testowym. Wyobraź sobie fikcyjnego administratora o imieniu Alex, który przygotowuje jeden serwer SLES 15 do obsługi usługi regulowanej: Alex wykorzystuje poniższy przepływ pracy do identyfikacji ustaleń, testowania zmian i gromadzenia dowodów, ale nie traktuje czystego automatycznego skanowania jako zatwierdzenia zgodności.

Polecenia są zgodne z aktualnymi wytycznymi STIG firmy SUSE dla systemu SLES 15. Zawartość profilu może ulec zmianie wraz z aktualizacjami pakietów i wersjami testów porównawczych DISA, dlatego przed użyciem tej procedury należy sprawdzić odpowiednią wersję i wymagania systemowe. Obrazy terminala ilustrują polecenia i nie pokazują rzeczywistych wyników skanowania.

1. Potwierdź cel i aktualny punkt odniesienia

Zacznij od zarejestrowania pakietu usług SLES hosta, jego przeznaczenia, roli sieciowej i aplikacji. Alex zapisuje, które usługi muszą pozostać dostępne, w jaki sposób administratorzy się łączą oraz metodę odzyskiwania, jeśli zmiana w zabezpieczeniu zakłóci dostęp. Ten zakres ma znaczenie: host bazy danych i serwer ogólnego przeznaczenia mogą mieć różne zatwierdzone wyjątki, nawet jeśli oba korzystają z tego samego profilu STIG systemu operacyjnego.

Przed wybraniem treści sprawdź zainstalowaną wersję:

cat /etc/os-release
hostnamectl

Następnie pobierz odpowiednią listę kontrolną STIG dla SLES 15 i wersję testów porównawczych z oficjalnej strony pobierania DISA STIG . Dopasuj listę kontrolną do rodziny systemów i postępuj zgodnie z instrukcjami oceny obowiązującymi w Twojej organizacji. Dokumenty firmy SUSE obsługują profil SCAP „DISA STIG dla SUSE Linux Enterprise 15”, ale samo to nie określa, której wersji wymaga dany organ ani jakiej certyfikacji wymaga dany host.

2. Zainstaluj i zweryfikuj zawartość SCAP

W zarejestrowanym systemie SLES z dostępem do odpowiednich repozytoriów zainstaluj narzędzia wiersza poleceń OpenSCAP i zawartość Przewodnika zabezpieczeń SCAP:

sudo zypper install openscap-utils scap-security-guide

Poniższe nazwy pakietów i lokalizacja strumienia danych SLES 15 są udokumentowane w przewodniku SUSE dotyczącym zabezpieczania OpenSCAP oraz procedurze STIG . Repozytoria pakietów i wersje profili mogą się różnić w zależności od dodatku Service Pack i poziomu aktualizacji. Wypisz zainstalowane strumienie danych i sprawdź plik kandydacki, zamiast zakładać nazwę pliku lub profil:

ls -1 /usr/share/xml/scap/ssg/content/ssg-*-ds.xml
oscap info /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

Sprawdź, czy strumień danych SLES 15 jest obecny i czy lista profili zawiera plik stig. Jeśli plik lub profil brakuje, przerwij test i rozwiąż niezgodność pakietu lub repozytorium; nie zastępuj go testem porównawczym innego systemu operacyjnego.

3. Zbierz dane bazowe, a następnie przetestuj działania naprawcze

Utwórz chroniony katalog dowodów przed wygenerowaniem raportów. Najpierw przeskanuj, nie zmieniając ustawień systemowych:

sudo install -d -m 0700 /root/stig-review
sudo oscap xccdf eval \
  --profile stig \
  --results /root/stig-review/baseline.xml \
  --report /root/stig-review/baseline.html \
  /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

Otwórz raport HTML i przejrzyj każdy wynik, zwłaszcza błędy, awarie i reguły, których nie udało się sprawdzić. Zachowaj plik XML i raport jako poufny dowód konfiguracji. Mogą one ujawnić szczegóły hosta i stan zabezpieczeń, dlatego przechowuj je lub przesyłaj wyłącznie za pośrednictwem zatwierdzonych kanałów.

Następnie sklonuj lub utwórz migawkę serwera w środowisku nieprodukcyjnym. Przed zastosowaniem zautomatyzowanych zmian sprawdź działanie aplikacji, dostęp do tożsamości, sieć, monitorowanie i odzyskiwanie. SUSE ostrzega administratorów przed przetestowaniem działań naprawczych poza środowiskiem produkcyjnym, ponieważ zmieniają one konfigurację systemu. Na hoście testowym udokumentowana metoda „w locie” to:

sudo oscap xccdf eval --remediate \
  --profile stig \
  --results /root/stig-review/remediation.xml \
  /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

Wygenerowany wynik może obejmować wynik testu przed naprawą i po naprawieniu. Oznaczenie reguły fixedwskazuje, że jej automatyczna poprawka została zastosowana i przeszła pomyślnie ocenę; oznaczenie erroroznacza, że ​​naprawa dla tej reguły zakończyła się niepowodzeniem. Żaden ze statusów nie zastępuje testowania operacyjnego ani przeglądu podstawowego wymagania.

4. Przeskanuj ponownie, rozwiąż wyjątki i zachowaj dowody

Po przeanalizowaniu zachowania testu, uruchom osobne skanowanie z nowymi ścieżkami wyjściowymi. Ocena oparta wyłącznie na skanowaniu pomaga odróżnić stan bieżący od przebiegu naprawczego:

sudo oscap xccdf eval \
  --profile stig \
  --results /root/stig-review/final.xml \
  --report /root/stig-review/final.html \
  /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

Nie oczekuj, że każda reguła będzie automatycznie naprawialna. Zbadaj błędy w pełnym sprawdzaniu reguły i popraw tekst w dokładnej wersji listy kontrolnej DISA wybranej dla systemu. Niektóre reguły wymagają świadomej decyzji właściciela usługi, konfiguracji specyficznej dla danej lokalizacji lub ręcznego dowodzenia. Jeśli reguła nie ma zastosowania lub nie może być spełniona, udokumentuj uzasadnienie i mechanizmy kompensacyjne za pośrednictwem formalnego procesu obsługi wyjątków w organizacji; zmiana lub dostosowanie profilu samo w sobie nie oznacza spełnienia wymagania.

Aby zapoznać się z listą kontrolną, SUSE dokumentuje eksport pliku XCCDF, który można zaimportować do programu DISA STIG Viewer. Wygeneruj go za pomocą obsługiwanej opcji, a następnie zaimportuj do programu Viewer zgodnie z aktualnymi instrukcjami użytkownika:

sudo oscap xccdf eval \
  --profile stig \
  --stig-viewer /root/stig-review/results_stig.xml \
  /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

Pakiet dowodowy Alexa dotyczący fikcyjnego serwera zawiera dane dotyczące tożsamości hosta i Service Packa, wersji testów porównawczych, wersji zawartości SCAP, daty skanowania, raportów bazowych i końcowych, działań naprawczych, kontroli ręcznych oraz zatwierdzonych wyjątków. Potwierdź, że pliki istnieją i są dostępne do odczytu tylko dla upoważnionych recenzentów:

sudo ls -l /root/stig-review

Przed uznaniem zadania za zakończone należy sprawdzić, czy raport końcowy odzwierciedla skanowanie przeprowadzone po wprowadzeniu zmian, czy wszystkie pozostałe ustalenia mają właściciela i dyspozycję, a wymagane usługi serwera nadal działają. Zgodność ze standardem STIG to stan oceniany powiązany z konkretnym testem porównawczym i zakresem systemu; OpenSCAP wspiera tę ocenę, ale nie udziela akredytacji ani nie gwarantuje spełnienia wszystkich wymagań lokalizacji.

Źródła

• SUSE: Wzmacnianie systemu SUSE Linux Enterprise za pomocą STIG
• SUSE: Wzmocnienie SLES za pomocą OpenSCAP
• DISA: Pliki do pobrania STIG