Artykuł jest częścią serii opracowań zagadnień obowiązujących na egzaminie CompTIA Security+ SY0-701. Zapisz się na newsletter, jeżeli nie chcesz przegapić kolejnych publikacji.
W poprzedniej publikacji omówiliśmy procesy zarządzania zmianami z biznesowego punktu widzenia. Jednakże samo wdrożenie zmian leży w gestii zespołów technicznych, które wiedzą (a przynajmniej powinny) w jaki sposób to uczynić. W zależności od tego, co dokładnie należy zrobić, operacja może być technicznie prosta (np. niewielka aktualizacja systemu na jednym z serwerów), ale może też być bardzo złożona, szczególnie jeżeli dotyczy dużej liczby urządzeń i systemów działających w danej organizacji, np. zainstalowanie systemu EDR (Endpoint Detection and Response) na wszystkich stacjach roboczych należących do firmy.
Mówiąc krótko: biznes decyduje co, kiedy i dlaczego należy zmienić, ale to pracownicy techniczni przeprowadzają samą operację.
Kwestie techniczne, które warto wziąć pod uwagę podczas analizy zgłoszenia zmiany:
- Jakie zmiany konfiguracyjne należy wprowadzić w stosowanych środkach bezpieczeństwa (np. w ustawieniach firewalla)?
- Czy podczas wdrożenia należy ograniczyć działanie bądź całkowicie wyłączyć określone usługi, aplikacje lub zaprzestać wybranych działań pracowników?
- Czy wdrożenie wiąże się z niedostępnością wybranych usług?
- Czy wdrożenie będzie wymagało ponownego uruchomienia aplikacji, usług bądź całych systemów?
- Czy zmiana dotyczy starych aplikacji, które nie są już rozwijane?
- Czy w zgłoszeniu wprowadzenia zmiany uwzględniono wszystkie zależności?
Allow lists/deny lists
Jedną z częstych operacji jest przydzielanie bądź odbieranie dostępu lub uprawnień wybranym aplikacjom, usługom czy też użytkownikom. W tym celu wykorzystuje się listy dostępu (ang. allow lists) i/lub listy blokujące (ang. black lists, deny lists, block lists).
Listy są ogólnym konceptem, którego implementacja zależy od tego, co dokładnie konfigurujemy. Inaczej działają listy na poziomie firewalla, a jeszcze inaczej listy uprawnień użytkowników systemu operacyjnego, ale ogólna idea jest taka sama:
- Allow list – jak sama nazwa wskazuje, wszystko, co znajduje się na tej liście, jest dozwolone (np. tylko aplikacje znajdujące się na danej liście mogą zostać uruchomione w danym systemie). Wykorzystanie tzw. białej listy jest teoretycznie najbezpieczniejszym, ale również najbardziej restrykcyjnym podejściem, ponieważ jeśli czegoś nie ma na tej liście, jest w domyśle zablokowane lub niedozwolone.
- Deny list – nazywana również czarną listą (tutaj warto zaznaczyć, iż ten termin figuruje w Wikipedii, ale osobiście rzadko spotykam się z jego praktycznym użyciem). Wszystko, co znajduje się na tej liście, jest z kolei zablokowane bądź niedozwolone. W tym przypadku mamy do czynienia z luźniejszym podejściem, ponieważ w domyśle wszystko, co nie jest zabronione, jest dozwolone. Tę praktykę często stosuje się w oprogramowaniu typu anti-malware – jeżeli program nie wygląda podejrzanie (tj. nie znaleziono odpowiednich sygnatur w bazie danych), to może zostać uruchomiony.
Restricted activities
Zakres wszystkich planowanych zmian powinien zostać udokumentowany oraz zatwierdzony przez radę ds. zarządzania zmianą (change control board) i zespół odpowiedzialny za wdrożenie powinien się tego trzymać. Na przykład, jeżeli celem jest jedynie aktualizacja aplikacji klienckich firmowego systemu fakturowego, to w ramach zaplanowanych prac nie powinniśmy dodatkowo instalować poprawek systemu operacyjnego, jeżeli te nie są wymagane do realizacji planu.
**W wyjątkowych sytuacjach, kiedy osiągnięcie celu wdrożenia wymaga dodatkowych czynności, które nie zostały przewidziane przed zgłoszeniem planowanych zmian do akceptacji, zespół może wprowadzić dodatkowe, niezbędne modyfikacje.
Jednakże jest to zależne od aktualnie obowiązującej polityki oraz złożoności nadplanowych zmian, które mogą być na tyle poważne, iż czasami rozsądniej jest anulować bieżący proces wdrażania i zaplanować nowy. Procedury postępowania w takich sytuacjach również powinny zostać prawidłowo udokumentowane.
Downtime
Może się zdarzyć, iż wdrażanie zmian, szczególnie tych poważniejszych, wiąże się z tymczasową niedostępnością działania (ang. downtime) sieci, systemów, usług bądź aplikacji. Właśnie z tego względu ustala się wcześniej okna serwisowe (ang. maintenance windows) w okresach, kiedy przerwy w działaniu będą najmniej uciążliwe dla wszystkich zainteresowanych.
W środowiskach wymagających wysokiej dostępności (ang. high availability), w których usługi powinny być dostępne przez 24 godziny na dobę, przez 7 dni w tygodniu, jest to szczególne wyzwanie. W takim przypadku stosuje się podejście zero downtime, czyli wszelkiego rodzaju techniki umożliwiające wdrażanie zmian bez jakichkolwiek przerw w dostępie do usług.
Przykładem może być posiadanie dwóch instancji tej samej usługi, pomiędzy którymi można się gwałtownie przełączyć. Najpierw modyfikujemy jedną instancję, a w tym czasie użytkownicy cały czas korzystają z drugiej instancji. Kiedy proces wdrożenia się skończy i upewnimy się, iż wszystko działa jak należy, przekierowujemy ruch na zaktualizowaną kopię. Teraz możemy bezpiecznie i w spokoju wprowadzić niezbędne zmiany w pozostałych instancjach.
Czasami okres niedostępności może nastąpić przez przypadek, wskutek nieprzewidzianych komplikacji podczas procesu wdrażania zmian. Zawsze należy brać pod uwagę ryzyko wystąpienia takiego scenariusza już na etapie planowania, zanim zapadnie decyzja o akceptacji.
Niezależnie od tego, czy przerwy w dostępie są planowane, czy ryzyko ich wystąpienia jest minimalne, wszyscy interesariusze (ang. stakeholders) powinni zostać o tym wcześniej powiadomieni za pośrednictwem oficjalnych kanałów komunikacyjnych.
Service restart
Często, po wdrożeniu zmian, wymagane jest ponowne uruchomienie usługi (ang. service), aby modyfikacje przyniosły oczekiwany efekt. W skrajnych przypadkach może być konieczny restart całego systemu operacyjnego (ang. reboot), a tym samym – wszystkich działających na nim usług.
Usługi są specjalnymi aplikacjami działającymi w tle, bez widocznego interfejsu użytkownika. W systemach Linux takie aplikacje nazywane są również demonami (ang. daemon).
Proces ponownego uruchomienia usługi lub demona może trwać od kilku sekund do kilku minut, w zależności od operacji wykonywanych podczas startu danej usługi bądź wymaganych zależności (np. do uruchomienia jednej usługi wymagane jest działanie innej).
Ponowne uruchomienie usług pozwala również zweryfikować, czy proces ich startu przebiega poprawnie po wprowadzeniu najnowszych zmian. Dzięki temu upewnimy się, iż po niespodziewanym restarcie całego serwera system wraz z usługami wróci do pożądanego stanu.
Application restart
Oprócz wspomnianych wyżej usług działających w tle, zmiany mogą zostać wprowadzone w zwyczajnych aplikacjach (webowych, desktopowych, mobilnych), z których na co dzień korzystają użytkownicy.
Aktualizacja kodu aplikacji również może wymagać jej ponownego uruchomienia – w takim przypadku użytkownicy korzystający z aplikacji zostaną automatycznie wylogowani i będą zmuszeni do ponownego zalogowania się. W związku z tym konieczne jest zadbanie o to, żeby wszyscy użytkownicy byli świadomi odbywających się prac serwisowych i mogli wcześniej zapisać efekty swojej pracy.
Legacy applications
Termin legacy, w dosłownym tłumaczeniu, oznacza dziedzictwo, spuściznę, spadek. Legacy application oznacza starą aplikację, która nie jest już w żaden sposób rozwijana, ale dalej spełnia swoje zadanie, a zastąpienie jej nową technologią jest często nieopłacalne. Przymiotnikiem legacy można określić również system złożony z wielu aplikacji, który jest już tylko utrzymywany.
Zdarza się, iż w organizacji nie ma już choćby osób, które pracowały nad takimi aplikacjami. Częstą przypadłością jest też brak dokumentacji technicznej, więc utrzymanie starych rozwiązań sprowadza się do podejścia: jak działa, to nie ruszamy.
Mimo wszystko przychodzi taki moment, iż jednak trzeba wprowadzić pewne modyfikacje i aktualizacje, żeby aplikacja mogła dalej działać. W takim przypadku, jeżeli w organizacji nie ma już osób z odpowiednią wiedzą, najrozsądniejszym wyjściem powinno być poznanie niuansów starego rozwiązania (mówiąc wprost: nauczenie się, jak działa) oraz przygotowanie solidnej dokumentacji, aby nie powtórzyła się sytuacja, w której z firmy odchodzi ostatni wtajemniczony deweloper.
Należy pamiętać, iż w przypadku starych rozwiązań, które nie spełniają standardów aktualnie obowiązujących w organizacji (np. aplikacja została stworzona w nieużywanej już technologii), może być konieczne wypracowanie nowych, dedykowanych procedur zarządzania zmianami.
Dependencies
W przypadku złożonych systemów niejednokrotnie natkniemy się na zależności (ang. dependencies), które powodują, iż trudno jest aktualizować lub modyfikować poszczególne komponenty niezależnie. Może to znacznie utrudnić proces zarządzania zmianą, jak i samo wdrożenie – trzeba bowiem wziąć pod uwagę konieczność wprowadzenia zmian w kilku miejscach i to w odpowiedniej kolejności.
Weźmy pod uwagę przykładowy scenariusz, który zdarza się dosyć często w praktyce: w aktualnie wykorzystywanej przez nas wersji biblioteki programistycznej wykryto poważną lukę bezpieczeństwa. Trzeba więc jak najszybciej podbić wersję biblioteki we wszystkich aplikacjach i usługach działających w organizacji. Niestety, okazało się, iż najnowsza wersja nie współpracuje już z wersją języka programowania zainstalowaną w tej chwili na serwerach organizacji. Jakby tego było mało, żeby zaktualizować wersję języka programowania, konieczna jest aktualizacja systemu operacyjnego.
Jak widać, pozornie niewielka zmiana (aktualizacja biblioteki), ze względu na istniejące zależności, spowodowała, iż musimy wziąć pod uwagę wiele różnych aspektów podczas wdrożenia aktualizacji.
Nieocenioną pomocą przy identyfikowaniu zależności jest posiadanie tzw. listy SBOM (Software Bill of Materials), czyli cyfrowego spisu treści oprogramowania, zawierającego dokładne informacje o wszystkich komponentach, bibliotekach i ich wersjach.
