TuxCare ELS: kontrolowane dalsze użytkowanie starszych wersji systemu Linux

Czym uzupełnia TuxCare ELS

Gdy kończy się okres regularnej konserwacji dystrybucji systemu Linux, serwer niekoniecznie będzie nadal otrzymywał aktualizacje zabezpieczeń z dotychczasowych źródeł pakietów. Stanowi to szczególny problem, gdy aplikacja specjalistyczna jest nadal powiązana ze starym środowiskiem. Rozszerzona obsługa techniczna może zapewnić czas na kontrolowane przejście na nowe środowisko, nie cofając jednocześnie zakończenia regularnego wsparcia.

TuxCare Nieograniczone wsparcie przez cały cykl życia produktu Usługa „for OS” zapewnia aktualizacje zabezpieczeń oraz wybrane poprawki błędów dla obsługiwanych starszych dystrybucji. Według producenta oferta obejmuje jądro oraz zestaw ważnych pakietów zależnych od danej dystrybucji. Nie instaluje ona nowej głównej wersji systemu Linux: serwer pozostaje na dotychczasowej wersji dystrybucji i otrzymuje dodatkową obsługę techniczną dla objętych nią komponentów.

Dla przedsiębiorstwa może to stanowić ważne rozwiązanie przejściowe: zamiast od razu przechodzić na nową wersję niekompatybilnej aplikacji, można przygotować się do migracji, instalując w międzyczasie dostępne poprawki zabezpieczeń dla obsługiwanych pakietów. Warunkiem jest jednak, aby faktycznie potrzebne pakiety, architektura i wybrana oferta były ze sobą zgodne.

Die Osłona paczki nie oznacza to jednak bezpieczeństwa całego serwera. Aplikacja zainstalowana samodzielnie, rozszerzenie lub usługa pochodząca z innego źródła pakietów może wykraczać poza zakres oferowany przez system operacyjny. Również błędy konfiguracyjne i niepotrzebnie dostępne usługi nie znikają wraz z wykupieniem subskrypcji; nadal należy je sprawdzać i zabezpieczać.

Również w przypadku obsługiwanych pakietów istotny jest poziom zagrożenia: TuxCare przewiduje poprawki bezpieczeństwa dla wysokich i krytycznych zagrożeń o wskaźniku CVSS 7 lub wyższym. W przypadku średnich zagrożeń o wskaźniku CVSS od 4,0 do 6,9, według dostawcy, poprawki są brane pod uwagę, jeśli nie są dostępne żadne środki ograniczające ryzyko i istnieje wystarczające zapotrzebowanie ze strony klientów. TuxCare zastrzega sobie ponadto prawo do zaproponowania środków ograniczających ryzyko zamiast bezpośredniej poprawki kodu. Objęcie pakietu usługą nie oznacza zatem, że każda znana luka w nim zawarta zostanie usunięta.

Dlatego decydujące znaczenie ma nie tylko to, czy dana dystrybucja znajduje się na liście obsługiwanych. W przypadku Bezpieczeństwo systemu Linux sprawdza, jakie komponenty są używane na konkretnym serwerze, czy dostępne są odpowiednie poprawki oraz czy zostały one faktycznie zainstalowane. ELS uzupełnia proces wdrażania poprawek, ale nie zastępuje ani inwentaryzacji, ani planu migracji.

Sprawdź osłonę i stan serwerów

Przed wyborem TuxCare ELS należy Wykaz serwerów. Należy podać dystrybucję oraz dokładną wersję, architekturę i aktualnie uruchomiony jądro. Należy również udokumentować skonfigurowane źródła pakietów oraz usługi dostępne publicznie lub z innych sieci. W ten sposób można porównać listę producentów z rzeczywistym systemem, zamiast po prostu zaznaczać nazwę dystrybucji.

W przypadku starszego serwera WWW w spis należy uwzględnić na przykład pakiet serwera WWW, biblioteki kryptograficzne, środowisko uruchomieniowe PHP oraz niezbędne rozszerzenia PHP. W każdym przypadku należy odnotować, skąd pochodzi dany pakiet i jaka wersja została zainstalowana. Rozszerzenie pochodzące z zewnętrznego repozytorium może podlegać innym warunkom konserwacji niż pakiet z oryginalnej dystrybucji.

