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.
Każda zmiana, choćby najmniejsza, w rozbudowanym środowisku firmowym może nieść za sobą poważne konsekwencje dla wielu obszarów organizacji. Z tego względu wszystkie zmiany, szczególnie w obszarze IT, powinny odbywać się w ramach sformalizowanego procesu. Dzięki temu łatwiej jest utrzymać ciągłość działania systemów i usług, a tym samym zapewnić ciągłość działalności operacyjnej przedsiębiorstwa.
Proces zarządzania zmianami (ang. change management) określa między innymi częstotliwość wprowadzania aktualizacji, dopuszczalne typy zmian wraz z harmonogramem ich wdrażania oraz plan przywrócenia poprzedniej wersji w razie poważnych problemów.
Bez odpowiednio przemyślanego i udokumentowanego procesu zarządzania zmianami, moglibyśmy doprowadzić do poważnych problemów, które negatywnie wpływają na procesy biznesowe. Wyobraźmy sobie sytuację, iż różne osoby z działu IT, bez porozumienia między sobą, wprowadzają własne modyfikacje, które są niekompatybilne.
Niemalże każda organizacja dąży do równowagi pomiędzy bezpieczeństwem i użytecznością. Sformalizowany proces zarządzania zmianą okazuje się bardzo pomocnym narzędziem w drodze do osiągnięcia tej równowagi, ponieważ zmusza osoby decyzyjne do przemyślenia i oszacowania ewentualnych konsekwencji.
Approval process
Każda zmiana powinna zostać formalnie zatwierdzona przez odpowiedni podmiot decyzyjny. Pierwszym krokiem w procesie wdrażania zmian jest przygotowanie formalnego zgłoszenia (zapotrzebowania) na określoną aktualizację. Taki dokument (zazwyczaj w formie elektronicznej) powinien zawierać m.in. opis modyfikacji, jej cel, zakres oraz potencjalne skutki – w tym zagrożenia – a także planowany czas implementacji. Są to informacje niezbędne dla zespołu decyzyjnego, który ocenia, czy daną modyfikację można bezpiecznie wdrożyć.
Rada ds. zarządzania zmianą (ang. Change Control Board lub Change Advisory Board) – dysponując wszystkimi niezbędnymi danymi – może oszacować ryzyko związane z wdrożeniem zmiany w określonym czasie i zestawić je z ryzykiem jej niewprowadzenia.
Oczywiście, coś za coś: mając rozbudowany i sformalizowany proces zatwierdzania zmian, zmniejszamy liczbę pomyłek oraz ryzyko niepożądanych skutków, ale z drugiej strony, czas od zgłoszenia potrzeby modyfikacji do jej wdrożenia może się wydłużyć. Należy więc odpowiednio ocenić, co w danym momencie jest ważniejsze dla organizacji.
W bardzo skrajnych przypadkach, gdy administrator jest zmuszony do natychmiastowego wprowadzenia zmiany (np. w środku nocy), aby przywrócić działanie krytycznych usług, oczekiwanie na formalną decyzję może nie być wskazane. W takim przypadku zmiana powinna zostać odpowiednio udokumentowana i przejść cały proces akceptacji ex post (po fakcie).
Ownership
Proces wprowadzania zmian przeważnie zaczyna się od tzw. właściciela zasobu (ang. asset owner) lub właściciela produktu (ang. product owner). Chodzi tutaj o osobę zarządzającą danym zasobem lub produktem, którym może być aplikacja, system, a choćby zbiór danych.
Właściciel inicjuje zmiany, ale sam ich nie wdraża. Może jednak do pewnego stopnia zarządzać całym procesem. Przykładowo, owner powinien być informowany o przebiegu wdrażania oraz o ewentualnych problemach. Po zakończeniu procesu jest odpowiedzialny za weryfikację poprawnego działania podlegających mu zasobów.
Właścicielem nie musi być jedna osoba – może to być zespół, a choćby cały dział organizacji. Krótko mówiąc, są to osoby z tzw. biznesu, które zlecają wprowadzenie zmian zespołom IT.
Stakeholders
Interesariusze (ang. stakeholders) to wszystkie podmioty – osoby, działy lub organizacje – których dana zmiana dotyczy. Dlatego również oni powinni zostać poinformowani o planowanych pracach oraz ich ewentualnych konsekwencjach.
Identyfikacja wszystkich interesariuszy może być sporym wyzwaniem, ponieważ nie zawsze jest oczywista. Na przykład prosta aktualizacja bazy danych, polegająca na zmianie nazwy kolumny, może wpływać nie tylko na korzystające z niej aplikacje i ich użytkowników. Może się bowiem okazać, iż dział analiz generuje raporty na podstawie bezpośrednich zapytań do wspomnianej bazy – z pominięciem aplikacji. jeżeli analitycy nie zostaną poinformowani o zmianie nazwy istotnej kolumny, ich zapytania SQL generujące raporty przestaną działać.
Po wdrożeniu zmiany często prosi się użytkowników, których ta zmiana dotknęła, o weryfikację, czy wszystko przez cały czas działa poprawnie.
Impact analysis
Analiza skutków (ang. impact analysis) polega na oszacowaniu potencjalnych konsekwencji wdrożenia (bądź niewdrożenia) określonej zmiany. Każda zmiana może mieć różne skutki dla organizacji, dlatego zawsze należy ocenić potencjalne ryzyko jej zastosowania – wysokie, średnie lub minimalne.
Ryzykiem może być również sytuacja, w której aktualizacja lub poprawka niczego nie zepsuła, ale także nie spełniła swojej roli (np. wprowadzono poprawkę błędu w kodzie, ale nieskutecznie, i problem przez cały czas występuje). Należy także uwzględnić ryzyko niezaaplikowania pożądanej zmiany. Na przykład brak aktualizacji systemu może doprowadzić do sytuacji, w której krytyczna podatność nie zostanie usunięta, co zwiększa ryzyko udanego ataku.
Test results
Przed wdrożeniem zmian w środowisku produkcyjnym warto najpierw przeprowadzić stosowne testy w odizolowanym środowisku testowym, które czasami nazywane jest piaskownicą (ang. sandbox).
Nawet jeżeli testy zakończą się pomyślnie, czasami warto wprowadzać duże zmiany stopniowo. Na przykład aktualizacja środowiska produkcyjnego może na początku objąć tylko jedną, najmniej krytyczną usługę. jeżeli stwierdzimy, iż wszystko działa prawidłowo, możemy rozszerzyć aktualizację na kolejne, ważniejsze usługi.
Środowisko testowe powinno być możliwie jak najbardziej zbliżone do środowiska produkcyjnego, aby uniknąć problemów wynikających z rozbieżnej konfiguracji i nie przeoczyć potencjalnych błędów w przyszłości.
Backout plan
Nawet jeżeli testy przebiegły pomyślnie, bardzo istotne jest przygotowanie szczegółowej procedury wycofania zmiany, która powinna być przetestowana i dobrze udokumentowana. Docenimy to szczególnie podczas nocnych wdrożeń – gdy o 3 nad ranem coś pójdzie nie tak i okaże się, iż jedynym wyjściem jest przywrócenie pierwotnego stanu.
Niektóre zmiany mogą być proste do wycofania (np. przywrócenie poprzedniej wersji aplikacji jednym kliknięciem, jeżeli mamy prawidłowo skonfigurowane pipeline’y CI/CD), ale są też takie, których cofnięcie wymaga większego wysiłku (np. gdy podczas migracji danych wystąpił błąd i część tabel w bazie została zaktualizowana, a część nie).
Oprócz planu awaryjnego warto mieć również pełne backupy danych oraz konfiguracji. jeżeli coś pójdzie naprawdę źle, a wycofanie zmian okaże się mocno problematyczne, zawsze możemy przywrócić stan systemu, aplikacji czy bazy danych z ostatniej kopii zapasowej – dlatego tak ważne jest, by były one regularnie tworzone i możliwie aktualne.
Maintenance window
Ważnym aspektem procesu zarządzania zmianami jest ustalenie, kiedy powinno nastąpić wdrożenie. Okazuje się, iż nie zawsze jest to takie oczywiste – nie chcemy przecież zakłócić pracy organizacji, a przynajmniej nie na długo.
Jeśli zmiana wiąże się z niedostępnością określonych usług, często trzeba ją wprowadzić poza godzinami biznesowymi. jeżeli działalność opiera się na potrzebie ciągłego funkcjonowania (jak np. banki czy serwisy informacyjne), najlepiej takie operacje przeprowadzać w nocy – czyli wtedy, gdy najmniej osób korzysta z usług organizacji.
Ustalony czas, w którym zmiana może zostać w miarę bezpiecznie wprowadzona, nazywamy oknem serwisowym (ang. maintenance window) i należy o nim poinformować wszystkich interesariuszy.
Warto również rozważyć, czy nie jesteśmy akurat w trakcie gorącego okresu dla przedsiębiorstwa. Na przykład dla firm sprzedażowych takim czasem może być okres przed Bożym Narodzeniem, w którym obserwuje się duży wzrost zamówień. Dlatego też każde okno serwisowe powinno zostać wcześniej formalnie zatwierdzone przez odpowiednie jednostki organizacyjne (np. CAB = Change Advisory Board).
Standard operating procedure
Standardowa procedura operacyjna (ang. standard operating procedure, SOP) to dokument zawierający zbiór szczegółowych instrukcji i procedur obowiązujących w danej organizacji, który powinien być dostępny dla wszystkich zainteresowanych pracowników (np. za pośrednictwem intranetu). Mówiąc krótko, jest to zbiór instrukcji pomagających pracownikom wykonywać swoje obowiązki.
Procedura zarządzania zmianami powinna być częścią SOP. Należy w niej zaznaczyć, iż żadna zmiana nie może zostać wprowadzona bez uprzedniego uzyskania zgody (ang. approval) od odpowiedniego podmiotu (np. CAB).
Przykładowa zawartość dokumentu opisującego proces zarządzania zmianą może obejmować następujące punkty:
- Zgłoszenie potrzebnej zmiany. jeżeli pojawia się potrzeba wdrożenia określonej modyfikacji, należy to formalnie zgłosić dzięki systemu używanego przez organizację (np. Jira). Oprócz informacji o tym, co należy zmienić, istotne jest również rzeczowe uzasadnienie.
- Przegląd i analiza zgłoszenia. Każde żądanie zmiany powinno zostać dogłębnie przeanalizowane pod kątem potencjalnego ryzyka (impact analysis) i uzgodnione z wszystkimi zainteresowanymi, których dana zmiana może dotknąć. Analiza jest zwykle przeprowadzana przez odpowiedni zespół CAB (Change Advisory Board), który może spotykać się regularnie (np. raz w tygodniu) lub w trybie ad hoc, jeżeli wymaga tego sytuacja (np. poprawka krytycznej podatności, gdzie czas odgrywa istotną rolę).
- Zatwierdzenie bądź odrzucenie zmiany. Zespół (możliwy także jednoosobowy) podejmuje decyzję o wdrożeniu zgłoszonej zmiany bądź jej odrzuceniu, na podstawie otrzymanych informacji oraz przeprowadzonej analizy. Decyzja wraz z jej uzasadnieniem powinna zostać odpowiednio udokumentowana. Odrzucenie nie musi być definitywne – może się zdarzyć, iż żądanie zmiany wymaga uzupełnienia o dodatkowe informacje (np. procedurę przywrócenia pierwotnej wersji w razie niepowodzenia), zanim zostanie zaakceptowane.
- Testowanie zmiany. choćby jeżeli żądanie wdrożenia zmiany zostało zaakceptowane, powinna istnieć możliwość przetestowania wprowadzonych modyfikacji w odizolowanym środowisku, zbliżonym do produkcyjnego. Pozwoli to zweryfikować, czy nie wystąpią nieprzewidziane wcześniej komplikacje.
- Zaplanowanie i wdrożenie zmiany. Gdy modyfikacja została przetestowana i jest gotowa do wprowadzenia, należy ustalić termin jej wdrożenia (w ramach wspomnianego wcześniej maintenance window).
- Aktualizacja dokumentacji. Każda wprowadzona zmiana powinna zostać odnotowana w dokumentacji stosowanej przez organizację, celem utrzymania jej aktualności.