Porównaj te komponenty pojedynczo z aktualną listą pakietów dla danej dystrybucji. Sprawdź również architekturę i warunki danej oferty. Obsługiwana dystrybucja nie oznacza, że każdy zainstalowany w niej pakiet lub każda wersja środowiska uruchomieniowego jest automatycznie objęta obsługą przez ELS for OS. Nawet w przypadku pakietów objętych obsługą sposób postępowania z poszczególnymi lukami w zabezpieczeniach zależy między innymi od ich poziomu zagrożenia.

Szczególnie łatwo przeoczyć programy skompilowane samodzielnie oraz oddzielnie zainstalowane środowiska uruchomieniowe. Również obraz kontenera zawiera własne komponenty: konserwacja systemu operacyjnego hosta nie gwarantuje, że pakiety w obrazie są zaktualizowane. W przypadku takich elementów potrzebujesz oddzielnego potwierdzenia oraz własnego procesu aktualizacji.

ELS dla systemu operacyjnego oraz ELS do zastosowań są to odrębne oferty. To, czy starsza wersja PHP może być obsługiwana w ramach dodatkowej oferty, zależy między innymi od wersji, formatu pakietu, architektury i sposobu pobierania. Kolejne możliwe środowisko dla starszych aplikacji PHP opisano w artykule poświęconym CloudLinux Alt-PHP i związane z nim kwestie bezpieczeństwa; w związku z tym nie obejmuje tego subskrypcja systemu operacyjnego TuxCare.

Prawidłowe klasyfikowanie terminów wsparcia

Termin zakończenia wsparcia ma znaczenie tylko w kontekście danej fazy konserwacji. Zakończenie regularnej konserwacji nie zawsze oznacza, że wszystkie płatne lub dodatkowe usługi wygasają w tym samym czasie. Dlatego przed podjęciem decyzji warto zapisać zarówno okres obowiązywania, jak i objęte nim pakiety, architektury oraz warunki umowy.

W aktualnie dostępnej dokumentacji TuxCare podano dla obsługiwanych systemów operacyjnych gwarantowany czas działania ELS wynoszący 25 lat od podanej pierwotnej daty zakończenia wsparcia. Jako przykłady podaje 30 czerwca 2049 r. dla systemu CentOS 7 oraz 31 maja 2048 r. dla systemu Ubuntu 18.04. Są to informacje dostarczone przez dostawcę dotyczące okresu wsparcia, a nie gwarancja dla każdej zainstalowanej aplikacji.

W przypadku Ubuntu 18.04 firma Canonical wyróżnia kilka etapów: standardowe wsparcie zakończyło się w maju 2023 r.; wsparcie dla Ubuntu Pro potrwa do maja 2028 r. Aktualny przegląd wskazuje, że dodatkowe wsparcie dla starszych wersji będzie dostępne do maja 2033 r. Ofert tych nie można porównywać wyłącznie na podstawie dat zakończenia wsparcia, ponieważ decydujące znaczenie mają zakres pakietów, architektura oraz warunki umowy dla konkretnego serwera.

W przypadku serwera WWW z systemem Ubuntu należy na przykład sprawdzić, czy wymagane pakiety faktycznie znajdują się w wybranej wersji aktualizacji oraz w jaki sposób aktualizacje wpisują się w istniejący proces operacyjny. Dłuższy okres nie ma większego znaczenia, jeśli krytyczny czas działania lub rozszerzenie wykracza poza uzgodniony zakres.

Wymienione terminy opierają się na dynamicznie aktualizowanych stronach internetowych producentów, zgodnie ze stanem źródeł z dnia 4 listopada 2026 r. Nie da się w każdym przypadku zweryfikować z mocą wsteczną, czy wszystkie aktualne informacje obowiązywały już w tym dniu. Dlatego przed opublikowaniem lub zawarciem umowy należy ponownie sprawdzić terminy i listy pakietów oraz przestrzegać odpowiednich Stan wypożyczeń zdecydowanie. Nawet długoterminowa obietnica wsparcia technicznego nie stanowi gwarancji całkowitego bezpieczeństwa serwera.

Praktyczne wdrożenie serwera CentOS 7

Załóżmy, że serwer WWW z systemem CentOS 7 musi tymczasowo kontynuować działanie starszej aplikacji biznesowej. Zanim TuxCare ELS Wybierając tę opcję, rejestrujesz rzeczywisty stan systemu oraz zależności aplikacji. Decydujące znaczenie ma nie tylko to, czy system CentOS 7 jest obsługiwany, ale także to, czy uwzględniono komponenty niezbędne dla danej architektury.

Poniższe polecenia można wykonać na serwerze w powłoce. Odczytują one identyfikator dystrybucji, architekturę komputera oraz wersję uruchomionego jądra; nie wprowadzają one żadnych zmian w pakietach ani źródłach pakietów. Zanotuj wyniki w spisie zasobów serwera i porównaj je z aktualną instrukcją dotyczącą systemu CentOS 7.

cat /etc/os-release
uname -m
uname -r

Uzupełnij to Wykaz serwerów skonfigurowane źródła pakietów, zainstalowane wersje pakietów oraz usługi dostępne publicznie. W przypadku serwera WWW obejmują one w szczególności pakiet serwera WWW, biblioteki kryptograficzne, środowisko uruchomieniowe PHP oraz rozszerzenia. Należy również odnotować, które komponenty pochodzą ze źródeł zewnętrznych lub zostały skompilowane samodzielnie; nie mogą one być uznane za część zakresu systemu operacyjnego bez odpowiedniej weryfikacji.

W przypadku systemu CentOS 7 firma TuxCare wymienia jako warunki wstępne ważny klucz licencyjny, uprawnienia administratora oraz połączenia HTTPS. W instrukcji uwzględniono również różnice między architekturami: w przypadku aarch64 i i686 opisano obsługę przestrzeni użytkownika, natomiast aktualizowanie jądra na żywo dotyczy wyłącznie architektury x86_64. Ograniczenie to dotyczy instrukcji dla systemu CentOS 7 i nie można go ogólnie odnosić do innych dystrybucji.

Następnie, w odniesieniu do konkretnej aplikacji, sprawdź każdy wymagany pakiet na podstawie aktualnej listy i wyjaśnij pozostałe braki z odpowiednim dostawcą. Nawet obsługiwany, aktualnie działający jądro samo w sobie nie gwarantuje ani zgodności z aplikacją, ani tego, że wszystkie dostępne aktualizacje są zainstalowane i aktywne.

Konfiguracja repozytorium i wdrażanie aktualizacji

Zaplanuj wdrożenie jako kontrolowane łańcuch kontroli: Najpierw należy upewnić się, że licencja, architektura i wymagane pakiety są zgodne. Następnie należy sprawdzić, czy serwer ma uprawnienia do łączenia się z adresami docelowymi wymaganymi przez daną dystrybucję za pośrednictwem protokołu HTTPS. Do rejestracji i konfiguracji repozytorium należy skorzystać z aktualnej, oryginalnej instrukcji przeznaczonej dla danej dystrybucji, ponieważ wymagania i adresy docelowe mogą ulec zmianie.

W przypadku systemu CentOS 7 firma TuxCare opisuje proces rejestracji systemu, dodania źródła pakietów oraz klucza PGP. Źródło to umożliwia następnie pobieranie odpowiednich pakietów, jednak nie instaluje automatycznie wszystkich dostępnych aktualizacji. Po skonfigurowaniu sprawdź, czy repozytorium zostało poprawnie zintegrowane i czy menedżer pakietów oferuje odpowiednie aktualizacje.

W planowaniu należy uwzględnić serwer proxy lub restrykcyjne reguły zapory sieciowej dotyczące ruchu wychodzącego. W przypadku większej liczby systemów, po uzgodnieniu z TuxCare, można rozważyć utworzenie lokalnego serwera lustrzanego. Nie należy ślepo przejmować adresów docelowych z ogólnego FAQ: przed zatwierdzeniem należy je porównać z aktualną instrukcją dla wybranej dystrybucji oraz przewidzianą ścieżką operacyjną.

Najpierw przetestuj dostępne aktualizacje w środowisku testowym, które jest jak najbardziej zbliżone do środowiska aplikacji biznesowej. Sprawdź przy tym ich uruchamianie, kluczowe procesy biznesowe oraz interfejsy. Następnie należy uzyskać zgodę na wdrożenie operacyjne i zainstalować aktualizacje w systemie produkcyjnym; należy udokumentować wersje pakietów, datę i wynik, zamiast traktować samą pomyślną aktywację w repozytorium jako zakończenie procesu.

Jeśli oczekiwana aktualizacja nie jest jeszcze dostępna, sprawdź również Status wdrożenia. W przypadku wielu platform firma TuxCare udostępnia aktualizacje stopniowo; po opublikowaniu w stabilnym repozytorium może to potrwać do 14 dodatkowych dni. W razie potrzeby dostawca opisuje obejście: należy z niego korzystać wyłącznie zgodnie z aktualną instrukcją dla danej dystrybucji i konkretnej wersji, a także po uzyskaniu zgody działu operacyjnego. Czas wdrażania nie oznacza gwarantowanego całkowitego terminu udostępnienia poprawki.

Ponadto należy zapewnić sobie plan awaryjny oraz odpowiedni czas na konserwację. Klucze licencyjne nie powinny pojawiać się w opublikowanych przykładowych poleceniach, zgłoszeniach ani niezabezpieczonych logach. W celu przeprowadzenia rejestracji należy postępować zgodnie z aktualną instrukcją producenta, a dane dostępowe udostępniać wyłącznie za pomocą przewidzianych do tego celów procedur.

Porównanie alternatywnych metod konserwacji

Wybór między usługą TuxCare ELS a rozszerzoną obsługą serwisową producenta zależy od faktycznego zestawu pakietów oraz warunków umowy. Tabela zawiera przykłady wstępnego wyboru, a nie ogólne zobowiązanie dotyczące każdej architektury lub każdego pakietu. Dane w tabeli odnoszą się do stanu na dzień 4 listopada 2026 r.; dynamiczne informacje od producentów oraz listy pakietów należy ponownie sprawdzić przed publikacją.

W przypadku Ubuntu 18.04 standardowe wsparcie zakończyło się w maju 2023 r. Firma Canonical podaje, że wsparcie dla Ubuntu Pro będzie dostępne do maja 2028 r., a w swoim aktualnym zestawieniu dotyczącym dodatkowego wsparcia dla starszych wersji – do maja 2033 r. TuxCare podaje obecnie 31 maja 2048 r. jako datę zakończenia wsparcia ELS dla systemu Ubuntu 18.04. Dane te odnoszą się do różnych ofert; późniejsza data zakończenia nie oznacza automatycznie odpowiedniego zakresu wsparcia w ramach pakietu.

Dlatego porównaj Zakres konserwacji dla każdego wymaganego pakietu oraz faktycznie zastosowanej architektury. W przypadku systemu Ubuntu istotne znaczenie mają w szczególności komponenty Main i Universe, a także warunki dotyczące wersji Pro oraz ewentualnego dodatku Legacy. Należy również ustalić, w jaki sposób można zweryfikować dostępność poprawek CVE oraz czy istniejące procesy zatwierdzania i aktualizacji są dostosowane do oferty.

W obu przykładach cel migracji pozostaje decyzją planistyczną, a nie elementem umowy serwisowej. Jeśli aplikacja biznesowa nie działa jeszcze na obsługiwanej platformie, odpowiednia alternatywa w zakresie konserwacji może zapewnić czas na przeprowadzenie testów. Jeśli żadna z ofert nie uwzględnia krytycznej zależności, lukę tę należy rozpatrywać oddzielnie, zanim dalsza eksploatacja będzie mogła być uznana za odpowiedzialną.

Sprawdź zgłoszenia CVE i backporty

Jeśli po aktualizacji skaner nadal sygnalizuje lukę w zabezpieczeniach, najpierw sprawdź dokładną dystrybucję i wersję, a także nazwę, architekturę oraz zainstalowaną wersję danego pakietu. Sprawdź również, z jakiego źródła pochodzi ten pakiet. Wyniku dotyczącego pakietu dystrybucyjnego nie można bez dalszej analizy odnieść do aplikacji skompilowanej samodzielnie lub pakietu pochodzącego z zewnętrznego repozytorium.

Przyczyną pozornych sprzeczności może być Backport : Polega to na wprowadzeniu poprawki bezpieczeństwa do starszej wersji, mimo że widoczny numer wersji źródłowej nie odpowiada najnowszej publikacji. Sam starszy numer wersji nie świadczy zatem ani o tym, że pakiet jest podatny na atak, ani o tym, że komunikat skanera musi być błędny.

Porównaj konkretny identyfikator CVE i wersję zainstalowanego pakietu z informacjami dotyczącymi Twojej dystrybucji w narzędziu TuxCare CVE Tracker. Oznaczenie „In Testing“ oznacza, że poprawka jest nadal testowana; w przypadku „In Rollout“ jest ona dystrybuowana za pośrednictwem repozytoriów Rollout. Natomiast oznaczenie „Released“ oznacza pełne udostępnienie dla wszystkich użytkowników. Nawet wtedy musisz sprawdzić, czy rzeczywiście zainstalowano odpowiednią wersję; oznaczenie „Not Vulnerable“ oznacza, że wersja TuxCare nie jest narażona na tę lukę.

Jeśli w menedżerze pakietów brakuje oczekiwanej aktualizacji, sprawdź, oprócz źródła pakietu i wersji, również Status wdrożenia. W przypadku wielu platform stopniowe wdrażanie po opublikowaniu w stabilnym repozytorium może potrwać do 14 dodatkowych dni. Ewentualne obejście można uwzględnić w procesie wyłącznie zgodnie z aktualnymi, oryginalnymi wytycznymi dotyczącymi dystrybucji i wydania oraz po uzyskaniu zgody operacyjnej; nie gwarantuje to jednak całkowitego terminu wdrożenia poprawki.

Następnie przeanalizuj bazę danych i wyniki skanera. TuxCare udostępnia dane OVAL dla szeregu produktów ELS; musisz samodzielnie sprawdzić, czy Twoje narzędzie wykorzystuje dane odpowiednie dla konkretnego systemu i czy je poprawnie interpretuje. Udokumentuj wersję pakietu, status CVE oraz czas skanowania. Jeśli wynik porównania pozostaje niejasny, potraktuj ten wynik jako otwarty i wyjaśnij go z odpowiednimi jednostkami specjalistycznymi lub dostawcą.

Planowanie trybu pracy z poprawkami i ponownych uruchomień

Utworzenie repozytorium to dopiero początek procesu instalowania poprawek, a nie jego zakończenie. Należy określić, kto będzie regularnie sprawdzał dostępność aktualizacji, kto będzie udzielał zgody na ich instalację oraz w jaki sposób będą wykrywane nieudane aktualizacje. Należy przy tym porównać faktycznie zainstalowane wersje pakietów z dostępnymi aktualizacjami i odnotować rozbieżności dla każdego systemu.

W miarę możliwości najpierw przetestuj aktualizacje na podobnym systemie testowym z tą samą aplikacją i odpowiednimi źródłami pakietów. Sprawdź tam w szczególności uruchamianie, logowanie oraz kluczowe interfejsy aplikacji biznesowej. Dopiero po zatwierdzeniu przez dział operacyjny należy przeprowadzić kontrolowane wdrożenie pakietów; wynik oraz ewentualne błędy należy odnotować w protokole instalacji.

Zaplanuj też wprowadzenie zmian Okno konserwacji. Nawet po pomyślnej aktualizacji pakietów uruchomione procesy mogą nadal korzystać ze starych bibliotek, dopóki nie zostaną ponownie uruchomione. W razie potrzeby konieczne może być również ponowne uruchomienie aplikacji; w przypadku zmian w jądrze może być konieczne ponowne uruchomienie systemu. Po ponownym uruchomieniu sprawdź zarówno działanie usług, jak i oczekiwany stan pakietów oraz systemu.

KernelCare Live Patching jest produktem uzupełniającym i należy go odróżnić od regularnych aktualizacji pakietów ELS. Umożliwia on wdrażanie obsługiwanych poprawek jądra podczas pracy systemu, ale nie zastępuje ani wszystkich aktualizacji, ani każdego ponownego uruchomienia usługi lub systemu. Sprawdź produkt, dystrybucję i architekturę: w przypadku systemu CentOS 7 firma TuxCare dokumentuje funkcję Kernel Live Patching wyłącznie dla architektury x86_64. Dalsze podstawowe informacje wyjaśniono w artykule poświęconym KernelCare Patch Feed.

Wydanie uname -r pokazuje aktualnie działające jądro, ale nie przedstawia pełnego stanu aktualizacji serwera. Na przykład zainstalowany pakiet jądra może zacząć działać dopiero po ponownym uruchomieniu systemu; z drugiej strony wynik nie zawiera informacji o tym, czy biblioteki i aplikacje zostały zaktualizowane i ponownie uruchomione.

Wybierz rozwiązanie tymczasowe lub migrację

To, czy TuxCare ELS jest wystarczające dla konkretnego serwera, zależy od jego rzeczywistych komponentów i zagrożeń. Porównaj wymagane pakiety z dostępnym zakresem ochrony i zidentyfikuj luki w zabezpieczeniach aplikacji, środowisk uruchomieniowych i oprogramowania zewnętrznego. ELS for OS obejmuje wybór zależny od dystrybucji; wsparcie dla systemu operacyjnego nie oznacza konserwacji każdej aplikacji działającej w tym systemie.

Sprawdź również pozostałe luki CVE w ramach objętych poprawkami pakietów. Zgodnie z wytycznymi TuxCare średnie poziomy ryzyka są brane pod uwagę przy wydawaniu poprawki tylko pod dodatkowymi warunkami; ponadto dostawca może przewidzieć środek ograniczający ryzyko zamiast bezpośredniej korekty kodu. Dlatego w odniesieniu do konkretnej luki należy ocenić, czy dostępna jest poprawka lub środek ograniczający ryzyko oraz czy pozostałe ryzyko jest akceptowalne dla Twojej działalności.

Rozwiązanie przejściowe może być sensowne, jeśli aplikacja specjalistyczna jest na razie powiązana ze starą platformą, a pozostałe ryzyka są możliwe do opanowania. Należy jednak również porównać dostępne opcje wsparcia technicznego oferowanego przez producenta: w przypadku systemu Ubuntu 18.04, w zależności od wymaganych funkcji, jako alternatywy można rozważyć Ubuntu Pro oraz, w razie potrzeby, dodatek Legacy. Należy sprawdzić pakiety, architekturę i warunki umowy, a nie tylko datę wygaśnięcia wsparcia.

W przypadku usługi dostępnej publicznie, której aplikacja nie jest odpowiednio utrzymywana lub której okres działania nie jest objęty wsparciem, sam system ELS może okazać się niewystarczający. Należy zatem ograniczyć dostęp do sieci i usług, które są faktycznie potrzebne, usunąć zbędne uprawnienia oraz kontrolować dostępy administracyjne. Te Ograniczenie sieciowe zmniejsza powierzchnię ataku, ale nie zastępuje brakujących aktualizacji zabezpieczeń.

Ogranicz czas trwania dalszej eksploatacji i określ cel migracji wraz z osobami odpowiedzialnymi oraz terminem, który można zweryfikować. Zaplanuj testy aplikacji na platformie docelowej, przeniesienie danych oraz sprawdzenie wszystkich istotnych interfejsów. Plan awaryjny powinien określać, w jakich warunkach należy przerwać migrację i w jaki sposób powrócić do dotychczasowego trybu pracy.

Należy regularnie weryfikować plan pod kątem nowych luk w pakietach, zmienionych zależności od producentów oraz nakładów operacyjnych. Jeśli wymagane komponenty nie podlegają już konserwacji lub nie da się w wystarczającym stopniu ograniczyć niezbędnego dostępu, samo przedłużenie konserwacji systemu operacyjnego może okazać się niewystarczające. Wówczas należy ponownie rozważyć migrację, wymianę aplikacji lub kontrolowane wycofanie z eksploatacji.